RE: enumerating all classes in a package
There's nothing that I know of in the JDK to search a path consisting of urls by patterns and certainly there is no help in the ClassLoader and Package APIs for discovering classes. I thought that you might be able to hack on the funny RMI classloader, but since it sounds like it delegates to another classloader, it too is probably insulated from the actual file system where resources are located. I think you are going to have to either: 1. Tell the JUnit runner explicity which test classes to execute, or 2. Provide the JUnit runner network access to the file systems, perhaps through http, ftp, nfs, or samba, so it can resolve and search urls itself, or 3. Copy all resource local to the JUnit runner, a la GUMP. Personally, I like the first approach better because it allows you to have multiple, disributed JUnit runners work in parallel. Imagine an ant task the uses a fileset to find all of the **/*Test.class files (ie the test classes) and uses a registry to find or ssh to launch distributed JUnit runners with which to distribute those test classes. The ant task would also have to provide each JUnit runner with a suitable classpath so that the JUnit runner would be able to access any other resources it needs to execute the test. Finally, the ant task collates the results into a final report and mails it off. didge > -Original Message- > From: Steve Loughran [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 20, 2004 9:04 AM > To: Ant Developers List > Subject: Re: enumerating all classes in a package > > > didge wrote: > > What JDK version(s) do you need to support? Can you provide an > example of > > the classpath you have to search? Who's 'funny RMI > classloaders' are they? > > > > didge > > I'm trying to run junit remotely, so get something like a package name > "org.example.tests" and want to search for a specified pattern > "*Test\\.class" and get all classes that match it that the current > classloader knows about. Maybe recursively. > > The funny RMI classloader was written by a colleague, which adds extra > security to a normal one (resources are copied locally for signature > verification & other tricks). The key is that it (and parents) can be > configured with various urls to files, and the test runner has its code > auto-deployed from the URLs as needed. > > > > > > >>-Original Message- > >>From: Steve Loughran [mailto:[EMAIL PROTECTED] > >>Sent: Thursday, May 20, 2004 3:37 AM > >>To: Ant Developers List > >>Subject: enumerating all classes in a package > >> > >> > >> > >>Anyone know how to enum all classes defined in a package? I want to > >>search for *Test.class on a defined classpath, without having access to > >>the JARs as files I can get at (i.e. they are remote stuff coming > >>through funny RMI classloaders). > >> > >> > >>-steve > >> > >>- > >>To unsubscribe, e-mail: [EMAIL PROTECTED] > >>For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: enumerating all classes in a package
What JDK version(s) do you need to support? Can you provide an example of the classpath you have to search? Who's 'funny RMI classloaders' are they? didge > -Original Message- > From: Steve Loughran [mailto:[EMAIL PROTECTED] > Sent: Thursday, May 20, 2004 3:37 AM > To: Ant Developers List > Subject: enumerating all classes in a package > > > > Anyone know how to enum all classes defined in a package? I want to > search for *Test.class on a defined classpath, without having access to > the JARs as files I can get at (i.e. they are remote stuff coming > through funny RMI classloaders). > > > -steve > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: antlib and classloaders
So what's to say that we can't build up an ANTLIB_PATH just like we build up
CLASSPATHs using ?
didge
> -Original Message-
> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
> Sent: Friday, April 02, 2004 2:46 AM
> To: Ant Developers List; [EMAIL PROTECTED]
> Subject: RE: antlib and classloaders
>
>
> The only issue I have with your suggestions is the fact that
> they require the user to express dependencies outside the project
> itself.
>
> This may be fine for many, but if you have to deal with multiple
> projects
> that require different sets of dependencies, it would be nice if one
> could express this in the buildfile itself were it can be more easily
> maintained.
>
> The alternative today that most of us have to use is to create our own
> build.{sh,cmd,bat} and place the correct -lib args in the script.
> But then you may have to maintain that script too during the life of the
> project.
>
> My aim is to try to provide an in-buildfile alternative.
>
> Jose Alberto
>
> > -Original Message-
> > From: didge [mailto:[EMAIL PROTECTED]
> > Sent: 02 April 2004 01:16
> > To: Ant Developers List
> > Subject: RE: antlib and classloaders
> >
> >
> > How about just supporting an equivalent of an LD_LIBRARY_PATH
> > for antlibs, called ANTLIB_PATH or some such?
> >
> > didge
> >
> > > -Original Message-
> > > From: Matt Benson [mailto:[EMAIL PROTECTED]
> > > Sent: Thursday, April 01, 2004 1:58 PM
> > > To: Ant Developers List
> > > Subject: Re: antlib and classloaders
> > >
> > >
> > > I'm not sure I followed your suggestion. As far as
> > > allowing a way to automagically include stuff without
> > > adding it to the base installation, Antoine added the
> > > -lib option and Conor extended it to pull all jars
> > > from directories on (looks like) a path-style argument
> > specified with
> > > that option (as well as including the directories
> > themselves). So now
> > > I can store lots of antlib.xml files right on the filesystem, say
> > > under $HOME/.ant/lib in multiple package structures, set
> > > ANT_ARGS to include "-lib $HOME/.ant/lib" and voila!
> > > I can now modify commonly-used antlibs all I want.
> > >
> > > Now we can conceive of auto-installers that modify $HOME/.antrc to
> > > append -lib options to ANT_ARGS to point to 3rd-party
> > stuff... since
> > > windows systems are less likely to use shared Ant
> > installations, Un*x
> > > is the most useful place for this stuff.
> > >
> > > -Matt
> > >
> > > --- Jose Alberto Fernandez <[EMAIL PROTECTED]>
> > > wrote:
> > > >
> > > > Hi, I have been giving some thought on ways to solve
> > > > this nagging
> > > > issue of needing to put antlib jars on the lib
> > > > directory.
> > > >
> > > > We hear over and over people wanting to keep their
> > > > third party
> > > > libraries out of -lib because they are only for an
> > > > specific project.
> > > >
> > > > As I see it, our road block has been how to tell in
> > succinct way in
> > > > the buildfile that when loading the namespace
> > > > "antlib:foo.bar" you should
> > > > use this or that classpath or classloader.
> > > >
> > > > A simple solution could be to achieve this by name
> > > > association:
> > > >
> > > > - When ANT tries to find and load the resource for
> > "antlib:foo.bar"
> > > > it will first look for a reference named "foo.bar"
> > > > representing
> > > > a classloader (or classpath?). If an object of the
> > > > correct type is
> > > > found, then this classloader will be user for
> > > > resolving and loadding
> > > > the antlib, otherwise the default classloader will
> > > > be use, as it is
> > > > today.
> > > >
> > > > So with this in place, one could write things like:
> > > >
> > > >
> > > >
> > > > .
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Before jumping on a code proposal, does this sound a
> > > > the right or good
> > > > solution? Does this cover enough of the use cases?
> > > >
> > > > Let me kn
RE: antlib and classloaders
How about just supporting an equivalent of an LD_LIBRARY_PATH for antlibs, called ANTLIB_PATH or some such? didge > -Original Message- > From: Matt Benson [mailto:[EMAIL PROTECTED] > Sent: Thursday, April 01, 2004 1:58 PM > To: Ant Developers List > Subject: Re: antlib and classloaders > > > I'm not sure I followed your suggestion. As far as > allowing a way to automagically include stuff without > adding it to the base installation, Antoine added the > -lib option and Conor extended it to pull all jars > from directories on (looks like) a path-style argument > specified with that option (as well as including the > directories themselves). So now I can store lots of > antlib.xml files right on the filesystem, say under > $HOME/.ant/lib in multiple package structures, set > ANT_ARGS to include "-lib $HOME/.ant/lib" and voila! > I can now modify commonly-used antlibs all I want. > > Now we can conceive of auto-installers that modify > $HOME/.antrc to append -lib options to ANT_ARGS to > point to 3rd-party stuff... since windows systems are > less likely to use shared Ant installations, Un*x is > the most useful place for this stuff. > > -Matt > > --- Jose Alberto Fernandez <[EMAIL PROTECTED]> > wrote: > > > > Hi, I have been giving some thought on ways to solve > > this nagging > > issue of needing to put antlib jars on the lib > > directory. > > > > We hear over and over people wanting to keep their > > third party > > libraries out of -lib because they are only for an > > specific project. > > > > As I see it, our road block has been how to tell in > > succinct way in the > > buildfile that when loading the namespace > > "antlib:foo.bar" you should > > use this or that classpath or classloader. > > > > A simple solution could be to achieve this by name > > association: > > > > - When ANT tries to find and load the resource for > > "antlib:foo.bar" > > it will first look for a reference named "foo.bar" > > representing > > a classloader (or classpath?). If an object of the > > correct type is > > found, then this classloader will be user for > > resolving and loadding > > the antlib, otherwise the default classloader will > > be use, as it is > > today. > > > > So with this in place, one could write things like: > > > > > > > > . > > > > > > > > > > > > Before jumping on a code proposal, does this sound a > > the right or good > > solution? Does this cover enough of the use cases? > > > > Let me know what you people think. > > > > Jose Aberto > > > > > > > > > > > > - > > To unsubscribe, e-mail: > > [EMAIL PROTECTED] > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > __ > Do you Yahoo!? > Yahoo! Small Business $15K Web Design Giveaway > http://promotions.yahoo.com/design_giveaway/ > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Blog "Complex build systems need a real language" found
I tend to sympathize with the assertion since certainly as my build scripts have grown in complexity, I have found that I would greatly benefit from the same structuring functionality commonly found in general purpose scripting languages that support modularity, reuse and extension, but that are missing or lacking in Ant. To be sure, , , , Antlib, namespaces, and others address many of these issues, and are welcome, powerful and useful additions to Ant, making it more manegeable than ever before. However, they have also come at the cost of unresolved edge cases and ungainly syntax. I offer as an example what can be done when the basis of a build script is not a new language, but an existing, general purpose scripting language. As an experiment, I attempted to mimic Ant's style and organization as a language extension of python, i.e. packaged as a python module such that build scripts are pure python. Thus, build authors benefit from python's cross-platform scripting capabilities and mature structuring fuctionality. The project's admittedly unimaginative working title is 'pant'. In pant, I ported the main concepts of target, task, project, fileset, javac, copy, and delete, among others. Here is what a simple build file looks like, my hope is that it would be readily comprehensible by Ant users even if they don't know much python: # build.py - example pyant build script import os from pant import * project = Project(name = "test", default = "build") class properties(Target): classesdir = "build/classes" srcdir = "src" jarname = "test.jar" class compile(Target): depends = properties def run(self): javac(src = properties.srcdir, destdir = properties.classesdir) class clean(Target): depends = properties def run(self): delete(dir = properties.classesdir) class jar(Target): depends = properties def run(self): jar( destfile = properties.jarname, basedir = properties.srcname, destdir = properties.classesdir) class build(Target): def run(self): clean() compile() jar() Notes: 0. Everything in this example is pure python. There are no modifications to the language itself. 1. Targets are defined by subclassing pant.Target. 2. The depends class variable of a subclass of Target is a list of other Target subclasses and is analgous to the depends attribute of Ant's target element. 3. The body of a Target subclass's run method is analogous to the body of an Ant target's element content. Within the run method's body, any legal python code may be executed and normal scoping rules apply. After all dependent targets are run, if any, the run method of a Target is called, if defined. 4. Targets may be run by simply calling them, i.e. clean(). 5. Targets may be defined in another python script and imported using python's import keyword. 6. Parameters may be passed to Targets when calling them, e.g. clean(dir="some/dir") didge > -Original Message- > From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > Sent: Wednesday, January 21, 2004 10:09 AM > To: Ant Developers List > Subject: RE: Blog "Complex build systems need a real language" found > > > > From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > > > > From: Peter Reilly [mailto:[EMAIL PROTECTED] > > > > > > According to the last entry, they are currently > > > using a 45,000 line ant script =-O > > > which one of the team is reducing to ~700 lines by > > > using a custom dependency task. > > > > I didn't read all the thread completely, but I heartedly > > agree with Peter that much of the complexity of an Ant > > script can be removed by developing custom tasks/types. > > > > You go to Java to encapsulate complex processes, which are > > then exposed as much simpler high level tasks hiding all the > > coding complexities. Using Python in AAP, or Ruby might allow > > easier/faster programming than Java, but Java can do it all > > nonetheless, and I personally know Java much better than > > Python and Ruby ;-) > > > > And with scriptdef, you can write your tasks just the same in any > supported > scripting language, if it will fit your needs. > > Jose Alberto > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: XML Namespace avoids collision between xml vocabularies was RE: a comment about xml namespace
> -Original Message- > From: Steve Loughran [mailto:[EMAIL PROTECTED] > Sent: Tuesday, December 30, 2003 3:48 PM > To: Ant Developers List > Subject: Re: XML Namespace avoids collision between xml vocabularies was > RE: a comment about xml namespace > > > Jim Fuller wrote: > >>From: Steve Loughran [mailto:[EMAIL PROTECTED] > >>Sent: 29 December 2003 17:59 > >>Subject: Re: XML Namespace avoids collision between xml vocabularies > > > > was > > > >>RE: a comment about xml namespace > >>If you are interested in this kind of thing, point your browser at > >>http://1060.org and d/l a build of NetKernel -preferably 2.1 when it > >>ships shortly. This is definitely a generic XML processor engine which > >>does plenty much magic, like (in v2.1) autobinding a database select > > > > to > > > >>an XML document for later xformation. > > > > > > [Jim Fuller] interesting, will have a look... > > > > yes, worth a play. > > On an ant topic, they have an alternate dependency model, one not that > suited to a generic build process, but ideal for an XML engine. > > Here is where we are today: > > Ant: leave everything to the tasks > Make: declare everything > msbuild: declare everything (I think) > > NetKernel code consists of a set of instructions, all with a standard > syntax for operands and results, with different XML in the operand > field. The engine takes the operands and concatenates that with the > operator and constructs a URI that describes the operation. > > e.g. here is me applying xtidy to some generated code: > > XHTMLTidy > this:response > > /results/row/details > > var:tidied_details > > > The cool thing is that the contents of every operation are cached; > stored in the cache relative to the URI in. Which means that next time > the command is executed, if the inputs havent changed, the cached result > is returned instead. > > So the SQL query used to generate the XML to tidy up is just stuck in in > front, with the runtime handling all the details of pooling, database to > xml binding and choosing when to run stuff: > > stm > > > http://1060.org/stm";> > > SELECT * > from col > where col.colID= xpath="substring-after(/uri , ':')"/> > ; > > > > var:col > var:sql > > > Col > var:sql > > sqlQuery > > this:response > > > Of course, there is a problem: what if another operation has side > effects, like a SQL update. That is where you need to create pseudo > dependencies that sequences say they depend on; other things can touch > these to mark them out of date. > > The nice thing about this model is that there is a single engine > managing caching across all the threads working away, and it caches the > intermediate stuff, with various controls to choose when stuff expires > (different stuff can be marked as more important, so a big db query is > cached above some little xslt operation). > > Like I said, I dont see it applying to Ant, but it shows an alternate > world view in the XML-workflow-language space, at least for a workflow > focused on a server handling requests, doing things and sending the > results back. > > > > > > [Jim Fuller] uhhh, I just want an xml document to be used by multiple > > processors, not have Ant *be* the generic processor. I always assume > > that data lives longer then the applications that generate or manipulate > > themoh well as I said, I will leave this thread asis, for the time > > being. I need to spend a few days looking at Ant internals, before I > > comment any further. > > Ok, that is all right then. > > Maybe we should have > > 1. an type; takes generic XML. > > 2. an type, that takes generic XML with an ID that you can > refer to later. So any task that wants to use XML inline, can share the > data. > > Thoughts? And yes, I know (1) and (2) are nearly identical. But (1) > could discard all internal sax events. > > -steve > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: trying to get access to fileset from new task to javac task
Dean,
vppjavac (vpp.sourceforge.net, source available) wraps javac too perform
file preprocessing on the source path before invoking javac. The intent was
that vppjavac be a 'drop-in' replacement for javac. Originally, I'd hope to
simply extend Javac, however, because of the protected visibility of the src
fileset, I had to additionally create a new instance of Javac and execute it
in vppjavac's execute() method. So, my solution was to both extend and
create a new instance. I figure the extension still has value since it
guarantees that vppjavac's public interface is still a superset of javac's.
Here is how I invoke Javac internally, you could probabaly just cut & paste
this and fix the srcdir property how you want:
// Since the source path can't be reset directly, we have to create
a
// new Javac...
Javac javac = new Javac();
// --> set this how you want <--
javac.setSrcdir(somePath);
// ant properties
javac.setOwningTarget(getOwningTarget());
javac.setNowarn(javac.getNowarn());
javac.setFailonerror(getFailonerror());
javac.setLocation(getLocation());
javac.setTaskName(getTaskName());
// javac properties
javac.setDestdir(getDestdir());
javac.setEncoding(getEncoding());
javac.setDebug(getDebug());
javac.setOptimize(getOptimize());
javac.setDeprecation(getDeprecation());
javac.setDepend(getDepend());
javac.setVerbose(getVerbose());
javac.setTarget(getTarget());
javac.setBootclasspath(getBootclasspath());
javac.setExtdirs(getExtdirs());
javac.setClasspath(getClasspath());
javac.setProject(getProject());
javac.setLocation(getLocation());
javac.setIncludeantruntime(getIncludeantruntime());
javac.setIncludejavaruntime(getIncludejavaruntime());
javac.setMemoryInitialSize(getMemoryInitialSize());
javac.setMemoryMaximumSize(getMemoryMaximumSize());
// Compile!!
javac.execute();
Why should the src fileset be immutable when not much else is, particularly
classpath? No clue, maybe someone can shed some light on this...
didge
> -Original Message-
> From: Dean Hiller [mailto:[EMAIL PROTECTED]
> Sent: Monday, August 25, 2003 6:25 AM
> To: Ant Developers List
> Subject: Re: trying to get access to fileset from new task to javac task
>
>
> I am compiling the same src directory every time, but with different
> patterns.
>
> Javac uses the FileSet in MatchingTask. I currently have a hack into
> MatchingTask adding
> public void putNewFileSet(FileSet set) {
> fileset = set;
> }
> because I am not sure how to change out the FileSet of patterns. Above
> works for me, but is there an easier way ***without changing the ant
> base*** to get what I want.
>
> Your last statement is exactly my intention.
> thanks,
> dean
>
>
>
> Stefan Bodewig wrote:
>
> >On Sun, 24 Aug 2003, Dean Hiller <[EMAIL PROTECTED]> wrote:
> >
> >
> >
> >>I am writing a new task that happens to wrap javac and call it a few
> >>times. Is there any way to clear the FileSet?
> >>
> >>
> >
> >javac doesn't use a FileSet at all, or it uses a fresh FileSet for all
> > and srcdir entries - depends on how you look at it.
> >
> >
> >
> >>Short story is I want to reuse the same javac with all the same
> >>parameters compiling a different fileset each time.
> >>
> >>
> >
> >Compiling a different src directory?
> >
> >
> >
> >>Maybe it would be ok to put a public clearFileSet in
> >>MatchingTask.java???
> >>
> >>
> >
> >That would only affect the include/exclude patterns but nothing else.
> >
> >Stefan
> >
> >-
> >To unsubscribe, e-mail: [EMAIL PROTECTED]
> >For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
> >
> >
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: javac-task and mapper
> Have you tried it? I haven't, but somehow I doubt it will work... That's
> just a guess though. --DD
It works, but I actually use a very different version in practice to achieve
something similar to Ulf's original wish: a way in which projects can
inherit common project behavior and yet still allow for optional extensions
or overrides.
First, some background: My projects generally have a single src subdirectory
where all .java files go. However, some projects use additional
subdirectories to contain the output of code generators. (I don't like to
mix source and generated code because it gets to annoying to figure out
which is which when they are colocated in the same directory.)
Therefore, I needed a way for a project to specify its source directories,
but I wanted to use a common set of targets for building. Let me tell you,
this was not easy to figure out. In much more than just a nutshell, this is
what I do:
Each project contains a build.xml minimally containing the target 'init'
which initializes a number of properties unique to the project: javadoc
name, jar name, version and a couple of other things. In addition, the
'init' target may also specify extensions to the default source and class
paths. By default, projects get default source and class paths of 'src' and
'build/classes:lib/*.jar:lib/*.zip'. For a project that wants to extend its
source path, to include 'gen' for example, then its 'init' target must
initialize a property containing the extended path.
This is achieved by constructing a path, called 'javac.sourcepath', composed
of the default source path (usually just 'src') and an extended source path,
if any.
This gets complicated, but essentially I have an XML fragment called
buildTargets.xml that defines my regular build targets and properties. This
fragment is included (via XML) into each project's build.xml that wants to
use it.
Here are the relevant portions of buildTargets.xml and a project's
build.xml, with an explanation following so you can get an idea how this
works:
buildTargets.xml:
And here is an clip from one of my project build.xml files showing the
'init' and XML include:
]>
&buildTargets;
How it works: Issuing the 'ant compile' command, results in the following
sequence of target being executed:
init
buildTargets.setDefaultExtendedCompileSourcepath
buildTargets.init
compile
As you can see, 'init' defines the extended sourcepath, and the next target
does nothing since the extended sourcepath was defined. 'buildTargets.init'
then merges the default sourcepath and the extended sourcepath into a single
property, ('javac.sourcepath') and 'compile' uses it. It is hopefully clear
then that if 'init' does not define an extension, then only the default
source path is used by 'compile'. (Note that it was necessary to ensure that
'buildTargets.extended.javac.sourcepath' is defined before
'buildTargets.init' is executed otherwise the used to construct
'javac.sourcepath' can choke on an undefined property if the project does
not define an extended sourcepath.)
I've simplified things here a bunch to keep this as brief as possible and on
topic. However, there are a couple of other interesting features that my
scripts do as well:
1. Projects can override any target specified in buildTargets.xml, eg.
compile, clean, build, javadoc, etc. using indirect target references.
2. JDK specific classpaths and build tools are specifiable. This allows me
to easily build the same source against multiple JDK versions that may
require different sets of 3rd party libraries due to incompatibilities with
particular JDK versions.
I'd be happy to share more as people express interest.
didge
> -Original Message-
> From: Dominique Devienne [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, August 20, 2003 6:57 AM
> To: 'Ant Developers List'
> Subject: RE: javac-task and mapper
>
>
>
> > -Original Message-
> > From: didge [mailto:[EMAIL PROTECTED]
> > Sent: Tuesday, August 19, 2003 7:14 PM
> > To: Ant Developers List
> > Subject: RE: javac-task and mapper
> >
> > How about this?
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > didge
> >
> > > -Original Message-
> > > From: Ulf Caspers [mailto:[EMAIL PROTECTED]
> > > Sent: Tuesday, August 19, 2003 11:06 AM
> > > To: [EMAIL PROTECTED]
>
RE: javac-task and mapper
How about this? didge > -Original Message- > From: Ulf Caspers [mailto:[EMAIL PROTECTED] > Sent: Tuesday, August 19, 2003 11:06 AM > To: [EMAIL PROTECTED] > Subject: RE: javac-task and mapper > > > On Mon, 18 Aug 2003, Dominique Devienne <[EMAIL PROTECTED]> wrote: > > > All you need to do is: > > > > > > > > > > > > > > No need for a mapper. Works like a charm ;-) --DD > > This is true - as long as you know the names and the number of the > "team"s. > > My wish is to create a single build.xml-file that is usable for all > projects - no matter which teams are envolved. > > Ulf > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
