You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ant.apache.org by Jean-Louis BOUDART <je...@gmail.com> on 2008/10/17 21:25:57 UTC
EasyAnt project
Hi all,
Xavier Hanin and I are currently working on a new build system fully based
on Apache Ant / Apache Ivy, here is a short information.
Welcome to EasyAnt
Easyant is a toolbox focusing on easing project build processes.
It's based on Apache Ant and Apache Ivy, and allows for maximum flexibily,
improved integration in existing build systems and provides conventions and
guidelines.
Our goals are :
- to simplify build process by providing a set of ready to use build
scrips (or modules) to ease implemantation of a build system.
- to provide conventions and guidelines
- to leverage your ant knowledge (no need to learn yet another language)
- to stay flexible :
- what about conventions ? : Even if Easyant came with a lot of
conventions, we never lock you in.
- what about modules ? : You can easily adapt it to your projects. The
architecture of Easyant allow you to easily extends existing
modules, and to
provide your own one.
- what about if i have an existing project? As Easyant is fully based
on ant, you can keep existing project with "old school" ant
script. This can
simplify migrations.
Currently Easyant provides module for :
- java compilation
- javadoc generation
- scala compilation
- scaladoc
- unit tests (Junit / TestNG)
- emma coverage
- checkstyle
- packaging jar / war application
- dependency management (using Apache Ivy)
- publication (using Apache Ivy)
Source code
Easyant is released under Apache License 2.0.
Sources can be found here
SVN Url : http://easyant.abrm.info/svn
Login : anonymous
pass: (empty)
Google group
<http://easyant.abrm.info/trac/wiki/WikiStart#Googlegroup>
A google group is accessible here http://groups.google.com/group/easyant
Our website is accessible here http://easyant.abrm.info
Jean Louis Boudart
Re: EasyAnt project
Posted by Jean-Louis BOUDART <je...@gmail.com>.
>
> FWIW, I'm not fond of the "phase" name either. What you describe is
> better described as a target-group, with any target being able to join
> the group at will, and where there's no implicit intra-group
> dependencies, and no "body" to the target-group (i.e. the group is
> "abstract" in a way).
I like the target-group name too :)
I think <target-group> should only depend on another <target-group>
<target-group name="test-compile" description="..." />
<target-group name="test" description="..." depends="test-compile"/>
Just as you seem to propose, I'd be in favor of requiring your <phase>
> or my <target-group> to be explicitly declared before it can be
> referenced. This would avoid typos implicitly creating groups
> unbeknown to the build writer / fat fingered individual ;-)
I agree, we must declared it explicitly!
Just Stefan pocking gentle fun at me, because I vehemently argued for
> what you propose when import was introduced. If you look back at the
> archives, I was strongly against using the import*ed* build file name
> in the import*er*, as it needlessly coupled the two, when good
> compartmentalization is essential to flexible and scalable designs (I
> even proposed the ability of the import*er* to give its own prefix as
> well). I also argued for separate import/include, just like in XSLT.
> In both cases my objections were ignored. So it's interesting that a
> separate group of Frenchmen now wants these same changes in Ant.
Is this a French invasion ? :p
When I argue what I believe is the right way to do something, and my
> point is being dismissed in favor of a lesser design (at least to me),
> this typically leaves me frustrated. Stefan "remue le couteau dans la
> plaie" comme on dit chez nous ;-) --DD
Ok now i understand
2008/10/29 Stefan Bodewig <bo...@apache.org>
> BTW, targets (and your phase variant of it) are not tasks.
My bad, i wanted to write "abstract target" but my fingers has wrotten
something different. Maybe i've taken too much coffee yesterday.
(Interresting my fingers can write something different of i'm thinking
about... )
I like Dominique's target group more than the name "phase". And I
> understand that EasyAnt builds on the Maven concept to make things
> easier for users switching. Without EasyAnt, the name would be a bad
> choice inside Ant.
There is no problem to rename "phase" concept in "target-group".
I think as you said target group is more self-explicit.
We'll probably need support and feedback on others modifications/concept on
EasyAnt that could be included in ant or ivy.
For example we need :
- to add "visibility" feature on target (something close to private /
public) (ant related)
As we want to introduce prefix on some kind of import it could be nice to
have a way to display only "public" target when you type "ant -p".
And to provide a way to see All targets (public / private) when we type "ant
myPrefix -p" that should display all the targets available for the import
we've called "myPrefix".
- to provide support for parent module (ivy related)
This is probably close to this issue
https://issues.apache.org/jira/browse/IVY-742
Even if i think support for parent module is not only related "dependency".
We could imagine that parent support allow you to inherit dependencies /
configurations / licences / homeurl / etc ...?
What do you think about that?
Cheers!
Re: EasyAnt project
Posted by Jean-Louis BOUDART <je...@gmail.com>.
UP
Is there some news about our patch or about ProjectHelper class / Target
class refactoring?
Jean Louis
2008/10/29 Stefan Bodewig <bo...@apache.org>
> On Wed, 29 Oct 2008, Matt Benson <gu...@yahoo.com> wrote:
>
> --- Stefan Bodewig <bo...@apache.org> wrote:
>
> >> On Wed, 29 Oct 2008, Matt Benson
> >> <gu...@yahoo.com> wrote:
>
> >> > 3. Define an ant.project.class magic property to
> >> > easily allow the user to specify an extended Project
> >> > class to use.
> >> > 4. EasyAnt has its own Project, Target, and Executor
> >> > implementations that know about phases.
> >>
> >> If EasyAnt used a ProjectHelper of its own, it probably could get
> >> away without a custom Project. A custom Executor may be a good
> >> idea, though.
> >>
> >> EasyAnt would need its own wrapper script or an invocation would
> >> become cumbersome, though.
> >
> > How is a custom Project class(name) more cumbersome to
> > configure than a custom ProjectHelper?
>
> Not at all, sorry, I didn't mean to say that. EasyAnt would need a
> wrapper anyway in order to configure Project class/ProjectHelper,
> Target class and Executor.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: EasyAnt project
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 29 Oct 2008, Matt Benson <gu...@yahoo.com> wrote:
--- Stefan Bodewig <bo...@apache.org> wrote:
>> On Wed, 29 Oct 2008, Matt Benson
>> <gu...@yahoo.com> wrote:
>> > 3. Define an ant.project.class magic property to
>> > easily allow the user to specify an extended Project
>> > class to use.
>> > 4. EasyAnt has its own Project, Target, and Executor
>> > implementations that know about phases.
>>
>> If EasyAnt used a ProjectHelper of its own, it probably could get
>> away without a custom Project. A custom Executor may be a good
>> idea, though.
>>
>> EasyAnt would need its own wrapper script or an invocation would
>> become cumbersome, though.
>
> How is a custom Project class(name) more cumbersome to
> configure than a custom ProjectHelper?
Not at all, sorry, I didn't mean to say that. EasyAnt would need a
wrapper anyway in order to configure Project class/ProjectHelper,
Target class and Executor.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ProjectHelper
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 30 Oct 2008, Jan Materne <Ja...@rzf.fin-nrw.de> wrote:
> Looks like Leafcutter: https://leafcutter.dev.java.net/
I haven't been aware of it. If you look at the other thread I've
started, it approaches things from a different angle.
Also I'd prefer to use the builder pattern and a fluent interface over
TaskRunner.run(String), but that part still needs to be done.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
AW: ProjectHelper (was Re: EasyAnt project)
Posted by Ja...@rzf.fin-nrw.de.
>My "build file" is going to look like this (I'm making up half of it):
>
>@Project(Name="example", DefaultTarget="echo")
>public class BuildFile extends JavaFrontBuildFile {
> public BuildFile(Project p) {
> super(p);
> }
>
> @Target
> public void echo() {
> getProject().log("Hello world");
> }
>
> @Target(Name="-setproperty")
> public void setProperty() {
> taskBuilder().newProperty().withName("world").andValue("world")
> .execute();
> }
>
> @Target(Depends="-setproperty")
> public void moreComplexExample() {
> taskBuilder().newEcho().withMessage("Hello
${world}").execute();
> }
>}
Looks like Leafcutter: https://leafcutter.dev.java.net/
<target name="backup" depends="init" if="backup.enabled">
<property name="source.dir" value="src/main"/>
<copy todir="home/backups" verbose=true>
<fileset dir=${source.dir}" includes="**/*.txt"/>
</copy>
</target>
public void backup(boolean enabled){
init();
if (enabled){
File sourceDir = new File("src/main");
TaskRunner.run("copy todir=home/backups verbose=true (fileset
dir=${1} includes=**/*.txt)", sourceDir);
}
}
Jan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: JavFront ProjectHelper
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 30 Oct 2008, Kevin Jackson <fo...@gmail.com> wrote:
>> I'm not doing OO stuff, the build file is a Java source.
>
> I suppose it would be possible to do the same using JavaScript as
> the language?
Not by taking the same approach, but probably similar.
> All you would need is a dependency on Rhino +BSF or Java6. - It
> would be interesting to see how hard HelloWorld is (/me puts on huge
> list of things todo..)
A Clojure version is on mine 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: JavFront ProjectHelper
Posted by Kevin Jackson <fo...@gmail.com>.
> I'm not doing OO stuff, the build file is a Java source.
I suppose it would be possible to do the same using JavaScript as the
language? All you would need is a dependency on Rhino +BSF or Java6. -
It would be interesting to see how hard HelloWorld is (/me puts on
huge list of things todo..)
> I've committed an embryonic version to the sandbox[1] which right now
> doesn't have the convenience base class I envision and doesn't have
> the TaskBuilder (or probably better TagBuilder) library to create
> tasks, yet.
Looks really nice
Kev
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
JavFront ProjectHelper
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 29 Oct 2008, Matt Benson <gu...@yahoo.com> wrote:
--- Stefan Bodewig <bo...@apache.org> wrote:
>> My "build file" is going to look like this (I'm
>> making up half of it):
>>
>
> This looks like it's friends with my concept of an Ant
> DSL except mine is pretty much just a de-XMLization of
> the status quo, no OO stuff as you show above.
I'm not doing OO stuff, the build file is a Java source.
I've committed an embryonic version to the sandbox[1] which right now
doesn't have the convenience base class I envision and doesn't have
the TaskBuilder (or probably better TagBuilder) library to create
tasks, yet.
But a few things it can do:
$ cat src/etc/examples/Simple2.java
package org.example;
import org.apache.ant.javafront.annotations.AntProject;
import org.apache.ant.javafront.annotations.AntTarget;
import org.apache.tools.ant.Project;
@AntProject()
public class Simple2 {
private final Project p;
public Simple2(Project p) {
this.p = p;
}
@AntTarget(Name="hello", Description="says hello", Depends="nonsense")
public void foo() {
p.log("Hello, world!");
p.log("This is " + p.getProperty("ant.version") + " calling.");
}
@AntTarget public void nonsense() {}
}
$ ant -lib build/lib/ant-javafront-0.1.jar -f src/etc/examples/Simple2.java -projecthelp
Buildfile: src\etc\examples\Simple2.java
[null] Compiling 1 source file to c:\DOKUME~1\STEFAN~1.BOD\LOKALE~1\Temp\ja
vafront
Main targets:
hello says hello
$ ant -lib build/lib/ant-javafront-0.1.jar -f src/etc/examples/Simple2.java hello
Buildfile: src\etc\examples\Simple2.java
nonsense:
hello:
Hello, world!
This is Apache Ant version 1.7.1 compiled on June 27 2008 calling.
BUILD SUCCESSFUL
Total time: 0 seconds
Stefan
who feels like he is exposing a toy project too early.
[1] http://svn.apache.org/repos/asf/ant/sandbox/javafront/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ProjectHelper
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 30 Oct 2008, Jeffrey E. Care <ca...@us.ibm.com> wrote:
> For my DiagnosticsProvider/VersionProvider patch I wrote a
> ServiceLoader class that mimics the API of the supported
> ServiceLoader class that comes with JDK 6. I'm still trying to get
> that patch cleared through IBM legal though, so I have no idea when
> I would be able to complete the contribution.
It would be pretty straightforward to pull the code from
ProjectHelper.getProjectHelper and make it a bit more generic. It
looks as if the code was stolen from Xerces. No need to jump through
any legal hoops IMHO.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ProjectHelper
Posted by Jeffrey E Care <ca...@us.ibm.com>.
The services mechanism was added to the JAR spec in JDK 1.3 or 1.4; Sun
didn't add public classes to use services until JDK 6. Before JDK 6 you
either had to use sun.misc.Service or write your own loader; IIRC there
was also a loader available with one of the optional JDK extensions
(something to do with audio or graphics) that we could use (it wasn't
actually related to the function of the library that it was provided
with).
For my DiagnosticsProvider/VersionProvider patch I wrote a ServiceLoader
class that mimics the API of the supported ServiceLoader class that comes
with JDK 6. I'm still trying to get that patch cleared through IBM legal
though, so I have no idea when I would be able to complete the
contribution.
____________________________________________________________________________________________
Jeffrey E. (Jeff) Care
carej@us.ibm.com
IBM WebSphere Application Server
WAS Release Engineering
From:
"Xavier Hanin" <xa...@gmail.com>
To:
"Ant Developers List" <de...@ant.apache.org>
Date:
10/30/2008 09:02 AM
Subject:
Re: ProjectHelper
On Thu, Oct 30, 2008 at 1:01 PM, Stefan Bodewig <bo...@apache.org>
wrote:
> On Wed, 29 Oct 2008, Matt Benson <gu...@yahoo.com> wrote:
>
> --- Stefan Bodewig <bo...@apache.org> wrote:
>
> > Okay, what say we move the Project instantiation to
> > ProjectHelper then, so that custom ProjectHelpers can
> > influence the Project class used if needed?
>
> we probably can do so without breaking existing code.
>
> > This still doesn't alleviate the problem that EasyAnt will need a
> > little custom configuration to install the ProjectHelper and,
> > probably, an Executor.
>
> As for the ProjectHelper, there is a services facility, so all it
> takes is putting the correct services entry into META-INF/services
> (JavaFront does so) and keeping the jar in your classpath.
AFAIK this only works with Java 6.
Xavier
Re: ProjectHelper
Posted by Xavier Hanin <xa...@gmail.com>.
On Thu, Oct 30, 2008 at 2:12 PM, Stefan Bodewig <bo...@apache.org> wrote:
> On Thu, 30 Oct 2008, Xavier Hanin <xa...@gmail.com> wrote:
>
> > On Thu, Oct 30, 2008 at 1:01 PM, Stefan Bodewig <bo...@apache.org>
> wrote:
> >
> > > As for the ProjectHelper, there is a services facility, so all it
> > > takes is putting the correct services entry into META-INF/services
> > > (JavaFront does so) and keeping the jar in your classpath.
> >
> > AFAIK this only works with Java 6.
>
> We've implemented it ourselves in ProjectHelper, works like a charm in
> Java5 (which I used for my examples and only because JavaFront relies
> on annotations) and probably any version of Java supported by Ant.
Ok, nice to know yet another Ant feature :-).
Xavier
>
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
--
Xavier Hanin - 4SH France
BordeauxJUG co leader - http://www.bordeauxjug.org/
Blogger - http://xhab.blogspot.com/
Apache Ivy Creator - http://ant.apache.org/ivy/
Re: ProjectHelper
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 30 Oct 2008, Xavier Hanin <xa...@gmail.com> wrote:
> On Thu, Oct 30, 2008 at 1:01 PM, Stefan Bodewig <bo...@apache.org> wrote:
>
> > As for the ProjectHelper, there is a services facility, so all it
> > takes is putting the correct services entry into META-INF/services
> > (JavaFront does so) and keeping the jar in your classpath.
>
> AFAIK this only works with Java 6.
We've implemented it ourselves in ProjectHelper, works like a charm in
Java5 (which I used for my examples and only because JavaFront relies
on annotations) and probably any version of Java supported by Ant.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ProjectHelper
Posted by Xavier Hanin <xa...@gmail.com>.
On Thu, Oct 30, 2008 at 1:01 PM, Stefan Bodewig <bo...@apache.org> wrote:
> On Wed, 29 Oct 2008, Matt Benson <gu...@yahoo.com> wrote:
>
> --- Stefan Bodewig <bo...@apache.org> wrote:
>
> > Okay, what say we move the Project instantiation to
> > ProjectHelper then, so that custom ProjectHelpers can
> > influence the Project class used if needed?
>
> we probably can do so without breaking existing code.
>
> > This still doesn't alleviate the problem that EasyAnt will need a
> > little custom configuration to install the ProjectHelper and,
> > probably, an Executor.
>
> As for the ProjectHelper, there is a services facility, so all it
> takes is putting the correct services entry into META-INF/services
> (JavaFront does so) and keeping the jar in your classpath.
AFAIK this only works with Java 6.
Xavier
Re: ProjectHelper
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 29 Oct 2008, Matt Benson <gu...@yahoo.com> wrote:
--- Stefan Bodewig <bo...@apache.org> wrote:
> Okay, what say we move the Project instantiation to
> ProjectHelper then, so that custom ProjectHelpers can
> influence the Project class used if needed?
we probably can do so without breaking existing code.
> This still doesn't alleviate the problem that EasyAnt will need a
> little custom configuration to install the ProjectHelper and,
> probably, an Executor.
As for the ProjectHelper, there is a services facility, so all it
takes is putting the correct services entry into META-INF/services
(JavaFront does so) and keeping the jar in your classpath.
I haven't checked whether we do the same for executors, we probably
should.
> But these are both handled with system properties, so this could
> either be done with hook scripts or an EasyAnt Main class that calls
> Ant Main after setting the necessary properties.
The wrapper looks like the least intrusive approach. Users then have
to consciously use it, with the services facility they may end up
using EasyAnt's extended versions just because it happens to live on
the CLASSPATH.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: ProjectHelper (was Re: EasyAnt project)
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> hijacking a thread.
>
> On Wed, 29 Oct 2008, Matt Benson
> <gu...@yahoo.com> wrote:
>
> > I see; however let me ask you this: which is more
> straightforward,
> > creating a custom ProjectHelper or extending
> Project and/or Target?
> > I guess the answer depends on how comfortable you
> are with the SAX
> > APIs.
>
> Who said I was using SAX? I'm not even using XML.
Touche. :)
> The main reason to
> write it is to show that Ant doesn't need XML at
> all.
>
> My "build file" is going to look like this (I'm
> making up half of it):
>
> @Project(Name="example", DefaultTarget="echo")
> public class BuildFile extends JavaFrontBuildFile {
> public BuildFile(Project p) {
> super(p);
> }
>
> @Target
> public void echo() {
> getProject().log("Hello world");
> }
>
> @Target(Name="-setproperty")
> public void setProperty() {
>
>
taskBuilder().newProperty().withName("world").andValue("world")
> .execute();
> }
>
> @Target(Depends="-setproperty")
> public void moreComplexExample() {
> taskBuilder().newEcho().withMessage("Hello
> ${world}").execute();
> }
> }
>
> My Target class extends Target and gets a Runnable
> in its constructor
> which is then run in execute() (it completely
> ignores nested tasks).
This looks like it's friends with my concept of an Ant
DSL except mine is pretty much just a de-XMLization of
the status quo, no OO stuff as you show above. But
there's no telling when I'll get around to finishing
that. :(
Okay, what say we move the Project instantiation to
ProjectHelper then, so that custom ProjectHelpers can
influence the Project class used if needed? This
still doesn't alleviate the problem that EasyAnt will
need a little custom configuration to install the
ProjectHelper and, probably, an Executor. But these
are both handled with system properties, so this could
either be done with hook scripts or an EasyAnt Main
class that calls Ant Main after setting the necessary
properties.
-Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> 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
ProjectHelper (was Re: EasyAnt project)
Posted by Stefan Bodewig <bo...@apache.org>.
hijacking a thread.
On Wed, 29 Oct 2008, Matt Benson <gu...@yahoo.com> wrote:
> I see; however let me ask you this: which is more straightforward,
> creating a custom ProjectHelper or extending Project and/or Target?
> I guess the answer depends on how comfortable you are with the SAX
> APIs.
Who said I was using SAX? I'm not even using XML. The main reason to
write it is to show that Ant doesn't need XML at all.
My "build file" is going to look like this (I'm making up half of it):
@Project(Name="example", DefaultTarget="echo")
public class BuildFile extends JavaFrontBuildFile {
public BuildFile(Project p) {
super(p);
}
@Target
public void echo() {
getProject().log("Hello world");
}
@Target(Name="-setproperty")
public void setProperty() {
taskBuilder().newProperty().withName("world").andValue("world")
.execute();
}
@Target(Depends="-setproperty")
public void moreComplexExample() {
taskBuilder().newEcho().withMessage("Hello ${world}").execute();
}
}
My Target class extends Target and gets a Runnable in its constructor
which is then run in execute() (it completely ignores nested tasks).
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt project
Posted by Matt Benson <gu...@yahoo.com>.
--- Stefan Bodewig <bo...@apache.org> wrote:
> On Wed, 29 Oct 2008, Matt Benson
> <gu...@yahoo.com> wrote:
>
> > I am thinking a less invasive approach would be:
>
> Sounds good to me.
>
> > 1. Allow arbitrary properties of a Target object
> to
> > be set using IntrospectionHelper.
> > 2. Delegate Target instantiation to Project.
>
> Why?
Precedent. The Project instance is responsible for
creating its own subproject Project instances; this
seemed similar.
>
> I have a toy project that I hope to be pushing into
> the sandbox sooner
> or later which contains a custom ProjectHelper. It
> heavly relies on
> the ProjectHelper to be able to create its own
> subclass of target.
>
I see; however let me ask you this: which is more
straightforward, creating a custom ProjectHelper or
extending Project and/or Target? I guess the answer
depends on how comfortable you are with the SAX APIs.
Personally, for me, it's the latter. Without tipping
your hand, can you give any more information about
what requirements drove you to implement your custom
ProjectHelper?
> > 3. Define an ant.project.class magic property to
> > easily allow the user to specify an extended
> Project
> > class to use.
> > 4. EasyAnt has its own Project, Target, and
> Executor
> > implementations that know about phases.
>
> If EasyAnt used a ProjectHelper of its own, it
> probably could get away
> without a custom Project. A custom Executor may be
> a good idea,
> though.
>
> EasyAnt would need its own wrapper script or an
> invocation would
> become cumbersome, though.
How is a custom Project class(name) more cumbersome to
configure than a custom ProjectHelper?
br,
Matt
>
> Stefan
>
>
---------------------------------------------------------------------
> 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: EasyAnt project
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 29 Oct 2008, Matt Benson <gu...@yahoo.com> wrote:
> I am thinking a less invasive approach would be:
Sounds good to me.
> 1. Allow arbitrary properties of a Target object to
> be set using IntrospectionHelper.
> 2. Delegate Target instantiation to Project.
Why?
I have a toy project that I hope to be pushing into the sandbox sooner
or later which contains a custom ProjectHelper. It heavly relies on
the ProjectHelper to be able to create its own subclass of target.
> 3. Define an ant.project.class magic property to
> easily allow the user to specify an extended Project
> class to use.
> 4. EasyAnt has its own Project, Target, and Executor
> implementations that know about phases.
If EasyAnt used a ProjectHelper of its own, it probably could get away
without a custom Project. A custom Executor may be a good idea,
though.
EasyAnt would need its own wrapper script or an invocation would
become cumbersome, though.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt project
Posted by Matt Benson <gu...@yahoo.com>.
--- Xavier Hanin <xa...@gmail.com> wrote:
> On Wed, Oct 29, 2008 at 6:30 AM, Stefan Bodewig
> <bo...@apache.org> wrote:
>
> > On Tue, 28 Oct 2008, Dominique Devienne
> <dd...@gmail.com> wrote:
> >
> > > Your example would read just as well, if not
> better, written as
> > > <target name="foo" group="bar"
> depends="...">...</target>.
> >
> > I agree. I think part of the reason for the name
> "phase" is that it
> > is used to create a concept similar to Maven
> phases in EasyAnt.
> > Still, we should choose names that make sense
> inside Ant IMHO.
>
> I like the target-group name too, and I don't think
> it's a problem for the
> EasyAnt project to use this name instead of phase.
I am thinking a less invasive approach would be:
1. Allow arbitrary properties of a Target object to
be set using IntrospectionHelper.
2. Delegate Target instantiation to Project.
3. Define an ant.project.class magic property to
easily allow the user to specify an extended Project
class to use.
4. EasyAnt has its own Project, Target, and Executor
implementations that know about phases.
-Matt
>
> Xavier
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt project
Posted by Xavier Hanin <xa...@gmail.com>.
On Wed, Oct 29, 2008 at 6:30 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On Tue, 28 Oct 2008, Dominique Devienne <dd...@gmail.com> wrote:
>
> > Your example would read just as well, if not better, written as
> > <target name="foo" group="bar" depends="...">...</target>.
>
> I agree. I think part of the reason for the name "phase" is that it
> is used to create a concept similar to Maven phases in EasyAnt.
> Still, we should choose names that make sense inside Ant IMHO.
I like the target-group name too, and I don't think it's a problem for the
EasyAnt project to use this name instead of phase.
Xavier
Re: EasyAnt project
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 28 Oct 2008, Dominique Devienne <dd...@gmail.com> wrote:
> Your example would read just as well, if not better, written as
> <target name="foo" group="bar" depends="...">...</target>.
I agree. I think part of the reason for the name "phase" is that it
is used to create a concept similar to Maven phases in EasyAnt.
Still, we should choose names that make sense inside Ant IMHO.
> When I argue what I believe is the right way to do something, and my
> point is being dismissed in favor of a lesser design (at least to
> me), this typically leaves me frustrated.
I don't think you are alone with this.
> Stefan "remue le couteau dans la plaie"
Since my son who started learning french this term is asleep, I used
one of those online translators. In German we sprinkle salt into open
wounds, less violent.
Actually I was calling you up for support (which worked ;-) and didn't
mean to hurt. Jean-Louis wasn't aware of the context, my fault.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt project
Posted by Dominique Devienne <dd...@gmail.com>.
On Tue, Oct 28, 2008 at 10:38 AM, Jean-Louis BOUDART
<je...@gmail.com> wrote:
> 2008/10/27 Stefan Bodewig <bo...@apache.org>
>> I'm not good at names. I understand why this is a good name in the
>> context of EasyAnt but struggle with the same name when applied to
>> "pure" Ant.
>>
>> I recall being confused by the phase mapping when Xavier first
>> suggested it.
> By typing ant checkstyle-report you only generate checkstyle report.
> By typing ant javadoc you only generate javadoc report.
> By typing ant report you generate ALL targets related to the report phase.
>
> This allow you more modularity than creating a target like :
> <target name="report" depends="javadoc,checkstyle-report"/>
>
> Is it more clear?
FWIW, I'm not fond of the "phase" name either. What you describe is
better described as a target-group, with any target being able to join
the group at will, and where there's no implicit intra-group
dependencies, and no "body" to the target-group (i.e. the group is
"abstract" in a way).
Your example would read just as well, if not better, written as
<target name="foo" group="bar" depends="...">...</target>.
Just as you seem to propose, I'd be in favor of requiring your <phase>
or my <target-group> to be explicitly declared before it can be
referenced. This would avoid typos implicitly creating groups
unbeknown to the build writer / fat fingered individual ;-)
I think the notion of target-group is more self-explicit than the phase one.
>> > - introduce two different kind of import (what we call use /
>> > extends)
>>
>> I think you will quickly find support for this separation here, in
>> particular if we throw in user definded prefixes where the writer of
>> the build file that uses another build file gets to define the prefix
>> of targets - hi, DD ;-)
>
> I really not understand what you mean here :'(
Just Stefan pocking gentle fun at me, because I vehemently argued for
what you propose when import was introduced. If you look back at the
archives, I was strongly against using the import*ed* build file name
in the import*er*, as it needlessly coupled the two, when good
compartmentalization is essential to flexible and scalable designs (I
even proposed the ability of the import*er* to give its own prefix as
well). I also argued for separate import/include, just like in XSLT.
In both cases my objections were ignored. So it's interesting that a
separate group of Frenchmen now wants these same changes in Ant.
When I argue what I believe is the right way to do something, and my
point is being dismissed in favor of a lesser design (at least to me),
this typically leaves me frustrated. Stefan "remue le couteau dans la
plaie" comme on dit chez nous ;-) --DD
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt project
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 28 Oct 2008, Jean-Louis BOUDART <je...@gmail.com> wrote:
> 2008/10/27 Stefan Bodewig <bo...@apache.org>
>
>> > - introduce "phase" concept : A kind of target that contains
>> > *ONLY*dependencies,
>>
>> I'm not good at names. I understand why this is a good name in the
>> context of EasyAnt but struggle with the same name when applied to
>> "pure" Ant.
>>
>> I recall being confused by the phase mapping when Xavier first
>> suggested it.
>
> We can use write java classes without using abstract classes /
> interface and all that stuff? :p Phase is like an "abstract task" it
> doesn't introduce order in your build script but introduce a kind of
> "comportement"
I did understand your phase concept, don't worry. The phase mapping
is something different (where you add a task that says "the phase I
call compile is called build in that imported file"), I think that one
is over flexible, but unrelated to the phase itself.
BTW, targets (and your phase variant of it) are not tasks.
I like Dominique's target group more than the name "phase". And I
understand that EasyAnt builds on the Maven concept to make things
easier for users switching. Without EasyAnt, the name would be a bad
choice inside Ant.
>> > - introduce two different kind of import (what we call use /
>> > extends)
>>
>> I think you will quickly find support for this separation here, in
>> particular if we throw in user definded prefixes where the writer
>> of the build file that uses another build file gets to define the
>> prefix of targets - hi, DD ;-)
>
> I really not understand what you mean here :'(
forget the last part, which Dominique himself tried to explain and
I'll clarify again.
What I wanted to say is that there have been Ant committers, namely
Dominique, who argued for some features of your extends/use
distinction long ago, so I expect that adding them to Ant will be an
easy sell.
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt project
Posted by Jean-Louis BOUDART <je...@gmail.com>.
2008/10/27 Stefan Bodewig <bo...@apache.org>
> I've given in and used my googlemail account for the easyant group,
> grmbl.
Nice :)
"Google 1 vs Stefan Bodewig 0
Round 2... Fight !"
>
> I'll look through the patch and will comment/start new threads for
> them later (maybe more than just a bit later).
>
> Since you are using Ant's trunk anyway, if we decide to add parts of
> the patch or a similar patch to achieve the same, you could modifiy
> your patch and required baseline of ant, right?
No problem.
>
>
> > - introduce "phase" concept : A kind of target that contains
> > *ONLY*dependencies,
>
> I'm not good at names. I understand why this is a good name in the
> context of EasyAnt but struggle with the same name when applied to
> "pure" Ant.
>
> I recall being confused by the phase mapping when Xavier first
> suggested it.
We can use write java classes without using abstract classes / interface and
all that stuff? :p
Phase is like an "abstract task" it doesn't introduce order in your build
script but introduce a kind of "comportement"
Exemple:
<phase name="report" description="generate reports related to your
project"/>
<target name="javadoc" depends="whatever" phase="report">
....
</target>
<target name="checstyle-report" depends="checkstyle,whatever"
phase="report">
...
</target>
By typing ant checkstyle-report you only generate checkstyle report.
By typing ant javadoc you only generate javadoc report.
By typing ant report you generate ALL targets related to the report phase.
This allow you more modularity than creating a target like :
<target name="report" depends="javadoc,checkstyle-report"/>
Is it more clear?
> > - introduce two different kind of import (what we call use /
> > extends)
>
> I think you will quickly find support for this separation here, in
> particular if we throw in user definded prefixes where the writer of
> the build file that uses another build file gets to define the prefix
> of targets - hi, DD ;-)
I really not understand what you mean here :'(
>
>
> > - modify project-help to display phases separated from targets
>
> If the concept of a phase is different from that of a "plain" target,
> then it deserve its own logging, agreed.
>
> Cheers
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: EasyAnt project
Posted by Stefan Bodewig <bo...@apache.org>.
I've given in and used my googlemail account for the easyant group,
grmbl.
On Wed, 22 Oct 2008, Jean-Louis BOUDART <je...@gmail.com> wrote:
I'll look through the patch and will comment/start new threads for
them later (maybe more than just a bit later).
Since you are using Ant's trunk anyway, if we decide to add parts of
the patch or a similar patch to achieve the same, you could modifiy
your patch and required baseline of ant, right?
> - introduce "phase" concept : A kind of target that contains
> *ONLY*dependencies,
I'm not good at names. I understand why this is a good name in the
context of EasyAnt but struggle with the same name when applied to
"pure" Ant.
I recall being confused by the phase mapping when Xavier first
suggested it.
> - introduce two different kind of import (what we call use /
> extends)
I think you will quickly find support for this separation here, in
particular if we throw in user definded prefixes where the writer of
the build file that uses another build file gets to define the prefix
of targets - hi, DD ;-)
> - modify project-help to display phases separated from targets
If the concept of a phase is different from that of a "plain" target,
then it deserve its own logging, agreed.
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: EasyAnt project
Posted by Jean-Louis BOUDART <je...@gmail.com>.
Thanks for your support.
We've made a patch of ant-core to introduce some concept used by easyant.
This patch :
- introduce "phase" concept : A kind of target that contains
*ONLY*dependencies, useful to make build modules easily reusable in a
standard
build (more infos at http://easyant.abrm.info/trac/wiki/tasks/phase )
- introduce two different kind of import (what we call use / extends) :
- import extends : Equivalents to the current import task (The
terminology "import" could thus be used either for "extends" or
"use", each
being a subclass of import.) (more infos at
http://easyant.abrm.info/trac/wiki/tasks/extends )
- use : A way to import ant file using "namespace" ( more infos at
http://easyant.abrm.info/trac/wiki/tasks/use )
- modify project-help to display phases separated from targets (We'd need
to make the help more helpful, by classifying targets, or hiding some of
them maybe with different levels of help => not yet implemented)
You can see this patch at
http://easyant.abrm.info/trac/browser/trunk/src/main/patches/ant-697121-easyant-patch.diff
Feel free to give us a feedback on our patch or on EasyAnt.
Regards,
Jean Louis Boudart
2008/10/21 Stefan Bodewig <bo...@apache.org>
> On Fri, 17 Oct 2008, Jean-Louis BOUDART <je...@gmail.com>
> wrote:
>
> > Easyant is a toolbox focusing on easing project build processes.
> > It's based on Apache Ant and Apache Ivy, and allows for maximum
> > flexibily, improved integration in existing build systems and
> > provides conventions and guidelines.
>
> Cool.
>
> If you need changes in Ant's core to make things easier, not only
> Xavier is a committer but you can be sure you'll find support on this
> list.
>
> > A google group is accessible here
> > http://groups.google.com/group/easyant
>
> I'm trying to subscribe right now, but I've always been too dumb to
> work with googlegoups' interface (I do not want to use my gmail
> account as the address to subscribe with) - I usually figure it out
> after a few failed attempts 8-)
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
>
>
Re: EasyAnt project
Posted by Jérôme BENOIS <je...@benois.fr>.
Hi,
A few months ago, I studied the excellent EasyAnt POC of Xavier.
I am really happy to see that this project is officially born, Long
life to EasyAnt!
I subcribe now!
Cheers,
Jérôme.
On Tue, Oct 21, 2008 at 6:27 AM, Stefan Bodewig <bo...@apache.org> wrote:
> On Fri, 17 Oct 2008, Jean-Louis BOUDART <je...@gmail.com> wrote:
>
>> Easyant is a toolbox focusing on easing project build processes.
>> It's based on Apache Ant and Apache Ivy, and allows for maximum
>> flexibily, improved integration in existing build systems and
>> provides conventions and guidelines.
>
> Cool.
>
> If you need changes in Ant's core to make things easier, not only
> Xavier is a committer but you can be sure you'll find support on this
> list.
>
>> A google group is accessible here
>> http://groups.google.com/group/easyant
>
> I'm trying to subscribe right now, but I've always been too dumb to
> work with googlegoups' interface (I do not want to use my gmail
> account as the address to subscribe with) - I usually figure it out
> after a few failed attempts 8-)
>
> Stefan
>
Re: EasyAnt project
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 17 Oct 2008, Jean-Louis BOUDART <je...@gmail.com> wrote:
> Easyant is a toolbox focusing on easing project build processes.
> It's based on Apache Ant and Apache Ivy, and allows for maximum
> flexibily, improved integration in existing build systems and
> provides conventions and guidelines.
Cool.
If you need changes in Ant's core to make things easier, not only
Xavier is a committer but you can be sure you'll find support on this
list.
> A google group is accessible here
> http://groups.google.com/group/easyant
I'm trying to subscribe right now, but I've always been too dumb to
work with googlegoups' interface (I do not want to use my gmail
account as the address to subscribe with) - I usually figure it out
after a few failed attempts 8-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org