commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: unmavenising Commons projects
Date Mon, 24 Jun 2002 02:31:13 GMT


On Mon, 24 Jun 2002 dion@multitask.com.au wrote:

> Date: Mon, 24 Jun 2002 10:12:38 +1000
> From: dion@multitask.com.au
> Reply-To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
> Subject: Re: unmavenising Commons projects
>
>
> Craig, just a few questions:
>
> Which of mavens 'conventions' do not fit your needs? FWIW, we have been
> getting 'outsiders' involved with maven and gathering requirements. I ask
> the question seriously, as this is the first time I've heard your concerns
> voiced, and I appreciate and respect your opinion. I know there's a lot
> that Maven doesn't currently do, and we need to ensure that most
> requirements are covered in some way.
>

Well, that's sort of my point ... nobody has told me what Maven's
conventions are :-).  Or asked me for my concerns until now (thanks for
doing that).  Sure, I can go look for myself, but it was rather
surprising to see Maven-based builds of Commons projects start popping up,
along with a general assumption that "everybody" should be doing it.

I have never been particularly comfortable with the general "lib.repo"
approach to gaining references to the JAR files for dependent projects--
having a "${user.home}/build.properties" file with the ability to override
on a per-project basis has proven to meet my needs pretty well.  Robust
support for JAR versioning in Maven would probably alleviate most of that
concern (and a lot of it's probably there already).  Just don't forget
that lots of projects have more than one JAR file :-).

I'm not particularly a fan of Velocity or DVSL syntax, but that isn't
usually a huge issue for the documentation developer.  I think the
approach of building nav bar links from an external project.xml file
(versus using XML entities to import the shared chunks into the pages that
need them) is ultimately going to prove limiting, but that is a low level
detail.

It's also not yet clear to me yet how the Maven approach would scale to
something much bigger than a Commons project, that produces something
larger than a JAR file, some JavaDocs, and a few HTML pages.
Undoubtedly, this is due to my unfamiliarity -- if you can build
Turbine-sized things with it, I should be able to use it for something
like Struts (post-Struts-1.1;  now is not the time to switch :-).

There is also Costin's concern at the other end of the project complexity
scale.  It shouldn't take a lot of muss and fuss to download the source of
your favorite Commons package and build it -- for example, it needs to be
simple to leave out the things Maven does that you don't care about, lest
it be considered overkill.

> I'm happy for you guys to wait for a 1.0 release of Maven. What it means is
> that Maven 1.0 will be out sooner rather than later, and that we'll have
> covered all the requirements that people have for reasonable acceptance.
>

The most important issue to me is the result of doing a thought experiment
of looking out about a year.  Inevitably, different projects using Maven
will create their source environments based on different Maven versions.
If we can gracefully deal with building projects using Maven 1.0, 1.1, and
1.2 all at the same time, Maven will likely quite popular .  If there is
going to be an explicit or implicit requirement that all projects have to
upgrade to the new Maven at the same time (which will never happen in the
real world), we're all going to grumble a lot.

> FWIW, I don't consider someone that doesn't use Maven stupid. There are
> quite valid reasons not to use Maven, but since Maven is changing, those
> reasons may disappear over time.
>
> A quick look about commons shows that the docs and consistency of the
> projects are very varied. This decreases adoption of the code. For example:
> - DBCP has no home page, javadocs etc. A casual glancer would write this
> code off as unusable.
> - The listing of sandbox components is incomplete
> - Commons home page still lists Cactus as a component
> etc. In short Commons and sandbox are a shambles.
>
> I'm not blaming anybody for these problems, as I'm a committer on Commons
> and could fix them myself. But rather than fix every project's shortcomings
> when they are so similar in needs, I've decided to help out on Maven.

The goals you guys are after are the right ones, and it looks like you've
put some good thought into meeting them.  But people resist feeling
imposed upon (not that you've done that personally), no matter how much
they are going to like it after they've submitted :-).

> --
> dIon Gillard, Multitask Consulting
> Work:      http://www.multitask.com.au
> Developers: http://adslgateway.multitask.com.au/developers
>

Craig


--
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