dependencymanagement and releaseplugin

[Ian Boston <ie...@tfd.co.uk>]

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

I am happy to do a patch, and I don't think it would change the  
structure of the build, but it might reduce the volume of XML in the  
child poms.

I am also happy to wait, or not do it if the core team don't want it.
Ian

Re: dependencymanagement and releaseplugin

[Michael Angerman <zr...@gmail.com>]

You make some excellent points and I would tend to agree with most of
them...

But the key point is this....

Everytime we test the build from scratch we have to blow away the maven
repository and start over pulling stuff down...

And I have been doing that for the past day -- blowing away the Maven
repository
and re-running the build from scratch (many, many) times...

I actually don't mind doing this -- because once things work they work and
the
rest of the world won't have to do this because we got this darn thing
working
and we are happy...

THIS IS WHAT SCARES ME !....

People who are working on other open source projects have ONE Maven
repository
and then things get exponential on the dependencies...

That is the part I just don't understand well..  The concept behind Maven is
to solve
this problem and that is great -- but try debugging something when you are
working
on three different open source projects and there is a dependency clash...

The only real practical solution from my thinking is to have ONE Maven
repository per
open source project -- and then try integrating the other ones -- one by one
-- but then
when something changes and you get a dependency clash in the future look
out...

ALSO -- in general -- there has not yet been enough work on how Eclipse and
Maven
interact -- we are just not there yet -- there are still some fundamental
issues that are
not really fixed on the whole interaction between Eclipse and Maven, then
when you
add in Jetty...

The bottom line is this, Maven is a really nice idea...  And if you can get
it to work
fantastic...  The great idea is...  There are NO JARS associated with a
project,
its all Maven magic which is cool...

The other approach is THIS...

Just use a pure Ant system -- have your JARS hard coded in with your
project,
and have the downloads be really big for people installing the
application...
By doing this you greatly simplify the whole Eclipse issue, cause Ant and
Eclipse
work really well together, whereas Maven adds MUCH complexity...

Bottom line is this...  These are hard problems to solve correctly, and I
don't really
believe anyone truly knows YET whether Maven is the way to go...

Good luck and have fun !!
Michael I Angerman

On Sat, Apr 26, 2008 at 4:08 AM, Santiago Gala <sa...@gmail.com>
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
>
> >
> > I am happy to do a patch, and I don't think it would change the
> > structure of the build, but it might reduce the volume of XML in the
> > child poms.
> >
> > I am also happy to wait, or not do it if the core team don't want it.
> > Ian
> >
>
> Go for it and save us from the pain. :)
>
> >
> >
> --
> Santiago Gala
> http://memojo.com/~sgala/blog/ <http://memojo.com/%7Esgala/blog/>
>
>

Re: dependencymanagement and releaseplugin

[Santiago Gala <sa...@gmail.com>]

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

> 
> I am happy to do a patch, and I don't think it would change the  
> structure of the build, but it might reduce the volume of XML in the  
> child poms.
> 
> I am also happy to wait, or not do it if the core team don't want it.
> Ian
> 

Go for it and save us from the pain. :)

> 
> 
-- 
Santiago Gala
http://memojo.com/~sgala/blog/

Re: dependencymanagement and releaseplugin

[Ian Boston <ie...@tfd.co.uk>]

Ok, I will have a go.
Ian



On 23 Apr 2008, at 17:56, Cassie wrote:

> Please make a patch!
> That would be fantastic. The xml sizes are driving me crazy but I  
> haven't
> had enough time to look into them in detail. Brian's bug was a good  
> attempt
> at removing some duplication but as you noted was slightly  
> different than
> what we should probably aim for. If you can just attach another  
> patch to
> that bug I think that would be great.
>
> Thanks.
>
> - Cassie
>
>
> On Wed, Apr 23, 2008 at 6:53 PM, Ian Boston <ie...@tfd.co.uk> wrote:
>
>> 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
>>
>> I am happy to do a patch, and I don't think it would change the  
>> structure
>> of the build, but it might reduce the volume of XML in the child  
>> poms.
>>
>> I am also happy to wait, or not do it if the core team don't want it.
>> Ian
>>
>>
>>
>>

Re: dependencymanagement and releaseplugin

[Cassie <do...@google.com>]

Please make a patch!
That would be fantastic. The xml sizes are driving me crazy but I haven't
had enough time to look into them in detail. Brian's bug was a good attempt
at removing some duplication but as you noted was slightly different than
what we should probably aim for. If you can just attach another patch to
that bug I think that would be great.

Thanks.

- Cassie


On Wed, Apr 23, 2008 at 6:53 PM, Ian Boston <ie...@tfd.co.uk> wrote:

> 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
>
> I am happy to do a patch, and I don't think it would change the structure
> of the build, but it might reduce the volume of XML in the child poms.
>
> I am also happy to wait, or not do it if the core team don't want it.
> Ian
>
>
>
>