maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joachim Durchholz>
Subject Re: Packaging up pre-existing jar and source jar
Date Fri, 18 Jan 2013 17:41:44 GMT
Am 18.01.2013 11:07, schrieb Stephen Connolly:

> My point is, you think adding a MRM is adding a point of failure...
> actually it's taking away about 3-4 points of failure, so NET GAIN in
> reliability.

Well, right now, everything is bootstrapping nicely from a Bitbucket 
I'm using Maven as a build tool. Dependency consolidation is via 
Bitbucket, so that part of MRM functionality isn't very relevant to me.

>>   Third, performance. When you list multiple <repository> in your pom or
>>> settings.xml you force artifact resolution to hit ALL of them. with an MRM
>>> you set <mirrorOf>*</mirrorOf> and you now only hit one, it's local
>>> anyway,
>>> it's flattened (because it's a virtual repo) and you have a fast reliable
>>> build and you can scale it out to others.
>> I supposes the m2eclipse repository manager does that already. It is
>> hitting Maven Central on Eclipse startup, once (and takes minutes to
>> complete).
> With an MRM this would be seconds not minutes

Yep, it would be the MRM waiting for the repo information and not 
Eclipse :-)
It looks like m2e is doing the proxying already, so that part of an MRM 
isn't relevant either.

>> I can see that building from the command line might suck, because that
>> won't have the m2eclipse "Workspace Repositories"
> That, and I don't use eclipse, is just building a reactor out of all the
> projects in your workspace which is handy, but will cause issues for you.

Not sure what kinds of issues these might be.

> If you are really trying to grok what maven is doing, forget eclipse, start
> from the CLI. Eclipse does all sorts of magic to try and protect you from
> people who don't grok Maven and set up insane builds.

Oh, I don't think it's so hard. I'm avoiding the pom wizards (don't give 
me any value anymore), and I'm editing the poms in the XML editor.

 > That's what an IDE
> should do, but for an engineer trying to grok what Maven is doing, you got
> to go back to vi and CLI... otherwise you are dealing with Magic

Not much magic seems to be left with that.

I'm starting the builds through a Maven launch configuration. That's 
essentially the command line.

The only "magic" thing that happens is that I can have multiple projects 
open, modify code in any of them, and debug the whole system without 
having to mvn install. If that should fail - well, the launch 
configuration for "mvn install" is just a mouse click away.

> Our issue is we see this *every day*, so our short cut is to tell people:
> learn from us, this is the way to do it.

It would probably be easier if the online docs were better indexed.

I mean, the "Documentation" link on leads to, which has a single link to, which is essentially just a 
blurb and installation instructions, but no documentation on what it 
actually does (what you referred to as "magic" above).
The info on, for example, the items in the "Maven repositories" tab is 
available, but you need to ask Google, it's not linked from the pages.

There are more problems like that:

The Maven documentation site ( 
contains links to tutorials, to the POM and Settings references - but no 
link to .

The list of standard plugins is under "Maven Projects". I ignored that 
section because, you see, a "project" is something that you contribute 
to; that section should be labelled "Maven Usage" or something.

Plugin descriptions abound with terminology but lack links to the 
explanations of that terminology.
Sample excerpts from pom files do not highlight those parts that are 
relevant to the plugin itself.

Grouping the etc. plugins in a separate section creates 
more questions than answers. Are these plugins of lesser quality? Do 
they have some other technical quality? 'cause when I'm looking for a 
plugin that fulfills a specific task, the most important distinction is 
the class of tasks - core, packaging, reporting. (And the Tools section 
should be split up into "Publication", "Build process orchestration" and 
"Miscellaneous", "Tools" could apply to any plugin.)

The boilerplate text in the "Usage" section of all the plugins is less 
than useful. It's always the same, except where it isn't but you don't 
see it because the differences drown in a sea of, well, boilerplate. 
Besides, what good is "General instructions on how to use the Shade 
Plugin can be found on the usage page." if the "Usage" entry is right in 
the Overview section to the left?
The remaining boilerplate text follows just the same pattern: 
replicating links that are already present in the sidebar.
And "To provide you with better understanding on some usages of the 
Shade Plugin, you can take a look into the following examples:" is just 
fluff. It's just text that needs to be scanned to see whether anything 
relevant is in it, but there isn't; a list of bullets under a heading of 
"Examples" is enough.
The whole plugin documentation flies in the face of the DRY principle. 
Links to the standard explanations are in order, but they should be in 
the sidebar where people expect the always-the-same content, not in the 
running text.
I'm not sure how that text generation got into the docpage generation 
process. Maybe somebody complained that they overlooked the link in the 
sidebar; in that case, it's probably more helpful to reconsider the 
sidebar structure. For example, it should be structured like this:
Maven Shade plugin
     Selecting Contents for Uber JAR
     Relocating Classes
   Plugin information (don't replicate "Introduction" as "About")
   (Leaving out "About", that's the same as "Introduction" - DRY)
     Summary ("project" isn't helpful unless you say which)
     Source Repository
   Autogenerated Information (reordered: plugin user interests go first)
     Sources ("Xref" would be names plus using lines)
     Test results
       Cobertura Text Coverage
     Code analysis
       PMD's CPD
     (Leave "Plugin documentation" out, it's a duplicate of "Goals")
   (whatever sections are useful about Maven)
Apache Software Foundation
   (whatever sections are useful about the ASF)

There. Plugin information separated from Maven and ASF at the top level; 
no repetition, stuff restructured and renamed according to the target 
audience: People who're using the plugin.

Just my 5 cents, while the impression is fresh, written in a somewhat 
dazed state while breeding a flu (apologies for the crankiness), to be 
taken as a data point, in the hope that it helps reducing the 
always-the-same-newbie-question clutter here in the list.


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

View raw message