On Thu, 4 Jan 2018 09:21:52 -0500, Rob Tompkins wrote:
On Jan 4, 2018, at 9:18 AM, Gilles <gil...@harfang.homelinux.org>
wrote:
On Thu, 4 Jan 2018 08:56:09 -0500, Rob Tompkins wrote:
On Jan 4, 2018, at 8:41 AM, Gilles <gil...@harfang.homelinux.org>
wrote:
On Thu, 4 Jan 2018 08:08:05 -0500, Rob Tompkins wrote:
On Jan 4, 2018, at 5:24 AM, Gilles
<gil...@harfang.homelinux.org> wrote:
Hi.
On Wed, 3 Jan 2018 21:07:41 -0500, Rob Tompkins wrote:
Hello all,
So, now I have a plugin that detaches the distributions, zips
the
site, and then commits the zipped site, RELEASE-NOTES.txt (from
the
root), and the distributions to the svn staging area. All from:
mvn clean site deploy -Prelease -Duser.name=chtompki
-Duser.password=<my_password>
Thoughts on pulling this in as a new component and starting to
get it
to a more formal state? I’m sure we could add more, but this
does take
away a considerable portion of the manual steps.
Does it work for modular components? [See below.]
Also, as I said before I’ve not written any maven
unit/integration
tests. I do know that I could contrive some unit tests using
PowerMockito (but that feels mildly pointless because it is
indeed a
contrivance with little value). So, I will try to investigate
the
maven testing mechanics, but what I currently have does indeed
work.
Should I call a vote for the new component?
Cheers,
-Rob
On Jan 3, 2018, at 8:59 PM, chtom...@apache.org wrote:
Author: chtompki
Date: Thu Jan 4 01:59:44 2018
New Revision: 24003
Log:
Removing commons-text-1.3-SNAPSHOT
Removed:
dev/commons/text/RELEASE-NOTES.txt
dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz
dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz.asc
dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz.md5
dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.tar.gz.sha1
dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip
dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip.asc
dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip.md5
dev/commons/text/binaries/commons-text-1.3-SNAPSHOT-bin.zip.sha1
dev/commons/text/site.zip
dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz
dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz.asc
dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz.md5
dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.tar.gz.sha1
dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip
dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip.asc
dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip.md5
dev/commons/text/source/commons-text-1.3-SNAPSHOT-src.zip.sha1
In the case of a modular component, the file
commons-<name>-<version>-bin.tar.gz
should contain the JAR files (codes, sources, javadoc) of all
the modules, and the file
commons-<name>-<version>-src.tar.gz
should contain the (main) source codes of all the modules.
If your new plugin does that, then it will be unnecessary to
add an ad-hoc module like "dist-archive" (see e.g. [1]) that
only exists for the sake of creating those ("include-all")
"src" and "bin" files.
Yes. Your have a good point point Gilles.
It would seem that we would want some flavour of a new
distribution
handling mojo for just this case, but I don’t foresee that as
being
overly difficult, we’d have to just accommodate for a slightly
more
manual process. I still think that with a little work we could
make
the signing of those artifacts as well as the upload to svn maven
target based as opposed to you having to copy files around on
your
machine and check them in manually.
Thoughts?
Why "more manual process"? Is the modular case any different from
the
maven API POV (I'd imagine it's "just" building recursively)?
Do you plan to add the necessary code as part of your current work
on
this new plugin? This will surely help for the release of at
least
RNG
Numbers
Statistics
Math
and any other currently (or future) modular component.
I can make it work. It just wasn’t entirely clear to me what
command
you run to build the dists. And, it looks as if you are building
dists
(that aren’t published) for every module in the build.
[Talking about RNG.]
All modules are published/deployed to Nexus, except "dist-archive"
that only exists to bundle the contents of all the other modules
(separate "bin" and "src", as per Apache requirement).
For that purpose, I had to create a custom POM (in "dist-archive")
to run the "assembly" plugin.
Ok yeah, that’s what I was thinking, and I would (after writing the
code to do this) have you add another target after “assembly:single”
that would sign and check in the dists to svn. Does that sound
appropriate?
That would already be an improvement; but I had hoped for complete
automation: maven "knows" about the modules (they are declared in
the POMs); hence it seems natural that the "deploy" target should
be able to collect all the appropriate stuff out of the module
directories and make the bundle (as it does for each individual
module: signing and uploading to Nexus, without manual intervention
and no need to specify assembly directives (in "src/assembly").
Best,
Gilles
What is the release process here, and I’ll write something to get
it
to properly work.
AFAICT, the release process is standard.[1]
Everything works smoothly except for making the Apache distribution
(when the project is modular).
See issue:
https://issues.apache.org/jira/browse/RNG-31
Regards,
Gilles
[1] See e.g.
https://git1-us-west.apache.org/repos/asf?p=commons-rng.git;a=blob;f=doc/release/release.howto.txt;h=d1d96ed6baa522cb0abedd57e6022a819a5a6a01;hb=HEAD
-Rob
Thanks,
Gilles
-Rob
Regards,
Gilles
[1] https://issues.apache.org/jira/browse/RNG-31
<https://issues.apache.org/jira/browse/RNG-31>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
