https://bz.apache.org/bugzilla/show_bug.cgi?id=61365
Bug ID: 61365
Summary: Solve the "large classpath problem"
Product: Ant
Version: unspecified
Hardware: PC
Status: NEW
Severity: normal
Priority: P2
Component: Core
Assignee: [email protected]
Reporter: [email protected]
Target Milestone: ---
Me and according to Google a very large bunch of other people face the "large
classpath problem": Having many jar files in the classpath breaks calls to
javac and java.
The solution currently advertised in many forums in to create a jar file that
contains paths to the really used jars in its manifest and then to pass this
jar file as the only classpath element. This solution is in my eyes far from
optimal because it creates a new file on disk which is also ugly to create in
the build.xml (add about 20 lines just to work around a problem that many users
face, see
https://stackoverflow.com/questions/31006815/relative-paths-for-classpath-in-build-xml-ant-build).
Solution 1: Add a relative="true" attribute to the <Classpath> element which
works similar as the relative="true" in the <Property> element (Maybe also a
basedir attribute). I don't know if it would be better to add these attributes
to the <pathelement> or maybe both, because I don't know the implementaton
details. I sometimes create my classpaths from pathelements, and sometimes from
filesets (which should therefore also be optionally relative) so decide for
yourself on a solution that covers all bases.
A relative classpath should store all its elements in a relative way (vs.
storing them as absolute paths and just converting them to relative during
output). This might also help some users that use globbing to map a classpath
to another directory.
Solution 2 (preferred): Also I wonder if it wouldn't be possible to
automatically convert the Classpath to relative paths at the time java or javac
are called! When these programs are forked ant already knows the work directory
for these tools. It could therefore just strip the working directory from the
classpath entries that point to jars below the working directory at least. This
creates shorter command lines, looks much better in logfiles and is currently
my preferred solution because then there is no need to change the docs or api.
--
You are receiving this mail because:
You are the assignee for the bug.
