You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Kev Jackson <fo...@gmail.com> on 2007/11/13 03:02:15 UTC
ApacheCon Presentation
Hi all,
As some of you probably know already, the HK OSSummit has been canceled
due to lack of attendees.
But as I've already prepared my presentation (which will now not be
aired publicly), feel free to browse/peruse yourselves without my witty
voiceover
http://people.apache.org/~kevj/ossummit/extending-ant.html
If anyone is presenting at ApacheCon US / ApacheCon EU and wants to
take/modify material in the presentation, feel free - I hope it gets
some use.
I cover:
* Antlibs (same material as my previous presentation)
* BuildListener/Logger
* <scriptdef>
* Basic IVY
The format is S5 which is basically html + javascript + css.
Thanks,
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: ApacheCon Presentation
Posted by "Rebhan, Gilbert" <Gi...@huk-coburg.de>.
Hi, Kev
-----Original Message-----
From: Kev Jackson [mailto:foamdino@gmail.com]
Sent: Tuesday, November 13, 2007 3:02 AM
To: Ant Developers List; Ant Users List
Subject: ApacheCon Presentation
/*
Hi all,
As some of you probably know already, the HK OSSummit has been canceled
due to lack of attendees.
But as I've already prepared my presentation (which will now not be
aired publicly), feel free to browse/peruse yourselves without my witty
voiceover
http://people.apache.org/~kevj/ossummit/extending-ant.html
*/
Too bad,nevertheless thanks for sharing your excellent presentation !
Hope you'll get a some positive feedback from the ant community
as compensation.
Regards, Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
RE: ApacheCon Presentation
Posted by "Rebhan, Gilbert" <Gi...@huk-coburg.de>.
Hi, Kev
-----Original Message-----
From: Kev Jackson [mailto:foamdino@gmail.com]
Sent: Tuesday, November 13, 2007 3:02 AM
To: Ant Developers List; Ant Users List
Subject: ApacheCon Presentation
/*
Hi all,
As some of you probably know already, the HK OSSummit has been canceled
due to lack of attendees.
But as I've already prepared my presentation (which will now not be
aired publicly), feel free to browse/peruse yourselves without my witty
voiceover
http://people.apache.org/~kevj/ossummit/extending-ant.html
*/
Too bad,nevertheless thanks for sharing your excellent presentation !
Hope you'll get a some positive feedback from the ant community
as compensation.
Regards, Gilbert
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
For additional commands, e-mail: user-help@ant.apache.org
Re: ApacheCon Presentation
Posted by Xavier Hanin <xa...@gmail.com>.
Nice presentation, thanks for sharing!
One minor thing about Ivy presentation: I think the slide on artifact
declaration is misleading: when you say that the master conf has no
dependency, this is not a consequence of the publication section, the master
conf could have dependencies. The only thing the publication section says is
that the ant jar artifact (module name being the default for the artifact
name, and jar being the default for type and extension) is published as part
of the master configuration.
Xavier
On Nov 13, 2007 3:02 AM, Kev Jackson <fo...@gmail.com> wrote:
> Hi all,
>
> As some of you probably know already, the HK OSSummit has been canceled
> due to lack of attendees.
>
> But as I've already prepared my presentation (which will now not be
> aired publicly), feel free to browse/peruse yourselves without my witty
> voiceover
>
> http://people.apache.org/~kevj/ossummit/extending-ant.html<http://people.apache.org/%7Ekevj/ossummit/extending-ant.html>
>
> If anyone is presenting at ApacheCon US / ApacheCon EU and wants to
> take/modify material in the presentation, feel free - I hope it gets
> some use.
>
> I cover:
> * Antlibs (same material as my previous presentation)
> * BuildListener/Logger
> * <scriptdef>
> * Basic IVY
>
>
> The format is S5 which is basically html + javascript + css.
>
> Thanks,
> Kev
>
> ---------------------------------------------------------------------
> 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/
Re: ApacheCon Presentation
Posted by Peter Reilly <pe...@gmail.com>.
On Nov 14, 2007 4:51 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> >> Then again it's these people, Peter first, who enhance Ant to
> >> support better models for the future, so power to you guys ;-)
>
> Cool, so we can expect 'auto-download' to be a feature of 1.7.1?
>
> Serious, just to pull off some kind of demo implementation: is there some
> kind of
> namespace interceptor in Ant's source code? I'm just asking cause I have
> never
> seen such a beast...
There is code in oata.ComponentHelper#checkNamespace(String componentName)
that check the namespace:
private synchronized void checkNamespace(String componentName) {
String uri = ProjectHelper.extractUriFromComponentName(componentName);
if ("".equals(uri)) {
uri = ProjectHelper.ANT_CORE_URI;
}
if (!uri.startsWith(ProjectHelper.ANTLIB_URI)) {
return; // namespace that does not contain antlib
}
if (checkedNamespaces.contains(uri)) {
return; // Already processed
}
checkedNamespaces.add(uri);
Typedef definer = new Typedef();
definer.setProject(project);
definer.init();
definer.setURI(uri);
//there to stop error messages being "null"
definer.setTaskName(uri);
//if this is left out, bad things happen. like all build files break
//on the first element encountered.
definer.setResource(Definer.makeResourceFromURI(uri));
// a fishing expedition :- ignore errors if antlib not present
definer.setOnError(new Typedef.OnError(Typedef.OnError.POLICY_IGNORE));
definer.execute();
}
Peter
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. +31 (0)70 340 4931
> whaefelinger@epo.org
> http://www.epo.org
>
>
>
>
> "Dominique Devienne" <dd...@gmail.com>
> 14-11-2007 17:40
> Please respond to
> "Ant Developers List" <de...@ant.apache.org>
>
>
> To
> "Ant Developers List" <de...@ant.apache.org>
> cc
>
> Subject
> Re: ApacheCon Presentation
>
>
>
>
>
>
>
> On Nov 14, 2007 9:50 AM, Peter Reilly <pe...@gmail.com> wrote:
> > On Nov 14, 2007 3:18 PM, Dominique Devienne <dd...@gmail.com> wrote:
> > > On Nov 14, 2007 8:07 AM, Wolfgang Häfelinger <wh...@epo.org>
> wrote:
> > > > * Simple fix...place all third-party jars in $ANT_HOME/lib
> > > >
> > > > Honestly, putting something into Ant's lib directory is really ugly
> and all
> > > > those alternatives ($HOME/.ant etc) do not solve the overall
> problem.
> >
> > I would argue that using -lib is nearly as ugly as placing jars in
> $ANT_HOME/lib
> > (but not as bad!!)
> >
> > On projects at work, that I am involved in, I insist on
> > using "clean room" ant 1.7.0 and "clean room" java 1.5.* (or higher).
> >
> > For each antlib / extension that is needed, I have an ant file that
> > sets up the extension for-example ant-contrib.
>
> Given a corporate environment (as opposed to OSS), I believe it's
> entirely OK, and even A-Good-ThingTM to have an official and properly
> configured Ant version which is the only *official* and *sanctioned*
> way to run the builds, which is under source control.
>
> The allows proper control of the dependencies, and allows to manage
> Ant versions to be used by the different branches/versions of the
> software, and most importantly it's easy! Check out the proper branch
> of the build tools, and of the software to be built, and you're in
> business. Just add JDK and shake, and here you go, instant CM ;-)
>
> I'm sure your build organization rocks Peter, but I personally view it
> as more complex and more trouble that I was willing to live with
> myself (I'm not even sure I could pull such a setup off myself in
> fact!).
>
> Different people draw the line between the absolute ideal and the
> practical at different places. Having a centralized Ant under SCM was
> the thing for me, and obviously others find it unacceptable, and have
> to live with my complex setups. Then again it's these people, Peter
> first, who enhance Ant to support better models for the future, so
> power to you guys ;-)
>
> Cheers, --DD
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ApacheCon Presentation
Posted by Wolfgang Häfelinger <wh...@epo.org>.
>> Then again it's these people, Peter first, who enhance Ant to
>> support better models for the future, so power to you guys ;-)
Cool, so we can expect 'auto-download' to be a feature of 1.7.1?
Serious, just to pull off some kind of demo implementation: is there some
kind of
namespace interceptor in Ant's source code? I'm just asking cause I have
never
seen such a beast...
Regards,
Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
whaefelinger@epo.org
http://www.epo.org
"Dominique Devienne" <dd...@gmail.com>
14-11-2007 17:40
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Re: ApacheCon Presentation
On Nov 14, 2007 9:50 AM, Peter Reilly <pe...@gmail.com> wrote:
> On Nov 14, 2007 3:18 PM, Dominique Devienne <dd...@gmail.com> wrote:
> > On Nov 14, 2007 8:07 AM, Wolfgang Häfelinger <wh...@epo.org>
wrote:
> > > * Simple fix...place all third-party jars in $ANT_HOME/lib
> > >
> > > Honestly, putting something into Ant's lib directory is really ugly
and all
> > > those alternatives ($HOME/.ant etc) do not solve the overall
problem.
>
> I would argue that using -lib is nearly as ugly as placing jars in
$ANT_HOME/lib
> (but not as bad!!)
>
> On projects at work, that I am involved in, I insist on
> using "clean room" ant 1.7.0 and "clean room" java 1.5.* (or higher).
>
> For each antlib / extension that is needed, I have an ant file that
> sets up the extension for-example ant-contrib.
Given a corporate environment (as opposed to OSS), I believe it's
entirely OK, and even A-Good-ThingTM to have an official and properly
configured Ant version which is the only *official* and *sanctioned*
way to run the builds, which is under source control.
The allows proper control of the dependencies, and allows to manage
Ant versions to be used by the different branches/versions of the
software, and most importantly it's easy! Check out the proper branch
of the build tools, and of the software to be built, and you're in
business. Just add JDK and shake, and here you go, instant CM ;-)
I'm sure your build organization rocks Peter, but I personally view it
as more complex and more trouble that I was willing to live with
myself (I'm not even sure I could pull such a setup off myself in
fact!).
Different people draw the line between the absolute ideal and the
practical at different places. Having a centralized Ant under SCM was
the thing for me, and obviously others find it unacceptable, and have
to live with my complex setups. Then again it's these people, Peter
first, who enhance Ant to support better models for the future, so
power to you guys ;-)
Cheers, --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ApacheCon Presentation
Posted by Dominique Devienne <dd...@gmail.com>.
On Nov 14, 2007 9:50 AM, Peter Reilly <pe...@gmail.com> wrote:
> On Nov 14, 2007 3:18 PM, Dominique Devienne <dd...@gmail.com> wrote:
> > On Nov 14, 2007 8:07 AM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> > > * Simple fix...place all third-party jars in $ANT_HOME/lib
> > >
> > > Honestly, putting something into Ant's lib directory is really ugly and all
> > > those alternatives ($HOME/.ant etc) do not solve the overall problem.
>
> I would argue that using -lib is nearly as ugly as placing jars in $ANT_HOME/lib
> (but not as bad!!)
>
> On projects at work, that I am involved in, I insist on
> using "clean room" ant 1.7.0 and "clean room" java 1.5.* (or higher).
>
> For each antlib / extension that is needed, I have an ant file that
> sets up the extension for-example ant-contrib.
Given a corporate environment (as opposed to OSS), I believe it's
entirely OK, and even A-Good-ThingTM to have an official and properly
configured Ant version which is the only *official* and *sanctioned*
way to run the builds, which is under source control.
The allows proper control of the dependencies, and allows to manage
Ant versions to be used by the different branches/versions of the
software, and most importantly it's easy! Check out the proper branch
of the build tools, and of the software to be built, and you're in
business. Just add JDK and shake, and here you go, instant CM ;-)
I'm sure your build organization rocks Peter, but I personally view it
as more complex and more trouble that I was willing to live with
myself (I'm not even sure I could pull such a setup off myself in
fact!).
Different people draw the line between the absolute ideal and the
practical at different places. Having a centralized Ant under SCM was
the thing for me, and obviously others find it unacceptable, and have
to live with my complex setups. Then again it's these people, Peter
first, who enhance Ant to support better models for the future, so
power to you guys ;-)
Cheers, --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ApacheCon Presentation
Posted by Wolfgang Häfelinger <wh...@epo.org>.
Peter,
I'm missing the 'download' part in the example you gave. It appears that
you expect your
jars already to be present in ${commons.dir}, and even in a nicely
structured way. To
much too assume. It should all be handled by Ant's core ..
Regards,
Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
whaefelinger@epo.org
http://www.epo.org
"Peter Reilly" <pe...@gmail.com>
14-11-2007 16:51
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Re: ApacheCon Presentation
On Nov 14, 2007 3:18 PM, Dominique Devienne <dd...@gmail.com> wrote:
> On Nov 14, 2007 8:07 AM, Wolfgang Häfelinger <wh...@epo.org>
wrote:
> > * Simple fix...place all third-party jars in $ANT_HOME/lib
> >
> > Honestly, putting something into Ant's lib directory is really ugly
and all
> > those alternatives ($HOME/.ant etc) do not solve the overall problem.
>
> If the project you checkout includes its own Ant extensions, and you
> want to use a stock Ant release, you still have the option of using
> the -lib command line switch to tell the Ant launcher to use your
> custom libs. Using -lib is just as effective as putting the jars in
> $ANT_HOME/lib I believe. Then you only need a little wrapper
> build.bat/.sh script (checked in) to launch Ant properly configured
> for the projects.
I would argue that using -lib is nearly as ugly as placing jars in
$ANT_HOME/lib
(but not as bad!!)
On projects at work, that I am involved in, I insist on
using "clean room" ant 1.7.0 and "clean room" java 1.5.* (or higher).
For each antlib / extension that is needed, I have an ant file that
sets up the extension for-example ant-contrib.
<project name="ant-contrib.setup">
<typedef uri="antlib:net.sf.antcontrib"
resource="net/sf/antcontrib/antlib.xml">
<classpath>
<fileset dir="${commons.dir}/lib/ant/ant-contrib" includes="*.jar"/>
</classpath>
</typedef>
</project>
These setup files are called from a setup.xml:
<project name="ant.setup">
<!-- allow developer override of properties -->
<property file="override.properties"/>
<property name="java.ver" value="1.5"/>
<property environment="env"/>
<dirname property="ant.setup.dir" file="${ant.file.ant.setup}"/>
<property name="commons.dir"
location="${ant.setup.dir}/../.."/>
<property name="top.dir"
location="${commons.dir}/.."/>
<property name="dist.dir"
location="${top.dir}/build/dist"/>
<property name="main.java" location="src/main/java"/>
<property name="test.java" location="src/test/java"/>
<import file="ant-classloader.xml"/>
<import file="ant-contrib.xml"/>
<import file="log4j.xml"/>
<import file="beanshell.xml"/>
<import file="macros.xml"/>
<import file="cobertura.xml"/>
<import file="checkstyle.xml"/>
<import file="javadoc.xml"/>
<import file="axis.xml"/>
<import file="targets.xml"/>
<import file="findbugs.xml"/>
<import file="pmd.xml"/>
<import file="jaxb.xml"/>
</project>
Where necessary I use the {antlib:net.jtools.classloadertask}classloader
task
(http://enitsys.sourceforge.net/ant-classloadertask/) to
shovel jars into the project classloader - necessary for example to
use beanshell
with bsf on ant 1.7.0. I also found in necessary to use it to avoid
classloading issues
with coverage tools on axis tasks.
<project name="beanshell"
xmlns:cl="antlib:net.jtools.classloadertask"
xmlns:ac="antlib:net.sf.antcontrib">
<!-- Enable beanshell
With ant 1.7.0 the only way to do this
within a project is to use cl:classloader
-->
<cl:classloader loader="project">
<classpath>
<fileset dir="${commons.dir}/lib/main/commons-logging"
includes="*.jar"/>
<fileset dir="${commons.dir}/lib/ant/bsf" includes="*.jar"/>
<fileset dir="${commons.dir}/lib/ant/beanshell" includes="*.jar"/>
</classpath>
</cl:classloader>
</project>
Peter
>
> Sure, auto-download of dependencies would be nice, and with Ivy part
> of the Ant family, it may come sooner rather than later, but in the
> mean time, -lib is a very effective and easy way to work around your
> issue it sounds like. --DD
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ApacheCon Presentation
Posted by Peter Reilly <pe...@gmail.com>.
On Nov 14, 2007 3:18 PM, Dominique Devienne <dd...@gmail.com> wrote:
> On Nov 14, 2007 8:07 AM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> > * Simple fix...place all third-party jars in $ANT_HOME/lib
> >
> > Honestly, putting something into Ant's lib directory is really ugly and all
> > those alternatives ($HOME/.ant etc) do not solve the overall problem.
>
> If the project you checkout includes its own Ant extensions, and you
> want to use a stock Ant release, you still have the option of using
> the -lib command line switch to tell the Ant launcher to use your
> custom libs. Using -lib is just as effective as putting the jars in
> $ANT_HOME/lib I believe. Then you only need a little wrapper
> build.bat/.sh script (checked in) to launch Ant properly configured
> for the projects.
I would argue that using -lib is nearly as ugly as placing jars in $ANT_HOME/lib
(but not as bad!!)
On projects at work, that I am involved in, I insist on
using "clean room" ant 1.7.0 and "clean room" java 1.5.* (or higher).
For each antlib / extension that is needed, I have an ant file that
sets up the extension for-example ant-contrib.
<project name="ant-contrib.setup">
<typedef uri="antlib:net.sf.antcontrib"
resource="net/sf/antcontrib/antlib.xml">
<classpath>
<fileset dir="${commons.dir}/lib/ant/ant-contrib" includes="*.jar"/>
</classpath>
</typedef>
</project>
These setup files are called from a setup.xml:
<project name="ant.setup">
<!-- allow developer override of properties -->
<property file="override.properties"/>
<property name="java.ver" value="1.5"/>
<property environment="env"/>
<dirname property="ant.setup.dir" file="${ant.file.ant.setup}"/>
<property name="commons.dir"
location="${ant.setup.dir}/../.."/>
<property name="top.dir"
location="${commons.dir}/.."/>
<property name="dist.dir"
location="${top.dir}/build/dist"/>
<property name="main.java" location="src/main/java"/>
<property name="test.java" location="src/test/java"/>
<import file="ant-classloader.xml"/>
<import file="ant-contrib.xml"/>
<import file="log4j.xml"/>
<import file="beanshell.xml"/>
<import file="macros.xml"/>
<import file="cobertura.xml"/>
<import file="checkstyle.xml"/>
<import file="javadoc.xml"/>
<import file="axis.xml"/>
<import file="targets.xml"/>
<import file="findbugs.xml"/>
<import file="pmd.xml"/>
<import file="jaxb.xml"/>
</project>
Where necessary I use the {antlib:net.jtools.classloadertask}classloader task
(http://enitsys.sourceforge.net/ant-classloadertask/) to
shovel jars into the project classloader - necessary for example to
use beanshell
with bsf on ant 1.7.0. I also found in necessary to use it to avoid
classloading issues
with coverage tools on axis tasks.
<project name="beanshell"
xmlns:cl="antlib:net.jtools.classloadertask"
xmlns:ac="antlib:net.sf.antcontrib">
<!-- Enable beanshell
With ant 1.7.0 the only way to do this
within a project is to use cl:classloader
-->
<cl:classloader loader="project">
<classpath>
<fileset dir="${commons.dir}/lib/main/commons-logging" includes="*.jar"/>
<fileset dir="${commons.dir}/lib/ant/bsf" includes="*.jar"/>
<fileset dir="${commons.dir}/lib/ant/beanshell" includes="*.jar"/>
</classpath>
</cl:classloader>
</project>
Peter
>
> Sure, auto-download of dependencies would be nice, and with Ivy part
> of the Ant family, it may come sooner rather than later, but in the
> mean time, -lib is a very effective and easy way to work around your
> issue it sounds like. --DD
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ApacheCon Presentation
Posted by Wolfgang Häfelinger <wh...@epo.org>.
Dominique,
>> If the project you checkout includes its own Ant extensions
I does not and I also believe it should not. I believe it's a rather good
rule that a source
repository contains sources and not binaries.
Perhaps I should also mention that I'm not talking here about one or two
projects. It's
more a matter of hundreds or even thousands.
>> Using -lib is just as effective as putting the jars in
>> $ANT_HOME/lib I believe [..]
>> [..]
>> Then you only need a little wrapper build.bat/.sh [..]
The problem starts already with the fact that you need to maintain two
scripts (Windows
and Unix). Then you need to download somehow. You can't assume that wget
is around.
So my script generates/contains a Ant script 'fetch.xml' which I would
need to call to my
plugins in place (using get task to download). I optimize this script to
call Ant only in
case something is missing....
Then you have the problem that you just add another complexity level, i.e.
the script. If
something is going wrong you firstly start to blame this script ..
Finally there's the scenario where the build script is implemented in
terms of a framework
sitting on top of Ant. This frameworks builds the project, the
developer does not need to
care about the details. If this framework requires a new dependency,
then I would need to
change each "build.bat/.sh" script around. I could also optimize this
by letting my down-
loader fetch a list of artefacts to be downloaded. Then I only need to
change this list on a
central server ...
I went a bit a different path in my framework case. I just created one big
fat binary containing
all those extension jars. So I just need to ask our users to update a
single jar once in a while.
It works although it's another ugly hack.
I'm not a fan of Maven, but this automatic "plugin" download feature is
really a good thing!
>> Sure, auto-download of dependencies would be nice, and with Ivy
>> part of the Ant family, it may come sooner rather than later, [..]
I'm in favor of "sooner" :-) Of course, if I'm the only one missing
"auto-download" then it
doesn't make sense to ask for it.
Regards,
Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
whaefelinger@epo.org
http://www.epo.org
"Dominique Devienne" <dd...@gmail.com>
14-11-2007 16:18
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Re: ApacheCon Presentation
On Nov 14, 2007 8:07 AM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> * Simple fix...place all third-party jars in $ANT_HOME/lib
>
> Honestly, putting something into Ant's lib directory is really ugly and
all
> those alternatives ($HOME/.ant etc) do not solve the overall problem.
If the project you checkout includes its own Ant extensions, and you
want to use a stock Ant release, you still have the option of using
the -lib command line switch to tell the Ant launcher to use your
custom libs. Using -lib is just as effective as putting the jars in
$ANT_HOME/lib I believe. Then you only need a little wrapper
build.bat/.sh script (checked in) to launch Ant properly configured
for the projects.
Sure, auto-download of dependencies would be nice, and with Ivy part
of the Ant family, it may come sooner rather than later, but in the
mean time, -lib is a very effective and easy way to work around your
issue it sounds like. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ApacheCon Presentation
Posted by Dominique Devienne <dd...@gmail.com>.
On Nov 14, 2007 8:07 AM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> * Simple fix...place all third-party jars in $ANT_HOME/lib
>
> Honestly, putting something into Ant's lib directory is really ugly and all
> those alternatives ($HOME/.ant etc) do not solve the overall problem.
If the project you checkout includes its own Ant extensions, and you
want to use a stock Ant release, you still have the option of using
the -lib command line switch to tell the Ant launcher to use your
custom libs. Using -lib is just as effective as putting the jars in
$ANT_HOME/lib I believe. Then you only need a little wrapper
build.bat/.sh script (checked in) to launch Ant properly configured
for the projects.
Sure, auto-download of dependencies would be nice, and with Ivy part
of the Ant family, it may come sooner rather than later, but in the
mean time, -lib is a very effective and easy way to work around your
issue it sounds like. --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ApacheCon Presentation
Posted by Steve Loughran <st...@apache.org>.
Xavier Hanin wrote:
> Here's what we do in Ivy build to use emma (this is just an example):
> <ivy:cachepath organisation="emma" module="emma" revision="2.0.5312"
>
> inline="true" conf="default" pathid="emma.classpath"
> />
> <ivy:cachepath organisation="emma" module="emma_ant" revision="
> 2.0.5312"
> inline="true" conf="default" pathid="
> emma.ant.classpath" transitive="false" />
> <taskdef resource="emma_ant.properties">
> <classpath refid="emma.classpath" />
> <classpath refid="emma.ant.classpath" />
> </taskdef>
>
> With cleaner metadata using only one ivy:cachepath would be enough. Without
> Ivy, you can simply use a get task and build a path from the downloaded jar.
> That's what we suggest to do to "install" Ivy itself if you want to use
> clean Ant install (since using Ivy for that is obviously not an option :-)).
Right now we are half way to something that works. With an xml
namespace, you can autoload third party tasks. But those tasks need to
be in the classpath or specified with a lib argument.
I could imagine
-an <ivy:typedef> command that integrates retrieval/classpath setup with
type definitions.
Easy to do, no changes to Ant
-the ability to declare in a build file what the resolver setup is; a
component that is given the problem of resolving antlib URLs.
We'd need changes to Ant to delegate to any defined resolver, then have
a task like <ivy:resolver ivyconf="${root.dir}/ivyconf.xml" />; this
would plug in a new resolver, if none was already live (if it was, tough).
You could maybe define one on the command line too, one that could be
driven by ant properties:
ant -resolver org.eclipse.eclipseresolver
-Dorg.eclipse.eclipseresolver.osgiurl=http://eclipse.org
This is something we could think of for Ant1.8
however, before we do this, we also have to address the security issue.
All artifacts need to come with authenticated checksums. That is either
separate (signed) MD5 sums, or we serve all MD5 sums up from an apache
https server. without either of those, there is no way to detect
malicious artifacts sneaking in. In this respect, the java world is
actually behind, say the debian apt-get world.
-steve
--
Steve Loughran http://www.1060.org/blogxter/publish/5
Author: Ant in Action http://antbook.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ApacheCon Presentation
Posted by Wolfgang Häfelinger <wh...@epo.org>.
Hi Xavier,
>> Without Ivy, you can simply use a get task and build a path
>> from the downloaded jar.
Well, but that implies that each and every build script (in thousands of
projects) need
to include such a "bootstrap".
Something like you code example is what I want to "burry" in the Ant core.
Just the
namespace implies the artefacts to be used.
Regards,
Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
whaefelinger@epo.org
http://www.epo.org
"Xavier Hanin" <xa...@gmail.com>
14-11-2007 23:29
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
"Ant Developers List" <de...@ant.apache.org>
cc
Subject
Re: ApacheCon Presentation
Here's what we do in Ivy build to use emma (this is just an example):
<ivy:cachepath organisation="emma" module="emma"
revision="2.0.5312"
inline="true" conf="default"
pathid="emma.classpath"
/>
<ivy:cachepath organisation="emma" module="emma_ant" revision="
2.0.5312"
inline="true" conf="default" pathid="
emma.ant.classpath" transitive="false" />
<taskdef resource="emma_ant.properties">
<classpath refid="emma.classpath" />
<classpath refid="emma.ant.classpath" />
</taskdef>
With cleaner metadata using only one ivy:cachepath would be enough.
Without
Ivy, you can simply use a get task and build a path from the downloaded
jar.
That's what we suggest to do to "install" Ivy itself if you want to use
clean Ant install (since using Ivy for that is obviously not an option
:-)).
Xavier
On Nov 14, 2007 3:07 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> Hey Kev,
>
> I just browsed your presentation and came across page 3/54 where I'm
> reading
>
> * Simple fix...place all third-party jars in $ANT_HOME/lib
>
> Honestly, putting something into Ant's lib directory is really ugly and
> all
> those alternatives ($HOME/.ant etc) do not solve the overall problem.
>
> My/our problem is that we would like to checkout a project from a
> source
> repository and then just call Ant to build it.
>
> That's the theory, but all but most trivial scripts I've seen have
> customized
> Ant. So they all need all those tiny little antlib jars. And that's why
> you
> need to resolve all those class-not-found-exceptions, very annoying
> actually.
>
> I wonder whether Ant/Ivy has a "dependency fetching" mechanism like
Maven
> has
> regarding "plugins". This is what I have in mind: A antlib provides
> tasks
> and macros and implements them in terms of 3rdparty libraries. Those
> libraries
> are described in dependencies (perhaps a la Maven). If such a antlib
is
> used,
> Ant will download those 3rdparty stuff some cache directory and
adjust
> it's
> classpath.
>
> Does such a feature exist? Is such a feature reasonable? Am I the only
one
> who
> is annoyed by putting 3rdparty libs in Ant's home directory?????
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. +31 (0)70 340 4931
> whaefelinger@epo.org
> http://www.epo.org
>
>
>
>
> Kev Jackson <fo...@gmail.com>
> 13-11-2007 03:02
> Please respond to
> "Ant Developers List" <de...@ant.apache.org>
>
>
> To
> Ant Developers List <de...@ant.apache.org>, Ant Users List
> <us...@ant.apache.org>
> cc
>
> Subject
> ApacheCon Presentation
>
>
>
>
>
>
> Hi all,
>
> As some of you probably know already, the HK OSSummit has been canceled
> due to lack of attendees.
>
> But as I've already prepared my presentation (which will now not be
> aired publicly), feel free to browse/peruse yourselves without my witty
> voiceover
>
> http://people.apache.org/~kevj/ossummit/extending-ant.html<
http://people.apache.org/%7Ekevj/ossummit/extending-ant.html>
>
> If anyone is presenting at ApacheCon US / ApacheCon EU and wants to
> take/modify material in the presentation, feel free - I hope it gets
> some use.
>
> I cover:
> * Antlibs (same material as my previous presentation)
> * BuildListener/Logger
> * <scriptdef>
> * Basic IVY
>
>
> The format is S5 which is basically html + javascript + css.
>
> Thanks,
> Kev
>
> ---------------------------------------------------------------------
> 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/
Re: ApacheCon Presentation
Posted by Xavier Hanin <xa...@gmail.com>.
Here's what we do in Ivy build to use emma (this is just an example):
<ivy:cachepath organisation="emma" module="emma" revision="2.0.5312"
inline="true" conf="default" pathid="emma.classpath"
/>
<ivy:cachepath organisation="emma" module="emma_ant" revision="
2.0.5312"
inline="true" conf="default" pathid="
emma.ant.classpath" transitive="false" />
<taskdef resource="emma_ant.properties">
<classpath refid="emma.classpath" />
<classpath refid="emma.ant.classpath" />
</taskdef>
With cleaner metadata using only one ivy:cachepath would be enough. Without
Ivy, you can simply use a get task and build a path from the downloaded jar.
That's what we suggest to do to "install" Ivy itself if you want to use
clean Ant install (since using Ivy for that is obviously not an option :-)).
Xavier
On Nov 14, 2007 3:07 PM, Wolfgang Häfelinger <wh...@epo.org> wrote:
> Hey Kev,
>
> I just browsed your presentation and came across page 3/54 where I'm
> reading
>
> * Simple fix...place all third-party jars in $ANT_HOME/lib
>
> Honestly, putting something into Ant's lib directory is really ugly and
> all
> those alternatives ($HOME/.ant etc) do not solve the overall problem.
>
> My/our problem is that we would like to checkout a project from a
> source
> repository and then just call Ant to build it.
>
> That's the theory, but all but most trivial scripts I've seen have
> customized
> Ant. So they all need all those tiny little antlib jars. And that's why
> you
> need to resolve all those class-not-found-exceptions, very annoying
> actually.
>
> I wonder whether Ant/Ivy has a "dependency fetching" mechanism like Maven
> has
> regarding "plugins". This is what I have in mind: A antlib provides
> tasks
> and macros and implements them in terms of 3rdparty libraries. Those
> libraries
> are described in dependencies (perhaps a la Maven). If such a antlib is
> used,
> Ant will download those 3rdparty stuff some cache directory and adjust
> it's
> classpath.
>
> Does such a feature exist? Is such a feature reasonable? Am I the only one
> who
> is annoyed by putting 3rdparty libs in Ant's home directory?????
>
> Regards,
>
> Wolfgang Häfelinger
> Research & Architecture | Dir. 2.7.0.2
> European Patent Office
> Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> Tel. +31 (0)70 340 4931
> whaefelinger@epo.org
> http://www.epo.org
>
>
>
>
> Kev Jackson <fo...@gmail.com>
> 13-11-2007 03:02
> Please respond to
> "Ant Developers List" <de...@ant.apache.org>
>
>
> To
> Ant Developers List <de...@ant.apache.org>, Ant Users List
> <us...@ant.apache.org>
> cc
>
> Subject
> ApacheCon Presentation
>
>
>
>
>
>
> Hi all,
>
> As some of you probably know already, the HK OSSummit has been canceled
> due to lack of attendees.
>
> But as I've already prepared my presentation (which will now not be
> aired publicly), feel free to browse/peruse yourselves without my witty
> voiceover
>
> http://people.apache.org/~kevj/ossummit/extending-ant.html<http://people.apache.org/%7Ekevj/ossummit/extending-ant.html>
>
> If anyone is presenting at ApacheCon US / ApacheCon EU and wants to
> take/modify material in the presentation, feel free - I hope it gets
> some use.
>
> I cover:
> * Antlibs (same material as my previous presentation)
> * BuildListener/Logger
> * <scriptdef>
> * Basic IVY
>
>
> The format is S5 which is basically html + javascript + css.
>
> Thanks,
> Kev
>
> ---------------------------------------------------------------------
> 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/
Re: ApacheCon Presentation
Posted by Wolfgang Häfelinger <wh...@epo.org>.
Hi,
>> IMHO dependency fetching is the *worst* of the ideas that Maven has
>> popularised.
Hmm, dependency fetching is the *best* in my opinion - so we
disagree :-)
>> Instead of having a controlled build, you get a build where it's
>> possible that every single build is done against a different set
>> of artifacts
How come? A dependency uniquely identifies an artefact and assuming you
can't override (
versioned) artefacts - how do you end up with different artefacts?
>> I prefer to know which libraries I'm building my code against :)
No you don't. This is the biggest mistake of Maven. The version of
an artefact is not important at all. However, I don't want to intro-
duce this into Ant. I just favour auto-download of artefacts.
>> As for the problem you have, different organizations deal with
>> the problem in different ways.
Kev, you didn't take the most obvious solution into account:
5. REPLACE ANT WITH MAVEN !!
And this is a real pitty cause Ant is the better solution, almost
at least. Just add some coool features please ..
Regards,
Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
whaefelinger@epo.org
http://www.epo.org
Kev Jackson <fo...@gmail.com>
15-11-2007 03:11
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
Ant Developers List <de...@ant.apache.org>
cc
Subject
Re: ApacheCon Presentation
Hi,
> I wonder whether Ant/Ivy has a "dependency fetching" mechanism like
Maven
> has
> regarding "plugins". This is what I have in mind: A antlib provides
> tasks
> and macros and implements them in terms of 3rdparty libraries. Those
> libraries
> are described in dependencies (perhaps a la Maven). If such a antlib
is
> used,
> Ant will download those 3rdparty stuff some cache directory and
adjust
> it's
> classpath.
IMHO dependency fetching is the *worst* of the ideas that Maven has
popularised.
Instead of having a controlled build, you get a build where it's
possible that every single build is done against a different set of
artifacts
I prefer to know which libraries I'm building my code against :)
As for the problem you have, different organizations deal with the
problem in different ways.
1 - Place the full Ant (core) + extensions (antlibs etc) under version
control as a 'build' project - make this the only sanctioned way of
building the rest of your code
* This relies on allowing binaries into your scm - sorry *
2 - Use multiple build files and a complex arrangements of classloader
task, wget/get etc to pull in the correct dependencies for the build
3 - Edit the ant.bat|ant.sh
4 - Write a wrapper script that calls ant.bat|ant.sh with the correct
env setup
As you can see in other replies, the 'solution' varies depending on the
particular needs of the organization :)
Thanks,
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ApacheCon Presentation
Posted by Kev Jackson <fo...@gmail.com>.
Hi,
> I wonder whether Ant/Ivy has a "dependency fetching" mechanism like Maven
> has
> regarding "plugins". This is what I have in mind: A antlib provides
> tasks
> and macros and implements them in terms of 3rdparty libraries. Those
> libraries
> are described in dependencies (perhaps a la Maven). If such a antlib is
> used,
> Ant will download those 3rdparty stuff some cache directory and adjust
> it's
> classpath.
IMHO dependency fetching is the *worst* of the ideas that Maven has
popularised.
Instead of having a controlled build, you get a build where it's
possible that every single build is done against a different set of
artifacts
I prefer to know which libraries I'm building my code against :)
As for the problem you have, different organizations deal with the
problem in different ways.
1 - Place the full Ant (core) + extensions (antlibs etc) under version
control as a 'build' project - make this the only sanctioned way of
building the rest of your code
* This relies on allowing binaries into your scm - sorry *
2 - Use multiple build files and a complex arrangements of classloader
task, wget/get etc to pull in the correct dependencies for the build
3 - Edit the ant.bat|ant.sh
4 - Write a wrapper script that calls ant.bat|ant.sh with the correct
env setup
As you can see in other replies, the 'solution' varies depending on the
particular needs of the organization :)
Thanks,
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ApacheCon Presentation
Posted by Wolfgang Häfelinger <wh...@epo.org>.
Hey Kev,
I just browsed your presentation and came across page 3/54 where I'm
reading
* Simple fix...place all third-party jars in $ANT_HOME/lib
Honestly, putting something into Ant's lib directory is really ugly and
all
those alternatives ($HOME/.ant etc) do not solve the overall problem.
My/our problem is that we would like to checkout a project from a
source
repository and then just call Ant to build it.
That's the theory, but all but most trivial scripts I've seen have
customized
Ant. So they all need all those tiny little antlib jars. And that's why
you
need to resolve all those class-not-found-exceptions, very annoying
actually.
I wonder whether Ant/Ivy has a "dependency fetching" mechanism like Maven
has
regarding "plugins". This is what I have in mind: A antlib provides
tasks
and macros and implements them in terms of 3rdparty libraries. Those
libraries
are described in dependencies (perhaps a la Maven). If such a antlib is
used,
Ant will download those 3rdparty stuff some cache directory and adjust
it's
classpath.
Does such a feature exist? Is such a feature reasonable? Am I the only one
who
is annoyed by putting 3rdparty libs in Ant's home directory?????
Regards,
Wolfgang Häfelinger
Research & Architecture | Dir. 2.7.0.2
European Patent Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
whaefelinger@epo.org
http://www.epo.org
Kev Jackson <fo...@gmail.com>
13-11-2007 03:02
Please respond to
"Ant Developers List" <de...@ant.apache.org>
To
Ant Developers List <de...@ant.apache.org>, Ant Users List
<us...@ant.apache.org>
cc
Subject
ApacheCon Presentation
Hi all,
As some of you probably know already, the HK OSSummit has been canceled
due to lack of attendees.
But as I've already prepared my presentation (which will now not be
aired publicly), feel free to browse/peruse yourselves without my witty
voiceover
http://people.apache.org/~kevj/ossummit/extending-ant.html
If anyone is presenting at ApacheCon US / ApacheCon EU and wants to
take/modify material in the presentation, feel free - I hope it gets
some use.
I cover:
* Antlibs (same material as my previous presentation)
* BuildListener/Logger
* <scriptdef>
* Basic IVY
The format is S5 which is basically html + javascript + css.
Thanks,
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org