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 Fri, 16 Feb 2018 15:05:15 GMT


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

If we do a release removing sub modules, how do we accomplish that? Do we remove them from
the Pom?

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

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


Mime
View raw message