commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cost...@covalent.net
Subject Re: unmavenising Commons projects
Date Sat, 22 Jun 2002 17:02:08 GMT
On Sat, 22 Jun 2002, Geir Magnusson Jr. wrote:

> > This is not about using maven of Makefiles - it is about having the
> > common sense of making a proposal and discussing it.
> > 
> > I can't believe this is happening - and in commons of all places !
> 
> Are you joking?  I am totally not surprised that it's happening in commons.
> It's one of the 'benefits' of the governance model.

:-) 
Geir enjoying the "I told you so" moment :-)

I don't know how a different model would have prevented that - 
I don't follow the development of those components, so I couldn't
have spoted the changes in any model. 

And we can still vote -1 on the release of any component that doesn't
have a working build.xml, with the current model. Or if I need
 one of the components - I can get involved and add/maintain the 
build.xmls that I need. 


> I don't think we should be *required* to wait for a 1.0 release, as that's
> somewhat arbitrary anyway. (Just like I don't think we should be *required*
> to use Maven - I choose to use Maven.)

+1

We can use any version of Maven - but releasing a component that can't be 
built without maven and requires maven beta3  doesn't sound very
right. And if that component is used by few projects ( as we all hope will
happen ) - that's even worse.

If maven is optional ( i.e. a tool for those who need it, and the build
can go on without maven) - then 1.0 doesn't matter. 

> I think there are lots of nice things about Maven.  I also think there are

+1

As I said, I'm +1 on adding a build-maven.xml on any project I'm a 
commiter, as long as it is optional and doesn't brake the existing 
build.xml. 

If some projects decide ( by vote ) they don't want to maintain a 
separate build.xml but generate it ( with whatever tool ) - that's also 
fine.

If maven can't deal with having other build systems around  ( like a 
custom build.xml ) - that's a maven problem. 

Costin

> lots of nice things about ant-based builds.  I intend to keep both in Jexl
> and Velocity, so I can take advantage of the features of Maven yet still
> keep the speed, control and universality of the ant approach.    Not
> everyone wants to use Maven - for example, for those that want to do
> deployments via ant to lots of production boxes (I have met such people)
> then the overhead of maven won't be appealing.
> 
> I think that the best thing Maven could do is standardize on a
> build-maven.xml file, and produce a build.xml for ant, but of course, that's
> an argument for the Maven list.
> 
> 


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