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 04:59:25 GMT
Costin,

Maven builds on ant, so the existing build process is an 'ant-based 
build'.
--
dIon Gillard, Multitask Consulting
Work:      http://www.multitask.com.au
Developers: http://adslgateway.multitask.com.au/developers



costinm@covalent.net
06/22/02 09:50 AM
Please respond to "Jakarta Commons Developers List"


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

bcc

Subject
Re: unmavenising Commons projects



On 21 Jun 2002, John McNally wrote:

> I'm pretty sure you are aware of this, but the usual method of voting on
> changes of this kind (modifying build, source, or documentation files)
> is done by viewing the changes as they occur and -1 the changes.

It is a common practice that important changes - like adding a new 
dependency to a project - are first proposed.

This is not a simple code change ( commit-then-review ), it's actually 
a change in the component definition ( most commons components define
what their dependencies are explicitely ).

I would expect droping support for ant-based build will also be proposed
explicitely.


> Your choice to force projects where you are a committer to keep a
> build.xml file that does not require maven is fine by me.  And it would
> be up to the other committers who work on the projects to eventually
> persuade you to drop the old system when they feel the new system is
> adequate.  Hopefully, if you were the only committer on a project who
> wanted to maintain a legacy system, you would take on the task of
> keeping it up-to-date.
> 
> Since each component in commons maintains its own build system I don't
> see why it should be a general concern at which point the committers on
> that component decide to quit maintaining a dual build system.


The goal of commons is to create software that is shared ( in both 
development and use ) by jakarata projects, and I think it is against
the goals of jakarta-commons to create this kind of fragmentation
in the build system. Ant is the common standard for all jakarta projects.
If you also want a maven, centipede, Makefiles/configure or whatever
else - fine, but removing the ant build is wrong IMHO.
If a project can't easily build a commons component - it's likley
it'll not use it. 

As I said, I can't influence projects where I'm not a commiter, 
but on those where I am I intend to make sure ant can be used to
build the project and all the components we require.


Costin


> 
> > 
> > > > We do have a requirement minimising external dependencies, and 
> > > > the commons components must be built and used by people who use 
> > > > a variety of build systems. 
> > > 
> > > The requirement minimizing external dependencies is useful for users 
of
> > > the components.  Whether a component is built using maven or 
directly
> > > using ant does not affect whether the component can be used within a
> > > larger project.
> > 
> > It does - people working on a project should be able to build easily 
> > all the components from commons they are using. Don't forget those
> > components are shared by all projects - we all use them and maintain 
> > them. 
> > 
> 
> Users of commons components would be best served by using released
> versions.
> 
> > 
> > > Your requirement that any component wanting to use a standardized 
build
> > > system also keep a freestyle version that must be kept up-to-date
> > > removes the benefit of using the standardized version.  Keeping two
> > > build systems that must be maintained separately is not a reasonable
> > > compromise.
> > 
> > There are projects that maintain both Makefile and ant, and I don't
> > think it's unreasonable. 
> > 
> 
> Its not unreasonable to maintain both.  But it is unreasonable to force
> a project maintain both.
> 
> 
> 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