Ok, that was a bad example. It was far too much a programmer point of
view rather than a user's. Plus it lost formatting. Let me try again
with a (hopefully) clearer example of what I think you are talking about.
artifacts name=simple-lib
artifact name=create-dirs
Unit testing has long been considered important for Ant. A published
report a few years ago (can't find it now) showed our code coverage was
among the highest of the open source projects that they reported on, as
I recall. It has often happened that committers push back on code
submissions
It sounds like you are both are on a similar wavelength. Let me see if I
understand.
A new style of build (while maintaining the old style, of course) would
be to declare some combination of resources to have similar states and
transitions between states. So something like this (just as an
On Sat, Feb 18, 2012 at 11:02 AM, Gilles Scokart gscok...@gmail.com wrote:
For me, one feature for a 2,0 would be a different style of dependency
tree that would allow better parallel execution (on the same machine,
or why not on distributed machines).
Agreed. I was in fact thinking of this
For me, one feature for a 2,0 would be a different style of dependency
tree that would allow better parallel execution (on the same machine,
or why not on distributed machines).
I see the 'targets' being more declarative, becoming a state
transition saying : I need this resources in that state, I
This too I find a great idea. Multicores mean we need more ways of
exploiting parallelism, particularly if they can be identified
automatically by the application.
For backward compatibility it would have to be optional, though, either
specified on the command line or at the build file level
Keeping it simple, is a great idea.
I am not sure if introducing parallelism is a good idea or if it's
easy to implement and maintain.
If it is design is modular, I think all these can be added as plugins.
Performance ??!!
On Sat, Feb 18, 2012 at 1:47 PM, Bruce Atherton br...@callenish.com
Of course you are right, and initially parallelism and distributed
builds will probably not be in the initial alpha release (unless it is
on someones scratching list). Just getting something to run existing
build files reliably will be fine.
But you have suggested that we tag build files that
Bruce,
The current design is simple, and proven successful and easy to
maintain. Here's a quick pseudo:
1- parse the build file, initializing all the DataStructures and
references to the tasks and macros. Populate them all to the running
context. Maybe OSGI has something like this.
2- if
On Sat, Feb 18, 2012 at 6:03 PM, Bruce Atherton br...@callenish.com wrote:
I have similar thoughts on the high level abstract view of Ant. Here is how
I see it:
1. Command Line Processor
2. Build File Parser
3. Dependency Tree Resolver
- This is essentially a Dependency Injection/IOC
2012/2/17 Bruce Atherton br...@callenish.com:
A lot of companies have their own, internally written build file generators
just so their build systems are consistent and exactly what they want. Our
Related Projects and External Tools page has some of these that were made
public, I suspect.
It doesn't require a rewrite, but a rewrite could simplify integrating a
usecase like this as well as integrating other features that we already
have into it and making them simpler and unified inthe code. I agree the
usecase is an excellent one which could simplify the lives of exactly
the
On 2/15/2012 5:48 PM, Bruce Atherton wrote:
I've read a blog post that said that one of the requirements that has
been adopted is OSGI compatibility...
Here is the post I mentioned:
http://osgithoughts.blogspot.com/2011/05/java-se-8-modularity-requirements.html
It brings up a good
Le 14 févr. 2012 à 20:02, Bruce Atherton a écrit :
On 2/14/2012 6:13 AM, Stefan Bodewig wrote:
This will lead us to the discussion of what Ant2 would be. A rewritten
Ant that remains compatible (or mostly so) on the build file level or
something quite different?
My opinion.
I
Le 15 févr. 2012 à 20:05, Mansour Al Akeel a écrit :
Another thing I don't understand about the current Ant. Why there are
derivatives from ant and they are gaining popularity ? I am talking about
gradle and easyant.
Gradle adds mutli project support, and easyant sets some conventions (I
I'd hope to go further than that in backwards compatibility. I work with
a lot of companies that are:
a) resistant to learning new things unless there is a good reason
for it (such as the migration from Apache HTTP Server from 1.x to 2.x to
resolve security issues)
b) have a number
2012/2/16 Nicolas Lalevée nicolas.lale...@hibnet.org
I cannot talk about Gradle because I never really understand the real
motive apart from the apparent cool groovy language features.
On the other hand, Easyant is about using Ant on steroïds. The idea is
basically sharing Ant build
Oops, accidental deletion.
On 2/16/2012 11:47 AM, Bruce Atherton wrote:
b) have a number of separate Ant build scripts that follow
different standards in different areas of the company, particularly if
they have acquired other companies with their own Ant builds.
On Thu, Feb 16, 2012 at 2:49 PM, Mansour Al Akeel mansour.alak...@gmail.com
wrote:
2012/2/16 Nicolas Lalevée nicolas.lale...@hibnet.org
implementation are, but a 1s launch (bash script and jvm launch included)
would be to too long for me.
Agreed.
And this is why I suggested
, were that backward binary compatibility
could only be broken through an Ant 2.0 release, and that Ant 2.0 should
do everything in its power to be build file compatible. The thinking
then was an XSLT file could be provided if necessary although at this
point I think we could provide an upgrade
to
adopt it.
Well, again, I think it's already there, no need to wait for an Ant 2.0 :)
If you add the groovy-front.jar in Ant's boot classpath, write a build.groovy,
then a launch of ant with no parameter on the command line will execute your
groovy build script. See
I haven't trawled the
mailing list to find references, were that backward binary compatibility
could only be broken through an Ant 2.0 release, and that Ant 2.0 should do
everything in its power to be build file compatible. The thinking then was an
XSLT file could be provided if necessary
Le 16 févr. 2012 à 20:49, Mansour Al Akeel a écrit :
2012/2/16 Nicolas Lalevée nicolas.lale...@hibnet.org
I cannot talk about Gradle because I never really understand the real
motive apart from the apparent cool groovy language features.
On the other hand, Easyant is about using Ant
important. They can roll out an upgrade to Ant 2,
make sure everything works as expected, and then in their own time roll
out a simplified, standardized build to each of the systems they are
currently running it.
Well, again, I think it's already there, no need to wait for an Ant 2.0 :)
If you
. But just to
check available ideas.
On Tue, Feb 14, 2012 at 2:35 PM, Bruce Atherton br...@callenish.com wrote:
On 2/13/2012 2:55 PM, Jesse Glick wrote:
On 02/13/2012 01:25 PM, Bruce Atherton wrote:
could Java 7 and NIO 2.0 be a good reason to create Ant 2.0?
While the new java.nio.file
Mansour Al Akeel mansour.alak...@gmail.com wrote on 02/15/2012 02:05:28
PM:
Is there something wrong with antlib ? Would OSGI be more convenient and
appealing for programmers to create and contribute their plugins rather
than writing their own build system ? Derivatives of eclipse exists, but
Those changes you have sound useful. Good luck with getting them
cleared, I'm sure a number of people would appreciate having access to
those hooks.
I think adding the standard packaging and deployment mechanism of Java 8
to Antlibs once 8 comes out makes a lot of sense. Once that happens
to create Ant
2.0?
There are things in NIO2 that can be added via FileUtils one way or the
other, but it could also make us rethink our concept of Resources
(although nio2's Path looks too limited for that).
If we really want to take the burden of redesigning Ant on us then it
certainly wouldn't only
, but I've still been
wondering, could Java 7 and NIO 2.0 be a good reason to create Ant
2.0?
There are things in NIO2 that can be added via FileUtils one way or the
other, but it could also make us rethink our concept of Resources
(although nio2's Path looks too limited for that).
If we really
On 2/14/2012 6:13 AM, Stefan Bodewig wrote:
This will lead us to the discussion of what Ant2 would be. A rewritten
Ant that remains compatible (or mostly so) on the build file level or
something quite different?
My opinion.
I think we need at least an option for being backwards compatible
On 2/13/2012 2:55 PM, Jesse Glick wrote:
On 02/13/2012 01:25 PM, Bruce Atherton wrote:
could Java 7 and NIO 2.0 be a good reason to create Ant 2.0?
While the new java.nio.file.* APIs are indeed valuable for a tool like
Ant, I hardly think a fork or major rewrite is required to take
)
new version of Ant that started from Java 7. Personal issues have taken
me out of the game for a while, but I've still been wondering, could
Java 7 and NIO 2.0 be a good reason to create Ant 2.0?
I realize I am violating Shut up and show me the code. While I
personally won't be able to help
version of Ant that started from Java 7. Personal issues have taken me
out of the game for a while, but I've still been wondering, could Java 7
and NIO 2.0 be a good reason to create Ant 2.0?
I realize I am violating Shut up and show me the code. While I
personally won't be able to help much
Mansour Al Akeel mansour.alak...@gmail.com wrote on 02/13/2012 01:57:56
PM:
From: Mansour Al Akeel mansour.alak...@gmail.com
To: Ant Developers List dev@ant.apache.org
Cc: Stefan Bodewig bode...@apache.org
Date: 02/13/2012 01:58 PM
Subject: Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
: 02/13/2012 01:58 PM
Subject: Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Bruce,
In fact I was thinking about the same thing. The idea of forking Ant and
rewrite parts of it to use Java 7 NIO, and introduce java plugin frame
work http://jpf.sourceforge.net/ crossed my mind few times
...@gmail.com wrote on 02/13/2012
01:57:56 PM:
From: Mansour Al Akeel mansour.alak...@gmail.com
To: Ant Developers List dev@ant.apache.org
Cc: Stefan Bodewig bode...@apache.org
Date: 02/13/2012 01:58 PM
Subject: Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
Bruce,
In fact I was thinking
:
Mansour Al Akeel mansour.alak...@gmail.com wrote on 02/13/2012
01:57:56 PM:
From: Mansour Al Akeel mansour.alak...@gmail.com
To: Ant Developers List dev@ant.apache.org
Cc: Stefan Bodewig bode...@apache.org
Date: 02/13/2012 01:58 PM
Subject: Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
On 02/13/2012 01:25 PM, Bruce Atherton wrote:
could Java 7 and NIO 2.0 be a good reason to create Ant 2.0?
While the new java.nio.file.* APIs are indeed valuable for a tool like Ant, I hardly think a fork or major rewrite is required to take advantage of them. As Stefan
pointed out, it would
.
I spent some time starting to implement a very simple (only a few tasks)
new version of Ant that started from Java 7. Personal issues have taken
me out of the game for a while, but I've still been wondering, could
Java 7 and NIO 2.0 be a good reason to create Ant 2.0?
...
It could
One thing that was voted on (positively, I recall), way way back in
time, was for Ant2.0 to fail on undefined properties.
Although I've never looked into it, can't you already have it with a
custom PropertyHelper? If you can ensure that your custom property
helper is the last one that
I've also ran into this problem, which prompted the assert task that
is now in ant-contrib as a solution. It works a lot like Java's assert
in that it can be turned on or off either through a command line
parameter or by a property. It is a task, so does require build file
modification, but it
Dale Anson wrote:
I've also ran into this problem, which prompted the assert task that
is now in ant-contrib as a solution. It works a lot like Java's assert
in that it can be turned on or off either through a command line
parameter or by a property. It is a task, so does require build file
Steve Loughran wrote:
I know Ant2.0-the-rewrite is essentially dead (and essentially obsolete
through evolution in the codebase), but I still think we ought to
consider using the name as and when the time is appropriate. If we add
enough interesting stuff to 1.7, it could be the time.
Please,
Costin Manolache wrote:
Steve Loughran wrote:
I know Ant2.0-the-rewrite is essentially dead (and essentially
obsolete through evolution in the codebase), but I still think we
ought to consider using the name as and when the time is appropriate.
If we add enough interesting stuff to 1.7, it
On Sun, 08 Feb 2004, Steve Loughran [EMAIL PROTECTED] wrote:
One thing that was voted on (positively, I recall), way way back in
time, was for Ant2.0 to fail on undefined properties.
Although I've never looked into it, can't you already have it with a
custom PropertyHelper? If you can ensure
Steve Loughran wrote:
I suppose the problem was that undefined properties were just ignored,
and you had a hard time debugging this ( I had similar problems many
times ).
you can get those messages if you crank up the verbosity, but you still
need to go through the lines and look at them. I
I know Ant2.0-the-rewrite is essentially dead (and essentially obsolete
through evolution in the codebase), but I still think we ought to
consider using the name as and when the time is appropriate. If we add
enough interesting stuff to 1.7, it could be the time.
One thing that was voted on
47 matches
Mail list logo
