My view on the relative merits of different ways to unpack jars into target/classes

[Stephen Connolly <st...@gmail.com>]

I think mailing lists are not the best way to explain why different
solutions are to be preferred when ranking against what is best for the
Maven ecosystem as a whole.

So I wrote a blog post to explain my views on what are good ways and what
are bad ways.

http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html

Hopefully people find this useful.

-Stephen

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Brian Fox <br...@infinity.nu>]

That's a good post to sum up all the options.

On Thu, Mar 21, 2013 at 8:15 AM, Stephen Connolly
<st...@gmail.com> wrote:
> I think mailing lists are not the best way to explain why different
> solutions are to be preferred when ranking against what is best for the
> Maven ecosystem as a whole.
>
> So I wrote a blog post to explain my views on what are good ways and what
> are bad ways.
>
> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
>
> Hopefully people find this useful.
>
> -Stephen

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Ron Wheeler <rw...@artifact-software.com>]

I guess that we will just have to explain that we will write it to them 
in a long series of annoying short cryptic messages if the don't read it 
themselves.

Ron

On 21/03/2013 1:33 PM, Wayne Fay wrote:
> Another +1 from me. This was quite a substantial amount of effort on
> your part Stephen!
>
>>> This should save a lot of mailing list traffic.
> Honestly not so sure about that. Unless you mean the reply traffic
> from the regulars on this list. :)
>
> And I'm slightly concerned that the people who NEED to read it will be
> put-off by the length, but don't see any easy way to trim it down
> without losing important content.
>
> Wayne
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Wayne Fay <wa...@gmail.com>]

Another +1 from me. This was quite a substantial amount of effort on
your part Stephen!

>> This should save a lot of mailing list traffic.

Honestly not so sure about that. Unless you mean the reply traffic
from the regulars on this list. :)

And I'm slightly concerned that the people who NEED to read it will be
put-off by the length, but don't see any easy way to trim it down
without losing important content.

Wayne

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Curtis Rueden <ct...@wisc.edu>]

Hi Stephen,

> This should save a lot of mailing list traffic.

I agree with Ron; thank you very much for writing that article.

I know some people don't like "+1" replies, but the article really is
excellent, and much appreciated.

Regards,
Curtis


On Thu, Mar 21, 2013 at 9:49 AM, Ron Wheeler <rwheeler@artifact-software.com
> wrote:

> Great idea.
> This should save a lot of mailing list traffic.
>
> Can you add this to the Maven site or if not add a link to you post?
>
> Ron
>
>
> On 21/03/2013 8:15 AM, Stephen Connolly wrote:
>
>> I think mailing lists are not the best way to explain why different
>> solutions are to be preferred when ranking against what is best for the
>> Maven ecosystem as a whole.
>>
>> So I wrote a blog post to explain my views on what are good ways and what
>> are bad ways.
>>
>> http://developer-blog.**cloudbees.com/2013/03/playing-**
>> trade-offs-with-maven.html<http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html>
>>
>> Hopefully people find this useful.
>>
>> -Stephen
>>
>>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Ron Wheeler <rw...@artifact-software.com>]

Great idea.
This should save a lot of mailing list traffic.

Can you add this to the Maven site or if not add a link to you post?

Ron

On 21/03/2013 8:15 AM, Stephen Connolly wrote:
> I think mailing lists are not the best way to explain why different
> solutions are to be preferred when ranking against what is best for the
> Maven ecosystem as a whole.
>
> So I wrote a blog post to explain my views on what are good ways and what
> are bad ways.
>
> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
>
> Hopefully people find this useful.
>
> -Stephen
>


-- 
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Tamás Cservenák <ta...@cservenak.net>]

+1 Nailed. It's not all black-or-white.


On Fri, Mar 22, 2013 at 10:19 AM, Stephen Connolly <
stephen.alan.connolly@gmail.com> wrote:

>
> Finally, putting them in your settings.xml allows reacting to repository
> location changes when building old builds, putting them in your pom.xml may
> mean that 1 year from now, checking out the tag will not build without
> modifying the pom.xml (or even worse, depending on the 1 year old version
> in a project your are building - you might want to verify a regression in
> behaviour for example - won't work because that version's pom.xml has
> invalid repository URLs)
>
> For all the above reasons, pushing OSS projects to central is the
> recommended practice, but getting them into any public Maven repository is
> better than not having them in a public Maven repository.
>
> TL;DR pushing open source projects to a repository other than Central (at
> least for the moment given how Maven works) is bad practice. Arguing over
> whether it is better to reference those other repositories from
> settings.xml or from pom.xml is very much like two fleas arguing over who
> will get squashed first when the building collapses and flattens the dog
> they live on ;-)
>
>

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Martin Hoeller <ma...@xss.co.at>]

On 22 Mär 2013, Stephen Connolly wrote:
> On 22 March 2013 08:12, Martin Höller <ma...@xss.co.at> wrote:
> 
> > Hi!
> >
> > On 21 Mär 2013, Stephen Connolly wrote:
> >
> > > I think mailing lists are not the best way to explain why different
> > > solutions are to be preferred when ranking against what is best for the
> > > Maven ecosystem as a whole.
> > >
> > > So I wrote a blog post to explain my views on what are good ways and what
> > > are bad ways.
> > >
> > >
> > http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
> >
> > Really good post, but... ;-)
> >
> > There is one thing that is IMHO not clearly (enough) stated in your post:
> > it is in general a bad idea to add repositories to your POMs [1].
> >
> > Section "2. Get the external jars into a public Maven repository" adds an
> > additional <repository> to the pom.xml. This is usually bad pratice and
> > should be avoided. Brian Fox wrote a detailed blog post [1] about this.
> >
> > Maybe you could link to this post and mentione, that putting the
> > additional repo in your settings.xml is an alternative.
> >
> 
> Well if you put them into your settings.xml, then those extra repositories
> are applied for *every single project that you build*
> 
> If you put them in your pom.xml, then those extra repositories are only
> applied for that project and *every single project that lists that project
> as a transitive dependency*

Good point.

> Also putting them in your settings.xml means you cannot just checkout and
> build, putting them in your pom.xml allows most others to just checkout and
> build (except for those of us behind a corporate proxy with a mandated
> <mirrorOf>*</mirrorOf>)

On the other hand putting them in pom.xml might bring you artifacts into
your build from this repo without one noticing they are not coming from
central.

But I have to admit, in the scenario described by your post the pom.xml
might be the better choice. However, a word of warning and a link to
Brian's post would not hurt and would hopefully further educate maven
users.

best regards,
- martin

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Stephen Connolly <st...@gmail.com>]

On 22 March 2013 08:12, Martin Höller <ma...@xss.co.at> wrote:

> Hi!
>
> On 21 Mär 2013, Stephen Connolly wrote:
>
> > I think mailing lists are not the best way to explain why different
> > solutions are to be preferred when ranking against what is best for the
> > Maven ecosystem as a whole.
> >
> > So I wrote a blog post to explain my views on what are good ways and what
> > are bad ways.
> >
> >
> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html
>
> Really good post, but... ;-)
>
> There is one thing that is IMHO not clearly (enough) stated in your post:
> it is in general a bad idea to add repositories to your POMs [1].
>
> Section "2. Get the external jars into a public Maven repository" adds an
> additional <repository> to the pom.xml. This is usually bad pratice and
> should be avoided. Brian Fox wrote a detailed blog post [1] about this.
>
> Maybe you could link to this post and mentione, that putting the
> additional repo in your settings.xml is an alternative.
>

Well if you put them into your settings.xml, then those extra repositories
are applied for *every single project that you build*

If you put them in your pom.xml, then those extra repositories are only
applied for that project and *every single project that lists that project
as a transitive dependency*

Also putting them in your settings.xml means you cannot just checkout and
build, putting them in your pom.xml allows most others to just checkout and
build (except for those of us behind a corporate proxy with a mandated
<mirrorOf>*</mirrorOf>)

Finally, putting them in your settings.xml allows reacting to repository
location changes when building old builds, putting them in your pom.xml may
mean that 1 year from now, checking out the tag will not build without
modifying the pom.xml (or even worse, depending on the 1 year old version
in a project your are building - you might want to verify a regression in
behaviour for example - won't work because that version's pom.xml has
invalid repository URLs)

For all the above reasons, pushing OSS projects to central is the
recommended practice, but getting them into any public Maven repository is
better than not having them in a public Maven repository.

TL;DR pushing open source projects to a repository other than Central (at
least for the moment given how Maven works) is bad practice. Arguing over
whether it is better to reference those other repositories from
settings.xml or from pom.xml is very much like two fleas arguing over who
will get squashed first when the building collapses and flattens the dog
they live on ;-)


>
> Thanks for your efforts for the maven community and hth,
> - martin
>
> [1]
> http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/
>

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Martin Höller <ma...@xss.co.at>]

Hi!

On 21 Mär 2013, Stephen Connolly wrote:

> I think mailing lists are not the best way to explain why different
> solutions are to be preferred when ranking against what is best for the
> Maven ecosystem as a whole.
> 
> So I wrote a blog post to explain my views on what are good ways and what
> are bad ways.
> 
> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-maven.html

Really good post, but... ;-)

There is one thing that is IMHO not clearly (enough) stated in your post:
it is in general a bad idea to add repositories to your POMs [1].

Section "2. Get the external jars into a public Maven repository" adds an
additional <repository> to the pom.xml. This is usually bad pratice and
should be avoided. Brian Fox wrote a detailed blog post [1] about this. 

Maybe you could link to this post and mentione, that putting the
additional repo in your settings.xml is an alternative.

Thanks for your efforts for the maven community and hth,
- martin

[1] http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Jörg Schaible <jo...@gmx.de>]

Stephen Connolly wrote:

> Jörg, Any better now?

Yep. Fine.

Cheers,
Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Stephen Connolly <st...@gmail.com>]

Jörg, Any better now?


On 21 March 2013 14:56, Jörg Schaible <jo...@gmx.de> wrote:

> Hi Stephen,
>
>
> Stephen Connolly wrote:
>
> > That is really just a different flavour of internal maven repository,
> i.e.
> > just one that does not give the proxying or performance benefits that a
> > MRM can give... perhaps you would feel more comfortable if I called it
> the
> > "file:///${basedir}" hack which is really really bad for the reasons I
> > cited.
>
> Definitely. Currently your article sounds as if any use of the file
> protocol
> would be bad.
>
> > With an absolute URI that does not include project mutable properties
> > (i.e. anything that is ${project.*} or ${basedir}) then that is just
> > really an internal maven repository... which is 2b in my post.
> >
> > And saying that, if you define the URI as
> > file:///${shared-fs-root}/maven-repo/ and then people just define the
> > shared-fs-root as a property in their settings.xml that works too... what
> > makes it a hack is when one is relying on ${basedir} being the directory
> > where the pom.xml is located and then relying on the repo being at a
> fixed
> > *relative* path to the pom.xml... which stops being true the minute that
> > the pom is resolved from the ~/.m2/repository/... cache and which can get
> > completely messed up when the effective list of repositories in play is
> > computed for downstream projects.
>
> No objection at all. If the file URL refers the current project location,
> it
> simply wreaks havoc.
>
> Cheers,
> Jörg
>
> >
> >
> > On 21 March 2013 14:24, Jörg Schaible <jo...@gmx.de> wrote:
> >
> >> Hi Stephen,
> >>
> >> Stephen Connolly wrote:
> >>
> >> > I think mailing lists are not the best way to explain why different
> >> > solutions are to be preferred when ranking against what is best for
> the
> >> > Maven ecosystem as a whole.
> >> >
> >> > So I wrote a blog post to explain my views on what are good ways and
> >> > what are bad ways.
> >> >
> >> > http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-
> >> maven.html
> >> >
> >> > Hopefully people find this useful.
> >>
> >> There's an additional option using a NAS/network share. Drawback:
> >> Everyone must set a URL to the repo in his own settings.xml, but there's
> >> nothing wrong to use file:/ in this case. No POMs got polluted and if
> you
> >> decide later to install a real MRM, all that has to be adjusted are the
> >> local settings.xml - but that applies to any case.
> >>
> >> - Jörg
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> >> For additional commands, e-mail: users-help@maven.apache.org
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Jörg Schaible <jo...@gmx.de>]

Hi Stephen,


Stephen Connolly wrote:

> That is really just a different flavour of internal maven repository, i.e.
> just one that does not give the proxying or performance benefits that a
> MRM can give... perhaps you would feel more comfortable if I called it the
> "file:///${basedir}" hack which is really really bad for the reasons I
> cited.

Definitely. Currently your article sounds as if any use of the file protocol 
would be bad.

> With an absolute URI that does not include project mutable properties
> (i.e. anything that is ${project.*} or ${basedir}) then that is just
> really an internal maven repository... which is 2b in my post.
> 
> And saying that, if you define the URI as
> file:///${shared-fs-root}/maven-repo/ and then people just define the
> shared-fs-root as a property in their settings.xml that works too... what
> makes it a hack is when one is relying on ${basedir} being the directory
> where the pom.xml is located and then relying on the repo being at a fixed
> *relative* path to the pom.xml... which stops being true the minute that
> the pom is resolved from the ~/.m2/repository/... cache and which can get
> completely messed up when the effective list of repositories in play is
> computed for downstream projects.

No objection at all. If the file URL refers the current project location, it 
simply wreaks havoc.

Cheers,
Jörg

> 
> 
> On 21 March 2013 14:24, Jörg Schaible <jo...@gmx.de> wrote:
> 
>> Hi Stephen,
>>
>> Stephen Connolly wrote:
>>
>> > I think mailing lists are not the best way to explain why different
>> > solutions are to be preferred when ranking against what is best for the
>> > Maven ecosystem as a whole.
>> >
>> > So I wrote a blog post to explain my views on what are good ways and
>> > what are bad ways.
>> >
>> > http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-
>> maven.html
>> >
>> > Hopefully people find this useful.
>>
>> There's an additional option using a NAS/network share. Drawback:
>> Everyone must set a URL to the repo in his own settings.xml, but there's
>> nothing wrong to use file:/ in this case. No POMs got polluted and if you
>> decide later to install a real MRM, all that has to be adjusted are the
>> local settings.xml - but that applies to any case.
>>
>> - Jörg
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>>



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Stephen Connolly <st...@gmail.com>]

That is really just a different flavour of internal maven repository, i.e.
just one that does not give the proxying or performance benefits that a MRM
can give... perhaps you would feel more comfortable if I called it the
"file:///${basedir}" hack which is really really bad for the reasons I
cited.

With an absolute URI that does not include project mutable properties (i.e.
anything that is ${project.*} or ${basedir}) then that is just really an
internal maven repository... which is 2b in my post.

And saying that, if you define the URI as
file:///${shared-fs-root}/maven-repo/ and then people just define the
shared-fs-root as a property in their settings.xml that works too... what
makes it a hack is when one is relying on ${basedir} being the directory
where the pom.xml is located and then relying on the repo being at a fixed
*relative* path to the pom.xml... which stops being true the minute that
the pom is resolved from the ~/.m2/repository/... cache and which can get
completely messed up when the effective list of repositories in play is
computed for downstream projects.


On 21 March 2013 14:24, Jörg Schaible <jo...@gmx.de> wrote:

> Hi Stephen,
>
> Stephen Connolly wrote:
>
> > I think mailing lists are not the best way to explain why different
> > solutions are to be preferred when ranking against what is best for the
> > Maven ecosystem as a whole.
> >
> > So I wrote a blog post to explain my views on what are good ways and what
> > are bad ways.
> >
> > http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-
> maven.html
> >
> > Hopefully people find this useful.
>
> There's an additional option using a NAS/network share. Drawback: Everyone
> must set a URL to the repo in his own settings.xml, but there's nothing
> wrong to use file:/ in this case. No POMs got polluted and if you decide
> later to install a real MRM, all that has to be adjusted are the local
> settings.xml - but that applies to any case.
>
> - Jörg
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Re: My view on the relative merits of different ways to unpack jars into target/classes

[Jörg Schaible <jo...@gmx.de>]

Hi Stephen,

Stephen Connolly wrote:

> I think mailing lists are not the best way to explain why different
> solutions are to be preferred when ranking against what is best for the
> Maven ecosystem as a whole.
> 
> So I wrote a blog post to explain my views on what are good ways and what
> are bad ways.
> 
> http://developer-blog.cloudbees.com/2013/03/playing-trade-offs-with-
maven.html
> 
> Hopefully people find this useful.

There's an additional option using a NAS/network share. Drawback: Everyone 
must set a URL to the repo in his own settings.xml, but there's nothing 
wrong to use file:/ in this case. No POMs got polluted and if you decide 
later to install a real MRM, all that has to be adjusted are the local 
settings.xml - but that applies to any case.

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org