Gilles Scokart wrote:
>
> You should maybe have a look to buildr.
>
I did, and also raven, guilder, gant, gradle, graven and more. The thing is,
Ant is the de-facto standard, with the largest community. If we want to
finally have a system that is easy to understand and yet can build JEE
projec
Dominique Devienne-2 wrote:
>
> But while I agree that having a true scripting language for Ant would
> help (OO, prototype-based, or functional, leaning towards the latter
> for Ant myself), I think it's important to remember than good builds
> are *declarative* in nature. Using a pure language
2008/4/30 Ittay Dror <[EMAIL PROTECTED]>:
>
> I've read this thread and would like to maybe try and take this discussion
> elsewhere.
>
> The way I see it is that Ant and Maven came to being in order to simplify
> building projects. The philosophy (as I see it) was either "create an xml
> file
On Wed, Apr 30, 2008 at 1:19 AM, Ittay Dror <[EMAIL PROTECTED]> wrote:
> The root of this is, I think, because while dealing with all this build
> logic, both frameworks refused to embrace the principals behind OOP. Both
> obviously need a backing language to actually do things and have chosen
>
I've read this thread and would like to maybe try and take this discussion
elsewhere.
The way I see it is that Ant and Maven came to being in order to simplify
building projects. The philosophy (as I see it) was either "create an xml
file with a few lines calling some tasks" or "create an xml wit
A year ago I started implemented something with similar ideas. The idea
is to describe your module metadata in a separate file and provide
ant tasks to process that data. It supports multi-module builds and
it also supports fetching dependencies from maven repositories.
A module might be describ
On Feb 11, 2008 8:35 PM, limbicsystem <[EMAIL PROTECTED]> wrote:
>
> What Xavier is describing is exactly what I thought Maven should have
> been- a
> standard way to lay out projects, with Ant underneath to use as needed.
> And
> once your projects become non-trivial there is always the "as need
2008/2/11, limbicsystem <[EMAIL PROTECTED]>:
>
>
> We spent a long painful month trying to move from Maven1 to Maven2, and
> ultimately gave up. We quickly grew tired of trying to write plugins to
> handle things that would have othewise been 5 lines of Ant (or things that
> worked in M1 but no lo
What Xavier is describing is exactly what I thought Maven should have been- a
standard way to lay out projects, with Ant underneath to use as needed. And
once your projects become non-trivial there is always the "as needed" part.
We spent a long painful month trying to move from Maven1 to Mave
Dominique Devienne wrote:
On 1/16/08, Gilles Scokart <[EMAIL PROTECTED]> wrote:
I was just saying that Ant benefits/(or suffer...) from great flexibility,
and you should not change that. [...]
I agree with Xavier, control in large build system is a very desirable
feature, if only to fo
On 1/16/08, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> I was just saying that Ant benefits/(or suffer...) from great flexibility,
> and you should not change that. [...]
I agree with Xavier, control in large build system is a very desirable
feature, if only to force developers to talk to the buil
think it is not possible with a language
like ant.
Gilles
> -Original Message-
> From: Xavier Hanin [mailto:[EMAIL PROTECTED]
> Sent: mercredi 16 janvier 2008 9:53
> To: Ant Developers List
> Subject: Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
On Jan 16, 2008 8:54 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> 2008/1/15, Louis Tribble <[EMAIL PROTECTED]>:
> >
> > Dominique Devienne wrote:
> > > On 1/15/08, Louis Tribble <[EMAIL PROTECTED]> wrote:
> > >
> > >> Consequently, my main comment (apologies if I missed it in the
> thread)
> >
2008/1/15, Louis Tribble <[EMAIL PROTECTED]>:
>
> Dominique Devienne wrote:
> > On 1/15/08, Louis Tribble <[EMAIL PROTECTED]> wrote:
> >
> >> Consequently, my main comment (apologies if I missed it in the thread)
> >> is that any magic target overriding feature needs to balanced by
> >> a target lo
Dominique Devienne wrote:
On 1/15/08, Louis Tribble <[EMAIL PROTECTED]> wrote:
Consequently, my main comment (apologies if I missed it in the thread)
is that any magic target overriding feature needs to balanced by
a target locking feature, for at least two reasons: (1) the integrity of
the
b
On 1/15/08, Louis Tribble <[EMAIL PROTECTED]> wrote:
> Consequently, my main comment (apologies if I missed it in the thread)
> is that any magic target overriding feature needs to balanced by
> a target locking feature, for at least two reasons: (1) the integrity of
> the
> build depends on certai
On Jan 15, 2008 7:39 PM, Louis Tribble <[EMAIL PROTECTED]> wrote:
> We have a scheme like some that have been mentioned,
> in which the system is broken into modules and building the
> system means looping through the modules applying the
> same build script to each. The build of each module is
>
We have a scheme like some that have been mentioned,
in which the system is broken into modules and building the
system means looping through the modules applying the
same build script to each. The build of each module is
broken down into phases, e.g., assemble, compile,
create-jar, test, etc (tha
By the way, a truly generic build script will probably have to support 2 level
of customization/extension.
The first one being an enterprise level, and the second one being at project
level.
Gilles
-
To unsubscribe, e-mail:
On 1/14/08, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> If our base build file contains a compile target and several "plugins"
> that I want to use need to do stuff before the compile target then we
> need a way to have a defined order. In the order my build file
> requires the plugins, I guess.
"Gilles Scokart" <[EMAIL PROTECTED]> writes:
> An other thing to specify with before is its position relatively to the
> dependencies of the 'extended' taget.
>
> Do we place the before really just before the target itself, or before the
> dependencies of the target?
Just before the target itself
On Jan 15, 2008 9:00 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> An other thing to specify with before is its position relatively to the
> dependencies of the 'extended' taget.
>
> Do we place the before really just before the target itself, or before the
> dependencies of the target?
IMO it
2008/1/14, Dominique Devienne <[EMAIL PROTECTED]>:
>
> On 1/14/08, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > "Dominique Devienne" <[EMAIL PROTECTED]> writes:
> > Having something like before/after/around advices (where around is the
> > same as an override that doesn't change the dependencies l
On Jan 15, 2008 6:31 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> "Peter Reilly" <[EMAIL PROTECTED]> writes:
>
> > I would say that if the build file does not specify the order, then the
> order
> > is undefined.
> >
> > If the order is important, then the build file can enforce an order by
> >
An other thing to specify with before is its position relatively to the
dependencies of the 'extended' taget.
Do we place the before really just before the target itself, or before the
dependencies of the target?
The second aproach is currently possible from the script that want to extend
an impo
On Jan 14, 2008 9:37 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> On Jan 14, 2008 6:39 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> > Q1: Does everyone agree that adding before/after to target to Ant 1.8
> > is useful and should be done before (in conjunction of) creating
> > generic build
"Markus M. May" <[EMAIL PROTECTED]> writes:
> I definitly do like the before/after approach, but the already
> suggested depends usage will add another step of complexity.
Not sure which part of the depends uage you mean.
When overriding a target we generally have two different use cases
a) I w
"Peter Reilly" <[EMAIL PROTECTED]> writes:
> I would say that if the build file does not specify the order, then the order
> is undefined.
>
> If the order is important, then the build file can enforce an order by
> using "depends".
>
>
>
>
One thing we are not taking into accou
Wolfgang Häfelinger <[EMAIL PROTECTED]> writes:
> Why not simply:
>
>
>
>
>
>
>
>
>
>
>
>
>
> If a user then really need to override "foo", he or she would simply
> write in build.xml something like
>
>
>
>
> before original foo ..
>
>
"Dominique Devienne" <[EMAIL PROTECTED]> writes:
> On 1/14/08, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> "Dominique Devienne" <[EMAIL PROTECTED]> writes:
>> Having something like before/after/around advices (where around is the
>> same as an override that doesn't change the dependencies list) m
> > > > Assume also:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Do you want this before your "start-server" or after it or
> > > > in parallel?
> > > >
> > >
> > > I would say that if the build file does not specify the order,
> > > then the order is undefined.
maybe document o
On Jan 14, 2008 6:39 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On 1/14/08, Peter Reilly <[EMAIL PROTECTED]> wrote:
> > On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]>
> wrote:
> > > Assume also:
> > >
> > >
> > >
> > >
> > >
> > > Do you want this before y
Hello,
I have build a large automatic and generic build system using ANT.
This build system got very complex, especially due to dependencies.
I definitly do like the before/after approach, but the already
suggested depends usage will add another step of complexity.
Furthermore, up until now, I t
On 1/14/08, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > Q1: Does everyone agree that adding before/after to target to Ant 1.8
> > is useful and should be done before (in conjunction of) creating
> > generic build files?
>
> could you please explain why you see a need for target attributes "b
lt;[EMAIL PROTECTED]>
14-01-2008 18:39
Please respond to
"Ant Developers List"
To
"Ant Developers List"
cc
Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
On 1/14/08, Peter Reilly <[EMAIL PROTECTED]> wrote:
> On Ja
On Jan 14, 2008 5:39 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On 1/14/08, Peter Reilly <[EMAIL PROTECTED]> wrote:
> > On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > > Assume also:
> > >
> > >
> > >
> > >
> > >
> > > Do you want this before your
d to
"Ant Developers List"
To
"Ant Developers List"
cc
Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
On 1/14/08, Peter Reilly <[EMAIL PROTECTED]> wrote:
> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]>
On 1/14/08, Peter Reilly <[EMAIL PROTECTED]> wrote:
> On Jan 14, 2008 5:02 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > Assume also:
> >
> >
> >
> >
> >
> > Do you want this before your "start-server" or after it or
> > in parallel?
> >
>
> I would say that if the build fil
inger
> > Research & Architecture | Dir. 2.7.0.2
> > European Patent Office
> > Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
> > Tel. +31 (0)70 340 4931
> > [EMAIL PROTECTED]
> > http://www.epo.org
> >
> >
> >
> >
> >
01-2008 17:52
>
> Please respond to
> "Ant Developers List"
>
>
> To
> "Ant Developers List"
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
> Why not have
nt Office
Patentlaan 3-9 | 2288 EE Rijswijk | The Netherlands
Tel. +31 (0)70 340 4931
[EMAIL PROTECTED]
http://www.epo.org
"Peter Reilly" <[EMAIL PROTECTED]>
14-01-2008 17:52
Please respond to
"Ant Developers List"
To
"Ant Developers List"
cc
Subject
Re: [DI
On 1/14/08, Peter Reilly <[EMAIL PROTECTED]> wrote:
> Why not have something simple like having a "before" and "after" attributes to
> the element.
This is indeed something we discussed and proposed earlier in the
thread. (except I envisioned the before/after to be used instead of
the name attrib
Why not have something simple like having a "before" and "after" attributes to
the element.
...
Peter
On Jan 14, 2008 4:35 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > So every concrete simple target like became
> >
> >
> > ...
> >
>
On Jan 14, 2008 5:35 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> > So every concrete simple target like became
> >
> >
> > ...
> >
> >
>
> This looks pretty ugly this me!
If I understand correctly, that's exactly what Dominique complained about
:-)
>
>
> I believe that this whole
> So every concrete simple target like became
>
>
> ...
>
>
This looks pretty ugly this me!
I believe that this whole discussion focusses too much on targets
instead of macros. Macros are a very powerfull feature and they
deserve much more attention!
Why not simply:
On 1/14/08, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> "Dominique Devienne" <[EMAIL PROTECTED]> writes:
> Having something like before/after/around advices (where around is the
> same as an override that doesn't change the dependencies list) may
> suffice and leave overwriting the whole target def
"Dominique Devienne" <[EMAIL PROTECTED]> writes:
> On Jan 11, 2008 8:11 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
>> "Gilles Scokart" <[EMAIL PROTECTED]> writes:
>>
>> > I never thought to overwrite macro to customize a generic build script.
>> > Can
>> > macro be overwritten?
>>
>> Sure, it
On Jan 11, 2008 6:35 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> "Xavier Hanin" <[EMAIL PROTECTED]> writes:
>
> > But in my mind I was more thinking about a build system based on
> > current Ant feature set and syntax,
>
> Which probably would lead to a more complex system than it needed to
>
On Jan 11, 2008 9:55 AM, Gilles Scokart <[EMAIL PROTECTED]> wrote:
> 2008/1/10, Dominique Devienne <[EMAIL PROTECTED]>:
> >
> >
> > it was successful enough to still be in use today more than 2 years
> > after I'm gone, mostly untouched.
> >
> >
> I think this is very usual. Once a build system i
On Jan 11, 2008 5:40 PM, Peter Arrenbrecht <[EMAIL PROTECTED]>
wrote:
> [...]
> That is correct. However, being able to do it still beats not being
> able to. It allows for a better balancing of accommodating yet another
> esoteric hook request and making the template yet more complex vs.
> just t
On Jan 11, 2008 5:14 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008 8:11 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > "Gilles Scokart" <[EMAIL PROTECTED]> writes:
> >
> > > I never thought to overwrite macro to customize a generic build
> script. Can
> > > macro be overw
Please unsubscribe me from the following list.
- Original Message
From: Peter Arrenbrecht <[EMAIL PROTECTED]>
To: Ant Developers List
Sent: Friday, January 11, 2008 10:40:40 AM
Subject: Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
On Jan 11,
On Jan 11, 2008 5:14 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Jan 11, 2008 8:11 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> > "Gilles Scokart" <[EMAIL PROTECTED]> writes:
> >
> > > I never thought to overwrite macro to customize a generic build script.
> > > Can
> > > macro be o
On Jan 11, 2008 8:11 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:
> "Gilles Scokart" <[EMAIL PROTECTED]> writes:
>
> > I never thought to overwrite macro to customize a generic build script. Can
> > macro be overwritten?
>
> Sure, it's just another Ant task that has been defined.
But my point is
"Gilles Scokart" <[EMAIL PROTECTED]> writes:
> I never thought to overwrite macro to customize a generic build script. Can
> macro be overwritten?
Sure, it's just another Ant task that has been defined.
Stefan
-
To unsubscribe
I never thought to overwrite macro to customize a generic build script. Can
macro be overwritten?
2008/1/10, Wolfgang Häfelinger <[EMAIL PROTECTED]>:
>
> >> it is certainly something that already exists in the wild. Does it?
>
> It's called AntEpoline and lives currently in The Netherlands,
>
2008/1/10, Dominique Devienne <[EMAIL PROTECTED]>:
>
>
> it was successful enough to still be in use today more than 2 years
> after I'm gone, mostly untouched.
>
>
I think this is very usual. Once a build system is ok, no-one want to take
the risk to change it, and often no-one can change it anym
On Jan 10, 2008 9:13 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <[EMAIL PROTECTED]>
> wrote:
>
> > Providing
> > override hooks is all well and good, but that is still basically the
> > very controlled and rigit maven approach, I think.
> It depends on
On Jan 10, 2008 9:33 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Jan 10, 2008 2:13 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <[EMAIL PROTECTED]>
> > > Providing
> > > override hooks is all well and good, but that is still basically the
> >
"Xavier Hanin" <[EMAIL PROTECTED]> writes:
> But in my mind I was more thinking about a build system based on
> current Ant feature set and syntax,
Which probably would lead to a more complex system than it needed to
be without such a restriction.
Dominique's or something similar was among the
"Xavier Hanin" <[EMAIL PROTECTED]> writes:
> On Jan 10, 2008 10:20 PM, Bruce Atherton <[EMAIL PROTECTED]> wrote:
>
>> There used to be a project called Centipede that built Ant scripts
>> into something called "cents", which were attempts to capture best
>> practices for various parts of builds.
--- Xavier Hanin <[EMAIL PROTECTED]> wrote:
> On Jan 10, 2008 9:33 PM, Dominique Devienne
> <[EMAIL PROTECTED]> wrote:
>
> > On Jan 10, 2008 2:13 PM, Xavier Hanin
> <[EMAIL PROTECTED]> wrote:
> > > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht
> <[EMAIL PROTECTED]>
> > > > Providing
> > > > overrid
On Jan 10, 2008 10:21 PM, kermitt <[EMAIL PROTECTED]> 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, thi
On Jan 10, 2008 10:20 PM, Bruce Atherton <[EMAIL PROTECTED]> wrote:
> Gilles Scokart wrote:
> > Finally, I stopped my reflections, thinking that it is certainly
> something that already exists in the wild. Does it?
> If I remember correctly (it was a long time ago) it used to. There used
> to be
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.
I read your idea about interceptor I think it could be a good idea but as
you said
Gilles Scokart wrote:
Finally, I stopped my reflections, thinking that it is certainly something that
already exists in the wild. Does it?
If I remember correctly (it was a long time ago) it used to. There used
to be a project called Centipede that built Ant scripts into something
called "cen
On Jan 10, 2008 9:33 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Jan 10, 2008 2:13 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> > On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <[EMAIL PROTECTED]>
> > > Providing
> > > override hooks is all well and good, but that is still basically the
>
On Jan 10, 2008 2:13 PM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <[EMAIL PROTECTED]>
> > Providing
> > override hooks is all well and good, but that is still basically the
> > very controlled and rigit maven approach, I think.
>
> It depends on what you
On Jan 10, 2008 8:16 PM, kermitt <[EMAIL PROTECTED]> 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 jus
On Jan 10, 2008 7:21 PM, Peter Arrenbrecht <[EMAIL PROTECTED]>
wrote:
> I like the idea very much. One crucial aspect, however, would be to
> provide a graceful path from using the prepackaged building blocks
> towards inlining and customizing them. If this is not possible, the
> thing will most l
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
I like the idea very much. One crucial aspect, however, would be to
provide a graceful path from using the prepackaged building blocks
towards inlining and customizing them. If this is not possible, the
thing will most likely start feeling as unwieldy as maven itself in a
while. The advantage of an
4
> Please respond to
> "Ant Developers List"
>
>
> To
> "Ant Developers List"
> cc
>
> Subject
> Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
>
>
>
>
>
> On Jan 10, 2008 5:29 PM, Wolfgang
quot;Ant Developers List"
To
"Ant Developers List"
cc
Subject
Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
On Jan 10, 2008 5:29 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> >> it is certainly something that already exists in
On Jan 10, 2008 5:29 PM, Wolfgang Häfelinger <[EMAIL PROTECTED]> wrote:
> >> it is certainly something that already exists in the wild. Does it?
>
> It's called AntEpoline and lives currently in The Netherlands,
> especially here at the EPO in The Hague.
Is it open source or proprietary? Any li
On Jan 10, 2008 5:13 PM, Dominique Devienne <[EMAIL PROTECTED]> wrote:
> On Jan 10, 2008 8:25 AM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> > So, what do you think? Do you think this would be useful? Would you be
> > interested in contributing? Do you think a new Ant sub project would be
> a
> > g
;
10-01-2008 17:03
Please respond to
"Ant Developers List"
To
"'Ant Developers List'"
cc
Subject
RE: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
projects
I already thinked to something similar as well (after having re-written a
few
On Jan 10, 2008 4:12 PM, Matt Benson <[EMAIL PROTECTED]> wrote:
> Xavier:
> I think it would be good to have a system that
> pretty much bundles alternatives for everything Maven
> provides, but without all the black magic that makes
> Maven difficult to customize. Basically antlibs for
> all pa
lles
>
> > -Original Message-
> > From: Matt Benson [mailto:[EMAIL PROTECTED]
> > Sent: jeudi 10 janvier 2008 16:12
> > To: Ant Developers List
> > Subject: Re: [DISCUSS] EasyAnt: Ant based pre packaged build system for
> java projects
> >
> >
On Jan 10, 2008 8:25 AM, Xavier Hanin <[EMAIL PROTECTED]> wrote:
> So, what do you think? Do you think this would be useful? Would you be
> interested in contributing? Do you think a new Ant sub project would be a
> good fit?
I too like Ant, and in the past worked full time on doing ad-hoc
builds
e: [DISCUSS] EasyAnt: Ant based pre packaged build system for java
> projects
>
> Xavier:
> I think it would be good to have a system that
> pretty much bundles alternatives for everything Maven
> provides, but without all the black magic that makes
> Maven difficult to customize.
Xavier:
I think it would be good to have a system that
pretty much bundles alternatives for everything Maven
provides, but without all the black magic that makes
Maven difficult to customize. Basically antlibs for
all parts of the Maven lifecycle, including,
especially, Ivy. :) In fact, I alre
Hi,
It's been a long time since I'm thinking about this, and thought it might be
interesting to share with you and see where the idea can go.
I see many developers adopt Maven because they want a build system able to
provide common features with no effort. Most of them don't want to spend
much ti
83 matches
Mail list logo
