My idea for #1 was not to expand the SCM API for Maven, but to reduce and simplify it to the parts actually used (i.e. the operations done by the maven-release-plugin, since that plugin is really main user of the SCM API, along with the pull/checkout done typically by CI servers).
Moreover, the reasons I bring these thoughts up is that I have been asked the questions about what relevance some of the POM elements have over and over by Maven users. While we can certainly structure the thoughts and prioritize to achieve business as usual, my idea was more to get a healthy discussion going. It is good to ask ourselves "why" every now and then. 2013/7/24 Robert Scholte <[email protected]> > 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 < > [email protected]>: > > 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: [email protected] >> | URL: www.jguru.se >> | Phone >> | (skype): jgurueurope >> | (intl): +46 708 507 603 >> | (domestic): 0708 - 507 603 >> +=============================**=+ >> > > ------------------------------**------------------------------**--------- > To unsubscribe, e-mail: > [email protected].**org<[email protected]> > For additional commands, e-mail: [email protected] > > -- -- +==============================+ | Bästa hälsningar, | [sw. "Best regards"] | | Lennart Jörelid | EAI Architect & Integrator | | jGuru Europe AB | Mölnlycke - Kista | | Email: [email protected] | URL: www.jguru.se | Phone | (skype): jgurueurope | (intl): +46 708 507 603 | (domestic): 0708 - 507 603 +==============================+
