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