commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Tompkins <chtom...@gmail.com>
Subject Re: [commons-release-plugin] (Was: svn commit: r24003 - in /dev/commons/text: ./ binaries/ source/)
Date Thu, 04 Jan 2018 13:40:27 GMT
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 <mbenson@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" <chtompki@gmail.com> wrote:
>> 
>> 
>> 
>>> On Jan 4, 2018, at 5:24 AM, Gilles <gilles@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


Mime
View raw message