Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Date: Sun, 23 Jun 2002 23:27:34 -0700 (PDT)
From: costinm@covalent.net
To: Jakarta Commons Developers List <commons-dev@jakarta.apache.org>
Subject: Re: unmavenising Commons projects
In-Reply-To: <1024881056.1517.32.camel@localhost.localdomain>
Message-ID: 
 <Pine.LNX.4.44.0206232223300.11573-100000@costinm.sfo.covalent.net>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On 23 Jun 2002, Jason van Zyl wrote:

> Listen man, I haven't tried to force anyone to use Maven. Every project

Jason, this is not about you or maven - it's about commons components 
 removing the ant files and adding dependencies  without anyone asking. 

If it would happen in tomcat, it would be very bad. In commons
it's much worse. 


> You ask you average user how easy it would be to build something with
> Gump versus Maven. I don't think there is any comparison there, trying

All I'm saying is that Gump proves it is technically possible to 
accomodate each project build file and style of tracking dependencies,
without any pain on the projects themself.

Gump is hard to use and the implementations is very bad - but 
it _can_ build the entire jakarta without changing a single 
file or 'deprecating' ant build files.

Nobody ever sugested that Gump would be used by a regular user - 
but I'm willing to wait for a easy to use tool that have the same
power as gump. 

And if Maven can't do it - it's clearly not the tool for me, it
doesn't solve my itches. And I don't think it's a right tool
for commons.
 

> That was never the primary goal. Maven showed it's first face as
> something like Gump because it was originally in the Alexandria
> repository but the primary goal of Maven was to provide something of
> value to an individual project. Starting from this I think real progress

Well, replacing the build.xml and the established conventions 
a project uses is not necesarily a 'value'. Gump may be ugly, but
it provides a value - without most people even knowing about
it. 

All apache ( java ) projects are 'gump'-ised, and we just had to
change some properties here and there.

> can be made toward inter-project efforts like Gump. Within Jakarta some
> projects maintain their own descriptors but most people don't even know
> what it is.

:-) I know how amazingly painfully it is, had few problems in tomcat. But 
it's a value we really need. 


> > As for 'common policy/style' for all commons packages - yes, it
> > would be nice, but so far we don't seem to have any agreement
> > on this. 
> 
> That IMO is a serious problem. Users having to build all the different
> components are confronted the 2-3 very different ways of building
> components which is silly for the 'commons'. I don't care what the
> build.xml format is but I think one should be chosen.

I think that too. But I have to accept that other people have different
tastes and other projects have different needs. 

I usually use a wrapper or just gump - I'm not happy about that, but
that's how things are.


> > And that's a pretty good sign that it's the build system
> > that should be able to adapt, instead of forcing everyone in
> > jakarta to adapt to a new build system. 
> 
> Maven isn't a build system like Gump. There is a tool that is being made
> called the Reactor that will be able to do things like Gump and it will
> deal with your typical build.xml file. Again, this wasn't the original
> goal for Maven.

Then why does it mess with the build.xml and the build process ?? When 
it can do builds and what gump does, we can discuss about using it 
to build commons components, tomcat, whatever. 

For all the other features  - if they are not too hard to use from a 
build.xml with ant and some taksdefs, I'll be happy to try and see them
in commons and all jakarta projects. 

Just don't try to present ant as 'legacy' and replace the build.xml
and the conventions we use with something else. 

> If the discussion is only to select Ant as the baseline and not
> selecting a build.xml format then the discussion is useless IMO because
> you're not solving any real user problem. The components are still a
> PITA to build.

I can't 'select' a build.xml format, and I don't think you or 
maven can, and I don't think it's even right. 

It is perfectly possible to use gump-like descriptors to wrap
any possible build.xml style and provide a consistent behavior
and build process. That's already proven.  


> If a build.xml file is going to be generated then I want to generate one
> that commons users are familiar with. There has never been any
> discussion of what the build system would be other than Ant which is too
> vague to be practically useful. I wish in the charter there had been a
> mandated build.xml file. I know that was the intention as all the
> original components had the same build system. One should have been
> picked and we should have used it. I've stated my opinion before but
> having myriad possibilities in the build system is detrimental. You want
> to build a JAR, who needs to be creative with a build.xml file. Nobody
> gives a shit, just make it work. That's all any of the users want and
> they don't have that now and just saying we are going to use ant with a
> build.xml file isn't going to make anything better.


Set some standard target names and rules in maven, and 
make build-maven.xml _wrap_ the original component's build.xml.
Then users can call maven and have the consistent build.

There is no standard way to write a makefile, and it'll never
be. Build systems like RPM are just adapting to the build
process, and so does gump. You can build almost any linux
package with 'rpm -ba', and you can build any jakarta project
with the gump's 'build.sh project-name'.

I can't believe it's impossible to implement the gump features
in a user-friendly way and with java instead of .bash. If Maven
can't do it, we'll just have to wait for something else.


Costin


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