Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "MicroProfile/ContributingGuidelines"

(documented our CQ process)
(Deliverable group and artifact naming convention: Clarified maven artifact naming schema and aling it with current best practice)
(3 intermediate revisions by one other user not shown)
Line 3: Line 3:
 
== Ways to contribute ==
 
== Ways to contribute ==
 
* Propose ideas or give feedback in the [https://groups.google.com/forum/#!forum/microprofile MicroProfile Google Group (Forum)]
 
* Propose ideas or give feedback in the [https://groups.google.com/forum/#!forum/microprofile MicroProfile Google Group (Forum)]
* [https://github.com/eclipse/microprofile-evolution-process Submit a proposal] for a new specification or improvement
+
* [[MicroProfile/FeatureInit|Submit a proposal]] for a new specification or improvement
* Create a pull request to existing repositories (before a PR can be accepted, its contributor must undergo Eclipse processes, mainly sign the [https://www.eclipse.org/legal/CLA.php Eclipse Foundation Contributor License Agreement]
+
* Create a pull request (before a PR can be accepted, its contributor must undergo Eclipse processes, mainly sign the [https://www.eclipse.org/legal/CLA.php Eclipse Foundation Contributor License Agreement]
 
* Become a project committer (a contributor is nominated by one of the project committers and other committers vote about the nomination)
 
* Become a project committer (a contributor is nominated by one of the project committers and other committers vote about the nomination)
  
Line 79: Line 79:
  
 
<pre>
 
<pre>
   groupId: org.eclipse.microprofile.spec for all spec subprojects,
+
   groupId: org.eclipse.microprofile.<subproject> for all subprojects (specs/features or any other project like conference app)
 
   artifactId: microprofile-<subproject>-<submodule>
 
   artifactId: microprofile-<subproject>-<submodule>
 
</pre>
 
</pre>
Line 86: Line 86:
  
 
<pre>
 
<pre>
     org.eclipse.microprofile.spec.config : microprofile-config-api  - for the Config API
+
     org.eclipse.microprofile.config : microprofile-config-api  - for the Config API
     org.eclipse.microprofile.spec.config : microprofile-config-tck - for the Config TCK
+
     org.eclipse.microprofile.config : microprofile-config-tck - for the Config TCK
  
 
     org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app
 
     org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app
Line 93: Line 93:
 
</pre>
 
</pre>
  
The same project will have the same groupId.
+
The same project will have the same groupId for all artifacts (including parent).
  
 
== Java package naming conventions ==
 
== Java package naming conventions ==
Line 102: Line 102:
  
 
The discussion about this convention is [https://groups.google.com/forum/#!topic/microprofile/3Pdk1gRlVnQ on the mailing list here].
 
The discussion about this convention is [https://groups.google.com/forum/#!topic/microprofile/3Pdk1gRlVnQ on the mailing list here].
 
== Contribution Questionnaires (CQ) ==
 
 
All software contributed to or used by an Eclipse project needs to be properly [https://www.google.com/url?q=https%3A%2F%2Feclipse.org%2Forg%2Fdocuments%2FEclipse_IP_Policy.pdf&sa=D&sntz=1&usg=AFQjCNFpDmP13ild3s9cIcL9d7jgVDyx1Q vetted by the Eclipse Intellectual Property Office (IPO)].  This vetting is initiated by a [https://www.eclipse.org/projects/handbook/#ip-cq Contribution Questionnaire].  Once a [https://projects.eclipse.org/projects/technology.microprofile/cq/create Contribution Questionnaire is created], it is turned into an [https://dev.eclipse.org/ipzilla/ IPZilla bug tracker].  All interaction with the IPO is then done via the associated bug tracker.
 
 
As an example, our Initial Contribution to Eclipse was [https://dev.eclipse.org/ipzilla/show_bug.cgi?id=12628 tracked via this CQ].
 
 
=== Source Originality ===
 
 
Whenever a [https://www.eclipse.org/projects/handbook/#release Release is created] for one of our components or the overall Microprofile project, an IP review is required.  This process should cover any updates required for our Initial Contribution vetting.  That is, as a component is developed, all of us need to keep an eye on the source that is being integrated into our product to ensure we understand it's origin and license.
 
 
=== 3rd Party Open Source ===
 
 
Many of the open-source packages that MicroProfile utilizes are already vetted and approved by Eclipse (ie. JSR APIs, Apache Commons libraries, etc).  In this case, we can [https://www.eclipse.org/projects/handbook/#ip-ipzilla piggy-back] on top of the work that has already been done.  But, a CQ is still required.  When creating a CQ for 3rd Party content, you enter the name and version of the software in use.  Most times, the software is registered under the Maven artifactId (ie. commons-io or commons-lang3).  Once you start typing, Eclipse will be searching for a match.  Be creative.  If you can't find a match, then you'll have to go through the full CQ process.  A piggy-back CQ is very easy to process.
 
 
=== Build and Test Dependencies ===
 
 
All of the build and test dependencies that we use is a special case for the 3rd Party open source.  Instead of creating individual CQs for every piece of build and test software (ie. arquillian, maven, hamcrest, etc), we can group the request into a single CQ.  This link has a [https://wiki.eclipse.org/Development_Resources/IP/Test_and_Build_Dependencies good description of this process].
 
 
Since the MicroProfile project is developing individual components (config, fault tolerance, health metrics, etc), the initial set of Build and Test CQs were created on a per-component basis.  Here is an [https://dev.eclipse.org/ipzilla/show_bug.cgi?id=13755 example Build and Test CQ].
 
 
=== Type A vs Type B Due Diligence ===
 
 
This CQ Section of our process is a synopsis of a [https://groups.google.com/forum/#!topic/microprofile/CSP0rPutSGw much longer discussion] that happened in our Google group and the associated CQs.  We learned a great deal during this initial IP vetting process.  One of the key items is the use of [https://groups.google.com/d/msg/microprofile/CSP0rPutSGw/nTYLz-Z1AgAJ Type A vs Type B Due Diligence].  For our initial efforts, Type A (licensing review) is much easier to process, especially for our preliminary component releases.  Type B is a much more thorough review of the material.  Once we get through these initial reviews with Type A, we will likely change to Type B.  Or, maybe we do Type A reviews for the individual components (config, fault tolerance, etc) and use the Type B review for the MicroProfile project releases.  Still working through the details on this...
 

Revision as of 18:42, 24 August 2017

Guidelines for contributing to the MicroProfile project

Ways to contribute

Documentation Formatting Guidelines

Per a recent discussion and "vote" on our Google Group Forum, it has been decided that AsciiDoc will be our preferred documentation formatting language. Please use AsciiDoc (.adoc) for creating and formatting any proposals, specifications, README files, CONTRIBUTING files, etc as you develop artifacts for the MicroProfile project.

License of the contributed resources

All code and resources submitted via a pull request or directly (by a committer) should be licensed under the Apache License Version 2.0

License header

All files must include a license header. Moreover, a NOTICE file should exist for each repository. Author tags under a license header are optional and not mandated by the Eclipse foundation. It's strongly recommended to abide by the following templates:


A license header (included in the beginning of each file):

/**********************************************************************
* Copyright (c) {DATE} Contributors to the Eclipse Foundation
 *
 * See the NOTICES file(s) distributed with this work for additional
 * information regarding copyright ownership.
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * You may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 *     http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
*
* SPDX-License-Identifier: Apache-2.0
**********************************************************************/

{DATE} can either be a single year or a range of years separated by a comma.


NOTICE file (in the root of each repository):

SPDXVersion: SPDX-2.1
PackageName: Eclipse Microprofile
PackageHomePage: http://www.eclipse.org/microprofile
PackageLicenseDeclared: Apache-2.0
 
PackageCopyrightText: <text>
{Legal Entity 1}
{Legal Entity 2}
{Legal Entity 3}
...
</text>

The NOTICE file also has to be included in all distribution artifacts (JAR, WAR, etc.).



The templates were discussed with Eclipse mentors:

Deliverable group and artifact naming convention

We have decided here on the mailing list that we'll use the following convention for (maven) artifact and group names:

  groupId: org.eclipse.microprofile.<subproject> for all subprojects (specs/features or any other project like conference app)
  artifactId: microprofile-<subproject>-<submodule>

Examples:

    org.eclipse.microprofile.config : microprofile-config-api  - for the Config API
    org.eclipse.microprofile.config : microprofile-config-tck - for the Config TCK

    org.eclipse.microprofile.conference : microprofile-conference - for Conference Demo app
    org.eclipse.microprofile.conference : microprofile-conference-session - for the session module of the Conference app

The same project will have the same groupId for all artifacts (including parent).

Java package naming conventions

CDI API package names

The CDI API classes should be placed in a subpackage inject of the API. E.g., if the API package is named org.eclipse.microprofile.abcspec, then the package name for the CDI API should be org.eclipse.microprofile.abcspec.inject. This is to follow the convention used in javax.inject and javax.enterprise.inject.

The discussion about this convention is on the mailing list here.

Back to the top