Hi,
Although I've seen a lot of threads about the maven-release-plugin, IMHO
it is often caused by bad reading. But that could also mean that we need
to improve the docs. I'm not aware of a lot of maven-site-plugin issues.
I'd like to base your opinion on facts, so in both cases I'd like to know
a top-10 or so for both plugins with the issue and the solution.
I don't think Maven users have issues with #1, it's sometimes a struggle
for Maven developers. Yes, there's a wish to separate this by making
interfaces for distributed and non-distributed SCMs, but that's a huge,
HUGE job.
#2 I think can only be simplified if you take the SCM into account. So
SCM-based default, but that's even harder to document. I'm not sure if
we're helping the community with such changes. Also, simplifying would
mean that some parameters are redundant or could be combined. The idea has
always been to use logical defaults, so there shouldn't be any need to use
large configuration-blocks for the maven-release-plugin. Your asking to
investigate, but I guess you already have some concrete ideas. Which ones?
#3 Again, I don't see any issues for general Maven users. We're offering a
lot of markup languages because the community wants too. The only
frustrations I can think of is path calculations and the site.xml in
multimodule projects (which parts of the site.xml must inherited,
overridden or extended? Now it's a mixture).
I'd suggest to start confluence-pages and separate these challenges.
Improvements for both plugins can be investigated and developed apart from
each other.
Robert
Op Wed, 24 Jul 2013 20:47:54 +0200 schreef Lennart Jörelid
<lennart.jore...@gmail.com>:
Hello all,
I have pondered a tad about the usability, applicability and
underpinnings
of Maven's current way to release artifacts [including source and javadoc
JARs] and sites. I feel that a lot of the confusion posted to diverse
mailing lists and forums originates in the release plugin, the site
plugin
and the slush of required configuration noted in the pom, settings.xml
and
plugin <configuration> sections.
It could be that Maven-Release-Plugin and Maven-Site-Plugin try to be too
generic or use too complex underpinnings. For example, we have a
Maven/VCS
integration framework - but it seems that the vast majority of devs only
ever use this functionality during releases (and, thus, indirectly
through
the maven-release-plugin). Moreover, since Maven (or some of its core
plugins) assume a SVN-centric view of the world, some Maven/VCS
operations
done during release seem to work poorly or requiring much repetitive
configuration for DVCSs. All - not most - devs I have spoken to prefer
using the native VCS client for their daily work over Maven's VCS
integration, implying that we might define the scope of the Maven/VCS
integration to fit the release and CI use case instead of being a generic
VCS integration into Maven (which is not used other than in the release
cases anyways?).
Could we simplify the release process and the configuration for
Maven-Release-Plugin and Maven-Site-Plugin by making and reacting to a
few
assumptions? Here goes:
1. The vast majority of Devs/CIs use Maven/SCM integration mainly for
checkout and release (which implies mainly tag, commit, checkin/push)
operations. These operations are used mainly for checking out/pulling
and
releasing artifacts.
2. We should investigate simplifying the configuration used for the
release process, potentially by simplifying the SCM layer to cater
only for
the operations used within its main use case (i.e. the release
process).
3. We should investigate simplifying the configuration used for
releasing a site - including relativization and aggregation - either
by
documenting the process better or perhaps narrowing down the amount of
input formats to potentially remove the use of Doxia altogether?
(After
all, there are quite a few good markup/HTML editors out there, and
much
more reference literature on HTML than ... say ... APT).
Simplification and usability improvements are - in my view - always Good
Things(tm).
What do you think?
--
+==============================+
| Bästa hälsningar,
| [sw. "Best regards"]
|
| Lennart Jörelid
| EAI Architect & Integrator
|
| jGuru Europe AB
| Mölnlycke - Kista
|
| Email: l...@jguru.se
| URL: www.jguru.se
| Phone
| (skype): jgurueurope
| (intl): +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
