Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cross-project-issues-dev] Policy on unreleased or non-participating dependencies

This question has come up before .... if an Eclipse Project can release, while it depends on something that is not released. And there are two flavors: a) the dependency has never released at all, and b) the dependency has been released before, but the project is not participating in current release train.

The issue was discussed in bug 370974 [1] and the Planning Council decided in March 7th meeting [2] to the following policy statement.  It partially just re-states EDP rules, but makes it clear that "orbit-like" dependencies are fine. (I'm not completely sure how the current cases fit in to this ... gef3d, gemini, etc., but thought I'd provide pointers to the policy).

A project can not be in the Sim. Release, or Released at all, if they include things that are unreleased from other projects (and this is true of any release, not just Sim. Release).

A project can include releases from other Eclipse projects, even if that other project is itself not part of the Simultaneous Release. This still requires the "other project's release" meets all the requirements for Release and Sim. Release ... signed jars, about.html file, etc. This is conceptually just like including a third party package from Orbit ... the original authors do not "participate" in the Release, but the bundles meet all the release requirements.



From:        Thomas Watson/Austin/IBM@IBMUS
To:        Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>,
Date:        06/06/2012 09:58 AM
Subject:        Re: [cross-project-issues-dev] Layout and licenses
Sent by:        cross-project-issues-dev-bounces@xxxxxxxxxxx

I don't know anything about why gemini.jpa or gef3d are getting added to the repo, but this made me think about your question:

"If these bundles are in the repository, shouldn't the owning projects be Juno particpants?"

I don't know the correct answer, but it strikes me as odd that we allow non-eclipse third party dependencies to be added to the repo, but when it comes to a dependency on another project's bundles we force the other owning project to participate fully in the release.  What if the project does not want to participate?  What if there is an IP acceptable alternative (non-eclipse) project that could be used?  Would we prefer the use of that non-eclipse third party technology over the eclipse one simple because the owning eclipse project does not want to participate in the Juno release?  It seems to me that such cases should be treated as any other third party dependency and we should not force the owning project to participate in the release.


Inactive hide details for Wayne Beaton ---06/06/2012 08:17:55 AM---Hey folks. I'm going through the layout and licenses reportsWayne Beaton ---06/06/2012 08:17:55 AM---Hey folks. I'm going through the layout and licenses reports today.


Wayne Beaton <wayne@xxxxxxxxxxx>




06/06/2012 08:17 AM


[cross-project-issues-dev] Layout and licenses

Hey folks. I'm going through the layout and licenses reports today.

I've already opened a couple of bugs regarding missing about files and am just starting into the licenses. These issues need to be addressed before any reviews can be declared successful. Note that these are very basic requirements that are independent of participation in the simultaneous release. If you need help, please ask.

There a Gemini JPA bundle in the repository. I'm also seeing a GEF3D bundle. Why? If these bundles are in the repository, shouldn't the owning projects be Juno particpants? Or did I miss a memo?


Who owns these bundles:


(I'll guess tools.ptp.photran based on the version number).

Wayne Beaton
The Eclipse Foundation
Twitter: @waynebeaton
Eclipse Projects_______________________________________________
cross-project-issues-dev mailing list

cross-project-issues-dev mailing list

Attachment: STG32175
Description: Binary data

Attachment: STG13724
Description: Binary data

Attachment: STG18042
Description: Binary data

Attachment: STG04855
Description: Binary data

Attachment: STG02568
Description: Binary data

Attachment: STG26006
Description: Binary data

Attachment: STG32071
Description: Binary data

Attachment: STG50688
Description: Binary data

Attachment: STG52403
Description: Binary data

Back to the top