ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xavier Hanin" <xavier.ha...@gmail.com>
Subject Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java projects
Date Thu, 10 Jan 2008 22:00:36 GMT
On Jan 10, 2008 10:21 PM, kermitt <herve.bourzeix@genesys.com> wrote:

>
> I had a look, I share the same goal but I don't like the need to compile
> class especially just to setup a task with default value. It also had a
> bit
> of black magic as you can look quickly in source as a reference.

Exactly, this is drawbacks that should be addressed IMO.

>
>
> I read your idea about interceptor I think it could be a good idea but as
> you said it requires a new ant build.
>
> To move forward quickly, the hack of the merevaik project could be reused
> to
> implement Gilles idea ( having build file in a jar) and inject ivy as I
> suggest.
>
> What do you think?

I think I share your opinion: keep things simple to get something working
pretty quickly.

But first we'd need to know where to further discuss ideas about the
project. I've started the discussion here to get feedback, and I would like
to gather more feedback here and ideas before moving forward. But then we
will need to know if this should be an Ant subproject which could be
discussed here. Or if it would better to start outside the ASF. Let's take
some time before going into too low level details.

Xavier

>
>
>
>
>
>
> Xavier Hanin wrote:
> >
> > On Jan 10, 2008 8:16 PM, kermitt <herve.bourzeix@genesys.com> wrote:
> >
> >>
> >> I wish we could find a way to bundle common tasks : I have more than 9
> >> templates :
> >>
> >> build-common.xml
> >> build-j2ee.xml
> >> build-war.xml
> >> build-ejb.xml
> >> build-ws.xml
> >> build-client-ws.xml
> >> build-ear.xml
> >> ...
> >>
> >> These builds just formalize my build system based on Ivy.
> >> For each project I need to sync those files which is a pain within a
> >> team.
> >> How to enforce team to use your  build process, how do you easly patch,
> >> add
> >> feature. It's puzzling me. Today I need to copy paste all these files
> all
> >> over my projects.
> >>
> >> I think Ivy dictate somehow the build process as you always need to
> >> perform
> >> some tasks configure/resolve/cachepath...
> >>
> >> My common-build.xml has 9 visible targets:
> >>
> >> all -> clean , build , package , publish
> >> build -> init ivy -> resolve -> compute classpath -> do I have
> something
> >> to
> >> build ? (has dependencies  changed? files ?)  -> find what is the next
> >> release -> compile
> >> clean -> clean any generated files
> >> doc -> build any doc
> >> package -> make a jar
> >> publish -> get current ivy version -> publish jar on local repo
> >> share -> publish jar on integration repo
> >> release -> publish jar in test/prod repo
> >> test -> lauch unit tests
> >>
> >>
> >> I wish Ant import would support URL + jar like that :
> >>
> >> <project ...>
> >>   <import
> >> url="http://repo/build.jar!common-build.xml<http://repo/build.jar%21common-build.xml>
> <http://repo/build.jar%21common-build.xml>
> >> "/>
> >> </project>
> >>
> >> As ivy became a sub project, it would make sense to have a closer
> >> integration like :
> >>
> >> <project ...>
> >>   <import url="ivy://settings.xml:org/module/artifact@MyResolver" />
> >> <!--
> >> would locate the settings.xml file and seek a build-common.xml file
> using
> >> MyResolver resolver.
> >> -->
> >> </project>
> >>
> >> we could imagine deeper integration :
> >>
> >> <project ...>
> >>   <import url="ivy://settings.xml:org/module/artifact@MyResolver"
> >> ivyFile="${basedir]/ivy.xml"/>
> >> <!--
> >> configure ivy / read the ivy file
> >> would map each ivy configuration to a path ( path could use a lazy
> >> resolve
> >> proxy: resolve only when it get used)
> >> would import resolved artifcat as an ant build file
> >>
> >> -->
> >> </project>
> >
> >
> > Improving the import mechanism to leverage Ivy is indeed a good idea and
> a
> > good solution to package the build system parts. I also like what has
> been
> > done in merevaik, leveraging directly the xmlns support in Ant (see the
> > comment on my blog).
> >
> > Xavier
> >
> >
> >>
> >>
> >> I think is not easy to not like maven ... but Xavier is right it's time
> >> to
> >> go a step beyond with ant+ivy
> >>
> >>
> >> So any comments on that ?
> >>
> >>
> >>
> >>
> >>
> >>
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p14741437.html
> >> Sent from the Ant - Dev mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> >> For additional commands, e-mail: dev-help@ant.apache.org
> >>
> >>
> >
> >
> > --
> > Xavier Hanin - Independent Java Consultant
> > http://xhab.blogspot.com/
> > http://ant.apache.org/ivy/
> > http://www.xoocode.org/
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/-DISCUSS--EasyAnt%3A-Ant-based-pre-packaged-build-system-for-java-projects-tp14735371p14744234.html
> Sent from the Ant - Dev mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>


-- 
Xavier Hanin - Independent Java Consultant
http://xhab.blogspot.com/
http://ant.apache.org/ivy/
http://www.xoocode.org/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message