Mailing-List: contact dev-help@maven.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Maven Developers List" <dev@maven.apache.org>
Received-SPF: pass (athena.apache.org: domain of chrisgwarp@gmail.com
 designates 209.85.128.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <op.w728621nkdkhrr@robertscholte>
References: 
 <CADVp3v87tTdpVBCO6GDcCFPttcCoeqQ=0iG1Z5YbwfA+wNPxVg@mail.gmail.com>
	<3200821.dXjIO4fT7A@herve-desktop>
	<op.w726a1shkdkhrr@robertscholte>
	<1427503.zoyyuPaoP3@herve-desktop>
	<op.w728621nkdkhrr@robertscholte>
Date: Sun, 15 Dec 2013 13:24:57 +1100
Message-ID: 
 <CAJcKzHERf0AmdsJRHE-=iCRaX+WX9sW0ryXJSzT7dt4UQq_utg@mail.gmail.com>
Subject: Re: Release Instructions: Unified or Simpler Mono-Module (was Re: svn
 commit: r1549574 - /maven/skins/trunk/maven-skins/pom.xml)
From: Chris Graham <chrisgwarp@gmail.com>
To: Maven Developers List <dev@maven.apache.org>
Content-Type: multipart/alternative; boundary=001a11c2c7dac843c604ed8966da

--001a11c2c7dac843c604ed8966da
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

+1
The value is in the process, and that comes from it being simple and
repeatable, minimising 'specials' :)
-Chris


On Sun, Dec 15, 2013 at 2:26 AM, Robert Scholte <rfscholte@apache.org>wrote=
:

> +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 <
> herve.boutemy@free.fr>:
>
>
>  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 configured
>> 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
>>>
>>> <herve.boutemy@free.fr>:
>>> > before I update documentation and parent poms:
>>> > any objection from any future release manager if we unify site:stage
>>> > 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/site/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 build=
s
>>> 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 Mave=
n
>>> 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 <herve.boutemy@free.f=
r>
>>> >>
>>> >> wrote:
>>> >> > > > Le mardi 10 d=E9cembre 2013 01:05:30 Michael-O a =E9crit :
>>> >> > > >> Am 2013-12-10 00:58, schrieb Herv=E9 BOUTEMY:
>>> >> <content>${project.build.directory}/staging/${maven.site.path}</co
>>> >>
>>> >> > > >> >> 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 need =
to
>>> >>
>>> >> do
>>> >>
>>> >> > > >> > extra
>>> >> > > >> > site:stage step, not usually needed
>>> >> > > >>
>>> >> > > >> I am aware of that. That change was intentional. It conforms =
to
>>> >>
>>> >> all
>>> >>
>>> >> > > >> other POMs and to the procedure described in the docs. Nothin=
g
>>> >>
>>> >> more,
>>> >>
>>> >> > > >> nothing less.
>>> >> > > >
>>> >> > > > not really what I wanted to express with "if the component has
>>> >> > > > 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 i=
s)
>>> >>
>>> >> 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 all
>>> 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 R=
M
>>> >>
>>> >> 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 stuf=
f
>>> >> > > something
>>> >> > > up. Which would make me lean to unified instructions to make it
>>> >>
>>> >> easier
>>> >>
>>> >> > > to
>>> >> > > update the instructions when necessary.
>>> >> > >
>>> >> > > Do we have any metrics on how many mono- to multi- module builds
>>> 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
>
>

--001a11c2c7dac843c604ed8966da--