Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [rt-pmc] IP FAQ

Joakim, 

Thanks for your detailed feedback.  The IP process is focused mainly on things that are "distributed" from eclipse.org.  That means that CQs and works-with requirements generally do not apply to tooling used in the development process.  Individuals and projects are welcome to get and use whatever tooling they want (subject to the constraints around commercial tools). There is a bit of a grey area around things like JUnit where developers write tests that directly reference the third party libs but ignoring that for now, it seems that most of the things you mention are not subject to the IP policy at all.

Having said that, since you ask the question, it is likely a good one to include in the FAQ and ensure that we get a solid answer from the IP team.  Could you add a question that captures your concern?  Feel free to add other questions that you think are on the minds of others in the communities you mention.

Thanks
Jeff

On 2010-05-28, at 1:19 PM, Joakim Erdfelt wrote:

The section on fetching of libs from non-eclipse repos is too narrow.
Not all content fetched from maven central is for product dependencies, runtime, or testing.
That section needs to be more clear about what kind of content from maven central needs to go through a CQ.
For those of us using more advanced tooling like maven (or buildr) the whole "works-with" concept is vague and unclear.
I strongly encourage you to be very clear and precise about what you expect from the projects.
Based on prior discussion about "works-with" in other threads, I would tend to err on the side of being paranoid and file a CQ for everything that even possibly shows up in memory during a maven build.

Examples of content from maven central that is not a distributed artifact with the project, and is not for testing, but is used actively, and daily, by many maven projects within the Eclipse community...

enforcer plugin (build requirements, environment requirements, release requirements)
checkstyle plugin (static syntax and formatting analysis)
pmd plugin (static source analysis)
findbugs plugin (static bytecode analysis)
osgi plugin (to manage osgi versions, setup release enforcement, validate osgi rules)
bundle plugin (to create bundles from maven build metadata)
ant plugin (used to make ant build from maven build, to interfaces with orbit, to supplement build for tasks only avaialble as ant tasks)
rpm plugin (packaging for linux)
deb plugin (packaging for linux)
site plugin (top level plugin used for various build time reports)
doxia plugin (for generating build reports, used by site plugin)
javadoc plugin (for generating and aggregating javadoc)
jxr plugin (java cross reference generation, used by other plugins to provide meaningful context to source related reports)
project-info-reports plugin (suite of reports about the project and its dependencies)
wagon plugins (for performing network operations on the build artifacts, deploy, etc...)
scm plugins (for interacting with CVS, SVN, GIT)
cobertura or clover plugins (for testing coverage)
assembly plugin (for assembling arbitrary content into zips, tarballs, etc ...)
gpg plugin (for signing and verifying artifacts)
jarsigner plugin (for signing bytecode)
maven core plugins (jar, war, resources, surefire, etc)
release plugin (for performing all the steps needed for a release of the project)
source plugin (for assembling up all of the projects source into a jar file suitable for linkage of dependencies in eclipse)
eclipse plugin (for generating eclipse project files for the maven project)

This is just a _short_ list of some of the popular plugins seen on a maven project.
I'm sure that of the maven projects in eclipse, they are using close to 90% of the plugins listed above, a few more not listed, and might even have a few plugins and archetype that the project themselves have even created.

If we take just the above list, and their downstream dependencies (example: the pmd-plugin.jar needs pmd.jar), then we are looking at close to 300 new CQs (and that's assuming a single version of each of the above plugins)

Please address these (currently) gray area artifacts in the FAQ.

There are many developers within the Eclipse community that contribute / commit / manage and push forward these more advanced build toolchains (maven, buildr, etc..), please engage them and learn from their experience on the nuances of how the various kinds of artifacts are used.   The global developer community has moved towards these build toolchains in large numbers, it is important to recognize this trend.  These toolchains have already been through the pain of categorizing and identifying how the build artifacts and dependencies are used, their experience and knowledge is valuable to the Eclipse IP and CQ problems.  Do not ignore this tremendously valuable resource you have access to.

Know also, that if certain critical plugins in the list above are rejected as part of going through the Eclipse IP/CQ process, then those projects using maven cannot exist in the Eclipse community.
For many of us using Maven, the prospect of this possibility scares us! 

I can't overstate how important being clear about this section is to many projects.

- Joakim Erdfelt
Jetty Developer


On Fri, May 28, 2010 at 9:00 AM, Jeff McAffer <jeff@xxxxxxxxxxxxxxxxx> wrote:
Recently there have been a number of questions coming up around IP issues.  Particularly around works-with dependencies, testing scenarios, fetching things from other non-eclipse places, ...

After some discussion with Janet and Wayne and various project folks, I created a DRAFT IP FAQ to capture some of the questions and some thoughts on answers.

Please take a look at
       http://wiki.eclipse.org/RT/IP_FAQ
and see what you think about both the questions and the answers.  Remember, this is just a first cut and is NOT a definitive guide. In particular, if there are additional questions or scenarios, please add them. If you think the existing info is ambiguous, incorrect, incomplete, ... please comment.

Jeff


_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc

_______________________________________________
rt-pmc mailing list
rt-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/rt-pmc


Back to the top