The standard for how we document the plugins within the Maven project
can be found here:
http://maven.apache.org/guides/development/guide-plugin-documentation.html
It has been a long way and a lot of work to get this in place for all
our plugins. The purpose of the standard was to document plugins in a
similar way. That should make it easier for users to find their way
around any plugin site, if they have learned it once.
We don't accept new plugins unless they follow the plugin documentation
standard. We have even written a plugin that helps us check this:
http://maven.apache.org/plugins/maven-docck-plugin/
Final note: I take it that you are being payed money where you work.
This is an open source project.
EJ Ciramella wrote:
I have to agree with the comments in this thread.
Asking someone to contribute documentation for a plugin they didn't
write is pretty lame. How about not letting someone submit a plugin
until not only has the code been tested/proven, but the associated
documentation is up to snuff? I don't know how it works where ever you
guys are working but when code is committed to our SCM system here, a
code review has to pass. Part of that review is to go over the
associated documentation.
Also, I've spent hours upon hours chasing my tail on things like the bug
where profiles weren't ordered in the order specified on the commandline
(it seemed partially random and then partially due to ordering in
settings.xml/profiles.xml). After many days of silence on both mailing
lists, we pulled down the source and realized that it was a bug, fixed
it, and then saw a new release of maven 2 come out that did the same
thing.
We've also noticed that classpaths aren't as controlled as we would have
liked. A scenario is - three modules at the same level, two branched
away as to be built in isolation. All of a sudden the third module
can't find any classes that the first two put into the compile classpath
- and this is the case if/if not there are dependencies on these modules
to/from each other.
I'd also like to echo the sentiment, "maven is great if you're doing
standard stuff" and "maven is HORRIBLE when you're trying to do anything
out of the norm". I feel like it's easier to just write my own plugin
than it is to scour the maven site in hopes of finding something
suitable to my needs. Additionally, twice now we've started using a
plugin just to find that it has been abandoned for a less buggy plugin.
Where's the repository management documentation (how to set one up at
your company, how to keep it up-to-date, etc.)? I work at a relatively
large company and I can't believe for a second other companies similarly
sized or bigger would want developer groups going across the internet
the way maven tries to do (for plugins and dependencies). This also
makes overseas development challenging.
Look, I think many people are wanting a build tool better than shell
scripting and make, possibly easier than ant - but something with less
of a learning curve of maven 1 or 2. I think ant is REALLY smooth and
easy to code/understand. To say that ant is challenging in any
way/shape/form is to deny the truth. Maven 2 build/release engineering
does get easier with time, but we all don't have limitless time to
learn.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
