Community
Participate
Working Groups
When we bootstrap, we build with the system javac. Some of the bundles involved in the bootstrap (o.e.e.p2.core is one of them) use -target=jsr14. It looks like Java 7 has made some changes to jsr14 that render it useless for our bootstrapping process. Since the bootstrapped bytecode (built with javac) is only used during bootstrap and is re-built with jdt.core (and thus proper jsr14 support), I propose making all bootstrap bundles with -target=jsr14 have -target=1.5 for the bootstrap phase and then changing them back afterwards.
Is there an easy way to do that or we will have to patch everybundle ?
Actually it's not a problem for us to make them even -target=1.6 as the only working jvm is openjdk and it starts from version 1.6
I'm looking into doing something in pdebuild.xml but my ant-fu is weak :) Something like (pseudo-code): for bundle in $depsDirs $helpDirs $depsDirs2; do if [ `grep jsr14 $bundle/build.xml` ]; then sed -i "s/jsr14/1.5" $bundle/build.xml changeBack += $bundle fi done for bundle in $changeBack; do sed -i "s/1.5/jsr14" $bundle/build.xml done
(In reply to comment #3) > I'm looking into doing something in pdebuild.xml but my ant-fu is weak :) > Something like (pseudo-code): > > for bundle in $depsDirs $helpDirs $depsDirs2; do > if [ `grep jsr14 $bundle/build.xml` ]; then > sed -i "s/jsr14/1.5" $bundle/build.xml > changeBack += $bundle > fi > done This is doable :) > > for bundle in $changeBack; do > sed -i "s/1.5/jsr14" $bundle/build.xml > done But this is not because the way back will override source(if defined) to unsupported value and might even change random version numbers e.g. 3.1.5 to 3.jsr14 :)
To achieve that we need a way to globally override ant properties. Have you tried using -Dant.build.javac.target=1.5 ? Note that we would need to ensure that all the params are properly sent to sub call.
(In reply to comment #4) > (In reply to comment #3) > > for bundle in $changeBack; do > > sed -i "s/1.5/jsr14" $bundle/build.xml > > done > > But this is not because the way back will override source(if defined) to > unsupported value and might even change random version numbers e.g. 3.1.5 to > 3.jsr14 :) Even if we keep track of which bundles we changed from <property name="bundleJavacTarget" value="jsr14"/> to <property name="bundleJavacTarget" value="1.5"/>? Alternatively we could just hard-code a property with the list of bundles that attempt to use jsr14. They are: org.eclipse.equinox.p2.artifact.repository org.eclipse.equinox.p2.console org.eclipse.equinox.p2.core org.eclipse.equinox.p2.director org.eclipse.equinox.p2.director.app org.eclipse.equinox.p2.engine org.eclipse.equinox.p2.garbagecollector org.eclipse.equinox.p2.metadata org.eclipse.equinox.p2.metadata.repository org.eclipse.equinox.p2.publisher org.eclipse.equinox.p2.publisher.eclipse org.eclipse.equinox.p2.repository org.eclipse.equinox.p2.repository.tools org.eclipse.equinox.p2.touchpoint.eclipse org.eclipse.equinox.p2.touchpoint.natives org.eclipse.equinox.p2.updatesite org.eclipse.osgi
Sami suggested that I change the build.xml files after they're generated and before they're tarred up. Since the first phase of the bootstrap is the only time these are used, this is a clean solution and we don't have to worry about changing them back (they'll be re-generated in subsequent phases).
Fixed: 9973edf0a5505856465b09ffb23665edfc510daf on eclipse37 aa3e48049e2bf92c5bba354a6065a4d319050019 on eclipse42 c96ca72c9bc087b61935481d24a3d654bc6d61b1 on master
