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 07:47:13 GMT
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).]

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