Summary: | A generic build.xml for packages without their own build.xml | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Petteri Räty (RETIRED) <betelgeuse> |
Component: | [OLD] Development | Assignee: | Saleem Abdulrasool (RETIRED) <compnerd> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | java |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.xml
build.xml include lib/*.jar build.xml build.xml build.xml build.xml build.xml |
Description
Petteri Räty (RETIRED)
2005-05-09 08:31:05 UTC
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. |