On Sun, Apr 27, 2008 at 8:28 PM, Ian Boston <[EMAIL PROTECTED]> wrote:
> With my normal hat on as a consumer of Apache projects, I would agree with
> this. Sakai, another open source project has about 73 base projects in the
> core, about 550 poms, and about 100 external jars, 1M lines of code. We
> started with Ant a long time ago, moved to Maven 1 and then Maven 2. We have
> between 50-70 active developers in the core and associated projects. There
> are some questions about the build on the list, but it is rare. I am certain
> we would be in a total mess without Maven.

Well, the linux kernel, glibc, the whole xorg stuff or even
OpenOffice.org, all project which I'm sure have greater complexity
than sakai, can do very well without maven. I'd say only the
windows/java culture, that doesn't really know about make & company,
thinks that there is no life outside ant/maven.

I'd even say that the fact that most java projects are that big in
terms of LOC and number of dependencies is a consequence of the
verbosity of java and the level code duplication that the "one file
per public class" causes.

>
>  Individual Apache projects are not this size, but as more apache projects
> have moved to Maven2, my life has become much easier. I don't have to add
> jars to our own maven repo any more, or manually work out the dependency
> tree. (this was starting to kill us in maven 1).
>

As the Flight of The Conchords say in "business time":  "two minutes
in heaven is better than one minute in heaven" ;-)
http://www.youtube.com/watch?v=WGOohBytKTU

>  When I last had to upgrade Jackrabbit for instance, all I did was change
> the version number in the dependencyManagement section of the base pom.
> After checking, I committed, and none of the 5 QA servers around the world
> noticed. Without the strong version management and transitive dependency
> resolution I would have to trawl through all the possible version collisions
> to check for incompatibilities on every version upgrade.
>
>  I know Maven2 is very Java focused, and when it doesn't work can be hard
> for the new comer to work out what is going on, but the doc is much better
> than it was 12 months ago.
>
>  So my vote ( I don't have one, but I will cast it anyway :) ), is to stick
> with Maven 2, and make the build work. I will happily help in that task...
> because its going to make my day job much much easier.
>
>  Just my 2p (£)
>  Ian
>

The reason why I'm bitching is not so much trying to get rid of maven
here but try to open the eyes and minds of "world is java" developers
to the fact that there is life outside java and that, increasingly as
the java ecosystem freezes and ossifies, life outside java is fresher
and evolving faster. No radical changes will work here, but to start
moving such a big inertia requires a high amount of thrust and bashing
;-) And it seems like pushing in this direction is the only healthy
behavior against lock-in, much like pushing for linux/BSD and against
windows was the way to go in from 1995 onwards. For the health of the
global computing environment. I might be wrong, of course.

Regards
Santiago

>
>
>
>
>  On 27 Apr 2008, at 18:04, Alexander Klimetschek wrote:
>
>
> > Hi,
> >
> > as someone new to this project but quite familiar with Maven (~2 years by
> now) I'd suggest to keep maven!
> >
> > I know Maven has its problems, is quite focused on the Java-world and only
> works properly if you do everything the Maven-way. But it always works in
> the end and IMHO it has these two killer-features:
> >
> > 1) standardizes the build process
> > 2) external dependency management / public artifact repositories
> >
> > Point 1 is very useful in Open-Source projects as new developers with
> experience from other projects can immediately understand the build process
> and directory layout. And maven seems to be standard at Apache by now.
> >
> > The second feature is most useful for all library-style projects that are
> embedded into other systems to build real applications. As all the libraries
> often share common libs (eg. XML parsers, commons-io, http-client etc.), the
> dependencies are automatically shared. And starting a project that uses the
> latest stable release of Shindig is simple, since you only have to add the
> reference to the shindig lib(s) once to the pom.xml and the rest is fetched
> automatically.
> >
> > Just my 2 cents...
> > Alex
> >
> > Am 26.04.2008 um 20:42 schrieb Michael Papp:
> >
> >
> > > +1 on Santiago's comments.  Given that this is a community project, the
> use
> > > of a tool such as Maven should be based on what works and general
> > > consensus.  I also would add that this should not be cast as a
> right/wrong,
> > > good/evil discussion.  The use of any tool adds value to a project only
> when
> > > it increases productivity and/or ease of use (in this case,
> > > download/build/install/run).  Maven does simplify fetching external
> > > resources (although this could be done in subversion as well) and
> managing
> > > dependencies.  OTOH, the current situation demonstrates that this tool
> only
> > > adds value when "everything is right" and can be impediment as a project
> > > changes/evolves.  As long as the interested parties to this effort feel
> that
> > > the current thrashing will not be repeated in a "business as usual"
> sense
> > > going forward, then Maven should be an acceptable tool for the project.
> If
> > > change is going to be constant (for the foreseeable future), and given
> > > Maven's inherent weaknesses, now is a good time to consider the
> alternatives
> > > and validate the belief that this tool can be managed effectively.
> > >
> > > Michael
> > >
> > > On Sat, Apr 26, 2008 at 4:08 AM, Santiago Gala <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > >
> > > > El mié, 23-04-2008 a las 17:53 +0100, Ian Boston escribió:
> > > >
> > > > > I was wondering after the recent rapid changes in the build, how
> much
> > > > > ' stomach ' people had for sorting out the dependency and plugin
> > > > > management in the build to bring it more inline with something like
> > > > > http://svn.apache.org/repos/asf/jackrabbit/trunk/pom.xm
> > > > >
> > > >
> > > > <rant>
> > > > I have vetoed maven in all the occasions I have had (and got ignored
> > > > most of the times just because it was "cool and what everyone was
> > > > using") because of several reasons:
> > > > - bad documentation and unstable/changing features/behaviors
> > > > - transparent download of "thingies" (I don't know or care what) that
> > > > makes it difficult to work offline without having to remember strange
> > > > switches
> > > > - transparent download of dependencies that makes it difficult to
> assess
> > > > dependencies (IMO an esencial part of Software Engineering, and
> > > > something that should never be abstracted away)
> > > > - very stateful under the hood (oh, you just remove the repository
> > > > directory / oh, you just reboot windows ...)
> > > > - a tool that uses "install" just for storing things for internal use
> is
> > > > crearly self-centered, not task or user centered
> > > > - extreme verbosity for useless information and silence about
> important
> > > > things, i.e., it talks a lot about what it does, but nothing about
> what
> > > > I do with it, something that always irritate me a lot.
> > > > - ugly XML and confusing declarative stuff, something shared with ant
> > > > - unnatural targets, where the default is always exactly what you
> don't
> > > > want (it remembers me wordperfect on this one)
> > > > - mostly always can't deal properly with dependencies, requiring
> "clean"
> > > > quite often
> > > > - it is very resource heavy, compare with make or ant
> > > > - it is written in java, a proprietary language with no legal OS
> > > > implementation that the ASF is having problems to turn into free
> > > > software because of nasty business practices (breach of contract) by
> Sun
> > > > Microsystems, and that I think will break in the same way as
> OpenSolaris
> > > > at the first governance conflict because of Sun's predatory practices
> of
> > > > late. This means that a pure free shindig install, using the PHP code
> > > > for the server, will still need to use java or duplicate the build
> > > > system.
> > > > </rant>
> > > >
> > > > I have been learning to tolerate it as a bare user, as "it is cool and
> > > > what everybody else uses" but I will never dig into it, use it in any
> > > > project where I can avoid it, or help making maven builds as a form of
> > > > civil resistance, much like when I abandoned windows for linux in
> 2000.
> > > >
> > > > So don't count on me on this one. I'll just use, and bitch about,
> > > > whatever other people sets there. :)
> > > >
> > > > So please, do it and make mvn the most invisible part of the project
> if
> > > > possible. :) Having like 70% of the resources of the project going to
> > > > trying to deal with maven for a couple of weeks just to do a simple
> > > > restructuring of the build system is wasteful.
> > > >
> > > > Regards
> > > > Santiago
> > > >
> > > >
> > >
> > > <[EMAIL PROTECTED]>
> > >
> >
> > --
> > Alexander Klimetschek
> > [EMAIL PROTECTED]
> >
> > >> Day JCR Cup 08 | Win a MacBook Pro: http://dev.day.com/ <<
> >
> >
> >
> >
> >
>
>

Reply via email to