On Fri, Nov 5, 2010 at 5:33 AM, wrote:
>
> - "Henri Yandell" a écrit :
>
>> Though depends on what you're submitting. JIRA issues, no worries.
>> Just hit the checkbox each time you add a patch.
>>
>> If you become a committer, or if you're submitting something large,
>> then we will ask you
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-email has an issue affecting its community integration.
This issue
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-vfs has an issue affecting its community integration.
This issue a
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-scxml-test has an issue affecting its community integration.
This
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-jelly-tags-quartz has an issue affecting its community
integratio
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at gene...@gump.apache.org.
Project commons-proxy-test has an issue affecting its community integration.
This
Switching to the right list...
-
What we need there is a good algorithm for approximating the KS
distribution. I have been corresponding with the author of a very good
one
with a Java implementation but have thus far failed in getting consent to
release under ASL. So at this point, I am looki
2010/11/7 Phil Steitz :
> Switching to the right list...
>
> -
What we need there is a good algorithm for approximating the KS
distribution. I have been corresponding with the author of a very good
one
with a Java implementation but have thus far failed in getting consent
On 11/7/10 10:10 AM, Mikkel Meyer Andersen wrote:
2010/11/7 Phil Steitz:
Switching to the right list...
-
What we need there is a good algorithm for approximating the KS
distribution. I have been corresponding with the author of a very good
one
with a Java implementation but have thus far fa
On 7 November 2010 02:17, Gary Gregory wrote:
>> -Original Message-
>> From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org]
>> Sent: Saturday, November 06, 2010 19:03
>> To: Commons Developers List
>> Subject: Re: [VOTE] Release Commons VFS 2.0
>>
>> +1
>>
>> - I don't think th
Pointing this email out.
JIRA for Sanselan is a bit confusing; it needs a new version created
for the next release and the changes that are going in that version
should have a fix version set of that new version.
Ideally the 'what's in the next version?' question can be answered
with a link to JI
I find myself wondering if Net should move to the Attic - is anyone
active on it and likely to do a release?
-- Forwarded message --
From: sebb
Date: Thu, Oct 14, 2010 at 4:28 PM
Subject: Re: How can I get Commons-net-2.1 Source and Binaries
To: Commons Users List
On 14 Octobe
On Nov 7, 2010, at 7:45, "sebb" wrote:
> On 7 November 2010 02:17, Gary Gregory wrote:
>>> -Original Message-
>>> From: Henning Schmiedehausen [mailto:henn...@schmiedehausen.org]
>>> Sent: Saturday, November 06, 2010 19:03
>>> To: Commons Developers List
>>> Subject: Re: [VOTE] Release C
I think a new release is overdue. I've been meaning to do it when
I find the time. If someone else would like to beat me to it, they're
welcome to go ahead. Almost everything new in the release is covered
by closed JIRA tickets.
> What are the implications of Sanselan's having been elevated
Something else to consider is Stephen Colebourne's Joda Primitives:
http://joda-primitives.sourceforge.net/
Commons Primitives hasn't been touched since 2005 when Stephen was
active on the component. I think it's an Attic component (ie not being
worked on and no future releases expected).
Bcc to
I would suggest that we (and in fact I started hacking around with
this) release a vfs2 which is Java6+ only and fully generified.
-h
On Sun, Nov 7, 2010 at 08:22, Gary Gregory wrote:
> On Nov 7, 2010, at 7:45, "sebb" wrote:
>
>> On 7 November 2010 02:17, Gary Gregory wrote:
-Origina
On Nov 7, 2010, at 8:37, "Henning Schmiedehausen"
wrote:
> I would suggest that we (and in fact I started hacking around with
> this) release a vfs2 which is Java6+ only and fully generified.
>
That's fine with me and my current work projects but I like a more iterative
process where we can g
2010/11/7 Phil Steitz :
> On 11/7/10 10:10 AM, Mikkel Meyer Andersen wrote:
>>
>> 2010/11/7 Phil Steitz:
>>>
>>> Switching to the right list...
>>>
>>> -
>>
>> What we need there is a good algorithm for approximating the KS
>> distribution. I have been corresponding with the author of
Based on entries in the pom and in the manifest of the jar I expect that
email should be compatible with Java 1.4. However, the build fails on a
JDK 1.4 with compilation failures (see below): With StringBuilder and
String.contains() classes and methods are used which are available in
JDK 1.5 on
On 7 November 2010 16:17, Henri Yandell wrote:
> I find myself wondering if Net should move to the Attic - is anyone
> active on it and likely to do a release?
>
I have been working on it from time to time and have been considering
doing a 2.x release.
Hopefully there will be enough people inter
Make sure you stay compatible or it'll have to go to 3.0
On Nov 7, 2010 11:44 AM, "Gary Gregory"
wrote:
> On Nov 7, 2010, at 8:37, "Henning Schmiedehausen" <
henn...@schmiedehausen.org> wrote:
>
>> I would suggest that we (and in fact I started hacking around with
>> this) release a vfs2 which is
On 11/5/10 5:39 PM, Gilles Sadowski wrote:
Hello.
[...]
Of course, I didn't overlook that you just ask for a
@throws FunctionEvaluationException when the evaluation failed.
Javadoc comment.
I'm just reluctant to publicize a guideline that is not adhered to in CM!
Whenever a method is p
No, that would be a vfs2. With new package names and everything. It
would not be intended to be drop in compatible.
-h
On Sun, Nov 7, 2010 at 10:53, James Carman wrote:
> Make sure you stay compatible or it'll have to go to 3.0
> On Nov 7, 2010 11:44 AM, "Gary Gregory"
> wrote:
>> On Nov 7, 201
Online report :
http://vmbuild.apache.org/continuum/buildResult.action?buildId=1466&projectId=65
Build statistics:
State: Failed
Previous State: Failed
Started at: Sun 7 Nov 2010 21:20:09 +
Finished at: Sun 7 Nov 2010 21:26:52 +
Total time: 6m 42s
Build Trigger: Schedule
Bui
If we release vfs2 and then we make changes that make it binary
incompatible, then we have to go to 3 to do a new release. Am I
missing something?
On Sun, Nov 7, 2010 at 4:20 PM, Henning Schmiedehausen
wrote:
> No, that would be a vfs2. With new package names and everything. It
> would not be in
What will the version number be for the next release?
On Sun, Nov 7, 2010 at 8:25 AM, Charles Matthew Chen
wrote:
> I think a new release is overdue. I've been meaning to do it when
> I find the time. If someone else would like to beat me to it, they're
> welcome to go ahead. Almost everythi
It will be a new sub-project. commons-vfs-2. and commons-vfs2-1.0
should be able to co-exist on the same classpath.
For maven reasons, it is not desirable to have shift its
internal packages (because Maven does not understand that 2.0 and 3.0
are not compatible) and commons-vfs and commons-vfs2 s
Hi Oliver,
thanks for the hint - as a Mac OS X user I have currently a limited
choice of JVMs ... :-(
I'm getting the JDK 1.4 installed on my Linux image ...
Cheers,
Siegfried Goeschl
On 11/7/10 6:28 PM, Oliver Heger wrote:
Based on entries in the pom and in the manifest of the jar I exp
Hi folks,
I would like to fix the JDK 1.4 issues and call for a new vote - and
this is the last JDK 1.4 compatible release anyway
Cheers,
Siegfried Goeschl
On 11/6/10 7:18 PM, Siegfried Goeschl wrote:
+1
Siegfried Goeschl
On 11/6/10 6:19 PM, Siegfried Goeschl wrote:
Hi folks,
I would li
It's not a new subproject. It's just a new version of the same
subproject. Trust me, I know about how the maven artifactId/package
name/classpath stuff works. I've had this discussion many times
before on this list. VFS is releasing its 2.0 release right now. If
you want to make binary incompa
On 7 November 2010 23:56, James Carman wrote:
> It's not a new subproject. It's just a new version of the same
> subproject. Trust me, I know about how the maven artifactId/package
> name/classpath stuff works. I've had this discussion many times
> before on this list. VFS is releasing its 2.0
On 11/7/10 7:03 PM, sebb wrote:
On 7 November 2010 23:56, James Carman wrote:
It's not a new subproject. It's just a new version of the same
subproject. Trust me, I know about how the maven artifactId/package
name/classpath stuff works. I've had this discussion many times
before on this list
Just tried using Clirr to check whether the API is compatible or not.
However, Maven Clirr won't work because it cannot find the previous version.
The reason for this is that the Maven groupId has been changed from
commons-vfs to org.apache.commons.
I think this could cause classpath problems in
>
> +1 - here is an idea that can likely be improved:
>
> IllegalArgumentException - thrown when the activated method itself
> can ascertain that preconditions specified in the API expressed at
> the level of the activated method have been violated. In the vast
> majority of cases where [math] t
Nobody listens to me
On Nov 7, 2010 7:49 PM, "sebb" wrote:
> Just tried using Clirr to check whether the API is compatible or not.
>
> However, Maven Clirr won't work because it cannot find the previous
version.
>
> The reason for this is that the Maven groupId has been changed from
> commons-vfs
So you think that if there is no API break, then you don't bump major
version numbers? So what about vfs 2.0? Would you vote against it?
On Nov 7, 2010 7:18 PM, "Phil Steitz" wrote:
> On 11/7/10 7:03 PM, sebb wrote:
>> On 7 November 2010 23:56, James Carman wrote:
>>> It's not a new subproject.
I've just run Clirr on VFS 2.0 (had to cheat and change the Maven
GroupId). There are quite a few errors, which mean that the code is
not binary compatible:
ERROR: 7012: org.apache.commons.vfs.FileContent: Method 'public
boolean hasAttribute(java.lang.String)' has been added to an interface
ERROR:
Ok, so change package, artifactid (group has already changed), and take the
opportunity to modernize the API unless you can do it in a compatible way in
a later 2.x release. Otherwise you will need to go to 3.x.
On Nov 7, 2010 8:21 PM, "sebb" wrote:
> I've just run Clirr on VFS 2.0 (had to cheat
On Nov 7, 2010, at 8:37 AM, Henning Schmiedehausen wrote:
> I would suggest that we (and in fact I started hacking around with
> this) release a vfs2 which is Java6+ only and fully generified.
>
I'm not sure whether I agree. I think I mentioned that Java 7 has a new
FileSystem abstraction.
ht
On Nov 7, 2010, at 4:49 PM, sebb wrote:
> Just tried using Clirr to check whether the API is compatible or not.
>
> However, Maven Clirr won't work because it cannot find the previous version.
>
> The reason for this is that the Maven groupId has been changed from
> commons-vfs to org.apache.com
On 11/7/10 8:19 PM, James Carman wrote:
So you think that if there is no API break, then you don't bump major
version numbers? So what about vfs 2.0? Would you vote against it?
I would not -1 the release, but I would encourage the RM to consider
making it 1.x if there are no compat breaks.
On Sun, Nov 7, 2010 at 8:57 PM, Ralph Goers wrote:
>
> I find this very confusing. In trunk I cannot find a version of pom.xml in
> either the parent or core that didn't have org.apache.commons as the groupid.
> Even in the 1.0 tag the pom.xml has org.apache.commons as the groupId.
> However,
On Sun, Nov 7, 2010 at 9:02 PM, Phil Steitz wrote:
> I would not -1 the release, but I would encourage the RM to consider making
> it 1.x if there are no compat breaks.
>
So, how about now that we know there are compat breaks? I would -1
the release now that we know the API is in fact "broken" b
On Nov 7, 2010, at 6:02 PM, Phil Steitz wrote:
> On 11/7/10 8:19 PM, James Carman wrote:
>> So you think that if there is no API break, then you don't bump major
>> version numbers? So what about vfs 2.0? Would you vote against it?
>
> I would not -1 the release, but I would encourage the RM t
On Sun, Nov 7, 2010 at 9:15 PM, Ralph Goers wrote:
>
> Is the goal to never do a release?
>
No, the goal is to not rush a release just to get something out there.
If we will be knowingly setting our users up for failure (or worse
"jar hell"), then I don't want to do a release that way.
On Nov 7, 2010, at 6:11 PM, James Carman wrote:
> On Sun, Nov 7, 2010 at 8:57 PM, Ralph Goers
> wrote:
>>
>> I find this very confusing. In trunk I cannot find a version of pom.xml in
>> either the parent or core that didn't have org.apache.commons as the
>> groupid. Even in the 1.0 tag th
On Nov 7, 2010, at 6:18 PM, James Carman wrote:
> On Sun, Nov 7, 2010 at 9:15 PM, Ralph Goers
> wrote:
>>
>> Is the goal to never do a release?
>>
>
> No, the goal is to not rush a release just to get something out there.
> If we will be knowingly setting our users up for failure (or worse
>
On Sun, Nov 7, 2010 at 9:25 PM, Ralph Goers wrote:
>
> That said, I understand the implications of screwing stuff up. I just think
> it is a lot less likely that you will find 2.0 and 1.0 of VFS in the same
> classpath vs something like commons lang. But if the consensus is to change
> the pac
On Sun, Nov 7, 2010 at 9:27 PM, Ralph Goers wrote:
> If this is rushing I'd hate to see slow. Releasing VFS 2.0 has been discussed
> several times over the last year or more. None of this is new information.
>
Rushing as in doing something before it's time to do it, not rushing
as in doing somet
On Nov 7, 2010, at 6:32 PM, James Carman wrote:
> On Sun, Nov 7, 2010 at 9:25 PM, Ralph Goers
> wrote:
>>
>> That said, I understand the implications of screwing stuff up. I just think
>> it is a lot less likely that you will find 2.0 and 1.0 of VFS in the same
>> classpath vs something lik
Get a relocation in. problem solved. "commons-vfs" ->
"org.apache.commons". See e.g.
http://repo2.maven.org/maven2/xerces/xerces/2.0.2/xerces-2.0.2.pom on
how to do that.
This should go into repo1:
4.0.0
commons-vfs
commons-vfs
2.0.0
org.apache.commons
commons-vfs
On Sun, Nov 7, 2010 at 9:40 PM, Ralph Goers wrote:
>
> Yeah. I should just get over it and go do it. Rereading the thread it is
> clear more people than not thought the package name should be changed. I'll
> take the blame for not doing it.
>
I don't mind lending a hand if you want it. I'm ac
I'd say that Java7 is still at least 12 months out and another 6-12
months to general adoption.
-h
On Sun, Nov 7, 2010 at 17:41, Ralph Goers wrote:
>
> On Nov 7, 2010, at 8:37 AM, Henning Schmiedehausen wrote:
>
>> I would suggest that we (and in fact I started hacking around with
>> this) relea
On Sun, Nov 7, 2010 at 9:43 PM, Henning Schmiedehausen
wrote:
> This is an old, buggy location and it should be cleaned up over time.
> Being locked into the mistakes of the past because some tool can not
> understand it, doesn't seem to be reasonable to me.
>
The cat's sort of out of the bag now
On Sun, Nov 7, 2010 at 8:41 PM, Ralph Goers wrote:
>
> I'm not sure whether I agree. I think I mentioned that Java 7 has a new
> FileSystem abstraction.
> http://download.oracle.com/javase/7/docs/api/java/nio/file/package-summary.html.
> I would think VFS 3.0 would remove the API and just pro
On Sun, Nov 7, 2010 at 9:48 PM, James Carman wrote:
>
> The cat's sort of out of the bag now. It pisses people (well at least
> it does me) off when you start moving stuff around on them. All of a
> sudden, you start seeing "blah blah moved to blah blah" in your build
> output. VFS apparently w
On 8 November 2010 02:53, James Carman wrote:
> On Sun, Nov 7, 2010 at 9:48 PM, James Carman
> wrote:
>>
>> The cat's sort of out of the bag now. It pisses people (well at least
>> it does me) off when you start moving stuff around on them. All of a
>> sudden, you start seeing "blah blah moved
I don't get it. Sorry. :-)
So maven1 kind of added ad-hoc groups. They chose to use the same as
the artifactId as the groupId when they constituted that back in the
maven1 days. That turned out to be suboptimal. But some artifacts that
were in the maven1 tree (most of commons) ended up in the comm
Most of the generics fixes have now been done.
There are still a few raw Class references; most of these can be fixed
if DefaultFileSystemConfigBuilder.getConfigClass() is changed to
return a FileSystem [1]
Can anyone else confirm that this is a sensible change?
[1] https://issues.apache.org/jir
On 8 November 2010 03:08, Henning Schmiedehausen
wrote:
> I don't get it. Sorry. :-)
>
> So maven1 kind of added ad-hoc groups. They chose to use the same as
> the artifactId as the groupId when they constituted that back in the
> maven1 days. That turned out to be suboptimal. But some artifacts t
On Sun, Nov 7, 2010 at 10:03 PM, sebb wrote:
>
> I just checked, and the tag agrees with the source archive - apart
> from the sandbox tree, which is only in the tag.
>
Huh? If you look at the tag that is supposed to be for 1.0 here:
http://svn.apache.org/repos/asf/commons/proper/vfs/tags/vfs-1
On Nov 7, 2010, at 6:49 PM, James Carman wrote:
> On Sun, Nov 7, 2010 at 8:41 PM, Ralph Goers
> wrote:
>>
>> I'm not sure whether I agree. I think I mentioned that Java 7 has a new
>> FileSystem abstraction.
>> http://download.oracle.com/javase/7/docs/api/java/nio/file/package-summary.html.
> -Original Message-
> From: jcar...@carmanconsulting.com [mailto:jcar...@carmanconsulting.com] On
> Behalf Of James Carman
> Sent: Sunday, November 07, 2010 18:14
> To: Commons Developers List
> Subject: Re: Backwards incompatible changes and package names (was: Re: [VOTE]
> Release Common
> +1 to org.apache.commons:* for all new releases. +1 to "JDK5+ (even
> though I would prefer JDK6+) for all new releases.
+1
-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h..
64 matches
Mail list logo
