Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta releases
On Mar 27, 2010, at 4:07 PM, Henri Yandell wrote: Possibly a query for IO too if it's 2.0 has large changes. Given the large API changes in Lang 3.0 and Collections 4.0, a beta release seems like a very useful thing (kudos to pbenedict for convincing of me that months ago on IM :) ). I'm interested in what advice and thoughts people might have on the subject. Areas I can think of are: 1) versioning, does JIRA identify the version as 3.0-beta1; or just have a 3.0 and treat the beta as an invisible release? I'm preferring the latter. 2) Maven - does the beta go to the main Maven repo, or just tell people to pull from snapshot (and make sure there are current snapshots in the snapshot repo)? I'm thinking the latter. 3) Announcements - blogging, announce@ type announcements presumably. 4) Length of time spent in beta. I think we should define this up front. The intent would be to get early adopters using and finding bugs, but more importantly drive conversation around the API changes and suggest new ones. I want us to be able to change an API without having to say Yeah, that was dumb - sadly we have to wait 'til 5.0. I think both Lang and Collections are ready to have a beta release asap - once some level of documentation is created, both proto release documentation and something to define the beta testing period. Any thoughts are much appreciated, While we're somewhat on-topic, I would heartily suggest that we give due consideration to switching to the Nexus install at repository.a.o for the Commons release cycles. This is the way the wind is blowing, seems to make management easier, and is mostly if not completely already set up as Ralph and I have been deploying sandbox snapshots there for some time. A formal PMC vote to do all our releases through Nexus would be best, though we _could_ continue to do this one component at a time; see http://issues.apache.org/jira/browse/ INFRA-1896. -Matt Hen - 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: Nexus for mvn management WAS Re: [LANG][COLLECTIONS] Beta releases
On Mar 28, 2010, at 11:29 AM, Henri Yandell wrote: On Sun, Mar 28, 2010 at 6:40 AM, Matt Benson gudnabr...@gmail.com wrote: On Mar 27, 2010, at 4:07 PM, Henri Yandell wrote: Possibly a query for IO too if it's 2.0 has large changes. Given the large API changes in Lang 3.0 and Collections 4.0, a beta release seems like a very useful thing (kudos to pbenedict for convincing of me that months ago on IM :) ). I'm interested in what advice and thoughts people might have on the subject. Areas I can think of are: 1) versioning, does JIRA identify the version as 3.0-beta1; or just have a 3.0 and treat the beta as an invisible release? I'm preferring the latter. 2) Maven - does the beta go to the main Maven repo, or just tell people to pull from snapshot (and make sure there are current snapshots in the snapshot repo)? I'm thinking the latter. 3) Announcements - blogging, announce@ type announcements presumably. 4) Length of time spent in beta. I think we should define this up front. The intent would be to get early adopters using and finding bugs, but more importantly drive conversation around the API changes and suggest new ones. I want us to be able to change an API without having to say Yeah, that was dumb - sadly we have to wait 'til 5.0. I think both Lang and Collections are ready to have a beta release asap - once some level of documentation is created, both proto release documentation and something to define the beta testing period. Any thoughts are much appreciated, While we're somewhat on-topic, I would heartily suggest that we give due consideration to switching to the Nexus install at repository.a.o for the Commons release cycles. This is the way the wind is blowing, seems to make management easier, and is mostly if not completely already set up as Ralph and I have been deploying sandbox snapshots there for some time. A formal PMC vote to do all our releases through Nexus would be best, though we _could_ continue to do this one component at a time; see http://issues.apache.org/jira/browse/INFRA-1896. What would using Nexus change about our release process? It's pretty well-documented from the JIRA issue I referenced above. AIUI we would tweak (or, more likely, de-tweak) some things in our parent POM hierarchy such that the release cycles of snapshot, RC, and release would all be managed through mvn goals. On the whole there should be much less manual intervention required for the whole process. -Matt Hen - 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: svn commit: r906673 - /commons/proper/lang/trunk/src/main/java/org/apache/commons/lang3/builder/ToStringStyle.java
Sorry, guys. I found the offending setting and disabled it. -Matt
On Feb 4, 2010, at 10:32 PM, Henri Yandell wrote:
+1 :)
On Thu, Feb 4, 2010 at 4:17 PM, Niall Pemberton
niall.pember...@gmail.com wrote:
Matt,
Can you stop mixing up style/format changes with real functional
changes - it makes it harder to follow along when you change a few
lines and theres 10 pages in the commit email, I guess this is
probably an IDE setting to remove trailing spaces. Can you either
change your IDE or if you do want to change the format then do it
as a
separate commit before you make any functional changes.
Thanks
Niall
On Thu, Feb 4, 2010 at 9:46 PM, mben...@apache.org wrote:
Author: mbenson
Date: Thu Feb 4 21:46:22 2010
New Revision: 906673
URL: http://svn.apache.org/viewvc?rev=906673view=rev
Log:
[LANG-586] clear ThreadLocal recursion registry (compatibly with
existing tests, first pass)
Modified:
commons/proper/lang/trunk/src/main/java/org/apache/commons/
lang3/builder/ToStringStyle.java
Modified: commons/proper/lang/trunk/src/main/java/org/apache/
commons/lang3/builder/ToStringStyle.java
URL: http://svn.apache.org/viewvc/commons/proper/lang/trunk/src/
main/java/org/apache/commons/lang3/builder/ToStringStyle.java?
rev=906673r1=906672r2=906673view=diff
==
--- commons/proper/lang/trunk/src/main/java/org/apache/commons/
lang3/builder/ToStringStyle.java (original)
+++ commons/proper/lang/trunk/src/main/java/org/apache/commons/
lang3/builder/ToStringStyle.java Thu Feb 4 21:46:22 2010
@@ -5,9 +5,9 @@
* The ASF licenses this file to You under the Apache License,
Version 2.0
* (the License); you may not use this file except in
compliance with
* the License. You may obtain a copy of the License at
- *
+ *
* http://www.apache.org/licenses/LICENSE-2.0
- *
+ *
* Unless required by applicable law or agreed to in writing,
software
* distributed under the License is distributed on an AS IS BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express
or implied.
@@ -19,9 +19,10 @@
import java.io.Serializable;
import java.lang.reflect.Array;
import java.util.Collection;
-import java.util.HashSet;
+import java.util.Collections;
import java.util.Map;
import java.util.Set;
+import java.util.WeakHashMap;
import org.apache.commons.lang3.ClassUtils;
import org.apache.commons.lang3.ObjectUtils;
@@ -46,7 +47,7 @@
* pFor example, the detail version of the array based methods
will
* output the whole array, whereas the summary method will just
output
* the array length./p
- *
+ *
* pIf you want to format the output of certain objects, such
as dates, you
* must create a subclass and override a method.
* pre
@@ -73,17 +74,17 @@
/**
* The default toString style. Using the Using the
codePerson/code
* example from {...@link ToStringBuilder}, the output would
look like this:
- *
+ *
* pre
* per...@182f0db[name=john Doe,age=33,smoker=false]
* /pre
*/
public static final ToStringStyle DEFAULT_STYLE = new
DefaultToStringStyle();
-
+
/**
* The multi line toString style. Using the Using the
codePerson/code
* example from {...@link ToStringBuilder}, the output would
look like this:
- *
+ *
* pre
* per...@182f0db[
* name=John Doe
@@ -93,26 +94,26 @@
* /pre
*/
public static final ToStringStyle MULTI_LINE_STYLE = new
MultiLineToStringStyle();
-
+
/**
* The no field names toString style. Using the Using the
* codePerson/code example from {...@link ToStringBuilder},
the output
* would look like this:
- *
+ *
* pre
* per...@182f0db[john Doe,33,false]
* /pre
*/
public static final ToStringStyle NO_FIELD_NAMES_STYLE = new
NoFieldNameToStringStyle();
-
+
/**
* The short prefix toString style. Using the codePerson/
code example
* from {...@link ToStringBuilder}, the output would look like
this:
- *
+ *
* pre
* Person[name=John Doe,age=33,smoker=false]
* /pre
- *
+ *
* @since 2.1
*/
public static final ToStringStyle SHORT_PREFIX_STYLE = new
ShortPrefixToStringStyle();
@@ -120,38 +121,32 @@
/**
* The simple toString style. Using the Using the
codePerson/code
* example from {...@link ToStringBuilder}, the output would
look like this:
- *
+ *
* pre
* John Doe,33,false
* /pre
*/
public static final ToStringStyle SIMPLE_STYLE = new
SimpleToStringStyle();
-
+
/**
* p
* A registry of objects used by codereflectionToString/
code methods
* to detect cyclical object references and avoid infinite
loops.
* /p
*/
-private static final ThreadLocalSetObject registry = new
ThreadLocalSetObject() {
-@Override
-protected SetObject initialValue() {
-// The HashSet
Re: [lang] Preparing for a 2.5 release
If you're offering, the changes I made yesterday to ClassUtils to default autoboxing based on RT Java version should probably be ported. After that, autoboxing can actually just be defaulted to true in trunk as it will require Java 5+ at RT. Thanks, Matt On Feb 2, 2010, at 8:22 PM, Niall Pemberton wrote: For anyone who hasn't noticed I've been back-porting Commons Lang changes from the trunk to a 2.x branch: http://svn.apache.org/viewvc/commons/proper/lang/branches/ LANG_2_X/ AFAIC its getting close to being ready for a 2.5 release. LANG-204 is currently in progress and I will try to post a summary of whats been back ported (and what hasn't) tomorrow. Other than that I have only updating the site and getting the release notes changes plugin up to date on my todo list. Is there anything anyone else wants included? Niall - 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: [lang] Preparing for a 2.5 release
I'll only say that not autoboxing by default is already over-paranoid when you consider that you're usually talking about doing reflective invocations, for which Objects (and therefore unboxing) are needed to make calls with primitive arguments. If you're talking about compiler-level stuff, the RT check seems more in line. But I don't feel strongly enough about it to debate the issue. br, Matt On Feb 3, 2010, at 9:47 AM, Niall Pemberton wrote: On Wed, Feb 3, 2010 at 3:28 PM, Matt Benson gudnabr...@gmail.com wrote: If you're offering, the changes I made yesterday to ClassUtils to default autoboxing based on RT Java version should probably be ported. After that, autoboxing can actually just be defaulted to true in trunk as it will require Java 5+ at RT. I did look at that, but its a change in how its currently working which is possibly a compatibility issue. Perhaps thats being over paranoid though. Niall Thanks, Matt On Feb 2, 2010, at 8:22 PM, Niall Pemberton wrote: For anyone who hasn't noticed I've been back-porting Commons Lang changes from the trunk to a 2.x branch: http://svn.apache.org/viewvc/commons/proper/lang/branches/ LANG_2_X/ AFAIC its getting close to being ready for a 2.5 release. LANG-204 is currently in progress and I will try to post a summary of whats been back ported (and what hasn't) tomorrow. Other than that I have only updating the site and getting the release notes changes plugin up to date on my todo list. Is there anything anyone else wants included? Niall - 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 - 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: [lang][collections] Overlap; Collections thoughts
On Jan 5, 2010, at 7:58 PM, Stephen Colebourne wrote: [SNIP] And splitting [collections]? Definitely a good idea. I would remove all the Predicate/Closure/Transformer code (if you believe in FP, use [functor]). Then split the rest by implementations of JDK collections, and extended JDK collections - BidiMap, Bag, Trie. +1 as I doubt any more reasonable approach exists. -Matt Stephen Henri Yandell wrote: Overlap between Lang and Collections is starting to increase a bit. Requested items for ArrayUtils (LANG-238, LANG-470) are better implemented imo as an ArraySet class. An easy add to Collections. ComparableComparator made its way (privately) over for the new Range class. Fair enough - Comparable and Comparator also overlap between lang.* and util.*. I have a JIRA issue threat to consider moving Collections code over to Lang if Collections becomes dead [LANG-532] :) --- One thought I have for Collections is splitting it up into two parts. The first would be items that add to collections in the JDK, the second would be additional collections. The former could conceivably merge with Lang, the latter could also be split up into an SPI style approach with an API jar and an Impl jar. The latter would most likely depend on the former. It would then be tempting to also merge Functors for example into the latter, plus I think we could get back on the bandwagon of adding new things, like the long standing Trie JIRA issue. Biased note: Part of this is that I'm interested in the JDK enhancing parts, but not all the implementations of weird and whacky collections; however I think this is likely not just me and that the separation would do wonders for the release cycle. Thoughts? Hen - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
M2 SNAPSHOTS at repository.a.o WAS Re: FaltFile.jar @ us...@commons.a.o
On Jan 5, 2010, at 10:16 AM, Jörg Schaible wrote: Matt Benson wrote: FWIW, there is a [flatfile] M2 snapshot published at repository.apache.org. Which should be definitely not there! Only official reelases can go to the repository. Does the repository == the Nexus instance at repository.apache.org? It's quite obviously intended to host SNAPSHOTs, so do we have a communication problem here or am I unaware of a Commons protocol that says either that publishing SNAPSHOTs is forbidden, or that publishing SNAPSHOTs of sandbox components is? Thanks, Matt - Jörg - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [lang][collections] Overlap; Collections thoughts
On Jan 2, 2010, at 3:27 PM, Henri Yandell wrote: On Sat, Jan 2, 2010 at 10:45 AM, Phil Steitz phil.ste...@gmail.com wrote: Henri Yandell wrote: I was thinking more that a smaller [collections] might have room for the functor code again - not that [lang] would :) Agreed that it's better out than in though. That is instructive, but sort of hurts the case, though, as functors are arguably closer to a language extension than they are related to the [collections] domain. Agreed that it's a bad example. I'd used it as a component that had left collections for some reason and might be a better fit - not from a technical perspective. My negative to adding to Lang would be that unlike the Enum and NestedException pieces of code, functional-in-OO needs a lot of language support to feel good. Better examples of what might be peeled off into [lang] could be the iterators or decorators. Can you get a little more specific on what parts of [collections] you see as in scope for merging into [lang]? https://issues.apache.org/jira/browse/LANG-532 has a bit. The various XxxUtils classes - but not the factory builder parts that supply various aspects. A slice of the iterators and the comparators. Possibly some basic 'missing' implementations such as ArrayStack, ArraySet, FastVector etc. So its the bits that connect the domain to the JDK? That would put, for example, parts of o.a.c.math.stat.StatUtils, o.a.c.math.util.MathUtils similarly in scope. The question here is what is special about [collections] and doesn't this just amount to artificially hacking off pieces that belong with the domain? I am still not seeing the joints here. Lang's math.NumberUtils and math.Fraction for example. MathUtils and a little bit of StatUtils do look to be similar in scope. The special bits with collections are: * Lang issues are identifying overlap problems with Collections. ArrayUtils starts to look like Collections when you take a more generic approach to a problem (for example ArraySet), ComparableComparator was recently copied over (private class) and there is a ComparableUtils class request. * I have concerns over whether there will be a Collections 4.0. My view on this is eventually--I certainly feel I've put in too much work to simply let [collections] go. However, the following issue you identified has been a thorn in my side for quite some time so I am on board for streamlining, multiple artifacts, and anything else that will improve the situation. * Collections has issues that say (paraphrasing) Nice idea, don't commit until Collections is lighter in weight. * Collections has more code at the JDK level being hidden by more additional features than say IO (less additional features), Codec (not a lot of JDK level code), Math (not a lot of JDK level code). Like [collections], they all have a more specialized domain that is their primary focus. So the natural question is, if this makes sense for [collections], why not everywhere else? Answering that question might help clarify intent here. Yup. We've already been doing it with BeanUtils - some of the code moved/copied over in 3.0. What it would possibly mean in your commons wide suggestion is a bunch of components having a dependency on [lang], which as you say below has often been a blocker. Then again - all java.* code depends on java.lang.* :) Can you explain a little more what exactly has moved from BeanUtils and what kinds of other things you have in mind? I thought the new reflect package was from BeanUtils. I think by way of the reflect sandbox component. If not code from BeanUtils, it is a direct overlap with some of the code at the core of BeanUtils. That code was indeed cloned/copied from BeanUtils. The [reflect] component in the sandbox didn't figure into the pedigree, though some of the class names there would understandably suggest otherwise (or, for all I know [reflect] may have also been cloned from BeanUtils code). The point being that oacl.reflect provides a thin veneer over java.lang.reflect and thus seemed to be a proper fit. -Matt One final comment is that a logical alternative is to just split [collections] internally into multiple pieces with separate release cycles. Managing dependencies among the subcomponents and user documentation might be tricky. IIRC, that is what has prevented us from actually ever doing this up to now. Yup. Effectively this is both a split into 'Collections JDK' and 'Collections Structures', and a merge of Collections JDK to Lang. A natural question to ask is is that the best way to split [collections] up? It would probably force some users to depend on - and look for stuff in - [lang] when [collections] by itself would now meet their needs. Pulling the iterators, for example, out of [collections] would make it harder to use by itself and I bet would force [collections] itself to depend on [lang]. I am not (yet) convinced that this is the best way
Re: [lang] Generic object factories
True enough that [functor] already contains *Function interfaces that
meet these requirements.
-Matt
On Dec 26, 2009, at 6:10 PM, Gary Gregory wrote:
Unless [lang] would use it internally all over the place. Is there
a case for that? How is the interface useful without parameters?
Gary
-Original Message-
From: Stephen Colebourne [mailto:scolebou...@btopenworld.com]
Sent: Saturday, December 26, 2009 15:55
To: Commons Developers List
Subject: Re: [lang] Generic object factories
Once upon a time, there was a commons sandbox project that held all
sorts of small interfaces just like this one. It was called commons-
pattern.
It didn't suceed, because these interfaces really need to be provided
by
the JDK and implemented by all the JDK classes to be successful.
Beyond
that, it turned out to be better to have domain specific interfaces.
Thus, I would recommend stronlgy against having this in [lang].
Today,
[functor] and [collections] are the right places for this in
commons -
[lang] doesn't have the necessary domain to back it up.
Stephen
Oliver Heger wrote:
With Java 1.5 it is possible to define a generic interface for
creating
an object:
public interface ObjectFactoryT {
T create();
}
This is a proposal to add such an interface to [lang] 3.0 with a
couple
of default implementations, e.g.
- a ConstantObjectFactory returning always the same constant object,
- a ReflectionObjectFactory which creates new instances of a given
class
using reflection
Some Initializer classes in the concurrent package also deal with
the
creation of objects. They could implement this interface, too.
Client classes that use this interface to create dependent objects
would
be pretty flexible. By specifying concrete factory
implementations it
is
easy to configure the concrete objects they use and how they are
created
as well.
Does this make sense?
Oliver
-
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
-
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: [validator] Direction of validator implementation based on JSR 303
+1 --- On Fri, 10/23/09, Mohammad Nour El-Din nour.moham...@gmail.com wrote: From: Mohammad Nour El-Din nour.moham...@gmail.com Subject: Re: [validator] Direction of validator implementation based on JSR 303 To: Commons Developers List dev@commons.apache.org Date: Friday, October 23, 2009, 4:35 AM +1 Actually this is even better to start from scratch. I am in Niall. On Fri, Oct 23, 2009 at 9:48 AM, Niall Pemberton niall.pember...@gmail.com wrote: On Fri, Oct 23, 2009 at 8:27 AM, Simone Tripodi simone.trip...@gmail.com wrote: Hi guys, I don't have the rights to express votes but at least please let me Anyone can vote - it may end up we don't agree - but votes are appreciated. say that sounds great, commons-validation has to be the proper home for JSR303, I'd like to contribute in this project since I already started studying the spec :) Great - I'm assuming you're not an existing ASF committer, so it'll have to be patches via JIRA tickets: http://commons.apache.org/validator/issue-tracking.html Probably best to ping the list before starting work so that we don't end up duplicating effort. Niall All the best, Simone On Fri, Oct 23, 2009 at 8:58 AM, Henri Yandell flame...@gmail.com wrote: +! On Thu, Oct 22, 2009 at 11:17 PM, Paul Benedict pbened...@apache.org wrote: +1 On Thu, Oct 22, 2009 at 9:33 PM, Niall Pemberton niall.pember...@gmail.com wrote: The current trunk in the validator2 sandbox is a copy of the Validator 1.4 code from commons proper - but I think we should dump all the existing validator framework code and just retain the routines package. Trying to maintain any sort of compatibility with the existing validator framework would be alot more work and code and create a real mess IMO and I think it would be better to not to even try. The routines package was refactored realtively recently(!) and can stand on its own. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- http://www.google.com/profiles/simone.tripodi - 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 -- Thanks - Mohammad Nour - LinkedIn: http://www.linkedin.com/in/mnour Life is like riding a bicycle. To keep your balance you must keep moving - Albert Einstein Writing clean code is what you must do in order to call yourself a professional. There is no reasonable excuse for doing anything less than your best. - Clean Code: A Handbook of Agile Software Craftsmanship - 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: svn commit: r825151 - /commons/proper/collections/trunk/src/java/org/apache/commons/collections/functors/NOPClosure.java
--- On Wed, 10/14/09, sebb seb...@gmail.com wrote:
From: sebb seb...@gmail.com
Subject: Re: svn commit: r825151 -
/commons/proper/collections/trunk/src/java/org/apache/commons/collections/functors/NOPClosure.java
To: dev@commons.apache.org
Date: Wednesday, October 14, 2009, 12:56 PM
On 14/10/2009, mben...@apache.org
mben...@apache.org
wrote:
Author: mbenson
Date: Wed Oct 14 14:23:13 2009
New Revision: 825151
URL: http://svn.apache.org/viewvc?rev=825151view=rev
Log:
[COLLECTIONS-341]
Modified:
commons/proper/collections/trunk/src/java/org/apache/commons/collections/functors/NOPClosure.java
Modified:
commons/proper/collections/trunk/src/java/org/apache/commons/collections/functors/NOPClosure.java
URL:
http://svn.apache.org/viewvc/commons/proper/collections/trunk/src/java/org/apache/commons/collections/functors/NOPClosure.java?rev=825151r1=825150r2=825151view=diff
==
---
commons/proper/collections/trunk/src/java/org/apache/commons/collections/functors/NOPClosure.java
(original)
+++
commons/proper/collections/trunk/src/java/org/apache/commons/collections/functors/NOPClosure.java
Wed Oct 14 14:23:13 2009
@@ -28,7 +28,7 @@
*
* @author Stephen Colebourne
*/
-public class NOPClosureE implements
ClosureE, Serializable {
+public final class NOPClosureE
implements ClosureE, Serializable {
/** Serial version UID */
private static final long
serialVersionUID = 3518477308466486130L;
@@ -68,13 +68,7 @@
*/
@Override
public boolean equals(Object arg0)
{
- if (arg0 == this)
{
-
return true;
- }
- if (arg0 instanceof
NOPClosure == false) {
-
return false;
- }
- return
arg0.hashCode() == this.hashCode();
+ return arg0 == this
|| arg0 instanceof NOPClosure?;
}
Why not just remove the equals() and hashCode() methods?
The defaults are just as good.
Yeah, I s'pose that'd be fine as well. :)
-Matt
/**
-
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: [COLLECTIONS] Advice on API Changes?
This probably just exemplifies why we need to change the package name. --- On Thu, 9/17/09, Stefan Bodewig bode...@apache.org wrote: From: Stefan Bodewig bode...@apache.org Subject: [COLLECTIONS] Advice on API Changes? To: dev@commons.apache.org Date: Thursday, September 17, 2009, 2:42 AM Hi all, as expected, Gump found a few projects that have been broken by the recent merge in Collections - that's what it's there fore anyway. The first ones I have found (there will be more, I'm sure are): Torque: uses FastArrayList and OrderedMap#orderedMapIterator() Jelly: uses BeanMap commons-graph (dormant I know): uses BinaryHeap and PriorityQueue XDoclet (probably not alive either): uses MultiHashMap invicta: uses SequencedHashMap Is there any clear migration path for either of them that would allow them to use Commons Collection 3.2.1 and the current trunk at the same time or is it a decide which one you want to use? 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
Re: [collections] merging collections - DONE
--- On Tue, 9/15/09, Henri Yandell flame...@gmail.com wrote: From: Henri Yandell flame...@gmail.com Subject: [collections] merging collections - DONE To: Commons Developers List dev@commons.apache.org Date: Tuesday, September 15, 2009, 1:07 AM On Sun, Sep 13, 2009 at 9:08 PM, Henri Yandell flame...@gmail.com wrote: Tests compile (under Maven). 4 serialization ones fail when running - will dig into. Might be a merging issue with .obj files and id values in classes. Fixed these btw by setting serialVersionUIDs to the previous values as they didn't currently have anything set. It was for CompositeMap and MultiValueMap's ReflectionFactory. I'm not sure how we want to handle generics + serialization... not sure if we have to reset all of the UIDs for any class with generics in the API. Anyway... all done with the merge. That was fun :) 1. RE fun: You are truly a geek. 2. Thanks a lot--I feel like I personally owe you a couple of beers now. 3. I'd love to see the scripts. -Matt Hen - 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
[collections] generics WAS [jira] Commented: (COLLECTIONS-110) Support parametized classes with commons.collections.
Henri Yandell commented on COLLECTIONS-110: --- In the absence of anyone being active on a rewrite of Collections for generics, I agree with James that you should look elsewhere for an active project. I'm happy to help out with Collections 3.x bugs, and have done a fair bit towards 3.3, but I've neither the time to release 3.3 nor inclination to drive a redesigned 4.0. This is someday going to drive me to want to add some of the core most basic pieces of Collections to Lang :) I suspect that might be after a look at google-collections to make sure it's not something they have. Parts of ComparatorUtils, CollectionUtils, MapUtils and SetUtils. Most of the work here has been done in the collections_jdk5_branch. Are we ready for these changes to be merged back to trunk, and is there anyone who considers his svn-fu to be top-notch for the purposes of a large and complex merge? If we answer the first question yes, maybe we should start a thread for the second question, as my attempts to merge were less than fruitful. -Matt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] generics WAS [jira] Commented: (COLLECTIONS-110) Support parametized classes with commons.collections.
--- On Fri, 9/11/09, Henri Yandell flame...@gmail.com wrote: From: Henri Yandell flame...@gmail.com Subject: Re: [collections] generics WAS [jira] Commented: (COLLECTIONS-110) Support parametized classes with commons.collections. To: Commons Developers List dev@commons.apache.org Date: Friday, September 11, 2009, 10:33 AM On Fri, Sep 11, 2009 at 7:17 AM, Matt Bensongudnabr...@yahoo.com wrote: Henri Yandell commented on COLLECTIONS-110: --- In the absence of anyone being active on a rewrite of Collections for generics, I agree with James that you should look elsewhere for an active project. I'm happy to help out with Collections 3.x bugs, and have done a fair bit towards 3.3, but I've neither the time to release 3.3 nor inclination to drive a redesigned 4.0. This is someday going to drive me to want to add some of the core most basic pieces of Collections to Lang :) I suspect that might be after a look at google-collections to make sure it's not something they have. Parts of ComparatorUtils, CollectionUtils, MapUtils and SetUtils. Most of the work here has been done in the collections_jdk5_branch. Are we ready for these changes to be merged back to trunk, and is there anyone who considers his svn-fu to be top- notch for the purposes of a large and complex merge? If we answer the first question yes, maybe we should start a thread for the second question, as my attempts to merge were less than fruitful. If: a) it's considered that collections_jdk5 is ready, and b) someone volunteers to be the release manager then I'll take a stab at the merge. Definitely done these in the past, though it's always fun when you can't walk over to the people who made the commits and get them to explain the problematic change. First up would be to cp trunk to a 3.x branch. It's also possible that merging from trunk to the branch may prove easier. Damn it, Hen--that's part of the debate I wanted to save for a new thread! ;) Currently there are 28 open issues on the Generics JIRA version. Some big topics in there still, so I'm not convinced on a) above. That said, if it's felt that it's far enough along and there is interest/energy, then the merge could happen and patches could be double applied. Obviously my time has been retardedly limited as of late. I must confess I wasn't aware of there being any issues on the generics JIRA version, so it's quite possible I have addressed some of them. I'll take a look. -Matt Hen - 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: svn commit: r813954 - /commons/proper/collections/branches/collections_jdk5_branch/src/java/org/apache/commons/collections/map/StaticBucketMap.java
Thanks, Seb! ;)
--- On Fri, 9/11/09, s...@apache.org s...@apache.org wrote:
From: s...@apache.org s...@apache.org
Subject: svn commit: r813954 -
/commons/proper/collections/branches/collections_jdk5_branch/src/java/org/apache/commons/collections/map/StaticBucketMap.java
To: comm...@commons.apache.org
Date: Friday, September 11, 2009, 12:50 PM
Author: sebb
Date: Fri Sep 11 17:50:42 2009
New Revision: 813954
URL: http://svn.apache.org/viewvc?rev=813954view=rev
Log:
Make private immutable variables final
Add missing @Override markers and fix some raw types
Modified:
commons/proper/collections/branches/collections_jdk5_branch/src/java/org/apache/commons/collections/map/StaticBucketMap.java
Modified:
commons/proper/collections/branches/collections_jdk5_branch/src/java/org/apache/commons/collections/map/StaticBucketMap.java
URL:
http://svn.apache.org/viewvc/commons/proper/collections/branches/collections_jdk5_branch/src/java/org/apache/commons/collections/map/StaticBucketMap.java?rev=813954r1=813953r2=813954view=diff
==
---
commons/proper/collections/branches/collections_jdk5_branch/src/java/org/apache/commons/collections/map/StaticBucketMap.java
(original)
+++
commons/proper/collections/branches/collections_jdk5_branch/src/java/org/apache/commons/collections/map/StaticBucketMap.java
Fri Sep 11 17:50:42 2009
@@ -106,9 +106,9 @@
/** The default number of buckets
to use */
private static final int
DEFAULT_BUCKETS = 255;
/** The array of buckets, where
the actual data is held */
- private NodeK, V[] buckets;
+ private final NodeK, V[] buckets;
/** The matching array of locks
*/
- private Lock[] locks;
+ private final Lock[] locks;
/**
* Initializes the map with the default
number of buckets (255).
@@ -410,11 +410,12 @@
* @param obj the object to
compare to
* @return true if equal
*/
+ @Override
public boolean equals(Object obj)
{
if (obj == this) {
return
true;
}
- if (obj instanceof Map ==
false) {
+ if (obj instanceof Map?,
? == false) {
return
false;
}
Map?, ?
other = (Map?, ?) obj;
@@ -426,6 +427,7 @@
*
* @return the hash code
*/
+ @Override
public int hashCode() {
int hashCode = 0;
@@ -459,16 +461,18 @@
return
value;
}
+ @Override
public int
hashCode() {
return
((key == null ? 0 : key.hashCode()) ^
(value == null ? 0 :
value.hashCode()));
}
+ @Override
public boolean
equals(Object obj) {
if
(obj == this) {
return true;
}
- if (obj
instanceof Map.Entry == false) {
+ if (obj
instanceof Map.Entry?, ? == false) {
return false;
}
@@ -553,18 +557,22 @@
private class EntrySet extends
AbstractSetMap.EntryK, V {
+ @Override
public int size() {
return
StaticBucketMap.this.size();
}
+ @Override
public void clear()
{
StaticBucketMap.this.clear();
}
+ @Override
public
IteratorMap.EntryK, V iterator() {
return
new EntryIterator();
}
+ @Override
public boolean
contains(Object obj) {
Map.Entry?, ? entry =
(Map.Entry?, ?) obj;
int
hash = getHash(entry.getKey());
@@ -576,8 +584,9 @@
return
false;
}
+ @Override
public boolean
remove(Object obj) {
- if (obj
instanceof Map.Entry == false) {
+ if (obj
instanceof Map.Entry?, ? == false) {
return false;
}
Map.Entry?, ? entry =
(Map.Entry?, ?) obj;
@@ -597,22 +606,27 @@
private class KeySet extends
AbstractSetK {
+ @Override
public int size() {
return
StaticBucketMap.this.size();
}
+ @Override
public void clear()
{
StaticBucketMap.this.clear();
}
+ @Override
public
IteratorK iterator() {
return
new KeyIterator();
}
+ @Override
public boolean
contains(Object obj) {
return
StaticBucketMap.this.containsKey(obj);
}
+ @Override
public boolean
remove(Object obj) {
int
hash = getHash(obj);
synchronized (locks[hash]) {
@@ -632,14 +646,17 @@
private class Values extends
AbstractCollectionV {
+ @Override
public int size() {
return
StaticBucketMap.this.size();
}
+ @Override
public void
Re: svn commit: r813971 [1/3] - in /commons/proper/lang/trunk/src: java/org/apache/commons/lang/ArrayUtils.java test/org/apache/commons/lang/ArrayUtilsAddTest.java
Guys, no idea why so many spurious changes in the diff, but... sorry! --- On Fri, 9/11/09, mben...@apache.org mben...@apache.org wrote: From: mben...@apache.org mben...@apache.org Subject: svn commit: r813971 [1/3] - in /commons/proper/lang/trunk/src: java/org/apache/commons/lang/ArrayUtils.java test/org/apache/commons/lang/ArrayUtilsAddTest.java To: comm...@commons.apache.org Date: Friday, September 11, 2009, 1:27 PM Author: mbenson Date: Fri Sep 11 18:27:18 2009 New Revision: 813971 URL: http://svn.apache.org/viewvc?rev=813971view=rev Log: ArrayUtils generics Modified: commons/proper/lang/trunk/src/java/org/apache/commons/lang/ArrayUtils.java commons/proper/lang/trunk/src/test/org/apache/commons/lang/ArrayUtilsAddTest.java - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: jxpath 1.3 / mockrunner dependency
--- On Fri, 8/28/09, Alexander Kahl ak...@imttechnologies.com wrote: From: Alexander Kahl ak...@imttechnologies.com Subject: Re: jxpath 1.3 / mockrunner dependency To: Commons Developers List dev@commons.apache.org Cc: Alexander Kurtakov akurt...@redhat.com Date: Friday, August 28, 2009, 1:52 AM Hi Matt, On Thu, 2009-08-27 at 08:13 -0700, Matt Benson wrote: --- On Thu, 8/27/09, Alexander Kahl ak...@imttechnologies.com wrote: From: Alexander Kahl ak...@imttechnologies.com Subject: jxpath 1.3 / mockrunner dependency To: dev@commons.apache.org Cc: Alexander Kurtakov akurt...@redhat.com Date: Thursday, August 27, 2009, 3:22 AM Hi Apache Commons Developers, I'm a packager for the Fedora Project and co-maintainer of jxpath. We, the maintainers of jxpath, recently tried to update to the latest version 1.3 and realized that building the package requires mockrunner which seems to be quite unmaintained and pulls in unbearable dependencies like a full-fledged J2EE stack. We would therefore like to ask you to migrate to a modern, actively maintained replacement like easymock2. Other downstream projects (esp. distributions) that depend on building from source would also benefit from doing so. Please share your thoughts with us. Hi--I'd qualify as the maintainer of [jxpath] but I have admittedly had little time for it lately. I actually can't recall what mockrunner is needed for, but I will take your complaint under advisement and look into it. For the record, I've been having good luck with mockito lately so I might look at migrating jxpath to that. great stuff! Do you need any help from us? Well, as Jorg (forgive my non-use of proper accent characters) mentioned, opening a JIRA would help ensure the request doesn't get lost. And we always encourage contributions! -Matt Alex - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] ChainedTransformer...
James,
I refactored the comparable classes in [functor] to work just that way. I
didn't feel it was worth my personal effort to do it again in [collections]
given all the discussion around the future of [collections]' functors. Didn't
we all agree we could provide analogous functionality to that provided in
[collections] in [functor] and later deprecate the [collections] functors?
-Matt
--- On Sun, 6/7/09, James Carman ja...@carmanconsulting.com wrote:
From: James Carman ja...@carmanconsulting.com
Subject: [collections] ChainedTransformer...
To: Commons Developers List dev@commons.apache.org
Date: Sunday, June 7, 2009, 10:22 PM
All,
I thought I'd check out the collections_jdk5_branch to see
if there
was anything that I could tinker with. I decided to
look into the
functors, since that's what I'm mainly interested in.
Immediately I
noticed ChainedTransformer. It's declared as:
public class ChainedTransformerT implements
TransformerT, T, Serializable
So, does this mean that a ChainedTransformer always has to
have the
same input and output types? Transformer is declared
as:
public interface TransformerI, O {
public O transform(I input);
}
Shouldn't it support different input/output types?
What I was thinking about would be a new way to think about
these chains:
public class ChainedTransformerI,O implements
TransformerI,O
{
public ChainedTransformer(TransformerI,O
initial);
public O transform(I input);
public T ChainedTransformerI,T
append(TransformerO,T next);
}
Typically, to create a ChainedTransformer, you have to put
your
transformers in a collection and pass them in to create
one. This
way, instead of having to create a new collection, you'd
just append
as you go. What do you think?
-
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: [collections] ChainedTransformer...
The analogous class in [functor], btw, is CompositeUnaryFunction.
-Matt
--- On Mon, 6/8/09, James Carman ja...@carmanconsulting.com wrote:
From: James Carman ja...@carmanconsulting.com
Subject: Re: [collections] ChainedTransformer...
To: Commons Developers List dev@commons.apache.org
Date: Monday, June 8, 2009, 8:45 AM
I was more thinking of the
concepts. I agree this kind of stuff
should move into functor.
On Mon, Jun 8, 2009 at 8:56 AM, Matt Bensongudnabr...@yahoo.com
wrote:
James,
I refactored the comparable classes in [functor] to
work just that way. I didn't feel it was worth my personal
effort to do it again in [collections] given all the
discussion around the future of [collections]' functors.
Didn't we all agree we could provide analogous
functionality to that provided in [collections] in [functor]
and later deprecate the [collections] functors?
-Matt
--- On Sun, 6/7/09, James Carman ja...@carmanconsulting.com
wrote:
From: James Carman ja...@carmanconsulting.com
Subject: [collections] ChainedTransformer...
To: Commons Developers List dev@commons.apache.org
Date: Sunday, June 7, 2009, 10:22 PM
All,
I thought I'd check out the
collections_jdk5_branch to see
if there
was anything that I could tinker with. I decided
to
look into the
functors, since that's what I'm mainly interested
in.
Immediately I
noticed ChainedTransformer. It's declared as:
public class ChainedTransformerT
implements
TransformerT, T, Serializable
So, does this mean that a ChainedTransformer
always has to
have the
same input and output types? Transformer is
declared
as:
public interface TransformerI, O {
public O transform(I input);
}
Shouldn't it support different input/output
types?
What I was thinking about would be a new way to
think about
these chains:
public class ChainedTransformerI,O
implements
TransformerI,O
{
public
ChainedTransformer(TransformerI,O
initial);
public O transform(I input);
public T ChainedTransformerI,T
append(TransformerO,T next);
}
Typically, to create a ChainedTransformer, you
have to put
your
transformers in a collection and pass them in to
create
one. This
way, instead of having to create a new collection,
you'd
just append
as you go. What do you think?
-
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
-
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
Commons available @ Atlassian Fisheye
http://fisheye6.atlassian.com/ - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: How to make a proposal
It kind of depends on what you're proposing... a new component? Probably start a discussion on this list. Enhancements to an existing component? Either start here on the list or open a JIRA issue. Does this help? -Matt --- On Sun, 5/31/09, chris0 technic...@gmail.com wrote: From: chris0 technic...@gmail.com Subject: How to make a proposal To: dev@commons.apache.org Date: Sunday, May 31, 2009, 5:57 AM Hello, Suppose I wanted to make a proposal for something to be included in Commons, is there any particular way I should go about it, or should I just post it in this forum? Thanks, Chris -- View this message in context: http://www.nabble.com/How-to-make-a-proposal-tp23802008p23802008.html Sent from the Commons - Dev mailing list archive at Nabble.com. - 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: [jxpath] Adding functions
Emmanuel: I couldn't speak to the original intent, of course. I would support anything that would make JXPath less brittle--it's just been that given the existence of XPath 2, it's been somewhat an expectation that any substantial rewrite of JXPath would also incorporate support for the later spec, which has been touted as being a tall order (I really haven't researched it in any depth). Personally I have no experience with JavaCC, preferring ANTLR. JavaCC does yield no runtime dependencies, but we _could_ inline ANTLR dependencies were we to rewrite the parser... -Matt --- On Fri, 5/29/09, Emmanuel Bourg ebo...@apache.org wrote: From: Emmanuel Bourg ebo...@apache.org Subject: [jxpath] Adding functions To: Commons Developers List dev@commons.apache.org Date: Friday, May 29, 2009, 6:30 AM I played a bit with JXPath today to implement the ends-with() function. I thought it would be a quick copypaste of the starts-with() function, but that was a little more tricky. The function is referenced in several places, and I had to regenerate the parser with JavaCC. I wonder if it would be possible to have a more modular design for the core functions. Since there is already a Function interface, the core functions could be implemented as individual classes implementing this interface. But maybe there was a reason for handling the core functions differently from the user defined functions? Also worth noting, I tried to generate the parser with JavaCC 4.1 through the Maven2 plugin but it failed. StressTest displayed a huge call trace on the console and died with an OutOfMemoryError, even with 1GB of RAM allocated to Maven. Emmanuel Bourg - 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-logging version 0.0.0-EMPTY
--- On Wed, 5/20/09, Niall Pemberton niall.pember...@gmail.com wrote: From: Niall Pemberton niall.pember...@gmail.com Subject: Re: commons-logging version 0.0.0-EMPTY To: Commons Developers List dev@commons.apache.org Date: Wednesday, May 20, 2009, 7:52 PM On Tue, May 19, 2009 at 1:03 PM, Ceki Gulcu c...@qos.ch wrote: Jörg Schaible wrote: Forgive me for asking, but were you aware of the above. And if you were, would you care to explain a scenario in mind which is troubling you? First: The solution is perfect for a normal user i.e. somebody building an application, not a library/framework. The problem starts when somebody publishes some artifacts that explicitly depend on cl-0.0.0-EMPTY: 1. Me building A, depending on B and C 2. B depends on cl-0.0.0-EMPTY 3. C depends on cl-1.1.1 According the definition above I get a ClassNotFoundException running A if I declare my dependencies in sequence B, C. Since both deps use CL and A inherits it transitively at equal level, the first one wins = boom. You are correct. In defense of 0.0-EMPTY authors of libraries are not supposed to use use cl-0.0-EMPTY. Only end-users should use it. Any documentation for cl-0.0-EMPTY would need to emphasize that in bold and red print. Moreover, if you are an author of a library, if you don't want to use commons-logging, you can simply remove the dependency on commons-logging. You would not need cl-0.0-EMPTY at all. You would have use for cl-0.0-EMPTY if as an author of a library or framework with many dependencies (e.g. wicket, tapestry) you had a dependency which in turn depended on commons-logging, (and only if you were using Maven and SLF4J). Stern warnings in the documentation of version 0.0-EMPTY should goad authors of shared components away from 0.0-EMPTY. However, I agree with you that the risk of misuse of 0.0-EMPTY cannot be completely alleviated. It's a tough call to make. So the alternative to releasing the version to the main maven repo is to setup a one-off repo just containing this 0.0-EMPTY version of logging and users who want to depend on it adding that repo to their pom along with the 0.0-EMPTY dependency. Thats just a few extra lines of XML and guarantees there can be no problem. I don't think we should do this if theres a potential problem for commons-logging users that don't want this hack and a simple and easy solution for those that do. Since I'm in the middle of prototyping a new $work app that uses slf4j/logback and needs such exclusion of [logging], can I gloatingly interject that Ivy interacts with Maven repos AND has exclusion declaration built right in? ;) -Matt Niall - Jörg -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: commons-logging version 0.0.0-EMPTY
--- On Tue, 5/19/09, Jochen Wiedmann jochen.wiedm...@gmail.com wrote: From: Jochen Wiedmann jochen.wiedm...@gmail.com Subject: Re: commons-logging version 0.0.0-EMPTY To: Commons Developers List dev@commons.apache.org Date: Tuesday, May 19, 2009, 9:40 AM On Tue, May 19, 2009 at 2:46 PM, Ceki Gulcu c...@qos.ch wrote: Jochen, you do realize that global exclusions would suffer from the same problems as you described in the A B C scenario. Here is a slightly modified version of your scenario. May be, but I'd rather have the overall Maven community work on that than our isolated group create a special solution for a problem, which isn't even ours. (Sorry!) Come to think of it, it occurs to me to wonder what happens if the would-be user of 0.0.0-EMPTY declares an explicit provided dependency on [logging]. Can anyone say? -Matt Jochen -- Don't trust a government that doesn't trust you. - 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: [all] Rebooting commons projects
--- On Mon, 5/18/09, Jörg Schaible joerg.schai...@gmx.de wrote: From: Jörg Schaible joerg.schai...@gmx.de Subject: Re: [all] Rebooting commons projects To: dev@commons.apache.org Date: Monday, May 18, 2009, 2:19 AM Matt Benson wrote at Sonntag, 17. Mai 2009 22:31: --- On Sun, 5/17/09, Matt Benson gudnabr...@yahoo.com wrote: --- On Wed, 5/13/09, James Carman ja...@carmanconsulting.com wrote: [snip] The point (at least mine) is that we don't *need* to create a new project here. We have the ability (if we jump major version numbers and change package names) to be innovative with the existing projects. We don't have to guarantee backward compatibility between major versions. This has historically been the view taken in Commons, and I'm not seeing a consensus to change that view. [SNIP] Or, to put it another way, the consensus seems to be that the component + the major version # makes a project. I think we more or less all agree that such a new component should play nice with an older version in the classpath. However, while I am all for evolving the current project with a new major release, we have to consider that it is not possible to have the same artifact twice in the same Maven project with a different version only. It does not matter if foo-1.x can be used at same time with foo-2.x, Maven does simply not support this scenario. Therefore we would have to change the artifact name anyway to something like foo2-2.x ... Which still resounds with my preceding statement, though I admittedly hadn't thought it through that far. So anytime the API changes in a breaking way we need to jump major versions, append the new major version to the component name for the m2 artifact, and do likewise for our o.a.c.*-level package. Having done all this our users have complete freedom to upgrade what they want, continue using other 3p libs that require [component]-previousVersion.n.n, etc. Stephen, you've indicated your intent to forfeit your -1 prerogative based on your having been drawn off to other things for the past year or two; at the same time I'd prefer to feel all PMC members who remain even perfunctorily engaged are at least satisfied with if not enthusiastic about whatever approach is settled upon. :) I really feel, however, that the above mitigates your expressed concerns, particularly when taken in consideration with the fact that probably half the time our breaking changes will NOT be a full redesign of a given component... So what do you say to that? ;D -Matt - Jörg - 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-logging version 0.0.0-EMPTY
--- On Mon, 5/18/09, nicolas de loof nicolas.del...@gmail.com wrote: From: nicolas de loof nicolas.del...@gmail.com Subject: Re: commons-logging version 0.0.0-EMPTY To: Commons Developers List dev@commons.apache.org Date: Monday, May 18, 2009, 8:39 AM The POM should include SCM path, url to commons-logging site and licensing metadata Maybe you could also include the blog extract as description / comment. The description explains the jar is empty but not why it is there 2009/5/18 Ceki Gulcu c...@qos.ch Hello all, I have created an empty Maven project with groupId commons-logging, artifactId commons-logging and version 0.0.0-EMPTY. There is very little content (around 500 bytes) in the whole project. This is to be expected as the original aim was to produce an empty jar file. For the actual source code, see https://svn.apache.org/viewvc/commons/sandbox/logging_empty/trunk/ Just to point out: the final location of this code should AIUI BE a branch under logging/branches... the current structure isn't harming anything at the moment, however. Anyway, as discussed previously, how do we go about publishing this empty jar on ibiblio (Maven's central repository). Is a vote warranted, or would that be premature? I think we need to: -agree that the POM is correct/complete according to the wishes of the community -promote to proper by moving https://svn.apache.org/repos/asf/commons/sandbox/logging_empty/trunk to https://svn.apache.org/repos/asf/commons/proper/logging/branches/logging_EMPTY -update svn information in POM -generate/tag/vote 0.0.0 RC cycle -release/tag 0.0.0 final Any modifications needed? -Matt -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - 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-logging version 0.0.0-EMPTY
--- On Mon, 5/18/09, Ceki Gulcu c...@qos.ch wrote: From: Ceki Gulcu c...@qos.ch Subject: Re: commons-logging version 0.0.0-EMPTY To: Commons Developers List dev@commons.apache.org Date: Monday, May 18, 2009, 9:14 AM Matt Benson wrote: For the actual source code, see https://svn.apache.org/viewvc/commons/sandbox/logging_empty/trunk/ Just to point out: the final location of this code should AIUI BE a branch under logging/branches... the current structure isn't harming anything at the moment, however. Sounds good. I think we need to: -agree that the POM is correct/complete according to the wishes of the community -promote to proper by moving https://svn.apache.org/repos/asf/commons/sandbox/logging_empty/trunk to https://svn.apache.org/repos/asf/commons/proper/logging/branches/logging_EMPTY -update svn information in POM -generate/tag/vote 0.0.0 RC cycle -release/tag 0.0.0 final +1 (thank you for making the above list) Is there a point in making a standalone release for an artifact which is empty? For someone using ant there is no point in including commons-logging.0.0.0-EMPTY.jar, as they can just as easily remove references to commons-logging in their build.xml file. (Obviously, for a developer using Maven with *transitive* dependencies, it's a different matter.) I think you're right; this release exists only for the benefit of Maven users, so we probably don't need to make a DL available from the website. We do need to decide how much documentation we want to provide from [logging]'s site about this release. -Matt -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - 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-logging version 0.0.0-EMPTY
--- On Mon, 5/18/09, Craig L Russell craig.russ...@sun.com wrote: From: Craig L Russell craig.russ...@sun.com Subject: Re: commons-logging version 0.0.0-EMPTY To: Commons Developers List dev@commons.apache.org Date: Monday, May 18, 2009, 12:18 PM Hi, On May 18, 2009, at 10:00 AM, sebb wrote: On 18/05/2009, Ceki Gulcu c...@qos.ch wrote: Hello, Thank you for this suggestion. Unfortunately, adding references to parent pom, addDefaultImplementationEntries and addDefaultSpecificationEntries creates a manifest file which includes OSGi directives, which is really not desirable. These can be suppressed. Just for my information, why is it not desirable to package this as an OSGi compliant jar? The very purpose of this branch is NOT to provide any classes/package implementations. ;) Also, why is the maven group id commons-logging and not org.apache.commons? Is this just a historical curiosity or was there a purpose? Historical oddity: previous logging releases have occurred using this group ID; since this pseudo-release is intended to allow users to supercede other logging releases, forcing the use of this empty jar, the same group ID is needed. If further commons-logging releases are made in the correct group (o.a.c.) I assume an o.a.c.logging-0.0.0-EMPTY release would have to be made then as well. HTH, Matt Thanks, Craig However, surely referencing the apache pom as a parent pom does not do this? I just tried, and using the default tags works OK for me. I changed the contents of the name element to Commons Logging. sebb wrote: Thanks, although IMO it would have been better to use manifest addDefaultImplementationEntriestrue/addDefaultImplementationEntries addDefaultSpecificationEntriestrue/addDefaultSpecificationEntries /manifest rather than hard-coding the values. Also, the pom name is wrong, it should be nameCommons Logging/name as per the existing pom.xml in logging/trunk. The pom.xml for empty_logging should also have as parent either the commons parent, or at least the apache parent. That would allow the use of the default manifest entries as above. -- Ceki Gülcü Logback: The reliable, generic, fast and flexible logging framework for Java. http://logback.qos.ch - 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 Craig L Russell Architect, Sun Java Enterprise System http://db.apache.org/jdo 408 276-5638 mailto:craig.russ...@sun.com P.S. A good JDO? O, Gasp! - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Rebooting commons projects
--- On Wed, 5/13/09, James Carman ja...@carmanconsulting.com wrote: From: James Carman ja...@carmanconsulting.com Subject: Re: [all] Rebooting commons projects To: Commons Developers List dev@commons.apache.org Date: Wednesday, May 13, 2009, 7:13 PM On Wed, May 13, 2009 at 7:21 PM, Stephen Colebourne scolebou...@btopenworld.com wrote: STOP everyone, please! Go back and read the original email. The name of the new project isn't the point of this discussion at all. Right now I don't give a damn about the name. The point (at least mine) is that we don't *need* to create a new project here. We have the ability (if we jump major version numbers and change package names) to be innovative with the existing projects. We don't have to guarantee backward compatibility between major versions. This has historically been the view taken in Commons, and I'm not seeing a consensus to change that view. In the concrete case of functor/collections it seems that Stephen is amenable to, over time, removing functor support from collections altogether, which IMHO is a satisfactory compromise. We just need to make sure that anything [collections] does with functors has an analogous operation in [functor], and maybe a nice writeup of how to use [functor]-provided collection operations instead of [collections]'. -Matt - 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: New Sandbox Component Proposal: Commons JSON
--- On Sat, 5/16/09, Phil Steitz phil.ste...@gmail.com wrote: From: Phil Steitz phil.ste...@gmail.com Subject: Re: New Sandbox Component Proposal: Commons JSON To: Commons Developers List dev@commons.apache.org Date: Saturday, May 16, 2009, 7:24 AM Henri Yandell wrote: On Fri, May 15, 2009 at 6:44 PM, Phil Steitz phil.ste...@gmail.com wrote: Christian Grobmeier wrote: Dear Commons-Folks, Yonik Seeley and I propose the creation of a new Sandbox component within Apache Commons. We would like to name it Commons JSON since it should deal with everything around JSON. Yonik did already implement a JSON-Parser in Apache Labs name Noggit: http://svn.apache.org/repos/asf/labs/noggit/ I have implemented some other JSON-Lib at Google Code: http://code.google.com/p/jjson We would like to join forces since my JSON lib isn't very good at parsing and Noggit lacks of some classes I created. Here is the original proposal from Noggit which also fits to JJSON: There is a need for an industrial strength JSON parser for Java with the following features: - Streaming API (StAX/pull-parser like) for both easy and efficient parsing - Conforms to the JSON standard: http://www.ietf.org/rfc/rfc4627.txt - Can adhere strictly to the standard (not a superset like existing parsers), preferably by default - Memory efficiency - incremental parsing (Reader-based) in order to handle huge messages - a single byte of state needed per nested object or array - does not read large objects (including primitives) completely into memory unless asked - can eliminate most copying, allowing the user to provide the output buffer for values - no built in size limits for primitives (less than 2GB) - can even handle keys of any size in a map - can handle primitives of *any* size (does not attempt to parse numerics into a certain language primitives unless asked) - Fast! I would like to add: - no dependencies! - Creates JSON Strings of Objects and vice versa - Annotations for creating objects from a JSON string. We believe that a JSON lib will become attention quickly and hope to get more developers attracted soon. Please let us know what you think about it! Sounds great! As a commons committer, you can start things in the sandbox without a formal vote. You should probably execute a grant for the stuff done outside the ASF. Does Yonik have sandbox karma? If not, just ask. Happy hacking! Didn't we resolve that a grant for stuff outside the ASF by someone who has signed a CLA is fine? Whence probably - I would not personally complain as long as the non-ASF stuff is the original work of one person, is clean from IP standpoint and is not large. The last is a judegement call. I think we did more-or-less agree, if lazily, that the above was okay. -Matt Phil Hen - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] Rebooting commons projects
--- On Wed, 5/13/09, Jörg Schaible joerg.schai...@gmx.de wrote: From: Jörg Schaible joerg.schai...@gmx.de Subject: Re: [all] Rebooting commons projects To: dev@commons.apache.org Date: Wednesday, May 13, 2009, 12:57 AM James Carman wrote at Mittwoch, 13. Mai 2009 04:30: On Tue, May 12, 2009 at 9:38 PM, Dan Fabulich d...@fabulich.com wrote: If you feel like you'd want to call it lang2 or lang-ng then just call it lang 2.0 or 3.0 or whatever and keep a lang-1.x branch around for stability fixes. I thought we agreed that we would jump major version numbers (as you suggest here I think) whenever we are going to break backwards compatibility (which would include next generation type changes). Then, we would change the package name to match to avoid the jar hell issue. +1 Add another voice to the pile saying that solutions other than a major version number bump don't seem to scale. -Matt I don't like the ng stuff either. What's next? Commons Lang Deep Space 9? :) Doesn't a new major version number imply next generation? Hehehe ... reloaded? Fortunately we're forward bound, otherwise we would additionally talk about origins :)) - Jörg - 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: [all] Core library dependencies [was COLLECTIONS 3.3 release]
--- On Tue, 5/12/09, Jörg Schaible joerg.schai...@gmx.de wrote: From: Jörg Schaible joerg.schai...@gmx.de Subject: Re: [all] Core library dependencies [was COLLECTIONS 3.3 release] To: dev@commons.apache.org Date: Tuesday, May 12, 2009, 7:54 AM John Bollinger wrote at Dienstag, 12. Mai 2009 14:19: Stephen Colebourne wrote: The 'functors' in [collections] and [functor] are very different: Thanks for clearing that up. It obviously moots my argument as it applies to Collections / Functor, though I think the distinction between private dependencies and public ones is still generally relevant to Commons projects. Thanks John for continuing the discussion. You did it exactly in the way I would have done, but as a non-native speaker, this gets hard sometimes to express the right thing. And I am also surprised of the big differences in implementation in this case. As I see it, the functors in [collections] are a subset of those in [functor]. Presuming we allow both sets to stand, this still does not address the concern voiced by James Carman: a [functor] UnaryFunctor--for any of which an analogous interface WILL exist in [collections]--is not readily usable in [collections]. I still don't see what the big deal is about optional dependencies, so can we agree that [functor] could provide adapters to [collections]'s functors when appropriate, creating an OPTIONAL dependency on [collections] from [functor] (i.e. required only when the adapter code is used)? -Matt - Jörg - 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: [all] Core library dependencies [was COLLECTIONS 3.3 release]
--- On Tue, 5/12/09, Stephen Colebourne scolebou...@btopenworld.com wrote: From: Stephen Colebourne scolebou...@btopenworld.com Subject: Re: [all] Core library dependencies [was COLLECTIONS 3.3 release] To: Commons Developers List dev@commons.apache.org Date: Tuesday, May 12, 2009, 6:29 AM From: John Bollinger thinma...@yahoo.com Which is exactly why Collections should not copy Functor. Either Functor should be absorbed back into Collections, or Collections should have Functor as a dependency, for otherwise users must maintain separate functors for use with Collections and for other purposes. Users of both can rely on the Collections functors for everything, but that de facto rolls Functor into Collections for them. It also obligates them to adhere to that approach, which has great potential for integration pain. A key issue here is that parts of the Collections public API reference classes / interfaces of Functor. Collections therefore must either own Functor or depend on it. There is no reasonable way to split the two projects without making one depend on the other. This is different from the case in some Commons projects where classes are copied from another Commons component for private, internal-only use. Note also that the same argument applies to moving the functor-based collections to Functor: then Functor would need to have Collections as a dependency. The 'functors' in [collections] and [functor] are very different: http://commons.apache.org/collections/api-release/org/apache/commons/collections/package-summary.html http://commons.apache.org/sandbox/functor/apidocs/org/apache/commons/functor/package-summary.html There is no need to share these interfaces, add dependencies or anything similar. (Equally, were they the same John's argument would be sound.) What [functor] needs is the confidence to stand up and say hey, come and use me, here's what I offer. I somewhat resent the implication that I and others might be trying to buffalo [functor] into proper status, but I'm known for paranoia, so forgive me if I've read more into that statement than was intended. There is good stuff in [functor], but critically it is a semi-religious approach to coding. By this, I mean that developers have to buy-in to the idea that writing and using lots of small inner classes in a compositional fashion is what they want. And exactly in the same way as many developers don't like functional programming, many won't like the [functor] approach. That doesn't make it bad or wrong, it just means that it needs to stand up and own its own space. Users should want to use [functor] for what it offers. They need to make a positive choice. Now look at the other angle - what do users of [collections] want? Its additional implementations of JCF collections, and new related collection interfaces. In many ways, its a historic oddity that [collections] has any functor-like stuff at all. Many (most) users of collections are not interested in the functor-type stuff I'd suggest. IMO this sounds like a reason to remove functor concerns from [collections] entirely. My strong recommendation is to add key collection classes to [functor] (directly implementing the JDK List/Set/Map interfaces). They differ from those in [collections] because the API of Predicate/Function etc is so different. Then promote [functor] to commons-proper with no dependencies. Then, [collections] can, over time, consider if it wishes to deprecate and remove its own functor based collections in favour of those in [functor], without ever needing a dependency beyond the JDK. This is exactly how the bean sytle collections were moved out to [bean-collections]. I wonder if it's worth the effort to maintain three jars for [beanutils] so that users can use split jars of a six-class difference when the dependency is still optional even when using the complete jar. But perhaps this is valuable when using dependency analysis of bytecode; not being a user of such tools I wouldn't know. From whence did the bean-collections move? [collections]? Otherwise the analogy seems a little off. BTW, [collections] does publish a test-framework jar that [functor] could depend on as a test-only dependency. Noted. -Matt Stephen - 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: [COLLECTIONS] 3.3 release
--- On Wed, 5/6/09, sebb seb...@gmail.com wrote: From: sebb seb...@gmail.com Subject: Re: [COLLECTIONS] 3.3 release To: Commons Developers List dev@commons.apache.org Date: Wednesday, May 6, 2009, 6:22 AM On 06/05/2009, Matt Benson gudnabr...@yahoo.com wrote: --- On Tue, 5/5/09, sebb seb...@gmail.com wrote: [SNIP] ExtendedProperties still needs to be genericised. This class can't be made generic in a meaningful way, IMO. We can make the gesture and say it extends HashtableObject, Object FWIW. [which is what java.util.Properties does] Or HashtableString, Object ? We have the option to enforce String keys if we want to break BC. Currently the class uses String.valueOf(key) to accept other types. Personally I can't see myself ever using this class so I really don't care. ;) I won't worry about having offended the original authors with such a statement because it appears (judging from order of @author tags) that they are all guys who have long since moved on from Commons (Java?). There are also internal fields which can be made type safe. Every little helps. When I went through the [collections] code I actually started working on this class but got too many changes at once whirling around--brain started to bleed, and I reverted lest I lose my mind completely. :D There are over 1000 missing @Override markers (some in test classes) and a few missing @Deprecated markers. Okay, but give me a break. Those aren't real work... :) Huh? each one should really be checked to ensure that the override is intentional ;-) Sure! -Matt -Matt -Matt On Thu, Apr 30, 2009 at 1:14 AM, Henri Yandell flame...@gmail.com wrote: 3.3 is a whole load of bugfixes that have accumulated. I added a few more likely tickets. I've been paying more attention to Jakarta Taglibs and trying to get JSTL out there than Collections (which is a bit of an indictment on my mental state as that's meant mavenizing that project rather than working out Collections' situation). I'm not sure if Collections is releasable from Maven2 - that's the next step for 3.3 to figure out if anything needs to change to make it more akin to the others. Hen On Tue, Apr 28, 2009 at 2:27 PM, Gary Gregory ggreg...@seagullsoftware.com wrote: I think adding generics would be great. Even if the next version only adds generics, that is reason enough for me to help and upgrade our apps. Release early, release often. Gary -Original Message- From: Dave Meikle [mailto:loo...@gmail.com] Sent: Tuesday, April 28, 2009 11:09 AM To: dev@commons.apache.org Subject: [COLLECTIONS] 3.3 release Hi, I know late last year Henri spoke about doing a 3.3 release of Collections but I assume other commitments took over - this certainly keeps happening to me just now. I see there are some new tickets that need some minor work, so was wondering what are the current plans? Apologises if I have missed a previous posting on this. Cheers, Dave - 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 - 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 - 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: [COLLECTIONS] 3.3 release
--- On Thu, 4/30/09, James Carman ja...@carmanconsulting.com wrote: From: James Carman ja...@carmanconsulting.com Subject: Re: [COLLECTIONS] 3.3 release To: Commons Developers List dev@commons.apache.org Date: Thursday, April 30, 2009, 12:18 AM I would love to see a collections version that is based on commons-functor (once it's generified). Notwithstanding the fact that I'm way behind on email, what is it above? [functor]'s generification has been complete for nearly a year. [collections] is done in the branch AFAIK. I simply haven't had time to figure out how to get svn to merge it back to trunk. -Matt On Thu, Apr 30, 2009 at 1:14 AM, Henri Yandell flame...@gmail.com wrote: 3.3 is a whole load of bugfixes that have accumulated. I added a few more likely tickets. I've been paying more attention to Jakarta Taglibs and trying to get JSTL out there than Collections (which is a bit of an indictment on my mental state as that's meant mavenizing that project rather than working out Collections' situation). I'm not sure if Collections is releasable from Maven2 - that's the next step for 3.3 to figure out if anything needs to change to make it more akin to the others. Hen On Tue, Apr 28, 2009 at 2:27 PM, Gary Gregory ggreg...@seagullsoftware.com wrote: I think adding generics would be great. Even if the next version only adds generics, that is reason enough for me to help and upgrade our apps. Release early, release often. Gary -Original Message- From: Dave Meikle [mailto:loo...@gmail.com] Sent: Tuesday, April 28, 2009 11:09 AM To: dev@commons.apache.org Subject: [COLLECTIONS] 3.3 release Hi, I know late last year Henri spoke about doing a 3.3 release of Collections but I assume other commitments took over - this certainly keeps happening to me just now. I see there are some new tickets that need some minor work, so was wondering what are the current plans? Apologises if I have missed a previous posting on this. Cheers, Dave - 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 - 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: [COLLECTIONS] 3.3 release
--- On Tue, 5/5/09, James Carman ja...@carmanconsulting.com wrote: From: James Carman ja...@carmanconsulting.com Subject: Re: [COLLECTIONS] 3.3 release To: Commons Developers List dev@commons.apache.org Date: Tuesday, May 5, 2009, 12:35 PM On Tue, May 5, 2009 at 1:14 PM, Matt Benson gudnabr...@yahoo.com wrote: Notwithstanding the fact that I'm way behind on email, what is it above? [functor]'s generification has been complete for nearly a year. [collections] is done in the branch AFAIK. I simply haven't had time to figure out how to get svn to merge it back to trunk. I'm trying to remember myself! :) I would think collections, since that's what this email was regarding. Is there a branch that gets rid of Transformer, Closure, and Predicate from collections and instead uses Functor's versions of these concepts? That's what I'd like to see (aside from the fact that I'd have to rewrite all my nifty transformers). That subject probably requires a debate. Stephen didn't want to completely switch to [functor]. -Matt - 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: [COLLECTIONS] 3.3 release
--- On Tue, 5/5/09, Stephen Colebourne scolebou...@btopenworld.com wrote: From: Stephen Colebourne scolebou...@btopenworld.com Subject: Re: [COLLECTIONS] 3.3 release To: Commons Developers List dev@commons.apache.org Date: Tuesday, May 5, 2009, 4:37 PM Matt Benson wrote: --- On Tue, 5/5/09, James Carman ja...@carmanconsulting.com wrote: I'm trying to remember myself! :) I would think collections, since that's what this email was regarding. Is there a branch that gets rid of Transformer, Closure, and Predicate from collections and instead uses Functor's versions of these concepts? That's what I'd like to see (aside from the fact that I'd have to rewrite all my nifty transformers). That subject probably requires a debate. Stephen didn't want to completely switch to [functor]. I think its really important that [collections] has no dependencies. As part of that, I'd also suggest that [functor] shouldn't have dependencies. While I understand the arguments of just picking up another jar if your using it, of tools like maven, and of eating dog food, when push comes to shove, I believe that one of the core conceptual attributes of [collections] is that it stands alone. The list archives contains more detailed discussion on this for those wanting to hunt it down ;-) Given that I am removed from the coding aspects of this these days, I won't -1 any decisions on this. But I will register that I believe my position very strongly. I feel differently--how many times do we need to duplicate code that does the same damned thing amongst the various components? For example, we've now added MethodUtils to [lang], but [collections] has its own set of code supporting InvokerTransformer. [functor] doesn't have an analogous function because it seemed to me silly to keep rewriting and/or copying the necessary code. IMHO we of the Commons need to establish an approach for mixin components, optional dependencies, svn externals, something, to avoid doing this again and again and again. br, Matt Stephen - 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: [COLLECTIONS] 3.3 release
--- On Tue, 5/5/09, sebb seb...@gmail.com wrote: From: sebb seb...@gmail.com Subject: Re: [COLLECTIONS] 3.3 release To: Commons Developers List dev@commons.apache.org Date: Tuesday, May 5, 2009, 6:02 PM On 05/05/2009, Matt Benson gudnabr...@yahoo.com wrote: --- On Thu, 4/30/09, James Carman ja...@carmanconsulting.com wrote: From: James Carman ja...@carmanconsulting.com Subject: Re: [COLLECTIONS] 3.3 release To: Commons Developers List dev@commons.apache.org Date: Thursday, April 30, 2009, 12:18 AM I would love to see a collections version that is based on commons-functor (once it's generified). Notwithstanding the fact that I'm way behind on email, what is it above? [functor]'s generification has been complete for nearly a year. [collections] is done in the branch AFAIK. I simply haven't had time to figure out how to get svn to merge it back to trunk. If you are referring to the branch collections_jdk5_branch then ExtendedProperties still needs to be genericised. This class can't be made generic in a meaningful way, IMO. We can make the gesture and say it extends HashtableObject, Object FWIW. There are over 1000 missing @Override markers (some in test classes) and a few missing @Deprecated markers. Okay, but give me a break. Those aren't real work... :) -Matt -Matt On Thu, Apr 30, 2009 at 1:14 AM, Henri Yandell flame...@gmail.com wrote: 3.3 is a whole load of bugfixes that have accumulated. I added a few more likely tickets. I've been paying more attention to Jakarta Taglibs and trying to get JSTL out there than Collections (which is a bit of an indictment on my mental state as that's meant mavenizing that project rather than working out Collections' situation). I'm not sure if Collections is releasable from Maven2 - that's the next step for 3.3 to figure out if anything needs to change to make it more akin to the others. Hen On Tue, Apr 28, 2009 at 2:27 PM, Gary Gregory ggreg...@seagullsoftware.com wrote: I think adding generics would be great. Even if the next version only adds generics, that is reason enough for me to help and upgrade our apps. Release early, release often. Gary -Original Message- From: Dave Meikle [mailto:loo...@gmail.com] Sent: Tuesday, April 28, 2009 11:09 AM To: dev@commons.apache.org Subject: [COLLECTIONS] 3.3 release Hi, I know late last year Henri spoke about doing a 3.3 release of Collections but I assume other commitments took over - this certainly keeps happening to me just now. I see there are some new tickets that need some minor work, so was wondering what are the current plans? Apologises if I have missed a previous posting on this. Cheers, Dave - 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 - 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 - 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: New Sandbox Component Proposal: Commons JSON
--- On Thu, 4/30/09, Christian Grobmeier grobme...@gmail.com wrote: From: Christian Grobmeier grobme...@gmail.com Subject: Re: New Sandbox Component Proposal: Commons JSON To: Commons Developers List dev@commons.apache.org Date: Thursday, April 30, 2009, 9:55 AM Why do you consider a dependency on Antlr a negative (the runtime is 148k), JSON is a formally defined language after all. I don't know a person face to face who actually can handle antlr. Its a cool tool, but if you need to create a patch for your json lib, it can be hell. Plain java is understood by every java developer (well, most ;-)). I don't know about folks you (or I) know face-to-face, but I know that several ASF committers and members have popped up around the ANTLR lists over the years, including, off the top of my head, myself, Torsten, O.Ziegermann, H.L. Ship, and probably others. I personally am quite comfortable with ANTLR 2.x but need to really take the time to play with ANTLR 3. The argument _for_ using parser generators is that those who use them feel the grammar is easier to digest (it's smaller) than the equivalent Java code. It's something else again to debug ANTLR parsers/treeparsers, but it's far from impossible. Once you get used to knowing what to look for it's actually fairly easy. I don't say any of this to disparage Yonik's work on Noggit (I've not looked at it); I am just airing my understanding of the motivations for using grammars and parser generators as opposed to hand-writing parsers. -Matt I always scratch my head when I hear there are dependencies! when any application I create or use always has dependencies. I wonder how much redundancies and bug fixes would be removed if, for example, all Apache Java code (or even just the Commons code) went the other way and did depend on each other. You might argue we would end up in 'jar hell' but that might force us to better draw boundaries between components and fix bugs :) In maven age I don't feel bad with dependencies, but one json lib did depend on asm version 1 once, and hibernate upgraded to asm version 2, and that gave me nightmare. I ended up with opening my json package and copied all version 1 files into it with own package name. I recompiled, brought this to my repos and so on. This was hell (cause my customer didn't want to pay the time). For me json is so basic, that we can do everything without any dependencie. And a basic lib should not have any, I think. Thanks! Christian - 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: New Sandbox Component Proposal: Commons JSON
--- On Thu, 4/30/09, Christian Grobmeier grobme...@gmail.com wrote: From: Christian Grobmeier grobme...@gmail.com Subject: Re: New Sandbox Component Proposal: Commons JSON To: Commons Developers List dev@commons.apache.org Date: Thursday, April 30, 2009, 2:25 PM Matt, I don't know about folks you (or I) know face-to-face, but I know that several ASF committers and members have popped up around the ANTLR lists over the years, including, off the top of my head, myself, Torsten, O.Ziegermann, H.L. Ship, and probably others. I personally am quite comfortable with ANTLR 2.x but need to really take the time to play with ANTLR 3. The argument _for_ using parser generators is that those who use them feel the grammar is easier to digest (it's smaller) than the equivalent Java code. It's something else again to debug ANTLR parsers/treeparsers, but it's far from impossible. Once you get used to knowing what to look for it's actually fairly easy. I don't say any of this to disparage Yonik's work on Noggit (I've not looked at it); I am just airing my understanding of the motivations for using grammars and parser generators as opposed to hand-writing parsers. what you (and Torsten, he PMed me) are saying will surely make digg me more into antlr. At the moment I always felt that such a simple format like json doesn't need such a tool like antlr, but maybe I am wrong and should rethink. However, Yoniks parser is very fast - antlr parsers should have same performance and should be memory efficient too. This can be checked, of course, and I will do that (when having some spare time left :-)). Cool--note that ANTLR 3 is designed to be much faster than ANTLR 2 IIRC. -Matt Thanks! Christian -Matt I always scratch my head when I hear there are dependencies! when any application I create or use always has dependencies. I wonder how much redundancies and bug fixes would be removed if, for example, all Apache Java code (or even just the Commons code) went the other way and did depend on each other. You might argue we would end up in 'jar hell' but that might force us to better draw boundaries between components and fix bugs :) In maven age I don't feel bad with dependencies, but one json lib did depend on asm version 1 once, and hibernate upgraded to asm version 2, and that gave me nightmare. I ended up with opening my json package and copied all version 1 files into it with own package name. I recompiled, brought this to my repos and so on. This was hell (cause my customer didn't want to pay the time). For me json is so basic, that we can do everything without any dependencie. And a basic lib should not have any, I think. Thanks! Christian - 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 - 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: [DISCUSS] Sanselan as a Commons library
--- On Wed, 4/22/09, Carsten Ziegeler cziege...@apache.org wrote: From: Carsten Ziegeler cziege...@apache.org Subject: Re: [DISCUSS] Sanselan as a Commons library To: Commons Developers List dev@commons.apache.org Date: Wednesday, April 22, 2009, 4:42 AM Phil Steitz wrote We have a rule of thumb here that in order to graduate a component from the sandbox to commons proper, we need to have 3 committers willing to work on it (which means more than just oversight - more like active involvement). This is not a hard and fast rule, but something we like to adhere to. We already have too many dormant components that should be moving out to the attic one day, so we aren't keen on promoting sandbox components or taking on codebases that we can't generate committer interest in. So lets see what level of interest we can generate here for Sanselan. We welcome all ASF committers at commons and we don't have a tremendously high bar for contributors who stick around long enough and play nice, so if we can get some volunteers to express interest, we can move forward. I think at least all or nearly most of the current Sanselan committers, e.g. Charles, Philipp and myself will be committed to Sanselan. Hi Carsten, I understood Phil's comments to mean that only Charles had been making much in the way of actual code changes to Sanselan from now for X amount of time into the past. Do the other committers have actual knowledge of the codebase, or, failing that, grim determination to see that Sanselan is properly supported? ;) I will try to make some time to peruse Sanselan's structure myself and would encourage other members of the Commons community to do the same, as we then might be in a better position to gauge how easily any Java developer could dive in and lend a hand. -Matt Carsten -- Carsten Ziegeler cziege...@apache.org - 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-VFS SVN commit permission
--- On Wed, 4/15/09, Henri Yandell flame...@gmail.com wrote: From: Henri Yandell flame...@gmail.com Subject: Re: Commons-VFS SVN commit permission To: Commons Developers List dev@commons.apache.org Date: Wednesday, April 15, 2009, 11:15 PM I'm all for Sergey to have sandbox access and a branch in the sandbox to work on the FTP code there. +1 -Matt On Wed, Apr 15, 2009 at 7:31 PM, Ralph Goers ralph.go...@dslextreme.com wrote: I see you still listed as a committer on FTPServer and you have an ICLA on file. I've been actively working trying to get a 2.0 release and would welcome the help. What specifically do you want to do? There a few challenging Jira issues that were found by findbugs and checkstyle still has lots of errors (I don't consider that a blocker for a release though). I know that FTP has several issues open and that really isn't one of the areas I have focused on. I'm not a PMC member so I don't get a vote but I would be in favor of this. Ralph On Apr 15, 2009, at 1:29 PM, Sergey Vladimirov wrote: Hi, I would like to ask for commons-vfs project SVN commit permission. Looking for 2.0 version to be released. At Apache I took part in FTPServer development before, also several patches were submitted to axis2, commons-dpcp, commons-jxpath projects. http://www.linkedin.com/in/vlsergey (nick on JIRA bsp, login on svn.apache.org sergey) -- Sergey Vladimirov - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Configuration] experimental branch uses java.util.logging?
My guess would be that an obvious lack in [logging] is that of message parameterization to avoid isDebug, etc. check blocks when building expensive log messages. -Matt P.S. I'm also interested in what your revolutionary-sounding ideas were, Torsten. --- On Tue, 4/14/09, Torsten Curdt tcu...@apache.org wrote: From: Torsten Curdt tcu...@apache.org Subject: Re: [Configuration] experimental branch uses java.util.logging? To: Commons Developers List dev@commons.apache.org Date: Tuesday, April 14, 2009, 3:48 PM Valid points. The main issue I have with Commons Logging is just that it is too minimal. But that can easily be addressed. But I do have a couple of comments. I always thought people were complaining it does too much ;-) Trying hard not to get dragged into logging discussions anymore - but I am curious: What are you missing? cheers -- Torsten - 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: [Configuration] experimental branch uses java.util.logging?
--- On Fri, 4/10/09, Oliver Heger oliver.he...@oliver-heger.de wrote: From: Oliver Heger oliver.he...@oliver-heger.de Subject: Re: [Configuration] experimental branch uses java.util.logging? To: Commons Developers List dev@commons.apache.org Date: Friday, April 10, 2009, 2:03 PM Ralph Goers schrieb: On Apr 10, 2009, at 11:40 AM, Oliver Heger wrote: Ralph Goers schrieb: I just noticed that this was changed from commons.logging. I'm very strongly opposed to using j.u.l. I much prefer a logging abstraction. While I'm not in love with commons-logging and would prefer SLF4J, using commons-logging is better than using j.u.l directly. As I said, if there is some reason for moving away from commons-logging I'd be happy to do the work to migrate to SLF4J. Ralph This change was made by Emmanuel, IIRC for the reason of getting rid of a dependency. Personally I was not too happy with this change either. IMHO libraries should use logging facades rather than forcing applications to use specific logging tools. So we seem to agree in this point. About the abstraction to use I am a bit indifferent. There is this point of eating our own dog food (i.e. commons-logging). But if you prefer SLF4J (I haven't used it myself), I am not opposed to moving to it. Glad to hear that we are on the same page. If we continue to use commons-logging I would want to add a bunch of enhancements to it that SLF4J already has. I suspect that this would require a new branch of commons logging and I'd probably want the minimum version to be Java 5. Since I'm only one guy and stretched very thin I'm not sure when I could get to that. But I really would like to. There should be a couple of people around here who are interested in commons-logging. So it may make sense to start a new thread to discuss the enhancements you have in mind. Maybe that gives some momentum to this component. Is there any point in turning [logging] into me-too-slf4j? If we can agree that slf4j's API is preferable to that of [logging] in its current form, why don't we EOL [logging] and bless the compatibly-licensed slf4j for future development? No slight to those who have worked on [logging] in the past, but if their interests have moved on while Ceki continues to focus on logging, why not simply leave the domain to him? There is an established path for interop, so this shouldn't keep anybody up at night IMHO. If we were interested in having [logging]'s API differ significantly from that of slf4j it'd be a different story, but this simply sounds like NIH, which is not what I think the ASF is about. -Matt Oliver - 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: RES: RES: RES: Possible incubation?
Perhaps the annotation could be extended in some way to permit mappings of
Throwable types to Handler types. This would (a) allow different handlers to
be used for the same method, and (b) allow the exception to be thrown as normal
when no matching handler was found.
Just thinking,
Matt
--- On Wed, 4/8/09, Andre Dantas Rocha andre.dantas.ro...@uol.com.br wrote:
From: Andre Dantas Rocha andre.dantas.ro...@uol.com.br
Subject: RES: RES: RES: Possible incubation?
To: 'Andre Dantas Rocha' andre.dantas.ro...@uol.com.br, 'Commons
Developers List' dev@commons.apache.org
Date: Wednesday, April 8, 2009, 1:49 PM
I agree with you in some points.
Maybe it is better to return inside
exceptions to the caller instead of catch them locally.
The problem, for me, remains in this part: see if we have
a method to
handle such an exception by checking if a method
handleIllegalArgumentException exists
I believe that implement an
handleIllegalArgumentException() method it's not
the best solution for the problem. Maybe the best strategy
is to overload
handle() method for handling exceptions of handler's
responsibility. For
example, Instead of handleIllegalArgumentException(),
codify a
handle(IllegalArgumentException e):
public class MyHandler implements handler {
public Throwable
handle(IllegalArgumentException e, ...) {
// specific code
}
public Throwable handle(Throwable t, ...)
{
return t;
}
}
But... and if does the user specify an handler that are not
supposed to
handle that code? Isn't better to throw an exception
instead of returning
the original one?
Andre
-Mensagem original-
De: Gaurav Arora [mailto:gauravar...@codercorp.com]
Enviada em: quarta-feira, 8 de abril de 2009 12:37
Para: Commons Developers List
Assunto: Re: RES: RES: Possible incubation?
I agree with you that there is no elegant way to say what
can and cannot
be handled by the handler so what I suggest is let the
handler decide what
it can and cannot handle. Looking at the handler should
give one a clear
picture of what its equipped to handle.
Here's what I mean with an example:
@ExceptionHandler(MyHandler.class)
public void foo() {
try {
doSomething();
} catch (Exception ex) {
handler.handle(ex);
}
}
Assume the above method throws an
IllegalArgumentException.
In our handler:
public Throwable handle(Exception e) {
// get the type of exception
// see if we have a method to handle such an
exception by checking if
a method handleIllegalArgumentException exists
// if we don't simply return the exception
back
}
This way there is no need to explicitly define what
exceptions can and
cannot be handled. What is not handled is simply thrown
back to the
caller. But what it does is provides a very clean caller in
the sense that
it has no actual exception handling code, just a single
catchAll.
I am not sure on what exceptions should be handled by the
handle method
itself. Asking the handler to handle all it's own
exceptions, in a way,
again asks you to duplicate the code, which is what Jeha is
trying to
remove. Otherwise, you'll need to define exception handlers
for the
handlers themselves which in my view can get tricky real
fast.
I don't think that the option of rethrowing should rest
with the caller.
What the caller is saying is that the handler will handle
all it's
exceptions and it itself knows nothing about what is going
on. Asking the
caller to handle rethrows sort of splits the responsibility
between the
two which again, is something that can get tricky.
Gaurav
Hi Gurav,
The weaving could be accomplished statically using
ASM, BCEL, Javassist or
any similar tool. In my opinion, a bytecode library
must be used only
during
compilation process; it's better (and cleaner) if the
program does not
need
it to work.
Personally, I think that attach handlers with specific
exception types
could
be a problem when you have a method that throws
exceptions of different
kinds. I don't think that it could be specified (in a
elegant way) in
annotations. Maybe it preferable to let it more
generic...
I believe that the strategy of rethrowing an exception
or not must be
accomplished by the caller method, and exceptions
inside the handler must
be
tackled there. Maybe a (new) parameter could specify
what to do.
What do you think?
Andre
-Mensagem original-
De: Gaurav Arora [mailto:gauravar...@codercorp.com]
Enviada em: quarta-feira, 8 de abril de 2009 10:37
Para: Commons Developers List
Assunto: Re: RES: Possible incubation?
I just want to take the discussion towards converting
compile time weaving
to load time weaving for a second here. Please feel
free to correct me if
I have gone off the wrong path here.
My idea is to simply have something like this:
1. apply throws advice on every
Re: New sandbox project -- Apache Commons (Portable) Runtime
--- On Mon, 4/6/09, Mladen Turk mt...@apache.org wrote: From: Mladen Turk mt...@apache.org Subject: Re: New sandbox project -- Apache Commons (Portable) Runtime To: Commons Developers List dev@commons.apache.org Date: Monday, April 6, 2009, 8:59 AM Paul Libbrecht wrote: This sounds good to me as an initiative. I am bit worried with the title apr (or is it acr?) since it overlaps a lot with apache httpd's apr (which is widespread in many distributions as one of the bases of httpd). I thought the name should be (Apache Commons Runtime). The short project name is just 'runtime' under commons. Why runtime? Eg. JDK comes with Runtime.exec() However project will allow things like running the process under different user credentials, getting its pid. Getting the uid/gid of the running JVM, cpu utilization, system memory profile, listing process and process modules, etc. Of course process is just one set of objects. Would it make sense for this to be rolled into the [exec] component? -Matt Majority of those things is already in Tomcat Native, but no one knows it's there. Everyone thinks its just one of the Tomcat connectors, while with high level api it can do great things not possible with java (at least not without spawning the shell for creating a symlink for example) Wouldn't ajr be better a term since it's about a java binding? Is tomcat native something really specific to apache httpd? What about aprj or japr then? The point is that like any commons project the Java package name carries the project name, so apache.commons.runtime in this case is the name that would perfectly contain classes like Cpu User, Group, Process, ProcesIterator, Memory, NetworkAdapter, TcpConnetion, Socket, etc. And even some platfrom specific things like windows.Registry and Service management classes, to name a few. Regards -- ^(TM) - 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: New sandbox project -- Apache Commons (Portable) Runtime
I would be +1 to include this in Commons. -Matt --- On Sat, 4/4/09, Mladen Turk mt...@apache.org wrote: From: Mladen Turk mt...@apache.org Subject: New sandbox project -- Apache Commons (Portable) Runtime To: Commons Developers List dev@commons.apache.org Date: Saturday, April 4, 2009, 2:21 AM Hi all This is not official project manifest, just few things so I can gather info weather the project has any chance to settle in the commons at the first place. The project is completely different from other commons projects, because it contains platform native code beside java api. The idea is to evolve the Tomcat Native to a standalone component. It is used by Apache Tomcat and Apache Mina projects, so we have two TLP projects already using it. And my plan is to use this component inside daemons project for common platform tasks. The java part will also have a special native library dynamic runtime, allowing the native module(s) to exist in the same jar and gets extracted at runtime depending on the JVM platform with all internal native dependencies resolved, thus liberating the user from .dll hell. So, thumbs up or down to pursue this, or do I need to find a different settlement :) Regards -- ^(TM) - 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: Release Schedule Request
--- On Fri, 4/3/09, Brad Davis brad.da...@amentra.com wrote: From: Brad Davis brad.da...@amentra.com Subject: Release Schedule Request To: dev@commons.apache.org Cc: agui...@redhat.com Date: Friday, April 3, 2009, 1:21 PM We are currently implementing jBPM 4.0, and would like to use Apache Commons Email within our email components. However, there are several methods we need described in the following JIRA: https://issues.apache.org/jira/browse/EMAIL-85 After creating the JIRA, I realize in retrospect that the code has made it into the repo. However, there is no current snapshot for 1.2 containing these methods. Additionally, we were hoping to get an idea of your release schedule to determine if it will be in line with our own. I can't speak personally to the release schedule, although if you let us know yours the community can take it into account--no promises though. As for the snapshot, you should be able to point to http://repository.apache.org/snapshots/. HTH, Matt Thanks, Brad Davis Amentra, a Red Hat company. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r758009 - /commons/proper/compress/trunk/pom.xml
It looks to me as though Adrian's report/patch actually came after (this) Christian's... no? -Matt --- On Wed, 3/25/09, Christian Grobmeier grobme...@gmail.com wrote: From: Christian Grobmeier grobme...@gmail.com Subject: Re: svn commit: r758009 - /commons/proper/compress/trunk/pom.xml To: dev@commons.apache.org Date: Wednesday, March 25, 2009, 1:17 AM Hi, shouldn't credits of: https://issues.apache.org/jira/browse/COMPRESS-23 go to Adrian Pronk? Cheers, Ch On Tue, Mar 24, 2009 at 9:41 PM, mben...@apache.org wrote: Author: mbenson Date: Tue Mar 24 20:41:45 2009 New Revision: 758009 URL: http://svn.apache.org/viewvc?rev=758009view=rev Log: credit for patch for COMPRESS-23/COMPRESS-33 Modified: commons/proper/compress/trunk/pom.xml Modified: commons/proper/compress/trunk/pom.xml URL: http://svn.apache.org/viewvc/commons/proper/compress/trunk/pom.xml?rev=758009r1=758008r2=758009view=diff == --- commons/proper/compress/trunk/pom.xml (original) +++ commons/proper/compress/trunk/pom.xml Tue Mar 24 20:41:45 2009 @@ -72,6 +72,10 @@ nameWolfgang Glas/name emailwolfgang.glas at ev-i.at/email /contributor + contributor + nameChristian Kohlschütte/name + emailc...@newsclub.de/email + /contributor /contributors scm - 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 Incubator proposal
--- On Mon, 3/23/09, Min Cha minslo...@gmail.com wrote: From: Min Cha minslo...@gmail.com Subject: Re: Commons Incubator proposal To: Commons Developers List dev@commons.apache.org Date: Monday, March 23, 2009, 3:05 AM Hi, Matt. I also think that this is a good proposal for Apache community. Not least because it would be the perfect fit for Robust-Task? ;D -Matt On Mon, Mar 23, 2009 at 2:11 AM, Matt Benson gudnabr...@yahoo.com wrote: Funnily enough I mentioned this the other day, then ran across the original proposal doc on my laptop. Though I was correct in my recollection that there was not a lot of interest, I failed to recall having made a final appeal for any naysayers to speak up, and in that it was apparently I who dropped that particular ball almost a year ago now. :) So maybe in the coming months we/I can pick this up. For background, the proposal is at [1]. If anyone has had any change of opinion on this please feel free to make it known. Thanks, Matt 1. http://wiki.apache.org/commons/CommonsIncubatorProposal - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org -- Min Cha, Dreaming Developer Robust-Task : http://code.google.com/p/robust-coupe/wiki/RobustTaskIntroduction English : http://minslovey.blogspot.com Korean : http://minslovey.tistory.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Robust-Task introduction
--- On Sun, 3/22/09, Min Cha minslo...@gmail.com wrote: From: Min Cha minslo...@gmail.com Subject: Re: Robust-Task introduction To: Commons Developers List dev@commons.apache.org Cc: incubator-general general-subscr...@incubator.apache.org Date: Sunday, March 22, 2009, 12:49 AM Hi, Matt. Thanks for your interest and opinion. As you said, this is food for thought. Honestly I think that Robust-Task is suitable for Commons rather than incubator for going to TLP. As you mentioned, however, I am worrying about I don`t have 'commit authority' when it goes to sandbox. So, I`d like to know how to obtain 'commit authority' when it goes to sandbox. Is it possible? Yes, by sustained engagement and participation in the Commons community you could earn committership. Not sure how this works with sandbox components, however. It would be somewhat a new situation, at least in my experience. -Matt Thanks for your reading. Cheers. On Sun, Mar 22, 2009 at 3:58 AM, Matt Benson gudnabr...@yahoo.com wrote: Speaking as a member of the Commons PMC, though not for the ENTIRE PMC: given the comparisons between robust-task and [chain], maybe this could be a seed for a [chain] rewrite/2.0 . Then you'd still have the question of sandbox grant vs. incubation; the problem with the sandbox grant AIUI is that as a non-ASF-committer Min would be reduced to the status of a community member, no longer able to make commits directly on the code. Further, this would require that some existing Apache committer(s) be willing to take responsibility for the sandbox component and commit (Min's or others') submitted patches. With the incubation route, Min would become a podling committer. While I would think there would be a fair chance that Commons would be willing to sign on as sponsoring PMC, I am unaware of any previous podlings that have graduated to Commons. Commons being a bit of a special case as TLPs go, the exit criteria for a podling into Commons are less than clear. With this in mind myself and Henri Yandell quite some time ago worked up a proposal for a Commons mini-incubator but received little (actually no IIRC) feedback. Food for thought anyway. -Matt --- On Sat, 3/21/09, Niclas Hedhman nic...@hedhman.org wrote: From: Niclas Hedhman nic...@hedhman.org Subject: Re: Robust-Task introduction To: gene...@incubator.apache.org Cc: dev@commons.apache.org Date: Saturday, March 21, 2009, 4:23 AM On Fri, Mar 20, 2009 at 9:04 PM, Min Cha minslo...@gmail.com wrote: I wonder whether I am understanding a message from you. Do you think this project should or can be a component in Commons? Could become... If so, I would like to know how to be a component in Commons. Well, it depends. The Commons community could either go for Incubation, in which case it is about getting a community built up with the codebase. I suspect that the codebase is too small for Incubation, and Commons should do a Software Grant and import the codebase into their existing community. Now, it is up to 'them' how they want to proceed. I am skeptical to incubation to grow community, but no problem to see a them take the library in via a Software Grant. Cheers Niclas -- http://www.qi4j.org - New Energy for Java - 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 -- Min Cha, Dreaming Developer Robust-Task : http://code.google.com/p/robust-coupe/wiki/RobustTaskIntroduction English : http://minslovey.blogspot.com Korean : http://minslovey.tistory.com - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: p.a.o m2 snapshot repo
--- On Sun, 3/22/09, Siegfried Goeschl siegfried.goes...@it20one.at wrote: From: Siegfried Goeschl siegfried.goes...@it20one.at Subject: Re: p.a.o m2 snapshot repo To: Commons Developers List dev@commons.apache.org Date: Sunday, March 22, 2009, 5:15 AM Hi Matt, if you talk about scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository and an M2 commons project that the following statement will help mvn -Pci deploy That is what I was talking about... I only hope none of the mvn magic gets me. ;) Thanks! -Matt Cheers, Siegfried Goeschl Matt Benson wrote: While we think over the Nexus issue, can anyone guide me in publishing snapshots to the existing repo? Thanks, Matt - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Commons Incubator proposal
Funnily enough I mentioned this the other day, then ran across the original proposal doc on my laptop. Though I was correct in my recollection that there was not a lot of interest, I failed to recall having made a final appeal for any naysayers to speak up, and in that it was apparently I who dropped that particular ball almost a year ago now. :) So maybe in the coming months we/I can pick this up. For background, the proposal is at [1]. If anyone has had any change of opinion on this please feel free to make it known. Thanks, Matt 1. http://wiki.apache.org/commons/CommonsIncubatorProposal - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Robust-Task introduction
Speaking as a member of the Commons PMC, though not for the ENTIRE PMC: given the comparisons between robust-task and [chain], maybe this could be a seed for a [chain] rewrite/2.0 . Then you'd still have the question of sandbox grant vs. incubation; the problem with the sandbox grant AIUI is that as a non-ASF-committer Min would be reduced to the status of a community member, no longer able to make commits directly on the code. Further, this would require that some existing Apache committer(s) be willing to take responsibility for the sandbox component and commit (Min's or others') submitted patches. With the incubation route, Min would become a podling committer. While I would think there would be a fair chance that Commons would be willing to sign on as sponsoring PMC, I am unaware of any previous podlings that have graduated to Commons. Commons being a bit of a special case as TLPs go, the exit criteria for a podling into Commons are less than clear. With this in mind myself and Henri Yandell quite some time ago worked up a proposal for a Commons mini-incubator but received little (actually no IIRC) feedback. Food for thought anyway. -Matt --- On Sat, 3/21/09, Niclas Hedhman nic...@hedhman.org wrote: From: Niclas Hedhman nic...@hedhman.org Subject: Re: Robust-Task introduction To: gene...@incubator.apache.org Cc: dev@commons.apache.org Date: Saturday, March 21, 2009, 4:23 AM On Fri, Mar 20, 2009 at 9:04 PM, Min Cha minslo...@gmail.com wrote: I wonder whether I am understanding a message from you. Do you think this project should or can be a component in Commons? Could become... If so, I would like to know how to be a component in Commons. Well, it depends. The Commons community could either go for Incubation, in which case it is about getting a community built up with the codebase. I suspect that the codebase is too small for Incubation, and Commons should do a Software Grant and import the codebase into their existing community. Now, it is up to 'them' how they want to proceed. I am skeptical to incubation to grow community, but no problem to see a them take the library in via a Software Grant. Cheers Niclas -- http://www.qi4j.org - New Energy for Java - 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
Switching to repository.a.o/Nexus
http://issues.apache.org/jira/browse/INFRA-1885 details some of the reasons for adopting this. It sounds like it should simplify the RC/release process somewhat. WDYT? -Matt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
p.a.o m2 snapshot repo
While we think over the Nexus issue, can anyone guide me in publishing snapshots to the existing repo? Thanks, Matt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [LANG] 3.0 JCIP Annotations
--- On Thu, 3/19/09, James Carman ja...@carmanconsulting.com wrote: From: James Carman ja...@carmanconsulting.com Subject: Re: [LANG] 3.0 JCIP Annotations To: Commons Developers List dev@commons.apache.org Date: Thursday, March 19, 2009, 1:14 AM On Wed, Mar 18, 2009 at 10:21 PM, Stephen Colebourne scolebou...@btopenworld.com wrote: Thats OK technically (as there is no runtime dependency on net.jcip.annotations). However, I suspect it will confuse users, as very few people realise that no dependency is created beyond compilation time. I agree. Most folks don't know that there annotation classes aren't really required at runtime. If we're just looking for documentation, can't we have our own doclet? *I* didn't know that the classes weren't required at RT... but I still don't know that we should consider that a blocker. Seems like a couple of well-placed warnings in documentation would take care of that pretty well. What does the annotation look like in the Javadoc? Because if the POM has it marked as optional (we can even include a comment there explaining further) then the Javadoc would be the only place left for a user to get the wrong idea. Adding our own annotation seems like NIH... -Matt - 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: [LANG] 3.0 JCIP Annotations
Googling led me to the httpclient thread you started. If there is no runtime dependency I am fine with it. :) -Matt --- On Wed, 3/18/09, sebb seb...@gmail.com wrote: From: sebb seb...@gmail.com Subject: [LANG] 3.0 JCIP Annotations To: Commons Developers List dev@commons.apache.org Date: Wednesday, March 18, 2009, 10:51 AM I've added JCIP annotations jar to the POM, but not started adding any actual annotations yet. The idea would be to annotate every class as one of @Immutable @ThreadSafe @NotThreadSafe These annotation appear in the Javadoc output in the class description. Also, for objects that need synchronization to ensure thread safety, add the annotation @GuardedBy Are there any objections to proceeding with this? It's probably easiest to deal with @Immutable first, then @ThreadSafe. If no annotation is present, then the user _should_ assume that the class is @NotThreadSafe, but I think it would be better to always have an annotation so that it's clear it has not been accidentally left off. WDYT? - 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: [LANG] 3.0 StrTokenizer API change for next()
--- On Sun, 3/15/09, sebb seb...@gmail.com wrote: From: sebb seb...@gmail.com Subject: [LANG] 3.0 StrTokenizer API change for next() To: Commons Developers List dev@commons.apache.org Date: Sunday, March 15, 2009, 11:31 AM StrTokenizer implements ListIterator currently. Given that it only deals in Strings, it could implement ListIteratorString, however that would mean changing public Object next() to public String next() Any objections to implementing the above? 1. A String _is_ an Object; I am convinced that narrowed return types are the right thing to do in Java5-compatible code. What reason could there be against it? 2. We have no obligation to be BC anyway. -Matt - 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: svn commit: r754584 - in /commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder: ToStringBuilder.java ToStringStyle.java
I suppose it depends whether we want the reflect stuff ported from [beanutils].
Personally I'd say yes, but since the same code exists, more-or-less, in
another component it's not _critical_.
-Matt
--- On Sun, 3/15/09, Henri Yandell flame...@gmail.com wrote:
From: Henri Yandell flame...@gmail.com
Subject: Re: svn commit: r754584 - in
/commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder:
ToStringBuilder.java ToStringStyle.java
To: Commons Developers List dev@commons.apache.org
Date: Sunday, March 15, 2009, 1:29 PM
Matt - if we did keep a 2.x branch,
would the POST-2.4 branch be of
value, or should we be branching from the 2.4 tag?
Hen
On Sun, Mar 15, 2009 at 11:20 AM, Henri Yandell flame...@gmail.com
wrote:
We can branch 2.4 if needed.
The biggest choice is whether we attempt to fix bugs
in both, while
reserving changes and new features for the 3.0
branch.
Ideally wed have the 2.4 one going, but that would be
quite a cultural
development change from the usual 1 trunk way we do
things. I'm
expecting us not to do anything unless we have a
serious enough bug
that requires change.
For example LANG-331... no real solution and I'm
expecting that this
needs to be resolved as a known-issue.
Hen
On Sun, Mar 15, 2009 at 4:52 AM, sebb seb...@gmail.com
wrote:
I assumed it was where the next 2.x release would
come from.
Or will there be no further releases supporting
versions of Java prior to 1.5?
On 15/03/2009, Matt Benson gudnabr...@yahoo.com
wrote:
Are we still using this branch? I created
it for work on the reflect subpackage but later merged back
to trunk... :|
-Matt
--- On Sat, 3/14/09, s...@apache.org
s...@apache.org
wrote:
From: s...@apache.org
s...@apache.org
Subject: svn commit: r754584 - in
/commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder:
ToStringBuilder.java ToStringStyle.java
To: comm...@commons.apache.org
Date: Saturday, March 14, 2009, 8:43
PM
Author: sebb
Date: Sun Mar 15 01:43:20 2009
New Revision: 754584
URL: http://svn.apache.org/viewvc?rev=754584view=rev
Log:
Replace deprecated method calls to
appendIdentityToString
with identityToString
Modified:
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringBuilder.java
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringStyle.java
Modified:
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringBuilder.java
URL:
http://svn.apache.org/viewvc/commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringBuilder.java?rev=754584r1=754583r2=754584view=diff
==
---
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringBuilder.java
(original)
+++
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringBuilder.java
Sun Mar 15 01:43:20 2009
@@ -945,7 +945,7 @@
* @since 2.0
*/
public ToStringBuilder
appendAsObjectToString(Object object)
{
-
ObjectUtils.appendIdentityToString(this.getStringBuffer(),
object);
+
ObjectUtils.identityToString(this.getStringBuffer(),
object);
return this;
}
Modified:
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringStyle.java
URL:
http://svn.apache.org/viewvc/commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringStyle.java?rev=754584r1=754583r2=754584view=diff
==
---
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringStyle.java
(original)
+++
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringStyle.java
Sun Mar 15 01:43:20 2009
@@ -562,7 +562,7 @@
* @since 2.2
*/
protected void
appendCyclicObject(StringBuffer buffer,
String fieldName,
Object value) {
-
ObjectUtils.appendIdentityToString(buffer,
value);
+
ObjectUtils.identityToString(buffer,
value);
}
/**
-
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: [lang] 3.0, what's in; what's out
I'd like to add a TypeUtils to the reflect subpackage, to provide as much help as possible for discovering type parameters of generic types. I recently commented in ClassUtils that a 3.0, Java5-compatible assignable test should assume autoboxing == true (since one would think the assignable test would normally be used in preparation for e.g. a reflection-based method call autoboxing should have been a safe assumption to begin with, but anyway...). -Matt --- On Sat, 3/14/09, Henri Yandell flame...@gmail.com wrote: From: Henri Yandell flame...@gmail.com Subject: [lang] 3.0, what's in; what's out To: Commons Developers List dev@commons.apache.org Date: Saturday, March 14, 2009, 4:21 AM Starting up a thread for cleanup discussions on Lang. I've removed the enum (was a blocker on JDK 5) and enums (people need to use real enums now) packages from Lang's trunk and moved them to a lang-backcompat sibling component. I've not made it a branch, it lives at the same level as trunk and will need its future to be decided. An EnumUtils class has been added to the main lang package. I also think the exception package should go. Again - the JDK has support for this now and there's no strong value in Lang having an alternative to stop people thinking about JDK 1.5. The ExceptionUtils class should move up to the main lang package and needs to have the Nestable Lang code removed from it. Presumably it still has value. Some of the Date code is tempting to delete. Either due to buginess, or general 'this isn't that cool' ness. JVMRandom should go. I'm not convinced it's had much use. IDKey should move to package scoping - I've not seen an argument made yet for it being public. Fraction is up for debate. Do we cede this to Commons Math. Sure it might add another jar to some people's code, but probably good for them to be more aware of Math. WordUtils and StringEscapeUtils both strike me as 'desirable but flawed'. We should consider overhauls. The Security requiring stuff in builder for reflection needs to go away imo. Makes it less than useful. We need a PackageUtils in reflect. We need to consider if there are any annotations that are valuable to be pseudo-standard. I'm still partial to a RegexUtils. Plus general generifying, varargs, autoboxing. Deletion of all deprecated methods/classes. And the various other backwards incompatible changes that people have been requesting. Hen - 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: [lang] 3.0, what's in; what's out
--- On Sat, 3/14/09, Gary Gregory ggreg...@seagullsoftware.com wrote: From: Gary Gregory ggreg...@seagullsoftware.com Subject: RE: [lang] 3.0, what's in; what's out To: Commons Developers List dev@commons.apache.org Date: Saturday, March 14, 2009, 2:19 PM -Original Message- From: Matt Benson [mailto:gudnabr...@yahoo.com] Sent: Saturday, March 14, 2009 11:57 AM To: Commons Developers List Subject: Re: [lang] 3.0, what's in; what's out I'd like to add a TypeUtils to the reflect subpackage, to provide as much help as possible for discovering type parameters of generic types. I I thought that type erasure made this impossible? Can you define what the class would do please? Based on the research I have done thus far, type erasure makes it impossible to determine the parameters of a given object, but you can still learn certain things about type parameters of methods, fields, and superclasses that may be helpful. The idea is under development, but it's based on James's code from [proxy]'s 2.0 branch. Thanks for your concern though! ;) -Matt Thanks, Gary recently commented in ClassUtils that a 3.0, Java5-compatible assignable test should assume autoboxing == true (since one would think the assignable test would normally be used in preparation for e.g. a reflection-based method call autoboxing should have been a safe assumption to begin with, but anyway...). -Matt --- On Sat, 3/14/09, Henri Yandell flame...@gmail.com wrote: From: Henri Yandell flame...@gmail.com Subject: [lang] 3.0, what's in; what's out To: Commons Developers List dev@commons.apache.org Date: Saturday, March 14, 2009, 4:21 AM Starting up a thread for cleanup discussions on Lang. I've removed the enum (was a blocker on JDK 5) and enums (people need to use real enums now) packages from Lang's trunk and moved them to a lang-backcompat sibling component. I've not made it a branch, it lives at the same level as trunk and will need its future to be decided. An EnumUtils class has been added to the main lang package. I also think the exception package should go. Again - the JDK has support for this now and there's no strong value in Lang having an alternative to stop people thinking about JDK 1.5. The ExceptionUtils class should move up to the main lang package and needs to have the Nestable Lang code removed from it. Presumably it still has value. Some of the Date code is tempting to delete. Either due to buginess, or general 'this isn't that cool' ness. JVMRandom should go. I'm not convinced it's had much use. IDKey should move to package scoping - I've not seen an argument made yet for it being public. Fraction is up for debate. Do we cede this to Commons Math. Sure it might add another jar to some people's code, but probably good for them to be more aware of Math. WordUtils and StringEscapeUtils both strike me as 'desirable but flawed'. We should consider overhauls. The Security requiring stuff in builder for reflection needs to go away imo. Makes it less than useful. We need a PackageUtils in reflect. We need to consider if there are any annotations that are valuable to be pseudo-standard. I'm still partial to a RegexUtils. Plus general generifying, varargs, autoboxing. Deletion of all deprecated methods/classes. And the various other backwards incompatible changes that people have been requesting. Hen - 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 - 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: [lang] 3.0, what's in; what's out
--- On Sat, 3/14/09, Gary Gregory ggreg...@seagullsoftware.com wrote: From: Gary Gregory ggreg...@seagullsoftware.com Subject: RE: [lang] 3.0, what's in; what's out To: Commons Developers List dev@commons.apache.org Date: Saturday, March 14, 2009, 2:39 PM -Original Message- From: Matt Benson [mailto:gudnabr...@yahoo.com] Sent: Saturday, March 14, 2009 12:36 PM To: Commons Developers List Subject: RE: [lang] 3.0, what's in; what's out --- On Sat, 3/14/09, Gary Gregory ggreg...@seagullsoftware.com wrote: From: Gary Gregory ggreg...@seagullsoftware.com Subject: RE: [lang] 3.0, what's in; what's out To: Commons Developers List dev@commons.apache.org Date: Saturday, March 14, 2009, 2:19 PM -Original Message- From: Matt Benson [mailto:gudnabr...@yahoo.com] Sent: Saturday, March 14, 2009 11:57 AM To: Commons Developers List Subject: Re: [lang] 3.0, what's in; what's out I'd like to add a TypeUtils to the reflect subpackage, to provide as much help as possible for discovering type parameters of generic types. I I thought that type erasure made this impossible? Can you define what the class would do please? Based on the research I have done thus far, type erasure makes it impossible to determine the parameters of a given object, but you can still learn certain things about type parameters of methods, fields, and superclasses that may be helpful. The idea is under development, but it's based on James's code from [proxy]'s 2.0 branch. Thanks for your concern though! ;) Thanks for the clarification. BTW, I've you have not read it yet, this is a great resource: http://www.angelikalanger.com/GenericsFAQ/FAQSections/ProgrammingIdioms.html I keep this tutorial open a lot of the time! ;) I even dropped her a note thanking her for it. -Matt Gary -Matt Thanks, Gary recently commented in ClassUtils that a 3.0, Java5-compatible assignable test should assume autoboxing == true (since one would think the assignable test would normally be used in preparation for e.g. a reflection-based method call autoboxing should have been a safe assumption to begin with, but anyway...). -Matt --- On Sat, 3/14/09, Henri Yandell flame...@gmail.com wrote: From: Henri Yandell flame...@gmail.com Subject: [lang] 3.0, what's in; what's out To: Commons Developers List dev@commons.apache.org Date: Saturday, March 14, 2009, 4:21 AM Starting up a thread for cleanup discussions on Lang. I've removed the enum (was a blocker on JDK 5) and enums (people need to use real enums now) packages from Lang's trunk and moved them to a lang-backcompat sibling component. I've not made it a branch, it lives at the same level as trunk and will need its future to be decided. An EnumUtils class has been added to the main lang package. I also think the exception package should go. Again - the JDK has support for this now and there's no strong value in Lang having an alternative to stop people thinking about JDK 1.5. The ExceptionUtils class should move up to the main lang package and needs to have the Nestable Lang code removed from it. Presumably it still has value. Some of the Date code is tempting to delete. Either due to buginess, or general 'this isn't that cool' ness. JVMRandom should go. I'm not convinced it's had much use. IDKey should move to package scoping - I've not seen an argument made yet for it being public. Fraction is up for debate. Do we cede this to Commons Math. Sure it might add another jar to some people's code, but probably good for them to be more aware of Math. WordUtils and StringEscapeUtils both strike me as 'desirable but flawed'. We should consider overhauls. The Security requiring stuff in builder for reflection needs to go away imo. Makes it less than useful. We need a PackageUtils in reflect. We need to consider if there are any annotations that are valuable to be pseudo-standard. I'm still partial to a RegexUtils. Plus general generifying, varargs, autoboxing. Deletion of all deprecated methods/classes. And the various other backwards incompatible changes that people have been requesting. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: svn commit: r754584 - in /commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder: ToStringBuilder.java ToStringStyle.java
Are we still using this branch? I created it for work on the reflect
subpackage but later merged back to trunk... :|
-Matt
--- On Sat, 3/14/09, s...@apache.org s...@apache.org wrote:
From: s...@apache.org s...@apache.org
Subject: svn commit: r754584 - in
/commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder:
ToStringBuilder.java ToStringStyle.java
To: comm...@commons.apache.org
Date: Saturday, March 14, 2009, 8:43 PM
Author: sebb
Date: Sun Mar 15 01:43:20 2009
New Revision: 754584
URL: http://svn.apache.org/viewvc?rev=754584view=rev
Log:
Replace deprecated method calls to appendIdentityToString
with identityToString
Modified:
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringBuilder.java
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringStyle.java
Modified:
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringBuilder.java
URL:
http://svn.apache.org/viewvc/commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringBuilder.java?rev=754584r1=754583r2=754584view=diff
==
---
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringBuilder.java
(original)
+++
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringBuilder.java
Sun Mar 15 01:43:20 2009
@@ -945,7 +945,7 @@
* @since 2.0
*/
public ToStringBuilder
appendAsObjectToString(Object object) {
-
ObjectUtils.appendIdentityToString(this.getStringBuffer(),
object);
+
ObjectUtils.identityToString(this.getStringBuffer(),
object);
return this;
}
Modified:
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringStyle.java
URL:
http://svn.apache.org/viewvc/commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringStyle.java?rev=754584r1=754583r2=754584view=diff
==
---
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringStyle.java
(original)
+++
commons/proper/lang/branches/LANG_POST_2_4/src/java/org/apache/commons/lang/builder/ToStringStyle.java
Sun Mar 15 01:43:20 2009
@@ -562,7 +562,7 @@
* @since 2.2
*/
protected void
appendCyclicObject(StringBuffer buffer, String fieldName,
Object value) {
-
ObjectUtils.appendIdentityToString(buffer,
value);
+
ObjectUtils.identityToString(buffer,
value);
}
/**
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Promote Compress to Commons Proper
--- On Fri, 3/13/09, Niall Pemberton niall.pember...@gmail.com wrote: From: Niall Pemberton niall.pember...@gmail.com Subject: Re: [VOTE] Promote Compress to Commons Proper To: Commons Developers List dev@commons.apache.org Date: Friday, March 13, 2009, 6:40 AM +1 from me. On Fri, Mar 13, 2009 at 4:02 AM, Henri Yandell flame...@gmail.com wrote: +0 (meaning I'm in favour, but as I don't plan to be involved in the short term then I won't vote +1; this being one of the few votes where I think a +1 = Yes and I'm going to volunteer time). If only pmc members planning to contribute vote +1 to promotions then we should probably shut down the sandbox because virtually nothing has the chance to graduate to proper. Voting +1 has nothing to do with contributing - same as releases. Agreeing with Niall here. FWIW, Stefan has been around Ant since long before I was involved with it (hell, since before I was a user!) and STILL has more steam left than any of the rest of us over there. Now that he's straddling Commons and Ant wrt [compress] I wouldn't expect him to be going anywhere. I don't know that I have any cycles or expertise for this component, but I am certainly interested in its success. +1 from me. -Matt Niall On Thu, Mar 12, 2009 at 8:58 PM, Stefan Bodewig bode...@apache.org wrote: Hi all, since I'm unsure whether a PROPOSAL is needed for existing sandbox components as old as compress I tried to be save and created one based on the old Jakarta template: http://svn.apache.org/viewvc/commons/sandbox/compress/trunk/PROPOSAL.txt?view=markuppathrev=753102 RAT only flags a few test input files as files with missing licenses. The vote will run for a week. Stefan -- ballot -- The compress component shall become a proper Commons component: [ ] +1 Yes [ ] -1 No - 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: [lang] Developer interested in common-lang project
Hi, Michael. [lang] has been officially marked as targeting 1.5 in its m2 pom, so I suppose you should feel free to let the patches fly. Regards, Matt --- On Fri, 3/13/09, Michael Wooten mwooten@gmail.com wrote: From: Michael Wooten mwooten@gmail.com Subject: [lang] Developer interested in common-lang project To: dev@commons.apache.org Date: Friday, March 13, 2009, 2:22 PM Hi. I am very interested in contributing to the commons-lang project, but would like to know the state of it. I've seen several posts in JIRA and in the developer mailing list about LangTwo and moving to Java 5.0 for version 3.0. The projects I work on for my company have either moved to Java 6.0, or in the case of one of them, are migrating to Java 5.0. In any case, one of the reasons we do not utilize commons-lang is its lack of Generics. I believe the project is highly useful and would be greatly improved with Java 5.0 Generics, varargs, and annotations, but the developer site still mentions targeting 1.2. Has anything been ratified about the use of Java 5.0? I don't see many commits to svn. Is commons-lang still being maintained or improved? I've read mention of a LangTwo branch in the repository, but I couldn't find it. Does this branch still exist? I would love to help contribute to bring the project up to Java 5.0 if this is indeed the path. Any information at all would be greatly appreciated. Thanks. -Michael - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[collections] jdk5 branch
I think this guy is getting ready to be merged back to trunk after I make sure any trunk changes are merged over. It'd be great if anybody wanted to have a look at it in case I'm on crack. -Matt - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [collections] jdk5 branch
I'm trying a (local) reintegrate merge first. In theory that should preserve trunk's changes... -Matt --- On Fri, 3/13/09, James Carman ja...@carmanconsulting.com wrote: From: James Carman ja...@carmanconsulting.com Subject: Re: [collections] jdk5 branch To: Commons Developers List dev@commons.apache.org Date: Friday, March 13, 2009, 3:57 PM As long as you've got any changes from trunk that you need in your branch, I'd say just copy the stuff around (copy trunk to a branch and copy your branch over to trunk). On Fri, Mar 13, 2009 at 4:53 PM, Matt Benson gudnabr...@yahoo.com wrote: Honestly, I don't rightly know. I suppose I could try a merge locally and see how painful it is. Otherwise I suppose the alternative is to make sure all trunk-to-branch catch-up merges are done atomically and extremely informatively, then replace? -Matt --- On Fri, 3/13/09, James Carman ja...@carmanconsulting.com wrote: From: James Carman ja...@carmanconsulting.com Subject: Re: [collections] jdk5 branch To: Commons Developers List dev@commons.apache.org Date: Friday, March 13, 2009, 3:45 PM Are you going to merge or just replace? On Fri, Mar 13, 2009 at 4:41 PM, Matt Benson gudnabr...@yahoo.com wrote: I think this guy is getting ready to be merged back to trunk after I make sure any trunk changes are merged over. It'd be great if anybody wanted to have a look at it in case I'm on crack. -Matt - 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[openmodels] planning WAS Re: gauging sandbox interest - openmodels
I have some code to start with (never been anywhere but my box so no IP problems) but I am currently using Ant + Ivy. This will be an empty project with n subprojects so I feel I will need a ridiculous amount of handholding to get this set up properly with m2. Do any of our Maven mavens have the cycles for this? Thanks, Matt --- On Sun, 3/1/09, Henri Yandell flame...@gmail.com wrote: From: Henri Yandell flame...@gmail.com Subject: Re: gauging sandbox interest - openmodels To: Commons Developers List dev@commons.apache.org Date: Sunday, March 1, 2009, 1:20 PM No reason not to give it a try and if it's too large it can move out of Commons. http://issues.apache.org/jira/browse/LANG-449 might be of interest to it. Hen On Sun, Mar 1, 2009 at 9:15 AM, Matt Benson gudnabr...@yahoo.com wrote: For awhile I've had an itch that it would be nice to have a project whose purpose is to provide small, realistic domain models for consumption primarily by tests of library-type code (if the domain models are actually usable/extensible for real work, so much the better). It seems to me that particularly at Commons it could be beneficial for tests/examples of various components to reference common object models, giving potential users a better point of reference to see how various components might be used with their own models. Is there any interest in having such a project in Commons; do we feel this would be too large and not precisely the mission of Commons; are there other opinions? Thanks, Matt - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: gauging sandbox interest - openmodels
Hen, --- On Sun, 3/1/09, Henri Yandell flame...@gmail.com wrote: From: Henri Yandell flame...@gmail.com Subject: Re: gauging sandbox interest - openmodels To: Commons Developers List dev@commons.apache.org Date: Sunday, March 1, 2009, 1:20 PM No reason not to give it a try and if it's too large it can move out of Commons. Thanks for the positive opinion... :) http://issues.apache.org/jira/browse/LANG-449 might be of interest to it. How so, precisely? -Matt Hen On Sun, Mar 1, 2009 at 9:15 AM, Matt Benson gudnabr...@yahoo.com wrote: For awhile I've had an itch that it would be nice to have a project whose purpose is to provide small, realistic domain models for consumption primarily by tests of library-type code (if the domain models are actually usable/extensible for real work, so much the better). It seems to me that particularly at Commons it could be beneficial for tests/examples of various components to reference common object models, giving potential users a better point of reference to see how various components might be used with their own models. Is there any interest in having such a project in Commons; do we feel this would be too large and not precisely the mission of Commons; are there other opinions? Thanks, Matt - 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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Commons Command proposal
--- Karl Wettin ka...@apache.org wrote: We are ready to pop it in the sandbox. I'll act as moderator for Erics patches. I can't find anything about limitations on sandbox projects, are there any? Compare with Apache Labs that does not allow releases. I'm cc:ing Apache Legal. Regarding paper work, we can get a software grant faxed over in no time. We are the original authors of all this code. Do we both need to send a grant? The original idea for this library came up working for TomTom. They have given us their permission to rewrite the project from scratch, and this we did. Is it nessecary for TomTom to send a grant too releasing some sort of IP? I really don't think there is an IP issue here at all, but I am not a laywer. If it is rewritten from scratch independently of any actual TomTom code, my understanding is that the ASF doesn't need anything from TomTom. Further, if you, as a committer, were the only author you could probably just drop it into the sandbox. But since Eric is your co-author (and as I understand it, not a committer), a grant would be needed from him. That being the case it might be more representative of the provenance of the code for the grant to include both of you as its original creators/copyright owners. Others may disagree, but that's my take. HTH, Matt karl 27 jan 2009 kl. 19.30 skrev Rahul Akolkar: I moderated this through, so folks will need be to CC'ed when necessary (such as I've done here). Three comments: 1) Unless there is anything of private nature here, we discuss proposals on the publicly archived dev list. So, if and when you feel like it, it'd be good to move this to the dev list. 2) If there is interest, new libraries can use the Commons Sandbox for development. However, it is only open to existing ASF committers. 3) If there is existing code, necessary policy procedures (for example, running a software grant through the Apache Incubator) will need to be executed. -Rahul On Tue, Jan 27, 2009 at 12:38 PM, Karl Wettin ka...@apache.org wrote: PMCs, cqueue is an Open Source, Apache-Licensed Java library for scheduling commands against one or more thread pools. http://en.wikipedia.org/wiki/Command_pattern http://en.wikipedia.org/wiki/Command_queue Eric Bowman and I created a similar library while working for TomTom. We are gratefull they let us develop this idea further and it would be our pleasure to see this library as a part of the ASF commons family. cqueue is java.util.concurrent.ExecutorService on steroids: it's an easy way to build a thread pool or pools that take commands from persistent storage, and very carefully control the lifetime of those commands. We built cqueue to help manipulate some pretty big pools of data, where we needed to be able to stop and restart a data processing pipeline without losing any data. We also needed to take full advantage of all available CPU cores. cqueue-bdb is a persistency facade that use BerkeleyDB for storage. It is a fully functional library ready for a release candidate, but as all projects it needs a bit of improvement. This code has never been in the wild so I believe it does not need release papers in order to be committed. karl - 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 download pages are out of date
--- sebb [EMAIL PROTECTED] wrote: On 21/11/2008, Niall Pemberton [EMAIL PROTECTED] wrote: On Fri, Nov 21, 2008 at 5:11 PM, sebb [EMAIL PROTECTED] wrote: Several of the Commons download pages are out of date, e.g. BeanUtils still has 1.8.0-BETA and 1.7.0 on the page http://commons.apache.org/downloads/download_beanutils.cgi but the current release is 1.8.0 V. strange - it was showing 1.8.0 but seems to have been reverted. It was previously updated by mbenson on Nov 20 18:35 FYI--the cgi scripts were all missing the x perm and as a result NO download pages were coming up yesterday. I wasn't able to change the perms for some reason, so I had to copy and recreate the entire downloads/ directory. Note that all the files out there are straight copies of the files that existed before I got my grubby little paws on them==the only thing I did was change the perms to 775. The original files are available at ~mbenson/commons-dlold.tar.gz and beanutils appears to show 1.8.0-BETA and 1.7.0 in those. I don't remember who owned the files when I found them, but I want to say they said they had been modified in June... surely the download pages weren't broken for that long; I don't know what could have happened to them. -Matt I've uploaded a new version - should see it after the next sync. Niall I've updated the source file: /commons/proper/commons-build/trunk/downloads/downloads.xml URL: http://svn.apache.org/viewvc?rev=719638view=rev Log: Remove Latka; add Net 1.4.1 But I'm not sure how to generate the updated html pages and deploy them. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: [Urgent] Please help promote ApacheCon video streaming!
--- Lars Eilebrecht [EMAIL PROTECTED] wrote: Date: Tue, 4 Nov 2008 10:27:25 -0600 From: Lars Eilebrecht [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Urgent] Please help promote ApacheCon video streaming! Hi, please help promote the ApacheCon live video streaming by forwarding the email below to your PMC user and dev mailing lists, ASAP! Thank you Lars Eilebrecht - Subject: ApacheCon live video streaming available; keynotes and Apache 101 are free Can't make ApacheCon this week in New Orleans? You can still watch all the keynotes, Apache 101 sessions, and system administration track in live video streams: http://streaming.linux-magazin.de/en/program_apacheconus08.htm?ann Keynotes and the Apache 101 lunchtime sessions are free; the full sysadmin track, including httpd performance, security, and server stack administration talks are available for a fee. Keynotes include: - David Recordon, Six Apart (Wednesday 09:30) Learning from Apache to create Open Specifications - Shahani Markus Weerawarana, Ph.D. (Thursday 11:30) Standing on the Shoulders of Giants - Sam Ramji, Microsoft (Friday 11:30) struct.new(future, :open, :microsoft) Reminder: New Orleans is CST or UTC/GMT -6 hours. Advance notice: ApacheCon EU 2009 returns to Amsterdam, 23-27 March. We had a great response to our CFP and look forward to announcing the schedule in the next month. --- -- Lars Eilebrecht - V.P., Conference Planning [EMAIL PROTECTED] - http://www.us.apachecon.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[flatfile] using [proxy] WAS Re: [all] Interesting feedback regarding Commons projects...
Actually, James, talking about Commons interdependencies and underuse of [proxy], I'd been meaning to ask you to have a look at [flatfile], specifically http://svn.apache.org/viewvc/commons/sandbox/flatfile/trunk/src/main/java/org/apache/commons/flatfile/ImmutableEntity.java and see if you could offer a recommendation on whether [proxy] looked like a good fit there (last time I looked at [proxy] I didn't quickly grasp just how to go about using it). Thanks, Matt --- James Carman [EMAIL PROTECTED] wrote: All, I recently proposed to the Google Guice project that they might benefit from Commons Proxy. Brian Pontarelli had some interesting things to say, in general, about Commons projects: http://groups.google.com/group/google-guice/browse_thread/thread/ac60750fa62b78e8 I thought some of you might be interested. I don't know well he represents the general public, but I do know that we've taken quite a bit of heat for not converting to JDK5 syntax on our projects. James - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [lang] Java 5
Resurrecting this thread from 3.5 months ago as my itch is returning: --- Niall Pemberton [EMAIL PROTECTED] wrote: On Fri, Jun 20, 2008 at 4:42 PM, Henri Yandell [EMAIL PROTECTED] wrote: On Thu, Jun 12, 2008 at 5:05 AM, sebb [EMAIL PROTECTED] wrote: On 12/06/2008, James Carman [EMAIL PROTECTED] wrote: On Thu, Jun 12, 2008 at 7:28 AM, Niall Pemberton [EMAIL PROTECTED] wrote: Do you mean that the removal of the enums would mean that we have to change package names? Would class/interface removals necessitate a package name change? I haven't really thought that through. Perhaps not, neither had I Removal of a *public* interface/method/class means that the API is not compatible, as it is not possible to replace the jar without breaking classes that use these items. I think we need to make a final decision on this. There seems little argument against moving to 1.5 in theory. And no one is concerned with using 1.5 features in new development. The one open question is: Should we rename the package? * If we goto 1.5, we have to remove the enum package. It's been deprecated for a good while and a source code fix is very easy. Any client that is 1.5 based has had to remove it already. * We have a handful of other deprecated methods that we've said will be removed in 3.0. We've removed methods in the past (I'm pretty sure we did that for 2.0). I'm 50/50 right now. On the one hand, yes I think we should remove things and it's not a major version problem. If people are having pain it would be very easy to build a separate jar with the deprecated methods. However if we are going to start writing new generics code etc, it is going to be impossible to manage to keep that separate from the existing code. How will people know what to code where? In which case I think we should just dive right into LangTwo now. svn cp the trunk to a branch for maintenance, and release of the current bugfixes if we ever need to, and start a new LangTwo on the current trunk. *If* lang2 breaks compatibility, then IMO we should use a new package name, but moving to JDK 1.5 minimum doesn't necessarily dictate that (assuming that we release a compatibility jar for the enum package which has to be removed). IMO it would be better to go through putting in the JDK 1.5 features that don't break compatibility and building up a list of possible changes that do. Then we make the decision on whether compatibility-breaking features seem worth it. If it is, then lets go all the way, remove deprecations, change the package name and put them in. If not, then lets leave the package name and deprecations. We've had a similar discussion over Commons IO and IMO so far nothing has come up that seems worth the whole sale package name change - so I think making the decision first, without any JDK 1.5+ features on the table for consideration is a mistake. Let's see, adding generics shouldn't break compatibility; would varargs? Beyond that anything _added_ doesn't break compatibility because we're talking about existing code with drop-in jar replacement, right? Have I correctly outlined the differences between breaking and non-breaking changes in this context? If so, I'd like to go ahead and start with the plan. More likely I've missed something; let's flush it out. -Matt Niall Gump btw is going to go mad :) It'll think we're breaking compatibility. Hen - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sandbox index.html
What's the right way to regen the site (so I can get [flatfile] properly linked in at sandbox/index.html)? Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: sandbox index.html
--- Niall Pemberton [EMAIL PROTECTED] wrote: On Thu, Sep 25, 2008 at 6:59 PM, Matt Benson [EMAIL PROTECTED] wrote: What's the right way to regen the site (so I can get [flatfile] properly linked in at sandbox/index.html)? I added flatfile[1] and have re-generated/uploaded the site - so should be there after the next sync (~4hrs). We still use maven 1.0 to generate the commons site (and it didn't work for me using JDK 1.6 - I had to revert to 1.5) - at some point we need to move this to m2. Thanks for the assistance, Niall! -Matt Niall Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] Generics and Return Type?
James later wrote some code to do this, which is in a
branch of Commons Proxy. I think we should add
something similar to the reflect subpackage (in trunk)
of the [lang] component, given the fact that BeanUtils
is in maintenance mode.
-Matt
--- Simone Gianni [EMAIL PROTECTED] wrote:
Hi all,
sorry for reopening such an old thread, but it's the
latest I've found
searching for generics.
As James say, it is quite a pain to determine types
in a generic class.
I think commons could be a good place for a library
that makes this
operation easier, maybe in beanutils since its
mission is to provide
easy-to-use wrappers around [these capabilities |
Reflection and
Introspection], and I'm writing such a library
(actually classes
wrapping Class, Method etc..) in my Apache Lab.
More in depth explanation follows.
While it is not possible for purely runtime types,
like local variables,
it is still possible for subclasses explicitly
extending a generic type
with concrete types and for fields declared as non
generics to obtain
vital informations about the type of generic fields
and generic method
parameters.
What I'm saying is that in both following cases :
private ListString names;
public class People implement ListPerson { }
It is possible to determine the fact that the
People.add() method will
accept a Person, and the names.get() method will
return a String.
Unfortunately, it is quite complex to determine it,
cause Sun decided to
use only 4 interfaces, and force the user to make
continuous blind casts
between them.
JRE currently seems not to provide an alternative
simple solution, nor
using reflection nor introspection. Even worse,
given the following
generic class :
public GenericBeanT {
private T myGeneric;
public T getMyGeneric() { return myGeneric; }
public void setMyGeneric(T v) { myGeneric = v; }
}
Even subclassing it like PersonBean extends
GenericBeanPerson,
Introspection (and so BeanUtils) will return the
type of the myGeneric
property as java.lang.Object, but trying to set the
property to any
value which is not a Person will cause a
ClassCastException at runtime
because of explicit cast in bridging methods
(methods which also create
more noise during reflection).
Not to mention if only the getter or only the setter
gets overridden in
a subclass: in that case the compiler requires that
the concrete type
is used, thus making the getters and setter appear
as having different
types, and causing problems both in Introspector and
BeanUtils.
I had this problem recently in my Apache Lab, and
wrote a (simple, not
yet complete nor optimized, but functioning) wrapper
around Class and
Method to obtain this informations. It works also in
obscure situations
where a generics is extended by a chain of classes
and determining the
actual type require recursion on superclasses while
remapping all
generic declarations from the concrete one up to
the generic one.
I don't think it is yet able to handle all possible
situations, but I
think it covers that 70% of use cases which
represent a good starting
point. The code is already Apache licensed and
junited and can be
found on the Magma lab svn here
http://svn.apache.org/repos/asf/labs/magma/foundation-basics/src/main/java/org/apache/magma/basics/utils/GenericClass.java
.
While generics are not the hot buzzword of the
month anymore, usage of
introspection and reflection is gaining more and
more importance since
more and more frameworks are depending on it and
gaining popularity
(JPA, IOC containers like Spring, alternative
serializations like JSON
and so on), and many of them are currently dealing
with the generics
problems with custom code.
WDYT?
Simone
James Carman wrote:
Does anyone have code that can take care of this
situation:
ListString strings = new ArrayListString();
Class returnType =
getReturnType(strings.getClass(), get, int.class);
I want the returnType to be java.lang.String.
Does anyone have code
that would return that? Is it possible?
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
--
Simone GianniCEO Semeru s.r.l.
Apache Committer
MALE human being programming a computer
http://www.simonegianni.it/
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r696369 - /commons/sandbox/flatfile/trunk/pom.xml
As you like... see forthcoming commit. -Matt --- sebb [EMAIL PROTECTED] wrote: On 17/09/2008, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Author: mbenson Date: Wed Sep 17 09:56:17 2008 New Revision: 696369 URL: http://svn.apache.org/viewvc?rev=696369view=rev Log: no sense in targeting 1.5 for a component whose whole purpose is integrating with old stuff Modified: commons/sandbox/flatfile/trunk/pom.xml Modified: commons/sandbox/flatfile/trunk/pom.xml URL: http://svn.apache.org/viewvc/commons/sandbox/flatfile/trunk/pom.xml?rev=696369r1=696368r2=696369view=diff == --- commons/sandbox/flatfile/trunk/pom.xml (original) +++ commons/sandbox/flatfile/trunk/pom.xml Wed Sep 17 09:56:17 2008 @@ -128,8 +128,6 @@ !-- Compiler source and target JVM (see parent pom) -- properties - maven.compile.source1.5/maven.compile.source - maven.compile.target1.5/maven.compile.target I think you still need to specify the Java requirements. Leaving it to the parent POM is not a good idea in the long run as that may change, and anyway it's useful to be able to look at the POM and find the Java requirements. commons.componentidflatfile/commons.componentid /properties reporting - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
headers script
anybody have a preexisting apply-ASF-headers script they'd like to send me off-list? I can do it, but if you already have, why should I? TIA, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [flatfile] IP Clearance [was Re: svn commit: r692147 [1/3]...]
Somehow I missed Niall's email. There must be some confusion about the order of operations here; I was under the impression that the code should have its new license, etc., in place before the IP clearance process could be completed. I will remove and seek clarification from [EMAIL PROTECTED] Thanks, Matt --- Martin Cooper [EMAIL PROTECTED] wrote: Matt, could you please take a minute out of all your commits right now to address this, please? I tend to agree with Niall that the code should be removed until the clearance has been completed. -- Martin Cooper On Fri, Sep 5, 2008 at 5:41 PM, Niall Pemberton [EMAIL PROTECTED]wrote: IMO flatfile should be removed from the repo until the IP Clearance process has been completed. The commit says the grant has been recorded (I haven't verified that) - but that is just part of the process and not sufficient on its own. You need to complete the IP Clearance form and then submit it for approval to [EMAIL PROTECTED] AIUI thats usually a 72hr lazy consensus type process. http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/commons-flatfile.xml Heres a recent example: http://markmail.org/message/p7ggxn2abw64gu75 Niall On Thu, Sep 4, 2008 at 5:39 PM, [EMAIL PROTECTED] wrote: Author: mbenson Date: Thu Sep 4 09:39:28 2008 New Revision: 692147 URL: http://svn.apache.org/viewvc?rev=692147view=rev Log: initial add of flatfile contribution [grant recorded] Added: commons/sandbox/flatfile/trunk/doc/ commons/sandbox/flatfile/trunk/doc/userguide.html (with props) commons/sandbox/flatfile/trunk/src/ commons/sandbox/flatfile/trunk/src/grammar/ commons/sandbox/flatfile/trunk/src/grammar/EntityParser.g commons/sandbox/flatfile/trunk/src/grammar/EntityTreeParser.g commons/sandbox/flatfile/trunk/src/java/ commons/sandbox/flatfile/trunk/src/java/com/ commons/sandbox/flatfile/trunk/src/java/com/pgac/ commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/ commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/DynamicField.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/Entity.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/EntityArray.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/EntityCollection.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/EntityCollectionSupport.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/EntityFactory.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/EntityMap.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/EntitySupport.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/Field.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/FieldOption.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/FieldSupport.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/ImmutableEntity.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/IndexedEntityCollection.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/InputFilteringDynamicField.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/NamedEntityCollection.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/PadJustifyFieldSupport.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/dsl/ commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/dsl/ConstantEntityNameStrategy.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/dsl/DefaultEntityNameStrategy.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/dsl/EntityDefinition.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/dsl/EntityNameStrategy.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/dsl/ParserEntityFactory.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/entityfactory/ commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/entityfactory/CloningEntityFactory.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/entityfactory/CompositeEntityFactory.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/morph/ commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/morph/BaseEntityCollectionReflector.java (with props) commons/sandbox/flatfile/trunk/src/java/com/pgac/flatfile/morph/ByteArrayToEntityCopier.java
Re: [VOTE] Accept flatfile codebase for new sandbox component
--- Matt Benson [EMAIL PROTECTED] wrote: The codebase is available for perusal at: http://people.apache.org/~mbenson/flatfile-proposal/ The IP clearance template has been started and is available at: http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/commons-flatfile.xml This vote will be open for 72 hours. I believe the requisite 72 hours have elapsed, and this proposal has passed with the following votes: Oliver Heger +1 Emmanuel Bourg +1 Matt Benson +1 Thanks for voting! Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Accept flatfile codebase for new sandbox component
The codebase is available for perusal at: http://people.apache.org/~mbenson/flatfile-proposal/ The IP clearance template has been started and is available at: http://svn.apache.org/repos/asf/incubator/public/trunk/site-author/ip-clearance/commons-flatfile.xml This vote will be open for 72 hours. Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JXPath 1.3 based on RC5
Much obliged, Niall! -Matt --- Niall Pemberton [EMAIL PROTECTED] wrote: On Tue, Aug 12, 2008 at 6:50 PM, Matt Benson [EMAIL PROTECTED] wrote: --- Rahul Akolkar [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 4:03 PM, Matt Benson [EMAIL PROTECTED] wrote: snip/ P.S. Now, who wants to guide me through the remainder of this process, besides renaming the svn tag? TIA snap/ Its easier if you ask questions if you need to. Am I supposed to do the actual release with m2? From the same branch, rebuilding/signing the artifacts? Or simply releasing the same exact artifacts as constituted the RC? m2 always leaves me in a state of doubt. No, that would re-build the artifacts and you need to complete the release using the artifacts we voted on. You need to do from Step 6 onwards documented here - but with a few variations: http://commons.apache.org/releases/release.html In Step 8 (Deploy jar, project.xml and license.html to Java-Repository) you need to do this in the m2 repo (rather than m1) here: /www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-jxpath /commons-jxpath/1.3/ ... by just creating the appropriate directory structure and copying in the pom, jars sigs etc You also need to create a maven-metadata.xml file in /www/people.apache.org/repo/m2-ibiblio-rsync-repository/commons-jxpath /commons-jxpath/ I would start with the following one and add in the 1.3 release: http://repo1.maven.org/maven2/commons-jxpath/commons-jxpath/maven-metadata.xml Because this is the first m2 release of JXPath you also need to ping [EMAIL PROTECTED] telling theres a new m2 groupId (i.e. commons-jxpath). hth Niall -Matt -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JXPath 1.3 based on RC5
--- Rahul Akolkar [EMAIL PROTECTED] wrote: On Mon, Aug 11, 2008 at 4:03 PM, Matt Benson [EMAIL PROTECTED] wrote: snip/ P.S. Now, who wants to guide me through the remainder of this process, besides renaming the svn tag? TIA snap/ Its easier if you ask questions if you need to. Am I supposed to do the actual release with m2? From the same branch, rebuilding/signing the artifacts? Or simply releasing the same exact artifacts as constituted the RC? m2 always leaves me in a state of doubt. -Matt -Rahul - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JXPath 1.3 based on RC5
My own +1. -Matt --- Matt Benson [EMAIL PROTECTED] wrote: Thanks to anyone who reported/resolved issues with the previous release candidates. The artifacts are here: http://people.apache.org/~mbenson/jxpath-1.3-rc5/ The tag is here: http://svn.apache.org/viewvc/commons/proper/jxpath/tags/JXPATH_1_3_RC5/ Site: http://people.apache.org/~mbenson/jxpath-1.3-rc5/site Clirr Report (compared to 1.2; one-shot not working w/ M2) http://people.apache.org/~mbenson/jxpath-1.3-rc5/clirr-report.txt Thanks in advance to whomever can take the time to check and vote on the artifacts. This vote will be open through Friday, August 8. Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release JXPath 1.3 based on RC5
Thanks to anyone who reported/resolved issues with the previous release candidates. The artifacts are here: http://people.apache.org/~mbenson/jxpath-1.3-rc5/ The tag is here: http://svn.apache.org/viewvc/commons/proper/jxpath/tags/JXPATH_1_3_RC5/ Site: http://people.apache.org/~mbenson/jxpath-1.3-rc5/site Clirr Report (compared to 1.2; one-shot not working w/ M2) http://people.apache.org/~mbenson/jxpath-1.3-rc5/clirr-report.txt Thanks in advance to whomever can take the time to check and vote on the artifacts. This vote will be open through Friday, August 8. Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] release preparation
--- Rahul Akolkar [EMAIL PROTECTED] wrote: On Mon, Jul 28, 2008 at 6:54 PM, Matt Benson [EMAIL PROTECTED] wrote: Is a `mvn site` from a src distribution supposed to generate download_[component].cgi? snip/ No. If not, are we intended to make sure we preserve the existing file or re-create it when deploying the site? snap/ Don't need to do anything special for it (its preserved by default). Process: * Update commons.release.version in pom * mvn commons:download-page to gen the .xml download page * mvn site-deploy (or similar) As an aside (though perhaps its related), I saw a couple of updates to SVN tags go by -- it'd be best if we can avoid these. As these were updates directly related to creating RC5, I have no idea how to appease you in this regard. :( -Matt -Rahul This is confusing to me. Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] release preparation
--- Niall Pemberton [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2008 at 3:47 PM, Matt Benson [EMAIL PROTECTED] wrote: --- Rahul Akolkar [EMAIL PROTECTED] wrote: On Mon, Jul 28, 2008 at 6:54 PM, Matt Benson [EMAIL PROTECTED] wrote: Is a `mvn site` from a src distribution supposed to generate download_[component].cgi? snip/ No. If not, are we intended to make sure we preserve the existing file or re-create it when deploying the site? snap/ Don't need to do anything special for it (its preserved by default). Process: * Update commons.release.version in pom * mvn commons:download-page to gen the .xml download page * mvn site-deploy (or similar) As an aside (though perhaps its related), I saw a couple of updates to SVN tags go by -- it'd be best if we can avoid these. As these were updates directly related to creating RC5, I have no idea how to appease you in this regard. :( Theres really two ways of doing this. 1) Do all the updates in the trunk and then tag 2) Create a branch for the release, update there and then tag IMO best to choose 1) if the whole focus is only on the current release and 2) if other people are want to continue to do development and not have to hold off on commits while the release is being done. So in the pursuit of (1) you would recommend doing all necessary changes, then rolling them immediately back after the tag has been copied? -Matt Niall -Matt -Rahul This is confusing to me. Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [all] release preparation
--- Niall Pemberton [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2008 at 5:33 PM, Matt Benson [EMAIL PROTECTED] wrote: --- Niall Pemberton [EMAIL PROTECTED] wrote: On Tue, Jul 29, 2008 at 3:47 PM, Matt Benson [EMAIL PROTECTED] wrote: --- Rahul Akolkar [EMAIL PROTECTED] wrote: On Mon, Jul 28, 2008 at 6:54 PM, Matt Benson [EMAIL PROTECTED] wrote: Is a `mvn site` from a src distribution supposed to generate download_[component].cgi? snip/ No. If not, are we intended to make sure we preserve the existing file or re-create it when deploying the site? snap/ Don't need to do anything special for it (its preserved by default). Process: * Update commons.release.version in pom * mvn commons:download-page to gen the .xml download page * mvn site-deploy (or similar) As an aside (though perhaps its related), I saw a couple of updates to SVN tags go by -- it'd be best if we can avoid these. As these were updates directly related to creating RC5, I have no idea how to appease you in this regard. :( Theres really two ways of doing this. 1) Do all the updates in the trunk and then tag 2) Create a branch for the release, update there and then tag IMO best to choose 1) if the whole focus is only on the current release and 2) if other people are want to continue to do development and not have to hold off on commits while the release is being done. So in the pursuit of (1) you would recommend doing all necessary changes, then rolling them immediately back after the tag has been copied? No need to roll back, just roll forward once you have a successful release. For me this has just been rolling on the version number to the next SNAPSHOT. Having said that, I usually tag from my local copy which just has the version number change (all other changes, e.g. site committed to trunk) - not sure if Rahul considers that equivalent to / as bad as updating a Tag. For example the last Chain release candidates: http://markmail.org/message/nk4v42ptxcuoemir http://markmail.org/message/2awdi7hntpqhmghw http://markmail.org/message/chkvopsanzwrlstq Apparently I'm not svn-savvy enough... what cmd accomplishes this? Thanks, Matt Niall -Matt Niall -Matt -Rahul This is confusing to me. Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[all] release preparation
Is a `mvn site` from a src distribution supposed to generate download_[component].cgi? If not, are we intended to make sure we preserve the existing file or re-create it when deploying the site? This is confusing to me. Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JXPath 1.3 based on RC4
--- Jörg Schaible [EMAIL PROTECTED] wrote: Hi Matt, Builds from source and works fine on my compiler zoo except for all IBM-JDKs, but that's a different story (http://jira.codehaus.org/browse/MNG-3580). Some minor issues though in the docs: - download page goes nowhere, I suspect this is caused by the current location and automatically fixed for the release Correct; it's a relative path assuming that the site is installed at http://commons.apache.org/jxpath. - the links to the older APIs does not work, again I suspect this is fixed for the release Correct again. - the user's guide contains a table of content at its top. However, quite all of the link anchors do not work Fixed. Issue in the POM: Addressed as discussed elsewhere. [SNIP] Wiki: - talks about release plan for 1.2 ;-) mmm... Being that I'm already in the process of releasing 1.3, it seems a little too late to come up with a release plan. Should a release plan be obliterated from the Wiki once the release has taken place? Summary: -1, simply because of the wrong download links, anything else is not critical Since you called that a -1, despite acknowledging that it probably wasn't a problem on the deployed site, I'm not sure where that leaves this issue. I'm cutting a new RC, but the download link will still lead nowhere unless we change the way the site is built--the M1 navigation.xml as well as the M2 src/site.xml actually list all these links explicitly including commons.apache.org but that is apparently stripped out as the site is built. -Matt - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JXPath 1.3 based on RC4
Officially cancelling this vote, blah blah... --- Matt Benson [EMAIL PROTECTED] wrote: Thanks to anyone who reported/resolved issues with the previous release candidates. The artifacts are here: http://people.apache.org/~mbenson/jxpath-1.3-rc4/ The tag is here: http://svn.apache.org/viewvc/commons/proper/jxpath/tags/JXPATH_1_3_RC4/ Site: http://people.apache.org/~mbenson/jxpath-1.3-rc4/site Clirr Report (compared to 1.2; one-shot not working w/ M2) http://people.apache.org/~mbenson/jxpath-1.3-rc4/clirr-report.txt Thanks in advance to whomever can take the time to check and vote on the artifacts. This vote will be open through Thursday, July 10 (I do these long votes because I'm too slow to act any faster myself anyway). Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JXPath 1.3 based on RC4
--- sebb [EMAIL PROTECTED] wrote: Hashes sigs look fine There is an extraneous 'options' file in the apidocs directory and the javadoc jar. This is caused by the javadoc plugin, apparently. The options file appears to be something that specifying debugtrue/debug in the plugin's configuration will cause _not_ to be deleted at the end of the plugin's having completed its tasks. Unfortunately, debug is not specified to true that I can see, and I have tried to the best of my ability to declare it as false in a vain attempt to remove this options file, which I'm not terribly eager to have go out in releases either--thanks for catching it, Sebastian. Any Maven-knowledgeable folks want to tell me what I'm doing wrong lest I spout Maven slander as I typically tend to do? (...not that I recall ever having had to eat my own words in that regard...) The Manifest files in the source and javadoc jars don't contain anything useful. I expect this is a Maven feature, but that does not mean that it is correct ;-) I think the manifests should contain the following: Once again, no idea how to do this either. -Matt Built-By: mbenson Build-Jdk: 1.5.0_13 Implementation-Title: Commons JXPath Implementation-Vendor: The Apache Software Foundation Implementation-Vendor-Id: org.apache Implementation-Version: 1.3 Specification-Title: Commons JXPath Specification-Vendor: The Apache Software Foundation Specification-Version: 1.3 And perhaps: X-Compile-Source-JDK: 1.3 X-Compile-Target-JDK: 1.3 On 05/07/2008, Oliver Heger [EMAIL PROTECTED] wrote: Everything looks fine, but a mvn site:site fails for me with the error message Embedded error: conf\findbugs-exclude-filter.xml (File cannot be found.) This file seems to be missing in the source distribution (there is no conf directory at all). Oliver Matt Benson schrieb: Thanks to anyone who reported/resolved issues with the previous release candidates. The artifacts are here: http://people.apache.org/~mbenson/jxpath-1.3-rc4/ The tag is here: http://svn.apache.org/viewvc/commons/proper/jxpath/tags/JXPATH_1_3_RC4/ Site: http://people.apache.org/~mbenson/jxpath-1.3-rc4/site Clirr Report (compared to 1.2; one-shot not working w/ M2) http://people.apache.org/~mbenson/jxpath-1.3-rc4/clirr-report.txt Thanks in advance to whomever can take the time to check and vote on the artifacts. This vote will be open through Thursday, July 10 (I do these long votes because I'm too slow to act any faster myself anyway). Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JXPath 1.3 based on RC4
--- Jörg Schaible [EMAIL PROTECTED] wrote: Matt Benson wrote: --- Jörg Schaible [EMAIL PROTECTED] wrote: [snip] Wiki: - talks about release plan for 1.2 ;-) mmm... Being that I'm already in the process of releasing 1.3, it seems a little too late to come up with a release plan. Should a release plan be obliterated from the Wiki once the release has taken place? Well, that page is really obsolete now. Summary: -1, simply because of the wrong download links, anything else is not critical Since you called that a -1, despite acknowledging that it probably wasn't a problem on the deployed site, I'm not sure where that leaves this issue. The -1 is caused by the xdocs/download_jxpath.xml of the source distribution that contains references and links to the 1.2 version of the artifacts, caused by the wrong property in the POM. I'm cutting a new RC, but the download link will still lead nowhere unless we change the way the site is built--the M1 navigation.xml as well as the M2 src/site.xml actually list all these links explicitly including commons.apache.org but that is apparently stripped out as the site is built. As long as the the property in the POM is wrong, the download page will always contain wrong links in the final version ;-) Okay, I understand you now. :) -Matt - Jörg - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JXPath 1.3 based on RC4
--- Jörg Schaible [EMAIL PROTECTED] wrote:
Forgot to add the path for the POM, just in case you
will do another RC.
So... can you explain again what is the effect of
moving [logging] to the separate dependencyManagement
section of the POM?
Thanks,
Matt
Jörg Schaible wrote:
Hi Matt,
Builds from source and works fine on my compiler
zoo except for all
IBM-JDKs, but that's a different story
(http://jira.codehaus.org/browse/MNG-3580).
Some minor issues though in the docs:
- download page goes nowhere, I suspect this is
caused by the current
location and automatically fixed for the release
- the links to the older APIs does not work, again
I suspect this is fixed
for the release
- the user's guide contains a table of content at
its top. However, quite
all of the link anchors do not work
Issue in the POM:
- it defines a property commons.release.version
with value 1.2. This is
used by the download-page-template.xml to generate
the download page in
xdocs. Therefore currently all liks are generated
for JXPath 1.2. Maybe
the property's value in the POM should be defined
as ${project.version} in
general and its definition can move up to the
parent-pom.
- it declares an optional provided dep to
commons-logging, which is simply
not true, since jxpath does not make usage of
commons-logging. However
commons-beanutils has it as transitive dep in an
old version, therefore
commons-logging should be declared in a
dependencyManagement with version
1.1.1 to overwrite the old transitive version
- it declares an optional runtime dep to
commons-collection, but it is not
used by any other dependency and can therefore
removed completely (all
tests run fine without it)
- I don't under stand why deps are declared with
scope provided *and*
optional. IMHO provided is enough, but it may have
also effect on the
generated dependencies page
Wiki:
- talks about release plan for 1.2 ;-)
Summary:
-1, simply because of the wrong download links,
anything else is not
critical
- Jörg
Index: pom.xml
===
--- pom.xml (Revision 674189)
+++ pom.xml (Arbeitskopie)
@@ -62,7 +62,7 @@
properties
commons.componentidjxpath/commons.componentid
-
commons.release.version1.2/commons.release.version
+
commons.release.version{project.version}/commons.release.version
commons.binary.suffix /
commons.jira.idJXPATH/commons.jira.id
commons.jira.pid12310480/commons.jira.pid
@@ -100,18 +100,21 @@
/plugin
/plugins
/build
+ dependencyManagement
+dependencies
+ dependency
+groupIdcommons-logging/groupId
+artifactIdcommons-logging/artifactId
+version1.1.1/version
+ /dependency
+/dependencies
+ /dependencyManagement
dependencies
dependency
- groupIdcommons-logging/groupId
- artifactIdcommons-logging/artifactId
- version1.1.1/version
- optionaltrue/optional
- scoperuntime/scope
-/dependency
-dependency
groupIdxerces/groupId
artifactIdxercesImpl/artifactId
version2.4.0/version
+ scopeprovided/scope
optionaltrue/optional
/dependency
dependency
@@ -154,13 +157,6 @@
optionaltrue/optional
/dependency
dependency
- groupIdcommons-collections/groupId
- artifactIdcommons-collections/artifactId
- version3.2/version
- optionaltrue/optional
- scoperuntime/scope
-/dependency
-dependency
groupIdcom.mockrunner/groupId
artifactIdmockrunner-jdk1.3-j2ee1.3/artifactId
version0.4/version
-
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JXPath 1.3 based on RC4
--- sebb [EMAIL PROTECTED] wrote: Hashes sigs look fine There is an extraneous 'options' file in the apidocs directory and the javadoc jar. Noted; will investigate. The Manifest files in the source and javadoc jars don't contain anything useful. I expect this is a Maven feature, but that does not mean that it is correct ;-) I think the manifests should contain the following: Built-By: mbenson Build-Jdk: 1.5.0_13 Implementation-Title: Commons JXPath Implementation-Vendor: The Apache Software Foundation Implementation-Vendor-Id: org.apache Implementation-Version: 1.3 Specification-Title: Commons JXPath Specification-Vendor: The Apache Software Foundation Specification-Version: 1.3 And perhaps: X-Compile-Source-JDK: 1.3 X-Compile-Target-JDK: 1.3 Anyone have any idea how to accomplish these in mvn? -Matt On 05/07/2008, Oliver Heger [EMAIL PROTECTED] wrote: Everything looks fine, but a mvn site:site fails for me with the error message Embedded error: conf\findbugs-exclude-filter.xml (File cannot be found.) This file seems to be missing in the source distribution (there is no conf directory at all). Oliver Matt Benson schrieb: Thanks to anyone who reported/resolved issues with the previous release candidates. The artifacts are here: http://people.apache.org/~mbenson/jxpath-1.3-rc4/ The tag is here: http://svn.apache.org/viewvc/commons/proper/jxpath/tags/JXPATH_1_3_RC4/ Site: http://people.apache.org/~mbenson/jxpath-1.3-rc4/site Clirr Report (compared to 1.2; one-shot not working w/ M2) http://people.apache.org/~mbenson/jxpath-1.3-rc4/clirr-report.txt Thanks in advance to whomever can take the time to check and vote on the artifacts. This vote will be open through Thursday, July 10 (I do these long votes because I'm too slow to act any faster myself anyway). Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[VOTE] Release JXPath 1.3 based on RC4
Thanks to anyone who reported/resolved issues with the previous release candidates. The artifacts are here: http://people.apache.org/~mbenson/jxpath-1.3-rc4/ The tag is here: http://svn.apache.org/viewvc/commons/proper/jxpath/tags/JXPATH_1_3_RC4/ Site: http://people.apache.org/~mbenson/jxpath-1.3-rc4/site Clirr Report (compared to 1.2; one-shot not working w/ M2) http://people.apache.org/~mbenson/jxpath-1.3-rc4/clirr-report.txt Thanks in advance to whomever can take the time to check and vote on the artifacts. This vote will be open through Thursday, July 10 (I do these long votes because I'm too slow to act any faster myself anyway). Thanks, Matt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] Release JXPath 1.3 based on RC3
I do hereby cancel this vote. I also forgot to update the release notes with the last bug I entered/fixed in order to get tests (whose breakage only showed up on JDK1.3) working again. Thanks and apologies to those who checked out this RC. I think the next one will be a winner... -Matt --- sebb [EMAIL PROTECTED] wrote: On 18/06/2008, Matt Benson [EMAIL PROTECTED] wrote: Because the findbugs results, as well as the minor documentation issues that were identified, have already been addressed in trunk, it probably doesn't make any sense to release 1.3 only to follow it immediately with 1.3.1 when the content of 1.3.1 is already known before 1.3 is released. Does anyone object to my cancelling this vote and preparing RC4? OK by me. Thanks, Matt --- Matt Benson [EMAIL PROTECTED] wrote: --- sebb [EMAIL PROTECTED] wrote: On 16/06/2008, Matt Benson [EMAIL PROTECTED] wrote: --- sebb [EMAIL PROTECTED] wrote: On 15/06/2008, Oliver Heger [EMAIL PROTECTED] wrote: sebb schrieb: On 14/06/2008, Matt Benson [EMAIL PROTECTED] wrote: --- Oliver Heger [EMAIL PROTECTED] wrote: +1 Artifacts look very good. I also ran the tests for commons configuration with the new version successfully. The only thing that makes me a bit uneasy is the findbugs report showing 133 errors. Did you have a look at those? I actually didn't, but I don't see anything in there that really surprises me. Some false positives (e.g. String ==), some Serialization issues I knew were there. It would be nice to attack these for another release. Certainly some of them need fixing, e.g. Use of non-localized String.toUpperCase() or String.toLowerCase at http://people.apache.org/~mbenson/jxpath-1.3-rc3/site/xref/org/apache/commons/jxpath/ri/model/NodePointer.html#549 and http://people.apache.org/~mbenson/jxpath-1.3-rc3/site/xref/org/apache/commons/jxpath/ri/model/dom/DOMNodePointer.html#330 These should use something like toUpperCase(Locale.ENGLISH). Might also be worth adding exclusions for the bugs that are false positives... I think if the problems were introduced during the work on the 1.3 release, they really should be addressed. However if they live in the code base for a longer time, they have obviously not caused major problems yet, and the strategy to fix them in the next release seems reasonable to me. Good point. Is this one new? Dead store to collection in org.apache.commons.jxpath.ri.model.beans.CollectionPointer.createPath(JXPathContext) http://people.apache.org/~mbenson/jxpath-1.3-rc3/site/xref/org/apache/commons/jxpath/ri/model/beans/CollectionPointer.html#125 The code certainly looks odd ... Not new, and from the POV of understanding what the code there does (grows the underlying collection to a size such that the index is valid) doesn't appear problematic. What's confusing is that the collection variable is assigned, but not used. Actually the problem here is shadowing. I'll work on this. This is a bug, but one that would only make a difference for arrays as they must be reassigned while a collection would simply be grown. Not sure if this should be a blocker. :| -Matt Perhaps remove the assignment to make it clearer. (most of the other dead store reports seem to be FPs) If getMessage() is heavily used, then this one should be fixed: Method org.apache.commons.jxpath.ri.parser.ParseException.getMessage() concatenates strings using + in a loop This is generated code. It wouldn't hurt to fix it, since the JXPath parser code is generated and then saved, but in theory if we ever regenerated the parser from the JavaCC grammar we'd be starting from scratch to add back any improvements made. It being the case
