Re: [WEAVER] - move to dormant?

This was spun out to support security manager stuff in Apache BVal. Until that known ASF client is able (at the specification level) to exclusively support Java versions with no SecurityManager whatsoever, I'd personally prefer to fix [weaver], but having made my preference known I will defer to th

Re: [collections] AbstractLinkedList is source incompatible with JDK 21

AM Matt Benson wrote: > IMO the version bump is warranted/I'd select option 2 (although if it's > not too early for me I don't see these options as being mutually exclusive). > > Matt > > On Fri, Sep 8, 2023, 7:46 AM Alex Herbert > wrote: > >> JDK

Re: [collections] AbstractLinkedList is source incompatible with JDK 21

IMO the version bump is warranted/I'd select option 2 (although if it's not too early for me I don't see these options as being mutually exclusive). Matt On Fri, Sep 8, 2023, 7:46 AM Alex Herbert wrote: > JDK 21 has added these methods to java.util.List: > > default public void addFirst(E o) >

Re: [lang] Considering a new String utility class

On Thu, Mar 16, 2023, 3:15 AM Hasan Diwan wrote: > Looking through StringUtils[1]m most of the methods have an "IgnoreCase" > variant, so I don't think one needs to DO anything to achieve this. If you > want to fold the ignoreCase variants, add something like: > > private static boolean disre

Re: [lang] Considering a new String utility class

On Wed, Mar 15, 2023 at 11:10 PM Hasan Diwan wrote: > On Wed, 15 Mar 2023 at 20:55, Matt Benson wrote: > > > > > > > Any thoughts? > > > > Something like: > > > StringUtils2.ignoreCase() /* makes the next functions case insensitive > */.respectCa

Re: [lang] Considering a new String utility class

On Wed, Mar 15, 2023 at 9:47 PM Gary Gregory wrote: > On Wed, Mar 15, 2023 at 9:11 AM Matt Benson wrote: > > > > Agreed, Gary. Sounds promising. Maybe consider the "modern" terser > builder > > style a la AWS builders or such (i.e. since the "mutator&quo

Re: [lang] Considering a new String utility class

Agreed, Gary. Sounds promising. Maybe consider the "modern" terser builder style a la AWS builders or such (i.e. since the "mutator" isn't a classic Java beans mutator in any case, you can omit "set"). Matt On Wed, Mar 15, 2023, 8:06 AM Melloware wrote: > This sounds like a great idea! > > > On

Re: [imaging] Preparing vote for imaging-1-0-alpha3 (last alpha release)

Nice job, Bruno! Thanks for pushing this. Matt On Wed, May 11, 2022, 11:32 PM Bruno Kinoshita wrote: > Hi, > > We have fixed all the issues that were raised as blockers for 1.0 some > years ago (4? maybe 5 years ago?). I'm finishing the preparations for the > 1.0-alpha3 vote for Imaging. It's t

Re: New component proposal: commons-plugins

Devil's advocate thought: given that Commons, while not officially limited to such, has heretofore concentrated on the Java ecosystem; as the core JDK evolves, matures and provides more and more functionality out of the box, possibly Commons components would have to increase in complexity to be abl

Re: New component proposal: commons-plugins

Generally speaking it sounds like there's at least enough interest to create a repo and start playing. Only recently I could personally have used a working version of something like this. No guarantees but I'd like to help if it works out that way, for whatever that's worth. Matt On Sat, Apr 2, 2

Re: can we get rid of dependabot?

On Wed, Dec 29, 2021, 9:27 AM Gary Gregory wrote: > On Wed, Dec 29, 2021 at 9:45 AM sebb wrote: > > > On Wed, 29 Dec 2021 at 14:36, Rob Tompkins wrote: > > > > > > Why not just run dependabot weekly. We move slowly enough that weekly > > currently works. Until we can get more hands on the proje

Re: can we get rid of dependabot?

On Wed, Dec 29, 2021, 9:21 AM Mark Thomas wrote: > On 29/12/2021 15:04, Gary Gregory wrote: > > On Wed, Dec 29, 2021 at 9:37 AM Rob Tompkins wrote: > > > >> Why not just run dependabot weekly. We move slowly enough that weekly > >> currently works. Until we can get more hands on the project, slo

Re: Move Proxy to dormant?

FWIW, my recollection is that proxy was ready for a 2.0 release which was vetoed on the basis that the site didn't contain a migration how-to document. Oh well. On Fri, Apr 23, 2021, 4:07 PM Gary Gregory wrote: > Sounds reasonable to me. > > Gary > > On Thu, Apr 22, 2021, 16:09 sebb wrote: > >

Re: [lang] org.apache.commons.lang3.StringUtils.join(Object[], char) backward

Definitely +1 if we didn't already do this, except I would put what I call a "Yoda preposition" in there, e.g. joinBy or joinWith. Matt On Wed, Mar 11, 2020, 9:00 AM Gary Gregory wrote: > HI All: > > Now that Java's had varargs for a while now, using APIs like > org.apache.commons.lang3.StringU

Re: [VOTE][LAZY] Move all proper svn repos to gitbox

[weaver] has already been migrated to gitbox. I see on review that the website still reflects svn. I'll add that to my OSS TODO list. Other than that, +1 Matt On Tue, Jan 8, 2019, 10:33 AM Rob Tompkins Vote statement: "I propose we move all ‘proper' svn repos to gitbox." > > I went though, and

Re: [lang] IllegalArgumentException factory methods

I would add to Validate with different names, or adopt an entirely new approach to constructing exceptions, like that demonstrated in [1]. Matt [1] https://github.com/apache/bval/blob/bv2/bval-jsr/src/main/java/org/apache/bval/util/Exceptions.java On Sun, Oct 7, 2018, 11:13 AM Gary Gregory wrote

[ANNOUNCE] Apache Commons Weaver 2.0 released

The Apache Commons Team is pleased to announce the availability of: Apache Commons Weaver 2.0 Apache Commons Weaver provides an easy way to enhance compiled Java classes by generating ("weaving") bytecode into those classes. The release notes can be reviewed at: http://www.apache.org/dist/common

[RESULT] Release Apache Commons Weaver 2.0 based on RC1

Hello, closing this vote as 72 hours have passed. The following votes were received: Roberto Cortez: +1 Romain Manni-Bucau: +1 Matt Benson: +1 (binding) Bruno P. Kinoshita: +1 (binding) Benedikt Ritter: +1 (binding) Mark Struberg: +1 With three binding +1s, the release vote passes. Thanks to

Re: [VOTE] Release Apache Commons Weaver 2.0 based on RC1

On Tue, Sep 4, 2018, 10:58 AM Matt Benson wrote: > I would like to release the [weaver] component. > > Apache Commons Weaver 2.0 RC1 is available for review at: > *https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/ > <https://dist.apache.org/repos/dist/dev/comm

Re: [VOTE] Release Apache Commons Weaver 2.0 based on RC1

gt; LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book > > < > > > https://www.packtpub.com/application-development/java-ee-8-high-performance > > > > > > > > > Le mar. 4 sept. 2018 à 19:04, Roberto Cortez > > > a écrit : > > >

[VOTE] Release Apache Commons Weaver 2.0 based on RC1

I would like to release the [weaver] component. Apache Commons Weaver 2.0 RC1 is available for review at: *https://dist.apache.org/repos/dist/dev/commons/weaver/2.0-RC1/ * (r29084). Maven artifacts are at: https://repository.apac

Re: [commons-weaver] 01/01: Build on Java 10; modification to public API requires major version bump

n Thu, Aug 30, 2018, 6:07 PM wrote: > This is an automated email from the ASF dual-hosted git repository. > > mbenson pushed a commit to branch java10 > in repository https://gitbox.apache.org/repos/asf/commons-weaver.git > > commit 69ef91e50a3fe3b736696c0ddc307e3c5bde0cb

Re: [release-plugin] multimodule sites

To answer my own question, we already have JaCoCo reporting configured, so I am going to remove javancss rather than be hobbled in terms of what code we can write. Matt On Thu, Aug 30, 2018, 2:43 PM Matt Benson wrote: > It ended up being quite easy to get the unit test to pass, though the

Re: [release-plugin] multimodule sites

ancss report that is configured is unable to parse :: syntax and no new release of the plugin is available. Can we remove or replace this plugin? Matt On Wed, Aug 29, 2018, 8:48 PM Rob Tompkins wrote: > > > > On Aug 29, 2018, at 7:16 PM, Matt Benson wrote: > > > >> O

Re: [release-plugin] multimodule sites

On Wed, Aug 29, 2018, 5:41 PM Rob Tompkins wrote: > > > > On Aug 29, 2018, at 4:43 PM, Matt Benson wrote: > > > > I have opened and resolved [1]. I classified this as a bug. Should we > > consider a 1.4.1 release or just leave the master version at > 1.5-SNA

[release-plugin] multimodule sites

I have opened and resolved [1]. I classified this as a bug. Should we consider a 1.4.1 release or just leave the master version at 1.5-SNAPSHOT? It appears I can do the weaver release using a locally overridden snapshot build of the plugin, so I don't think I'm blocked (or worse, forced to do thing

Re: [LANG] Minimum required Java version for 3.9

Do you have specific new features or deprecations in mind to accompany the bump? Matt On Tue, Aug 21, 2018, 7:00 AM Pascal Schumacher wrote: > +1 > > Am 20. August 2018 19:09:27 MESZ schrieb Benedikt Ritter < > brit...@apache.org>: > >Hi, > > > >any objections against raising the minimum requir

[weaver] preparing a 1.4 release

Hello, If it wasn't obvious, I'm gearing up to create a 1.4 RC in the near future. I will serve as the release manager; please respond with any concerns. Thanks, Matt

Re: [ALL][DRAFT] Board report

Fwiw, [weaver] will also be released in the near future, and will be reported as being the primary remaining blocker for Apache BVal 2.0. Matt On Wed, Jun 13, 2018, 12:27 AM Gilles wrote: > Hello. > > On Tue, 12 Jun 2018 16:11:30 -0600, Gary Gregory wrote: > > Thank you for your review Gilles (

Re: rolling a commons-weaver release?

Site needs some work before it will build. ISTR that the japicmp config needs tweaking. Matt On Sat, Jun 9, 2018, 7:36 AM Gary Gregory wrote: > Go for it. > > Gary > > On Sat, Jun 9, 2018, 02:32 Mark Struberg > wrote: > > > Hi folks! > > > > I'd like to run a commons-weaver release. > > We nee

Re: [commons-release-plugin] Next

I'm going to want to release [weaver] soon as well, so I might like to participate with plugin development. Matt On Sat, May 12, 2018, 10:40 AM Gary Gregory wrote: > On Fri, May 11, 2018 at 7:53 PM, Rob Tompkins wrote: > > > > > > > > On May 10, 2018, at 12:11 PM, Gary Gregory > > wrote: > >

[RESULT] [VOTE] Migrate Commons Weaver to Git

Hello, With 4 binding +1 votes and no -1 votes, this vote has passed. Thanks, Matt On Thu, Apr 19, 2018 at 2:33 PM, Romain Manni-Bucau wrote: > +1 > > Le 19 avr. 2018 20:17, "Pascal Schumacher" a > écrit : > > > +1 > > > > Am 19.04.2018 um 17:46 schr

Re: Discuss [VOTE] Migrate Commons Weaver to Git

sy work because we have so many components. > > Gary > > > > Oliver > > > > > > > > [1]: https://issues.apache.org/jira/browse/INFRA-16413 > > > > > > On 21 April 2018 at 12:23, Matt Benson wrote: > > > >

Re: Discuss [VOTE] Migrate Commons Weaver to Git

ere any reason that migrating components *en masse* would be easier or otherwise preferable to doing so "piecemeal"? Matt -Rob > > > > > Oliver > > > >> > >> On 20 April 2018 at 10:13, Matt Benson wrote: > >> > >>> As Emmanuel sugge

Re: Discuss [VOTE] Migrate Commons Weaver to Git

As Emmanuel suggested, Daniel Gruno confirmed for me that "git-wip is slowly being deprecated." So the answer to the question initially posed by Ralph would seem in fact to be gitbox. Thanks, Matt On Thu, Apr 19, 2018 at 11:57 PM, Romain Manni-Bucau wrote: > Gitbox is easier to use with github

Re: Discuss [VOTE] Migrate Commons Weaver to Git

read-only > mirror, allows PRs, etc.). > > On 19 April 2018 at 16:23, Matt Benson wrote: > > > Thanks for these, Seb. Not sure I really consider myself fully edified > yet, > > but I know how to go to Infra HipChat when I have time for a thorough > > explanation.

Re: Discuss [VOTE] Migrate Commons Weaver to Git

Thanks for these, Seb. Not sure I really consider myself fully edified yet, but I know how to go to Infra HipChat when I have time for a thorough explanation. :) Matt On Thu, Apr 19, 2018 at 4:16 PM, sebb wrote: > On 19 April 2018 at 22:09, Matt Benson wrote: > > I'm not cl

Re: Discuss [VOTE] Migrate Commons Weaver to Git

etty cool if all of Commons was on GitBox for > convenience, I’m pretty sure all the new repos have still been git-wip > > On Thu, Apr 19, 2018 at 15:15, Ralph Goers > wrote: > > > Is this vote for Git or Gitbox or is there any difference these days? > > > > Ralph &

Re: [VOTE] Migrate Commons Weaver to Git

On Thu, Apr 19, 2018 at 10:46 AM, Matt Benson wrote: > Hello, > After having received some support from a "feeler" email, I would like to > propose the formal vote to migrate this Commons component to Git for > version control. This vote will be open for at least 72 hour

[VOTE] Migrate Commons Weaver to Git

Hello, After having received some support from a "feeler" email, I would like to propose the formal vote to migrate this Commons component to Git for version control. This vote will be open for at least 72 hours, or until April 22, 2018 @ 16:00 UTC. Thanks, Matt

[weaver] migrate to git

I'd like to migrate this component to git. Will anyone support me to the point that I can start a vote to do so? Thanks, Matt

Re: [lang] Todo utility class

Thanks all. This has gone elsewhere. Matt On Mar 19, 2018 8:21 PM, "Matt Sicker" wrote: > I’ve used NotImplementedException as a way to do this. In Scala, there is a > function called ??? which throws a similar exception, and in Kotlin, > there’s an equivalent function called TODO. > > On Mon,

Re: [lang] Todo utility class

this, Matt On Mar 16, 2018 6:09 AM, "Gilles" wrote: > On Fri, 16 Mar 2018 00:35:24 -0700, Bindul Bhowmik wrote: > >> On Thu, Mar 15, 2018 at 4:05 PM, Gilles >> wrote: >> >>> Hi. >>> >>> On Wed, 14 Mar 2018 16:51:43 -0500, Matt Benson

[lang] Todo utility class

I have often thought about creating a utility class that allows me to write skeletal code that still compiles but will remind me to go back and finish it. This is a weird meta area of programming, but here are some basic usage examples: Foo foo = Todo.todo(); //returns null Bar bar = Todo.todo(THR

Re: [text] Upper/Lower case enum

On Feb 23, 2018 4:26 AM, "sebb" wrote: On 23 February 2018 at 00:41, Gary Gregory wrote: > On Thu, Feb 22, 2018 at 4:27 PM, sebb wrote: > >> On 22 February 2018 at 23:15, Gary Gregory wrote: >> > On Thu, Feb 22, 2018 at 4:11 PM, sebb wrote: >> > >> >> On 22 February 2018 at 22:27, Gary Gregor

Re: [lang]

On Jan 11, 2018 7:59 AM, "Gilles" wrote: On Thu, 11 Jan 2018 07:49:40 -0600, Matt Benson wrote: > On Jan 10, 2018 9:22 PM, "Gary Gregory" wrote: > > On Wed, Jan 10, 2018 at 5:44 PM, Matt Benson wrote: > > As I'm sure you're aware, the planned ob

Re: [lang]

On Jan 10, 2018 9:22 PM, "Gary Gregory" wrote: On Wed, Jan 10, 2018 at 5:44 PM, Matt Benson wrote: > As I'm sure you're aware, the planned obsolescence of this approach is its > obvious drawback (a similar drawback exists already in the JavaVersion > paramete

Re: [lang]

As I'm sure you're aware, the planned obsolescence of this approach is its obvious drawback (a similar drawback exists already in the JavaVersion parameter type). I assume this is the reason you said "technical reasons." However, wouldn't it be straight up simple, as well as future proof (if done c

Re: [commons-release-plugin] (Was: svn commit: r24003 - in /dev/commons/text: ./ binaries/ source/)

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" wrote: > > > > On Jan 4, 2018, at 5:24 AM, Gilles wrot

Re: [build-plugin] Re-engineering/release streamlining

On Nov 11, 2017 9:32 PM, "Rob Tompkins" wrote: > On Nov 11, 2017, at 10:24 PM, Gary Gregory wrote: > >> On Sat, Nov 11, 2017 at 8:19 PM, Rob Tompkins wrote: >> >> Hello all, >> >> I was wondering if we might think about a 2.X line in the [build-plugin] >> to better facilitate our release mech

Re: [COLLECTIONS] Time for 4.2

On Sep 20, 2017 11:08 AM, "Stephen Colebourne" wrote: I think its worth the extra step of checking the conditions are right for adding the Automatic-Module-Name manifest entry. Wouldn't that just offload the decision to "when to update the parent version in the component?" Matt I've not got

Re: [All][Math] New component: "Commons Geometry"?

I'm another Commons developer who: * Hasn't been "present" lately * Has no special mathematical background * Desires consensus * Repeatedly reads these exchanges in a state of vacillation between sympathy for Gilles's situation and suspicion that his communication style is too abrasive. Ultimat

Re: [collections][proposal] Java 7

I think Jochen is correct wrt the major version bump. But that gets me thinking: what did Java 7 bring that is of any particular relevance for [collections]? Wouldn't it present a much larger opportunity to make the jump to Java 8? Matt On Thu, Jul 27, 2017 at 8:47 AM, Jochen Wiedmann wrote: > W

Re: [FUNCTOR] Why do we have an API module?

urve here there's no reason IMO to do anything if it's not fairly radical. Matt On Sat, Jun 24, 2017 at 12:29 PM, Benedikt Ritter wrote: > Hi Matt, > > what is your opinion in this topic (targeting Java 8) > > Benedikt > > Matt Benson schrieb am Sa. 24. Juni 2017 um 1

Re: [FUNCTOR] Why do we have an API module?

If we want to repurpose functor for Java 8 then I imagine we'd just use their interfaces, for the most part. So the API module would indeed probably go away. Matt On Sat, Jun 24, 2017 at 12:08 PM, Benedikt Ritter wrote: > Hi, > >> Am 16.06.2017 um 13:03 schrieb Matt Benson

Re: [FUNCTOR] Why do we have an API module?

Yes, the point of the API module was to define the functional interfaces separately from the utility code around them; particularly pre-Java 8, these could be used apart from the utility code from the core. Matt On Jun 16, 2017 4:27 AM, "Bruno P. Kinoshita" wrote: No objection here too. I've be

Re: [LANG] Thoughts about Lang 4.0

On May 24, 2017 9:42 AM, "Rob Tompkins" wrote: > On May 24, 2017, at 10:33 AM, Dave Brosius wrote: > > Let's be honest, a Pair class is a bad paradigm, invented for lazyness which throws away any informative metadata. I'm not sure all of this fighting is worth it over a this. Dependency/classp

Re: [LANG] Thoughts about Lang 4.0

On May 24, 2017 6:56 AM, "Stephen Colebourne" wrote: On 23 May 2017 at 17:17, sebb wrote: >> Yes, the >> code compiles and both can be on the classpath, but it is a pain to >> use, just a different kind of hell. > > I don't see what the problem is here. Library A that depends on lang3 returns a

Re: [FUNCTOR] How do we move on?

TBH I cleaned up more than I implemented, but okay. What happened was we changed the nomenclature to better mesh with Java 8 and that pretty much killed the momentum on the project, despite having been the right thing to do. I wouldn't mind seeing a redefined component such as you have suggested, b

Re: Pair of nulls

7 at 11:17, Gary Gregory wrote: > >> On Thu, May 11, 2017 at 5:35 AM, Matt Benson >> wrote: >> >> > On May 11, 2017 1:03 AM, "Gary Gregory" wrote: >> > >> > On Wed, May 10, 2017 at 10:58 PM, Matt Sicker wrote: >> > >> > &g

Re: Pair of nulls

On May 11, 2017 1:03 AM, "Gary Gregory" wrote: On Wed, May 10, 2017 at 10:58 PM, Matt Sicker wrote: > Matching the of() static factories, how about ImmutablePair.ofNull() > I like it but at the same time it feels to me like I am getting a NEW object like ImmutablePair.of(x, y) give me a new ob

Re: Pair of nulls

On May 10, 2017 11:27 PM, "Matt Sicker" wrote: Wouldn't it make sense to expose typed methods like in Collections.emptyList() et al.? +1 Matt On 10 May 2017 at 22:10, Javen O'Neal wrote: > +1 > > The of method should check if all elements are null, and if so to return > the NULL singleton.

Re: [lang]

This is dead easy in Java 8: Comparator.comparing(Object::toString) Granted, you have to do a little more for null handling, but I'm not sure it's worth writing out a class definition in this form. If we are intending to cater to pre Java 8 clients, okay, but it seems a little late in the game to

Re: StringUtils.isEmpty() family of methods on Objects

Like Bene, this feels a little off to me. Just for argument's sake, let's look at: Optional.ofNullable(foo).map(Object::toString).filter(StringUtils::isNotBlank).isPresent(); Assuming you're on Java 8, of course. It's a bit long, but not horrible. What about, in a Java 8-compatible version of [la

Re: [all] Clirr or japicmp - does either work for anybody?

I used japicmp with the last [weaver] release. Also it seems more actively maintained than Clirr so it would probably be easier to get a fix in. Matt On Tue, Dec 20, 2016 at 9:35 AM, Stefan Bodewig wrote: > Hi > > I'm trying to figure out how to get a report on API changes in > compress. > > If

Re: [lang] Thread safety annotations

I hoped to stay out of this. :) Points: * "provided" scope is another Maven mechanism that compiles against a given dependency but does not pull the dependency in as a runtime dependency. I personally prefer it to marking a dependency optional. * For annotations with only classfile retention, a fu

Re: [TEXT] Add a duration parser, using donated code from gunip

TBH I think we need a software grant agreement (SGA) executed for this, regardless of license. Any other opinions? Matt On Nov 8, 2016 8:16 AM, "Jean Champémont" wrote: > Hi all, > > Yes, I confirm I'm OK to donate the code of gunip to the Apache commons > project. > > If there is anything else

Re: [ALL] hashes of signatures

gt; as artifacts. > > https://svn.apache.org/viewvc/view=revision&revision=1755904 > > > I don't believe it's been released. > > Chas > > > On Oct 31, 2016, at 9:53 AM, Matt Benson wrote: > > > > Thanks for repying, but that seems backward: signatures

Re: [ALL] hashes of signatures

**/*.sha1 > > > > > > is that sufficient in Bval? If so we can add it to commons-parent. > > > > On 31 October 2016 at 15:58, Matt Benson wrote: > > The releas

[ALL] hashes of signatures

The release procedures mention the problem of these extraneous files in the Nexus staging repo. I have noticed during the last couple of [weaver] release cycles that these files no longer show up and had thought it was something they had fixed on Nexus. Then I rolled a vote candidate for Apache BVa

Re: [ALL] Component with multiple modules?

016 07:23:28 -0500, Matt Benson wrote: > >> On Oct 20, 2016 7:00 AM, "Gilles" wrote: >> >>> >>> Hi. >>> >>> Can you point me at a component that has a config supporting >>> multiple modules? >>> >>> >> [we

Re: [ALL] Component with multiple modules?

On Oct 20, 2016 7:00 AM, "Gilles" wrote: > > Hi. > > Can you point me at a component that has a config supporting > multiple modules? > [weaver] is the most recently released multimodule Commons component. Matt > Thanks, > Gilles > > > ---

[ANNOUNCE] Apache Commons Weaver 1.3 Released

The Apache Commons Team is pleased to announce the availability of: Apache Commons Weaver 1.3 Apache Commons Weaver provides an easy way to enhance compiled Java classes by generating ("weaving") bytecode into those classes. The release notes can be reviewed at: http://www.apache.org/dist/common

[RESULT] Release Apache Commons Weaver 1.3 based on RC2

On Mon, Oct 17, 2016 at 6:29 PM, Matt Benson wrote: > > > On Thu, Oct 13, 2016 at 4:30 PM, Matt Benson wrote: > >> I would like to release the [weaver] component. >> >> Apache Commons Weaver 1.3 RC2 is available for review at: >> https://dist.apache.org/re

Re: [VOTE] Release Apache Commons Weaver 1.3 based on RC2

On Thu, Oct 13, 2016 at 4:30 PM, Matt Benson wrote: > I would like to release the [weaver] component. > > Apache Commons Weaver 1.3 RC2 is available for review at: > https://dist.apache.org/repos/dist/dev/commons/weaver/ (r16517). > > Maven artifacts are at: > https://

Re: [VOTE] Release Apache Commons Lang 3.5 based on RC2

On Oct 13, 2016 3:20 PM, "Benedikt Ritter" wrote: > > Hi, > > finally I found the time to prepare Apache Commons Lang 3.5 RC2 :-) > We could not release RC1, because I messed up the release archives. They > contained some snapshot artifacts. This has been fixed in RC2. Furthermore > LANG-1275 has

Re: [VOTE] Release Apache Commons Weaver 1.3 based on RC2

he following articles: [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ MojoExecutionException --x snip x-- Cheers Bruno - Original Message - > From: Matt Benson > To: Commons Developers List > Sent: Friday, 14 October 2016 10:30 AM > Subject: [VOTE] Release Ap

[VOTE] Release Apache Commons Weaver 1.3 based on RC2

I would like to release the [weaver] component. Apache Commons Weaver 1.3 RC2 is available for review at: https://dist.apache.org/repos/dist/dev/commons/weaver/ (r16517). Maven artifacts are at: https://repository.apache.org/content/repositories/orgapachecommons-1210 . Tested with Oracle JDK

Re: [VOTE] Release Apache Commons Weaver 1.3 based on RC1

This vote is cancelled; I have found a problem with the release notes--they were generated with the -SNAPSHOT version number embedded. RC2 forthcoming. Matt On Thu, Oct 13, 2016 at 3:08 PM, Matt Benson wrote: > I would like to release the [weaver] component. > > Apache Commons Weave

[VOTE] Release Apache Commons Weaver 1.3 based on RC1

I would like to release the [weaver] component. Apache Commons Weaver 1.3 RC1 is available for review at: https://dist.apache.org/repos/dist/dev/commons/weaver/ (r16504). Maven artifacts are at: https://repository.apache.org/content/repositories/orgapachecommons-1208 . Tested with Oracle JDK

[DISCUSS] Release of commons-parent v42

Does anyone object to this? Most of the recent commits are japicmp-related: r1764145 | mbenson | 2016-10-10 11:08:33 -0500 (Mon, 10 Oct 2016) | 1 line correct comment -

[weaver] 1.3 release process

Just a note to let the community I plan to start rolling release candidates in the near future. Matt

Re: [ALL] Volunteers for a Math IPMC?

On Jun 18, 2016 2:05 PM, "Gilles" wrote: > > On Sat, 18 Jun 2016 11:00:34 -0700, Ted Dunning wrote: >> >> On Sat, Jun 18, 2016 at 4:29 AM, Gilles >> wrote: >> >>> ... >>> I'm asking, again, whether I need to initiate a VOTE that would allow me >>> to set up a workspace ("git", etc.) and transfer

Re: [ALL] Volunteers for a Math IPMC?

On Jun 18, 2016 9:28 AM, "Gilles" wrote: > > Hi. > > > On Sat, 18 Jun 2016 14:42:46 +0200, Jörg Schaible wrote: >> >> Hi Gilles, >> >> Gilles wrote: >> >>> Hi. >>> >>> On Fri, 17 Jun 2016 16:01:20 -0700, Ted Dunning wrote: Gilles, Thanks for links. I just read that (l

Re: Re: [ALL] About binary compatibility

On Jun 14, 2016 9:55 AM, "Gary Gregory" wrote: > > > On Jun 14, 2016 7:45 AM, "Matt Benson" wrote: > > > > On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov wrote: > > > > > I like the way Eclipse it does for years: > > > > >

Re: Re: [ALL] About binary compatibility

On Tue, Jun 14, 2016 at 2:14 AM, Andrey Loskutov wrote: > I like the way Eclipse it does for years: > > 1) Everything inside **/internal/ packages is non API by definition > 2) MANIFEST.MF to use OSGI "Export-Package" attribute for "published" > packages > 3) Javadoc @noextend tag for classes not

Re: BCEL 6 API breakage

AFAIK ASM already put its users through the pain of BC breakage when they went from an interface-based design to one based on abstract classes (3 to 4 or 4 to 5) but mixing versions across that boundary is the very definition of jar hell and is why ASM recommends that their classes be shaded into a

Re: [ALL] About binary compatibility

On Thu, Jun 2, 2016 at 3:42 PM, Benedikt Ritter wrote: > Hi, > > we do seem to have different opinions when it comes to binary compatibility > and how it should be handled. Usually we would say "this should be decided > on a component basis". However this discussion is coming up again and again >

Re: [Math] How fast is fast enough?

I don't know that Dave intended his comments precisely as an indictment in this specific situation, but he is certainly neither the first nor, almost certainly, the last person to express similar feelings. I appreciated your support during my recent release vote, Phil, and would be sorry to see you

[ANNOUNCE] Apache Commons Weaver 1.2 Released

The Apache Commons Team is pleased to announce the availability of: Apache Commons Weaver 1.2 Apache Commons Weaver provides an easy way to enhance compiled Java classes by generating ("weaving") bytecode into those classes. The release notes can be reviewed at: http://www.apache.org/dist/common

[RESULT] Release Apache Commons Weaver 1.2 based on RC2

continued to be a roadblock for Apache projects downstream. I thank everyone who participated in the voting process, and will work to rectify the concerns expressed as soon as time permits. Thanks, Matt On Mon, Jan 25, 2016 at 5:40 PM, Gary Gregory wrote: > On Mon, Jan 25, 2016 at 3:37 PM, Matt Ben

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

rmannibucau.wordpress.com> | Github < >> >> https://github.com/rmannibucau> | >> >> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber >> >> <http://www.tomitribe.com> >> >> >> >> 2016-01-25 23:19 GMT+

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC2

rmation in hand, where do you now stand on this, Gary? Matt > > Gary > > >> >> Gary >> >> On Thu, Jan 21, 2016 at 10:39 AM, Matt Benson wrote: >> >>> I would like to release the [weaver] component. >>> >>> Apache Commons Weave

[VOTE] Release Apache Commons Weaver 1.2 based on RC2

I would like to release the [weaver] component. Apache Commons Weaver 1.2 RC2 is available for review at: https://dist.apache.org/repos/dist/dev/commons/weaver/ (r11994). Maven artifacts are at: https://repository.apache.org/content/repositories/orgapachecommons-1141 . Tested with Oracle JDK

Re: [lang] Simplify, less clutter.

It appears the whole file changed; why is that? I can't tell what was actually done. Matt On Jan 15, 2016 6:33 PM, wrote: > Repository: commons-lang > Updated Branches: > refs/heads/master 7429e75b7 -> 18f5f54ca > > > Simplify, less clutter. > > Project: http://git-wip-us.apache.org/repos/asf/

Re: svn commit: r1724334 - in /commons/proper/weaver/trunk: LICENSE-asm.txt LICENSE.txt RELEASE-NOTES.txt dist/src/assembly/bin.xml dist/src/assembly/src.xml pom.xml

I think I have satisfied the demands of Apache's and ASM's bundling policies. If everyone is satisfied, I will roll RC2 of the release. Matt On Tue, Jan 12, 2016 at 5:14 PM, wrote: > Author: mbenson > Date: Tue Jan 12 23:14:35 2016 > New Revision: 1724334 > > URL: http://svn.apache.org/viewvc?r

Re: [all] Commons Parent - detach src/bin artifacts?

Did this thread start out about distribution artifacts and end up about asc.md5 and asc.sha1? AFAIK the latter problem is now taken care of by Nexus, which is why the recent [weaver] RC was not affected by it. Most likely [weaver] will differ from other candidates regarding the distribution artifac

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC1

On Dec 22, 2015 1:27 PM, "Phil Steitz" wrote: > > On 12/22/15 12:05 AM, Matt Benson wrote: > > On Dec 21, 2015 8:46 PM, "James Carman" wrote: > >> Can you just abandon the ant build? > >> > > It's not an Ant build; it's an Ant

Re: [VOTE] Release Apache Commons Weaver 1.2 based on RC1

Ant; the least I can do is be inclusive. Matt > On Fri, Dec 18, 2015 at 6:41 PM Matt Benson wrote: >> >> On Fri, Dec 18, 2015 at 5:31 PM, Phil Steitz wrote: >> > On 12/18/15 3:38 PM, Matt Benson wrote: >> >> On Fri, Dec 18, 2015 at 4:33 PM, Phil Steitz wrote: >&

Re: svn commit: r1720859 - in /commons/proper/weaver/trunk: ant/NOTICE.txt modules/NOTICE.txt

And yes, I know these copyright years seem odd, but that's what they are on the site and in their Subversion repo. Matt On Fri, Dec 18, 2015 at 5:38 PM, wrote: > Author: mbenson > Date: Fri Dec 18 23:38:26 2015 > New Revision: 1720859 > > URL: http://svn.apache.org/viewvc?rev=1720859&view=rev >

  1   2   3   4   5   6   7   8   9   10   >