maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ron Wheeler <>
Subject Re: Packaging up pre-existing jar and source jar
Date Fri, 18 Jan 2013 19:46:22 GMT
If you look at the list of project commiters, you can see that you got 
the best advice possible.

I agree with your comments about the documentation in general and one 
has to browse some of the books to get oriented to a point where the 
docs are useful.

Good luck

On 18/01/2013 12:41 PM, Joachim Durchholz wrote:
> 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 
> repository.
> 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
>>>> 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
>   Introduction
>   Goals
>   Usage
>   FAQ
>   Examples
>     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)
>     License
>     Team
>     Source Repository
>   ...
>   Autogenerated Information (reordered: plugin user interests go first)
>     Javadocs
>       Main
>       Test
>     Sources ("Xref" would be names plus using lines)
>       Main
>       Test
>     Test results
>       Surefire
>       Cobertura Text Coverage
>     Code analysis
>       Checkstyle
>       PMD
>       PMD's CPD
>       Findbugs
>       Sonar
>     (Leave "Plugin documentation" out, it's a duplicate of "Goals")
> Maven
>   (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.
> Regards,
> Jo
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

Ron Wheeler
Artifact Software Inc
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

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

View raw message