You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Henri Yandell <ba...@generationjava.com> on 2002/06/21 20:12:40 UTC
unmavenising Commons projects
Currently we have 10 mavenised projects [to my tallying].
commons:
cli
configuration
email
graph2
jelly
net
util
xo
commons-sandbox:
betwixt
cli
I'm concerned that these changes happened to the build.xml files making
those projects require Maven. I'd like to suggest that we restore the old
build.xml and add a build-maven.xml file as is suggested in the Maven
documentation.
Or that we just roll these build.xml's back and use a script like the
maven2 script.
Hen
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: unmavenising Commons projects
Posted by Henri Yandell <ba...@generationjava.com>.
I'm not suggesting taking maven away, just unmavenising the build.xml's
which have no need to be mavenised and create a major versionning issue
for us.
I don't think the reaction is too late btw :) Most commons projects are
still on the old system. It was only when I started to mavenise Lang that
I realised that there is no real structure as to how we're planning to add
maven to the Commons packages.
I'm currently using the CVS Head for Maven and that is not backward
compatible with the project.xml's that Commons is using, so I'm pretty
sure that Maven-b5 will not accept any of the Commons projects.
Hen
On 21 Jun 2002, Martin van den Bemt wrote:
> -1
>
> If you really want the old stuff back, I prefer a build-legacy.xml or
> something like that..
> Maven is giving me (and probably others) too much benefits in regards to
> maintainance and feedback, that it will be a big step backward for us.
> Maybe it's an idea to create a plugin for maven that can generate a
> legacy build.xml file on the fly..
> And another note : your reaction is a bit late too...
>
> Mvgr,
> Martin
>
> On Fri, 2002-06-21 at 20:12, Henri Yandell wrote:
> > Currently we have 10 mavenised projects [to my tallying].
> >
> > commons:
> >
> > cli
> > configuration
> > email
> > graph2
> > jelly
> > net
> > util
> > xo
> >
> > commons-sandbox:
> >
> > betwixt
> > cli
> >
> > I'm concerned that these changes happened to the build.xml files making
> > those projects require Maven. I'd like to suggest that we restore the old
> > build.xml and add a build-maven.xml file as is suggested in the Maven
> > documentation.
> >
> > Or that we just roll these build.xml's back and use a script like the
> > maven2 script.
> >
> > Hen
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: unmavenising Commons projects
Posted by Martin van den Bemt <ml...@mvdb.net>.
-1
If you really want the old stuff back, I prefer a build-legacy.xml or
something like that..
Maven is giving me (and probably others) too much benefits in regards to
maintainance and feedback, that it will be a big step backward for us.
Maybe it's an idea to create a plugin for maven that can generate a
legacy build.xml file on the fly..
And another note : your reaction is a bit late too...
Mvgr,
Martin
On Fri, 2002-06-21 at 20:12, Henri Yandell wrote:
> Currently we have 10 mavenised projects [to my tallying].
>
> commons:
>
> cli
> configuration
> email
> graph2
> jelly
> net
> util
> xo
>
> commons-sandbox:
>
> betwixt
> cli
>
> I'm concerned that these changes happened to the build.xml files making
> those projects require Maven. I'd like to suggest that we restore the old
> build.xml and add a build-maven.xml file as is suggested in the Maven
> documentation.
>
> Or that we just roll these build.xml's back and use a script like the
> maven2 script.
>
> Hen
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: unmavenising Commons projects
Posted by co...@covalent.net.
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: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: unmavenising Commons projects
Posted by Jason van Zyl <ja...@zenplex.com>.
On Sat, 2002-06-22 at 17:13, costinm@covalent.net wrote:
> On 21 Jun 2002, Jason van Zyl wrote:
>
> > If we are going to do that then we should also specify a standard which
> > is the point of Maven: to unify the build process. Commons components
>
> I don't think you can 'unify' the build process by forcing everyone to
> use a single style and stop using 'legacy' ant. Even with all the problems
> it has, gump shows very clearly that it is possible to create an unified
> build process where each project can keep it's own style.
Listen man, I haven't tried to force anyone to use Maven. Every project
in the commons that is now using Maven I either explicitly asked to
change the build system so there was a consensus, or the committers for
the component changed it themselves. I did not cry for a mass conversion
because I think that it will happen on its own as it has. I have
certainly nudged people but if Maven didn't provide something valuable
people wouldn't have switched their projects willingly.
> I don't think I'll use maven to build projects until it is at least
> at the same level with gump.
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
to build something with Gump is a nightmare and I have first hand,
extended, long and drawn out experience. Having Gump be used for a
backward compatibility testing tool run by Sam is a very different thing
then a normal mortal being able to build anything with Gump. The former
is highly useful and has been an effective tool for Sam to find problems
with particular projects, for the latter I believe it's effectively
useless. Two very different things.
> If you can make Maven to use the existing build.xml files ( which
> shouldn't be very difficult, if Gump can do it with shell and xslt ) -
> I'll switch to maven. If you can support the gump project descriptors,
> then all jakarta will be buit with maven, and I don't think anyone
> could complain
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
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.
> 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.
> 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.
>
> This has nothing to do with the subject of this thread - which is
> the requirement to discuss and vote on major changes, like deprecating
> the ant build file ( which happened in commons ).
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.
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.
>
> Costin
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: unmavenising Commons projects
Posted by co...@covalent.net.
On 21 Jun 2002, Jason van Zyl wrote:
> If we are going to do that then we should also specify a standard which
> is the point of Maven: to unify the build process. Commons components
I don't think you can 'unify' the build process by forcing everyone to
use a single style and stop using 'legacy' ant. Even with all the problems
it has, gump shows very clearly that it is possible to create an unified
build process where each project can keep it's own style.
I don't think I'll use maven to build projects until it is at least
at the same level with gump.
If you can make Maven to use the existing build.xml files ( which
shouldn't be very difficult, if Gump can do it with shell and xslt ) -
I'll switch to maven. If you can support the gump project descriptors,
then all jakarta will be buit with maven, and I don't think anyone
could complain.
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. 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.
This has nothing to do with the subject of this thread - which is
the requirement to discuss and vote on major changes, like deprecating
the ant build file ( which happened in commons ).
Costin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: unmavenising Commons projects
Posted by Jason van Zyl <ja...@zenplex.com>.
On Fri, 2002-06-21 at 15:46, costinm@covalent.net wrote:
> I think it's a good idea.
As I mentioned in a previous email the next version of Maven won't
require a build.xml file to be present and I have no problem with there
being a legacy build system.
> I see no problem with supporting maven ( or centipede, or anything else ),
> but I'm strongly -1 on requiring any of them to build a commons
> component.
>
> That's an official veto for any component I'm a commiter on.
> I can live with a build-maven.xml and a build-centipede.xml, as long as
> build.xml remains and can be used to build.
>
> Ant is the build system we use, if someone wants to use something
> else - that's fine ( including maven or Makefiles ).
>
> I personally think this should be the official policy for the whole
> jakarta-commons project, given the fact that many projects are using
> those components.
If we are going to do that then we should also specify a standard which
is the point of Maven: to unify the build process. Commons components
have a bunch of different build systems and it's very annoying for
various people trying to build things. So if we are going to have a
policy then we should settle on a standard ant build file format. This
way, at least for projects using Maven, a standard ant build system can
be generated.
If this is the commons and the baseline is Ant and you want a policy
then it's time to pick a format for the build files because having
different configuration mechanisms for different components is just as
bad, IMO, as using Maven in some places, Centipede in others and
straight Ant build files in others.
> Costin
>
>
> On Fri, 21 Jun 2002, Henri Yandell wrote:
>
> > Currently we have 10 mavenised projects [to my tallying].
> >
> > commons:
> >
> > cli
> > configuration
> > email
> > graph2
> > jelly
> > net
> > util
> > xo
> >
> > commons-sandbox:
> >
> > betwixt
> > cli
> >
> > I'm concerned that these changes happened to the build.xml files making
> > those projects require Maven. I'd like to suggest that we restore the old
> > build.xml and add a build-maven.xml file as is suggested in the Maven
> > documentation.
> >
> > Or that we just roll these build.xml's back and use a script like the
> > maven2 script.
> >
> > Hen
> >
> >
> > --
> > To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
> >
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
--
jvz.
Jason van Zyl
jason@apache.org
http://tambora.zenplex.org
In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
-- Jacques Ellul, The Technological Society
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: unmavenising Commons projects
Posted by Nicola Ken Barozzi <ni...@apache.org>.
costinm@covalent.net wrote:
> I think it's a good idea.
>
> I see no problem with supporting maven ( or centipede, or anything else ),
> but I'm strongly -1 on requiring any of them to build a commons
> component.
>
> That's an official veto for any component I'm a commiter on.
> I can live with a build-maven.xml and a build-centipede.xml, as long as
> build.xml remains and can be used to build.
>
> Ant is the build system we use, if someone wants to use something
> else - that's fine ( including maven or Makefiles ).
>
> I personally think this should be the official policy for the whole
> jakarta-commons project, given the fact that many projects are using
> those components.
Personally I see two types of commons-sanbox stuff: would be
projects, and real "commons" stuff.
Limiting my POV on the "commons" stuff I think that the best thing is
that every project uses the build system it likes but also keeps a
build.xml ant file that has "clean" "compile" and "jar" tragets.
Just to be able to compile the code, it shouldn't be hard.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: unmavenising Commons projects
Posted by co...@covalent.net.
I think it's a good idea.
I see no problem with supporting maven ( or centipede, or anything else ),
but I'm strongly -1 on requiring any of them to build a commons
component.
That's an official veto for any component I'm a commiter on.
I can live with a build-maven.xml and a build-centipede.xml, as long as
build.xml remains and can be used to build.
Ant is the build system we use, if someone wants to use something
else - that's fine ( including maven or Makefiles ).
I personally think this should be the official policy for the whole
jakarta-commons project, given the fact that many projects are using
those components.
Costin
On Fri, 21 Jun 2002, Henri Yandell wrote:
> Currently we have 10 mavenised projects [to my tallying].
>
> commons:
>
> cli
> configuration
> email
> graph2
> jelly
> net
> util
> xo
>
> commons-sandbox:
>
> betwixt
> cli
>
> I'm concerned that these changes happened to the build.xml files making
> those projects require Maven. I'd like to suggest that we restore the old
> build.xml and add a build-maven.xml file as is suggested in the Maven
> documentation.
>
> Or that we just roll these build.xml's back and use a script like the
> maven2 script.
>
> Hen
>
>
> --
> To unsubscribe, e-mail: <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: unmavenising Commons projects
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 6/21/02 2:12 PM, "Henri Yandell" <ba...@generationjava.com> wrote:
> Currently we have 10 mavenised projects [to my tallying].
>
> commons:
>
> cli
> configuration
> email
> graph2
> jelly
> net
> util
> xo
>
> commons-sandbox:
>
> betwixt
> cli
Don¹t forget jexl!
:)
--
Geir Magnusson Jr.
Research & Development, Adeptra Inc.
geirm@adeptra.com
+1-203-247-1713
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>