maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lennart Jörelid <lennart.jore...@gmail.com>
Subject [Discussion] Simplifying the release process and the maven-release-plugin/maven-site-plugin
Date Wed, 24 Jul 2013 18:47:54 GMT
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: lj@jguru.se
| URL:   www.jguru.se
| Phone
| (skype):    jgurueurope
| (intl):     +46 708 507 603
| (domestic): 0708 - 507 603
+==============================+

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message