Re: [jira] [Created] (COMMONSSITE-102) Commons Release Plugin doesn't work with Commons Release Plugin
@Gary - I definitely need to fix this before taking 1.1 up and out. It
shouldn’t be a problem for our other components because the unit tests of those
components don’t do anything with the directory in question, namely
“./target/commons-release-plugin”. I think it may be fairly quick to sort out,
but I just wanted to give you (and folks) a heads up.
-Rob
> On Feb 15, 2018, at 9:15 AM, Rob Tompkins (JIRA) wrote:
>
> Rob Tompkins created COMMONSSITE-102:
>
>
> Summary: Commons Release Plugin doesn't work with Commons Release
> Plugin
> Key: COMMONSSITE-102
> URL: https://issues.apache.org/jira/browse/COMMONSSITE-102
> Project: Commons All
> Issue Type: Bug
> Components: Commons Release Plugin
>Affects Versions: 1.0
>Reporter: Rob Tompkins
>Assignee: Rob Tompkins
> Fix For: 1.1
>
>
> The tests for the commons release plugin dirty the
> {{./target/commons-release-plugin}} folder for the sake of releasing. When
> this directory get's created in the mojos, we should check if the component
> we are building is the {{commons-release-plugin}}, and if that is the case
> and the mojo is the first one, namely {{detach-distributions}} we should
> delete the {{./target/commons-release-plugin}} directory.
>
>
>
> --
> This message was sent by Atlassian JIRA
> (v7.6.3#76005)
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
[VFS] trunk build failing in travis
I have forked VFS and tried to build it in my personal travis, and it is failing. https://travis-ci.org/ottobackwards/commons-vfs/builds/341963824 It also fails testing locally as well. Is this expected? I can’t get the the apache/commons-vfs travis site to check if it is building there. ottO
Re: [VFS] trunk build failing in travis
It is also failed on github On February 15, 2018 at 11:59:22, Otto Fowler (ottobackwa...@gmail.com) wrote: I have forked VFS and tried to build it in my personal travis, and it is failing. https://travis-ci.org/ottobackwards/commons-vfs/builds/341963824 It also fails testing locally as well. Is this expected? I can’t get the the apache/commons-vfs travis site to check if it is building there. ottO
[VFS] commons-parent 43 breaks VFS build : (was) trunk build failing in travis
So, It looks like upgrading the parent pom from #42 to #43 broke the build. This can be seen in the travis build history, and I have checked that mvn clean verify works with 42 and fails with 43. On February 15, 2018 at 12:07:45, Otto Fowler (ottobackwa...@gmail.com) wrote: It is also failed on github On February 15, 2018 at 11:59:22, Otto Fowler (ottobackwa...@gmail.com) wrote: I have forked VFS and tried to build it in my personal travis, and it is failing. https://travis-ci.org/ottobackwards/commons-vfs/builds/341963824 It also fails testing locally as well. Is this expected? I can’t get the the apache/commons-vfs travis site to check if it is building there. ottO
Re: [release-plugin] best multi-module project?
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 wrote: On Mon, 5 Feb 2018 21:49:52 -0500, Rob Tompkins wrote: On Feb 5, 2018, at 3:05 PM, Gilles wrote: On Mon, 5 Feb 2018 14:27:53 -0500, Rob Tompkins wrote: On Feb 5, 2018, at 2:22 PM, Gilles 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--- distribution-bundle commons-compX-mod1 commons-compX-mod2 ---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? 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 -dist-.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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [RNG] Towards v1.1
On Thu, 08 Feb 2018 17:18:44 +0100, Gilles wrote:
Ping?
...
On Fri, 26 Jan 2018 16:06:10 +0100, Gilles wrote:
Hello.
I propose to release the next version of "Commons RNG".
The web site with the current (today) development version (to
become 1.1) is on-line:
http://commons.apache.org/rng
Could someone please take on the following issue (JDK 9):
https://issues.apache.org/jira/browse/RNG-40
and fix it if necessary (each maven "module" should be a
"Java" module)? [I do not have Java 9 installed.]
I've just installed it. See other post (with subject: "Travis
build fails").
Is there a multi-module "Commons" project whose artefacts
are known to work as Java 9 modules?
I'd like to release v1.1 but I don't think it's worth
pretending that it is Java 9 compatible without doing
anything more than adding a MANIFEST entry (that could
be wrong).
I'd rather remove the "Automatic-Module-Name" and postpone
issue RNG-40 to v1.2 (even if it would be the only change
wrt v1.1).
With the latest commits ("JPMS integration example" module),
I'm reasonably confident that the "Automatic-Module-Name"
works fine (despite the unconventional difference between
module name and package name for "commons-rng-client-api").
Review welcome.
A release candidate will proposed in the coming days.
Gilles
Regards,
Gilles
Other remarks, suggestions, blockers?
Help is welcome for the release process using the new plugin
developed by Rob (and, along the way, update the documentation
located in the "doc/release" directory).
Thanks,
Gilles
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [release-plugin] best multi-module project?
> On Feb 15, 2018, at 2:37 PM, Gilles 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 wrote: On Mon, 5 Feb 2018 21:49:52 -0500, Rob Tompkins wrote: >> On Feb 5, 2018, at 3:05 PM, Gilles wrote: >> >> On Mon, 5 Feb 2018 14:27:53 -0500, Rob Tompkins wrote: On Feb 5, 2018, at 2:22 PM, Gilles 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--- >> >> distribution-bundle >> >>commons-compX-mod1 >>commons-compX-mod2 >> >> >> ---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 -dist-.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-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h.
Re: [release-plugin] best multi-module project?
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. Gary On Thu, Feb 15, 2018 at 1:01 PM, Rob Tompkins wrote: > > > > On Feb 15, 2018, at 2:37 PM, Gilles > 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 > wrote: > > On Mon, 5 Feb 2018 21:49:52 -0500, Rob Tompkins wrote: > >> On Feb 5, 2018, at 3:05 PM, Gilles > wrote: > >> > >> On Mon, 5 Feb 2018 14:27:53 -0500, Rob Tompkins wrote: > On Feb 5, 2018, at 2:22 PM, Gilles > 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--- > >> > >> distribution-bundle > >> > >>commons-compX-mod1 > >>commons-compX-mod2 > >> > >> > >> ---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 > -dist-.tar.gz > > Regards, > Gilles > > > Cheers, > > -Rob > > > >> > >> Gilles > >> > > I > > figure we pick one and make that the standard multi-module build > >>>
Re: [release-plugin] best multi-module project?
> On Feb 15, 2018, at 3:06 PM, Gary Gregory 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 wrote: >> >> >> >>> On Feb 15, 2018, at 2:37 PM, Gilles >> 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 >> wrote: >> >> On Mon, 5 Feb 2018 21:49:52 -0500, Rob Tompkins wrote: On Feb 5, 2018, at 3:05 PM, Gilles >> wrote: On Mon, 5 Feb 2018 14:27:53 -0500, Rob Tompkins wrote: >> On Feb 5, 2018, at 2:22 PM, Gilles >> 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--- distribution-bundle commons-compX-mod1 commons-compX-mod2 ---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 >> -dist-.tar.gz >> >> Regards, >> Gilles >> >>> Cheers, >>> -Rob >>> >>>
Re: [VFS] trunk build failing in travis
Hello Otto, can confirm that on my local Windows builds the latest parent makes the package Goal fail (w/ a crashing jvm when starting surefire). When reverting the parent surefire is not started and the build suceeds. Error Messages are however different from your Travis logs. Setting the old surefire Version (and the new parent) works for me: 2.19.1 Should we revert the parent Version or add the property (for now)? Gruss Bernd -- http://bernd.eckenfels.net Von: Otto Fowler Gesendet: Donnerstag, 15. Februar 2018 18:07 An: Commons Developers List Betreff: Re: [VFS] trunk build failing in travis It is also failed on github On February 15, 2018 at 11:59:22, Otto Fowler (ottobackwa...@gmail.com) wrote: I have forked VFS and tried to build it in my personal travis, and it is failing. https://travis-ci.org/ottobackwards/commons-vfs/builds/341963824 It also fails testing locally as well. Is this expected? I can’t get the the apache/commons-vfs travis site to check if it is building there. ottO
Re: [VFS] trunk build failing in travis
On Thu, Feb 15, 2018 at 6:42 PM, Bernd Eckenfels wrote: > Hello Otto, > > can confirm that on my local Windows builds the latest parent makes the > package Goal fail (w/ a crashing jvm when starting surefire). > > When reverting the parent surefire is not started and the build suceeds. > Error Messages are however different from your Travis logs. > > Setting the old surefire Version (and the new parent) works for me: > > 2.19.1 fails --> > > Should we revert the parent Version or add the property (for now)? > -1 to revert the parent +1 to adjusting the VFS POM Gary > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > Von: Otto Fowler > Gesendet: Donnerstag, 15. Februar 2018 18:07 > An: Commons Developers List > Betreff: Re: [VFS] trunk build failing in travis > > It is also failed on github > > > On February 15, 2018 at 11:59:22, Otto Fowler (ottobackwa...@gmail.com) > wrote: > > I have forked VFS and tried to build it in my personal travis, and it is > failing. > > https://travis-ci.org/ottobackwards/commons-vfs/builds/341963824 > > It also fails testing locally as well. > Is this expected? I can’t get the the apache/commons-vfs travis site to > check if it is building there. > > > ottO > >
Re: [VFS] trunk build failing in travis
Hello, I have accidentially pushed the changes in SVN on the 2.2 branch. Is there a way to revert the last two commits, maybe with tag copy or something? I am not too familiar. Can you help me to undo this? I would then commit them on trunk, again. You said „adjust pom“, did you mean the Version downgrade? Gruss Bernd -- http://bernd.eckenfels.net Von: Gary Gregory Gesendet: Freitag, 16. Februar 2018 02:57 An: Commons Developers List Betreff: Re: [VFS] trunk build failing in travis On Thu, Feb 15, 2018 at 6:42 PM, Bernd Eckenfels wrote: > Hello Otto, > > can confirm that on my local Windows builds the latest parent makes the > package Goal fail (w/ a crashing jvm when starting surefire). > > When reverting the parent surefire is not started and the build suceeds. > Error Messages are however different from your Travis logs. > > Setting the old surefire Version (and the new parent) works for me: > > 2.19.1 fails --> > > Should we revert the parent Version or add the property (for now)? > -1 to revert the parent +1 to adjusting the VFS POM Gary > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > Von: Otto Fowler > Gesendet: Donnerstag, 15. Februar 2018 18:07 > An: Commons Developers List > Betreff: Re: [VFS] trunk build failing in travis > > It is also failed on github > > > On February 15, 2018 at 11:59:22, Otto Fowler (ottobackwa...@gmail.com) > wrote: > > I have forked VFS and tried to build it in my personal travis, and it is > failing. > > https://travis-ci.org/ottobackwards/commons-vfs/builds/341963824 > > It also fails testing locally as well. > Is this expected? I can’t get the the apache/commons-vfs travis site to > check if it is building there. > > > ottO > >
Re: [VFS] trunk build failing in travis
Hello, I digged a bit deeper, and on my Windows System surefire 1.20.1 is failing because of this new „ping“ behavior: http://maven.apache.org/surefire/maven-surefire-plugin/examples/shutdown.html Looks like a bug that surefire is not falling back when wmic is not found (or better search for it), however after I fixed my PATH to include c:\Windows\System32\wbem the new surefire also works. -> the downgrade is wrong. Since I commited on the wrong tag again, can somebody rename it and copy the Revision 1811361 from rc2 again? Gruss Bernd
Re: [release-plugin] best multi-module project?
On Thu, 15 Feb 2018 15:01:23 -0500, Rob Tompkins wrote: On Feb 15, 2018, at 2:37 PM, Gilles 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 wrote: On Mon, 5 Feb 2018 21:49:52 -0500, Rob Tompkins wrote: On Feb 5, 2018, at 3:05 PM, Gilles wrote: On Mon, 5 Feb 2018 14:27:53 -0500, Rob Tompkins wrote: On Feb 5, 2018, at 2:22 PM, Gilles 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--- distribution-bundle commons-compX-mod1 commons-compX-mod2 ---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 -dist-.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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
