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.
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 exa
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 aski
On Sat, Feb 18, 2012 at 11:02 AM, Gilles Scokart 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 one as well when I
On Sat, Feb 18, 2012 at 6:03 PM, Bruce Atherton 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 system, but with
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 system, but with
late binding (Unknown Element) and modification through things l
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 there
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
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 wrote:
> This too I find
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 o
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 w
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 typ
2012/2/17 Bruce Atherton :
> 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.
>
> Surely there is
ward
compatibility is so 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
Le 16 févr. 2012 à 20:49, Mansour Al Akeel a écrit :
> 2012/2/16 Nicolas Lalevée
>
>>
>>
>> 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.
ompatibility."
>
> The general agreements that I remember, although 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 t
d on file
> extension or a flag on the command line. That might encourage new projects 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 launc
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 although at this
poin
On Thu, Feb 16, 2012 at 2:49 PM, Mansour Al Akeel wrote:
> >
> > 2012/2/16 Nicolas Lalevée
> >
> > 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 java plugin framework in a previous email
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.
2012/2/16 Nicolas Lalevée
>
>
> 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 scripts.
> Each time I hav
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 o
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
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 opinio
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 point:
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
som
Mansour Al Akeel 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
> mainly they are just
early to start thinking about a rewrite. But just to
check available ideas.
On Tue, Feb 14, 2012 at 2:35 PM, Bruce Atherton wrote:
>
>
> On 2/13/2012 2:55 PM, Jesse Glick wrote:
>
>> On 02/13/2012 01:25 PM, Bruce Atherton wrote:
>>
>>> could Java
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
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 a
a while, 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
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 want to take the burden of redesigning Ant on us t
>
> 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
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
happen. Assuming anything happens.
>
>
> On 2/13/2012 12:02 PM, Jeffrey E Care wrote:
>
>> Mansour Al Akeel wrote on 02/13/2012
>> 01:57:56 PM:
>>
>> > From: Mansour Al Akeel
>> > To: Ant Developers List
>> > Cc: Stefan Bodewig
>> >
l Akeel wrote on 02/13/2012
01:57:56 PM:
> From: Mansour Al Akeel
> To: Ant Developers List
> Cc: Stefan Bodewig
> 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 about the same thing. The idea of
in these ideas.
On Mon, Feb 13, 2012 at 3:02 PM, Jeffrey E Care wrote:
> Mansour Al Akeel wrote on 02/13/2012 01:57:56
> PM:
>
> > From: Mansour Al Akeel
> > To: Ant Developers List
> > Cc: Stefan Bodewig
> > Date: 02/13/2012 01:58 PM
> > Sub
Mansour Al Akeel wrote on 02/13/2012 01:57:56
PM:
> From: Mansour Al Akeel
> To: Ant Developers List
> Cc: Stefan Bodewig
> 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 about the same thing.
> 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
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?
I realize I am violating "Shut up and show me the code". While I
personally w
Dale Anson wrote:
I've also ran into this problem, which prompted the 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
modificat
I've also ran into this problem, which prompted the 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 is use
> > 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
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 sup
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 ens
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 could
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, no
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 (po
48 matches
Mail list logo
