Community
Participate
Working Groups
one of the goals of CBI was to make builds easy. users expect 'mvn clean install' to just work on any project with reasonable defaults. please remove the need to specify -Pno-bree-libs [1](or any other additional non-standard switches for that matter) to successfully do local builds. casual contributors will probably fail on this step and may give up. You can always add more switches for specific build types like release builds or "more strict" builds, but 'mvn clean install' should work out of the box and with reasonable defaults. [1] http://wiki.eclipse.org/Platform-releng/Platform_Build#Running_the_build
The no-bree-libs profile was added for exactly 2 bundles per Bug 389751. - org.eclipse.equinox.io - org.eclipse.equinox.util There was a time when this profile wasn't needed at all but I think the ideal solution would be to fix whatever introduced the problem in Bug 389751 and removing the profile altogether.
I don't know if there is some underlying problem that also needs to be fixed, but for this bug, it is not strictly required to remove the no-bree-libs profile. It would be enough if you activate it by default, and make sure you deactivate it in your central build. I think you can get this working with an "activeByDefault" profiles, which is deactivated by a different profile which is activated through a property that is set in the central build.
Cf. http://maven.apache.org/guides/introduction/introduction-to-profiles.html
Moving to Platform-Releng. I'll leave it to David to make the decision as he'd have to modify his build scripts but I think the activeByDefault is doable. People who want to use BREE libs though would have to run with an additional profile declaration to disable the profile: "-P!no-bree-libs,bree-libs" (I don't think there's anyway to have a profile deactivate another profile in Maven, but correct me if I'm wrong.)
you can activate/deactivate profiles based on the presence/absence of a property specified on the commandline [1] [1] http://www.sonatype.com/books/mvnref-book/reference/profiles-sect-activation.html
I searched for instances of "bree-libs" in the project and it seems to appear in 4 places. ./rt.equinox.bundles/bundles/org.eclipse.equinox.io/pom.xml: <id>no-bree-libs</id> ./rt.equinox.bundles/bundles/org.eclipse.equinox.util/pom.xml: <id>no-bree-libs</id> ./eclipse-platform-parent/pom.xml: <id>bree-libs</id> ./rt.equinox.p2/bundles/org.eclipse.equinox.frameworkadmin.equinox/pom.xml: <id>bree-libs</id> I think we can use a property like "-Dbree-libs=true" (and stop using -Pbree-libs) to enable BREE libs. The absence of this variable will enable the "no-bree-libs" profile. All attach a proposal patch shortly.
Its fine with me, if this is clear "will of the community", but ... I thought I read somewhere where "even if it compiles, it can have different runtime behavior that is hard to track down" ... so ... I think wiki (and elsewhere) should well document that -Pbree-libs is required for accurate builds, especially that would be used in a production environment, but that is not required just to see if there are compile errors or similar. Of course, others may know better than I ... but, just voicing my concern over choosing "simplicity" over "correctness".
Created attachment 229247 [details] platform-parent.patch This is a patch for the aggregator repo's platform parent.
Created attachment 229248 [details] equinox.bundles.patch This patch is for the rt.equinox.bundles repo.
Created attachment 229249 [details] equinox.p2.patch This patch is for the rt.equinox.p2 repo.
(In reply to comment #7) > Its fine with me, if this is clear "will of the community", but ... I > thought I read somewhere where "even if it compiles, it can have different > runtime behavior that is hard to track down" ... so ... I think wiki (and > elsewhere) should well document that -Pbree-libs is required for accurate > builds, especially that would be used in a production environment, but that > is not required just to see if there are compile errors or similar. > > Of course, others may know better than I ... but, just voicing my concern > over choosing "simplicity" over "correctness". Agreed, the wiki already discusses in the section: http://wiki.eclipse.org/Platform-releng/Platform_Build#Using_BREE_Libs But perhaps we need to make it clear in the build step as well that the build will not produce a similar build unless bree-libs is used. With the attached patches they way to activate bree-libs will be done by -Dbree-libs=true instead of -Pbree-libs. It is important that activation is done this way otherwise the "no-bree-libs" profile will not be deactivated. This means the production build scripts will need to be updated with this change otherwise the build will have mixed profiles.
I think these patches should go into 3.8, 4.2 and master branches so that we can keep the build instructions on the wiki the same regardless of branch. Otherwise we'd have branching build instructions depending on which branch the user wants to build.
So ... there's three "groups" that have to apply these changes in a coordinated way, right? equinox, equinox.p2, and releng. I'll pick and arbitrary time, and if everyone says "ok", we'll assume that's the time (+/- 15 minutes) ... otherwise, please counter with another time and we'll iterate until everyone says ok. (My only "constraint" is I'd like it to be early enough in the day that I could do some local test builds long before a Nightly build.). So ... my first proposed time will be Thursday 10 AM? (Eastern)
(In reply to comment #13) > So ... there's three "groups" that have to apply these changes in a > coordinated way, right? equinox, equinox.p2, and releng. > > I'll pick and arbitrary time, and if everyone says "ok", we'll assume that's > the time (+/- 15 minutes) ... otherwise, please counter with another time > and we'll iterate until everyone says ok. (My only "constraint" is I'd like > it to be early enough in the day that I could do some local test builds long > before a Nightly build.). > > So ... my first proposed time will be Thursday 10 AM? (Eastern) If we can say -30 minutes, then that works for me (6:30am on Thursday).
(In reply to comment #13) > So ... there's three "groups" that have to apply these changes in a > coordinated way, right? equinox, equinox.p2, and releng. > Yes, that's right.
(In reply to comment #9) > Created attachment 229248 [details] > equinox.bundles.patch > > This patch is for the rt.equinox.bundles repo. I released changes in bug 399617 such that I don't think the no-bree-libs option is needed to build org.eclipse.equinox.io and org.eclipse.equinox.util Could you test out removing the profiles altogether? If we went this route then we would have to cherry-pick my changes from bug 399717 to the Juno branch also.
(In reply to comment #16) > If we went this route > then we would have to cherry-pick my changes from bug 399717 to the Juno > branch also. I meant bug 399617 above.
(In reply to comment #16) > (In reply to comment #9) > > Created attachment 229248 [details] > > equinox.bundles.patch > > > > This patch is for the rt.equinox.bundles repo. > > I released changes in bug 399617 such that I don't think the no-bree-libs > option is needed to build org.eclipse.equinox.io and org.eclipse.equinox.util > So, just to be explicit, (and spell this out for me) ... you mean that its not needed, and gives same binary output with or without the bree-libs, right? So simply not needed, ever? Or, do you mean "it'll compile without errors without bree libs, but to get correct byte codes you still need bree libs?" If we don't need for equinox.io and equinox.util, that just leaves a few bundles in p2? Is it really needed there? Or, are we just dragging along some history?
(In reply to comment #18) > (In reply to comment #16) > > (In reply to comment #9) > > > Created attachment 229248 [details] > > > equinox.bundles.patch > > > > > > This patch is for the rt.equinox.bundles repo. > > > > I released changes in bug 399617 such that I don't think the no-bree-libs > > option is needed to build org.eclipse.equinox.io and org.eclipse.equinox.util > > > > So, just to be explicit, (and spell this out for me) ... you mean that its > not needed, and gives same binary output with or without the bree-libs, > right? So simply not needed, ever? Or, do you mean "it'll compile without > errors without bree libs, but to get correct byte codes you still need bree > libs?" > You still need -Pbree-libs to produce a similar build to the one produced on build.eclipse.org. > If we don't need for equinox.io and equinox.util, that just leaves a few > bundles in p2? Is it really needed there? Or, are we just dragging along > some history? -Pno-bree-libs was a workaround for just those 2 bundles (io, and util) to get past a compile error when building without -Pbree-libs. If whatever is causing the compile error can be fixed in code so that we don't need the profile the simpler solution is to just remove the profile -Pno-bree-libs. I'm running a build now without -Pno-bree-libs profile and will report what I find, if Thomas' code changes makes this profile no longer necessary we can just remove it from the 2 bundles.
(In reply to comment #18) > So, just to be explicit, (and spell this out for me) ... you mean that its > not needed, and gives same binary output with or without the bree-libs, > right? So simply not needed, ever? Or, do you mean "it'll compile without > errors without bree libs, but to get correct byte codes you still need bree > libs?" org.eclipse.equinox.io and org.eclipse.equinox.util projects still have the <profiles></profiles> section in the pom that specify no-bree-libs. This was needed because of some strange compile errors that would occur when trying to compile against generified class libraries in Java 5 or later but with an earlier VM target (Java 1.3 I think). I made changes in bug 399617 such that the strange compile errors did not occur when compiling against Javs 5 class libraries. So now the projects will compile without error, but they will still have the potential to compile in incorrect method calls that are not available on the lowest execution environment the bundle supports. In order to produce reliable binaries that will run on the lowest EE specified the bundles must be compiled against the lowest profile (in other words use proper bree-libs). > > If we don't need for equinox.io and equinox.util, that just leaves a few > bundles in p2? Is it really needed there? Or, are we just dragging along > some history? I will have to take a closer look at org.eclipse.equinox.frameworkadmin.equinox in p2 to know the answer. I will try to have a look this afternoon.
(In reply to comment #19) > I'm running a build now without -Pno-bree-libs profile and will report what > I find, if Thomas' code changes makes this profile no longer necessary we > can just remove it from the 2 bundles. To be clear, are you running this build with the <profiles></profiles> section removed from the two pom.xml files?
(In reply to comment #21) > (In reply to comment #19) > > I'm running a build now without -Pno-bree-libs profile and will report what > > I find, if Thomas' code changes makes this profile no longer necessary we > > can just remove it from the 2 bundles. > > To be clear, are you running this build with the <profiles></profiles> > section removed from the two pom.xml files? Yes, I removed those sections from my poms (for equinox.io and equinox.util).
(In reply to comment #20) > I will have to take a closer look at > org.eclipse.equinox.frameworkadmin.equinox in p2 to know the answer. I will > try to have a look this afternoon. I took a quick look at org.eclipse.equinox.frameworkadmin.equinox and I have no idea why the <profiles> section is needed in the pom.xml: http://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse.equinox.frameworkadmin.equinox/pom.xml Anyone know why that section is needed there? Can we just remove the <profiles> section there also?
(In reply to comment #23) > (In reply to comment #20) > > I will have to take a closer look at > > org.eclipse.equinox.frameworkadmin.equinox in p2 to know the answer. I will > > try to have a look this afternoon. > > I took a quick look at org.eclipse.equinox.frameworkadmin.equinox and I have > no idea why the <profiles> section is needed in the pom.xml: > > http://git.eclipse.org/c/equinox/rt.equinox.p2.git/tree/bundles/org.eclipse. > equinox.frameworkadmin.equinox/pom.xml > > Anyone know why that section is needed there? Can we just remove the > <profiles> section there also? There was a time many months ago when we were comparing CBI jars to PDE jars to make sure they were producing the similar jars. I recall this was one of the bundles that needed a little help to ensure it produced a similar jar to PDE's jar. You can check by passing -X parameter when running a build and checking the comparator output to see what's different.
(In reply to comment #18) > So, just to be explicit, (and spell this out for me) ... you mean that its > not needed, and gives same binary output with or without the bree-libs, > right? So simply not needed, ever? Or, do you mean "it'll compile without > errors without bree libs, but to get correct byte codes you still need bree > libs?" it seems to me there is some confusion as to what compiling against BREE libs actually does (as opposed to just using the JDK that is running the build). byte code is "correct" in both cases, i.e. compiler source and target level is set according to MANIFEST BREE in both cases, regardless of which JDK *libs* you compile against. The only difference is that say when you have a BREE: J2SE-1.5 and compile using a JDK 1.6, it's possible to accidentally use a JDK API that did not exist yet in JDK 1.5 which would then fail at JDK 1.5 runtime only. Compiling against BREE libs will make sure the build fails in this case. However, since BREE libs are hard to set up locally (you need all JDKs/execution environments installed in parallel => barrier to entry for contributors) and the added value is only to catch the corner case above, I think it's OK to compile against the currently used JDK libs by default for local developer builds. The nightly build should have the full BREE setup and will still catch the corner case above.
Created attachment 229290 [details] no-bree.patch (rt.equinox.bundles) Attached patch removes the -Pno-bree-libs profile from equinox.io and equinox.util. I was able to successfully build without this profile. I'm obsoleting the previous patches since this one is much cleaner and more ideal I think. Building on build.eclipse.org should still require -Pbree-libs but a developer building locally with this patch can build simply with "mvn clean install".
(In reply to comment #26) > Created attachment 229290 [details] > no-bree.patch (rt.equinox.bundles) > > Attached patch removes the -Pno-bree-libs profile from equinox.io and > equinox.util. > > I was able to successfully build without this profile. I'm obsoleting the > previous patches since this one is much cleaner and more ideal I think. > Building on build.eclipse.org should still require -Pbree-libs but a > developer building locally with this patch can build simply with "mvn clean > install". I will do this tomorrow after we get a successful nightly build going again. Unrelated to this bug, we have been having difficulty getting a successful build out of master today. I would like to avoid more churn until the dusk settles for our releng team ;-) To be clear, there is no longer a need to touch the parent pom or the equinox.p2 repo for this?
(In reply to comment #27) > To be clear, there is no longer a need to touch the parent pom or the > equinox.p2 repo for this? Nope, just apply the new patch to equinox.bundles and we should be good.
(In reply to comment #28) > (In reply to comment #27) > > To be clear, there is no longer a need to touch the parent pom or the > > equinox.p2 repo for this? > > Nope, just apply the new patch to equinox.bundles and we should be good. Ok, then I won't get up early to co-ordinate this from the p2 side. If there are other things that need coordination, just let me know.
I released the pom updates to master with: http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?id=f0c38a4351ffbd9008d119613099504b2b63e8fa I also released the two changes needed for R3_8_maintenance (Juno): http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?h=R3_8_maintenance&id=265cdf13797aceda9780b744e3502eed5cd81b5b http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/?h=R3_8_maintenance&id=788310b2842a1b8e1e5b948387df94414a7b24f1 It would be good if someone could test out the Juno build with these changes.
(In reply to comment #30) > I released the pom updates to master with: > > http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/ > ?id=f0c38a4351ffbd9008d119613099504b2b63e8fa > > I also released the two changes needed for R3_8_maintenance (Juno): > > http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/ > ?h=R3_8_maintenance&id=265cdf13797aceda9780b744e3502eed5cd81b5b > > http://git.eclipse.org/c/equinox/rt.equinox.bundles.git/commit/ > ?h=R3_8_maintenance&id=788310b2842a1b8e1e5b948387df94414a7b24f1 > > It would be good if someone could test out the Juno build with these changes. I'll try to run a build but it looks like 3.8 and 4.2 branches are currently broken per Bug 403352
(In reply to comment #31) > I'll try to run a build but it looks like 3.8 and 4.2 branches are currently > broken per Bug 403352 I was able to successfully build 3.8 and 4.2 with the new patch. The respective branches still have issues which I've attached patches for in Bug 403352's child bugs.
