See /usr/portage/dev-java/sac/files/build.xml At the moment there are at least a couple build.xml files like this in the tree. It would be better if they all used the same file and ant -Dant.project.name=${PN} This file would be copied by java-config to ${S} or it could be used by giving the -buildfile option to ant.
Created attachment 58488 [details] build.xml This file is generic enough to support any basic build (that is the build requires the creation of a single jar file containing all sources within the source tree). Call using the following: ant -f build.xml -Dproject.name=sac -Dpackage.name=com.sun.sac jar,javadoc for example to build sac.
Further more, the manifest may not require special attributes (such as Main-Class).
Created attachment 58617 [details] build.xml Minor issues fixed, no changes to the call
Here you can find two functions for java-utils.eclass: https://gentooexperimental.org/svn/java/gentoo-java-experimental/eclass/java-utils.eclass javatoolkit will need to be bumped to provide the generic build.xml
Created attachment 62149 [details] include lib/*.jar I think it should include lib/* by default its easy to just jar-fom
Created attachment 62150 [details] build.xml better <javadoc> imo
No, we shouldnt require the docs to be built on "*" as there are times where the entire package is built (some optional feature is not included fex), in which case we should only build the docs on the parts that are installed. The change to the store location is prolly a good idea (can you change it to docs though?) and the classpath change should be fine.
This is starting to look nicely polished. Here is a list of packages that could have use for this: betelgeuse@pena /usr/portage $ find . -name "build*.xml" ./app-text/jing/files/build.xml ./app-text/trang/files/build.xml ./dev-db/jxtray/files/build.xml ./net-p2p/azureus/files/build.xml ./net-nds/jxplorer/files/build.xml ./dev-java/xp/files/build.xml ./dev-java/msv/files/build-20050627.xml ./dev-java/sac/files/build.xml ./dev-java/swt/files/build.xml ./dev-java/odmg/files/build-odmg.xml ./dev-java/classworlds/files/build-1.0.xml ./dev-java/cryptix/files/build.xml ./dev-java/flute/files/build.xml ./dev-java/mckoi/files/build.xml ./dev-java/saxon/files/build-8.4b.xml ./dev-java/xmldb/files/build-20011111.xml ./dev-java/swidgets/files/build.xml ./dev-java/forehead/files/build.xml ./dev-java/picocontainer/files/build-1.0_beta4.xml ./dev-java/dbunit/files/build.xml ./dev-java/avalon-framework/files/build.xml ./dev-java/iso-relax/files/build.xml ./dev-java/toolbar/files/build.xml ./dev-java/jsr173/files/build-1.0.xml ./dev-java/minml2/files/build.xml ./dev-java/eclipse-core/files/build.xml ./dev-java/eclipse-osgi/files/build.xml ./dev-java/hessian/files/build-2.1.12.xml ./dev-java/hessian/files/build-3.0.8.xml ./dev-java/jgoodies-forms/files/build.xml ./dev-java/jgoodies-looks/files/build-1.3.1.xml ./dev-java/jgoodies-looks/files/build.xml ./dev-java/xsdlib/files/build-20050627.xml ./dev-java/jgoodies-animation/files/build.xml ./dev-java/cdegroot-db/files/build.xml ./dev-java/datavision/files/build.xml ./dev-java/eclipse-jface/files/build.xml ./dev-java/kunststoff/files/build.xml ./dev-util/jcvs/files/build.xml So are we ready to bump javatoolkit to get this into official? I would have no problem if this was separate package either.
Not all of those can be replaced by this build.xml . I know for a fact that the swt one can not be nicely replaced by this build.xml
Created attachment 71219 [details] build.xml I noticed that the jar file includes the MANIFEST.MF file because it is made into the build directory. This update build.xml excludest the file.
Created attachment 71294 [details] build.xml Incorporates axxo's suggestion, but handles it more elegantly imo, and now fixes up the MANIFEST.MF issue through a conditional value of classloader.broken
Created attachment 71296 [details] build.xml Minor clean ups, improved the header, and added in allowance to modify the lib directory through the use of build.properties .
Created attachment 72695 [details] build.xml Proper copy, I hope
Is this still something we want to look at? I know when I've done per package build.xml files, they have needed some tweaks that weren't generalizable.
I'll take that as a no. I doubt that this is even necessary anymore. This was useful earlier as there were packages that needed a build.xml, and most of them very simple.
