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
Ron
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 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 http://eclipse.org/m2e/ leads to
http://eclipse.org/m2e/documentation/, which has a single link to
http://wiki.eclipse.org/Maven_Integration, 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
(http://maven.apache.org/users/index.html) contains links to
tutorials, to the POM and Settings references - but no link to
http://maven.apache.org/guides/index.html .
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 codehaus.org 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: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
