maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrien Rivard <>
Subject Re: Unpacking jars into target/classes
Date Thu, 07 Mar 2013 11:16:48 GMT
On Thu, Mar 7, 2013 at 11:37 AM, Joachim Durchholz <> wrote:

> Am 07.03.2013 10:00, schrieb Jörg Schaible:
>  Hi,
>> Joachim Durchholz wrote:
>>  Am 07.03.2013 05:51, schrieb Matthew Adams:
>>>> Quick jist:
>>>> 1. Use maven-install-plugin's
>>>> install-file<http://maven.****install-<>
>>> plugin/install-file-mojo.html>**goal
>>> to make maven artifacts out of the jars you intend to unpack, and do
>>>> it in any phase prior to process-classes (or do this first in the
>>>> process-classes phase).
>>> The overall organisational project structure does not allow any central
>>> servers beyond the SCM.
>>> It would also be silly to redundantly store a perfectly stable jar in a
>>> Maven repo just to make Maven happy.
>> But that's the point: Maven is all about conventions. It will not help
>> you a
>> lot in other regards - on purpose.
> So if a tool doesn't what it should, that's just on purpose? Come on.
> Oh, and conventions are useless unless applied to some domain, and Maven
> does indeed have domains (dependency management, builds, build stability).
> Sorry to sound harsh, but "it's on purpose" is just a cheap cop-out.
> > If you don't want to follow this
>> conventions, it is probably no the right tool for your job.
> I claim that Maven's stance of essentially requiring a repository manager
> needlessly complicates the build infrastructure.
It may complicate the build infrastrucure but it simplify and homogenize a
lots all the builds of all your project. Which is what Maven is all about.

If you don't want to use a repository manager, just don't use Maven, Maven
is not flexible by design. If you want to use it outside its main design,
you will have a too complex build. This will be better achieved with a
tools that support scripting in its design.

That said, it is still useful to have a repopsitory manager even with
others build tools like gradle/ant+ivy.

> Jo
> P.S.: Not that discussing Maven's philosophy helps my original problem in
> any way... essentially you're saying "Maven can't do that and that's okay",
> and I say "if Maven can't do that by design, then the design of Maven is
> broken".
> You consider my position baseless because, from your perspective, I want
> the undesirable; I consider your position baseless because you're putting
> some very abstract theory about what's desirable ahead of very concrete and
> practical needs, and I consider theory useless if it doesn't cover all
> bases.
> Given that situation, I don't think it's going to be very fruitful to
> discuss Maven's philosophy.
> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail: users-unsubscribe@maven.**<>
> For additional commands, e-mail:

Adrien Rivard

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message