commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From d...@multitask.com.au
Subject Re: unmavenising Commons projects
Date Sat, 22 Jun 2002 07:03:29 GMT
Henri,

I'm happy to help keep Commons up to date. The hassle from my perspective 
is there doesn't seem to be a 'team' working on a lot of commons to talk 
to.

e.g. I made some changes to io recently in the sandbox and asked for some 
details on a new release, but so far I've heard nothing.

I'm happy to take Jon's position and have commons rely only on released 
versions of maven as well. Also, I think Commons has some requirements 
that will drive development of Maven, too.
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers



Henri Yandell <bayard@generationjava.com>
06/22/02 03:39 PM
Please respond to "Jakarta Commons Developers List"


To
Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
cc

bcc

Subject
Re: unmavenising Commons projects



I'm on a different point of view than costin. I'm +1 using Maven, but a
mad rush to mavenise all of Commons without structure is going to hurt.

To answer costin first:

Maven is just another build tool. Why not use it instead of ant in the
end? Given the great quality of documentation that Maven has, I think it's
going to be a lot easier for a cvs-user to use than ant currently is.
It took me ages to get to the point of having ANT_HOME defined and knowing
to always put junit.jar in my ant-lib directory and to get optional jar
etc. Maven blows that away. Let's seriously consider a Mavenised Commons.

Mavenising a project is stunningly easy once you get into it. A small
group of committers can mavenise Commons very easily. In fact, one of the
most annoying parts of Maven at the moment is the build.xml file, which is
hopefully going away. [I'm sure Jason or someone will correct me on any
Maven mistakes I make, I'm not an Maven project member]

Replacing the current Commons website with a Maven generated site is a
delicious concept. It's so easy. It will be even easier.

To answer those who are pro going straight to maven right now:

Maven is not ready. There are going to be big versionning issues. It moves
at an amazing pace and is changing a lot. I think Commons needs to get in
on Maven now and look to replace the website, look to replace the build
and look to give Commons some much needed structure. Commons is a great
shop window for Maven.
But Commons should not make itself wholly dependant on Maven. That is far
too bleeding edge. If Maven slows, or enters a redesign period, Commons
exists in a limbo waiting for a complete redesign, tied to Maven. Maven
versions are not backwards compatible, only one version can run per user
[without some major sneaking], and doesn't have versionned documentation
yet. And it shouldn't have, it's still at a pre-project sandbox stage,
despite the high speed and professionalism. We will quite soon reach a
point where parts of Commons need Maven b3, parts need Maven b4 but kinda
run in b5, and parts need b5.

I'm sure it's not acceptable for me to make the Codec project work only
under Ant 1.5 Beta 2. We're going to be doing the same with Maven.

I'm sounding like a broken record...

Hen



On 21 Jun 2002, John McNally wrote:

> > I have a problem with forcing people to use Maven ( or any other 
similar
> > tool ), at least for tasks where ant can do a perfectly fine job,
> > and compiling some java to a jar is one of them.
> >
> > Especially in commons - where the goal is to have the components 
shared
> > and co-developed by all jakarta.
> >
>
> One of the things I find annoying whenever I want to build a new jakarta
> project is to track down where all the dependencies are specified, and
> fiddling with the build properties or build.xml directly to get the
> dependencies to match up with where I have some of the dependencies and
> then tracking down and downloading the rest.  And its pretty much
> guaranteed that if I downloaded the released binary version, the build
> system will be set up out of the box to use the source distribution or
> vice versa.
>
> It takes about as much time to install maven for the first time as to do
> this for one project/component.  And then I am fairly confident that if
> I try to build another mavenized project, I check out the source and
> type 'ant' or 'ant jar', it is going to build without any of the
> previously mentioned hassles.
>
> So I think the more components that switch to maven the better.  That is
> why I am arguing that components be allowed to switch in a way that is
> as easy as possible.  And requiring a component to maintain dual build
> systems past the point where the developers on the project are
> comfortable with the new system is not going to help adoption.
> Hopefully something can be worked out with maven generating the
> build.xml.
>
> john mcnally
>
>
> --
> To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>




--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message