Hi Dominique,
    ohh, it is at the more global level.  interesting.  I would like that on top of compile with walls which is at the package level(smaller than a jar).  I will have to look at that when I get back from vacation and think about both tasks a little more.  Up until now, I have had a large build.xml that copied the needed jars so those were the dependencies.  Of course it was a little messy.  this proposal sounds better.  I will think about it more when I get back from vacation.  I think I want both then
thanks for the info,
Dean

Dominique Devienne wrote:
That's not what I meant...

I would prefer an API which would allow to specify the source groups, and
there dependencies (between each other, and to external JARs), so that I can
plug my own way of specifying this information.

This is what I did with BuildPath and BuildPathResolver:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=12368 (last attachment).

Pluging-in custom implementations will be even easier in Ant 1.6 after
Peter's enhancements to Ant core, since that custom impl can be configured
in XML as any other tasks.

The task should provide a way to specify the constraints in the build file
itself, or from an external file as you propose, but that should not be the
only way to specify the constraints... This is the flexibility I will need.

I hope this helps clarify my comment. --DD

-----Original Message-----
From: Dean Hiller [mailto:dean@xsoftware.biz] 
Sent: Thursday, September 04, 2003 6:47 PM
To: Inger, Matthew
Cc: 'Dominique Devienne'; 'Stefan Bodewig';
ant-contrib-developers@lists.sourceforge.net
Subject: Re: [Ant-contrib-developers] new ant task

Actually, I was thinking if people liked this, it could be changed to
<compilewithwalls  file="descriptor.xml"> (or whatever name you like, I
don't mind if it's changed)
</compilewithwalls>

instead of embedding the descriptor in the xml file.  I didn't know if it
would be liked or not and was just testing the waters.  I will make that
change also.  For the cc task then it would look like so????....

<compilewithwalls>
 <cc>.....</cc>
</compilewithwalls>

Is this what you meant Matthew?
thanks,
dean

Inger, Matthew wrote:

I'll clarify my comment about the <cc> task.  It sounds 
like you're making an XML descriptor to automate the build 
process for a java project.  The same thing would be nice 
for the cc task.  Basically, to keep developers out of the 
ANT script, and let them be able to add libraries,flags, 
etc... to the build process. 

---------------- 
Matthew Inger [inger@synygy.com] 
Software Developer 
Synygy, Inc 
610-664-7433 x 7770 
"Man who jump off cliff, leap to conclusions." - Confucious 

-----Original Message----- 
From: Dominique Devienne [mailto:DDevienne@lgc.com] 
Sent: Thursday, September 04, 2003 11:49 AM 
To: 'Stefan Bodewig'; ant-contrib-developers@lists.sourceforge.net 
Subject: RE: [Ant-contrib-developers] new ant task 

+1. I don't like the name too much though... Any other suggestions? 
Once it's in, it will be easier to make it evolve. The XSL-based system I 
currently have, and would very much like to replace with something like this

task, reads the definition of what the project sub-parts are, and which 
dependencies they each have, between each other, but also with external 
JARs. I enable part of this functionality thru a <buildpath> element that 
extends Path, and allows to plug-in a custom BuildPathResolver to determine 
the build order. (I've posted that code). 
The ability to compile a project's subpart independently is great, but the 
exact dependencies between these parts, and for each part of external JARs 
is something that I (and I suspect other) really need. 
My $0.02. --DD 
  
-----Original Message----- 
From: Stefan Bodewig [mailto:bodewig@apache.org] 
Sent: Thursday, September 04, 2003 10:11 AM 
To: ant-contrib-developers@lists.sourceforge.net 
Subject: Re: [Ant-contrib-developers] new ant task 

I was waiting for anybody else to comment on Dean's compilewithwalls 
task.  I really like the idea and would like to see it somewhere. 

Ant is more or less in a no-new-tasks-accepted state and I don't 
expect it to change until after the release of Ant 1.6.  Maybe we'll 
see multiple antlibs as subprojects of Ant after that, who knows. 

Dean's task is really useful, well documented and tested IMHO and I 
see it as a good fit for ant-contrib.  What do others think? 

Stefan