I would be happy with a version 1 that only handles single module
components. RERO!
Gary
On Thu, Jan 4, 2018 at 8:10 AM, Rob Tompkins <chtom...@gmail.com> wrote:
>
>
> > On Jan 4, 2018, at 9:32 AM, Gilles <gil...@harfang.homelinux.org> wrote:
> >
> > 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").
>
> Yes, that would indeed be a better end-goal. Would take more work from me
> to get there. My goal at this point is to get some quick improvement out
> the door and then RERO it to better. But I’ll have to write some tests for
> better confidence.
>
> >
> > 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
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
