Re: Archetype for Ant
Jeffry, it could be. However, I am not going to switch to a different build system just to be able to create archetypes. Can you convince your boss to get the team to learn how to use new build system, and swap the current one, just to be able to create a project easily ? On Sun, Apr 22, 2012 at 6:43 PM, Jeffrey E Care wrote: > Isn't this what EasyAnt is for? > > > Jeffrey E. (Jeff) Care > *ca...@us.ibm.com* > IBM WebSphere Application Server > WAS Release Engineering > > [image: WebSphere Mosiac] > [image: WebSphere Brandmark] > > > > Mansour Al Akeel wrote on 04/22/2012 03:38:55 > PM: > > > From: Mansour Al Akeel > > To: Ant Developers List > > Date: 04/22/2012 03:40 PM > > Subject: Archetype for Ant > > > > Hello all, > > Currently, when starting a project we copy/paste from previous ant > > build files, and change as we go. Other build system offer a skeleton > > to start a project of > > some nature quickly. > > I decided to create a prototype project for ant archetype, to evaluate > > the idea and see if there is potential for it to be useful for the > > community. This project is hosted on > > google code. > > > > The project can be found here http://code.google.com/p/ant-archetype/ > > And to get started, > > http://code.google.com/p/ant-archetype/wiki/GettingStarted_Webapp > > > > > If you have any comments or feedback, please let me know. > > > > The first archetype is for web application. It can be implemented in a > > better way. I am just testing the idea. > > > > This works on Java7 and Ant 1.8.2. > > > > Thank you. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > For additional commands, e-mail: dev-h...@ant.apache.org > > >
Archetype for Ant
Hello all, Currently, when starting a project we copy/paste from previous ant build files, and change as we go. Other build system offer a skeleton to start a project of some nature quickly. I decided to create a prototype project for ant archetype, to evaluate the idea and see if there is potential for it to be useful for the community. This project is hosted on google code. The project can be found here http://code.google.com/p/ant-archetype/ And to get started, http://code.google.com/p/ant-archetype/wiki/GettingStarted_Webapp If you have any comments or feedback, please let me know. The first archetype is for web application. It can be implemented in a better way. I am just testing the idea. This works on Java7 and Ant 1.8.2. Thank you. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Tasks to be contributed
Jeffery, yes. It sits there and block until the user exists the process (CTRL-C). Running it in the background is possible, but it will require additional coding to shut it down. On Fri, Mar 9, 2012 at 4:27 PM, Jeffrey E Care wrote: > So this is some long running process? It sits there & blocks until a > change is dropped? > > I think we need more details. > > > Jeffrey E. (Jeff) Care > *ca...@us.ibm.com* > IBM WebSphere Application Server > WAS Release Engineering > > [image: WebSphere Mosiac] > [image: WebSphere Brandmark] > > > > Mansour Al Akeel wrote on 03/09/2012 04:15:40 > PM: > > > From: Mansour Al Akeel > > To: Ant Developers List > > Date: 03/09/2012 04:17 PM > > Subject: Re: Tasks to be contributed > > > > Thank you Stephan for your time. > > Ok, so let's ask here. I wrote a task that monitors a directory for > > file changes and when changes > > occur it triggers another task. This task helps me a lot in > > recompiling the modified code and copy resource files > > to the destination in case of a webapp. > > I think others may find it useful, especially those who doesn't use an > > IDE all the time. > > I wrote this task for my usage, and it uses java 1.7 NIO. Before I > > contribute something like this, I will need to rewrite it to > > use the currently supported java versions. > > > > the task is very simple: > > > > > > Which works great for me. > > I may have to rewrite to use resource and to make it consistent with > > the rest of the task. > > > > So my question, do other users think this can be useful for the > community ? > > > > > > > > > > On Fri, Mar 9, 2012 at 12:57 PM, Stefan Bodewig > wrote: > > > On 2012-03-09, Mansour Al Akeel wrote: > > > > > >> How do the community decide what tasks to be added to the distribution > > >> and what to be distributed some where else. > > > > > > The people who write the tasks and want to see them included with Ant > > > ask on the dev list (or attach them to Ant's bugzilla) and if a > > > committer feels like committing the task it will be done. If the task > > > may be controversial in scope, this likely won't happen without > > > discussion. > > > > > >> For example, some tasks from ant-contribution are widely used. > > > > > > Most if not all of these have not been written with the intention to > > > include them in Ant. The people behind the ant-contrib project are a > > > separate bunch of people from the Ant dev team even if some have been > on > > > both teams at one point in time. > > > > > >> How do I know if a task can be contributed and added to the core ? > > > > > > Ask for the concrete task 8-) > > > > > > 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 > > >
Re: Tasks to be contributed
Thank you Stephan for your time. Ok, so let's ask here. I wrote a task that monitors a directory for file changes and when changes occur it triggers another task. This task helps me a lot in recompiling the modified code and copy resource files to the destination in case of a webapp. I think others may find it useful, especially those who doesn't use an IDE all the time. I wrote this task for my usage, and it uses java 1.7 NIO. Before I contribute something like this, I will need to rewrite it to use the currently supported java versions. the task is very simple: Which works great for me. I may have to rewrite to use resource and to make it consistent with the rest of the task. So my question, do other users think this can be useful for the community ? On Fri, Mar 9, 2012 at 12:57 PM, Stefan Bodewig wrote: > On 2012-03-09, Mansour Al Akeel wrote: > >> How do the community decide what tasks to be added to the distribution >> and what to be distributed some where else. > > The people who write the tasks and want to see them included with Ant > ask on the dev list (or attach them to Ant's bugzilla) and if a > committer feels like committing the task it will be done. If the task > may be controversial in scope, this likely won't happen without > discussion. > >> For example, some tasks from ant-contribution are widely used. > > Most if not all of these have not been written with the intention to > include them in Ant. The people behind the ant-contrib project are a > separate bunch of people from the Ant dev team even if some have been on > both teams at one point in time. > >> How do I know if a task can be contributed and added to the core ? > > Ask for the concrete task 8-) > > 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
Re: import remote file
Jeffery, thank you for taking the time to explain the potential source of error. I am considering putting some macros on github. So a lot of the issues will be avoided. And by properly labeling each revision (changes), I should be ok with backward compatibility. Thank you for the advice, Jeffery. On Thu, Mar 8, 2012 at 9:20 PM, Jeffrey E Care wrote: > Don't misunderstand: I think a shared, common process is a good thing & > should be encouraged. My problem is more about how that sharing is > implemented by people who only "play" at being release engineers. > > Example: > > 1) Do you care about being able to recreate your builds a week from now? A > month? A year? Five years? Ten years? (Yes, we still service product > releases that have been in the field for 10+ years.) > 2) Who owns the infrastructure where that remote, shared resource lives? > 2a) Do you know who has write access to it? > 2b) What policies are in place for auditing access & modification? > 2c) What happens to your build when the URL changes? > 2d) What disaster recovery & business continuity policies are in place > in case the server hosting the remote resource gives up the ghost? > 3) Are changes make in a backwards compatible fashion? > > This is just off the top of my head. > > Now, for some projects none of this is a concern. For other projects these > are inviolable constraints that are necessarily at the forefront of > everything we do. > > Are there ways to mitigate these concerns with using a remote resource in > a build? Absolutely: you can clamp down on write access, use versioning, > have SLAs and backups, etc. The take-away message is that there's a lot > more complexity involved to properly support a remote resource than just > chunking it up on a some random web server. > > > Jeffrey E. (Jeff) Care > *ca...@us.ibm.com* > IBM WebSphere Application Server > WAS Release Engineering > > [image: WebSphere Mosiac] > [image: WebSphere Brandmark] > > > > Mansour Al Akeel wrote on 03/08/2012 05:42:56 > PM: > > > From: Mansour Al Akeel > > To: Ant Developers List > > Date: 03/08/2012 05:43 PM > > Subject: Re: import remote file > > > > Jeffery, > > thank you. I will try it soon. > > Can you please let me know what makes you think it's terrible idea ? > > > > > > On Thu, Mar 8, 2012 at 3:01 PM, Jeffrey E Care wrote: > > > Mansour Al Akeel wrote on 03/08/2012 > 02:53:55 > > > PM: > > > > > >> I am looking for a functionality to allow me to import remote files > > >> that contains tasks to be used in multiple projects. Something like: > > >> > > >> http://path/to/reusable/file.xml > " /> > > > >> > > >> I know I can include this in an antlib inside a jar, ant download it > > >> through ivy, but importing a remote file, seems to be easier way to > > >> share this macros with other > > >> projects. > > >> > > >> I didn't find this functionality, and looking to open a jira ticket. > > >> Just making sure it doesn't exist. > > > > > > You should be able to do this today using a nested url resource. > > > > > > Of course I'm on record as thinking this is a TERRIBLE idea, so use at > > > your own risk. > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org > > For additional commands, e-mail: dev-h...@ant.apache.org > > >
Re: import remote file
Jeffery, thank you. I will try it soon. Can you please let me know what makes you think it's terrible idea ? On Thu, Mar 8, 2012 at 3:01 PM, Jeffrey E Care wrote: > Mansour Al Akeel wrote on 03/08/2012 02:53:55 > PM: > >> I am looking for a functionality to allow me to import remote files >> that contains tasks to be used in multiple projects. Something like: >> >> http://path/to/reusable/file.xml"; /> >> >> I know I can include this in an antlib inside a jar, ant download it >> through ivy, but importing a remote file, seems to be easier way to >> share this macros with other >> projects. >> >> I didn't find this functionality, and looking to open a jira ticket. >> Just making sure it doesn't exist. > > You should be able to do this today using a nested url resource. > > Of course I'm on record as thinking this is a TERRIBLE idea, so use at > your own risk. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
import remote file
Hello all, I am looking for a functionality to allow me to import remote files that contains tasks to be used in multiple projects. Something like: http://path/to/reusable/file.xml"; /> I know I can include this in an antlib inside a jar, ant download it through ivy, but importing a remote file, seems to be easier way to share this macros with other projects. I didn't find this functionality, and looking to open a jira ticket. Just making sure it doesn't exist. - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Reasons why Java 7 got me excited about Ant 2
Java is widely used and accepted. Scala is functional and it could be more suitable for a build system, however, I don't see enough reasons for the core to be written with scala or any other language. I think it's better to keep it in java, and allow the addition of plugins written in other languages the works with JVM (scala, groovy, ... etc). This will allow contribution from users experts in java. 2012/2/26 wolfgang häfelinger > Hi there, > > how about rewriting Ant 2.0 using Scala? Scala appears to be well > suited as a scripting language. Charged with a scripting language, I > could write low level macros on the fly. > > > // Wolfgang > > > On Fri, Feb 17, 2012 at 2:31 AM, Bruce Atherton > wrote: > > I thought I'd expand on why I got so excited about NIO 2.0 and JSR 203 as > > well as the other changes in Java 7. I can see I have done a bad job of > > selling the benefits of a refactoring for potential volunteers. Reading > > through the changes that were introduced in Java 7, it seems to me that > Ant > > was probably an inspiration for a lot of them. > > > > Others come from taking the performance of I/O on Java more seriously. > This > > has the potential to speed Ant up enormously. Projects like Tim Bray's > Wide > > Finder 2[1] showcased just how badly Java performed and benchmarks like > that > > may have been an impetus to focus resources on taking advantage of all > the > > features of the native filesystems. Unfortunately the results of the > project > > are lost due to Oracle's acquisition of Sun, but you can still see the > > results from the original Wide Finder 1[2] although there isn't even an > > attempt to do a Java implementation there. I can tell you from memory > that > > the final results on WF2 were several C implementations with innovative > I/O > > using parallel processing at the top, erlang and ruby and scala were up > > there, but the fastest Java implementation was in the double digits in > the > > list as I recall. > > > > The basics for file handling in Java 7 are provided by Path and the Paths > > Utility class, along with the FileSystemProvider classes. If Ant 2 were > > created to make Resource a fundamental element and Path the Resource that > > represented something on a file system (native file systems, zip/jar file > > systems, and I expect eventually open source projects will add others > like > > HTTP, FTP, NFS and Samba), I think the LOC count on Ant could be reduced > > tremendously. Writing patches would be simplified and contributing to Ant > > would have a lower barrier to entry for new people coming in. Path is > > immutable which suits Ant well. Path has methods to access elements in a > > file path, compare, test, normalize, and relativize paths in the ways > that > > Ant has code to do. It has all kinds of features for determining > > accessibility on the native filesystem and bulk loading file metadata > > attributes whereas currently it is done one field at a time. Symbolic > link > > identification and handling is a core feature. And converting to and from > > File objects is trivial. > > > > Add to that the new methods on File. There is also a Files utility helper > > class. Files covers the most basic tasks in Ant implemented using all the > > features of the native filesystem to make them as fast as possible: > copying; > > deleting; moving; reading file contents; writing; creating directories, > file > > and links; getting input and output streams. There is also recursion > with a > > method for walking a file tree that creates a FileVisitor interface > > implementation, either default or custom, with 3 phases: previsit > directory, > > visit file, and postvisit directory. It also provides for a visit file > > failed method. At each point you can continue, stop, skip subtree, or > skip > > other entries in the current directory. Options control whether symlinks > are > > followed, and cycles are detected. > > > > DirectoryStream includes filters like glob, regex, and custom > > implementations that could be perfect for implementing Selectors. > > DirectoryStream uses less resources and works much better with remote > > resources. It also handles directories that are very large much more > > efficiently. > > > > Error handling throughout is by exception rather than boolean value as > it is > > now, which I'm sure we all agree is preferable. > > > > Then there is the Watch Service which uses the native eventing service if > > available, where you can get events in your build when a file is created > or > > deleted, or when a directory is modified. Would we translate it into > > something for BuildListeners? How would we harness it, scheduling a > target > > and its dependencies when the a watch fired an event? > > > > I could keep going but this is getting rather long. I'll just point out > a > > few resources from other people that are clearer than I am and have more > > detail: The Java 7 feature list[3] is comprehensive but has little on th
Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
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 late > binding (Unknown Element) and modification through things like macros done > in later phases > 4. Dependency Analyzer > - Generates the queue of ProjectComponents to execute incrementally based > on if/unless and dependencies > 5. Execution Engine > - May call back into 2, 3, or 4 > 6. Monitoring System > - logs, BuildEvents, etc) > > Note that this is just conceptual and not reflecting how things are actually > implemented in Ant 1. > > As I understand Gilles suggestion, he'd like to see something more like > this: > > 1. Command Line Processor > 2. Build File Parser > 3. Translation into State Machine > 4. Execution of State Machine > - This can modify itself as it processes. This would include resolving > UnknownElement, deleting transitions based on if/unless, allowing the > altering and additions of transitions to control new dependencies, inserting > macro subtrees, parsing and adding new build files, etc, etc. How easy is't to unit test additional plugins. When you rely a lot on context, you need to create a similar context for testing. Is't going to be easy ? Writing and testing tasks independently will allow a lot of plugins to exist. > 5. Monitoring System (logs, BuildEvents, etc) > > This design looks a lot simpler to me than the first one. As I think about > it more I'm starting to like it. > > As for automating parallelism, if you know what resources are needed and in > which state, and you know which ProjectComponents will get the resources > into that state for you, then it is possible for an application to determine > which ones can run in parallel rather than sequentially. Obviously there is > a lot of handwaving in there. > > > On 2/18/2012 1:13 PM, Mansour Al Akeel wrote: >> >> 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's sub modules declared then do the same, and populate them >> all the current context, adding name space to the references for the >> tasks in the sub modules. For example assuming the current project has >> a task called "build", then the one for the sub module will be >> "submodule1:build". (assuming you want multi module support built-in >> and not added by an OSGI bundle). >> >> 3- If you want parent project support then we can do the same. >> >> 4- Depeding on the task called, execute the corresponding task and >> pass it an object of the Data Structure you want to process. The >> reason for this is to make it easy to unit test it. >> >> 5- additional tasks and dataType can be added through OSGI bundles. >> For example, let's say I want a task to compile a war file, I can just >> extend the dataStructure (TypeDef, or any other name), with default >> values. Write my task, and test the execute method by passing it a >> reference to my WarDataStructure. Initializing a task requires only >> the path to the current directory. So instead of passing an object of >> type (Project), I will just it a path, and it knows the path it should >> execute in. (This is for multi module). >> >> 6- A generic data structure can be used (ie, hashmap) and passed to >> execute method. This has a copy of all the data initialized in the >> build file. >> >> >> 7- I am not sure what you mean by parallelism, but I am assuming >> running more that one task at the same time. This can be added through >> bundles, but then again, we will run into the same issue like Gradle. >> If you want a task to run continuously on even (ie, a file change), >> then you have to write a different task to do so, as parallelism >> requires a flag to tell if a task has been executed or not. I think >> the way ant doing it already is the best (ie. using). >> >> Trying to keep the core as simple as possible, will make maintenance >> easy, and prevent bugs. Once a bundle proven useful and required >> always by the users, then it can be merged with the core. >> > - To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org For additional commands, e-mail: dev-h...@ant.apache.org
Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
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's sub modules declared then do the same, and populate them all the current context, adding name space to the references for the tasks in the sub modules. For example assuming the current project has a task called "build", then the one for the sub module will be "submodule1:build". (assuming you want multi module support built-in and not added by an OSGI bundle). 3- If you want parent project support then we can do the same. 4- Depeding on the task called, execute the corresponding task and pass it an object of the Data Structure you want to process. The reason for this is to make it easy to unit test it. 5- additional tasks and dataType can be added through OSGI bundles. For example, let's say I want a task to compile a war file, I can just extend the dataStructure (TypeDef, or any other name), with default values. Write my task, and test the execute method by passing it a reference to my WarDataStructure. Initializing a task requires only the path to the current directory. So instead of passing an object of type (Project), I will just it a path, and it knows the path it should execute in. (This is for multi module). 6- A generic data structure can be used (ie, hashmap) and passed to execute method. This has a copy of all the data initialized in the build file. 7- I am not sure what you mean by parallelism, but I am assuming running more that one task at the same time. This can be added through bundles, but then again, we will run into the same issue like Gradle. If you want a task to run continuously on even (ie, a file change), then you have to write a different task to do so, as parallelism requires a flag to tell if a task has been executed or not. I think the way ant doing it already is the best (ie. using ). Trying to keep the core as simple as possible, will make maintenance easy, and prevent bugs. Once a bundle proven useful and required always by the users, then it can be merged with the core. On Sat, Feb 18, 2012 at 2:48 PM, Bruce Atherton wrote: > 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 require Ant 2 features > with something that identifies them as requiring Ant 2. I think this is > reasonable for the leap from Ant 1 to Ant 2, but one thing HTML has shown is > that version numbers are an anti-pattern, which is why the DOCTYPE for HTML5 > has done away with them (although that introduced its own "version" ie. no > version). What is important is the list of features that are needed to > interpret and run the file correctly. > > One can imagine a version tag listing Ant 2 as a minimum for a build file > with an attribute for a comma separated list of the features that are > required from Ant for the build. With this and the kind of packaging system > that OSGI and possibly Java 8 will introduce, Ant could dynamically > configure itself to load the parallelizing implementation of the state > machine or the distributed implementation. > > So long as the design is flexible enough that the kinds of usecases that > Dominique and Gilles are suggesting can be implemented eventually, then the > KISS principle can still be followed. > > I would also note that features like DSLs for custom builds, automatic > parallelism, and distribution to a fault tolerant cluster are exactly the > kinds of features that would allow many users that I know of to justify > allocating resources to rewrite major build scripts. > > > On 2/18/2012 11:26 AM, Mansour Al Akeel wrote: >> >> 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 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 or using a >>> different kind of target tag. Of course,
Re: Ant 2 design (was Re: NIO 2.0 == Ant 2.0?)
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 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 or using a > different kind of target tag. Of course, the additional information you > suggest on targets would make that the case anyway, but in some cases I > think we might be able to automate it based just on what we have if the > build system is written properly so that dependencies on targets that > provide needed resources are explicitly identified. > > Too many build systems in my experience rely on the order the dependencies > are resolved on a higher order target rather than explicitly identifying > dependencies on the targets that they are required on. This despite the fact > that we have some language somewhere that you can't rely on the order of > resolution of the dependencies. Sometimes that has proved a requirement to > avoid targets that depended on each other, but I've seen it used as a > shortcut instead far too often. > > Creating Ant clusters is also a great idea, at least to plan for. Perhaps > something like Zookeeper to coordinate builds and a message bus like > ActiveMQ or perhaps better QPid to schedule and report back to other nodes > on the results. > > The idea of turning the dependency tree into a state machine is also > interesting. It would combine the tree and the resolving of the tree with > execution of tasks into a single entity. I worry, though, that some > flexibility in our current system might be lost if the two portions are > combined into one. Perhaps not. It could also introduce the possibility of > cycles. Currently the dependency tree gets executed as a DAG but there have > been a lot of requests for looping which a state machine could more easily > support. > > On 2/18/2012 2: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). >> I see the 'targets' being more declarative, becoming a state >> transition saying : I need this resources in that state, I will use >> this other resources (and I don't want the to change during my >> execution, and I will produce this other resources in that other >> state. >> >> The dependency tree would be an logical engine finding the shortest >> path to go to the desired state, using parallel/distributed processing >> when possible. >> >> That's what I miss with existing build system : I want to go as >> quickly as possible to a desired build state (from a current state). >> >> >> >> Gilles Scokart >> >> >> >> On 17 February 2012 20:07, Bruce Atherton wrote: >>> >>> 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 type of >>> users I am talking about. >>> >>> It sounds like you are suggesting that the dependency tree be extensible >>> and >>> modifiable, perhaps manipulable, within targets as well so long as that >>> part >>> of the tree hasn't run yet. In a sense that is what macros do because >>> they >>> allow you to swap in some static block of tasks to replace a single task. >>> There is also the feature from EasyAnt for changing target dependencies. >>> But >>> what I'm hearing is that you want more flexibility than that. >>> >>> Something to walk the existing dependency tree, perhaps, with conditional >>> behaviors to modify the metadata on existing element such as dependencies >>> and if/unless, replacing the element with another or a subtree (perhaps >>> itself dynamically walked and created), adding branches, perhaps deleting >>> elements or subtrees. Kind of like what we can do with a tree of files >>> and >>> directories already. Does that sound like what the design you'd like to >>> see >>> would have? >>> >>> And perhaps it could encompass providing both the macro and target >>> dependency changes to the tree as well, along with any other code we have >>> that alters the dependency tree. I'm not sure which of the various ways >>> to >>> call back into Ant do this. I'm sure there are other examples in the >>> codebase. >>> >>> I'm not familiar enough with this part of the code any more to know >>> whether >>> there is already a single elegant solution in Ant 1 that all the code >>> which >>> modifies the dependency tree
Re: NIO 2.0 == Ant 2.0? was Re: Java NIO support
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 have to make a build of a Java webapp, I don't write my > build.xml from scratch each time. I look up for an old project I used to > work on, I copy its build and keep the interesting parts, I rehack the > build scripts. So with some convention and for very similar projects, we > could share theses scripts. Easyant does "just" this with Ivy. > I used gradle and don't see the reason for it except for the multi module support. And yes, it's slow. For a continuous build like (on file change, compile, build, and let jrebel reload), It's to slow for me. I understand that easyant makes reusable build available, but I think the multi project support (in gradle), the groovy feature (in gradle), and the reusable tasks (in easyant), can all be done with antlib. Why did their teams created a new build system, rather than antlib ? This is my question. > > > 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 bundles of different plugins. Is this because it's > > OSGI ? > > I like this idea of using of modular framework to handle properly > modularity. > But what I wouldn't like is having a longer bootstrapping of Ant. For > instance gradle is boring long to launch, even for printing the inline > help. The groovy frontend of Ant suffers for the same issues, unusable for > me. I don't have much experience with OSGi systems, I don't know how fast > some > > 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. > > And this is why I suggested java plugin framework in a previous email (assuming it is faster than OSGI). I read that there are some fast OSGI implementations. Didn't try anything yet. > Nicolas > > > - > 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
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 new build system, if things like this can be done with antlib. And why would users switch to these systems. I like writing my custom tasks and wrap them in an antlib. But why others are not doing the same to add multi project support, or set some conventions ? 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 bundles of different plugins. Is this because it's OSGI ? This is really another reason that makes me think about forking ant beside introducing NIO2. I agree with Jesse, there's inconsistency dealing with different Resource. With regard to backward compatibility, It is good idea to keep it as "Nice to have", and try to maintain it as much as possible. The one thing I am confident it's critical, is the simplicity. For example, I came back to ant because I wanted to write a task that will be triggered when a file changes. I was not able to do this with gradle: http://forums.gradle.org/gradle/topics/runnig_task_programmatically probably it's a bit 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 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. >> > > Required, no. If there is not enough interest in creating an Ant 2 then > everything will be fine staying with Ant 1.x. We've been doing it through > massive changes in the Java libraries and we can keep doing it the same > way. If there aren't enough people interested in doing the work then we > should just drop it. > > But I've talked about a few of the advantages I see in dropping backward > API compatibility and doing a major refactoring. Let me list a few more. > > My biggest problem with Ant is the many ways that files are dealt with. It > is all over the map. This isn't anyone's fault, it happened because of > hysterical porpoises, but both our users and ourselves have to deal with > the fallout. > > Users have to deal with understanding the differences between paths and > filelists and filesets and dirsets and resources. They have to come to > grips with how and don't work like selectors. Filters > aren't much better since there are different ways that they can work. > > We have it a bit easier because under the covers most things have been > normalized. Resources, for example. But thanks to API compatibility that > brings its own problems. For example, we have two completely separate yet > very similar set of classes for Selectors, one for FileSelectors and one > for ResourceSelectors. Fix a bug in one, did you remember to fix it in the > other? Does it matter if users of the FileSelector APIs still have the bug? > > Or look at the utility classes. How many methods, or lines of extra code > in methods that should be relatively simple, are devoted to dealing with > edge cases and these hangers on from our past? > > All of these things were an itch bad enough that I started to scratch it, > but for now I won't be doing any coding at all for a while. Maybe, though, > there are others who are as bothered by these things as I am who are > looking for a scratching post. > > > > --**--**- > 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
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/**crossed<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_ <mailto: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
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
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 > >
Java NIO support
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 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 ?
