commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles <gil...@harfang.homelinux.org>
Subject Re: [release-plugin] best multi-module project?
Date Fri, 16 Feb 2018 19:45:22 GMT
On Fri, 16 Feb 2018 14:33:19 -0500, Rob Tompkins wrote:
>> On Feb 16, 2018, at 2:23 PM, Gilles <gilles@harfang.homelinux.org> 
>> wrote:
>>
>> On Fri, 16 Feb 2018 12:17:29 -0500, Rob Tompkins wrote:
>>>> On Feb 16, 2018, at 11:50 AM, Rob Tompkins <chtompki@gmail.com> 
>>>> wrote:
>>>>
>>>>
>>>>
>>>>> On Feb 16, 2018, at 11:16 AM, Gilles 
>>>>> <gilles@harfang.homelinux.org> wrote:
>>>>>
>>>>> On Fri, 16 Feb 2018 10:05:15 -0500, Rob Tompkins wrote:
>>>>>>> On Feb 16, 2018, at 2:47 AM, Gilles 
>>>>>>> <gilles@harfang.homelinux.org> wrote:
>>>>>>>
>>>>>>> On Thu, 15 Feb 2018 15:01:23 -0500, Rob Tompkins wrote:
>>>>>>>>> On Feb 15, 2018, at 2:37 PM, Gilles 
>>>>>>>>> <gilles@harfang.homelinux.org> wrote:
>>>>>>>>>
>>>>>>>>>> On Wed, 07 Feb 2018 15:22:59 +0100, Gilles wrote:
>>>>>>>>>> On Wed, 7 Feb 2018 08:31:45 -0500, Rob Tompkins wrote:
>>>>>>>>>>>> On Feb 6, 2018, at 6:28 PM, Gilles 
>>>>>>>>>>>> <gilles@harfang.homelinux.org> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> On Mon, 5 Feb 2018 21:49:52 -0500, Rob Tompkins
wrote:
>>>>>>>>>>>>>> On Feb 5, 2018, at 3:05 PM, Gilles

>>>>>>>>>>>>>> <gilles@harfang.homelinux.org>
wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, 5 Feb 2018 14:27:53 -0500,
Rob Tompkins wrote:
>>>>>>>>>>>>>>>> On Feb 5, 2018, at 2:22 PM,
Gilles 
>>>>>>>>>>>>>>>> <gilles@harfang.homelinux.org>
wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, 5 Feb 2018 14:17:18
-0500, Rob Tompkins 
>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> Which should be the template
multi-module project? 
>>>>>>>>>>>>>>>>> They all have
>>>>>>>>>>>>>>>>> subtle differences that
lead to different nuances to 
>>>>>>>>>>>>>>>>> the build.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Which differences did you
spot?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Nothing of any particular consequence,
just where the 
>>>>>>>>>>>>>>> main assemblies
>>>>>>>>>>>>>>> end up. Or which Pom they’re
in.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What do you mean by "main assemblies"?
 If it's the 
>>>>>>>>>>>>>> "full"
>>>>>>>>>>>>>> distribution, then is it a matter
of naming the output 
>>>>>>>>>>>>>> directory?
>>>>>>>>>>>>>> It could be configurable.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> For the config, the main POM looks
the appropriate place 
>>>>>>>>>>>>>> if it can
>>>>>>>>>>>>>> be done without side-effects. [For
RNG I created a 
>>>>>>>>>>>>>> separate directory
>>>>>>>>>>>>>> because I was not sure how to do
it.]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Right….that’s why I was asking which
project would be the 
>>>>>>>>>>>>> best
>>>>>>>>>>>>> standard to work from, and then I could
go through and 
>>>>>>>>>>>>> take all of the
>>>>>>>>>>>>> other multi-module builds and mildly
refactor the 
>>>>>>>>>>>>> pom/directory
>>>>>>>>>>>>> structure to align with which ever we
decided was 
>>>>>>>>>>>>> standard.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is [jcs] the right choice as the standard?
>>>>>>>>>>>>
>>>>>>>>>>>> Why this one rather than another?
>>>>>>>>>>>> It's not clear what you are looking for.
>>>>>>>>>>>
>>>>>>>>>>> It really doesn’t matter too much to me, I
just wanted to 
>>>>>>>>>>> get a
>>>>>>>>>>> community consensus on what we think a standard
directory 
>>>>>>>>>>> structure
>>>>>>>>>>> should be, or the exemplar
>>>>>>>>>>> multimodule commons project.
>>>>>>>>>>
>>>>>>>>>> Quite possibly none of them is *the* example to follow.
>>>>>>>>>>
>>>>>>>>>>> It’s just easier to work from a specific project
as opposed 
>>>>>>>>>>> to trying
>>>>>>>>>>> to generalize immediately.
>>>>>>>>>>
>>>>>>>>>> Perhaps (?) the other way around: by implementing
some 
>>>>>>>>>> release
>>>>>>>>>> procedure of a multi-module project, you can suggest
a 
>>>>>>>>>> matching
>>>>>>>>>> layout.
>>>>>>>>>>
>>>>>>>>>> See also my "wish" below. If it could work that way,
the 
>>>>>>>>>> layout
>>>>>>>>>> does not matter since the module info is taken from
the top 
>>>>>>>>>> POM.
>>>>>>>>>>
>>>>>>>>>> Perhaps there could be a profile
>>>>>>>>>> ---CUT---
>>>>>>>>>> <profile>
>>>>>>>>>>  <id>distribution-bundle</id>
>>>>>>>>>>  <modules>
>>>>>>>>>>    <module>commons-compX-mod1</module>
>>>>>>>>>>    <module>commons-compX-mod2</module>
>>>>>>>>>>  </modules>
>>>>>>>>>> </profile>
>>>>>>>>>> ---CUT---
>>>>>>>>>> And the plugin would go down the named directories
and 
>>>>>>>>>> collect
>>>>>>>>>> the artefacts.  This would allow a project to contain

>>>>>>>>>> modules
>>>>>>>>>> not yet ready for release.
>>>>>>>>>>
>>>>>>>>>>> So my thought right now is either [rng] or [jcs].
>>>>>>>>>>>
>>>>>>>>>>> I suppose another thought could be: is anyone
planning a 
>>>>>>>>>>> release on a
>>>>>>>>>>> commons multi-module project anytime soon?
>>>>>>>>>>
>>>>>>>>>> Yes.
>>>>>>>>>>
>>>>>>>>>>> If so which?
>>>>>>>>>>
>>>>>>>>>> "Commons RNG", as soon as the pending issues[1] are

>>>>>>>>>> resolved:
>>>>>>>>>> * RNG-40
>>>>>>>>>> * RNG-31
>>>>>>>>>> * RNG-48
>>>>>>>>>> * RNG-44
>>>>>>>>>>
>>>>>>>>>> The latter three are related to the multi-module
handling by
>>>>>>>>>> the "parent" project (i.e. the problem(s) which you
intend 
>>>>>>>>>> to
>>>>>>>>>> solve IIUC).
>>>>>>>>>
>>>>>>>>> Where do we stand wrt the functionalities needed to
>>>>>>>>> release a modular project?
>>>>>>>>
>>>>>>>> My first attempt (which I’ve gotten to work with other
maven 
>>>>>>>> plugins)
>>>>>>>> didn’t immediately work.
>>>>>>>
>>>>>>> Which project is serving as playground?
>>>>>>>
>>>>>>>> More debugging there will likely tease out
>>>>>>>> the issue. The goal is to have the mojos only operate on
the 
>>>>>>>> top level
>>>>>>>> pom.xml.
>>>>>>>
>>>>>>> Why? [It is conceivable that some project may want to release
>>>>>>> some sub-module(s).]
>>>>>>
>>>>>> For the most part the plugin centers on the assembly files, the 
>>>>>> site,
>>>>>> and the release notes for which a release only has one of.
>>>>>
>>>>> For "site" and "release notes" I agree that there is one. [Which
>>>>> is the same as saying that this is not multi-module related.]
>>>>>
>>>>> The "assembly" is an problem with the release of a multi-module
>>>>> project (see issue RNG-31).
>>>>>
>>>>> I see that Maven is working "hierarchically" (cf. "effective 
>>>>> POM").
>>>>> But from the above, I have the (perhaps wrong) impression, that 
>>>>> you
>>>>> are working against that feature...
>>>>>
>>>>> I have the perhaps naïve view that whenever a module is
>>>>> mentioned in a <modules> directive, it should just be
>>>>> aggregated to the "assembly".
>>>>>
>>>>>> So my focus
>>>>>> is to get that working, then we can jump into the how to think 
>>>>>> about a
>>>>>> release where individual sub modules are removed.
>>>>>
>>>>> Again, this is the other way around (IMHO): let maven tell you 
>>>>> which
>>>>> module is "on" (and the plugin will aggregate); nothing to do for
>>>>> a "removed" <module> directive.
>>>>
>>>> I’m actually not all that concerned with which modules are or 
>>>> aren’t included because I’m focusing on what gets staged in 
>>>> subversion for website download in the end. I’m not familiar with 
>>>> lots of different types of tars/zips other than src and bin ending 
>>>> up there in svn.
>>
>> Sorry I don't follow.
>> I've detailed what went wrong with the distribution files when
>> doing the release candidate for RNG v1.0.
>> The web site is/was not a problem for me, and is not part of
>> the official artefacts.
>
> Sure I understand that.
>
> The goal was to avoid having to SFTP the site up to your personal
> location by checking it in as a .zip to the dev dist location
> automatically.
>
>>
>>>>
>>>> For the main maven process I’m trying to stay away from doing any 
>>>> subtle build manipulation that could effect what gets deployed to 
>>>> nexus, aside from keeping the tars/zips from landing up there.
>>
>> That bit (having to remove unwanted artefacts from Nexus) was/is
>> annoying.  But IIRC some people argued that the removal is not
>> necessary (?).
>>
>
> This may indeed be the case, but the current documentation says to
> not do this, so the plugin facilitates that. I’m personally
> indifferent, so I’m just sticking with the docs for the time being.
>
> I’m going to play with [rng] from now forward to see how the
> -Ptest-deploy works. I’ve seen you in there (in the last day or so),
> and don’t want to step on any toes. I’ll try to follow along with 
> what
> we have in place and form the plugin to work with what you have. 
> Note,
> only minimal changes may be necessary to accomplish this, but it’s a
> matter of my playing with things to get there.

OK. As I've noted in another post, I think that everything is
in place for an attempt to release v1.1 of "Commons RNG".
Let me know when you are finished "playing with things". ;-)

What would be great is that you create a new document
besides the one documenting the current recipe:
   doc/release/release.howto.txt
with the alternative steps (i.e. using you new plugin).

Thanks,
Gilles

>
> -Rob
>
>>>>>
>>>>>> If we do a release removing sub modules, how do we accomplish 
>>>>>> that?
>>>>>> Do we remove them from the Pom?
>>>>>
>>>>> It's a possibility (to be done only in the release branch then).
>>>>> Another, which I mentioned in a previous post (see somewhere
>>>>> above), would be to have a profile that would list the modules
>>>>> to be released.
>>>>> Please look at the POMs, "top-level" and modules, for [RNG].
>>>>>
>>>>> There is a default list of modules and there is a profile that
>>>>> duplicates that list and add "commons-rng-examples" to allow
>>>>> a more recent language level.
>>>
>>> And, I forgot to mention that I’m working with jcs and vfs as the
>>> sample modules. I think having that src directory at the top level 
>>> for
>>> the distributions makes sense.
>>
>> How is [RNG] different?
>>  
>> https://git1-us-west.apache.org/repos/asf?p=commons-rng.git;a=tree;f=src;h=647b5d7b8fa117237fa068ba458736c5f996abc7;hb=HEAD
>>
>>
>> Gilles
>>
>>>>>>>
>>>>>>>>
>>>>>>>> -Rob
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Regards,
>>>>>>>>> Gilles
>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>> 
>>>>>>>>>> https://issues.apache.org/jira/browse/RNG-40?filter=-5&jql=project%20%3D%20RNG%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%201.1%20order%20by%20priority%20DESC%2Cupdated%20DESC
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -Rob
>>>>>>>>>>>
>>>>>>>>>>>> From what I see wrt the creation of "full
dist" artefacts, 
>>>>>>>>>>>> the
>>>>>>>>>>>> difference with e.g. [RNG] is that in [jcs],
there is a 
>>>>>>>>>>>> maven
>>>>>>>>>>>> module, with no code, while for [RNG], there
is a 
>>>>>>>>>>>> directory
>>>>>>>>>>>> (not a maven module), but both contain a
POM whose only 
>>>>>>>>>>>> purpose
>>>>>>>>>>>> is to provide an "assembly" config.
>>>>>>>>>>>>
>>>>>>>>>>>> Having no idea on how to achieve it, I'd
wish that 
>>>>>>>>>>>> creating
>>>>>>>>>>>> the "full dist" only requires a custom "goal"
like (?)
>>>>>>>>>>>> $ mvn package:dist
>>>>>>>>>>>> with no ad-hoc directory/module: all modules
specified in 
>>>>>>>>>>>> the
>>>>>>>>>>>> top POM would have their artefacts (recursively)
bundled 
>>>>>>>>>>>> into
>>>>>>>>>>>> <component>-dist-<version>.tar.gz
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Gilles
>>>>>>>>>>>>
>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>> -Rob
>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Gilles
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>> figure we pick one and
make that the standard 
>>>>>>>>>>>>>>>>> multi-module build
>>>>>>>>>>>>>>>>> paradigm and fit the
others into it.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> -Rob


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message