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
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
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
On 2/16/2012 2:36 PM, Nicolas Lalevée wrote:
Le 16 févr. 2012 à 20:47, Bruce Atherton a écrit :
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 mi
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.
Le 16 févr. 2012 à 21:08, Bruce Atherton a écrit :
> It has but not for quite a long time. Look in the archives from 2001 to 2003
> for "Mutant"[1] which Conor proposed, and "Myrmidon"[2] which Peter Donald
> proposed back in 2000. You can still find them in the svn repository[3], [4].
>
> I
Le 16 févr. 2012 à 20:47, Bruce Atherton a écrit :
> 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
It has but not for quite a long time. Look in the archives from 2001 to
2003 for "Mutant"[1] which Conor proposed, and "Myrmidon"[2] which
Peter Donald proposed back in 2000. You can still find them in the svn
repository[3], [4].
I think there was so much discussion on a new design of Ant tha
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
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
didn't use it). I am wondering what makes the author go with a
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
advanta
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
On Tue, Feb 14, 2012 at 8:13 AM, Stefan Bodewig wrote:
> On 2012-02-13, Bruce Atherton wrote:
>
>> 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 b
On 2012-02-13, Bruce Atherton wrote:
> 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
Bruce Atherton wrote on 02/13/2012 01:25:30 PM:
> I actually wanted to discuss Java 7 on the list. I went through its
> features a while ago and got really excited when I read through NIO 2.0.
> It does so much that Ant has to struggle with, and so much that Ant
> can't do.
>
> I spent some
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 b
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.
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.
On Mon, Feb 13, 2012 at 1:25 PM, Bruce Atherton wrote:
> I actually wanted to disc
I actually wanted to discuss Java 7 on the list. I went through its
features a while ago and got really excited when I read through NIO 2.0.
It does so much that Ant has to struggle with, and so much that Ant
can't do.
I spent some time starting to implement a very simple (only a few tasks)
n
On 2012-02-05, Mansour Al Akeel wrote:
> I have been looking and developing some custom task for ant, for the last
> few days. I noticed that ant tasks don't use java.io directly. I am
> assuming this is due to the way java.io.File behave on different platforms,
> and the support for patterns
Hello all,
I have been looking and developing some custom task for ant, for the last
few days. I noticed that ant tasks don't use java.io directly. I am
assuming this is due to the way java.io.File behave on different platforms,
and the support for patterns etc.
However, now with java 7, we h
35 matches
Mail list logo
