Skip to main content
Jump to: navigation, search

Difference between revisions of "MicroProfile/3rdPartyDependencyProcess"

(Included a link to a spreadsheet for keeping track of dependencies)
m
Line 7: Line 7:
 
=== Source Originality ===
 
=== 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.
+
Whenever a [https://www.eclipse.org/projects/handbook/#release Release is created] for 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 ===
 
=== 3rd Party Open Source ===
Line 17: Line 17:
 
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].
 
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].
+
Since the MicroProfile project is developing individual components (config, fault tolerance, 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 ===
 
=== 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...
+
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 may change to Type B.  But, for now, Type A reviews are sufficient.
  
 
=== Spreadsheet ===
 
=== Spreadsheet ===

Revision as of 10:18, 7 December 2017

Contribution Questionnaires (CQ)

All software contributed to or used by an Eclipse project needs to be properly vetted by the Eclipse Intellectual Property Office (IPO). This vetting is initiated by a Contribution Questionnaire. Once a Contribution Questionnaire is created, it is turned into an 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 tracked via this CQ.

Source Originality

Whenever a Release is created for 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 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 good description of this process.

Since the MicroProfile project is developing individual components (config, fault tolerance, metrics, etc), the initial set of Build and Test CQs were created on a per-component basis. Here is an example Build and Test CQ.

Type A vs Type B Due Diligence

This CQ Section of our process is a synopsis of a 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 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 may change to Type B. But, for now, Type A reviews are sufficient.

Spreadsheet

To help with keeping track of our 3rd Party Dependency clearances, I have created this Google Sheet (spreadsheet). Please reference this spreadsheet as you are creating or updating your pom.xml files with your component's dependencies. It is currently sorted on the name of the 3rd Party Dependency, which is normally based on the Maven artifactId. We will need to keep this up-to-date for the overall MicroProfile project. (Let Kevin know if you don't have access to this spreadsheet.)

A flowchart, if you are interested...

Eclipse also provides this flowchart as a guide to help find your way through their IP process... It's not for the faint of heart, but it did help with deciphering some of the ins and outs of the process.

Back to the top