Re: Questions regarding improving the Apache Commons release process.

[Rob Tompkins]

Stephen,

I can’t thank you enough for your reply. I’ll take your suggestions and 
continue to sandbox around using the maven-release-plugin as a guideline.

All the best and happy holidays,
-Rob

> On Dec 26, 2017, at 5:27 AM, Stephen Connolly 
>  wrote:
> 
> On Tue 26 Dec 2017 at 03:10, Rob Tompkins  > wrote:
> 
>> Hello all,
>> 
>> Pardon, maybe this should have gone to your @user list, but why not ping
>> the dev crew. I’ve been playing around the ideas surrounding our fairly
>> manual release process for the components in Commons, and I was hoping for
>> some insights.
>> 
>> Scripting the version changes isn’t really that big of a deal for us, and
>> that I can manage. But, when it comes to publishing our artifacts to the
>> apache nexus repository, and then separately publishing our -src and -bin
>> assemblies to the dev dist subversion repository (and consequently deleting
>> those artifacts from nexus as they’re “attached” for the purpose of gpg
>> signing), I feel it a tad cumbersome.
>> 
>> I’ve fiddled around a little with the idea of detaching the -src and -bin
>> assemblies after gpg signing with some success, but then I have to delve
>> into the mechanics of publishing those up to the subversion repository, and
>> clearly that problem has already been solved.
> 
> 
> Is your problem you don’t want those going to Nexus staging but only to
> dist? Or is it that you want them *also* going to dist.
> 
> Personally... I see no reason to remove them from going to Nexus staging
> (in fact I have a background plan to add secondary signing support to
> staging... i’m Waiting to see the Nexus 3 staging APIs before attempting
> though. That would mean that the PMC would be able to *add* their GPG
> signature to the staged artifacts as part of the voting... in which case
> you’d want to hold off uploading to dist until *after* the vote so you get
> the full set of signatures)
> 
> If you want to upload a subset of attached artifacts to dist as part of the
> release, that seems much more tenable... just a derivative of the
> scm-publish plugin from what I can see.
> 
> So I find myself in the space of trying to shoehorn our process into its
>> the main maven-release-plugin, which I’ve found a tad difficult, versus
>> writing our own release plugin, which feels like I would be duplicating
>> tons of code (which I don’t want to do).
> 
> 
> So the release plugin is really two parts:
> 
> 1. A toolkit for writing release plugins
> 
> 2. An example that does the job for the requirements of the Maven TLP and
> has seemed “sufficient” for a lot of other people.
> 
> As such, if you have different needs, do not feel bad about having to
> encode differently... hopefully the toolkit half of the codebase is
> sufficient for you.
> 
>> 
>> 
>> I’m curious if you guys have any thoughts on the matter as I’ve been
>> playing around in the space for a little while now.
>> 
>> Cheers and happy holidays from UTC-5,
>> -Rob
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@maven.apache.org 
>> 
>> 
>> --
> Sent from my phone

Re: Questions regarding improving the Apache Commons release process.

[sebb]

On 26 December 2017 at 18:48, Matt Sicker  wrote:
> On 26 December 2017 at 04:27, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> Personally... I see no reason to remove them from going to Nexus staging
>> (in fact I have a background plan to add secondary signing support to
>> staging... i’m Waiting to see the Nexus 3 staging APIs before attempting
>> though. That would mean that the PMC would be able to *add* their GPG
>> signature to the staged artifacts as part of the voting... in which case
>> you’d want to hold off uploading to dist until *after* the vote so you get
>> the full set of signatures)
>>

It would be better to upload the original files (including RM-only
sig) to dist/dev.
The updated sigs can always be replaced on dist/dev just before publication.

> Wow, this sounds really cool! So the PMC votes can add a vote by adding
> their GPG signature? That's a really nifty idea.
>
> --
> Matt Sicker 

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

RE: [beanutils] Moving to beanutils2

[dbrosIus]

Agree, I can do this tonite. 

 Original message 
From: Gary Gregory  
Date: 12/27/17  1:55 PM  (GMT-05:00) 
To: Commons Developers List  
Subject: [beanutils] Moving to beanutils2 

The changes for:

BEANUTILS-500 Upgrade commons-collections to 4

break BC (see BEANUTILS-500).

Therefore, I created BEANUTILS-503: Change packaging from
org.apache.commons.beanutils to org.apache.commons.beanutils2

This change should happen sooner rather than later IMO to allow folks using
SNAPSHOT builds to adapt.

Thoughts?

Gary

[beanutils] Update to Java 7

[Gary Gregory]

FYI:

I plan on updating [beanutils] to Java 7. This should make the code base
slightly more appealing.

Gary

[beanutils] Moving to beanutils2

[Gary Gregory]

The changes for:

BEANUTILS-500 Upgrade commons-collections to 4

break BC (see BEANUTILS-500).

Therefore, I created BEANUTILS-503: Change packaging from
org.apache.commons.beanutils to org.apache.commons.beanutils2

This change should happen sooner rather than later IMO to allow folks using
SNAPSHOT builds to adapt.

Thoughts?

Gary

[beanutils] Missing entries in changes.xml since 1.9.3

[Gary Gregory]

Hi All,

Whomever committed since 1.9.3, please update the changes.xml file to
reflect changes that have JIRA issues like BEANUTILS-500.

Thank you,
Gary

[ANNOUNCEMENT] Apache Apache Commons DBCP 2.2.0

[Gary Gregory]

The Apache Commons DBCP team is pleased to announce the release of Apache
Apache Commons DBCP 2.2.0.

Apache Commons DBCP software implements Database Connection Pooling.

This is a minor release, including bug fixes and enhancements.

Changes in this version include:

New features:
o DBCP-451:  Add constructor DriverManagerConnectionFactory(String).
o DBCP-462:  Refactoring to prepare for a future patch to enable pooling of
all
 prepared and callable statements in PoolingConnection. Thanks
to Keiichi Fujino.
o DBCP-458:  Make it simpler to extend BasicDataSource to allow sub-classes
to
 provide custom GenericObjectPool implementations. Thanks to
Adrian Tarau.
o DBCP-474:  Enable pooling of all prepared and callable statements
 inPoolingConnection. Thanks to Keiichi Fujino.

Fixed Bugs:
o DBCP-481:  Update Apache Commons Pool from 2.4.2 to 2.5.0. Thanks to Gary
Gregory.
o DBCP-454:  OSGi declarations contain multiple import headers for
javax.transaction. Thanks to Philipp Marx, Matt Sicker.
o DBCP-478:  Wrong parameter name in site documentation for BasicDataSource
Configuration Parameters. Thanks to nicola mele.
o DBCP-452:  Add jmxName to properties set by BasicDataSourceFactory.  This
 enables container-managed pools created from JNDI Resource
 definitions to enable JMX by supplying a valid root JMX name.
o DBCP-446:  NullPointerException thrown when calling
ManagedConnection.isClosed(). Thanks to Gary Gregory, feng yang, Euclides
M, Phil Steitz.
o DBCP-444:  InvalidateConnection can result in closed connection returned
by getConnection.
o DBCP-449:  Complete the fix for DBCP-418, enabling PoolableConnection
class to load in environments
 (such as GAE) where the JMX ManagementFactory is not
available. Thanks to Grzegorz D.
o DBCP-455:  Ensure that the cacheState setting is used when statement
pooling is
 disabled. Thanks to Kyohei Nakamura.
o DBCP-453:  Ensure that setSoftMinEvictableIdleTimeMillis is used when
working with
 BasicDataSource. Thanks to Philipp Marx.
o DBCP-456:  Correct the name of the configuration attribute
 softMinEvictableIdleTimeMillis. Thanks to Kyohei Nakamura.
o DBCP-472:  Avoid potential infinite loops when checking if an
SQLException is fatal
 for a connection or not.
o DBCP-468:  Expand the fail-fast for fatal connection errors feature to
include
 managed connections.
o DBCP-463:  Correct a typo in the method name
 PoolableConnectionFactory#setMaxOpenPreparedStatements. The
old method
 remains but is deprecated so not to break clients currently
using the
 incorrect name.
o DBCP-459:  Ensure that a thread's interrupt status is visible to the
caller if the
 thread is interrupted during a call to
 PoolingDataSource.getConnection().
o DBCP-457:  When using a BasicDataSource, pass changes related to the
handling of
 abandoned connections to the underlying pool so that the pool
 configuration may be updated dynamically.


For complete information on Apache Commons DBCP, including instructions on
how to submit bug reports,
patches, or suggestions for improvement, see the Apache Apache Commons DBCP
website:

http://commons.apache.org/dbcp/

Gary Gregory
Apache Commons V.P., Chair.

Re: [ALL] Who want's access to @ApacheCommons

[Sergio Fernández]

I guess if the people managing the account could just RT the
project-related tweets (particularly announcements), I think that would be
great.

I'm happy to help on that, but I'm just a raw committer, not sure if it
would be appropriate.

On Tue, Dec 26, 2017 at 2:22 AM, Benedikt Ritter  wrote:

> Hi,
>
> I’ve created the Apache Commons twitter account [1] a few years ago. I try
> to announce anything that might be of interest for Commons users. Since my
> activity for the project varies a bit depending on what is going on in my
> life, I think it would be good if more people would have access to the
> twitter account.
> Twitter has ha nice feature, called Teams, where you can give other
> Twitter users access to a team account. So if anybody wants to have access,
> just ping me with your Twitter user name and I can grant you access.
>
> Regards,
> Benedikt
>
> [1] https://twitter.com/ApacheCommons
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] Who want's access to @ApacheCommons

[Gary Gregory]

Thanks B!

On Dec 27, 2017 08:47, "Benedikt Ritter"  wrote:

>
>
> > Am 26.12.2017 um 16:41 schrieb Gary Gregory :
> >
> > GaryGregory
>
> I’ve added you as admin.
>
> Regards,
> Benedikt
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

Re: [ALL] Who want's access to @ApacheCommons

[Benedikt Ritter]

> Am 26.12.2017 um 16:41 schrieb Gary Gregory :
> 
> GaryGregory

I’ve added you as admin.

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

Re: [math] stat package

[Gilles]

Hello.

On Fri, 22 Dec 2017 17:00:10 -0700, Gary Gregory wrote:

Hi All,

In light of the [math] work being done, does anyone have thoughts on 
what
should happen to the stat packages? As in stay in [math] or [split] 
into a

new component or module?

Gary


It will come as no surprise that, in principle, I favour "split".
[It is telling that the initial proposal[1] for the "component"
listed "statistical algorithms" and "mathematical algorithms" on
a par (with the former cited first!).]

There are only a handful uses of classes from "o.a.c.m.stat" by
other parts of CM, most of which in "o.a.c.m.distribution" and
the remainder in "o.a.c.m.ml.clustering".

Setting up of "Commons Stat" would not be an easy one like "Commons
Geometry" since package "o.a.c.m.stat" depends on classes in
 * o.a.c.m.linear
 * o.a.c.m.analysis
 * o.a.c.m.distribution

Package "linear" itself requires a lot of work (but we could perhaps
hide its API from the POV of "Commons Stat" users).
Also to be noted: some design issues were uncovered in "stat" (see
JIRA).

I think that the contents of "o.a.c.m.distribution" would nicely fit
as a module of "Commons Stat". [Quite some work has been done on
"distribution" since the last release of CM, thus we could imagine
to release versions 0.x of "Commons Stat" with contents gradually
added as issues are fixed.]


Gilles

[1] http://commons.apache.org/proper/commons-math/proposal.html

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