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: [email protected]
For additional commands, e-mail: [email protected]
