[Signing] New component for code signing

[Mark Thomas]

All,

As you may know, the ASF has been using a code signing service for a
number of years provided by Symantec. We use it to sign Commons Daemon
Windows binaries.

The code signing service has a web based GUI and a SOAP based API.
Tomcat has written an Ant task to use the SOAP API and Sling has taken
this used and used it as the basis for a Maven plug-in.

Currently, the Ant task is hosted within the Tomcat codebase and the
Maven plug-in within Sling. Both communities would like to move this to
a better home where it can more easily be re-used by other Apache
projects and other organisations using Symantec's code signing service.

After some thought and discussion, we (Robert Munteanu and I) would like
to propose this code signing component as a new component at Commons.
Our reasons for this are as follows:

- The code is written in Java
- It is a relatively small component
- It is a utility likely to be of interest to multiple Apache projects
- If it is going to be re-used across multiple projects, it needs to be
  formally released and that requires a PMC

If accepted the plan would be:
- commit the original Tomcat code for the Ant task
- refactor it to allow re-use of code common to the Ant task and Maven
  plug-in
- add the Maven plug-in
- release it as a single JAR that provided both the Ant task and the
  Maven plug-in
- Ongoing review and maintenance (there are a couple of areas that could
  benefit from some improvement)

Thoughts? Comments?

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-parent][commons-release-plugin] integration of

[Gary Gregory]

On Mon, Jan 22, 2018 at 7:12 PM, Rob Tompkins  wrote:

> Do you think the “-Dcommons.release.dryRun” command line parameter is
> worth rolling another RC?


Not for me.


> Also, I could use the plugin to do the release too just for the sake of
> testing it more throughly?
>

Absolutely! :-)

Then I would like you to try to release commons-parent with the new plugin
baked in so that components can use it easily. Or I can do it.

Gary



>
> > On Jan 22, 2018, at 9:01 PM, Gary Gregory 
> wrote:
> >
> > Ok, please do so soon. I'm itchin' to try it :-)
> >
> > Gary
> >
> > On Jan 22, 2018 6:56 PM, "Rob Tompkins"  wrote:
> >
> >> I do think that I should get a 1.1 out before we release commons-parent
> >> with it though.
> >>
> >>> On Jan 22, 2018, at 8:10 PM, Rob Tompkins  wrote:
> >>>
> >>> +1
> >>>
>  On Jan 22, 2018, at 7:41 PM, Gary Gregory 
> >> wrote:
> 
>  Rob, All:
> 
>  WDYT of https://pastebin.com/HtMXZhwh
> 
>  ?
> 
>  Gary
> >>
> >>
> >> -
> >> 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
>
>

Re: [commons-parent][commons-release-plugin] integration of

[Rob Tompkins]

Do you think the “-Dcommons.release.dryRun” command line parameter is worth 
rolling another RC? Also, I could use the plugin to do the release too just for 
the sake of testing it more throughly?

> On Jan 22, 2018, at 9:01 PM, Gary Gregory  wrote:
> 
> Ok, please do so soon. I'm itchin' to try it :-)
> 
> Gary
> 
> On Jan 22, 2018 6:56 PM, "Rob Tompkins"  wrote:
> 
>> I do think that I should get a 1.1 out before we release commons-parent
>> with it though.
>> 
>>> On Jan 22, 2018, at 8:10 PM, Rob Tompkins  wrote:
>>> 
>>> +1
>>> 
 On Jan 22, 2018, at 7:41 PM, Gary Gregory 
>> wrote:
 
 Rob, All:
 
 WDYT of https://pastebin.com/HtMXZhwh
 
 ?
 
 Gary
>> 
>> 
>> -
>> 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

Re: [commons-parent][commons-release-plugin] integration of

[Gary Gregory]

Ok, please do so soon. I'm itchin' to try it :-)

Gary

On Jan 22, 2018 6:56 PM, "Rob Tompkins"  wrote:

> I do think that I should get a 1.1 out before we release commons-parent
> with it though.
>
> > On Jan 22, 2018, at 8:10 PM, Rob Tompkins  wrote:
> >
> > +1
> >
> >> On Jan 22, 2018, at 7:41 PM, Gary Gregory 
> wrote:
> >>
> >> Rob, All:
> >>
> >> WDYT of https://pastebin.com/HtMXZhwh
> >>
> >> ?
> >>
> >> Gary
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [commons-parent][commons-release-plugin] integration of

[Rob Tompkins]

I do think that I should get a 1.1 out before we release commons-parent with it 
though.

> On Jan 22, 2018, at 8:10 PM, Rob Tompkins  wrote:
> 
> +1
> 
>> On Jan 22, 2018, at 7:41 PM, Gary Gregory  wrote:
>> 
>> Rob, All:
>> 
>> WDYT of https://pastebin.com/HtMXZhwh
>> 
>> ?
>> 
>> Gary


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [commons-parent][commons-release-plugin] integration of

[Rob Tompkins]

+1

> On Jan 22, 2018, at 7:41 PM, Gary Gregory  wrote:
> 
> Rob, All:
> 
> WDYT of https://pastebin.com/HtMXZhwh
> 
> ?
> 
> Gary

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[commons-parent][commons-release-plugin] integration of

[Gary Gregory]

Rob, All:

WDYT of https://pastebin.com/HtMXZhwh

?

Gary

Re: [Statistics] Ready for work

[Gilles]

On Mon, 22 Jan 2018 15:50:22 +0100, Eric Barnhill wrote:
On Sun, Jan 21, 2018 at 5:45 PM, Gilles 


wrote:




Next step should probably be:

 * create the web site directory



Do you mean with mvn site?


For a modular project it is
 $ mvn site site:stage
so that all modules' contents are collected into the parent's
"target" directory.


The target folder is in the .gitignore .


The contents must be copied to "site-content" and then commit
to a "svn"-managed directory.
I've created that directory, but there is no link yet from
"Commons" main site.

I'm adding the required files so that "mvn site" will
successfully complete.
This is a fairly "manual" process; fortunately, it does not
occur too often. ;-)

You could perhaps start to look at the actual contents that
needs to move from Commons Math, and propose a plan and a
list of issues to watch out.

Thanks a lot,
Gilles




-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [Statistics] Ready for work

[Eric Barnhill]

 On Sun, Jan 21, 2018 at 5:45 PM, Gilles 
wrote:

>
>> Next step should probably be:
>  * create the web site directory
>

Do you mean with mvn site? The target folder is in the .gitignore .

Re: [compress] TarArchiveEntry and Windows drive letter

[sebb]

On 22 January 2018 at 09:53, Stefan Bodewig  wrote:
> On 2018-01-21, sebb wrote:
>
>> On 21 January 2018 at 16:07, Stefan Bodewig  wrote:
>
>>> The contract of tar archives is they contain relative path names. GNU
>>> tar strips leading slashes both when creating archives and when
>>> extracting archives who's entry names contain leading slashes. Sticking
>>> with that contract I still believe we should remove leading slashes by
>>> default - and removing the drive letters is the Windows equivalent of it
>>> IMHO. That's why I suggest to keep the drive letter in the
>>> preserveLeadingSlashes == true case.
>
>> I would expect the Windows default behaviour to generate/use relative
>> names only.
>> This means dropping both the drive letter *and* any leading \ or /.
>
> This is what happens right now.
>
>> Optionally, tar should be able to preserve/use absolute path names.
>> But the user must specify this.
>
> This is what I suggested. Change the meaning of "preserveLeadingSlashes"
> to "preserveAbsolutePath" and use it to keep the drive letter on
> Windows.
>
> The current code will always strip the drive letter spec.

In that case, I agree with you.

Also as a name,  'preserveLeadingSlashes' only makes sense on a unix
system, and it describes the processing rather than the functionality.

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

JDK 10 Early Access b40 & JDK 8u172 Early Access b02 are available on jdk.java.net

[Rory O'Donnell]

 Hi Benedikt,

Happy New Year!

*OpenJDK builds - *JDK 10 Early Access build 40 is available at 
http://jdk.java.net/10/


 * These early-access, open-source builds are provided under the GNU
   General Public License, version 2, with the Classpath Exception
   .
 * Summary of changes :-
   https://download.java.net/java/jdk10/archive/40/jdk-10+40.html

*JDK 10 will enter Rampdown Phase Two on Thursday the 18th of January, 
2018. *


 * More details , see Mark Reinhold's email to jdk-dev mailing list [1]
 * The Rampdown Phase Two process will be similar to that of JDK 9 [2].
 * JDK 10 Schedule, Status & Features are available [3]

*JDK **8u172 Early-Access build 03*is available at :- 
http://jdk.java.net/8/


 * Summary of Changes here :-
   https://download.java.net/java/jdk8u172/changes/jdk8u172-b02.html




Regards,
Rory

[1] http://mail.openjdk.java.net/pipermail/jdk-dev/2018-January/000416.html
[2] http://openjdk.java.net/projects/jdk/10/rdp-2
[3] http://openjdk.java.net/projects/jdk/10/

--
Rgds,Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin,Ireland

Re: [compress] TarArchiveEntry and Windows drive letter

[Stefan Bodewig]

On 2018-01-21, sebb wrote:

> On 21 January 2018 at 16:07, Stefan Bodewig  wrote:

>> The contract of tar archives is they contain relative path names. GNU
>> tar strips leading slashes both when creating archives and when
>> extracting archives who's entry names contain leading slashes. Sticking
>> with that contract I still believe we should remove leading slashes by
>> default - and removing the drive letters is the Windows equivalent of it
>> IMHO. That's why I suggest to keep the drive letter in the
>> preserveLeadingSlashes == true case.

> I would expect the Windows default behaviour to generate/use relative
> names only.
> This means dropping both the drive letter *and* any leading \ or /.

This is what happens right now.

> Optionally, tar should be able to preserve/use absolute path names.
> But the user must specify this.

This is what I suggested. Change the meaning of "preserveLeadingSlashes"
to "preserveAbsolutePath" and use it to keep the drive letter on
Windows.

The current code will always strip the drive letter spec.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org