Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

2012-02-13 Thread Jeffrey E Care 
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 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 be a way to sweep away the kind of cruft that is holding up the 

> release and to redesign Ant to reflect all the lessons learned about how 

> to build software in the last 10 years. Or it could be I'm the only one 
> who read through the NIO 2.0 features and instantly thought about 
> rewriting Ant.

I think you have to enumerate what you want to accomplish with a complete 
rewrite and what the compelling reasons are for such an undertaking. 

I agree that there are many compelling features in NIO 2 that I would like 
to see leveraged in Ant but I have to say that I'm not seeing a straight 
line from NIO 2 to a complete rewrite of Ant. For a less drastic approach 
maybe we could re-write only those tasks that would benefit the most from 
NIO 2's features. Put them in a different package and perhaps even put 
them in their own antlib.

Putting task implementations to the side, what is there in the core of Ant 
that would benefit from NIO 2 or other parts of JDK 7?

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

2012-02-13 Thread Jesse Glick 

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 be as easy as creating a new FileUtils subclass, and for now compiling it conditionally. Whenever we drop JDK 5 and 6 support and require JDK 7 
(which BTW is soon to be available for all major platforms when the Mac version is released), it will be simple to make that be the standard impl.



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

2012-02-13 Thread Mansour Al Akeel 
interesting info. It looks like the idea of the redesign has been discussed
a lot in the past.
Another good point, is to have ant independent of any external libraries.
However, I am wondering if this applies to run time environment ?
For example, writing a core ant (mainly build.xml parser), as an osgi
bundle. And collection of bundles for Javac, Java, Copy,... etc. would:

1- be independent of any external libraries and relies on JRE to build.
2- allow integration with IDEs.
3- allow to compile and build the build system, without a build system (ie,
using bootstrap). or like you said "self-building".

Would this be acceptable idea ? A core bundle, and extra bundles for basic
tasks. A bundle for ivy (maybe). We can even have a bundle to install
additional bundles remotely
And with Java7 NIO the performance will be fine.

comments ?


On Mon, Feb 13, 2012 at 4:04 PM, Bruce Atherton  wrote:

> This brings up a point to consider if a rewrite is desired. Ant has always
> avoided relying on external libraries because it is usually the first thing
> in the build chain. It can't have any dependencies itself if it is to be
> self-building. There are tasks that require external libraries to be
> compiled, yes, but they are all optional. That is why there is a bootstrap
> build before the full build. The only libraries you can rely on being there
> are the ones that ship with the JRE.
>
> This could change in Ant 2 if people wanted but I think we'd need a
> strategy for it.  For example, there was a lot of talk at one point about
> moving the package name from org.apache.tools.ant.* to org.apache.ant.*.
> Doing this would allow both Ant 1.x and Ant 2 to exist in the same program
> (like IDEs), and it would allow a bootstrap Ant 1.x to build Ant 2. Doing
> that would allow the use of libraries.
>
> I'm sure there could be other solutions as well, but I don't think anyone
> should automatically assume that non-optional libraries will be available
> until it is decided that that will 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 
>> > 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 forking Ant and
>> > rewrite parts of it to use Java 7 NIO, and introduce java plugin frame
>> > work 
>> > http://jpf.sourceforge.net/**crossedmy 
>> > mind few times.
>>
>>
>> Why JPF instead of OSGi or whatever extensibility mechanism is working
>> it's way through the JCP for Java 8? IMO the idea of basing an Ant re-write
>> on some dubiously supported clone of Eclipse's plugin mechanism from 8
>> years ago isn't very appealing.
>> __**__**
>> __**__
>> Jeffrey E. (Jeff) Care
>> _ca...@us.ibm.com_ 
>>
>> IBM WebSphere Application Server
>> WAS Release Engineering
>>
>>
>> WebSphere Mosiac
>> WebSphere Brandmark
>>
>>
>>

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

2012-02-13 Thread Bruce Atherton 
This brings up a point to consider if a rewrite is desired. Ant has 
always avoided relying on external libraries because it is usually the 
first thing in the build chain. It can't have any dependencies itself if 
it is to be self-building. There are tasks that require external 
libraries to be compiled, yes, but they are all optional. That is why 
there is a bootstrap build before the full build. The only libraries you 
can rely on being there are the ones that ship with the JRE.


This could change in Ant 2 if people wanted but I think we'd need a 
strategy for it.  For example, there was a lot of talk at one point 
about moving the package name from org.apache.tools.ant.* to 
org.apache.ant.*. Doing this would allow both Ant 1.x and Ant 2 to exist 
in the same program (like IDEs), and it would allow a bootstrap Ant 1.x 
to build Ant 2. Doing that would allow the use of libraries.


I'm sure there could be other solutions as well, but I don't think 
anyone should automatically assume that non-optional libraries will be 
available until it is decided that that will 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 
> 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 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.

Why JPF instead of OSGi or whatever extensibility mechanism is working 
it's way through the JCP for Java 8? IMO the idea of basing an Ant 
re-write on some dubiously supported clone of Eclipse's plugin 
mechanism from 8 years ago isn't very appealing.
 


Jeffrey E. (Jeff) Care  
_ca...@us.ibm.com_ 
IBM WebSphere Application Server
WAS Release Engineering


WebSphere Mosiac
WebSphere Brandmark

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

2012-02-13 Thread Mansour Al Akeel 
good point Jeff.
I just though about the performance. I am not sure what would be the
performance for JPF compared to OSGI. But your are very correct. That's why
we discuss this on the mailing list. In all cases, these are just thoughts,
and I don't know if there's enough interest 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
> > 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.
>
> Why JPF instead of OSGi or whatever extensibility mechanism is working
> it's way through the JCP for Java 8? IMO the idea of basing an Ant re-write
> on some dubiously supported clone of Eclipse's plugin mechanism from 8
> years ago isn't very appealing.
>   
> 
>  Jeffrey E. (Jeff) Care
> *ca...@us.ibm.com* 
>  IBM WebSphere Application Server
> WAS Release Engineering
>
>  [image: WebSphere Mosiac]
> [image: WebSphere Brandmark]
>
>

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

2012-02-13 Thread Jeffrey E Care 
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. 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.

Why JPF instead of OSGi or whatever extensibility mechanism is working 
it's way through the JCP for Java 8? IMO the idea of basing an Ant 
re-write on some dubiously supported clone of Eclipse's plugin mechanism 
from 8 years ago isn't very appealing.


 

Jeffrey E. (Jeff) Care 
ca...@us.ibm.com 
IBM WebSphere Application Server 
WAS Release Engineering

Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support

2012-02-13 Thread Mansour Al Akeel 
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 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)
> 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 much for the foreseeable future, I've seen
> communities be revitalized by creating a new codebase. It attracts new
> committers who have been annoyed by the previous bug/feature combinations
> and get excited about the possibilities of helping to create a new
> codebase. Cocoon did it twice, although I wouldn't recommend that because
> the people attracted by Cocoon 2.2 went away because they felt their
> efforts were wasted thanks to Cocoon 3.0.
>
> It could be a way to sweep away the kind of cruft that is holding up the
> release and to redesign Ant to reflect all the lessons learned about how to
> build software in the last 10 years. Or it could be I'm the only one who
> read through the NIO 2.0 features and instantly thought about rewriting Ant.
>
> What do you guys think about it?
>
> On 2/5/2012 11:25 PM, Stefan Bodewig wrote:
>
>> 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  etc.
>>>
>> You must not forget that parts of Ant have been written at a time where
>> Java2 was too new to require it as runtime environment.
>>
>>  However, now with java 7, we have the Path class that is very convenient
>>> to
>>> use. I think having this will make writing tasks easier, by cuting down
>>> the
>>> steps to convert between ants Path and java.nio.file.Path.
>>> Are there any interests ?
>>>
>> Yes, there is.
>>
>> Just now we have voted to accept Java5 (yes, 5, not 7) as our minimum
>> requirement for Ant's trunk following the upcoming 1.8.3 release.  This
>> means we can not use Java7 features directly.
>>
>> One approach that may be possible is to write a FileUtils replacement
>> using Java7 features.  Almost all file system interactions of Ant go
>> through FileUtils and Ant's core could detect at runtime whether Java7
>> is around and use the matching FileUtils class.
>>
>> Stefan
>>
>> --**--**-
>> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
>> For additional commands, e-mail: dev-h...@ant.apache.org
>>
>>
> --**--**-
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

NIO 2.0 == Ant 2.0? was Re: Java NIO support

2012-02-13 Thread Bruce Atherton 
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) 
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 much for the foreseeable future, I've 
seen communities be revitalized by creating a new codebase. It attracts 
new committers who have been annoyed by the previous bug/feature 
combinations and get excited about the possibilities of helping to 
create a new codebase. Cocoon did it twice, although I wouldn't 
recommend that because the people attracted by Cocoon 2.2 went away 
because they felt their efforts were wasted thanks to Cocoon 3.0.


It could be a way to sweep away the kind of cruft that is holding up the 
release and to redesign Ant to reflect all the lessons learned about how 
to build software in the last 10 years. Or it could be I'm the only one 
who read through the NIO 2.0 features and instantly thought about 
rewriting Ant.


What do you guys think about it?

On 2/5/2012 11:25 PM, Stefan Bodewig wrote:

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  etc.

You must not forget that parts of Ant have been written at a time where
Java2 was too new to require it as runtime environment.


However, now with java 7, we have the Path class that is very convenient to
use. I think having this will make writing tasks easier, by cuting down the
steps to convert between ants Path and java.nio.file.Path.
Are there any interests ?

Yes, there is.

Just now we have voted to accept Java5 (yes, 5, not 7) as our minimum
requirement for Ant's trunk following the upcoming 1.8.3 release.  This
means we can not use Java7 features directly.

One approach that may be possible is to write a FileUtils replacement
using Java7 features.  Almost all file system interactions of Ant go
through FileUtils and Ant's core could detect at runtime whether Java7
is around and use the matching FileUtils class.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
For additional commands, e-mail: dev-h...@ant.apache.org