date:20111205

On Mon, Dec 5, 2011 at 5:45 PM, Jörg Schaible  wrote:

> Hi Gary,
>
> Gary Gregory wrote:
>
> > Hi All:
> >
> > I've made several improvements to VFS over the last couple of months
> which
> > feels ready for a release soon.
> >
> > One important internal change is that the builds runs almost all unit
> > tests
> > :)
>
> I saw your efforts and this is really a great improvement! Thanks!
>
> > I've not found an easy way to embed a WebDAV server in the tests like
> > JackRabbit, which would be nice to do.
>
> Definitely :)
>
> > I know Ralph just mentioned thoughts of a VFS3 on top of Java 7, which is
> > great news indeed. This feels like it needs a new name instead of a
> > version change though because the change is so radical (and nice.)
> >
> > Thoughts?
>
> I'd keep the name, it's a brand here and if we name it VFS3 and document
> that it is based on Java 7 technology, so why change it?
>

Point taken; VFS3 it is :)

Gary


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


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VFS] next release

Hi Gary,

Gary Gregory wrote:

> Hi All:
> 
> I've made several improvements to VFS over the last couple of months which
> feels ready for a release soon.
> 
> One important internal change is that the builds runs almost all unit
> tests
> :) 

I saw your efforts and this is really a great improvement! Thanks!

> I've not found an easy way to embed a WebDAV server in the tests like
> JackRabbit, which would be nice to do.

Definitely :)

> I know Ralph just mentioned thoughts of a VFS3 on top of Java 7, which is
> great news indeed. This feels like it needs a new name instead of a
> version change though because the change is so radical (and nice.)
> 
> Thoughts?

I'd keep the name, it's a brand here and if we name it VFS3 and document 
that it is based on Java 7 technology, so why change it?

- Jörg


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

Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX

On Mon, Dec 5, 2011 at 5:19 PM, Jörg Schaible  wrote:

> Gary Gregory wrote:
>
> > Good day to you all:
> >
> > I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am
> > not calling it RC3 because there are no changes in source files from the
> > last RC. The only difference is that I built from a fresh checkout of the
> > RC2 svn tag.
> >
> > The changes from RC1 are what Sebb found:
> > - EOL in sources
> > - Cruft from a dirty build, so I built this RC as I should have the first
> > time around with:
> > - mvn clean
> > - mvn deploy -Prelease
> >
> > Tag:
> >
> > https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec
> > -1.6-RC2
> >
> > Site:
> >
> > https://people.apache.org/builds/commons/codec/1.6/RC2/
> >
> > Binaries:
> >
> > <
> https://repository.apache.org/content/repositories/orgapachecommons-224/>
> > https://repository.apache.org/content/repositories/orgapachecommons-290/
> >
> > The link above includes checksum files.
> >
> > [ ] +1 release it
> > [ ] +0 go ahead, I cannot take the time
> > [ ] -1 no, do not release it because:
>
> +1
>
> > This VOTE is open for 72 hours, until November 23 2011, 14:00 EST.
>
> Change the history ... ?!? :)
>

Ah, yes, we have different clocks here on planet Zeenar.

REDUX: This VOTE is open for 72 hours, until December 5 2011, 23:00 EST.

Good catch,
Gary


> Build went fine for my compiler zoo (apart from the well-known problem with
> IBM JDK 5) on Linux/amd64. I had none of Olivers problems with Java 5
> versions.
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE][email] Release Commons Email 1.3 based on RC2

Hi Siegfried,

Siegfried Goeschl wrote:

> Hi folks,
> 
> I would like to call a vote to release commons-email-1.3 which contains
> the following bug fixes and improvements found here
> 
> http://people.apache.org/builds/commons/email/1.3/RC2/site/changes-
report.html
> 
> Tag:
> 
> https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC2
> 
> Site:
> 
> http://people.apache.org/builds/commons/email/1.3/RC2/site/index.html
> 
> Binaries:
> 
> 
http://people.apache.org/builds/commons/email/1.3/RC2/staged/org/apache/commons/commons-
email/1.3/
> 
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because

-1

like Gary I miss the distribution .zip and .tar.gz files for binaries and 
source.

Cheers,
Jörg


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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 4:13 PM, Christian Grobmeier  wrote:
> On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson  wrote:
>> On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier  
>> wrote:
>>> On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson  wrote:
 I think all that Sebastian is saying is something like "if you can
 create your new, cool API and the only things you really miss from
 Java 6 are @Override on interface implementation methods and
 ServiceLoader, for example, maybe it's worth that tiny bit of extra
 pain to reach that slightly larger audience."  We all feel frustrated
 from time to time working in the community setting; I've been there
 myself, but I don't think Seb is just trying to be a killjoy just for
 the hell of it.
>>>
>>> Yes, you might be right on this interpretation.
>>>
>>> As long as there a volunteers for maintaining jexl2 on j5 setting, I
>>> am fine with keeping j5 for it. To be clear, I am not saying we kill
>>> jexl2 today or quit jdk5 support for jexl2.
>>>
>>> But we should not make it a policy to start a new, major version with
>>> the lowest JDK version possible when the actual maintainers would like
>>> to use a current platform - this needs no discussion imho, they should
>>> simply do as they please.
>>
>> I agree that the developers of a component should do as they
>> [collectively] please.  However, in the case of [jexl] it appears that
>> Seb is interested in the development of this component.  He may
>> continue to be interested in the development of a v3.x of [jexl].  Now
>> we don't have as clear-cut a case of do-ocracy and henrib just doing
>> what he pleases anymore, because he has to do instead "as near as he
>> can get to what he pleases while still functioning in a
>> consensus-based manner."  A possible sequence of events:
>>
>>  - henrib proposes that [jexl] include feature X, using feature Y
>> from Java 6, thus justifying this minimum version.  Assuming the
>> community doesn't vote down the feature on its own merits, Java 6 it
>> is.
>>  - sebb can then come along say, hey, I know we agreed on feature X,
>> but I can put in 4 hours of work or create a new Commons component to
>> reimplement feature Y, and now Java 5 users can also benefit from
>> [jexl] 3!
>>
>> Assuming someone else is willing to do the *actual* work required to
>> keep Java 5 compatibility, are you really going to spend time and
>> energy fighting for interface @Overrides?  Obviously there would
>> probably be some point at which Seb in this example would say, sure, I
>> could reimplement feature Y, but it's going to take ten hours, twenty
>> hours.  Not worth it; have your Java 6!
>>
>> This is the way I see our community as having to function.
>
> With just 2 committers on a component, is not really easy to get an
> consens when both have different opinions. What now?
> Henri needs to wait until Sebb gives up java5.
>

I don't know what to say.  Finding consensus is part of The Apache
Way.  I guess this means all concerned parties should try and be
reasonable and remember that this is a do-ocracy.  If Seb wants to
make the contributions that will keep [jexl] 3x compatible with 1.5, I
don't see that this should inconvenience Henri B. to the point that he
should rather work elsewhere.  Again, when the burden of maintaining
compatibility becomes too great, it will be obviously time to move to
Java 6.

On the other hand, how long will an API redesign take?  Maybe the
right approach is to start with Java 6, then whoever likes to can
investigate how much work it would take to restore Java 5
compatibility.  This could even be done with multiple mvn modules.

Matt

> ...
>
> Christian
>
>>
>> Matt
>>
>>>
>>> Cheers
>>>

 Matt

 On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier  
 wrote:
> On Mon, Dec 5, 2011 at 7:38 PM, sebb  wrote:
>> On 5 December 2011 18:10, henrib  wrote:
>>> sebb-2-2 wrote

 My view is that while there is still a need for software to be able to
 run on Java 1.5, we should not insist on requiring a minimum of
 1.6.*unless* there is good technical reason for doing so.

>>> But you don't consider a good (technical) reason the fact that the
>>> contributor can not/does not want to incur the cost of maintaining a 
>>> JDK 1.5
>>> on its dev platforms to be able to contribute to newer versions...
>>
>> No, I don't consider that a valid reason on its own.
>
> Committing should be fun. If one does not want to support JDK 1.5 he
> goes away. Henri seems as he does not want and would like to put
> effort in a more modern environment. In addition, how many people can
> you attract with a JDK 1.5 version to contribute? For me this is valid
> reason.
>
>>> And no-one is stating that Java 1.5 is not in used in production 
>>> somewhere;
>>> but IMHO, these are not the ones that will be JEXL3 users, especially 
>>> since

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 5:13 PM, Christian Grobmeier wrote:

> On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson  wrote:
> > On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier 
> wrote:
> >> On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson 
> wrote:
> >>> I think all that Sebastian is saying is something like "if you can
> >>> create your new, cool API and the only things you really miss from
> >>> Java 6 are @Override on interface implementation methods and
> >>> ServiceLoader, for example, maybe it's worth that tiny bit of extra
> >>> pain to reach that slightly larger audience."  We all feel frustrated
> >>> from time to time working in the community setting; I've been there
> >>> myself, but I don't think Seb is just trying to be a killjoy just for
> >>> the hell of it.
> >>
> >> Yes, you might be right on this interpretation.
> >>
> >> As long as there a volunteers for maintaining jexl2 on j5 setting, I
> >> am fine with keeping j5 for it. To be clear, I am not saying we kill
> >> jexl2 today or quit jdk5 support for jexl2.
> >>
> >> But we should not make it a policy to start a new, major version with
> >> the lowest JDK version possible when the actual maintainers would like
> >> to use a current platform - this needs no discussion imho, they should
> >> simply do as they please.
> >
> > I agree that the developers of a component should do as they
> > [collectively] please.  However, in the case of [jexl] it appears that
> > Seb is interested in the development of this component.  He may
> > continue to be interested in the development of a v3.x of [jexl].  Now
> > we don't have as clear-cut a case of do-ocracy and henrib just doing
> > what he pleases anymore, because he has to do instead "as near as he
> > can get to what he pleases while still functioning in a
> > consensus-based manner."  A possible sequence of events:
> >
> >  - henrib proposes that [jexl] include feature X, using feature Y
> > from Java 6, thus justifying this minimum version.  Assuming the
> > community doesn't vote down the feature on its own merits, Java 6 it
> > is.
> >  - sebb can then come along say, hey, I know we agreed on feature X,
> > but I can put in 4 hours of work or create a new Commons component to
> > reimplement feature Y, and now Java 5 users can also benefit from
> > [jexl] 3!
> >
> > Assuming someone else is willing to do the *actual* work required to
> > keep Java 5 compatibility, are you really going to spend time and
> > energy fighting for interface @Overrides?  Obviously there would
> > probably be some point at which Seb in this example would say, sure, I
> > could reimplement feature Y, but it's going to take ten hours, twenty
> > hours.  Not worth it; have your Java 6!
> >
> > This is the way I see our community as having to function.
>
> With just 2 committers on a component, is not really easy to get an
> consens when both have different opinions. What now?
> Henri needs to wait until Sebb gives up java5.
>

No one has veto power here. We're all reasonable folks. Well, I'd like to
think I am. Most of us are passionate and opinionated. That a good thing.

If you work towards a .jexl3 Java 6 release and get the votes to get an RC
out, I won't and can't stop you. Actually, I'm all for it :)

Gary


> ...
>
> Christian
>
> >
> > Matt
> >
> >>
> >> Cheers
> >>
> >>>
> >>> Matt
> >>>
> >>> On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier <
> grobme...@gmail.com> wrote:
>  On Mon, Dec 5, 2011 at 7:38 PM, sebb  wrote:
> > On 5 December 2011 18:10, henrib  wrote:
> >> sebb-2-2 wrote
> >>>
> >>> My view is that while there is still a need for software to be
> able to
> >>> run on Java 1.5, we should not insist on requiring a minimum of
> >>> 1.6.*unless* there is good technical reason for doing so.
> >>>
> >> But you don't consider a good (technical) reason the fact that the
> >> contributor can not/does not want to incur the cost of maintaining
> a JDK 1.5
> >> on its dev platforms to be able to contribute to newer versions...
> >
> > No, I don't consider that a valid reason on its own.
> 
>  Committing should be fun. If one does not want to support JDK 1.5 he
>  goes away. Henri seems as he does not want and would like to put
>  effort in a more modern environment. In addition, how many people can
>  you attract with a JDK 1.5 version to contribute? For me this is valid
>  reason.
> 
> >> And no-one is stating that Java 1.5 is not in used in production
> somewhere;
> >> but IMHO, these are not the ones that will be JEXL3 users,
> especially since
> >> they have 2.1 (soon).
> >
> >> Anyway and beyond the point, my advice to 1.5 users is that before
> trying to
> >> use "new" versions of libraries, migrating away from an
> unsupported/EOLed
> >> platform should be their priority.
> >
> > Indeed, ideally everyone would now be using Java 6 and Windows users
> > should all upgrade to Windows 7 etc.

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

henrib wrote:

> 
> sebb-2-2 wrote
>> 
>> 
>>> But even if it were the case, you'd still argue for us to continue using
>>> IE6...
>> 
>> No, I would not; that's an end-user product.
>> 
>> 
> I see it as the worst web app client platform... Even on that, we can't
> agree!
> (sorry, couldn't resist :-)...)

... and you know what? One of our major customers finally (!!!) did an 
upgrade *last month*. This *is* a typical situation in large companies, 
where a software upgrade means to roll out software to 100'000 computers.

- Jörg

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

Hi Henri,

henrib wrote:

> Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
> little forward...
> 
> Since a 2-person opposition never breaks the tie, a vote is in order to
> decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123)
> can actually break loose of Java 1.5 compatibility. (sic)
> 
> JEXL3 is intended to be a next major release of JEXL that cleans up the
> API, making sure the internal/public contract is crystal clear. Since it
> is a major revamp of the API, JEXL3 is intended to be used by new/active
> projects that will be deployed on Java6 / Java7. To avoid some development
> cost, I've "blatantly" crossed another rule without much thinking by
> requiring Java6 for JEXL3 (instead of Java5 which is EOL).
> 
> Since JEXL2.1 - aka the next imminent version of jexl2 - already targets
> Java 1.5, I did not think it would start yet another fight with the
> release police. Was I wrong... "Why can't you supporting a EOL-ed platform
> for a new version of the project?". (Because it's not a freebie for me but
> no matter).

As a rule of thumb: Do not drop binary compatibility without a really good 
reason. We were really glad when some of our major customers finally dropped 
Java 1.4 two years ago, long after its EOL. It is really not uncommon for 
big players to stay way behind especially in financial business. However ...

if you make a complete redesign of the API, that will break compatibility in 
large parts anyway, it is IMHO also fine to rely on the latest Java version. 
JEXL 2.x will not vanish and nobody is stopped from creating a maintenance 
release.

> So, here we are again for some bickering and vote:
> [+1] Yes, you may release the next major release of JEXL3 with a Java6
> requirement
> [-1] No, this is an important case/issue/matter/rule that we continue
> supporting Java 1.5
> [0]  Don't care

+1

> Many thanks to those who will vote for their time and patience;
> Henrib
> 
> PS: Is there a process to formally move a project from Commons to
> elsewhere within Apache?

The problem of deep dependency conflicts will not suddenly vanish though ;-)

- Jörg


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

Re: svn commit: r1210678 - in /commons/proper/digester/trunk/src: main/java/org/apache/commons/digester3/binder/ test/resources/org/apache/commons/digester3/xmlrules/

Note that in the testcase XML you don't need @params if you're using
the (boolean, double) constructor.  The default constructor arguments
were needed to avoid the NPEs that were thrown due to the (Boolean,
Double) constructor calling { this( booleanProperty.booleanValue(),
doubleProperty.doubleValue() ); }

Matt

On Mon, Dec 5, 2011 at 4:27 PM,   wrote:
> Author: simonetripodi
> Date: Mon Dec  5 22:27:50 2011
> New Revision: 1210678
>
> URL: http://svn.apache.org/viewvc?rev=1210678&view=rev
> Log:
> [DIGESTER-154] The DigesterBinder is not able to load primitive classes by 
> name
>
> Added:
>    
> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
>    (with props)
> Modified:
>    
> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/DigesterLoader.java
>    
> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/ObjectCreateBuilder.java
>    
> commons/proper/digester/trunk/src/test/resources/org/apache/commons/digester3/xmlrules/constructor-testrules.xml
>
> Added: 
> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
> URL: 
> http://svn.apache.org/viewvc/commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java?rev=1210678&view=auto
> ==
> --- 
> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
>  (added)
> +++ 
> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
>  Mon Dec  5 22:27:50 2011
> @@ -0,0 +1,71 @@
> +package org.apache.commons.digester3.binder;
> +
> +import java.util.Collections;
> +import java.util.HashMap;
> +import java.util.Map;
> +
> +/*
> + * Licensed to the Apache Software Foundation (ASF) under one
> + * or more contributor license agreements.  See the NOTICE file
> + * distributed with this work for additional information
> + * regarding copyright ownership.  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.  See the License for the
> + * specific language governing permissions and limitations
> + * under the License.
> + */
> +
> +final class BinderClassLoader
> +    extends ClassLoader
> +{
> +
> +    private static final Map> PRIMITIVE_TYPES;
> +    static
> +    {
> +        HashMap> primitiveTypes = new HashMap Class>();
> +        primitiveTypes.put( "boolean", boolean.class );
> +        primitiveTypes.put( "byte", byte.class );
> +        primitiveTypes.put( "short", short.class );
> +        primitiveTypes.put( "int", int.class );
> +        primitiveTypes.put( "char", char.class );
> +        primitiveTypes.put( "long", long.class );
> +        primitiveTypes.put( "float", float.class );
> +        primitiveTypes.put( "double", double.class );
> +        PRIMITIVE_TYPES = Collections.unmodifiableMap( primitiveTypes );
> +    }
> +
> +    private final ClassLoader adaptedClassLoader;
> +
> +    public BinderClassLoader( ClassLoader adaptedClassLoader )
> +    {
> +        this.adaptedClassLoader = adaptedClassLoader;
> +    }
> +
> +    public ClassLoader getAdaptedClassLoader()
> +    {
> +        return adaptedClassLoader;
> +    }
> +
> +    /**
> +     * {@inheritDoc}
> +     */
> +    @Override
> +    protected synchronized Class loadClass( String name, boolean resolve )
> +        throws ClassNotFoundException
> +    {
> +        if ( PRIMITIVE_TYPES.containsKey( name ) )
> +        {
> +            return PRIMITIVE_TYPES.get( name );
> +        }
> +        return adaptedClassLoader.loadClass( name );
> +    }
> +
> +}
>
> Propchange: 
> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
> --
>    svn:eol-style = native
>
> Propchange: 
> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
> --
>    svn:keywords = Date Author Id Revision HeadURL
>
> Propchange: 
> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/BinderClassLoader.java
> --
>    svn:mime-type = text/plain
>
> Modified: 
> commons/proper/digester/trunk/src/main/java/org/apache/commons/digester3/binder/DigesterLoa

Re: [JEXL] [PreVOTE] OK to release Jexl with some Clirr errors but no package/id change?

Go for 2.1.

The problem of binary incompatibility only arise if you do *not* have access 
to the sources.

sebb wrote:

> The Jexl 2.0 branch now has only a few incompatibilities reported by
> Clirr (see below).
> 
> Also the 2.0.1 JUnit tests now run (with minor essential changes)
> against both 2.0.1 and 2.1-SNAPSHOT.
> 
> The remaining errors all relate to adding methods to interfaces.
> According to the JLS [1], adding methods to an interface does not
> break *binary* compatibility; however of course it will break source
> compatibility.
> I assume that Clirr has got this wrong; or is failing to distinguish
> source compatibility from binary compatibility.
> There is a test case to show this -
> ScriptTest.testScriptInterfaceBinaryCompat() - in the
> COMMONS_JEXL_2_0_1_TEST branch.
> 
> I think it would be OK to release the code without changing package
> names / Maven id if other Commons developers agree.
> What do others think?
> 
> Assuming that there are no objections, there is the question of what
> version to use.
> 
> The changes clearly require at least a minor version bump, i.e. 2.1
> rather than 2.0.2.
> It is unlikely that any users will have implemented the Script
> interface directly; any that have done so will need to update their
> source before recompiling.
> Does such a source incompatibility require a major version bump to 3.0?
> [Note: this does *not* mean a package change is required; however a
> package change would require a major version bump]
> 
> I think this discussion is best held separately from any release vote,
> as there are always plenty of other items to check in a release
> vote...
> 
> =
> 
> ERROR: 7012: org.apache.commons.jexl2.introspection.Uberspect: Method
> 'public org.apache.commons.jexl2.introspection.JexlMethod
> getConstructorMethod(java.lang.Object, java.lang.Object[],
> org.apache.commons.jexl2.JexlInfo)' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.JexlInfo: Method 'public
> org.apache.commons.jexl2.DebugInfo debugInfo()' has been added to an
> interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.lang.Object execute(org.apache.commons.jexl2.JexlContext,
> java.lang.Object[])' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.lang.String[] getLocalVariables()' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.lang.String[] getParameters()' has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.util.concurrent.Callable
> callable(org.apache.commons.jexl2.JexlContext)' has been added to an
> interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.util.concurrent.Callable
> callable(org.apache.commons.jexl2.JexlContext, java.lang.Object[])'
> has been added to an interface
> ERROR: 7012: org.apache.commons.jexl2.Script: Method 'public
> java.util.Set getVariables()' has been added to an interface
> 
> [1]
> 
[http://java.sun.com/docs/books/jls/second_edition/html/binaryComp.doc.html#45347



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

Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX

Gary Gregory wrote:

> Good day to you all:
> 
> I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am
> not calling it RC3 because there are no changes in source files from the
> last RC. The only difference is that I built from a fresh checkout of the
> RC2 svn tag.
> 
> The changes from RC1 are what Sebb found:
> - EOL in sources
> - Cruft from a dirty build, so I built this RC as I should have the first
> time around with:
> - mvn clean
> - mvn deploy -Prelease
> 
> Tag:
> 
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec
> -1.6-RC2
> 
> Site:
> 
> https://people.apache.org/builds/commons/codec/1.6/RC2/
> 
> Binaries:
> 
> 
> https://repository.apache.org/content/repositories/orgapachecommons-290/
> 
> The link above includes checksum files.
> 
> [ ] +1 release it
> [ ] +0 go ahead, I cannot take the time
> [ ] -1 no, do not release it because:

+1

> This VOTE is open for 72 hours, until November 23 2011, 14:00 EST.

Change the history ... ?!? :)

Build went fine for my compiler zoo (apart from the well-known problem with 
IBM JDK 5) on Linux/amd64. I had none of Olivers problems with Java 5 
versions.

- Jörg


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

Re: [RELEASE PROCESS] Stability versus usability

Hi Henri,

henrib wrote:

> 
> It seems to me we have a hard time allowing both stability and usability.
> Stability of APIs does not contradict usability of the library, at least
> should not.
> 
> Some of us are looking for very long term/stable/high-quality solutions
> because they need to aggregate lost of components, the stability users.
> Others are looking for best-of-breed/narrow scope/malleable libraries a
> with a guaranteed quality, the usability users.
> Thus the importance of clearly stating in our libraries what is 'stable'
> and what is 'usable'.
> The expressiveness in the language itself is not enough to properly
> describe the contract made regarding each party; i.e. sometimes things
> have to be public but should not be considered part of the API that follow
> the major,minor - deprecation.
> I believe we can come up with a set of agreeable rules to please both
> "camps" be through some naming convention in packages and annotations.
> 
> As an kickstart proposal, may be something as simple as 2 annotations
> actually could be enough: @stable, @usable.
> @stable meaning the contract this API represents will not change without
> being first @deprecated
> @usable meaning this API is valid for this major version but may change in
> each minor with no warning
> We might also use a clear 'internal' sub-package name as a frontier
> delimiter on the same rule.
> 
> Thoughts ?

I don't see a real different between stable and usable. Either a user can 
rely on a functionality or not. If you want to improve a part of the API 
without breaking compatibility, you may always deprecate the part that 
should no longer be used, because it will vanish in the next major release. 
This is what we normally do for a new release. This is e.g. what we've done 
with commons-io (although we improved the interface for generics). If it is 
a real redesign of the API (like lang3), we make it possible to use old and 
new versions side-by-side with new package name and artifactId to avoid 
unresolvable dependency situations for our users.

I am all for 'internal' packages. IMHO it is not necessary to name a package 
as 'internal' as long as it is clearly documented, but it is definitely a 
better indication. It's definitely the right approach to exclude internal 
packages from clirr, personally I'd even exclude internal packages from 
Javadoc. The risc of usage must be clear to every user.

However, I don't believe that annotations will really help. I'd separate 
internal stiff on package boundary and anything else is part of the public 
API. If you start to mix different annotations within one package, all you 
get is confusion.

Cheers,
Jörg

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 10:37 PM, Matt Benson  wrote:
> On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier  
> wrote:
>> On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson  wrote:
>>> I think all that Sebastian is saying is something like "if you can
>>> create your new, cool API and the only things you really miss from
>>> Java 6 are @Override on interface implementation methods and
>>> ServiceLoader, for example, maybe it's worth that tiny bit of extra
>>> pain to reach that slightly larger audience."  We all feel frustrated
>>> from time to time working in the community setting; I've been there
>>> myself, but I don't think Seb is just trying to be a killjoy just for
>>> the hell of it.
>>
>> Yes, you might be right on this interpretation.
>>
>> As long as there a volunteers for maintaining jexl2 on j5 setting, I
>> am fine with keeping j5 for it. To be clear, I am not saying we kill
>> jexl2 today or quit jdk5 support for jexl2.
>>
>> But we should not make it a policy to start a new, major version with
>> the lowest JDK version possible when the actual maintainers would like
>> to use a current platform - this needs no discussion imho, they should
>> simply do as they please.
>
> I agree that the developers of a component should do as they
> [collectively] please.  However, in the case of [jexl] it appears that
> Seb is interested in the development of this component.  He may
> continue to be interested in the development of a v3.x of [jexl].  Now
> we don't have as clear-cut a case of do-ocracy and henrib just doing
> what he pleases anymore, because he has to do instead "as near as he
> can get to what he pleases while still functioning in a
> consensus-based manner."  A possible sequence of events:
>
>  - henrib proposes that [jexl] include feature X, using feature Y
> from Java 6, thus justifying this minimum version.  Assuming the
> community doesn't vote down the feature on its own merits, Java 6 it
> is.
>  - sebb can then come along say, hey, I know we agreed on feature X,
> but I can put in 4 hours of work or create a new Commons component to
> reimplement feature Y, and now Java 5 users can also benefit from
> [jexl] 3!
>
> Assuming someone else is willing to do the *actual* work required to
> keep Java 5 compatibility, are you really going to spend time and
> energy fighting for interface @Overrides?  Obviously there would
> probably be some point at which Seb in this example would say, sure, I
> could reimplement feature Y, but it's going to take ten hours, twenty
> hours.  Not worth it; have your Java 6!
>
> This is the way I see our community as having to function.

With just 2 committers on a component, is not really easy to get an
consens when both have different opinions. What now?
Henri needs to wait until Sebb gives up java5.

...

Christian

>
> Matt
>
>>
>> Cheers
>>
>>>
>>> Matt
>>>
>>> On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier  
>>> wrote:
 On Mon, Dec 5, 2011 at 7:38 PM, sebb  wrote:
> On 5 December 2011 18:10, henrib  wrote:
>> sebb-2-2 wrote
>>>
>>> My view is that while there is still a need for software to be able to
>>> run on Java 1.5, we should not insist on requiring a minimum of
>>> 1.6.*unless* there is good technical reason for doing so.
>>>
>> But you don't consider a good (technical) reason the fact that the
>> contributor can not/does not want to incur the cost of maintaining a JDK 
>> 1.5
>> on its dev platforms to be able to contribute to newer versions...
>
> No, I don't consider that a valid reason on its own.

 Committing should be fun. If one does not want to support JDK 1.5 he
 goes away. Henri seems as he does not want and would like to put
 effort in a more modern environment. In addition, how many people can
 you attract with a JDK 1.5 version to contribute? For me this is valid
 reason.

>> And no-one is stating that Java 1.5 is not in used in production 
>> somewhere;
>> but IMHO, these are not the ones that will be JEXL3 users, especially 
>> since
>> they have 2.1 (soon).
>
>> Anyway and beyond the point, my advice to 1.5 users is that before 
>> trying to
>> use "new" versions of libraries, migrating away from an unsupported/EOLed
>> platform should be their priority.
>
> Indeed, ideally everyone would now be using Java 6 and Windows users
> should all upgrade to Windows 7 etc.
>
> But that is a separate issue.

 No it is not.

 It seems you ignore my idea on having jexl2 in maintenance mode, but
 this is actually what MS did with Win XP. Now they don't support it. I
 ask myself, why do we need to support outdated jdks until all
 committers are gone away or the library is the outdated people get
 some fresher stuff (Collections vs Guava)?

 If Henri is the opinion that people should use jdk6 he should be
 allowed to create such a version and call it Jexl3.

Re: [VOTE][email] Release Commons Email 1.3 based on RC2

Hi Siegfried:

Thank you for preparing the RC.

This /sounds/ worrisome from RAT:

Unapproved licenses:

  src/resources/META-INF/mime.types
  src/test/eml/attachment-only.eml
  src/test/eml/html-attachment.eml
  src/test/eml/multipart-report.eml
  src/test/eml/simple-reply.eml
  src/test/eml/simple.eml

Where is the 'src' zip I can build from?

Looks like there are three easy to fix checkstyle errors (not the missing
Javadocs.)

-1: Can you justify the 51 Clirr errors in a minor release?

Our current guideline is that such a change means a major version and new
package. I do not care which way we go but we should be mindful of binary
compatibility for minor release.

Thank you,
Gary

On Mon, Dec 5, 2011 at 4:31 PM, Siegfried Goeschl  wrote:

> Hi folks,
>
> I would like to call a vote to release commons-email-1.3 which contains
> the following bug fixes and improvements found here
>
> http://people.apache.org/**builds/commons/email/1.3/RC2/**
> site/changes-report.html
>
> Tag:
>
> https://svn.apache.org/repos/**asf/commons/proper/email/tags/**
> EMAIL_1_3_RC2
>
> Site:
>
> http://people.apache.org/**builds/commons/email/1.3/RC2/**site/index.html
>
> Binaries:
>
> http://people.apache.org/**builds/commons/email/1.3/RC2/**
> staged/org/apache/commons/**commons-email/1.3/
>
> [ ] +1 release it
> [ ] +0 go ahead I don't care
> [ ] -1 no, do not release it because
>
> Thanks in advance
>
> Siegfried Goeschl
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX

My +1.

Gary

On Fri, Dec 2, 2011 at 10:06 PM, Gary Gregory  wrote:

> Good day to you all:
>
> I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I am
> not calling it RC3 because there are no changes in source files from the
> last RC. The only difference is that I built from a fresh checkout of the
> RC2 svn tag.
>
> The changes from RC1 are what Sebb found:
> - EOL in sources
> - Cruft from a dirty build, so I built this RC as I should have the first
> time around with:
> - mvn clean
> - mvn deploy -Prelease
>
> Tag:
>
> https://svn.apache.org/repos/asf/commons/proper/codec/tags/commons-codec
> -1.6-RC2
>
> Site:
>
> https://people.apache.org/builds/commons/codec/1.6/RC2/
>
> Binaries:
>
> 
> https://repository.apache.org/content/repositories/orgapachecommons-290/
>
> The link above includes checksum files.
>
> [ ] +1 release it
> [ ] +0 go ahead, I cannot take the time
> [ ] -1 no, do not release it because:
>
> This VOTE is open for 72 hours, until November 23 2011, 14:00 EST.
>
> Fixed Bugs:
> o Use standard Maven directory layout.  Issue: CODEC-129. Thanks to
> ggregory.
> o Documentation spelling fixes.  Issue: CODEC-128. Thanks 
> toville.sky...@iki.fi
> .
> o Fix various character encoding issues in comments and test cases.
> Issue: CODEC-127.
> o ColognePhonetic Javadoc should use HTML entities for special characters.
> Issue: CODEC-123.
>
> Changes:
> o Implement a Beider-Morse phonetic matching codec.  Issue: CODEC-125.
> Thanks to Matthew Pocock.
> o Migrate to Java 5.  Issue: CODEC-119.
> o Migrate to JUnit 4.  Issue: CODEC-120.
>
> Heads up: the Beider-Morse encoder tests take a long time to run (5
> minutes). The code has been optimized.
>
> Thank you,
> Gary
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory 
>



-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE][Codec] Release Commons Codec 1.6-RC2 REDUX

On Sun, Dec 4, 2011 at 3:24 PM, Oliver Heger
wrote:

> Am 03.12.2011 22:14, schrieb Gary Gregory:
>
>> On Sat, Dec 3, 2011 at 3:14 PM, Oliver Heger
>> **wrote:
>>
>>  Am 03.12.2011 17:18, schrieb Gary Gregory:
>>>
>>>  On Sat, Dec 3, 2011 at 5:45 AM, Oliver Heger
 wrote:


  When building I get a heap space error in testSpeedCheck(org.apache.**

> commons.codec.language.bm.**BeiderMorseEncoderTest), even when
> setting
>
>
> MAVEN_OPTS=-Xmx1024m. I remember there was discussion about this for
> the
> last RC. Which amount of memory is required?
>
>
>  Try bumping up your MaxPermSize, for example:

 MAVEN_OPTS=-XX:MaxPermSize=256m -Xmx1024m


>>> No luck either. As the error message indicates, the problem really seems
>>> to be related to heap size (AFAIK you get a specific perm gen error
>>> message
>>> otherwise). I get the same error message up to 1400 MB heap space.
>>> Unfortunately, I cannot increase my heap size beyond this value because I
>>> reach the limit of my physical memory. For a unit test these seem to be
>>> tough requirements.
>>>
>>>
>> If I turn /off/ MAVEN_OPTS (set MAVEN_OPTS=) it still works for me, so
>> that's good. I tied the 'mvn test' and 'mvn site'.
>>
>> After running site, Maven reports:
>>
>> [INFO] Final Memory: 43M/143M
>>
>
> Did some more testing: the build runs fine for me with Java 1.6, but the
> heap space error occurs on Java 1.5 (on Windows 7). Any idea what could be
> the source of this problem?
>

I am good on Java 5 and Windows 7, so I am not sure how to help here.

[INFO]

[INFO] BUILD SUCCESS
[INFO]

[INFO] Total time: 45.467s
[INFO] Finished at: Mon Dec 05 16:59:48 EST 2011
[INFO] Final Memory: 15M/65M
[INFO]

C:\temp\codec>m3 -version
Apache Maven 3.0.3 (r1075438; 2011-02-28 12:31:09-0500)
Maven home: C:\Java\apache-maven-3.0.3\bin\..
Java version: 1.5.0_22, vendor: Sun Microsystems Inc.
Java home: C:\Program Files\Java\jdk1.5.0_22\jre
Default locale: en_US, platform encoding: Cp1252
OS name: "windows 7", version: "6.1", arch: "amd64", family: "windows"

Gary

>
> Oliver
>
>
>> Gary
>>
>>
>>
>>> Oliver
>>>
>>>
>>>  Gary



  Otherwise, I did not find major problems. The site has two checkstyle
> links: one is clean, the other contains errors.
>
> Oliver
>
> Am 03.12.2011 04:06, schrieb Gary Gregory:
>
>  Good day to you all:
>
>>
>> I have prepared Commons Codec 1.6-RC2, again, per Sebb's suggestion. I
>> am
>> not calling it RC3 because there are no changes in source files from
>> the
>> last RC. The only difference is that I built from a fresh checkout of
>> the
>> RC2 svn tag.
>>
>> The changes from RC1 are what Sebb found:
>> - EOL in sources
>> - Cruft from a dirty build, so I built this RC as I should have the
>> first
>> time around with:
>> - mvn clean
>> - mvn deploy -Prelease
>>
>> Tag:
>>
>> https://svn.apache.org/repos/**asf/commons/proper/codec/
>> tags/**
>> 
>> >
>> commons-codec
>> proper/codec/tags/commons-codec> repos/asf/commons/proper/**codec/tags/commons-codec
>> >
>>
>>>
>>>  -1.6-RC2
>>
>> Site:
>>
>> https://people.apache.org/**builds/commons/codec/1.6/RC2/
>> <**https://people.apache.org/builds/commons/codec/1.6/RC2/
>> >
>> <**https://people.apache.org/builds/commons/codec/1.6/RC2/
>> **
>> >
>>
>>>
>>>
>> Binaries:
>>
>> > orgapachecommons-224/
>> repositories/orgapachecommons-224/> apache.org/content/**repositories/orgapachecommons-**224/
>> >
>>
>>>
>>>
>>
>>>
>>>  
>>> https://repository.apache.org/**content/re

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 1:39 PM, Christian Grobmeier  wrote:
> On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson  wrote:
>> I think all that Sebastian is saying is something like "if you can
>> create your new, cool API and the only things you really miss from
>> Java 6 are @Override on interface implementation methods and
>> ServiceLoader, for example, maybe it's worth that tiny bit of extra
>> pain to reach that slightly larger audience."  We all feel frustrated
>> from time to time working in the community setting; I've been there
>> myself, but I don't think Seb is just trying to be a killjoy just for
>> the hell of it.
>
> Yes, you might be right on this interpretation.
>
> As long as there a volunteers for maintaining jexl2 on j5 setting, I
> am fine with keeping j5 for it. To be clear, I am not saying we kill
> jexl2 today or quit jdk5 support for jexl2.
>
> But we should not make it a policy to start a new, major version with
> the lowest JDK version possible when the actual maintainers would like
> to use a current platform - this needs no discussion imho, they should
> simply do as they please.

I agree that the developers of a component should do as they
[collectively] please.  However, in the case of [jexl] it appears that
Seb is interested in the development of this component.  He may
continue to be interested in the development of a v3.x of [jexl].  Now
we don't have as clear-cut a case of do-ocracy and henrib just doing
what he pleases anymore, because he has to do instead "as near as he
can get to what he pleases while still functioning in a
consensus-based manner."  A possible sequence of events:

  - henrib proposes that [jexl] include feature X, using feature Y
from Java 6, thus justifying this minimum version.  Assuming the
community doesn't vote down the feature on its own merits, Java 6 it
is.
 - sebb can then come along say, hey, I know we agreed on feature X,
but I can put in 4 hours of work or create a new Commons component to
reimplement feature Y, and now Java 5 users can also benefit from
[jexl] 3!

Assuming someone else is willing to do the *actual* work required to
keep Java 5 compatibility, are you really going to spend time and
energy fighting for interface @Overrides?  Obviously there would
probably be some point at which Seb in this example would say, sure, I
could reimplement feature Y, but it's going to take ten hours, twenty
hours.  Not worth it; have your Java 6!

This is the way I see our community as having to function.

Matt

>
> Cheers
>
>>
>> Matt
>>
>> On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier  
>> wrote:
>>> On Mon, Dec 5, 2011 at 7:38 PM, sebb  wrote:
 On 5 December 2011 18:10, henrib  wrote:
> sebb-2-2 wrote
>>
>> My view is that while there is still a need for software to be able to
>> run on Java 1.5, we should not insist on requiring a minimum of
>> 1.6.*unless* there is good technical reason for doing so.
>>
> But you don't consider a good (technical) reason the fact that the
> contributor can not/does not want to incur the cost of maintaining a JDK 
> 1.5
> on its dev platforms to be able to contribute to newer versions...

 No, I don't consider that a valid reason on its own.
>>>
>>> Committing should be fun. If one does not want to support JDK 1.5 he
>>> goes away. Henri seems as he does not want and would like to put
>>> effort in a more modern environment. In addition, how many people can
>>> you attract with a JDK 1.5 version to contribute? For me this is valid
>>> reason.
>>>
> And no-one is stating that Java 1.5 is not in used in production 
> somewhere;
> but IMHO, these are not the ones that will be JEXL3 users, especially 
> since
> they have 2.1 (soon).

> Anyway and beyond the point, my advice to 1.5 users is that before trying 
> to
> use "new" versions of libraries, migrating away from an unsupported/EOLed
> platform should be their priority.

 Indeed, ideally everyone would now be using Java 6 and Windows users
 should all upgrade to Windows 7 etc.

 But that is a separate issue.
>>>
>>> No it is not.
>>>
>>> It seems you ignore my idea on having jexl2 in maintenance mode, but
>>> this is actually what MS did with Win XP. Now they don't support it. I
>>> ask myself, why do we need to support outdated jdks until all
>>> committers are gone away or the library is the outdated people get
>>> some fresher stuff (Collections vs Guava)?
>>>
>>> If Henri is the opinion that people should use jdk6 he should be
>>> allowed to create such a version and call it Jexl3.
>>> If you want to keep a jdk5 version, you are of course allowed to
>>> support that one.
>>>
>>> Cheers
>>> Christian
>>>

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

>>>
>>>
>>>
>>> --
>>> http://www.grob

[VOTE][email] Release Commons Email 1.3 based on RC2

2011-12-05 Thread Siegfried Goeschl


Hi folks,

I would like to call a vote to release commons-email-1.3 which contains 
the following bug fixes and improvements found here


http://people.apache.org/builds/commons/email/1.3/RC2/site/changes-report.html

Tag:

https://svn.apache.org/repos/asf/commons/proper/email/tags/EMAIL_1_3_RC2

Site:

http://people.apache.org/builds/commons/email/1.3/RC2/site/index.html

Binaries:

http://people.apache.org/builds/commons/email/1.3/RC2/staged/org/apache/commons/commons-email/1.3/

[ ] +1 release it
[ ] +0 go ahead I don't care
[ ] -1 no, do not release it because

Thanks in advance

Siegfried Goeschl

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)


sebb-2-2 wrote
> 
> 
>> But even if it were the case, you'd still argue for us to continue using
>> IE6...
> 
> No, I would not; that's an end-user product.
> 
> 
I see it as the worst web app client platform... Even on that, we can't
agree! 
(sorry, couldn't resist :-)...)


--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161935.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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On 5 December 2011 19:01, henrib  wrote:
>
> sebb-2-2 wrote
>>
>> Indeed, ideally everyone would now be using Java 6 and Windows users
>> should all upgrade to Windows 7 etc.
>>
> But even if it were the case, you'd still argue for us to continue using
> IE6...

No, I would not; that's an end-user product.


> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161736.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: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 8:22 PM, Matt Benson  wrote:
> I think all that Sebastian is saying is something like "if you can
> create your new, cool API and the only things you really miss from
> Java 6 are @Override on interface implementation methods and
> ServiceLoader, for example, maybe it's worth that tiny bit of extra
> pain to reach that slightly larger audience."  We all feel frustrated
> from time to time working in the community setting; I've been there
> myself, but I don't think Seb is just trying to be a killjoy just for
> the hell of it.

Yes, you might be right on this interpretation.

As long as there a volunteers for maintaining jexl2 on j5 setting, I
am fine with keeping j5 for it. To be clear, I am not saying we kill
jexl2 today or quit jdk5 support for jexl2.

But we should not make it a policy to start a new, major version with
the lowest JDK version possible when the actual maintainers would like
to use a current platform - this needs no discussion imho, they should
simply do as they please.

Cheers

>
> Matt
>
> On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier  
> wrote:
>> On Mon, Dec 5, 2011 at 7:38 PM, sebb  wrote:
>>> On 5 December 2011 18:10, henrib  wrote:
 sebb-2-2 wrote
>
> My view is that while there is still a need for software to be able to
> run on Java 1.5, we should not insist on requiring a minimum of
> 1.6.*unless* there is good technical reason for doing so.
>
 But you don't consider a good (technical) reason the fact that the
 contributor can not/does not want to incur the cost of maintaining a JDK 
 1.5
 on its dev platforms to be able to contribute to newer versions...
>>>
>>> No, I don't consider that a valid reason on its own.
>>
>> Committing should be fun. If one does not want to support JDK 1.5 he
>> goes away. Henri seems as he does not want and would like to put
>> effort in a more modern environment. In addition, how many people can
>> you attract with a JDK 1.5 version to contribute? For me this is valid
>> reason.
>>
 And no-one is stating that Java 1.5 is not in used in production somewhere;
 but IMHO, these are not the ones that will be JEXL3 users, especially since
 they have 2.1 (soon).
>>>
 Anyway and beyond the point, my advice to 1.5 users is that before trying 
 to
 use "new" versions of libraries, migrating away from an unsupported/EOLed
 platform should be their priority.
>>>
>>> Indeed, ideally everyone would now be using Java 6 and Windows users
>>> should all upgrade to Windows 7 etc.
>>>
>>> But that is a separate issue.
>>
>> No it is not.
>>
>> It seems you ignore my idea on having jexl2 in maintenance mode, but
>> this is actually what MS did with Win XP. Now they don't support it. I
>> ask myself, why do we need to support outdated jdks until all
>> committers are gone away or the library is the outdated people get
>> some fresher stuff (Collections vs Guava)?
>>
>> If Henri is the opinion that people should use jdk6 he should be
>> allowed to create such a version and call it Jexl3.
>> If you want to keep a jdk5 version, you are of course allowed to
>> support that one.
>>
>> Cheers
>> Christian
>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> -
>> 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
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)


Matt Benson-2 wrote
> 
> ... maybe it's worth that tiny bit of extra pain to reach that slightly
> larger audience...
> 
It is not a tiny bit when you accumulate it; and JEXL3 would not reach a
larger audience because it allows deployment on Java 1.5. This is a wrongly
imposed cost with no benefit.


--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161848.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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

I think all that Sebastian is saying is something like "if you can
create your new, cool API and the only things you really miss from
Java 6 are @Override on interface implementation methods and
ServiceLoader, for example, maybe it's worth that tiny bit of extra
pain to reach that slightly larger audience."  We all feel frustrated
from time to time working in the community setting; I've been there
myself, but I don't think Seb is just trying to be a killjoy just for
the hell of it.

Matt

On Mon, Dec 5, 2011 at 1:13 PM, Christian Grobmeier  wrote:
> On Mon, Dec 5, 2011 at 7:38 PM, sebb  wrote:
>> On 5 December 2011 18:10, henrib  wrote:
>>> sebb-2-2 wrote

 My view is that while there is still a need for software to be able to
 run on Java 1.5, we should not insist on requiring a minimum of
 1.6.*unless* there is good technical reason for doing so.

>>> But you don't consider a good (technical) reason the fact that the
>>> contributor can not/does not want to incur the cost of maintaining a JDK 1.5
>>> on its dev platforms to be able to contribute to newer versions...
>>
>> No, I don't consider that a valid reason on its own.
>
> Committing should be fun. If one does not want to support JDK 1.5 he
> goes away. Henri seems as he does not want and would like to put
> effort in a more modern environment. In addition, how many people can
> you attract with a JDK 1.5 version to contribute? For me this is valid
> reason.
>
>>> And no-one is stating that Java 1.5 is not in used in production somewhere;
>>> but IMHO, these are not the ones that will be JEXL3 users, especially since
>>> they have 2.1 (soon).
>>
>>> Anyway and beyond the point, my advice to 1.5 users is that before trying to
>>> use "new" versions of libraries, migrating away from an unsupported/EOLed
>>> platform should be their priority.
>>
>> Indeed, ideally everyone would now be using Java 6 and Windows users
>> should all upgrade to Windows 7 etc.
>>
>> But that is a separate issue.
>
> No it is not.
>
> It seems you ignore my idea on having jexl2 in maintenance mode, but
> this is actually what MS did with Win XP. Now they don't support it. I
> ask myself, why do we need to support outdated jdks until all
> committers are gone away or the library is the outdated people get
> some fresher stuff (Collections vs Guava)?
>
> If Henri is the opinion that people should use jdk6 he should be
> allowed to create such a version and call it Jexl3.
> If you want to keep a jdk5 version, you are of course allowed to
> support that one.
>
> Cheers
> Christian
>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> 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: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 7:38 PM, sebb  wrote:
> On 5 December 2011 18:10, henrib  wrote:
>> sebb-2-2 wrote
>>>
>>> My view is that while there is still a need for software to be able to
>>> run on Java 1.5, we should not insist on requiring a minimum of
>>> 1.6.*unless* there is good technical reason for doing so.
>>>
>> But you don't consider a good (technical) reason the fact that the
>> contributor can not/does not want to incur the cost of maintaining a JDK 1.5
>> on its dev platforms to be able to contribute to newer versions...
>
> No, I don't consider that a valid reason on its own.

Committing should be fun. If one does not want to support JDK 1.5 he
goes away. Henri seems as he does not want and would like to put
effort in a more modern environment. In addition, how many people can
you attract with a JDK 1.5 version to contribute? For me this is valid
reason.

>> And no-one is stating that Java 1.5 is not in used in production somewhere;
>> but IMHO, these are not the ones that will be JEXL3 users, especially since
>> they have 2.1 (soon).
>
>> Anyway and beyond the point, my advice to 1.5 users is that before trying to
>> use "new" versions of libraries, migrating away from an unsupported/EOLed
>> platform should be their priority.
>
> Indeed, ideally everyone would now be using Java 6 and Windows users
> should all upgrade to Windows 7 etc.
>
> But that is a separate issue.

No it is not.

It seems you ignore my idea on having jexl2 in maintenance mode, but
this is actually what MS did with Win XP. Now they don't support it. I
ask myself, why do we need to support outdated jdks until all
committers are gone away or the library is the outdated people get
some fresher stuff (Collections vs Guava)?

If Henri is the opinion that people should use jdk6 he should be
allowed to create such a version and call it Jexl3.
If you want to keep a jdk5 version, you are of course allowed to
support that one.

Cheers
Christian

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

-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)


sebb-2-2 wrote
> 
> Indeed, ideally everyone would now be using Java 6 and Windows users
> should all upgrade to Windows 7 etc.
> 
But even if it were the case, you'd still argue for us to continue using
IE6...

--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161736.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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On 5 December 2011 18:10, henrib  wrote:
>
> sebb-2-2 wrote
>>
>> My view is that while there is still a need for software to be able to
>> run on Java 1.5, we should not insist on requiring a minimum of
>> 1.6.*unless* there is good technical reason for doing so.
>>
> But you don't consider a good (technical) reason the fact that the
> contributor can not/does not want to incur the cost of maintaining a JDK 1.5
> on its dev platforms to be able to contribute to newer versions...

No, I don't consider that a valid reason on its own.

> And no-one is stating that Java 1.5 is not in used in production somewhere;
> but IMHO, these are not the ones that will be JEXL3 users, especially since
> they have 2.1 (soon).

> Anyway and beyond the point, my advice to 1.5 users is that before trying to
> use "new" versions of libraries, migrating away from an unsupported/EOLed
> platform should be their priority.

Indeed, ideally everyone would now be using Java 6 and Windows users
should all upgrade to Windows 7 etc.

But that is a separate issue.

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On 5 December 2011 18:30, ralph.goers @dslextreme.com
 wrote:
> FWIW, I have been planning on starting work on vfs3 when I finish up with
> some other stuff. VFS3 will require Java 7 as Java 7 provides virtual file
> support, so vfs3 will be slimmed down to just provide implementations.

That's again a bit different.

VFS3 will effectively then be a different component, addressing a
completely different user base.

> Ralph
>
> On Mon, Dec 5, 2011 at 9:51 AM, sebb  wrote:
>
>> On 5 December 2011 16:46, henrib  wrote:
>> > You summed it up pretty well;
>> > Can we participate in moving forward  - Java6 is not really the bleeding
>> > edge... - or are we bound to remain on obsolete platforms with Commons ?
>>
>> That is not a question I can answer, because it's not a simple
>> dichotomy (if that's the correct word).
>>
>> It's not my view that all Commons components have to remain on 1.5
>> until no-one else is using that release.
>> Nor is it my view that all Commons components should immediately be
>> able to switch to 1.6.
>>
>> My view is that while there is still a need for software to be able to
>> run on Java 1.5, we should not insist on requiring a minimum of
>> 1.6.*unless* there is good technical reason for doing so.
>>
>> I've yet to see that argument put forward; nor has anyone produced
>> evidence that Java 1.5 is not still being used in production across
>> the user base.
>>
>> >
>> >
>> > --
>> > View this message in context:
>> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161262.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
>>
>>

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

2011-12-05 Thread ralph.goers @dslextreme.com

FWIW, I have been planning on starting work on vfs3 when I finish up with
some other stuff. VFS3 will require Java 7 as Java 7 provides virtual file
support, so vfs3 will be slimmed down to just provide implementations.

Ralph

On Mon, Dec 5, 2011 at 9:51 AM, sebb  wrote:

> On 5 December 2011 16:46, henrib  wrote:
> > You summed it up pretty well;
> > Can we participate in moving forward  - Java6 is not really the bleeding
> > edge... - or are we bound to remain on obsolete platforms with Commons ?
>
> That is not a question I can answer, because it's not a simple
> dichotomy (if that's the correct word).
>
> It's not my view that all Commons components have to remain on 1.5
> until no-one else is using that release.
> Nor is it my view that all Commons components should immediately be
> able to switch to 1.6.
>
> My view is that while there is still a need for software to be able to
> run on Java 1.5, we should not insist on requiring a minimum of
> 1.6.*unless* there is good technical reason for doing so.
>
> I've yet to see that argument put forward; nor has anyone produced
> evidence that Java 1.5 is not still being used in production across
> the user base.
>
> >
> >
> > --
> > View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161262.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: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)


sebb-2-2 wrote
> 
> My view is that while there is still a need for software to be able to
> run on Java 1.5, we should not insist on requiring a minimum of
> 1.6.*unless* there is good technical reason for doing so.
> 
But you don't consider a good (technical) reason the fact that the
contributor can not/does not want to incur the cost of maintaining a JDK 1.5
on its dev platforms to be able to contribute to newer versions...
And no-one is stating that Java 1.5 is not in used in production somewhere;
but IMHO, these are not the ones that will be JEXL3 users, especially since
they have 2.1 (soon).
Anyway and beyond the point, my advice to 1.5 users is that before trying to
use "new" versions of libraries, migrating away from an unsupported/EOLed
platform should be their priority.



--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161571.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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 6:51 PM, sebb  wrote:
> On 5 December 2011 16:46, henrib  wrote:
>> You summed it up pretty well;
>> Can we participate in moving forward  - Java6 is not really the bleeding
>> edge... - or are we bound to remain on obsolete platforms with Commons ?
>
> That is not a question I can answer, because it's not a simple
> dichotomy (if that's the correct word).
>
> It's not my view that all Commons components have to remain on 1.5
> until no-one else is using that release.
> Nor is it my view that all Commons components should immediately be
> able to switch to 1.6.
>
> My view is that while there is still a need for software to be able to
> run on Java 1.5, we should not insist on requiring a minimum of
> 1.6.*unless* there is good technical reason for doing so.
>
> I've yet to see that argument put forward; nor has anyone produced
> evidence that Java 1.5 is not still being used in production across
> the user base.

Hey what is wrong with doing jexl3 with Java 6?
Why do we need to satisfy to use current technology (guess its already
j7 out there)?
I mean, the proposal is to upgrade the requirements with a version bump.

What is the problem with:
- Jexl 2 going maintenance and bugfix mode only, using j5
- Jexl 3 going to have j6 (to the joy of its developers) and doing all
the new fancy stuff

I do not think we have to clarify why we go to j6, we have to clarify
why we still stick to j5 when we do a major version bump.

Probably there is need for j5 software - these users can benefit from
jexl2. If maintenance mode is not enough I ask myself why we don't
still support Java 1.4. I mean, recently I saw it live (guess, at a
bank).

Imho Commons must not always be the most conservative place ever. We
should progress a little more or after all we have only the banks as
users, because the modern guys go with all that modern stuff.

Of course if you volunteer to migrate all the jexl3 things to jexl2,
please go ahead and do it. But this should not force Henri to develop
in j6. I mean one team, one dream, but how can you attract new
developers with java5 nowadays?

Cheers

>
>>
>>
>> --
>> View this message in context: 
>> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161262.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
>

-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 6:44 PM, ralph.goers @dslextreme.com
 wrote:
> +1 to the proposal.
>
> As for moving out of commons I would expect that it would require a vote of
> the Commons PMC with approval from the board. I don't know why it would
> need to go through the incubator since it would have already performed
> releases here, its IP would already be cleared and presumably we would only
> make the proposal if it already had a community of its own.

I said it only because of the "community building aspect". A new tld
would be required and a working PMC must be setup. If this is would be
clear from the beginning I agree. Actually if this step would be
required, I would try to avoid the incubator as much as I can

>
> Ralph
>
> On Mon, Dec 5, 2011 at 6:17 AM, henrib  wrote:
>
>> Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
>> little forward...
>>
>> Since a 2-person opposition never breaks the tie, a vote is in order to
>> decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123)
>> can actually break loose of Java 1.5 compatibility. (sic)
>>
>> JEXL3 is intended to be a next major release of JEXL that cleans up the
>> API,
>> making sure the internal/public contract is crystal clear. Since it is a
>> major revamp of the API, JEXL3 is intended to be used by new/active
>> projects
>> that will be deployed on Java6 / Java7. To avoid some development cost,
>> I've
>> "blatantly" crossed another rule without much thinking by requiring Java6
>> for JEXL3 (instead of Java5 which is EOL).
>>
>> Since JEXL2.1 - aka the next imminent version of jexl2 - already targets
>> Java 1.5, I did not think it would start yet another fight with the release
>> police. Was I wrong... "Why can't you supporting a EOL-ed platform for a
>> new
>> version of the project?". (Because it's not a freebie for me but no
>> matter).
>>
>> So, here we are again for some bickering and vote:
>> [+1] Yes, you may release the next major release of JEXL3 with a Java6
>> requirement
>> [-1] No, this is an important case/issue/matter/rule that we continue
>> supporting Java 1.5
>> [0]  Don't care
>>
>> Many thanks to those who will vote for their time and patience;
>> Henrib
>>
>> PS: Is there a process to formally move a project from Commons to elsewhere
>> within Apache?
>>
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.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
>>
>>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On 5 December 2011 16:46, henrib  wrote:
> You summed it up pretty well;
> Can we participate in moving forward  - Java6 is not really the bleeding
> edge... - or are we bound to remain on obsolete platforms with Commons ?

That is not a question I can answer, because it's not a simple
dichotomy (if that's the correct word).

It's not my view that all Commons components have to remain on 1.5
until no-one else is using that release.
Nor is it my view that all Commons components should immediately be
able to switch to 1.6.

My view is that while there is still a need for software to be able to
run on Java 1.5, we should not insist on requiring a minimum of
1.6.*unless* there is good technical reason for doing so.

I've yet to see that argument put forward; nor has anyone produced
evidence that Java 1.5 is not still being used in production across
the user base.

>
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161262.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: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

2011-12-05 Thread ralph.goers @dslextreme.com

+1 to the proposal.

As for moving out of commons I would expect that it would require a vote of
the Commons PMC with approval from the board. I don't know why it would
need to go through the incubator since it would have already performed
releases here, its IP would already be cleared and presumably we would only
make the proposal if it already had a community of its own.

Ralph

On Mon, Dec 5, 2011 at 6:17 AM, henrib  wrote:

> Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
> little forward...
>
> Since a 2-person opposition never breaks the tie, a vote is in order to
> decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123)
> can actually break loose of Java 1.5 compatibility. (sic)
>
> JEXL3 is intended to be a next major release of JEXL that cleans up the
> API,
> making sure the internal/public contract is crystal clear. Since it is a
> major revamp of the API, JEXL3 is intended to be used by new/active
> projects
> that will be deployed on Java6 / Java7. To avoid some development cost,
> I've
> "blatantly" crossed another rule without much thinking by requiring Java6
> for JEXL3 (instead of Java5 which is EOL).
>
> Since JEXL2.1 - aka the next imminent version of jexl2 - already targets
> Java 1.5, I did not think it would start yet another fight with the release
> police. Was I wrong... "Why can't you supporting a EOL-ed platform for a
> new
> version of the project?". (Because it's not a freebie for me but no
> matter).
>
> So, here we are again for some bickering and vote:
> [+1] Yes, you may release the next major release of JEXL3 with a Java6
> requirement
> [-1] No, this is an important case/issue/matter/rule that we continue
> supporting Java 1.5
> [0]  Don't care
>
> Many thanks to those who will vote for their time and patience;
> Henrib
>
> PS: Is there a process to formally move a project from Commons to elsewhere
> within Apache?
>
>
>
>
>
>
>
> --
> View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.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
>
>

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

You summed it up pretty well;
Can we participate in moving forward  - Java6 is not really the bleeding
edge... - or are we bound to remain on obsolete platforms with Commons ?



--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161262.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

Re: [RELEASE PROCESS] Stability versus usability

About the *internal* and @internal (package & annotation);
Of course if we could come up with a "binding" convention on the source
layout and package name for all projects, it would be really nice (i.e. the
*internal* package convention). 
(Oh, a common pom where only the source/test/site would be specific and
allow automated reports and release vote publication... just dreaming out
loud)

But as a pragmatist, I'd rather have the @internal annotation that can serve
as an intermediate, easy to use way to determine stability (both for the dev
and the user) than nothing that slows down release cycles to a crawl;
forcing projects to align on a source layout convention is likely bound to
fail or at least a very (very very) long path. 

One of the goal is to allow at least easier - if not faster - release
cycles; as devs, we'd be made easily aware that we are tinkering with the
API contract and for release voting, it gets easier to control that we've
not unintentionally screwed it up.

Oh, and I do agree on the immutability / thread safety doc. :-)
Cheers,
Henrib



--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4161225.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

Re: [RELEASE PROCESS] Stability versus usability

On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory  wrote:
> Personally, I do not like annotations to describe the stability of an API.
>
> If it's public I can use it. The next release is binary and/or source
> compatible, just document how to migrate. No one is forcing me to upgrade.
> If I upgrade, I am using a new pile of code and I must deal with that.
>
> Using ".internal" packages is an interesting way to go.

It is fine, using annotations is not really a "must have" for me. I
think similar stuff like ".internal" do the Cayenne developers.

> But I do like documentation of some kind for things like immutability and
> thread-safety.

+1

> We've started going down the path of what I call "extreme versioning" when
> we create new packages for new incompatible releases.
>
> Right now, binary incompatible -> new package (I'm even going to include
> Maven artifact ID noise here).
>
> But what about a change in behavior that is not compatible? Should that not
> lead to a new package?

Honestly, no clue.

What do you think on making up some good interfaces for a components.
For example, a "Compress" interface set for version 1. If we decide to
change something, no problem - interfaces stay the same. When the
interfaces change, the version number changes and this will probably
lead to a packagename change.

I would hate to see o.a.c.compress_2_1.bla btw. ;-)

> Commons is a 'special' project because it includes so many components. It
> would be nice if all components played by the same rules. Strictly
> speaking, I think we are bound to do so.

Very much +1. There are so many differences. As a user I am totally
lost on all the different things people do.

Cheers

>
> Gary
>
> On Mon, Dec 5, 2011 at 10:21 AM, Christian Grobmeier 
> wrote:
>
>> Henri,
>>
>> I would love to see this as a Commons recommendation on the Wiki.
>> As Stefan mentioned, in Compress we have @experimental annons (I
>> actually added them).
>> I like the idea to make up a public, rarely to break interface api and
>> some not so public sometimes to break implementation. Maybe we should
>> even consider to create an interface jar and an implementation jar of
>> different versions. On the other hand this makes things complex - but
>> anyway
>>
>> Cheers
>> Christian
>>
>> On Sun, Dec 4, 2011 at 11:41 AM, henrib  wrote:
>> > Keeping track as it evolves based on feedback;
>> >
>> > Goal is to allow easy definition, usage and check of stable APIs.
>> > An annotation and a package naming convention allow the project
>> developer to
>> > clearly state when a class/method/field is not part of the stable
>> contract
>> > despite a public/protected declaration but only of the internal part of
>> the
>> > project.
>> >
>> > @internal annotated class/method or *internal* package mean "use this at
>> > your own maintenance cost"; those are not part of the "public" API. They
>> can
>> > be used and extended but are subject to change between versions without
>> > @deprecated annotations.
>> >
>> > Those annotations and conventions should allow feeding a clirr report
>> with
>> > the proper information to allow detection of unintended API breakage and
>> may
>> > even allow creating IDE plugins to warn about usage.
>> >
>> > --
>> > View this message in context:
>> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.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
>> >
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [RELEASE PROCESS] Stability versus usability

On 5 December 2011 15:42, Gary Gregory  wrote:
> Personally, I do not like annotations to describe the stability of an API.
>
> If it's public I can use it. The next release is binary and/or source
> compatible, just document how to migrate. No one is forcing me to upgrade.

If your component is part of a larger application that may not be
true, see below.

> If I upgrade, I am using a new pile of code and I must deal with that.

That's OK if your code is stand-alone at the end of the food chain,
and you have control over it.

Commons components often are deeply embedded.

> Using ".internal" packages is an interesting way to go.
>
> But I do like documentation of some kind for things like immutability and
> thread-safety.
>
> We've started going down the path of what I call "extreme versioning" when
> we create new packages for new incompatible releases.
>
> Right now, binary incompatible -> new package (I'm even going to include
> Maven artifact ID noise here).

See below for the reason why that is generally necessary.

> But what about a change in behavior that is not compatible? Should that not
> lead to a new package?

Depends why the behaviour changed. Is it a bug fix?

> Commons is a 'special' project because it includes so many components. It
> would be nice if all components played by the same rules. Strictly
> speaking, I think we are bound to do so.

I would say the Commons components are special because they are likely
to be deeply nested in applications, with many other components
depending on them.

It may not be possible to upgrade the other components all at once.
Some may be impossible to replace.
If two components in the same classpath need incompatible versions, it
will in general be impossible to update unless the two versions can
coexist.

That is why we have the rules on package/Maven id changes, so there
can be multiple versions of a Commons component on the same classpath,
if the need arises.

Because package changes are expensive to end users, we try to avoid
them if at all possible.

That is why it's worth striving for binary compatibility.

> Gary
>
> On Mon, Dec 5, 2011 at 10:21 AM, Christian Grobmeier 
> wrote:
>
>> Henri,
>>
>> I would love to see this as a Commons recommendation on the Wiki.
>> As Stefan mentioned, in Compress we have @experimental annons (I
>> actually added them).
>> I like the idea to make up a public, rarely to break interface api and
>> some not so public sometimes to break implementation. Maybe we should
>> even consider to create an interface jar and an implementation jar of
>> different versions. On the other hand this makes things complex - but
>> anyway
>>
>> Cheers
>> Christian
>>
>> On Sun, Dec 4, 2011 at 11:41 AM, henrib  wrote:
>> > Keeping track as it evolves based on feedback;
>> >
>> > Goal is to allow easy definition, usage and check of stable APIs.
>> > An annotation and a package naming convention allow the project
>> developer to
>> > clearly state when a class/method/field is not part of the stable
>> contract
>> > despite a public/protected declaration but only of the internal part of
>> the
>> > project.
>> >
>> > @internal annotated class/method or *internal* package mean "use this at
>> > your own maintenance cost"; those are not part of the "public" API. They
>> can
>> > be used and extended but are subject to change between versions without
>> > @deprecated annotations.
>> >
>> > Those annotations and conventions should allow feeding a clirr report
>> with
>> > the proper information to allow detection of unintended API breakage and
>> may
>> > even allow creating IDE plugins to warn about usage.
>> >
>> > --
>> > View this message in context:
>> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.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
>> >
>>
>>
>>
>> --
>> http://www.grobmeier.de
>> https://www.timeandbill.de
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
> JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
> Spring Batch in Action: http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory

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

Re: [RELEASE PROCESS] Stability versus usability

Hi Gary!

On Mon, Dec 5, 2011 at 4:42 PM, Gary Gregory  wrote:
> Personally, I do not like annotations to describe the stability of an API.
>
> If it's public I can use it. The next release is binary and/or source
> compatible, just document how to migrate. No one is forcing me to upgrade.
> If I upgrade, I am using a new pile of code and I must deal with that.
>
> Using ".internal" packages is an interesting way to go.
>

interesting stuff as well - I learnt a trick from Google Guice team
that developed internal stuff only[1] and then "obfuscate"[2] them in
the way most ides won't recognize for code completion, so users cannot
rely on internal APIs :P
I personally think that is a valid approach, just my 0.02 cents,
-Simo

[1] http://s.apache.org/dt7
[2] http://s.apache.org/yC

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Mon, Dec 5, 2011 at 4:43 PM, sebb  wrote:
> On 5 December 2011 15:06, Simone Tripodi  wrote:
>> Salut Henri,
>>
>> if you need the Java6 APIs to provide a fresh new set of APIs to JEXL
>> users, I would be +1.
>> We recently accepted Java6 in Apache Cocoon since Oracle announced
>> Java 5 SE EOL (End Of Life) since 2009.
>
> Cocoon is a slightly different case, as it's probably not embedded in
> other components as much as Commons components are.
>

nope, new Cocoon3 has small commons components as well that allow
users embed it in a commons-xxx style, take a look at Christian's
experience on his blog post[1]

>> Anyway I would to point you to a message in the ASF Tika ML[1] where
>> describing the pros and cons about moving to Java6 - I wonder how many
>> users would still require Java4/5 to run JEXL.
>
> Exactly - but I'm not sure we'll find that out by asking on the
> developer list, where one would expect people to install the new
> versions of Java as they come out.
>
> If the argument is that Jexl users don't need it to run on Java 1.5,
> then a better place to ask the question might be the user list.
>

agreed, but I guess HenriB concern is on dev side as well, the
implicit question sounds clear to me: "is there any objection in the
dev community?"

-Simo

[1] http://www.grobmeier.de/create-pdf-cocoon-3-struts-2-15112011.html

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

Forgot to add the vote will close in 72 hours, as per-usual rules.


--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4161054.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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 4:43 PM, sebb  wrote:
> On 5 December 2011 15:06, Simone Tripodi  wrote:
>> Salut Henri,
>>
>> if you need the Java6 APIs to provide a fresh new set of APIs to JEXL
>> users, I would be +1.
>> We recently accepted Java6 in Apache Cocoon since Oracle announced
>> Java 5 SE EOL (End Of Life) since 2009.
>
> Cocoon is a slightly different case, as it's probably not embedded in
> other components as much as Commons components are.

Java 5 EOL 2009? Thats 2 years. I mean, we can still make releases of
JEXL 2.x and fix bugs, while the new JEXL 3.x line supports a newer
Java and creates new features. I think this is how most software
vendors do it. Make the old line bugfix only and concentrate on the
new line with current platform.

>> Anyway I would to point you to a message in the ASF Tika ML[1] where
>> describing the pros and cons about moving to Java6 - I wonder how many
>> users would still require Java4/5 to run JEXL.
>
> Exactly - but I'm not sure we'll find that out by asking on the
> developer list, where one would expect people to install the new
> versions of Java as they come out.
>
> If the argument is that Jexl users don't need it to run on Java 1.5,
> then a better place to ask the question might be the user list.

Jexl users in need of 1.5 can still use the 2.x line. Where is the problem?
If we always ask about every of our steps we will never go forward.

Cheers

>
>
>> Break a leg, all the best,
>> Simo
>>
>> [1] http://lucene.472066.n3.nabble.com/support-of-Java-5-td3039517.html
>>
>> http://people.apache.org/~simonetripodi/
>> http://simonetripodi.livejournal.com/
>> http://twitter.com/simonetripodi
>> http://www.99soft.org/
>>
>>
>>
>> On Mon, Dec 5, 2011 at 3:17 PM, henrib  wrote:
>>> Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
>>> little forward...
>>>
>>> Since a 2-person opposition never breaks the tie, a vote is in order to
>>> decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123)
>>> can actually break loose of Java 1.5 compatibility. (sic)
>>>
>>> JEXL3 is intended to be a next major release of JEXL that cleans up the API,
>>> making sure the internal/public contract is crystal clear. Since it is a
>>> major revamp of the API, JEXL3 is intended to be used by new/active projects
>>> that will be deployed on Java6 / Java7. To avoid some development cost, I've
>>> "blatantly" crossed another rule without much thinking by requiring Java6
>>> for JEXL3 (instead of Java5 which is EOL).
>>>
>>> Since JEXL2.1 - aka the next imminent version of jexl2 - already targets
>>> Java 1.5, I did not think it would start yet another fight with the release
>>> police. Was I wrong... "Why can't you supporting a EOL-ed platform for a new
>>> version of the project?". (Because it's not a freebie for me but no matter).
>>>
>>> So, here we are again for some bickering and vote:
>>> [+1] Yes, you may release the next major release of JEXL3 with a Java6
>>> requirement
>>> [-1] No, this is an important case/issue/matter/rule that we continue
>>> supporting Java 1.5
>>> [0]  Don't care
>>>
>>> Many thanks to those who will vote for their time and patience;
>>> Henrib
>>>
>>> PS: Is there a process to formally move a project from Commons to elsewhere
>>> within Apache?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> View this message in context: 
>>> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.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
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 4:31 PM, Gary Gregory  wrote:
> On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier 
> wrote:
>
>> > [+1] Yes, you may release the next major release of JEXL3 with a Java6
>> > requirement
>>
>> I think the maintainers of a component can decide on their own which
>> jdk they want to support. If you want to support a newer Java with the
>> next big major version of JEXL I give you my +1. For me a major
>> version is allowed to break old rules and create new ones.
>>
>
> I agree.
>
> Gary
>

me too, that's why I started working on Digester3

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On 5 December 2011 15:06, Simone Tripodi  wrote:
> Salut Henri,
>
> if you need the Java6 APIs to provide a fresh new set of APIs to JEXL
> users, I would be +1.
> We recently accepted Java6 in Apache Cocoon since Oracle announced
> Java 5 SE EOL (End Of Life) since 2009.

Cocoon is a slightly different case, as it's probably not embedded in
other components as much as Commons components are.

> Anyway I would to point you to a message in the ASF Tika ML[1] where
> describing the pros and cons about moving to Java6 - I wonder how many
> users would still require Java4/5 to run JEXL.

Exactly - but I'm not sure we'll find that out by asking on the
developer list, where one would expect people to install the new
versions of Java as they come out.

If the argument is that Jexl users don't need it to run on Java 1.5,
then a better place to ask the question might be the user list.


> Break a leg, all the best,
> Simo
>
> [1] http://lucene.472066.n3.nabble.com/support-of-Java-5-td3039517.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Mon, Dec 5, 2011 at 3:17 PM, henrib  wrote:
>> Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
>> little forward...
>>
>> Since a 2-person opposition never breaks the tie, a vote is in order to
>> decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123)
>> can actually break loose of Java 1.5 compatibility. (sic)
>>
>> JEXL3 is intended to be a next major release of JEXL that cleans up the API,
>> making sure the internal/public contract is crystal clear. Since it is a
>> major revamp of the API, JEXL3 is intended to be used by new/active projects
>> that will be deployed on Java6 / Java7. To avoid some development cost, I've
>> "blatantly" crossed another rule without much thinking by requiring Java6
>> for JEXL3 (instead of Java5 which is EOL).
>>
>> Since JEXL2.1 - aka the next imminent version of jexl2 - already targets
>> Java 1.5, I did not think it would start yet another fight with the release
>> police. Was I wrong... "Why can't you supporting a EOL-ed platform for a new
>> version of the project?". (Because it's not a freebie for me but no matter).
>>
>> So, here we are again for some bickering and vote:
>> [+1] Yes, you may release the next major release of JEXL3 with a Java6
>> requirement
>> [-1] No, this is an important case/issue/matter/rule that we continue
>> supporting Java 1.5
>> [0]  Don't care
>>
>> Many thanks to those who will vote for their time and patience;
>> Henrib
>>
>> PS: Is there a process to formally move a project from Commons to elsewhere
>> within Apache?
>>
>>
>>
>>
>>
>>
>>
>> --
>> View this message in context: 
>> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.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
>

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

Re: [RELEASE PROCESS] Stability versus usability

Personally, I do not like annotations to describe the stability of an API.

If it's public I can use it. The next release is binary and/or source
compatible, just document how to migrate. No one is forcing me to upgrade.
If I upgrade, I am using a new pile of code and I must deal with that.

Using ".internal" packages is an interesting way to go.

But I do like documentation of some kind for things like immutability and
thread-safety.

We've started going down the path of what I call "extreme versioning" when
we create new packages for new incompatible releases.

Right now, binary incompatible -> new package (I'm even going to include
Maven artifact ID noise here).

But what about a change in behavior that is not compatible? Should that not
lead to a new package?

Commons is a 'special' project because it includes so many components. It
would be nice if all components played by the same rules. Strictly
speaking, I think we are bound to do so.

Gary

On Mon, Dec 5, 2011 at 10:21 AM, Christian Grobmeier wrote:

> Henri,
>
> I would love to see this as a Commons recommendation on the Wiki.
> As Stefan mentioned, in Compress we have @experimental annons (I
> actually added them).
> I like the idea to make up a public, rarely to break interface api and
> some not so public sometimes to break implementation. Maybe we should
> even consider to create an interface jar and an implementation jar of
> different versions. On the other hand this makes things complex - but
> anyway
>
> Cheers
> Christian
>
> On Sun, Dec 4, 2011 at 11:41 AM, henrib  wrote:
> > Keeping track as it evolves based on feedback;
> >
> > Goal is to allow easy definition, usage and check of stable APIs.
> > An annotation and a package naming convention allow the project
> developer to
> > clearly state when a class/method/field is not part of the stable
> contract
> > despite a public/protected declaration but only of the internal part of
> the
> > project.
> >
> > @internal annotated class/method or *internal* package mean "use this at
> > your own maintenance cost"; those are not part of the "public" API. They
> can
> > be used and extended but are subject to change between versions without
> > @deprecated annotations.
> >
> > Those annotations and conventions should allow feeding a clirr report
> with
> > the proper information to allow detection of unintended API breakage and
> may
> > even allow creating IDE plugins to warn about usage.
> >
> > --
> > View this message in context:
> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.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
> >
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier wrote:

> > [+1] Yes, you may release the next major release of JEXL3 with a Java6
> > requirement
>
> I think the maintainers of a component can decide on their own which
> jdk they want to support. If you want to support a newer Java with the
> next big major version of JEXL I give you my +1. For me a major
> version is allowed to break old rules and create new ones.
>

I agree.

Gary


>
> > PS: Is there a process to formally move a project from Commons to
> elsewhere
> > within Apache?
>
> What exactly do you mean? Make JEXL a top level project or move JEXL
> to another toplevel project? Or something completley different?
>
> To move JEXL out of here, i think you should make up a (good) proposal
> and vote on this list. I can imagine it would go to the incubator to
> build up an community. Anyway I tend to think a component should have
> a pretty good size to stand on its own.
>
> Cheers
> Christian
>
> >
> >
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.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
> >
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

Easy one: +1.

Gary

On Mon, Dec 5, 2011 at 10:14 AM, Christian Grobmeier wrote:

> > [+1] Yes, you may release the next major release of JEXL3 with a Java6
> > requirement
>
> I think the maintainers of a component can decide on their own which
> jdk they want to support. If you want to support a newer Java with the
> next big major version of JEXL I give you my +1. For me a major
> version is allowed to break old rules and create new ones.
>
> > PS: Is there a process to formally move a project from Commons to
> elsewhere
> > within Apache?
>
> What exactly do you mean? Make JEXL a top level project or move JEXL
> to another toplevel project? Or something completley different?
>
> To move JEXL out of here, i think you should make up a (good) proposal
> and vote on this list. I can imagine it would go to the incubator to
> build up an community. Anyway I tend to think a component should have
> a pretty good size to stand on its own.
>
> Cheers
> Christian
>
> >
> >
> >
> >
> >
> >
> >
> > --
> > View this message in context:
> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.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
> >
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
E-Mail: garydgreg...@gmail.com | ggreg...@apache.org
JUnit in Action, 2nd Ed: http://bit.ly/ECvg0
Spring Batch in Action: http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Re: [RELEASE PROCESS] Stability versus usability

+1 Christian this is a nice idea - maybe RetentionPolicy.SOURCE
annotations? (so we don't have to bring the dependency in each
component for runtime...)
Simo

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Mon, Dec 5, 2011 at 4:21 PM, Christian Grobmeier  wrote:
> Henri,
>
> I would love to see this as a Commons recommendation on the Wiki.
> As Stefan mentioned, in Compress we have @experimental annons (I
> actually added them).
> I like the idea to make up a public, rarely to break interface api and
> some not so public sometimes to break implementation. Maybe we should
> even consider to create an interface jar and an implementation jar of
> different versions. On the other hand this makes things complex - but
> anyway
>
> Cheers
> Christian
>
> On Sun, Dec 4, 2011 at 11:41 AM, henrib  wrote:
>> Keeping track as it evolves based on feedback;
>>
>> Goal is to allow easy definition, usage and check of stable APIs.
>> An annotation and a package naming convention allow the project developer to
>> clearly state when a class/method/field is not part of the stable contract
>> despite a public/protected declaration but only of the internal part of the
>> project.
>>
>> @internal annotated class/method or *internal* package mean "use this at
>> your own maintenance cost"; those are not part of the "public" API. They can
>> be used and extended but are subject to change between versions without
>> @deprecated annotations.
>>
>> Those annotations and conventions should allow feeding a clirr report with
>> the proper information to allow detection of unintended API breakage and may
>> even allow creating IDE plugins to warn about usage.
>>
>> --
>> View this message in context: 
>> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.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
>>
>
>
>
> --
> http://www.grobmeier.de
> https://www.timeandbill.de
>
> -
> 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 PROCESS] Stability versus usability

Henri,

I would love to see this as a Commons recommendation on the Wiki.
As Stefan mentioned, in Compress we have @experimental annons (I
actually added them).
I like the idea to make up a public, rarely to break interface api and
some not so public sometimes to break implementation. Maybe we should
even consider to create an interface jar and an implementation jar of
different versions. On the other hand this makes things complex - but
anyway

Cheers
Christian

On Sun, Dec 4, 2011 at 11:41 AM, henrib  wrote:
> Keeping track as it evolves based on feedback;
>
> Goal is to allow easy definition, usage and check of stable APIs.
> An annotation and a package naming convention allow the project developer to
> clearly state when a class/method/field is not part of the stable contract
> despite a public/protected declaration but only of the internal part of the
> project.
>
> @internal annotated class/method or *internal* package mean "use this at
> your own maintenance cost"; those are not part of the "public" API. They can
> be used and extended but are subject to change between versions without
> @deprecated annotations.
>
> Those annotations and conventions should allow feeding a clirr report with
> the proper information to allow detection of unintended API breakage and may
> even allow creating IDE plugins to warn about usage.
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/RELEASE-PROCESS-Stability-versus-usability-tp4150322p4156552.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
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

> [+1] Yes, you may release the next major release of JEXL3 with a Java6
> requirement

I think the maintainers of a component can decide on their own which
jdk they want to support. If you want to support a newer Java with the
next big major version of JEXL I give you my +1. For me a major
version is allowed to break old rules and create new ones.

> PS: Is there a process to formally move a project from Commons to elsewhere
> within Apache?

What exactly do you mean? Make JEXL a top level project or move JEXL
to another toplevel project? Or something completley different?

To move JEXL out of here, i think you should make up a (good) proposal
and vote on this list. I can imagine it would go to the incubator to
build up an community. Anyway I tend to think a component should have
a pretty good size to stand on its own.

Cheers
Christian

>
>
>
>
>
>
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.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
>



-- 
http://www.grobmeier.de
https://www.timeandbill.de

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

Re: [VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

Salut Henri,

if you need the Java6 APIs to provide a fresh new set of APIs to JEXL
users, I would be +1.
We recently accepted Java6 in Apache Cocoon since Oracle announced
Java 5 SE EOL (End Of Life) since 2009.

Anyway I would to point you to a message in the ASF Tika ML[1] where
describing the pros and cons about moving to Java6 - I wonder how many
users would still require Java4/5 to run JEXL.

Break a leg, all the best,
Simo

[1] http://lucene.472066.n3.nabble.com/support-of-Java-5-td3039517.html

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Mon, Dec 5, 2011 at 3:17 PM, henrib  wrote:
> Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
> little forward...
>
> Since a 2-person opposition never breaks the tie, a vote is in order to
> decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123)
> can actually break loose of Java 1.5 compatibility. (sic)
>
> JEXL3 is intended to be a next major release of JEXL that cleans up the API,
> making sure the internal/public contract is crystal clear. Since it is a
> major revamp of the API, JEXL3 is intended to be used by new/active projects
> that will be deployed on Java6 / Java7. To avoid some development cost, I've
> "blatantly" crossed another rule without much thinking by requiring Java6
> for JEXL3 (instead of Java5 which is EOL).
>
> Since JEXL2.1 - aka the next imminent version of jexl2 - already targets
> Java 1.5, I did not think it would start yet another fight with the release
> police. Was I wrong... "Why can't you supporting a EOL-ed platform for a new
> version of the project?". (Because it's not a freebie for me but no matter).
>
> So, here we are again for some bickering and vote:
> [+1] Yes, you may release the next major release of JEXL3 with a Java6
> requirement
> [-1] No, this is an important case/issue/matter/rule that we continue
> supporting Java 1.5
> [0]  Don't care
>
> Many thanks to those who will vote for their time and patience;
> Henrib
>
> PS: Is there a process to formally move a project from Commons to elsewhere
> within Apache?
>
>
>
>
>
>
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.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

[VOTE] Can the next version major version of a project require Java6? (i.e. drop Java 1.5)

Sorry to bug everyone again, I'm hopelessly trying to make Commons move a
little forward...

Since a 2-person opposition never breaks the tie, a vote is in order to
decide whether JEXL3 (aka the next major version after 2.1, see JEXL-123)
can actually break loose of Java 1.5 compatibility. (sic)

JEXL3 is intended to be a next major release of JEXL that cleans up the API,
making sure the internal/public contract is crystal clear. Since it is a
major revamp of the API, JEXL3 is intended to be used by new/active projects
that will be deployed on Java6 / Java7. To avoid some development cost, I've
"blatantly" crossed another rule without much thinking by requiring Java6
for JEXL3 (instead of Java5 which is EOL).

Since JEXL2.1 - aka the next imminent version of jexl2 - already targets
Java 1.5, I did not think it would start yet another fight with the release
police. Was I wrong... "Why can't you supporting a EOL-ed platform for a new
version of the project?". (Because it's not a freebie for me but no matter).

So, here we are again for some bickering and vote:
[+1] Yes, you may release the next major release of JEXL3 with a Java6
requirement
[-1] No, this is an important case/issue/matter/rule that we continue
supporting Java 1.5
[0] Don't care

Many thanks to those who will vote for their time and patience;
Henrib

PS: Is there a process to formally move a project from Commons to elsewhere
within Apache?

--
View this message in context:
http://apache-commons.680414.n4.nabble.com/VOTE-Can-the-next-version-major-version-of-a-project-require-Java6-i-e-drop-Java-1-5-tp4160635p4160635.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

Re: [jira] [Created] (JEXL-123) Redesign API for stability

On 5 December 2011 13:34, henrib  wrote:
> JSR-269: custom annotation processing hooks are available in Java6; say
> someones wants to develop an IDE plugin that checks whether usage of a
> class/field/method annotated by @internal is made from the same package and
> issue a warning in that case...

In that case, surely the plugin can target Java 1.6?

> JSR-199: convert a script / or part of a script as a "compiled" class;
> instead of going through ASM et al libraries, generate the Java code - Jexl
> templates - and compile it.

Is that going to be part of JEXL itself?
Again, if it is an add-on, that can require 1.6.

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

Re: [jira] [Created] (JEXL-123) Redesign API for stability

JSR-269: custom annotation processing hooks are available in Java6; say
someones wants to develop an IDE plugin that checks whether usage of a
class/field/method annotated by @internal is made from the same package and
issue a warning in that case...
JSR-199: convert a script / or part of a script as a "compiled" class;
instead of going through ASM et al libraries, generate the Java code - Jexl
templates - and compile it.

The real question is whether a project that seeks (5 years old) "novelty"
has a place within Commons; is there a way to move JEXL (at least from v3
up) somewhere else within Apache where the 1984-release-police is not
tempted to rule the world ?

--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4160457.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

Re: [Graph] Weighted as an interface

Hi Claudio,
so nice to see you are already deep in the spirit of the project! :)

> As for my suggestion on types, should I go for {{Weighted Number>}}?
> Note that I am also concerned about domain-specific requirements (e.g. all
> weights must be positive) that I would like to see implemented as
> "statically" as possible in the code. {{Number}} should give us quite enough
> freedom in that direction (e.g. one could later extend it with something
> like {{PositiveInteger}}).
>
> A more platonic alternative would be to have an abstract type of weight
> which 1. is comparable and 2. can be aggregated in some way (e.g. the weight
> of a path is the sum of weights of its edges). But I am probably going too
> far...
>
>

I think that is a valid idea, please don't stop and explore more! ;)

>>
>> Moreover, I start having the feeling the {{WeightedGraph}} is a
>> useless interface: it is enough marking the vertices/edges as weighted
>> depending on the problem... or not? At the end of the day,
>> {{WeightedGraph}} does nothing than having the the edges marked as
>> weighted, so Dijkstra signature changed as:
>>
>> > WE>>  WeightedPath  findShortestPath( G graph,  V source, V
>> target )
>>
>> still define well the input type, a graph wich relations are directed
>> edges and edges are weighted... WDYT?
>
>
> I agree, as long as there are no specific features of the graph that are
> independent on its vertices and edges. Another advantage: I won't bother
> later to add more speficic interfaces like {{EdgeWeightedGraph}} or
> {{VertexWeightedGraph}} ;-)
>

+1, please include that in a separate issue!
All the best, have a nice day!
Simo

> Ciao,
> Claudio

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/

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

Re: [Graph] Weighted as an interface

2011-12-05 Thread Claudio Squarcella


Hi,

thanks to both for your words! Please find comments below.

On 05/12/2011 10:01, Simone Tripodi wrote:

Hi Claudio,
what a pleasant surprise! :) I was hoping commons-graph would have
caught the interest of researchers on that field, I'm really happy you
would like to contribute!

I agree with your observations, please fill new issues on JIRA[1] and
feel free to provide patches, I'll process them ASAP :)


Alright, I'll find time later this week.

As for my suggestion on types, should I go for {{WeightedNumber>}}?
Note that I am also concerned about domain-specific requirements (e.g. 
all weights must be positive) that I would like to see implemented as 
"statically" as possible in the code. {{Number}} should give us quite 
enough freedom in that direction (e.g. one could later extend it with 
something like {{PositiveInteger}}).


A more platonic alternative would be to have an abstract type of weight 
which 1. is comparable and 2. can be aggregated in some way (e.g. the 
weight of a path is the sum of weights of its edges). But I am probably 
going too far...




Moreover, I start having the feeling the {{WeightedGraph}} is a
useless interface: it is enough marking the vertices/edges as weighted
depending on the problem... or not? At the end of the day,
{{WeightedGraph}} does nothing than having the the edges marked as
weighted, so Dijkstra signature changed as:

>  WeightedPath  findShortestPath( G graph,  V source, V
target )

still define well the input type, a graph wich relations are directed
edges and edges are weighted... WDYT?


I agree, as long as there are no specific features of the graph that are 
independent on its vertices and edges. Another advantage: I won't bother 
later to add more speficic interfaces like {{EdgeWeightedGraph}} or 
{{VertexWeightedGraph}} ;-)


Ciao,
Claudio



Looking forward for your contributions, can't wait for them! :)
Simo

[1] https://issues.apache.org/jira/browse/SANDBOX

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Mon, Dec 5, 2011 at 2:00 AM, James Carman  wrote:

Welcome!  Contributions (and the contributor) are always welcome.  In my
past life, I did quite a bit of graph programming to solve "business"
problems.  We used yfiles, though.  I hope to get around to playing with
[graph] someday too.  Please do submit a patch!
On Dec 4, 2011 6:43 PM, "Claudio Squarcella"
wrote:


Hello,

I have been reading the source in the past days and I found that the
concept of "weight" (e.g. weighted edge, graph, etc) could benefit from a
bit of abstraction.

The basic idea would be to have an interface called Weighted with an
obvious method getWeight(). Changes in the code would easily derive from
that. As a side effect it would be easy to implement new stuff like
weighted vertices: not as glorious as weighted edges, but still needed in
some problems (e.g. all-pairs bottleneck paths) and therefore desirable for
a general purpose graph API.

One step further. A weight is not necessarily a double: in some cases not
even a number, but rather a "comparable" of some sort. So I would suggest
to make use of generics in some way, possibly the smartest. Suggestions are
welcome :-)

If my thoughts meet some interest I will work on a patch.

Ciao,
Claudio


P.S.
I am a first-timer here, so what follows is a short introduction.
I am doing a PhD in Graph Drawing and Information Visualization. I always
looked for a standard, unified way to represent and handle graphs when
developing prototypes. So my interest in this project is quite natural, and
I am willing to help and see it become a robust project.

--
Claudio Squarcella
PhD student at Roma Tre University
E-mail address: squar...@dia.uniroma3.it
Phone: +39-06-57333215
Fax: +39-06-57333612
http://www.dia.uniroma3.it/~**squarcel


--**--**-
To unsubscribe, e-mail: 
dev-unsubscribe@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



--
Claudio Squarcella
PhD student at Roma Tre University
E-mail address: squar...@dia.uniroma3.it
Phone: +39-06-57333215
Fax: +39-06-57333612
http://www.dia.uniroma3.it/~squarcel


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

Re: [jira] [Created] (JEXL-123) Redesign API for stability

On 5 December 2011 10:50, henrib  wrote:
> Up-coming technical needs requiring Java 6: JSR-269 (apt/annotation
> processing),

JUnit4 relies on annotations, but does not require Java 1.6

> JSR-199 (compiler API).

I think we need a bit more info than that.

What are the new features that will require 1.6?

I'm not saying that the move to 1.6 should not be made; but I'm not
yet convinced that it is strictly necessary.

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

Re: [jira] [Created] (JEXL-123) Redesign API for stability

Up-coming technical needs requiring Java 6: JSR-269 (apt/annotation
processing), JSR-199 (compiler API).


--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4160017.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

Re: [math] Inconsistencies (bugs) in PascalDistribution?

Hi Mikkel,
> It seems like only the test was changed in r1210359 (svn diff -r
> 1210359). This does _not_ correspond to the log (svn log -r 1210359).

Here is an excerpt of the email sent automatically when I committed
revision 1210359

==BEGIN EXCERPT==
Author: celestin
Date: Mon Dec  5 08:15:38 2011
New Revision: 1210359

URL: http://svn.apache.org/viewvc?rev=1210359&view=rev
Log:
- Corrected expressions for mean and variance in
distribution.PascalDistribution (MATH-715).
- Made javadoc more explicit
- Restored SVN properties to various files in package distribution.



Modified: 
commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
URL: 
http://svn.apache.org/viewvc/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java?rev=1210359&r1=1210358&r2=1210359&view=diff
==
--- 
commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
(original)
+++ 
commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
Mon Dec  5 08:15:38 2011
@@ -31,10 +31,25 @@ import org.apache.commons.math.util.Fast
 * 
 * 
 * There are various ways to express the probability mass and distribution
- * functions for the Pascal distribution.  The convention employed by the
- * library is to express these functions in terms of the number of failures in
- * a Bernoulli experiment
- * (see http://en.wikipedia.org/wiki/Negative_binomial_distribution#Waiting_time_in_a_Bernoulli_process";>Waiting
Time in a Bernoulli Process).
+ * functions for the Pascal distribution. The present implementation represents
+ * the distribution of the number of failures before {@code r} successes occur.
+ * This is the convention adopted in e.g.
+ * http://mathworld.wolfram.com/NegativeBinomialDistribution.html";>MathWorld,
+ * but not in
+ * http://en.wikipedia.org/wiki/Negative_binomial_distribution";>Wikipedia.
+ * 
+ * 
+ * For a random variable {@code X} whose values are distributed
according to this
+ * distribution, the probability mass function is given by
+ * {@code P(X = k) = C(k + r - 1, r - 1) * p^r * (1 - p)^k,}
+ * where {@code r} is the number of successes, {@code p} is the probability of
+ * success, and {@code X} is the total number of failures. {@code C(n, k)} is
+ * the binomial coefficient ({@code n} choose {@code k}). The mean and variance
+ * of {@code X} are
+ * {@code E(X) = (1 - p) * r / p, var(X) = (1 - p) * r / p^2.}
+ * Finally, the cumulative distribution function is given by
+ * {@code P(X <= k) = I(p, r, k + 1)},
+ * where I is the regularized incomplete Beta function.
 * 
 *
 * @see http://en.wikipedia.org/wiki/Negative_binomial_distribution";>
@@ -159,25 +174,24 @@ public class PascalDistribution extends
 * {@inheritDoc}
 *
 * For number of successes {@code r} and probability of success {@code p},
- * the mean is {@code (r * p) / (1 - p)}.
+ * the mean is {@code r * (1 - p) / p}.
 */
public double getNumericalMean() {
final double p = getProbabilityOfSuccess();
final double r = getNumberOfSuccesses();
-return (r * p) / (1 - p);
+return (r * (1 - p)) / p;
}

/**
 * {@inheritDoc}
 *
 * For number of successes {@code r} and probability of success {@code p},
- * the variance is {@code (r * p) / (1 - p)^2}.
+ * the variance is {@code r * (1 - p) / p^2}.
 */
public double getNumericalVariance() {
final double p = getProbabilityOfSuccess();
final double r = getNumberOfSuccesses();
-final double pInv = 1 - p;
-return (r * p) / (pInv * pInv);
+return r * (1 - p) / (p * p);
}

==END EXCERPT==

It seems to me that everything (?) is OK?

>
> It seems like the changes was done in r1210358. Is that true?
>
I don't think so (see extract below).

==BEGIN EXCERPT==

Author: sgoeschl
Date: Mon Dec  5 08:02:46 2011
New Revision: 1210358

URL: http://svn.apache.org/viewvc?rev=1210358&view=rev
Log:
[maven-release-plugin] prepare for next development iteration

Modified:
   commons/proper/email/trunk/pom.xml

==END EXCERPT==

I don't really understand what is happening. I hope I didn't mess up
anything this morning. Please keep me posted.
Sébastien


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

Re: [math] Inconsistencies (bugs) in PascalDistribution?

Hi Mikkel,
>
> This is not to bash, but merely to try to
> stress the importance of keeping a stringent svn history.
>
> Cheers, Mikkel.
>
Thanks for pointing that out. I have run into numerous problems with
SVN this morning, and, although I'm sure I've committed with a log
(it's actually still recorded in eclipse), I would not be surprised if
this log had gone. I will correct that immediately. Thanks again,
Sébastien


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

Re: [jira] [Created] (JEXL-123) Redesign API for stability

On 5 December 2011 09:34, henrib  wrote:
> Sebb;
> Lets not return the pb; Java6 is not downwards compatible with Java 1.5.

Of course not; that's the point.

> There is a cost in maintaining 2 JDKs on 3 boxes, a cost in remembering that
> @Override can not be used on interfaces implementation, that addAll is not
> there, a cost in switching environments before using mvn and publishing,
> etc. All these "little" things that accumulated make it a pain in the a

That is partly why we have CI systems such as Continuum.

> But, again, the main point is just that it is not useful to maintain Java
> 1.5 which is eol; JEXL3 is a new project API intended for active/new
> projects and thus will be used and deployed on Java 6. Besides, there is
> always JEXL 2.1 - soon to be released I hope - which will cover the Java 1.5
> aficionados needs.
>
> Why do you want to impose an unnecessary compatibility ?

Why do you wish to impose a potentially unnecessary compatibily?

> Is there anything
> in the Commons charter that states that obsolete platforms need to be
> deployment targets?

No, but Commons does strive for compatibility as far as possible.

> And IMHO, it is a disservice to the Java community to
> let them run new APIs on Java 1.5 when Java7 is out.

Irrelevant; they can still run any Commons component that targets 1.4
or 1.5 on Java7.

> Finally, do you really need to challenge any change or evolution even when
> not related to stability or quality ?

No, but I think it's necessary to explain why the change in JVM is
necessary for end-users.

The change between 1.4 and 1.5 was much easier to justify, as there
were huge improvements; not least in the memory model.

There are of course improvements in Java 1.6, but they are not of the
same order.

So unless there is a feature in Java 1.6 that is essential for JEXL 3,
then I don't think it's necessary to make Java 1.6 a requirement.

> Will we have to call votes for everything and anything ?

No, but I think it's necessary to justify the change in JVM.

I have yet to see a technical argument why 1.6 is necessary.

> And then we wonder why people seem to be fed up;
> re-read Simo, JamesC, GaryG recent message in the "[JEXL] Jexl 2.1"
> thread...

Also see response from Joerg Schaible.

In Commons particularly, it is important to strive for compatibilty.

> Regards,
> Henrib
>
>
> --
> View this message in context: 
> http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4159821.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: [jira] [Created] (JEXL-123) Redesign API for stability

Sebb;
Lets not return the pb; Java6 is not downwards compatible with Java 1.5.
There is a cost in maintaining 2 JDKs on 3 boxes, a cost in remembering that
@Override can not be used on interfaces implementation, that addAll is not
there, a cost in switching environments before using mvn and publishing,
etc. All these "little" things that accumulated make it a pain in the a

But, again, the main point is just that it is not useful to maintain Java
1.5 which is eol; JEXL3 is a new project API intended for active/new
projects and thus will be used and deployed on Java 6. Besides, there is
always JEXL 2.1 - soon to be released I hope - which will cover the Java 1.5
aficionados needs.
Why do you want to impose an unnecessary compatibility ? Is there anything
in the Commons charter that states that obsolete platforms need to be
deployment targets? And IMHO, it is a disservice to the Java community to
let them run new APIs on Java 1.5 when Java7 is out.

Finally, do you really need to challenge any change or evolution even when
not related to stability or quality ? Will we have to call votes for
everything and anything ? And then we wonder why people seem to be fed up;
re-read Simo, JamesC, GaryG recent message in the "[JEXL] Jexl 2.1"
thread...

Regards,
Henrib


--
View this message in context: 
http://apache-commons.680414.n4.nabble.com/Re-jira-Created-JEXL-123-Redesign-API-for-stability-tp4157779p4159821.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

Re: [math] Inconsistencies (bugs) in PascalDistribution?

2011-12-05 Thread Mikkel Meyer Andersen

2011/12/5 Sébastien Brisard :
> Hi Mikkel,
>>
>> No, you are more than welcome to do the patch and I'll review it :-). Thanks!
>>
>> Cheers, Mikkel.
>>
> I've committed a correction (r1210359). Could you please review it and
> post your comments on the JIRA ticket (MATH-715).
> Thanks a lot!
> Sébastien
>
Dear Sébastien,

It seems like only the test was changed in r1210359 (svn diff -r
1210359). This does _not_ correspond to the log (svn log -r 1210359).
It seems like the changes was done in r1210358. Is that true? svn log
is empty for r1210358. This is not to bash, but merely to try to
stress the importance of keeping a stringent svn history.

Cheers, Mikkel.

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

Re: [Graph] Weighted as an interface

Hi Claudio,
what a pleasant surprise! :) I was hoping commons-graph would have
caught the interest of researchers on that field, I'm really happy you
would like to contribute!

I agree with your observations, please fill new issues on JIRA[1] and
feel free to provide patches, I'll process them ASAP :)

Moreover, I start having the feeling the {{WeightedGraph}} is a
useless interface: it is enough marking the vertices/edges as weighted
depending on the problem... or not? At the end of the day,
{{WeightedGraph}} does nothing than having the the edges marked as
weighted, so Dijkstra signature changed as:

> WeightedPath findShortestPath( G graph,  V source, V
target )

still define well the input type, a graph wich relations are directed
edges and edges are weighted... WDYT?

Looking forward for your contributions, can't wait for them! :)
Simo

[1] https://issues.apache.org/jira/browse/SANDBOX

http://people.apache.org/~simonetripodi/
http://simonetripodi.livejournal.com/
http://twitter.com/simonetripodi
http://www.99soft.org/



On Mon, Dec 5, 2011 at 2:00 AM, James Carman  wrote:
> Welcome!  Contributions (and the contributor) are always welcome.  In my
> past life, I did quite a bit of graph programming to solve "business"
> problems.  We used yfiles, though.  I hope to get around to playing with
> [graph] someday too.  Please do submit a patch!
> On Dec 4, 2011 6:43 PM, "Claudio Squarcella" 
> wrote:
>
>> Hello,
>>
>> I have been reading the source in the past days and I found that the
>> concept of "weight" (e.g. weighted edge, graph, etc) could benefit from a
>> bit of abstraction.
>>
>> The basic idea would be to have an interface called Weighted with an
>> obvious method getWeight(). Changes in the code would easily derive from
>> that. As a side effect it would be easy to implement new stuff like
>> weighted vertices: not as glorious as weighted edges, but still needed in
>> some problems (e.g. all-pairs bottleneck paths) and therefore desirable for
>> a general purpose graph API.
>>
>> One step further. A weight is not necessarily a double: in some cases not
>> even a number, but rather a "comparable" of some sort. So I would suggest
>> to make use of generics in some way, possibly the smartest. Suggestions are
>> welcome :-)
>>
>> If my thoughts meet some interest I will work on a patch.
>>
>> Ciao,
>> Claudio
>>
>>
>> P.S.
>> I am a first-timer here, so what follows is a short introduction.
>> I am doing a PhD in Graph Drawing and Information Visualization. I always
>> looked for a standard, unified way to represent and handle graphs when
>> developing prototypes. So my interest in this project is quite natural, and
>> I am willing to help and see it become a robust project.
>>
>> --
>> Claudio Squarcella
>> PhD student at Roma Tre University
>> E-mail address: squar...@dia.uniroma3.it
>> Phone: +39-06-57333215
>> Fax: +39-06-57333612
>> http://www.dia.uniroma3.it/~**squarcel
>>
>>
>> --**--**-
>> To unsubscribe, e-mail: 
>> dev-unsubscribe@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

[continuum] BUILD FAILURE: Apache Commons - Commons Math - Default Maven 2 Build Definition (Java 1.5)

2011-12-05 Thread Continuum@vmbuild

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15402&projectId=97

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Mon 5 Dec 2011 08:24:38 +
  Finished at: Mon 5 Dec 2011 08:28:46 +
  Total time: 4m 7s
  Build Trigger: Schedule
  Build Number: 607
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_26"
  Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
  Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_26
  Java home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre
  Default locale: en_US, platform encoding: UTF-8
  OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: 
"unix"


SCM Changes:

Changed: celestin @ Mon 5 Dec 2011 08:15:38 +
Comment: - Corrected expressions for mean and variance in 
distribution.PascalDistribution (MATH-715).
- Made javadoc more explicit
- Restored SVN properties to various files in package distribution.
Files changed:
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/AbstractRealDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BetaDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/BinomialDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/CauchyDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ChiSquaredDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ExponentialDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/FDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/GammaDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/HypergeometricDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/KolmogorovSmirnovDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/NormalDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PascalDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/PoissonDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/SaddlePointExpansion.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/TDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/WeibullDistribution.java
 ( 1210359 )
  
/commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/ZipfDistribution.java
 ( 1210359 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.5
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Default Maven 2 Build Definition (Java 1.5)


Test Summary:

Tests: 3164
Failures: 1
Errors: 0
Success Rate: 99
Total time: 141.78304


Test Failures:


PascalDistributionTest
testMoments :
  java.lang.AssertionError
  java.lang.AssertionError: expected:<58.336> but 
was:<10.714285714285715>
at org.junit.Assert.fail(Assert.java:91)
at org.junit.Assert.failNotEquals(Assert.java:645)
at org.junit.Assert.assertEquals(Assert.java:441)
at org.junit.Assert.assertEquals(Assert.java:510)
at 
org.apache.commons.math.distribution.PascalDistributionTest.testMoments(PascalDistributionTest.java:130)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Meth

[continuum] BUILD FAILURE: Apache Commons - Commons Email - Default Maven 2 Build Definition (Java 1.5)

2011-12-05 Thread Continuum@vmbuild

Online report : 
http://vmbuild.apache.org/continuum/buildResult.action?buildId=15401&projectId=79

Build statistics:
  State: Failed
  Previous State: Ok
  Started at: Mon 5 Dec 2011 08:21:42 +
  Finished at: Mon 5 Dec 2011 08:24:19 +
  Total time: 2m 37s
  Build Trigger: Schedule
  Build Number: 31
  Exit code: 1
  Building machine hostname: vmbuild
  Operating system : Linux(unknown)
  Java Home version : 
  java version "1.6.0_26"
  Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
  Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)

  Builder version :
  Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+)
  Java version: 1.6.0_26
  Java home: /usr/lib/jvm/java-6-sun-1.6.0.26/jre
  Default locale: en_US, platform encoding: UTF-8
  OS name: "linux" version: "2.6.32-31-server" arch: "amd64" Family: 
"unix"


SCM Changes:

Changed: sgoeschl @ Mon 5 Dec 2011 07:52:36 +
Comment: Updating to newest common-parent
Files changed:
  /commons/proper/email/trunk/pom.xml ( 1210350 )

Changed: sgoeschl @ Mon 5 Dec 2011 07:53:55 +
Comment: [maven-release-plugin] prepare release EMAIL_1_3_RC2
Files changed:
  /commons/proper/email/trunk/pom.xml ( 1210351 )

Changed: sgoeschl @ Mon 5 Dec 2011 07:58:30 +
Comment: [maven-release-plugin] rollback the release of EMAIL_1_3_RC2
Files changed:
  /commons/proper/email/trunk/pom.xml ( 1210353 )

Changed: sgoeschl @ Mon 5 Dec 2011 08:01:04 +
Comment: Rolling back after SVN issues
Files changed:
  /commons/proper/email/trunk/pom.xml ( 1210355 )

Changed: sgoeschl @ Mon 5 Dec 2011 08:02:29 +
Comment: [maven-release-plugin] prepare release EMAIL_1_3_RC2
Files changed:
  /commons/proper/email/trunk/pom.xml ( 1210356 )

Changed: sgoeschl @ Mon 5 Dec 2011 08:02:46 +
Comment: [maven-release-plugin] prepare for next development iteration
Files changed:
  /commons/proper/email/trunk/pom.xml ( 1210358 )


Dependencies Changes:

No dependencies changed



Build Definition:

POM filename: pom.xml
Goals: clean deploy   
Arguments: --batch-mode -Pjava-1.5
Build Fresh: false
Always Build: false
Default Build Definition: true
Schedule: COMMONS_SCHEDULE
Profile Name: Maven 2.2.1
Description: Default Maven 2 Build Definition (Java 1.5)


Test Summary:

Tests: 123
Failures: 1
Errors: 3
Success Rate: 96
Total time: 11.346001


Test Failures:


ImageHtmlEmailTest
testSendHtml :
  junit.framework.AssertionFailedError
  junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:47)
at junit.framework.Assert.assertTrue(Assert.java:20)
at junit.framework.Assert.assertTrue(Assert.java:27)
at 
org.apache.commons.mail.ImageHtmlEmailTest.testSendHtml(ImageHtmlEmailTest.java:99)


  



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

Re: [math] Inconsistencies (bugs) in PascalDistribution?

Hi Mikkel,
>
> No, you are more than welcome to do the patch and I'll review it :-). Thanks!
>
> Cheers, Mikkel.
>
I've committed a correction (r1210359). Could you please review it and
post your comments on the JIRA ticket (MATH-715).
Thanks a lot!
Sébastien


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

Re: svn commit: r1210359 - /commons/proper/math/trunk/src/main/java/org/apache/commons/math/distribution/