Bug 4065 - Regexp mapper and classpath
Summary: Regexp mapper and classpath
Status: RESOLVED DUPLICATE of bug 6606
Alias: None
Product: Ant
Classification: Unclassified
Component: Core tasks (show other bugs)
Version: 1.4
Hardware: Other Linux
: P3 normal with 1 vote (vote)
Target Milestone: ---
Assignee: Ant Notifications List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2001-10-10 03:38 UTC by nicolas.mailhot
Modified: 2008-02-22 12:18 UTC (History)
0 users



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description nicolas.mailhot 2001-10-10 03:38:20 UTC
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)
Comment 1 Stefan Bodewig 2001-11-13 05:07:55 UTC
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-)
Comment 2 nicolas.mailhot 2001-11-13 07:52:14 UTC
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



Comment 3 Stefan Bodewig 2001-11-13 08:09:21 UTC
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.
Comment 4 nicolas.mailhot 2001-11-13 08:39:24 UTC
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:()
Comment 5 Stefan Bodewig 2002-02-21 11:54:15 UTC
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 ***