commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Tompkins <chtom...@gmail.com>
Subject Re: [release-plugin] best multi-module project?
Date Thu, 15 Feb 2018 20:49:17 GMT


> On Feb 15, 2018, at 3:06 PM, Gary Gregory <garydgregory@gmail.com> wrote:
> 
> Another goal (for me at least) is to put the plugin in commons-parent such
> each Commons Component does not need to define it, only refer to it.
> 

+1

> Gary
> 
>> On Thu, Feb 15, 2018 at 1:01 PM, Rob Tompkins <chtompki@gmail.com> 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. More debugging there will likely tease out the
>> issue. The goal is to have the mojos only operate on the top level pom.xml.
>> 
>> -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
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
>> 

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


Mime
View raw message