Community
Participate
Working Groups
There is a discussion on the crossproject why Riena is contributing a Nebula Grid 1.0.0.HEAD Version to the Kepler composite Repo. This bug tracks the discussion around it. http://dev.eclipse.org/mhonarc/lists/cross-project-issues-dev/msg09228.html
I totally agree that having a 1.0.0.HEAD version in the composite repo is wrong and should be corrected. We have used other components from the Nebula projects in the past however (the Composite Table) which we dont use anymore. At that time I have CQs and email conversions with Janet Campell, Barb Cochrane and Wayne Beaton with the result that I can in fact restribute software from another Eclipse project as long as I follow the IP guidelines. Its specifically NOT necessary that this project has a release. One pointer was this well-known PDF http://www.eclipse.org/legal/EclipseLegalProcessPoster.pdf From the PDF and from emails from Janet, I think I would have needed a CQ for Nebula Grid (and I dont have one…. shame on me). So thats certainly wrong….. The CQ for the Composite Table is here https://dev.eclipse.org/ipzilla/show_bug.cgi?id=3180 . At that time I submitted the CQ and then later I also added the source code as zip although it was already in source control (CVS back then). Jeff McAffer back then noted that it was pretty odd that I attached source code for eclipse.org software but he approved it. Following that I had some email exchange with Janet and Barb about what if the source code moves on in CVS and they said its ok unless there is new third party code introduced. I also remember that at the time we added the Nebula Grid to our build there was NO downloadable build available from Nebula. I agree we should have checked every now and then, but that escaped us. So bottom line: I think I can restribute unreleased code from other projects in my own repository if I have a CQ for that It should have used a specific build number rather than 1.0.0.HEAD (even if we had to create one ourselves) Moving forward I will add a CQ change the build to use a specific build of Nebula rather than 1.0.0.HEAD
I don't know what was said about using unreleased project's code in your own project's repo, but I there is a difference in what you do in your own project's repo, and what you contribute to the common Sim. Release. In the common Sim. Release repo, we require released code. See http://wiki.eclipse.org/SimRel/Simultaneous_Release_FAQ#Can_a_Simultaneous_Release_project_include_bundles_or_features_from_a_project_not_in_the_Simultaneous_Release.3F Especially where it says ... = = = = It can "include" another Eclipse Project that is not in the Simultaneous Release, if that other other Eclipse Project has been released before, and if that other Eclipse project (still) meets all the requirements of a Release (such as correct about.html files, etc.) and also the extra requirements of Simultaneous Release (such as signed jars, etc.,). This is analogous to the use of "third party" bundles from Orbit, where the original authors clearly do not "participate" in the release ... = = = =
Ok so you certainly make the rules for simrels. I am confused about Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=370974 where it says that I cannot have unreleased Eclipse software in my own projects releases. That is clearly the opposite of what the IP Team have told me. They said, if I have a CQ then yes I can put it in my own release. Check the release train for the last 4 years I would say. Except last year (where Riena was not in the composite repo) you find a nebula composite table which is no longer in Kepler (we dont use it anymore) and which was not released at the time it was in the release train repo. Maybe that was not ok for the simrel, but I believe that CQ 3180 allowed me to put it in the Riena release repo. (and maybe the version of the composite table was not that helpful :-) )
(In reply to comment #3) > Ok so you certainly make the rules for simrels. > > I am confused about Bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=370974 > where it says that I cannot have unreleased Eclipse software in my own > projects releases. > > That is clearly the opposite of what the IP Team have told me. They said, if > I have a CQ then yes I can put it in my own release. > > Check the release train for the last 4 years I would say. Except last year > (where Riena was not in the composite repo) you find a nebula composite > table which is no longer in Kepler (we dont use it anymore) and which was > not released at the time it was in the release train repo. > > Maybe that was not ok for the simrel, but I believe that CQ 3180 allowed me > to put it in the Riena release repo. (and maybe the version of the composite > table was not that helpful :-) ) what I mean was that the nebula composite table jar has the version number of the tag that we used back then. Not a build number.
(In reply to comment #3) > Ok so you certainly make the rules for simrels. > > I am confused ... Yes, I'm confused too :) Which is why I commented. I think essentially it comes down to the conceptual difference of you "re-using code from an unreleased project" vs. "you yourself releasing code from an unreleased project". The later of course puts a higher burden on "you", essentially requiring you to take full responsibility for that code for that release. But, I'll admit I need to think about this more and am interested in hearing the opinions of others. But, I do know the goal of the Sim. Release common repo is that adopters and users can "count on it" as a source of for their own distributions or production environments. As long as we meet that goal, I'm happy.
I think that is pretty much the point. We release Grid from Nebula as OUR component which as you said means that we take responsibilty. Maybe the key is that this is ok in a project p2 repo but not everything is melted together in a composite repo. Then the namespace defines who is responsible and no one will open a bug against Riena when the Grid component has a bug. (they might do when they got the Grid from a Riena repo) I have opened a CQ question asking the IP Team for advise. (only if a CQ is now required for Kepler) I will fix this of course in the next build of Riena for first service release.
Thanks for the elaborate explanation. Please note that the compositetable is also in the kepler repo. Did you remove it from all your features? What I am confused about is the impact on people trying to install Riena code and then Nebula code. I assume that they are not able to install our version of Grid if Riena is installed and vice versa. I think the correct way of including software from other projects is to make sure you get a complete feature and not include a single bundle in your own feature.
> We release Grid from Nebula as OUR component which as you said means that we > take responsibilty. A project cannot use another project's namespace. All names (including the root package and bundle namespace) are granted to the project upon a successful creation review and only that project gets to use those names. So even if per IP process, you were ok taking the code in question and releasing it as part of a Riena release, the only way for this to be fully ok is to re-package it. The stakes are higher in the simrel repository due the widespread impact, but the issue here is not limited to simrel.
(In reply to comment #8) > > We release Grid from Nebula as OUR component which as you said means that we > > take responsibilty. > > A project cannot use another project's namespace. All names (including the > root package and bundle namespace) are granted to the project upon a > successful creation review and only that project gets to use those names. So > even if per IP process, you were ok taking the code in question and > releasing it as part of a Riena release, the only way for this to be fully > ok is to re-package it. > > The stakes are higher in the simrel repository due the widespread impact, > but the issue here is not limited to simrel. You make it sound that I am hijacking the namespace of a different project. That would be really bad. But thats not what we are doing. We are distributing code that the other project has open sourced. They decided not to do a release yet but we thought its good enough for us already. Outside the scope of simrel which I realize is more complicated, I don't see why that is forbidden. The IP Rules allow it as I explained. So I am sure you have a link to a document in the Eclipse guidelines that backup your claim that its forbidden.
(In reply to comment #7) > Thanks for the elaborate explanation. > > Please note that the compositetable is also in the kepler repo. Did you > remove it from all your features? > > What I am confused about is the impact on people trying to install Riena > code and then Nebula code. I assume that they are not able to install our > version of Grid if Riena is installed and vice versa. > > I think the correct way of including software from other projects is to make > sure you get a complete feature and not include a single bundle in your own > feature. You are right I was wrong here. We had plans to drop support for the composite table but then we decided not to do in Kepler but after Kepler. We use that build of the composite table now for a number of years since the code base does not move. David Orme (PL of the composite table back then) created a tag for us which we used since then. So he knew about it and was ok with it. We (Elias Volonakis) submitted a number of patches to the composite table which were never applied. (we open also bugreports which were never solved)
> You make it sound that I am hijacking the namespace of a different project. That is indeed what you are doing. By re-using the namespace, you are impersonating the project and putting out a fake release. > The IP Rules allow it as I explained. The IP rules have nothing to do with this. Control over naming rights is part of Eclipse Development Process. Name assignment and use authorization is handled by EMO.
(In reply to comment #11) > > You make it sound that I am hijacking the namespace of a different project. > > That is indeed what you are doing. By re-using the namespace, you are > impersonating the project and putting out a fake release. > > > The IP Rules allow it as I explained. > > The IP rules have nothing to do with this. Control over naming rights is > part of Eclipse Development Process. Name assignment and use authorization > is handled by EMO. I wish you had link that you can point to, but apparently you dont or its tooo obvious. Riena also contributed the nebula composite table to previous release trains. We have even a CQ for that 3180. It was approved by the IP Team, by the RT-PMC and then later the IP Log was approved by EMO and IP. The earliest IP Log I could find was from 2009 where we had the contribution of the Nebula composite table in our IP Log as approved EPL component. But obviously all these people are wrong if I understand you correctly. (And in 2009 it was clear to everyone that Nebula had never seen a release)
Through the IP process, you've secured the approval to re-use the code, but that doesn't grant you the use of the namespace. If you had re-packaged in your fork, you would have been ok. Since you didn't, you have created problems for others, which is one of the reasons that the naming rights are protected by EMO. The names are held as trademarks by Eclipse Foundation. If you want further confirmation, send an e-mail to emo _at_ eclipse.org, asking whether a project can re-use another project's namespace. I understand that it can be frustrating to wait for another project to release when you want to take a dependency, but taking matters in your own hands is not an acceptable solution. I would have liked to see Riena working with Nebula to ensure that a release happened in a timely manner. If Nebula was unresponsive, there are channels for escalating concerns in EDP.
(In reply to comment #13) > Through the IP process, you've secured the approval to re-use the code, but > that doesn't grant you the use of the namespace. If you had re-packaged in > your fork, you would have been ok. Since you didn't, you have created > problems for others, which is one of the reasons that the naming rights are > protected by EMO. The names are held as trademarks by Eclipse Foundation. > > If you want further confirmation, send an e-mail to emo _at_ eclipse.org, > asking whether a project can re-use another project's namespace. > > I understand that it can be frustrating to wait for another project to > release when you want to take a dependency, but taking matters in your own > hands is not an acceptable solution. I would have liked to see Riena working > with Nebula to ensure that a release happened in a timely manner. If Nebula > was unresponsive, there are channels for escalating concerns in EDP. I am not re-using another projects namespace and I dont have a fork. I basically run a build on the Nebula project on their content. I didnt add or change anything. And I added the outcome to my p2 repo. I dont think this is about frustration. Nebula is a very special projects. Back then when we started to use it in 2009, each bundle had its own project lead. The intention of Nebula was to never release. Never ever. It was a container for interesting SWT Widget that did get into SWT itself. While we could have escalated the topic of not accepting patches, I dont think the EDP allows me to force the Nebula project to do a release. As I said we distribute 2 components from Nebula "CompositeTable" and "Grid". We dont use the CompositeTable so much anymore so we can safely forget about it for any future milestone. So my intention for SR1 would be include latest version of "Grid" in SR1 of Riena and remove the "CompositeTable". It seems from Toms response that there just a restructuring review for Nebula but still no release. I also would create a CQ for the "Grid". I would seek advise from EMO whether that is a correct approach. I mean Riena is not super-dependant on the "Grid" widget, but its better with it :-). So I really like to include it. I dont see a release of Nebula planned :-) (the latest plan is this http://www.eclipse.org/projects/project-plan.php?planurl=/nebula/project-info/nebula-project-plan.xml) Would that be ok for the Nebula project ? Wim, Tom ?
(In reply to comment #7) > Thanks for the elaborate explanation. > > Please note that the compositetable is also in the kepler repo. Did you > remove it from all your features? > > What I am confused about is the impact on people trying to install Riena > code and then Nebula code. I assume that they are not able to install our > version of Grid if Riena is installed and vice versa. > > I think the correct way of including software from other projects is to make > sure you get a complete feature and not include a single bundle in your own > feature. BTW there seems to be a feature for every bundle or for every widget at least. So for the Grid bundle, there is the Grid feature....
> > I am not re-using another projects namespace and I dont have a fork. I > basically run a build on the Nebula project on their content. I didnt add or > change anything. And I added the outcome to my p2 repo. I wonder how you then reached 1.0.0.HEAD as the version number instead of 1.0.0.qualifier [1]. Is it a maven thing? Anyway, there are two options. 1. I start working to put out a release of Nebula that can be picked up before SR1. I am very happy to do that. 2. Riena takes the grid jar and includes that in every project that needs the Grid and fixes it before SR1. [1] https://git.eclipse.org/c/nebula/org.eclipse.nebula.git/tree/widgets/grid/org.eclipse.nebula.widgets.grid/META-INF/MANIFEST.MF > > So my intention for SR1 would be include latest version of "Grid" in SR1 of > Riena and remove the "CompositeTable". It seems from Toms response that > there just a restructuring review for Nebula but still no release. I don't think you can do that because Nebula is not yet released. But, like i said, I am happy to make a release. If it is possible to include it, then I am happy to work with you to make sure we don't bite each other.
(In reply to comment #16) > > > > I am not re-using another projects namespace and I dont have a fork. I > > basically run a build on the Nebula project on their content. I didnt add or > > change anything. And I added the outcome to my p2 repo. > > I wonder how you then reached 1.0.0.HEAD as the version number instead of > 1.0.0.qualifier [1]. Is it a maven thing? > > Anyway, there are two options. > > 1. I start working to put out a release of Nebula that can be picked up > before SR1. I am very happy to do that. > > 2. Riena takes the grid jar and includes that in every project that needs > the Grid and fixes it before SR1. > > [1] > https://git.eclipse.org/c/nebula/org.eclipse.nebula.git/tree/widgets/grid/ > org.eclipse.nebula.widgets.grid/META-INF/MANIFEST.MF > > > > > > So my intention for SR1 would be include latest version of "Grid" in SR1 of > > Riena and remove the "CompositeTable". It seems from Toms response that > > there just a restructuring review for Nebula but still no release. > > I don't think you can do that because Nebula is not yet released. But, like > i said, I am happy to make a release. If it is possible to include it, then > I am happy to work with you to make sure we don't bite each other. If you do 1. that would be really coool. I just need the grid and maybe the compositetable. (I am still unsure about the compositetable, it has many issues, still I found today that people use it together with Riena) And then I would consume those bits from you. Like I said that would be optimal. Thanks for the offer. Highly appreciated.
As Tom Watson already noted in https://bugs.eclipse.org/bugs/show_bug.cgi?id=412047 its not yet clear why a project cannot just consume a bundle and you (Wim) think we need also to consume the feature. I think that is something that happens quit often that I include a bundle into my own feature where bundle is somewhere else. Like o.e.core.net or org.junit. If I include o.e.nebula.widgets.grid in the Riena feature than all I need is the grid widget bundle + source bundle. Maybe its a little theoretical in this case because you have a feature just for that (the grid feature) but I don't think there is a rule in the EDP that I can only consume bundles by the use of the features of other projects.
(In reply to comment #18) Yes, I am probably wrong about this. My fear is the following: Riena makes a feature that includes our bundle e.g. 1.0.0.2013-0707 Then a consumer wants to install our latest build which contains the bundle 1.0.0.2013-1111 I am afraid that P2 will prevent this because your feature depends on the 0707 version AND the bundle is a singleton.
(In reply to comment #19) > (In reply to comment #18) > Yes, I am probably wrong about this. My fear is the following: > > Riena makes a feature that includes our bundle e.g. 1.0.0.2013-0707 > > Then a consumer wants to install our latest build which contains the bundle > 1.0.0.2013-1111 > > I am afraid that P2 will prevent this because your feature depends on the > 0707 version AND the bundle is a singleton. I am pretty sure that this is no problem. Our bundles specifies a minimum version but no maximum version. So upgrading a Nebula bundle will be no problem. You can also try that as soon as we have a new Nebula version (or the release). Just install a new target platform just with Riena (which contains the two Nebula bundles) and then try to add the Nebula p2 repo to that target platform. That would upgrade the two in place… Out of curiosity: Why are Nebula bundles a singleton anyway ? Have two different versions of the Grid would probably look awful but it shouldnt be a technical difficulty.
I know there are exceptions to the rule, but in general, it is best if Riena didn't refer to its need for 'grid' in a feature, at all, but simply as one of the requirements of what ever bundles use it. In that case, p2, can "sort out" what's needed to fit the requirements and install from whatever is available (that best meets the (perhaps multiple) requirements). But, again, that's just the general rule and perhaps I'm telling you what you already know and perhaps it does need to be included in a feature. Just trying to help.
(In reply to comment #20) > Out of curiosity: Why are Nebula bundles a singleton anyway ? Have two > different versions of the Grid would probably look awful but it shouldnt be > a technical difficulty. You are right. I am confused with contributions to the UI through plugin.xml. Grid does not use that so it is not/should not be a singleton.
(In reply to comment #3) > Maybe that was not ok for the simrel, but I believe that CQ 3180 allowed me > to put it in the Riena release repo. It does. AFAICT, there has been no violation of the EDP or the IP Policy. The CQ records this as a fork (the "epl" keyword indicates code to be maintained by the project). FWIW, it is perfectly reasonable for Nebula to do a 1.0 release with "1.0.1" bundle versions. There's no specific requirement for bundle versions to match the release version. Though, the PMC should take issue with a 1.0 release containing pre-1.0 bundle version numbers.
(In reply to comment #21) > I know there are exceptions to the rule, but in general, it is best if Riena > didn't refer to its need for 'grid' in a feature, at all, but simply as one > of the requirements of what ever bundles use it. In that case, p2, can "sort > out" what's needed to fit the requirements and install from whatever is > available (that best meets the (perhaps multiple) requirements). But, again, > that's just the general rule and perhaps I'm telling you what you already > know and perhaps it does need to be included in a feature. Does this work even if Grid is not in Kepler simrel?
(In reply to comment #24) > (In reply to comment #21) > > I know there are exceptions to the rule, but in general, it is best if Riena > > didn't refer to its need for 'grid' in a feature, at all, but simply as one > > of the requirements of what ever bundles use it. In that case, p2, can "sort > > out" what's needed to fit the requirements and install from whatever is > > available (that best meets the (perhaps multiple) requirements). But, again, > > that's just the general rule and perhaps I'm telling you what you already > > know and perhaps it does need to be included in a feature. > > > Does this work even if Grid is not in Kepler simrel? I dont think so either. Since Nebula is not in the simrel, someone has to get it their and that is done using a feature. Just having a dependency in a bundle doesnt tell the aggregator to include it (I believe) but I am not a knowledgable person of B3. If the aggregator takes every bundle that is in the p2 repo, then this might be correct.
Wim when would have time to start working on a release ? (I am not pushing, just try to set up a plan) Anything I can help you with ? highly appreciated if you can make it happen, as I said... christian
Wim, you proposed either a Nebula release before SR1 so that we can consume it. Is that still the plan or how are we moving forward…. christian
(In reply to comment #27) Christian I returned from holiday yesterday. I have pinged Wayne to find out if we can release. I have sent a mail to the Nebula dev mailing list asking if we want to do a release. You could help by commenting on the thread in Nebula dev.
Ok I look into nebula-dev…. There is another request on cross project about Nattable…. I will point them to this bug…. christian
RC1 +0 of SR1 of Kepler is starting this week. Since I dont see anything from Nebula, we will start working on moving all Riena code that has dependencies to extra bundles (unless that already happened). So the goal is to be free of Nebula for RC1 or SR1. We can easily reenable Nebula dependencies as soon as Nebula has released something.
Hi Cristian. Yes, we need more time to make a release. It looks like it is going to happen though. Please continue as described.
