On Sat, Feb 23, 2008 at 11:55 AM, Nicolas Lalevée < [EMAIL PROTECTED]> wrote:
> > Le 1 févr. 08 à 20:31, Xavier Hanin a écrit : > > > Hi, > > > > Some time ago I've launched a discussion about a new Ant+Ivy based > > build > > system, that I called EasyAnt. Based on the discussion we've had so > > far, > > I've developed a small proof of concept, which is available here: > > http://people.apache.org/~xavier/easyant-POC-0.1.zip<http://people.apache.org/%7Exavier/easyant-POC-0.1.zip> > > > > If you have some time, please have a look, there's a README file at > > the root > > of the main directory in the zip, explaining how to try it, and how it > > works. > > > > I'd appreciate to get some feedback on the concepts developed, and > > especially those requiring changes in Ant: mainly use and extends > > mode for > > Import and the phase concept (explained in the README and more > > extensively > > in the todo.txt). > > > > Xavier > > PS: don't pay too much attention to the code itself, it's rather > > ugly and > > undocumented, but it's just a POC :-) > > I like the idea but as an end user I had a very bad user experience is > using maven because it resolve the build before using it. And it seems > to be reproduced here. Indeed, it's kind of reproduced here, except that I've used fixed versions for each build module, so with Ivy cache the build system is cached at first call and don't use any network connection on later calls. You need a network connection only if you use a new build module, or specify to use a latest version of a build module (which would mimic maven auto update mechanism, but that I'd decourage). I would prefer a tool like the linux > distributions are using. There is a special tool to manage the > download of the latest component, resolving dependencies so ensuring > that the downloaded tools are consistent. > For instance we could imagine having some targets easyant:init and > esayant:update which should be similar to an "apt-get install" and an > "apt-get dist-upgrade". So after successfully calling these targets > the end user will be able to use its build system offline without > worring of the consistent state of its build system. > Then there are the "apt-get update" and the "apt-cache search" > features which would be very cool, but I wonder how Ivy could support. > that. Indeed, clearly separing steps is a good idea. With Ivy cache as I said we already have some support of this as is (and with recent support for TTL for dynamic revision resolution, we could even support some kind of on demand update mechanism, by using an infinite TTL and the refresh mechanism). But we could make it even more separated, having an explicit step to initialize the build system, putting everything in the modules directory as it's done in the POC. Then you use a local only build system, which is much easier to understand. BTW, we are only talking about the build system itself here. The process of resolving module dependencies is another aspect, with different needs in change management. > > Then about the implementation, here are some few questions: > > I don't understand exactly what is the module.ivy in the exemple. Is > it a strict equivalent to the pom.xml, so it will replace a build.xml > + ivy.xml ? Well, I see it as an equivalent of a simple and basic pom.xml. One thing I dislike with pom.xml is that they mix project metadata (such as id, dependencies, project type, ...) with some build specific information (such as configuration of build plugins). Then when you publish a maven module you end up with all this information in your repository, while I don't think they fit very well in a module repository. So what I envision is a slightly enhanced ivy.xml, with very basic information used for the build itself: module type (ie the main build module to import), and some properties to customize the build. If you need more, you write a module.ant file, in which you have the full power and flexibility of Ant. > > > Then quoting the README: > "The idea is to have a very limited options of customizing the build > in the Ivy file: settings > properties, and telling which main build module shold be imported. If > you need more, you have to use > a module.ant file." > > Why not just having a module.ant ? As I explained earlier, I personnaly prefer to isolate module metadata from build logic. module.ivy is for module metadata, module.ant is for custom build logic if necessary. But in most cases I'd encourage creating a custom build module, and importing this module, rather than creating a module.antfile. > And then why naming it module.ant, couldn't it be a classic > build.xml ? What will be the difference for the end user? I thought it was more consistent with the module.ivy naming convention, and the usage is slightly different from a build.xml: in all cases easyant actually use its own ant file (easyant.ant) to load the module specific files (including module.ant). But I agree this is very similar to a build.xml, so maybe we should drop the module.ant concept in favor of standard build.xml when the user want a module specific build. Xavier > > > Nicolas > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Xavier Hanin - Independent Java Consultant http://xhab.blogspot.com/ http://ant.apache.org/ivy/ http://www.xoocode.org/
