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 16:16:01 GMT
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.

> 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.

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