maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <>
Subject Re: Unpacking jars into target/classes
Date Tue, 19 Mar 2013 22:40:56 GMT
On Tuesday, 19 March 2013, Joachim Durchholz wrote:

> Am 19.03.2013 22:20, schrieb Stephen Connolly:
>> On Tuesday, 19 March 2013, Joachim Durchholz wrote:
>>  Am 19.03.2013 12:13, schrieb Stephen Connolly:
>>>  Jo,
>>>> Just for you, I have taken the 30 minutes out of my life and written a
>>>> Maven Plugin that will solve your issues with those pesky non-maven
>>>> dependencies.
>>> Sorry, but that bold text is a piece of both impudence and arrogance.
>>> I don't think we have anything to discuss with each other anymore.
>>>  Pity, you are missing out on the solution you seek.
> The solution I seek does not lie with Maven.
> Not anymore anyway; this was the last straw.
>  I need to put that disclaimer on the project because I am on the Maven PMC
>> and therefore, even though the project is hosted on my GitHub account as
>> opposed to the ASF or the mojo project at codehaus it is necessary to let
>> people who stumble upon the project be aware that it is *not the
>> recommended solution*.
> Obviously you think I'm a fool if you think I can't read the subtext in
> the message.

Genuinely, no.

You are entitled to your opinion, but my stated reason of protecting the Mr
A Randomuser from stumbling upon the technique was the *only* reason for
the disclaimer.

> And don't you worry, with that attempt to justify yourself for the
> injustifiable you lost the last shred of respect you held in my eyes.

Well I am not out to gain/lose your respect. I am out to make the commons
better for everyone.

In fact that last phrase sums up "the maven way"

The guiding principle of the maven way is to make life easier for those
that come after.

* Standardised folder layout: makes life easier for those that come after
as it is one less thing to figure out.

* Standardised build life cycle: one less thing again.

* publishing built artifacts to a central repository: make life easier,
anyone around for the madness of 3rd party dependencies before central will
agree on that one

* encapsulate repeated build tasks as plugins: makes life easier, no
reinventing the wheel

Everything about the maven way is about making life easier for those that
come after.

The recommended solution to the problem of 3rd party non-maven jars is to
push them to a maven repository that benefits everyone who comes after.
They just need to declare the dependency and move on.

Alternative "solutions" such as the file:/// repository hack only work for
the project being built and can even not work fully for those projects.
They force everyone to add hacks on top of the hack to get their job done.

The non-maven-jar plugin solution that I implemented can be used with
internal projects to push 3rd party dependencies to an internal repository.
It won't work for pushing to central due to the validation requirements of
pushing to central (requires source.jar and javadoc.jar) so while not the
screaming ugly hack that others use, it has great potential to make life
harder for those that follow. If one does "mvn deploy" with this plugin =>
life is better for those that follow as the dependencies are available
outside the build reactor. If one does "mvn install" with this plugin =>
life is not better for others, but is better for you as the dependencies
are available outside the reactor but only on your machine.
Without doing "mvn deploy" then anyone needing to use your project will
need to checkout your project and build it to get those dependencies, now
chase that tree when you are wanting to use a library that depends on a
projects that depends on a project that depends on your project that
depends on those non-maven jar files... They will be forced to chase and
find the source code for each in turn, hope they have the correct revision
that works, and build... Oops dependency not found, oh another build from
source... Reminds me of all those ANT builds before maven central.

A commons only works if everyone has the principle "I will leave it tidier
than I found it". Good citizens follow that principle, bad citizens don't.

You have already indicated that you don't want to be a citizen of the maven
ecosystem so what should it matter whether you would be a good or bad
citizen of the maven ecosystem when you are not interested in such

I never said "good person" or "bad person" instead "citizen of the maven

You have said you don't want to create a jira to help document
improvements.., that is not somebody wanting to leave things tidier than
you found it

You have against deploying to a maven repository... Again not making things

It is an observable based on your actions that you are not interested in
leaving things tidier, that is not a good citizen of the maven ecosystem in
my book... That is not a value judgement on you as a person, just an
observation of your interaction with the community.

>  Just continue as you wish, you have nothing to lose.
> You should really add this disclaimer:
> Irks you?


> Doesn't do justice to you?

I fully accept that people outside my sphere of experience have things to
teach me, I've been developing software professionally for over 20 years on
everything from embedded systems through to front-end applications to
computational modelling to telecoms to working on cloud computing
platforms. 95% of the time I find people are working in a sphere I have
good overlap with, but I am always on the look out for signs of others who
have relevant teachings for me

> Applies a yardstick you're not willing to accept as relevant?

Applies a yardstick against which I feel you fall short yourself.

> Fine. Then you know what kind of message I just got.

I don't know what kind of message you got, because it seems that you are
intent on mis-interpreting everything I write... I wonder what you will
jump on in this reply!

> ------------------------------**------------------------------**---------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Sent from my phone

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