Dear PMC members,
During the IP review of the code contribution for IAM (
https://dev.eclipse.org/ipzilla/show_bug.cgi?id=2723), we have been 
prompted
to ask the PMC the appropriate dependency type for maven archetypes 
used by
the code. I'm forwarding the whole conversation and copying Sharon 
so she's
aware of the PMC decision.
Maven Archetypes are project templates that are downloaded on demand 
from
maven repositories. As such, they can have any content and license 
and the
full list of available archetypes can not be determined in advance.
A similar thing happens with maven artifacts (archetypes are just a 
type of
artifacts). To put it simply, a maven artifact is anything that can be
downloaded from a maven repository (public or corporate, with any 
licensing
terms and any content). Typical artifacts are binary jars, source code,
javadocs and metadata.
By reading the Eclipse Policy and Procedure for 3rd Party
Dependencies<http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf>, 
I think that we don't need to declare a dependency:
*The key issue we need to address is the one where projects are 
essentially
bypassing the IP due*
*diligence process by prereq'ing third party software, which is to be
downloaded and installed separately** **by the user, instead of
redistributing such software in their projects.*
(Emphasis mine)
Since IAM downloads the files on its own, I don't think the policy 
rules
applies (the user does not download or install anything).
To me, IAM behavior is no different than P2, Buckminster, WTP 
installable
runtimes, Mylyn issue and patch management and many other eclipse 
projects
which use available external resources.
In any case, if the policy is to be followed, I think that IAM would 
need to
define a "works-with maven artifacts" dependency (if such a generic
statement is valid).
On the same line, IAM is able to download repository indexes from 
arbitrary
locations. Should we ask for a "works-with repository indexes" also?
It can also download archetype lists from any location (like a wiki 
page).
Does this require a "works-with artifact lists"?
Thanks!
Abel Muiño
---------- Forwarded message ----------
From: Abel Muiño <amuino@xxxxxxxxx>
Date: Tue, Nov 25, 2008 at 4:35 PM
Subject: Re: CQ2723: q for Eclipse
To: Sharon Corbett <sharon.corbett@xxxxxxxxxxx>
Cc: Carlos Sanchez <carlossg@xxxxxxxxx>, Barb Cochrane <
barb.cochrane@xxxxxxxxxxx>
Thanks for the detailed explanation.
Everything is clear except for "Point 2 - files are not packaged 
with IAM or
in SVN - they are downloaded at Runtime", which I think I didn't expain
clearly enough.
The user of IAM can describe the artifacts (files) that he will be 
using and
it will then ask IAM to download them as needed. Those files are not
required by IAM and, more importantly, are not known in advance.
Those files are downloaded from locations unknown to us (the user 
can point
to several locations, some of the files might be internal to his
organization).
I would say the IAM's situation is not different from P2/Update 
Manager or
Buckminster (which can download any kind of file), CVS/SVN tooling, 
(which
also can fetch some files in behalf of the user) or maybe the 
"downloadable
runtimes" from WTP (which are created by third parties without 
knowledge of
the WTP developers).
We can talk this with the PMC, but I'm hoping that it is just my bad
explanation which caused a misunderstanding, and we can skip IP 
review of
every single file that can be downloaded while using IAM (which, to 
put it
simply, is an infinite number).
Thanks for your time and good advice!
On Tue, Nov 25, 2008 at 3:36 PM, Sharon Corbett
<sharon.corbett@xxxxxxxxxxx>wrote:
Hi Guys:
Regarding Point 2 - files are not packaged with IAM or in SVN - 
they are
downloaded at Runtime.  This means that your project has a 
dependency on
these files.  As such, please see the Eclipse Guidelines for Third 
Party
Dependencies<http://www.eclipse.org/org/documents/Eclipse_Policy_and_Procedure_for_3rd_Party_Dependencies_Final.pdf>. 
You will need to discuss which dependency applies in this situation 
with
your PMC via the PMC Tech Mailing List.  You will note that "works 
with"
dependencies can be approved solely by your PMC.  However, 
"pre-exempt"
dependencies must be approved by the EMO via a submitted CQ.
Regarding Points 3 and 9 – Even a few lines of code from any third 
party
package must be requested via a CQ if they are being distributed from
Eclipse.  You can request a "subset" of files for any component 
from Maven
that you require.  You do not have to request the entire 
component.  Please
note in cases where a small amount of third party code is included 
in an EPL
File, we would expect to see a reference to the third party license 
and
identification of third party package below the EPL header.  In the 
case
where third party files are modified and distributed by Eclipse, a 
CQ again
is required and the modified files would be solely under the third 
party
license not the EPL.
Regarding the last point of delaying the submission of CQs for Maven
components (29 source/binary dependencies),  we typically do not 
review
alpha or beta code unless there are extenuating circumstances 
involved which
are dealt with on a case by case basis.  However, if any of the 
components
are in RC stages, we would recommend that you enter the CQs now as the
NonEpl due diligence queue is quite long.  For third party code 
where a full
release is imminent, you can enter the CQ now with the latest 
version and
update the CQ when the code is fully released as long as the CQ has 
not yet
been reviewed – this will ensure you are in the queue.
Regarding the advice concerning once a version of a component has been
approved; new versions are easier to process.  Yes, this is mostly 
true
depending on the length of time and the amount of changes in the 
approved
code base versus the new code.  If both of these are minimal we 
perform a
"diff" scan which typically takes less time but again keep in mind the
NonEPL queue is long.
I hope this helps.  I'm copying my colleague, Barb Cochrane, on 
this email
as Barb handles most of the third party reviews.
Regards,
Sharon
-----Original Message-----
From: Content-filter at foundation.eclipse.org [mailto:
virusalert@xxxxxxxxxxx] On Behalf Of Abel Muiño Vizcaino
Sent: Monday, November 24, 2008 4:51 PM
To: Sharon Corbett
Cc: Abel Muiño Vizcaino; Carlos Sanchez
Subject: CQ2723: q for Eclipse
Hi Sharon,
I have some questions that I think would be better addressed outside
of the CQ.
Point 2: I'm not sure we need a CQ for this. The files are not
packaged with IAM or in svn. They are downloaded as needed at runtime.
Points 3 and 9 are not covered by another CQ. Since we only use a few
lines of code, I'm wondering if we need to file a CQ for the whole
Maven component (I guess that we can file a CQ for the XSD files
alone, not so sure about java files).
Slightly related to this is that we've been delaying the submission of
CQs for maven components (29 source/binary dependencies), since many
of them have not made an official release yet and we might need to
update them very often. We currently host them outside of eclipse.
Our mentors told us that once a version of a component has been
approved, new versions are easier to process. If that's the case, we
can submit the current (unreleased) versions of the components for
review and re-submit released versions later.
Is that right? can we submit a zip of code for an unreleased version
of the maven components and have it approved?
Thanks!
Abel
- -- Abel Muiño - http://ramblingabout.wordpress.com/
- -- Abel Muiño - http://ramblingabout.wordpress.com/
 ------------------------------------------------------------------------ 
_______________________________________________
technology-pmc mailing list
technology-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/technology-pmc