Hi, I'm trying to use the regexp mapper with a specific classpath (much as it is now possible with style). The documentation says : « The regexp mapper needs a supporting library and an implementation of org.apache.tools.ant.util.regexp.RegexpMatcher that hides the specifics of the library. Ant comes with implementations for the java.util.regex package of JDK 1.4, jakarta-regexp and jakarta-ORO. If you compile from sources and plan to use one of them, make sure the libraries are in your CLASSPATH. » and indeed, with one of these jars in the build classpath, the mapper will work. However when the classpath is specified via the documented classpathref attribute of mapper : *** <path id="regexp.path"> <pathelement location="lib/extlib/regexp/1.2/lib/jakarta-regexp-1.2.jar"/> </path> <target name="make-src"> <copy todir="${dest}"> <mapper to="\1/\2" from="^(.*)/src/java/(.*)$$" classpathref="regexp.path" type="regexp"/> *** ant will fail with : No supported regular expression matcher found So there seem to be a problem somewhere. That's a pain, the regexp jar is downloaded somewhere else in the build process and therefore I can't use in in the general classpath since it won't exist at first. (btw a nested classpath element to mapper would be nice)
I think this is a classloader problem that we cannot easily resolve. If you remove org/apache/tools/ant/util/regexp/JakartaRegexpMatcher.class from optional.jar and add it to the classpath of the mapper, it will probably work. For a description of why this happens, see bug#3934 for further explanation of the classloader issue. BTW - <mapper> does support nested <classpath> elements 8-)
It is ? Then that's a documentation bug (that's the kind of bug I *love*). However will it work better than classpathref here ? A for bug#3934, if there are no references to another regexp parser in ant internal classes, I don't see why it should apply. As far as I see the problem is not clashes between my jar specification and some internal ant one, but that somehow ant forgets to seeache the specified classpathref for a valid RegexpMatcher
OK, let's start with the documentation bug - it is documented in my copy, but I'm not 100% sure that the paragraph The classpath can be specified via a nested <classpath>, as well - that is, a path-like structure. has always been there - I've changed the file to add a heading and make it more visible now. No, a nested <classpath> element will do exactly the same as your classpathref attribute. Let me rephrase what I've written in the style case for regexp - it is not about conflicting libraries or so: org.apache.tools.ant.util.regexp.JakartaRegexpRegexp is part of optional.jar. optional.jar is in ANT_HOME/lib and thus will be put into CLASSPATH, which means it can be found by the system classloader - the parent of all classloaders. You give an additional classpath that contains the jakarta-regexp library and maybe even set the system property to tell Ant you want to use jakarta-regexp. Ant tries to load org.apache.tools.ant.util.regexp.JakartaRegexpRegexp via a new classloader that contains the CLASSPATH you've specified. Being a good classloader, Ant's classloader does like Sun asks it to do and consults the system classloader first. Great, the class can be found and loaded via the system classloader. Now, this class needs additional classes from the JAR you've supplied - it tries to load them, but as it has been loaded via the system classloader, it doesn't know about your JAR and fails to find the classes. This is where my proposed solution kicks in, remove the class from optional.jar. If the class cannot be found via the system classloader, you can specify the additional library as well. I hope this is at least a little clearer.
Ok. I think this time I've understood this. Does that mean ant will never consult the specified classpath if optionnal.jar is present as in any normal installation ? Why doesn't he tries a second time on the specified classpeth if the system one fails ? I don't really see the point of ant scripts if you have to go on all the user posts modify the default ant install to make them work (this is the frustrated me speaking:()
Please see whether I make any sense in what I've written in the description of the META BUG. I think in the case of mappers, things are even worse as the regexp classes have been part of ant.jar and not optional.jar (this will be different in the future). The way it is right now in Ant - ant.jar and optional.jar are on CLASSPATH is legacy and there is nothing much we could do without breaking backwards compatibility. Most users will rather clutter their CLASSPATH with the required libraries instead of using nested <classpath> elements in their build files - for those users the default of having optional.jar in CLASSPATH is correct. I'm not trying to defend the current situation and I completely understand your frustration, but I'm afraid we cannot fix it without breaking backwards compatibility. *** This bug has been marked as a duplicate of 6606 ***