Return-Path: X-Original-To: apmail-maven-dev-archive@www.apache.org Delivered-To: apmail-maven-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 46FCC1090F for ; Sat, 14 Dec 2013 15:27:16 +0000 (UTC) Received: (qmail 36003 invoked by uid 500); 14 Dec 2013 15:27:09 -0000 Delivered-To: apmail-maven-dev-archive@maven.apache.org Received: (qmail 35890 invoked by uid 500); 14 Dec 2013 15:27:02 -0000 Mailing-List: contact dev-help@maven.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Maven Developers List" Reply-To: "Maven Developers List" Delivered-To: mailing list dev@maven.apache.org Received: (qmail 35867 invoked by uid 99); 14 Dec 2013 15:27:00 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Dec 2013 15:27:00 +0000 Received: from localhost (HELO robertscholte) (127.0.0.1) (smtp-auth username rfscholte, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Sat, 14 Dec 2013 15:26:53 +0000 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: "Maven Developers List" Subject: Re: Release Instructions: Unified or Simpler Mono-Module (was Re: svn commit: r1549574 - /maven/skins/trunk/maven-skins/pom.xml) References: <3200821.dXjIO4fT7A@herve-desktop> <1427503.zoyyuPaoP3@herve-desktop> Date: Sat, 14 Dec 2013 16:26:52 +0100 MIME-Version: 1.0 Content-Transfer-Encoding: Quoted-Printable From: "Robert Scholte" Message-ID: In-Reply-To: <1427503.zoyyuPaoP3@herve-desktop> User-Agent: Opera Mail/12.16 (Win32) +1 for a standardized process, even though the results for mono-projects= = stay the same. Robert Op Sat, 14 Dec 2013 15:47:51 +0100 schreef Herv=E9 BOUTEMY = : > the only change is that you'd have to run "mvn -Preporting site = > site:stage" > even for mono-modules, when actually the "site:stage" part is required= = > only > for multi-module > > the purpose is to have stupid easy unified instructions, without "if = > multi- > module" step: every component has the exact same commands > > the drawback is that, from a pure technical point of view, "site:stage= " = > goal > could be avoided for the 80 mono-components and is absolutely required= = > only > for the 20 multi-modules: but once scm-publish plugin will be configur= ed = > to > publish from staging directory instead of direct site directory, = > "site:stage" > will be required even for mono-modules. > It costs typing a few letters more (or copy/pasting). Running the goal= = > doesn't > take much time (a few seconds). And I suppose nobody cares about site = = > content > being duplicated on disk, using twice space. > > Regards, > > Herv=E9 > > Le samedi 14 d=E9cembre 2013 15:24:27 Robert Scholte a =E9crit : >> Could you describe in short how the process would look like? As in >> staging/performing the release and finalizing it (after enough votes)= . >> >> Robert >> >> Op Sat, 14 Dec 2013 14:19:52 +0100 schreef Herv=E9 BOUTEMY >> >> : >> > before I update documentation and parent poms: >> > any objection from any future release manager if we unify site:stag= e >> > requirement? >> > >> > Regards, >> > >> > Herv=E9 >> > >> > Le mardi 10 d=E9cembre 2013 23:59:19 Herv=E9 BOUTEMY a =E9crit : >> >> really, here is the link... >> >> = >> https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/si= te/d >> >> ist -tool-check-source-release.html >> >> >> >> Le mardi 10 d=E9cembre 2013 23:50:26 Herv=E9 BOUTEMY a =E9crit : >> >> > (better with link) >> >> > /> Do we have any metrics on how many mono- to multi- module = >> builds we >> >> > have?/ indirectly, yes: dist-tool [1] tells we have 101 releases= >> >> > >> >> > >> >> > plugins, shared, skins, poms, reporting and resources are >> >> >> >> mono-modules: >> >> > 44+20+6+2+3+5 =3D 80 >> >> > >> >> > >> >> > other ones are multi-modules: 101-80 =3D 21 (-3 given we have Ma= ven = >> 2.0, >> >> > 2.2, >> >> > 3.0 and 3.1) >> >> > >> >> > >> >> > >> >> > so I see 80 mono-module and 18 multi-modules >> >> > >> >> > >> >> > Regards, >> >> > >> >> > >> >> > Herv=E9 >> >> > >> >> > Le mardi 10 d=E9cembre 2013 11:39:13 Barrie Treloar a =E9crit : >> >> > > On 10 December 2013 11:24, Herv=E9 BOUTEMY >> >> >> >> wrote: >> >> > > > Le mardi 10 d=E9cembre 2013 01:05:30 Michael-O a =E9crit : >> >> > > >> Am 2013-12-10 00:58, schrieb Herv=E9 BOUTEMY: >> >> ${project.build.directory}/staging/${maven.site.path}> >> >> >> > > >> >> nt >> >> > > >> >> en >> >> > > >> >> t> >> >> > > >> > >> >> > > >> > is not really necessary here, since skins are never >> >> >> >> multi-module, >> >> >> >> > > >> > then >> >> > > >> > no >> >> > > >> > need to site:stage >> >> > > >> > >> >> > > >> > that's not a blocking issue, since it will work: just nee= d = >> to >> >> >> >> do >> >> >> >> > > >> > extra >> >> > > >> > site:stage step, not usually needed >> >> > > >> >> >> > > >> I am aware of that. That change was intentional. It conform= s = >> to >> >> >> >> all >> >> >> >> > > >> other POMs and to the procedure described in the docs. Noth= ing >> >> >> >> more, >> >> >> >> > > >> nothing less. >> >> > > > >> >> > > > not really what I wanted to express with "if the component h= as >> >> > > > multiple >> >> > > > modules, locally stage the site:" >> >> > > > but staging in every situation has the advantage that = >> instructions >> >> > > > would >> >> > > > not be different for mono-module and multi-module >> >> > > > >> >> > > > I don't know what you all prefer: simpler instructions for >> >> >> >> mono-module >> >> >> >> > > > (but >> >> > > > require a little thinking to know in which situation a build= = >> is) >> >> >> >> or >> >> >> >> > > > uniform >> >> > > > instructions (even if it is a little more complex than = >> absolutely >> >> > > > necessary >> >> > > > for mono-modules) >> >> > > > >> >> > > > the ideal situation would be a site:deploy goal that does al= l = >> the >> >> > > > magic >> >> > > > in >> >> > > > case of scm: dist management site url >> >> > > > anybody interested in trying to do it with me? >> >> > > >> >> > > You might want to pull this out into a new thread. - Why dont = I = >> do >> >> > > that... >> >> > > I have been following because we had someone new wanting to do= RM >> >> >> >> and >> >> >> >> > > I was interested in their pain. >> >> > > >> >> > > I'm not sure I have a preference since its been so long since = I = >> last >> >> > > did a release. >> >> > > >> >> > > I definitely want to follow the instructions so that I dont st= uff >> >> > > something >> >> > > up. Which would make me lean to unified instructions to make i= t >> >> >> >> easier >> >> >> >> > > to >> >> > > update the instructions when necessary. >> >> > > >> >> > > Do we have any metrics on how many mono- to multi- module buil= ds = >> we >> >> > > have? >> >> >> >> ------------------------------------------------------------------= --- >> >> >> >> > > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >> >> > > For additional commands, e-mail: dev-help@maven.apache.org >> >> >> >> ------------------------------------------------------------------= --- >> >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >> >> For additional commands, e-mail: dev-help@maven.apache.org >> > >> > -------------------------------------------------------------------= -- >> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >> > For additional commands, e-mail: dev-help@maven.apache.org >> >> ---------------------------------------------------------------------= >> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org >> For additional commands, e-mail: dev-help@maven.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org > For additional commands, e-mail: dev-help@maven.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org For additional commands, e-mail: dev-help@maven.apache.org