Re: Discussion: New commons module/project

What can / does commons provide that cannot be done with GitHub? chas > On Feb 13, 2018, at 5:58 PM, Ralph Goers wrote: > > If this was a project to create specs AND provide reference implementations I > think it would make sense. I don’t see how a project that

Re: [all] Preventing assembly archives from being deployed to nexus.

I’ve been down this path about a year ago. We’re relying on the side effect of these assemblies being artifacts for the GPG plugin to sign them. There is an outstanding JIRA (https://issues.apache.org/jira/browse/MGPG-43 ) to support signing

[net] URLStreamHandler / URLStreamHandlerFactory implementations

Has anyone considered implementing URLStreamHandler(s) for the protocols in commons net? thanks, chas - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org

Re: [ALL] Changing the commons process

I tested IDEs with a non-standard packaging of -sources.jar; java sources were inside of src/main/java/ folder. - Eclipse was able to use. - IntelliJ was able to use with a few extra clicks. - Netbeans was NOT able to use. I don’t think this option should be pursued further. A better

Re: [ALL] Changing the commons process

nce the IDE expect a > package-like directory structure. I am not sure it would work with src/main/ > prefix. > > Gruss > Bernd > -- > http://bernd.eckenfels.net > > On Fri, Dec 23, 2016 at 11:33 PM +0100, "Gary Gregory" > <garydgreg...@gmail.com&

[ALL] Changing the commons process

Several recent email threads have discussed our parent pom and release process. The process we have derive from Apache Common’s rich history which pre-dates many current distribution practices. I’d like to summarize several quirks with our current releases: The official release source tarball

Re: [parent] Publishing src Distributions to Nexus?

> On Dec 23, 2016, at 3:41 AM, Stefan Bodewig wrote: > > Hi all > > the RC1 vote for Parent 42 failed because it no longer pulishes the > source tarballs/zips to Nexus. > > The change was > which has > obviously been a

Commons release policy

To follow up the thread on releasing parent 42 and exactly what needs to signed, etc. I’ve researched asf release policy. Here’s the gist: 1. Every ASF release must contain a source package, which must be sufficient for a user to build and test the release provided they have access to the

Re: [VOTE][LAZY] Release Commons Parent POM 42 based on RC1

find a way to sign non-attachments. chas > On Dec 2, 2016, at 7:13 PM, Gary Gregory <garydgreg...@gmail.com> wrote: > > On Fri, Dec 2, 2016 at 7:03 PM, Charles Honton <c...@honton.org > <mailto:c...@honton.org>> wrote: > >> Signing is a requirement?

Re: [VOTE][LAZY] Release Commons Parent POM 42 based on RC1

Signing is a requirement? > On Dec 2, 2016, at 4:53 PM, Gary Gregory wrote: > > On Thu, Dec 1, 2016 at 3:26 AM, Stian Soiland-Reyes > wrote: > >> I did "mvn clean install -Prelease" from SVN and got in target/: >> >>

Re: [CANCE][VOTE][LAZY] Release Commons Parent POM 42 based on RC1

Why do we expect the src zip to be present in the maven repository? No other commons project pushes the src zip/gz to maven central. If we want to supply src zip/gz as a convenience, why wouldn’t it be at http://commons.apache.org/proper/ as all other

Re: [VOTE][RC5] Release "Apache Commons RNG" version 1.0

Re: P.S. Is everyone happy with having to manually delete one-by-one all the distribution archives spuriously uploaded to Nexus? Commons Parent 42 has a false setting for assembly plugin to prevent zips/gz from being uploaded to Nexus. Unfortunately, the last vote for parent 42 was cancelled

Re: [VOTE][LAZY] Release Commons Parent POM 42 based on RC1

I added the false to explicitly deal with the excess artifacts being pushed to Nexus. Preparations For A Release - Creating a Release Candidate - Step By Step states: Unfortunately this uploads more than should be part of the Maven repository,

Re: [ALL] Version number(s) for modular components

My experience suggests that the "one repository, one version" rule works best. This, however, does not solve the concern of allowing quick releases with multiple simultaneous features. This concern is better solved with feature branches. Mainline branch, (“master”) must be releasable at

Re: [ANNOUNCE] Apache Commons Lang 3.5 Released!

Thanks Benedikt! > On Oct 18, 2016, at 11:44 PM, Benedikt Ritter wrote: > > The Apache Commons community is happy to announce the availability of > Apache Commons Lang 3.5. > > Apache Commons Lang provides helper utilities for the java.lang API, > notably String

Re: [LANG] Towards 3.5

There are multiple causes to LANG-1265. The two I have traced look like incomplete locale/timezone data from the CLDR provider. I recommend moving forward on 3.5 release without solving LANG-1265. chas >> On Sep 26, 2016, at 10:29 AM, Benedikt Ritter wrote: >> >> Hi

Re: [VOTE] Release Configuration 2.1 based on RC3

Either ’a’ or ‘b’. I’m all for anything that makes releasing easier. +1 for requiring java 1.7 or 1.8 to build site +1 (in general) for requiring java 1.7 or 1.8 to build artifacts, even if project is targeted to 1.6, 1.5, etc. chas > On Aug 13, 2016, at 12:37 PM, Oliver Heger

[ANNOUNCEMENT] Commons parent 41 Released

Commons parent 41 has been released. Commons parent is the maven parent of most commons components. This release includes plugin version updates and two new profiles to support source compatibility checking. Details can be found at the commons parent site:

Re: [VOTE] Release commons-parent 41 based on RC2

This VOTE passed with lazy consensus. No explicit votes. No vetoes. chas > On Aug 3, 2016, at 9:17 PM, Charles Honton <c...@honton.org> wrote: > > We have added a significant enhancements since commons-parent 40 was released, > so I would like to release commons-parent 41. &

[VOTE] Release commons-parent 41 based on RC2

We have added a significant enhancements since commons-parent 40 was released, so I would like to release commons-parent 41. commons-parent 41 RC2 is available for review here: https://dist.apache.org/repos/dist/dev/commons/commons-parent/commons-parent-41-RC2 (svn revision 14654) The tag

Re: [configuration] Checkstyle settings

Why wouldn’t we want build to fail early if incorrect style is used? chas > On Jul 31, 2016, at 11:09 AM, Oliver Heger > wrote: > > Hi, > > in revision 1742698 the checkstyle configuration has been changed. The > log says "fixed checkstyle violations, updated to

[ALL] Create a pom parent 41 release

Any objections to creating a release for pom parent 41? This currently has one change; two new profiles that enable clirr or japicmp for binary compatibility reports. chas - To unsubscribe, e-mail:

Re: [lang] replace clirr with japicmp

wrote: > >> Jochen Wiedmann <jochen.wiedm...@gmail.com> schrieb am Di., 14. Juni 2016 >> um 08:14 Uhr: >> >>> On Tue, Jun 14, 2016 at 8:11 AM, Benedikt Ritter <brit...@apache.org> >>> wrote: >>> >>>> Charles Honton <c...@h

[lang] replace clirr with japicmp

Now that lang is compiled with java6, clirr is broken. Do we want to update to a more modern report like japicmp ? The pom change is something like com.github.siom79.japicmp japicmp-maven-plugin 0.8.0 true true

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

Please look at https://github.com/apache/commons-lang/pull/165/files <https://github.com/apache/commons-lang/pull/165/files> for the suggested javadoc changes. regards, chas > On Jun 12, 2016, at 6:18 PM, Charles Honton <c...@honton.org> wrote: > > No, these are the in

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

; Should these be package private then? > > G > On Jun 12, 2016 5:32 PM, "Charles Honton" <c...@honton.org > <mailto:c...@honton.org>> wrote: > >> DateParser and DatePrinter interfaces are not just for internal use. I >> will gladly add javad

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

, chas > On Jun 12, 2016, at 5:09 PM, sebb <seb...@gmail.com> wrote: > > On 13 June 2016 at 01:00, Charles Honton <c...@honton.org> wrote: >> I added DateParser and DatePrinter interfaces in 3.2. These are not >> expected to be implemented by end users, only by

Re: [lang] Time Package: Binary Breaking Changes Between 3.4 and Master

I added DateParser and DatePrinter interfaces in 3.2. These are not expected to be implemented by end users, only by org.apache.commons.lang3.time classes. The interfaces exist to hide the actual implementation classes. Please look at FastDateFormat javadoc for the factory pattern that

Re: BCEL 6 API breakage

How Apache Commons BCEL got to where it is currently. 1. I wanted to release a version of BCEL which would support Java 6 and 7. 2. I updated several classes that handled the new instructions and new code attributes. 3. This required new methods on several interfaces. 4. These new methods broke