You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@commons.apache.org by ch...@apache.org on 2018/01/04 01:59:45 UTC
svn commit: r24003 - in /dev/commons/text: ./ binaries/ source/
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
Re: [commons-release-plugin] (Was: svn commit: r24003 - in /dev/commons/text: ./ binaries/ source/)
Posted by Rob Tompkins <ch...@gmail.com>.
I think that I’ve accommodated for that, but to be certain I’ll stage the lang3 snapshot in the dev dust area in the morning to be certain.
-Rob
> On Jan 3, 2018, at 10:46 PM, Gary Gregory <ga...@gmail.com> wrote:
>
> Did you see my message about lang vs lang3, where the folder name does not
> match the artifact ID?
>
> Gary
>
>> On Jan 3, 2018 19:07, "Rob Tompkins" <ch...@gmail.com> 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.
>>
>> 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, chtompki@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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-release-plugin] (Was: svn commit: r24003 - in
/dev/commons/text: ./ binaries/ source/)
Posted by Gary Gregory <ga...@gmail.com>.
Did you see my message about lang vs lang3, where the folder name does not
match the artifact ID?
Gary
On Jan 3, 2018 19:07, "Rob Tompkins" <ch...@gmail.com> 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.
>
> 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, chtompki@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
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [commons-release-plugin] (Was: svn commit: r24003 - in
/dev/commons/text: ./ binaries/ source/)
Posted by sebb <se...@gmail.com>.
On 4 January 2018 at 13:30, Matt Benson <mb...@apache.org> wrote:
> Hi Rob,
> I noticed that your sample usage included authentication credentials at the
> command line. Does your work also support Maven settings-based
> authentication specified in server XML elements?
If not, there is some sample code you could lift from:
https://svn.apache.org/repos/asf/commons/dev/plugins/commonsdev-example-plugin/trunk/src/main/java/org/apache/commons/dev_plugins/example/ExampleMojo.java
> Matt
>
> On Jan 4, 2018 7:08 AM, "Rob Tompkins" <ch...@gmail.com> wrote:
>
>>
>>
>> > On Jan 4, 2018, at 5:24 AM, Gilles <gi...@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, chtompki@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?
>>
>> -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-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>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-release-plugin] (Was: svn commit: r24003 - in /dev/commons/text: ./ binaries/ source/)
Posted by Rob Tompkins <ch...@gmail.com>.
Yes. You can make those properties in the settings.xml, and if you’ve authenticated once with the svn server, you do not need to provide credentials.
> On Jan 4, 2018, at 8:30 AM, Matt Benson <mb...@apache.org> wrote:
>
> Hi Rob,
> I noticed that your sample usage included authentication credentials at the
> command line. Does your work also support Maven settings-based
> authentication specified in server XML elements?
>
> Matt
>
>> On Jan 4, 2018 7:08 AM, "Rob Tompkins" <ch...@gmail.com> wrote:
>>
>>
>>
>>> On Jan 4, 2018, at 5:24 AM, Gilles <gi...@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, chtompki@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?
>>
>> -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-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>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-release-plugin] (Was: svn commit: r24003 - in
/dev/commons/text: ./ binaries/ source/)
Posted by Matt Benson <mb...@apache.org>.
Hi Rob,
I noticed that your sample usage included authentication credentials at the
command line. Does your work also support Maven settings-based
authentication specified in server XML elements?
Matt
On Jan 4, 2018 7:08 AM, "Rob Tompkins" <ch...@gmail.com> wrote:
>
>
> > On Jan 4, 2018, at 5:24 AM, Gilles <gi...@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, chtompki@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?
>
> -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-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>
>
Re: [commons-release-plugin] (Was: svn commit: r24003 - in
/dev/commons/text: ./ binaries/ source/)
Posted by Gary Gregory <ga...@gmail.com>.
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 <ch...@gmail.com> wrote:
>
>
> > On Jan 4, 2018, at 9:32 AM, Gilles <gi...@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 <gi...@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 <gi...@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 <gi...@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, chtompki@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-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
Re: [commons-release-plugin] (Was: svn commit: r24003 - in /dev/commons/text: ./ binaries/ source/)
Posted by Rob Tompkins <ch...@gmail.com>.
> On Jan 4, 2018, at 9:32 AM, Gilles <gi...@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 <gi...@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 <gi...@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 <gi...@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, chtompki@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-release-plugin] (Was: svn commit: r24003 - in
/dev/commons/text: ./ binaries/ source/)
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 4 Jan 2018 09:21:52 -0500, Rob Tompkins wrote:
>> On Jan 4, 2018, at 9:18 AM, Gilles <gi...@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 <gi...@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
>>>>>> <gi...@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, chtompki@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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-release-plugin] (Was: svn commit: r24003 - in /dev/commons/text: ./ binaries/ source/)
Posted by Rob Tompkins <ch...@gmail.com>.
> On Jan 4, 2018, at 9:18 AM, Gilles <gi...@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 <gi...@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 <gi...@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, chtompki@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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-release-plugin] (Was: svn commit: r24003 - in
/dev/commons/text: ./ binaries/ source/)
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 4 Jan 2018 08:56:09 -0500, Rob Tompkins wrote:
>> On Jan 4, 2018, at 8:41 AM, Gilles <gi...@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 <gi...@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, chtompki@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.
>
> 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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-release-plugin] (Was: svn commit: r24003 - in /dev/commons/text: ./ binaries/ source/)
Posted by Rob Tompkins <ch...@gmail.com>.
> On Jan 4, 2018, at 8:41 AM, Gilles <gi...@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 <gi...@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, chtompki@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.
What is the release process here, and I’ll write something to get it to properly work.
-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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-release-plugin] (Was: svn commit: r24003 - in
/dev/commons/text: ./ binaries/ source/)
Posted by Gilles <gi...@harfang.homelinux.org>.
On Thu, 4 Jan 2018 08:08:05 -0500, Rob Tompkins wrote:
>> On Jan 4, 2018, at 5:24 AM, Gilles <gi...@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, chtompki@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.
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-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [commons-release-plugin] (Was: svn commit: r24003 - in
/dev/commons/text: ./ binaries/ source/)
Posted by Rob Tompkins <ch...@gmail.com>.
> On Jan 4, 2018, at 5:24 AM, Gilles <gi...@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, chtompki@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?
-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-unsubscribe@commons.apache.org <ma...@commons.apache.org>
> For additional commands, e-mail: dev-help@commons.apache.org <ma...@commons.apache.org>
Re: [commons-release-plugin] (Was: svn commit: r24003 - in
/dev/commons/text: ./ binaries/ source/)
Posted by Gilles <gi...@harfang.homelinux.org>.
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, chtompki@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.
Regards,
Gilles
[1] https://issues.apache.org/jira/browse/RNG-31
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
[commons-release-plugin] (Was: svn commit: r24003 - in
/dev/commons/text: ./ binaries/ source/)
Posted by Rob Tompkins <ch...@gmail.com>.
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.
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, chtompki@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org