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 19:21:17 GMT


> On Feb 16, 2018, at 12:17 PM, Rob Tompkins <chtompki@gmail.com> wrote:
> 
> 
> 
>> On Feb 16, 2018, at 11:50 AM, Rob Tompkins <chtompki@gmail.com <mailto:chtompki@gmail.com>>
wrote:
>> 
>> 
>> 
>>> On Feb 16, 2018, at 11:16 AM, Gilles <gilles@harfang.homelinux.org <mailto: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
<mailto: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
<mailto: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
<mailto: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
<mailto: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 <mailto: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. 
>> 
>> 
>> 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. 
>> 
>>> 
>>>> 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.

Working with [rng] now as the other’s were a bit cumbersome to work with.

> 
>>> 
>>> 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
<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 <mailto:dev-unsubscribe@commons.apache.org>
>>> For additional commands, e-mail: dev-help@commons.apache.org <mailto:dev-help@commons.apache.org>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message