RE: [VFS] Maven groupId problem?
> +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...@commons.apache.org
RE: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
> -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 Commons VFS 2.0) > > 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" between 1 and > 2 and they're not doing the package/artifactId change (barring any > justification why we think it's okay). Well, that should settle it. API-breakage -> new major version -> package/artifactId change. So we can take this RC, do the above changes, then keep move on to a Java 5 themed release for 2.1. Gary > > - > 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] Release Commons VFS 2.0
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. >> I would think VFS 3.0 would remove the API and just provide FileSystem >> implementations. So I'm not sure how much effort is worth investing in V2.0 >> to move it to Java 6. >> > > I saw something about this recently (if I had more sleep I could > probably recall where) and wondered about VFS. Does this new API look > like it would do everything that VFS currently does? If so, it's a > great step forward for the language, IMHO. > I've not investigated it extensively, but the new API seems to have a lot of similarity to VFS. Instead of a File the new API uses a FileChannel, which is an abstract class. It wouldn't be a stretch to imagine all the various FileObjects extending that. The SPI also has a FileSystemProvider which is used to create a FileSystem and a FileStore. It also includes a WatchService to listen for changes and events. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Maven groupId problem?
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.0/ It contains a pom.xml file in the "root" directory. If you download an unzip/untar the source distributions from here: http://commons.apache.org/vfs/download_vfs.cgi they do not. How do they agree? Am I looking in the wrong place? - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Maven groupId problem?
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 that > were in the maven1 tree (most of commons) ended up in the commons-* > locations. > > Pretty much everyone agrees that this was a mistake and these > artifacts should have been put into org.apache.commons. However, they > were not. Why should be stay locked into these mistakes forever? > > Maven offers a relocation mechanism. So we use it and put the new > releases into the more sane location which is > org.apache.commons:commons-vfs. Life goes on afterwards. Relocation > helps people to transition. But as far as I can ascertain, relocation does not solve all the problems of changes of group/artifact ids. This is because relocation is added to the old location - which may not always be examined. Anyway, relocation should only be used for compatible binaries. In this case we really don't want Maven to consider 1.0 and 2.0 as being different versions of the same code > I love backwards compatibility as the next guy, but we do have to move > on at some point. JDK 1.3 and Maven 1 are gone for five+ years now. > Everyone who is still using them will not upgrade anyway. Not > leveraging what exists in 2010 seems to wrong to me. Let's acknowledge > mistakes of the past and move on. > > +1 to org.apache.commons:* for all new releases. +1 to "JDK5+ (even > though I would prefer JDK6+) for all new releases. > > -h > > On Sun, Nov 7, 2010 at 18:48, James Carman wrote: >> 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. 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 wasn't a Maven 2 project at the time it was >> released. The source distribution doesn't contain a pom.xml file. >> I'm more worried about how the tag is out of sync with the "official" >> released source. That's not good. >> >> - >> 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
[VFS] Generics fixes
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/jira/browse/VFS-334 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Maven groupId problem?
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 commons-* locations. Pretty much everyone agrees that this was a mistake and these artifacts should have been put into org.apache.commons. However, they were not. Why should be stay locked into these mistakes forever? Maven offers a relocation mechanism. So we use it and put the new releases into the more sane location which is org.apache.commons:commons-vfs. Life goes on afterwards. Relocation helps people to transition. I love backwards compatibility as the next guy, but we do have to move on at some point. JDK 1.3 and Maven 1 are gone for five+ years now. Everyone who is still using them will not upgrade anyway. Not leveraging what exists in 2010 seems to wrong to me. Let's acknowledge mistakes of the past and move on. +1 to org.apache.commons:* for all new releases. +1 to "JDK5+ (even though I would prefer JDK6+) for all new releases. -h On Sun, Nov 7, 2010 at 18:48, James Carman wrote: > 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. 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 wasn't a Maven 2 project at the time it was > released. The source distribution doesn't contain a pom.xml file. > I'm more worried about how the tag is out of sync with the "official" > released source. That's not good. > > - > 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: [VFS] Maven groupId problem?
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 to blah blah" in your build >> output. VFS apparently wasn't a Maven 2 project at the time it was >> released. The source distribution doesn't contain a pom.xml file. >> I'm more worried about how the tag is out of sync with the "official" >> released source. That's not good. I just checked, and the tag agrees with the source archive - apart from the sandbox tree, which is only in the tag. >> > > The other weird thing here is that there actually *are* pom.xml files > in the core and examples subfolders in the source distribution for > 1.0. So, Maven 2 was at least part of the picture. Curiouser and > curiouser. Probably just the start of creating the M2 build. > - > 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: [VFS] Maven groupId problem?
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 wasn't a Maven 2 project at the time it was > released. The source distribution doesn't contain a pom.xml file. > I'm more worried about how the tag is out of sync with the "official" > released source. That's not good. > The other weird thing here is that there actually *are* pom.xml files in the core and examples subfolders in the source distribution for 1.0. So, Maven 2 was at least part of the picture. Curiouser and curiouser. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
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 provide FileSystem > implementations. So I'm not sure how much effort is worth investing in V2.0 > to move it to Java 6. > I saw something about this recently (if I had more sleep I could probably recall where) and wondered about VFS. Does this new API look like it would do everything that VFS currently does? If so, it's a great step forward for the language, IMHO. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Maven groupId problem?
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. 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 wasn't a Maven 2 project at the time it was released. The source distribution doesn't contain a pom.xml file. I'm more worried about how the tag is out of sync with the "official" released source. That's not good. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
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) 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. > 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 provide FileSystem > implementations. So I'm not sure how much effort is worth investing in V2.0 > to move it to Java 6. > > Ralph > - > 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: [VFS] Maven groupId problem?
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 actually a VFS user, so I do have some stake in the code. :) Let me know if there's anything you want me to do. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Maven groupId problem?
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 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. -h On Sun, Nov 7, 2010 at 16:49, 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.commons. > > I think this could cause classpath problems in Maven, and we should > hold off releasing 2.0 until this is resolved. > > - > 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: [VFS] Maven groupId problem?
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 like commons lang. But if the consensus is to change >> the package names before doing a release it can certainly be done. Note >> that I raised this question in August 2009 when we first discussed changing >> the JDK version to Java 5 (see the thread I referenced for that in the >> previous VOTE thread). I'm just a little miffed that I could have done this >> a year ago. >> > > I can understand why you would be miffed. Do you remember the first > person who replied to you in that thread and the first question out of > their mouth > (http://www.mail-archive.com/u...@commons.apache.org/msg03711.html)? > Please review the discussion. These issues were addressed. > 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. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
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 something quickly. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Maven groupId problem?
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 package names before doing a release it can certainly be done. Note that > I raised this question in August 2009 when we first discussed changing the > JDK version to Java 5 (see the thread I referenced for that in the previous > VOTE thread). I'm just a little miffed that I could have done this a year > ago. > I can understand why you would be miffed. Do you remember the first person who replied to you in that thread and the first question out of their mouth (http://www.mail-archive.com/u...@commons.apache.org/msg03711.html)? Please review the discussion. These issues were addressed. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
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 > "jar hell"), then I don't want to do a release that way. > 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. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Maven groupId problem?
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 the pom.xml has org.apache.commons as the >> groupId. However, the project.xml used by maven 1 had commons-vfs as the >> groupid. So if someone checks out VFS 1.0 and builds it with maven 2 they >> are going to get a different groupId than the binary release (assuming the >> Maven 2 build even works). >> > > This is the only thing that really matters: While I agree that matters, it actually doesn't matter at all from an ASF point of view. The only thing that matters is the source that was voted on. Apparently it was in error. 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 package names before doing a release it can certainly be done. Note that I raised this question in August 2009 when we first discussed changing the JDK version to Java 5 (see the thread I referenced for that in the previous VOTE thread). I'm just a little miffed that I could have done this a year ago. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
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. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
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 to consider making > it 1.x if there are no compat breaks. > As Sebb has shown there are compatibility breaks. The real issue here is that it has been far too long since a VFS release has been done. I'm not sure why the version was bumped from 1.1 to 2.0, but it happened in March 2008, at least 8 months before I started working on the code. That change was 16 months after the prior release. Is the goal to never do a release? Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
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" between 1 and 2 and they're not doing the package/artifactId change (barring any justification why we think it's okay). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VFS] Maven groupId problem?
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, the project.xml used by maven 1 had commons-vfs as the groupid. So > if someone checks out VFS 1.0 and builds it with maven 2 they are going to > get a different groupId than the binary release (assuming the Maven 2 build > even works). > This is the only thing that really matters: http://repo1.maven.org/maven2/commons-vfs/commons-vfs/1.0/commons-vfs-1.0.pom That's how it was released into the central repo. I have no idea how stuff got messed up, but that's what it shows up as and that's how folks are using it. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
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. Phil 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. 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 incompatible changes, it has to bump its major version number to 3 (along with artifactId/package change). Agreed. This is why I've argued that VFS 2.0 should actually be 1.1, so that we don't introduce an inconsistency. The 2.x stuff should be in a vfs2 package, per our naming conventions. In my opinion, it's not enough AFAIK, we have not agreed that package name suffix == major version number. I used to be among those resisting this, but James' admirable persistence has won me over :) For the components that are likely to have any possibility of needing to appear twice on the classpath of an application at least, I think the following convention makes sense: Major version bump<-> compatibility break in API<-> change package name<-> change maven artifactId Bumping required JDK does not by itself force a compat break. I guess it is possible that so much can be accomplished without any breaks that a major version bump is warranted in some cases; but I have never seen that happen. So I am +1 on trying to adhere to this convention or at least explaining why not (in [math] for example we perhaps lamely argue that classpath multiplicity is not likely). Phil different to merit a 2.0 release. Not enough has been done. Especially when you consider the version numbering madness that this is going to cause. On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen wrote: 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 should not use use the same packages. So commons-vfs will continue to use org.apache.commons.vfs.* and commons-vfs2 will use org.apache.commons.vfs2.* And it must be possible to have both versions on the classpath without clashing. -h On Sun, Nov 7, 2010 at 13:45, James Carman wrote: 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 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, 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 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 generify the code on java 5 for a 2.1. Then we can do a java 6 release. Gary -h On Sun, Nov 7, 2010 at 08:22, Gary Gregory< ggreg...@seagullsoftware.com> wrote: On Nov 7, 2010, at 7:45, "sebb" wrote: On 7 November 2010 02:17, Gary Gregory< ggreg...@seagullsoftware.com> 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 that "has warnings" is a problem - If deprecated APIs are still around, we can always remove them later. Yes, release early, release often. I would encourage work to proceed immediately to implement this, generics, and whatever Java 5 changes we can take advantage of. I've already done the main annotations (@Override and @Deprecation) I've started looking at generics. There's rather a lot of changes to fix all the Java 1.5 warnings, so it will probably have to be done in stages, but I can start committing soon Great news. It would be nice to release early release often a la XP with a 2.1 themed release 'java 5 optimized' Gary Gary -h On Fri, Nov 5, 2010 at 13:12, Ralph Goers< ralph.go...@dslextreme.com> wrote: This is a vote to release Apache Commons VFS 2.0. Since the last candidate the jdk version has been changed to 1.5 and the requirement has been added to the web site main page. The test
Re: [VFS] Maven groupId problem?
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.commons. > > I think this could cause classpath problems in Maven, and we should > hold off releasing 2.0 until this is resolved. > 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, the project.xml used by maven 1 had commons-vfs as the groupid. So if someone checks out VFS 1.0 and builds it with maven 2 they are going to get a different groupId than the binary release (assuming the Maven 2 build even works). Ralph
Re: [VOTE] Release Commons VFS 2.0
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. 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 provide FileSystem implementations. So I'm not sure how much effort is worth investing in V2.0 to move it to Java 6. Ralph - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
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 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: 7012: org.apache.commons.vfs.FileContent: Method 'public void > removeAttribute(java.lang.String)' has been added to an interface > ERROR: 7012: org.apache.commons.vfs.FileSystem: Method 'public > java.lang.String getRootURI()' has been added to an interface > ERROR: 7009: org.apache.commons.vfs.FileSystemConfigBuilder: > Accessibility of method 'public FileSystemConfigBuilder()' has been > decreased from public to protected > ERROR: 7012: org.apache.commons.vfs.FileSystemManager: Method 'public > boolean hasProvider(java.lang.String)' has been added to an interface > ERROR: 3003: org.apache.commons.vfs.FileSystemOptions: Added final > modifier to class > ERROR: 2001: org.apache.commons.vfs.Selectors: Changed from interface to class > ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority: > Accessibility of field hostName has been weakened from public to > private > ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority: > Accessibility of field password has been weakened from public to > private > ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority: > Accessibility of field port has been weakened from public to private > ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority: > Accessibility of field scheme has been weakened from public to private > ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority: > Accessibility of field userName has been weakened from public to > private > ERROR: 3003: org.apache.commons.vfs.util.UserAuthenticatorUtils: Added > final modifier to class > ERROR: 7009: org.apache.commons.vfs.util.UserAuthenticatorUtils: > Accessibility of method 'public UserAuthenticatorUtils()' has been > decreased from public to private > > On 5 November 2010 20:12, Ralph Goers wrote: >> This is a vote to release Apache Commons VFS 2.0. >> >> Since the last candidate the jdk version has been changed to 1.5 and the requirement has been added to the web site main page. The test file for LargeTarTestCase has been added to the test-data directory, greatly improving the build time. Many of the messages from the test cases have been removed. >> >> [ ] +1 release it >> [ ] +0 go ahead I don't care >> [ ] -1 no, do not release it because... >> >> Ralph >> >> tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ (revision 1031749) >> >> site: http://people.apache.org/~rgoers/commons-vfs/index.html >> >> The following artifacts have been staged to the Apache Nexus Staging repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) https://repository.apache.org/content/repositories/orgapachecommons-038/ >> >> commons-vfs-examples-2.0.jar >> commons-vfs-examples-2.0.pom >> commons-vfs-examples-2.0-javadoc.jar >> commons-vfs-examples-2.0-sources.jar >> commons-vfs-examples-2.0.jar.asc >> commons-vfs-examples-2.0-sources.jar.asc >> commons-vfs-examples-2.0.pom.asc >> commons-vfs-examples-2.0-javadoc.jar.asc >> commons-vfs-2.0-tests.jar >> commons-vfs-2.0-test-sources.jar.asc >> commons-vfs-2.0-sources.jar.asc >> commons-vfs-2.0.jar >> commons-vfs-2.0.pom >> commons-vfs-2.0-test-sources.jar >> commons-vfs-2.0-javadoc.jar >> commons-vfs-2.0-javadoc.jar.asc >> commons-vfs-2.0-tests.jar.asc >> commons-vfs-2.0.pom.asc >> commons-vfs-2.0-sources.jar >> commons-vfs-2.0.jar.asc >> commons-vfs-sandbox-2.0-tests.jar.asc >> commons-vfs-sandbox-2.0-sources.jar >> commons-vfs-sandbox-2.0-tests.jar >> commons-vfs-sandbox-2.0-test-sources.jar.asc >> commons-vfs-sandbox-2.0-sources.jar.asc >> commons-vfs-sandbox-2.0.jar.asc >> commons-vfs-sandbox-2.0-test-sources.jar >> commons-vfs-sandbox-2.0-javadoc.jar >> commons-vfs-sandbox-2.0.pom >> commons-vfs-sandbox-2.0.jar >> commons-vfs-sandbox-2.0-javadoc.jar.asc >> commons-vfs-sandbox-2.0.pom.asc >> commons-vfs-distribution-2.0-src.zip >> commons-vfs-distribution-2.0.pom >> commons-vfs-distribution-2.0-src.tar.gz.asc >> commons-vfs-distribution-2.0-src.tar.gz >> commons-vfs-distribution-2.0-bin.zip >> commons-vfs-distribution-2.0-bin.zip.asc >> commons-vfs-distribution-2.0-bin.tar.gz >> commons-vfs-distribution-2.0-src.zip.asc >> commons-vfs-distribution-2.0-bin.tar.gz.asc >> commons-vfs-distribution-2.0.pom.asc >> commons-vfs-project-2.0-site.xml.asc >> commons-vfs-project-2.0.pom >> commons-vfs-project-2.0-site.xml >> commons-vfs-project-2.0.pom.asc > > --
Re: [VOTE] Release Commons VFS 2.0
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: 7012: org.apache.commons.vfs.FileContent: Method 'public void removeAttribute(java.lang.String)' has been added to an interface ERROR: 7012: org.apache.commons.vfs.FileSystem: Method 'public java.lang.String getRootURI()' has been added to an interface ERROR: 7009: org.apache.commons.vfs.FileSystemConfigBuilder: Accessibility of method 'public FileSystemConfigBuilder()' has been decreased from public to protected ERROR: 7012: org.apache.commons.vfs.FileSystemManager: Method 'public boolean hasProvider(java.lang.String)' has been added to an interface ERROR: 3003: org.apache.commons.vfs.FileSystemOptions: Added final modifier to class ERROR: 2001: org.apache.commons.vfs.Selectors: Changed from interface to class ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority: Accessibility of field hostName has been weakened from public to private ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority: Accessibility of field password has been weakened from public to private ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority: Accessibility of field port has been weakened from public to private ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority: Accessibility of field scheme has been weakened from public to private ERROR: 6010: org.apache.commons.vfs.provider.HostFileNameParser$Authority: Accessibility of field userName has been weakened from public to private ERROR: 3003: org.apache.commons.vfs.util.UserAuthenticatorUtils: Added final modifier to class ERROR: 7009: org.apache.commons.vfs.util.UserAuthenticatorUtils: Accessibility of method 'public UserAuthenticatorUtils()' has been decreased from public to private On 5 November 2010 20:12, Ralph Goers wrote: > This is a vote to release Apache Commons VFS 2.0. > > Since the last candidate the jdk version has been changed to 1.5 and the > requirement has been added to the web site main page. The test file for > LargeTarTestCase has been added to the test-data directory, greatly improving > the build time. Many of the messages from the test cases have been removed. > > [ ] +1 release it > [ ] +0 go ahead I don't care > [ ] -1 no, do not release it because... > > Ralph > > tag: > https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs-project-2.0/ > (revision 1031749) > > site: http://people.apache.org/~rgoers/commons-vfs/index.html > > The following artifacts have been staged to the Apache Nexus Staging > repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) > https://repository.apache.org/content/repositories/orgapachecommons-038/ > > commons-vfs-examples-2.0.jar > commons-vfs-examples-2.0.pom > commons-vfs-examples-2.0-javadoc.jar > commons-vfs-examples-2.0-sources.jar > commons-vfs-examples-2.0.jar.asc > commons-vfs-examples-2.0-sources.jar.asc > commons-vfs-examples-2.0.pom.asc > commons-vfs-examples-2.0-javadoc.jar.asc > commons-vfs-2.0-tests.jar > commons-vfs-2.0-test-sources.jar.asc > commons-vfs-2.0-sources.jar.asc > commons-vfs-2.0.jar > commons-vfs-2.0.pom > commons-vfs-2.0-test-sources.jar > commons-vfs-2.0-javadoc.jar > commons-vfs-2.0-javadoc.jar.asc > commons-vfs-2.0-tests.jar.asc > commons-vfs-2.0.pom.asc > commons-vfs-2.0-sources.jar > commons-vfs-2.0.jar.asc > commons-vfs-sandbox-2.0-tests.jar.asc > commons-vfs-sandbox-2.0-sources.jar > commons-vfs-sandbox-2.0-tests.jar > commons-vfs-sandbox-2.0-test-sources.jar.asc > commons-vfs-sandbox-2.0-sources.jar.asc > commons-vfs-sandbox-2.0.jar.asc > commons-vfs-sandbox-2.0-test-sources.jar > commons-vfs-sandbox-2.0-javadoc.jar > commons-vfs-sandbox-2.0.pom > commons-vfs-sandbox-2.0.jar > commons-vfs-sandbox-2.0-javadoc.jar.asc > commons-vfs-sandbox-2.0.pom.asc > commons-vfs-distribution-2.0-src.zip > commons-vfs-distribution-2.0.pom > commons-vfs-distribution-2.0-src.tar.gz.asc > commons-vfs-distribution-2.0-src.tar.gz > commons-vfs-distribution-2.0-bin.zip > commons-vfs-distribution-2.0-bin.zip.asc > commons-vfs-distribution-2.0-bin.tar.gz > commons-vfs-distribution-2.0-src.zip.asc > commons-vfs-distribution-2.0-bin.tar.gz.asc > commons-vfs-distribution-2.0.pom.asc > commons-vfs-project-2.0-site.xml.asc > commons-vfs-project-2.0.pom > commons-vfs-project-2.0-site.xml > commons-vfs-project-2.0.pom.asc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
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. 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 incompatible changes, it has to bump its major >>> version number to 3 (along with artifactId/package change). >> >> Agreed. >> >>> This is >>> why I've argued that VFS 2.0 should actually be 1.1, so that we don't >>> introduce an inconsistency. The 2.x stuff should be in a vfs2 >>> package, per our naming conventions. In my opinion, it's not enough >> >> AFAIK, we have not agreed that package name suffix == major version number. > > I used to be among those resisting this, but James' admirable > persistence has won me over :) For the components that are likely to > have any possibility of needing to appear twice on the classpath of > an application at least, I think the following convention makes sense: > > Major version bump <-> compatibility break in API <-> change package > name <-> change maven artifactId > > Bumping required JDK does not by itself force a compat break. I > guess it is possible that so much can be accomplished without any > breaks that a major version bump is warranted in some cases; but I > have never seen that happen. So I am +1 on trying to adhere to this > convention or at least explaining why not (in [math] for example we > perhaps lamely argue that classpath multiplicity is not likely). > > Phil >> >>> different to merit a 2.0 release. Not enough has been done. >>> Especially when you consider the version numbering madness that this >>> is going to cause. >>> >>> On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen >>> wrote: 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 should not use use the same packages. So commons-vfs will continue to use org.apache.commons.vfs.* and commons-vfs2 will use org.apache.commons.vfs2.* And it must be possible to have both versions on the classpath without clashing. -h On Sun, Nov 7, 2010 at 13:45, James Carman wrote: > 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 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, 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 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 generify the code on java 5 for a 2.1. Then >>> we can do a java 6 release. Gary > > -h > > On Sun, Nov 7, 2010 at 08:22, Gary Gregory< ggreg...@seagullsoftware.com> >>> wrote: >> On Nov 7, 2010, at 7:45, "sebb" wrote: >> >>> On 7 November 2010 02:17, Gary Gregory< ggreg...@seagullsoftware.com> >>> 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 that "has warnings" is a problem > - If deprecated APIs are still around, we can always remove them >>> later. Yes, release early, release often. I would encourage work to proceed immediately to implement this, >>> generics, and whatever Java 5 changes we can take advantage of. >>> >>> I've already done the main annotations (@Override and @Deprecation) >>> >>> I've started looking at generics. >>> >>> There's rath
Re: [VFS] Maven groupId problem?
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 to org.apache.commons. > > I think this could cause classpath problems in Maven, and we should > hold off releasing 2.0 until this is resolved. > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org >
Re: [Math] FunctionEvaluationException in UnivariateRealFunction
> > +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] throws IllegalArgumentException, it > is the result of argument checking of actual parameters immediately > passed to a method. > > FunctionEvaluationException - may be advertised by a method that may > encounter errors evaluating a function. This *should* be thrown > only in circumstances where at the level of the activated function > IllegalArgumentException is not appropriate and it *should* indicate > that while formal preconditions of the method have not been > violated, an irrecoverable error has occurred evaluating a function > at some (usually lower) level of the call stack. Convergence > failures, runtime exceptions (even IllegalArgumentExceptions) in > user code or lower level methods can cause (and should be wrapped > in) FunctionEvaluationExceptions. Added in revision 1032424. > >You could write a document that would explain how good it would be if all > >programs were using the same exceptions. But I must point out that CM isn't > >a good example, with its policy of no dependencies. Why would anyone depend > >on CM just for the sake of using CM exceptions? > > I think you are missing the point here - our APIs can encourage > consistent use of exceptions by user code that uses and/or > integrates with [math]. > > These are the kinds of things we need to talk about in refactoring > exceptions. Our API - including all advertised exceptions - needs > to help users understand what we - and they - are doing, not just > minimize the amount of code they need to write or simplify our lives > as maintainers. This is especially true of the more complex > algorithms and frameworks where user code plugs into [math]. We're probably not talking about the same things. And you are missing my points as much as I've missed yours. CM is a Java library that has many advantages, but before trying to give lessons to other programmers on "what they are doing", we should concentrate on internal improvements. The handling of exceptions is something that cannot come as an after-thought. I think that exceptions should primarily be useful *inside* the code base in which they are defined (even more so with checked ones) and not pre-suppose they will be handled in larger scopes. Here is a quote from Bruce Eckel at http://www.mindview.net/Etc/Discussions/CheckedExceptions: --- [...] it does agree that checked exceptions seem to be helpful for small projects, which is generally the space where we argue the point. However, when projects get large (actually, I've noticed it when they are anything except small), checked exceptions get ungainly and seem to cause problems. I would therefore suggest that the reason checked exceptions seem so compellingly "right" at first is that they have been presented and argued in the realm of small examples. --- Finally, I indeed share the opinion that clean, lean, and consistent code makes it more maintainable (and hence simplify the maintainer's lives). Gilles - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[VFS] Maven groupId problem?
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 Maven, and we should hold off releasing 2.0 until this is resolved. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 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. VFS is releasing its 2.0 release right now. If you want to make binary incompatible changes, it has to bump its major version number to 3 (along with artifactId/package change). Agreed. This is why I've argued that VFS 2.0 should actually be 1.1, so that we don't introduce an inconsistency. The 2.x stuff should be in a vfs2 package, per our naming conventions. In my opinion, it's not enough AFAIK, we have not agreed that package name suffix == major version number. I used to be among those resisting this, but James' admirable persistence has won me over :) For the components that are likely to have any possibility of needing to appear twice on the classpath of an application at least, I think the following convention makes sense: Major version bump <-> compatibility break in API <-> change package name <-> change maven artifactId Bumping required JDK does not by itself force a compat break. I guess it is possible that so much can be accomplished without any breaks that a major version bump is warranted in some cases; but I have never seen that happen. So I am +1 on trying to adhere to this convention or at least explaining why not (in [math] for example we perhaps lamely argue that classpath multiplicity is not likely). Phil different to merit a 2.0 release. Not enough has been done. Especially when you consider the version numbering madness that this is going to cause. On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen wrote: 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 should not use use the same packages. So commons-vfs will continue to use org.apache.commons.vfs.* and commons-vfs2 will use org.apache.commons.vfs2.* And it must be possible to have both versions on the classpath without clashing. -h On Sun, Nov 7, 2010 at 13:45, James Carman wrote: 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 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, 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 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 generify the code on java 5 for a 2.1. Then we can do a java 6 release. Gary -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: -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 that "has warnings" is a problem - If deprecated APIs are still around, we can always remove them later. Yes, release early, release often. I would encourage work to proceed immediately to implement this, generics, and whatever Java 5 changes we can take advantage of. I've already done the main annotations (@Override and @Deprecation) I've started looking at generics. There's rather a lot of changes to fix all the Java 1.5 warnings, so it will probably have to be done in stages, but I can start committing soon Great news. It would be nice to release early release often a la XP with a 2.1 themed release 'java 5 optimized' Gary Gary -h On Fri, Nov 5, 2010 at 13:12, Ralph Goers wrote: This is a vote to release Apache Commons VFS 2.0. Since the last candidate the jdk version has been changed to 1.5 and the requirement has been added to the web site main page. The test file for LargeTarTestCase has been added to the test-data directory, greatly improving the build time. Many of the messages from the test cases have been removed. [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because... Ralph tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- project-2.0/ (revision 1031749) site: http://people.apache.org/~rgoers/commons-vfs/index.html Th
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
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 release right now. If > you want to make binary incompatible changes, it has to bump its major > version number to 3 (along with artifactId/package change). Agreed. > This is > why I've argued that VFS 2.0 should actually be 1.1, so that we don't > introduce an inconsistency. The 2.x stuff should be in a vfs2 > package, per our naming conventions. In my opinion, it's not enough AFAIK, we have not agreed that package name suffix == major version number. > different to merit a 2.0 release. Not enough has been done. > Especially when you consider the version numbering madness that this > is going to cause. > > On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen > wrote: >> 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 should not use >> use the same packages. >> >> So commons-vfs will continue to use org.apache.commons.vfs.* and >> commons-vfs2 will use org.apache.commons.vfs2.* >> >> And it must be possible to have both versions on the classpath without >> clashing. >> >> -h >> >> >> >> >> On Sun, Nov 7, 2010 at 13:45, James Carman >> wrote: >>> 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 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, 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 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 generify the code on java 5 for a 2.1. Then > we can do a java 6 release. >> >> Gary >>> >>> -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: >>> -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 that "has warnings" is a problem >>> - If deprecated APIs are still around, we can always remove them > later. >> >> Yes, release early, release often. >> >> I would encourage work to proceed immediately to implement this, > generics, and whatever Java 5 changes we can take advantage of. > > I've already done the main annotations (@Override and @Deprecation) > > I've started looking at generics. > > There's rather a lot of changes to fix all the Java 1.5 warnings, so > it will probably have to be done in stages, but I can start committing > soon Great news. It would be nice to release early release often a la XP with > a 2.1 themed release 'java 5 optimized' Gary > >> Gary >> >>> >>> -h >>> >>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers >>> > wrote: This is a vote to release Apache Commons VFS 2.0. Since the last candidate the jdk version has been changed to 1.5 and > the >>> requirement has been added to the web site main page. The test file > for >>> LargeTarTestCase has been added to the test-data directory, greatly > improving >>> the build time. Many of the messages from the test cases have been > removed. [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because... Ralph tag: > https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- >>> project-2.0/ (rev
Re: Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
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 incompatible changes, it has to bump its major version number to 3 (along with artifactId/package change). This is why I've argued that VFS 2.0 should actually be 1.1, so that we don't introduce an inconsistency. The 2.x stuff should be in a vfs2 package, per our naming conventions. In my opinion, it's not enough different to merit a 2.0 release. Not enough has been done. Especially when you consider the version numbering madness that this is going to cause. On Sun, Nov 7, 2010 at 5:05 PM, Henning Schmiedehausen wrote: > 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 should not use > use the same packages. > > So commons-vfs will continue to use org.apache.commons.vfs.* and > commons-vfs2 will use org.apache.commons.vfs2.* > > And it must be possible to have both versions on the classpath without > clashing. > > -h > > > > > On Sun, Nov 7, 2010 at 13:45, James Carman wrote: >> 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 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, 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 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 generify the code on java 5 for a 2.1. Then we can do a java 6 release. > > Gary >> >> -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: >> -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 that "has warnings" is a problem >> - If deprecated APIs are still around, we can always remove them later. > > Yes, release early, release often. > > I would encourage work to proceed immediately to implement this, generics, and whatever Java 5 changes we can take advantage of. I've already done the main annotations (@Override and @Deprecation) I've started looking at generics. There's rather a lot of changes to fix all the Java 1.5 warnings, so it will probably have to be done in stages, but I can start committing soon >>> >>> Great news. It would be nice to release early release often a la XP with a 2.1 themed release 'java 5 optimized' >>> >>> Gary >>> > Gary > >> >> -h >> >> On Fri, Nov 5, 2010 at 13:12, Ralph Goers >> wrote: >>> This is a vote to release Apache Commons VFS 2.0. >>> >>> Since the last candidate the jdk version has been changed to 1.5 and the >> requirement has been added to the web site main page. The test file for >> LargeTarTestCase has been added to the test-data directory, greatly improving >> the build time. Many of the messages from the test cases have been removed. >>> >>> [ ] +1 release it >>> [ ] +0 go ahead I don't care >>> [ ] -1 no, do not release it because... >>> >>> Ralph >>> >>> tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- >> project-2.0/ (revision 1031749) >>> >>> site: http://people.apache.org/~rgoers/commons-vfs/index.html >>> >>> The following artifacts have been staged to the Apache Nexus Staging >> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) >> https://repository.apache.org/cont
[VOTE] Cancelling vote for commons-email-1.3 based on RC1
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 like to call a vote to release commons-email-1.3 based on RC1 - see the release coordinates below. Tag: http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC1/ Site: http://people.apache.org/builds/commons/email/1.3/RC1/site/ Binaries: http://people.apache.org/builds/commons/email/1.3/RC1/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 - 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] Release commons-email-1.3 based on RC1
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 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 only. Oliver [INFO] Compilation failure \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\HtmlEmailTest.java:[536,19] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\HtmlEmailTest.java:[537,20] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[80,16] cannot resolve symbol symbol : class StringBuilder location: class org.apache.commons.mail.ImageHtmlEmailTest \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[80,40] cannot resolve symbol symbol : class StringBuilder location: class org.apache.commons.mail.ImageHtmlEmailTest \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[106,51] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[121,63] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[137,63] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\EmailTest.java:[1121,19] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String Am 06.11.2010 18:19, schrieb Siegfried Goeschl: Hi folks, I would like to call a vote to release commons-email-1.3 based on RC1 - see the release coordinates below. Tag: http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC1/ Site: http://people.apache.org/builds/commons/email/1.3/RC1/site/ Binaries: http://people.apache.org/builds/commons/email/1.3/RC1/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 - 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
Backwards incompatible changes and package names (was: Re: [VOTE] Release Commons VFS 2.0)
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 should not use use the same packages. So commons-vfs will continue to use org.apache.commons.vfs.* and commons-vfs2 will use org.apache.commons.vfs2.* And it must be possible to have both versions on the classpath without clashing. -h On Sun, Nov 7, 2010 at 13:45, James Carman wrote: > 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 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, 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 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 generify the code on java 5 for a 2.1. Then >>> we can do a java 6 release. Gary > > -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: > -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 that "has warnings" is a problem > - If deprecated APIs are still around, we can always remove them >>> later. Yes, release early, release often. I would encourage work to proceed immediately to implement this, >>> generics, and whatever Java 5 changes we can take advantage of. >>> >>> I've already done the main annotations (@Override and @Deprecation) >>> >>> I've started looking at generics. >>> >>> There's rather a lot of changes to fix all the Java 1.5 warnings, so >>> it will probably have to be done in stages, but I can start committing >>> soon >> >> Great news. It would be nice to release early release often a la XP with >>> a 2.1 themed release 'java 5 optimized' >> >> Gary >> >>> Gary > > -h > > On Fri, Nov 5, 2010 at 13:12, Ralph Goers >>> wrote: >> This is a vote to release Apache Commons VFS 2.0. >> >> Since the last candidate the jdk version has been changed to 1.5 and >>> the > requirement has been added to the web site main page. The test file >>> for > LargeTarTestCase has been added to the test-data directory, greatly >>> improving > the build time. Many of the messages from the test cases have been >>> removed. >> >> [ ] +1 release it >> [ ] +0 go ahead I don't care >> [ ] -1 no, do not release it because... >> >> Ralph >> >> tag: >>> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- > project-2.0/ (revision 1031749) >> >> site: http://people.apache.org/~rgoers/commons-vfs/index.html >> >> The following artifacts have been staged to the Apache Nexus Staging > repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) > >>> https://repository.apache.org/content/repositories/orgapachecommons-038/ >> >> commons-vfs-examples-2.0.jar >> commons-vfs-examples-2.0.pom >> commons-vfs-examples-2.0-javadoc.jar >> commons-vfs-examples-2.0-sources.jar >> commons-vfs-examples-2.0.jar.asc >> commons-vfs-examples-2.0-sources.jar.asc >> commons-vfs-examples-2.0.pom.asc >> commons-vfs-examples-2.0-javadoc.jar.asc >> commons-vfs-2.0-tests.jar >> commons-vfs-2.0-test-sources.jar.asc >> commons-vfs-2.0-sources.jar.asc >> commons-vfs-2.0.jar >> commons-vfs-2.0.pom >> commons-vfs-2.0-test-sources.jar >> commons-vfs-2.0-javadoc.jar >> commons-vfs-2.0-javadoc.jar.asc >> commons-vfs-2.0-tests.jar.asc >> commons-vfs-2.0.pom.asc >> commons-vfs-2.0-sources.jar >> commons-vfs-2.0.jar.asc >> commons-vfs-sandbox-2.0-tests.jar.asc >> commons-vfs-sandbox-2.0-s
Re: [SANSELAN] Status and future of Sanselan?
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 everything new in the release is covered > by closed JIRA tickets. > > >> What are the implications of Sanselan's having been elevated from > Apache Incubator to Commons status? > > I'm not sure what you mean? Has the code changed? No. > >> Are there any plans to release more complete Sanselan > documentation? > > Agreed, this is (also) long overdue. > >> Are there any known issues concerning discrepancies between the > current version (0.97) of Sanselan and the latest release (2.3, > April 26, 2010) of the EXIF standard? > > I haven't had a chance to look at this at all. > > Matthew > > > On Sun, Nov 7, 2010 at 2:14 PM, Henri Yandell wrote: >> 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 JIRA. >> >> Having discovered the pain of the iPod iThmb format, I find myself >> wanting Sanselan to support that :) >> >> Hen >> >> -- Forwarded message -- >> From: >> Date: Sun, Oct 31, 2010 at 10:51 AM >> Subject: [SANSELAN] Status and future of Sanselan? >> To: Commons Users List >> Cc: jeff_rothenb...@acm.org, n...@dad.org >> >> >> Does anyone know if a new release of Sanselan, after the current >> sanselan-0.97-incubator, is in the works? If so, are the >> features, enhancements, and status of the forthcoming version >> described anywhere? >> >> What are the implications of Sanselan's having been elevated from >> Apache Incubator to Commons status? >> >> Are there any plans to release more complete Sanselan >> documentation? >> >> Are there any known issues concerning discrepancies between the >> current version (0.97) of Sanselan and the latest release (2.3, >> April 26, 2010) of the EXIF standard? >> >> Norman Shapiro >> >> >> - >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >> For additional commands, e-mail: user-h...@commons.apache.org >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > 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] Release Commons VFS 2.0
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 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, 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 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 generify the code on java 5 for a 2.1. Then >> we can do a java 6 release. >>> >>> Gary -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: -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 that "has warnings" is a problem - If deprecated APIs are still around, we can always remove them >> later. >>> >>> Yes, release early, release often. >>> >>> I would encourage work to proceed immediately to implement this, >> generics, and whatever Java 5 changes we can take advantage of. >> >> I've already done the main annotations (@Override and @Deprecation) >> >> I've started looking at generics. >> >> There's rather a lot of changes to fix all the Java 1.5 warnings, so >> it will probably have to be done in stages, but I can start committing >> soon > > Great news. It would be nice to release early release often a la XP with >> a 2.1 themed release 'java 5 optimized' > > Gary > >> >>> Gary >>> -h On Fri, Nov 5, 2010 at 13:12, Ralph Goers >> wrote: > This is a vote to release Apache Commons VFS 2.0. > > Since the last candidate the jdk version has been changed to 1.5 and >> the requirement has been added to the web site main page. The test file >> for LargeTarTestCase has been added to the test-data directory, greatly >> improving the build time. Many of the messages from the test cases have been >> removed. > > [ ] +1 release it > [ ] +0 go ahead I don't care > [ ] -1 no, do not release it because... > > Ralph > > tag: >> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- project-2.0/ (revision 1031749) > > site: http://people.apache.org/~rgoers/commons-vfs/index.html > > The following artifacts have been staged to the Apache Nexus Staging repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) >> https://repository.apache.org/content/repositories/orgapachecommons-038/ > > commons-vfs-examples-2.0.jar > commons-vfs-examples-2.0.pom > commons-vfs-examples-2.0-javadoc.jar > commons-vfs-examples-2.0-sources.jar > commons-vfs-examples-2.0.jar.asc > commons-vfs-examples-2.0-sources.jar.asc > commons-vfs-examples-2.0.pom.asc > commons-vfs-examples-2.0-javadoc.jar.asc > commons-vfs-2.0-tests.jar > commons-vfs-2.0-test-sources.jar.asc > commons-vfs-2.0-sources.jar.asc > commons-vfs-2.0.jar > commons-vfs-2.0.pom > commons-vfs-2.0-test-sources.jar > commons-vfs-2.0-javadoc.jar > commons-vfs-2.0-javadoc.jar.asc > commons-vfs-2.0-tests.jar.asc > commons-vfs-2.0.pom.asc > commons-vfs-2.0-sources.jar > commons-vfs-2.0.jar.asc > commons-vfs-sandbox-2.0-tests.jar.asc > commons-vfs-sandbox-2.0-sources.jar > commons-vfs-sandbox-2.0-tests.jar > commons-vfs-sandbox-2.0-test-sources.jar.asc > commons-vfs-sandbox-2.0-sources.jar.asc > commons-vfs-sandbox-2.0.jar.asc > commons-vfs-sandbox-2.0-test-sources.jar > commons-vfs-sandbox-2.0-javadoc.jar > commons-vfs-sandbox-2.0.pom > commons-vfs-sandbox-2.0.jar > commons-vfs-sandbox-2.0-javadoc.jar.asc > commons-vfs-sandbox-2.0.pom.asc > commons-vfs-distribution-2.0-src.zip > commons-vfs-distribution-2.0.pom > commons-vfs-distribution-2.0-src.tar.gz.asc > commons-vfs-distribution-2.0-src.tar.gz > commons-vfs-distribution-2.0-bin.zip > commons
[continuum] BUILD FAILURE: Apache Commons - Commons BeanUtils - Default Maven 2 Build Definition (Java 1.5)
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 Build Number: 3 Exit code: 1 Building machine hostname: vmbuild Operating system : Linux(unknown) Java Home version : java version "1.6.0_20" Java(TM) SE Runtime Environment (build 1.6.0_20-b02) Java HotSpot(TM) 64-Bit Server VM (build 16.3-b01, mixed mode) Builder version : Apache Maven 2.2.1 (r801777; 2009-08-06 19:16:01+) Java version: 1.6.0_20 Java home: /usr/lib/jvm/java-6-sun-1.6.0.20/jre Default locale: en_US, platform encoding: ANSI_X3.4-1968 OS name: "linux" version: "2.6.32-24-server" arch: "amd64" Family: "unix" SCM Changes: No files changed Dependencies Changes: No dependencies changed Build Definition: POM filename: pom.xml Goals: clean install 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: 1180 Failures: 0 Errors: 1 Success Rate: 99 Total time: 90.542 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
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, 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 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 generify the code on java 5 for a 2.1. Then > we can do a java 6 release. >> >> Gary >>> >>> -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: >>> -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 that "has warnings" is a problem >>> - If deprecated APIs are still around, we can always remove them > later. >> >> Yes, release early, release often. >> >> I would encourage work to proceed immediately to implement this, > generics, and whatever Java 5 changes we can take advantage of. > > I've already done the main annotations (@Override and @Deprecation) > > I've started looking at generics. > > There's rather a lot of changes to fix all the Java 1.5 warnings, so > it will probably have to be done in stages, but I can start committing > soon Great news. It would be nice to release early release often a la XP with > a 2.1 themed release 'java 5 optimized' Gary > >> Gary >> >>> >>> -h >>> >>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers > wrote: This is a vote to release Apache Commons VFS 2.0. Since the last candidate the jdk version has been changed to 1.5 and > the >>> requirement has been added to the web site main page. The test file > for >>> LargeTarTestCase has been added to the test-data directory, greatly > improving >>> the build time. Many of the messages from the test cases have been > removed. [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because... Ralph tag: > https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- >>> project-2.0/ (revision 1031749) site: http://people.apache.org/~rgoers/commons-vfs/index.html The following artifacts have been staged to the Apache Nexus Staging >>> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) >>> > https://repository.apache.org/content/repositories/orgapachecommons-038/ commons-vfs-examples-2.0.jar commons-vfs-examples-2.0.pom commons-vfs-examples-2.0-javadoc.jar commons-vfs-examples-2.0-sources.jar commons-vfs-examples-2.0.jar.asc commons-vfs-examples-2.0-sources.jar.asc commons-vfs-examples-2.0.pom.asc commons-vfs-examples-2.0-javadoc.jar.asc commons-vfs-2.0-tests.jar commons-vfs-2.0-test-sources.jar.asc commons-vfs-2.0-sources.jar.asc commons-vfs-2.0.jar commons-vfs-2.0.pom commons-vfs-2.0-test-sources.jar commons-vfs-2.0-javadoc.jar commons-vfs-2.0-javadoc.jar.asc commons-vfs-2.0-tests.jar.asc commons-vfs-2.0.pom.asc commons-vfs-2.0-sources.jar commons-vfs-2.0.jar.asc commons-vfs-sandbox-2.0-tests.jar.asc commons-vfs-sandbox-2.0-sources.jar commons-vfs-sandbox-2.0-tests.jar commons-vfs-sandbox-2.0-test-sources.jar.asc commons-vfs-sandbox-2.0-sources.jar.asc commons-vfs-sandbox-2.0.jar.asc commons-vfs-sandbox-2.0-test-sources.jar commons-vfs-sandbox-2.0-javadoc.jar commons-vfs-sandbox-2.0.pom commons-vfs-sandbox-2.0.jar commons-vfs-sandbox-2.0-javadoc.jar.asc commons-vfs-sandbox-2.0.pom.asc commons-vfs-distribution-2.0-src.zip commons-vfs-distribution-2.0.pom commons-vfs-distribution-2.0-src.tar.gz.asc commons-vfs-distribution-2.0-src.tar.gz commons-vfs-distribution-2.0-bin.zip commons-vfs-distribution-2.0-bin.zip.asc commons-vfs-distribution-2.0-bin.tar.gz commons-vfs-distribution-2.0-src.zip.asc commons-vfs-distribution-2.0-bin.tar.gz.asc commons-vfs-distribution-2.0.pom.asc commons-vfs-project-2.0-site.xml.asc commons-vfs-project-2.0.pom commons-vfs-project-2.0-si
Re: [Math] FunctionEvaluationException in UnivariateRealFunction
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 passed an argument that doesn't fulfill pre-conditions, it throws an "IllegalArgumentException". But "FunctionEvaluationException" is not a subclass of "IllegalArgumentException". Users who are passed a "UnivariateRealFunction" instance should not rely that catching "FunctionEvaluationException" will work in most cases! So, should the Javadoc in fact be @throws IllegalArgumentException when the evaluation failed because of an invalid argument. @throws FunctionEvaluationException when the evaluation failed for any other reason. ? In the cases where we know both are possible, yes, including as much context- or algorithm-specific information as possible in each throws clause. I somewhat reluctantly agreed to dispense with checked exceptions, but we absolutely need to document the unchecked exceptions that we know can be thrown by [math]. The examples that Luc refers to above and the usefulness in general of the FunctionEvaluationException are consequences of the layered structure of the library and inclusion of user code "sandwiched" as he describes it within the [math] frameworks. Then, how do you extend your guidelines to make it clear when to use one or the other? +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] throws IllegalArgumentException, it is the result of argument checking of actual parameters immediately passed to a method. FunctionEvaluationException - may be advertised by a method that may encounter errors evaluating a function. This *should* be thrown only in circumstances where at the level of the activated function IllegalArgumentException is not appropriate and it *should* indicate that while formal preconditions of the method have not been violated, an irrecoverable error has occurred evaluating a function at some (usually lower) level of the call stack. Convergence failures, runtime exceptions (even IllegalArgumentExceptions) in user code or lower level methods can cause (and should be wrapped in) FunctionEvaluationExceptions. You could write a document that would explain how good it would be if all programs were using the same exceptions. But I must point out that CM isn't a good example, with its policy of no dependencies. Why would anyone depend on CM just for the sake of using CM exceptions? I think you are missing the point here - our APIs can encourage consistent use of exceptions by user code that uses and/or integrates with [math]. These are the kinds of things we need to talk about in refactoring exceptions. Our API - including all advertised exceptions - needs to help users understand what we - and they - are doing, not just minimize the amount of code they need to write or simplify our lives as maintainers. This is especially true of the more complex algorithms and frameworks where user code plugs into [math]. Phil Best regards, Gilles - 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] Release Commons VFS 2.0
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 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 generify the code on java 5 for a 2.1. Then we can do a java 6 release. > > Gary >> >> -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: >> -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 that "has warnings" is a problem >> - If deprecated APIs are still around, we can always remove them later. > > Yes, release early, release often. > > I would encourage work to proceed immediately to implement this, generics, and whatever Java 5 changes we can take advantage of. I've already done the main annotations (@Override and @Deprecation) I've started looking at generics. There's rather a lot of changes to fix all the Java 1.5 warnings, so it will probably have to be done in stages, but I can start committing soon >>> >>> Great news. It would be nice to release early release often a la XP with a 2.1 themed release 'java 5 optimized' >>> >>> Gary >>> > Gary > >> >> -h >> >> On Fri, Nov 5, 2010 at 13:12, Ralph Goers wrote: >>> This is a vote to release Apache Commons VFS 2.0. >>> >>> Since the last candidate the jdk version has been changed to 1.5 and the >> requirement has been added to the web site main page. The test file for >> LargeTarTestCase has been added to the test-data directory, greatly improving >> the build time. Many of the messages from the test cases have been removed. >>> >>> [ ] +1 release it >>> [ ] +0 go ahead I don't care >>> [ ] -1 no, do not release it because... >>> >>> Ralph >>> >>> tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- >> project-2.0/ (revision 1031749) >>> >>> site: http://people.apache.org/~rgoers/commons-vfs/index.html >>> >>> The following artifacts have been staged to the Apache Nexus Staging >> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) >> https://repository.apache.org/content/repositories/orgapachecommons-038/ >>> >>> commons-vfs-examples-2.0.jar >>> commons-vfs-examples-2.0.pom >>> commons-vfs-examples-2.0-javadoc.jar >>> commons-vfs-examples-2.0-sources.jar >>> commons-vfs-examples-2.0.jar.asc >>> commons-vfs-examples-2.0-sources.jar.asc >>> commons-vfs-examples-2.0.pom.asc >>> commons-vfs-examples-2.0-javadoc.jar.asc >>> commons-vfs-2.0-tests.jar >>> commons-vfs-2.0-test-sources.jar.asc >>> commons-vfs-2.0-sources.jar.asc >>> commons-vfs-2.0.jar >>> commons-vfs-2.0.pom >>> commons-vfs-2.0-test-sources.jar >>> commons-vfs-2.0-javadoc.jar >>> commons-vfs-2.0-javadoc.jar.asc >>> commons-vfs-2.0-tests.jar.asc >>> commons-vfs-2.0.pom.asc >>> commons-vfs-2.0-sources.jar >>> commons-vfs-2.0.jar.asc >>> commons-vfs-sandbox-2.0-tests.jar.asc >>> commons-vfs-sandbox-2.0-sources.jar >>> commons-vfs-sandbox-2.0-tests.jar >>> commons-vfs-sandbox-2.0-test-sources.jar.asc >>> commons-vfs-sandbox-2.0-sources.jar.asc >>> commons-vfs-sandbox-2.0.jar.asc >>> commons-vfs-sandbox-2.0-test-sources.jar >>> commons-vfs-sandbox-2.0-javadoc.jar >>> commons-vfs-sandbox-2.0.pom >>> commons-vfs-sandbox-2.0.jar >>> commons-vfs-sandbox-2.0-javadoc.jar.asc >>> commons-vfs-sandbox-2.0.pom.asc >>> commons-vfs-distribution-2.0-src.zip >>> commons-vfs-distribution-2.0.pom >>> commons-vfs-distribution-2.0-src.tar.gz.asc >>> commons-vfs-distribution-2.0-src.tar.gz >>> commons-vfs-distribution-2.0-bin.zip >>> commons-vfs-distribution-2.0-bin.zip.asc >>> commons-vfs-distribution-2.0-bin.tar.gz >>> commons-vfs-distribution-2.0-src.zip.asc >>> commons-vfs-distribution-2.0-bin.tar.gz.asc >>> commons-vfs-distribution-2.0.pom.asc >>> commons-vfs-project-2.0-site.xml.asc >>> commons-vfs-project-2.0.pom >>> commons-vfs-project-2.0-site.xml >>> commons-vfs-project-2.0.pom.asc >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org > > > --
Re: How can I get Commons-net-2.1 Source and Binaries
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 interested to test and vote on it if I step up as RM. If not, then it would definitely be time to consider the Attic. > -- 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 October 2010 13:31, James Carman wrote: >> Why does the site list it in the release notes? > > Because that was correct at the time the site was updated, i.e. before > 2.1 was even proposed for release. > > Note that there is no date associated with the release. > > However, it's a bit misleading now, so I'll change it to 2.2. > >> Do we need to move all of the jira issues to 2.2? > > Possibly. Sounds like a discussion for the dev list. > >> On Oct 14, 2010 3:36 AM, "Jörg Schaible" wrote: >>> 陳雪傑 wrote: >>> Hi all How can I get Commons-net-2.1 Source and Binaries? I want get publiced Commons-net-2.1 Source and Binaries from apache, but the page (http://commons.apache.org/net/download_net.cgi) do not provide it. >>> >>> You cannot, since it was never officially released. So, yes, there is a >> tag >>> in Subversion, but nobody knows, who spread it into public, what it >> actually >>> contains and you're on your own using this code. Therefore you cannot >>> download any binaries or tar balls, it has no direct support here. >> Actually >>> you should use version 2.0 until we release the next version which will be >> >>> 2.2. >>> >>> - Jörg >>> >>> >>> - >>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >>> For additional commands, e-mail: user-h...@commons.apache.org >>> >> > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release commons-email-1.3 based on RC1
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 only. Oliver [INFO] Compilation failure \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\HtmlEmailTest.java:[536,19] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\HtmlEmailTest.java:[537,20] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[80,16] cannot resolve symbol symbol : class StringBuilder location: class org.apache.commons.mail.ImageHtmlEmailTest \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[80,40] cannot resolve symbol symbol : class StringBuilder location: class org.apache.commons.mail.ImageHtmlEmailTest \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[106,51] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[121,63] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\ImageHtmlEmailTest.java:[137,63] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String \data\projects\OpenSource\email\commons-email-1.3-src\src\test\org\apache\common s\mail\EmailTest.java:[1121,19] cannot resolve symbol symbol : method contains (java.lang.String) location: class java.lang.String Am 06.11.2010 18:19, schrieb Siegfried Goeschl: Hi folks, I would like to call a vote to release commons-email-1.3 based on RC1 - see the release coordinates below. Tag: http://svn.apache.org/viewvc/commons/proper/email/tags/EMAIL_1_3_RC1/ Site: http://people.apache.org/builds/commons/email/1.3/RC1/site/ Binaries: http://people.apache.org/builds/commons/email/1.3/RC1/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 - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: Komogorov distribution WASF Re: [jira] Commented: (MATH-431) New tests: Wilcoxon signed-rank test and Mann-Whitney U
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 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 looking for an alternative >> good >> algorithm to implement. All suggestions / unencumbered patches >> welcome! >> >> See comments on the MATH-431 for other questions. >> > Just to be sure of what you mean: > Do you want to have a two-sample Kolmogorov-Smirnov test for equality > of distributions in addition to the Mann-Whitney? Or do you need the > Kolmogorov-Smirnov distribution (as stated for example at > > > > http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test#Kolmogorov_distribution > ) in regards to the MATH-428? Sorry, but I'm at bit confused :-). The goal is to implement the KS test for equality of distributions (or homogeneity against a reference distribution). To do that we need at least critical values of the Kolmogorov distribution. The natural way for us to do that would be to implement the full distribution which would be nice to have in the distributions package. Phil >>> >>> Have you read "Evaluating Kolmogorov’s Distribution" by Marsaglia et >>> al. available on http://www.jstatsoft.org/v08/i18/paper ? And do you >>> think their approach would be the way to go? >>> >>> I am not sure it is best. See the comments here: >>> http://www.iro.umontreal.ca/~lecuyer/myftp/papers/ksdist.pdf >>> >>> Phil >> >> Thanks. It looks quite thorough, indeed. Was it the Java >> implementation you didn't get a consent to release under ASL? >>> > Yes. I am interested in your and others' opinions on the various algorithms > reviewed there. Could be the Marsaglia reference above is adequate for a > start. I'll try to make a short comparison of the two methods ASAP. > > Phil >>> Interesting approach for the exact algorithm for Wilcoxon. If we stay with this, we should ack the original author of the algorithm in the javadoc. Looks OK to use. > >>> >>> Agree - both on the approach and legal part! Does the author need to >>> sign anything but write a mail? Regarding the difference from R, what I usually do in this case is look at the R sources to try to explain the difference. Most likely in this case, what is going on is they are using a different estimation algorithm for small n or treating ties differently. The ranking options that we use were largely adapted from R, so if that is the problem, it should be easy to test. We need to convince ourselves that ours is better or at least a legitimate alternative. I will take a close look this evening, but it looks like the algorithm you are using should be exact. If we can't reconcile the difference with R, it would be good to find a way to validate correct functioning of the algorithm by manufacturing reference data with known p. >>> >>> I'll try to investigate the difference, hopefully tomorrow, so that >>> formal tests can be written and included. > New tests: Wilcoxon signed-rank test and Mann-Whitney U > --- > > Key: MATH-431 > URL: https://issues.apache.org/jira/browse/MATH-431 > Project: Commons Math > Issue Type: New Feature > Reporter: Mikkel Meyer Andersen > Assignee: Mikkel Meyer Andersen > Priority: Minor > Attachments: MannWhitneyUTest.java, > MannWhitneyUTestImpl.java, > WilcoxonSignedRankTest.java, WilcoxonSignedRankTestImpl.java > > Original Estimate: 4h > Remaining Estimate: 4h > > Wilcoxon signed-rank test and Mann-Whitney U are commonly used > non-parametric statistical hypothesis tests (e.g. instead of > various > t-tests > when normality is not present). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. >> >> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.o
Re: [VOTE] Release Commons VFS 2.0
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 generify the code on java 5 for a 2.1. Then we can do a java 6 release. Gary > > -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: > -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 that "has warnings" is a problem > - If deprecated APIs are still around, we can always remove them later. Yes, release early, release often. I would encourage work to proceed immediately to implement this, generics, and whatever Java 5 changes we can take advantage of. >>> >>> I've already done the main annotations (@Override and @Deprecation) >>> >>> I've started looking at generics. >>> >>> There's rather a lot of changes to fix all the Java 1.5 warnings, so >>> it will probably have to be done in stages, but I can start committing >>> soon >> >> Great news. It would be nice to release early release often a la XP with a >> 2.1 themed release 'java 5 optimized' >> >> Gary >> >>> Gary > > -h > > On Fri, Nov 5, 2010 at 13:12, Ralph Goers > wrote: >> This is a vote to release Apache Commons VFS 2.0. >> >> Since the last candidate the jdk version has been changed to 1.5 and the > requirement has been added to the web site main page. The test file for > LargeTarTestCase has been added to the test-data directory, greatly > improving > the build time. Many of the messages from the test cases have been > removed. >> >> [ ] +1 release it >> [ ] +0 go ahead I don't care >> [ ] -1 no, do not release it because... >> >> Ralph >> >> tag: >> https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- > project-2.0/ (revision 1031749) >> >> site: http://people.apache.org/~rgoers/commons-vfs/index.html >> >> The following artifacts have been staged to the Apache Nexus Staging > repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) > https://repository.apache.org/content/repositories/orgapachecommons-038/ >> >> commons-vfs-examples-2.0.jar >> commons-vfs-examples-2.0.pom >> commons-vfs-examples-2.0-javadoc.jar >> commons-vfs-examples-2.0-sources.jar >> commons-vfs-examples-2.0.jar.asc >> commons-vfs-examples-2.0-sources.jar.asc >> commons-vfs-examples-2.0.pom.asc >> commons-vfs-examples-2.0-javadoc.jar.asc >> commons-vfs-2.0-tests.jar >> commons-vfs-2.0-test-sources.jar.asc >> commons-vfs-2.0-sources.jar.asc >> commons-vfs-2.0.jar >> commons-vfs-2.0.pom >> commons-vfs-2.0-test-sources.jar >> commons-vfs-2.0-javadoc.jar >> commons-vfs-2.0-javadoc.jar.asc >> commons-vfs-2.0-tests.jar.asc >> commons-vfs-2.0.pom.asc >> commons-vfs-2.0-sources.jar >> commons-vfs-2.0.jar.asc >> commons-vfs-sandbox-2.0-tests.jar.asc >> commons-vfs-sandbox-2.0-sources.jar >> commons-vfs-sandbox-2.0-tests.jar >> commons-vfs-sandbox-2.0-test-sources.jar.asc >> commons-vfs-sandbox-2.0-sources.jar.asc >> commons-vfs-sandbox-2.0.jar.asc >> commons-vfs-sandbox-2.0-test-sources.jar >> commons-vfs-sandbox-2.0-javadoc.jar >> commons-vfs-sandbox-2.0.pom >> commons-vfs-sandbox-2.0.jar >> commons-vfs-sandbox-2.0-javadoc.jar.asc >> commons-vfs-sandbox-2.0.pom.asc >> commons-vfs-distribution-2.0-src.zip >> commons-vfs-distribution-2.0.pom >> commons-vfs-distribution-2.0-src.tar.gz.asc >> commons-vfs-distribution-2.0-src.tar.gz >> commons-vfs-distribution-2.0-bin.zip >> commons-vfs-distribution-2.0-bin.zip.asc >> commons-vfs-distribution-2.0-bin.tar.gz >> commons-vfs-distribution-2.0-src.zip.asc >> commons-vfs-distribution-2.0-bin.tar.gz.asc >> commons-vfs-distribution-2.0.pom.asc >> commons-vfs-project-2.0-site.xml.asc >> commons-vfs-project-2.0.pom >> commons-vfs-project-2.0-site.xml >> commons-vfs-project-2.0.pom.asc > > - > 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] Release Commons VFS 2.0
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: -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 that "has warnings" is a problem - If deprecated APIs are still around, we can always remove them later. >>> >>> Yes, release early, release often. >>> >>> I would encourage work to proceed immediately to implement this, generics, >>> and whatever Java 5 changes we can take advantage of. >> >> I've already done the main annotations (@Override and @Deprecation) >> >> I've started looking at generics. >> >> There's rather a lot of changes to fix all the Java 1.5 warnings, so >> it will probably have to be done in stages, but I can start committing >> soon > > Great news. It would be nice to release early release often a la XP with a > 2.1 themed release 'java 5 optimized' > > Gary > >> >>> Gary >>> -h On Fri, Nov 5, 2010 at 13:12, Ralph Goers wrote: > This is a vote to release Apache Commons VFS 2.0. > > Since the last candidate the jdk version has been changed to 1.5 and the requirement has been added to the web site main page. The test file for LargeTarTestCase has been added to the test-data directory, greatly improving the build time. Many of the messages from the test cases have been removed. > > [ ] +1 release it > [ ] +0 go ahead I don't care > [ ] -1 no, do not release it because... > > Ralph > > tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- project-2.0/ (revision 1031749) > > site: http://people.apache.org/~rgoers/commons-vfs/index.html > > The following artifacts have been staged to the Apache Nexus Staging repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) https://repository.apache.org/content/repositories/orgapachecommons-038/ > > commons-vfs-examples-2.0.jar > commons-vfs-examples-2.0.pom > commons-vfs-examples-2.0-javadoc.jar > commons-vfs-examples-2.0-sources.jar > commons-vfs-examples-2.0.jar.asc > commons-vfs-examples-2.0-sources.jar.asc > commons-vfs-examples-2.0.pom.asc > commons-vfs-examples-2.0-javadoc.jar.asc > commons-vfs-2.0-tests.jar > commons-vfs-2.0-test-sources.jar.asc > commons-vfs-2.0-sources.jar.asc > commons-vfs-2.0.jar > commons-vfs-2.0.pom > commons-vfs-2.0-test-sources.jar > commons-vfs-2.0-javadoc.jar > commons-vfs-2.0-javadoc.jar.asc > commons-vfs-2.0-tests.jar.asc > commons-vfs-2.0.pom.asc > commons-vfs-2.0-sources.jar > commons-vfs-2.0.jar.asc > commons-vfs-sandbox-2.0-tests.jar.asc > commons-vfs-sandbox-2.0-sources.jar > commons-vfs-sandbox-2.0-tests.jar > commons-vfs-sandbox-2.0-test-sources.jar.asc > commons-vfs-sandbox-2.0-sources.jar.asc > commons-vfs-sandbox-2.0.jar.asc > commons-vfs-sandbox-2.0-test-sources.jar > commons-vfs-sandbox-2.0-javadoc.jar > commons-vfs-sandbox-2.0.pom > commons-vfs-sandbox-2.0.jar > commons-vfs-sandbox-2.0-javadoc.jar.asc > commons-vfs-sandbox-2.0.pom.asc > commons-vfs-distribution-2.0-src.zip > commons-vfs-distribution-2.0.pom > commons-vfs-distribution-2.0-src.tar.gz.asc > commons-vfs-distribution-2.0-src.tar.gz > commons-vfs-distribution-2.0-bin.zip > commons-vfs-distribution-2.0-bin.zip.asc > commons-vfs-distribution-2.0-bin.tar.gz > commons-vfs-distribution-2.0-src.zip.asc > commons-vfs-distribution-2.0-bin.tar.gz.asc > commons-vfs-distribution-2.0.pom.asc > commons-vfs-project-2.0-site.xml.asc > commons-vfs-project-2.0.pom > commons-vfs-project-2.0-site.xml > commons-vfs-project-2.0.pom.asc - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > ---
Re: [Primitives] Does anyone use this?
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 Commons Users; moving conversation to Dev on the 2nd point. Hen On Tue, Nov 2, 2010 at 1:52 PM, sebb wrote: > Note that lack of recent activity is not necessarily a bad sign; in > this case I think it's because the code is working fine. > I could find no outstanding bugs for the component. > > On 2 November 2010 20:10, Brian Pontarelli wrote: >> I probably wouldn't use these collections in a factory context. If I'm >> concerned about speed and size, I'm going to create the primitive collection >> using the constructor and then use it directly. Adding in any factories, >> AOP, etc. is just going to add overhead. >> >> The original issue is really whether or not the commons library is still >> active or if Trove is a better choice. I'd say either library will work and >> I've used both. Another thing to think about is your comfort with licenses. >> I prefer ASL over LGPL as a rule of thumb and Trove is LGPL. I tend to avoid >> anything with the letters G, P and L in the license. But if you can find >> something with BSD, that's the way to go. >> >> ;) >> >> -bp >> >> >> On Nov 2, 2010, at 1:24 PM, Martin Gainty wrote: >> >>> >>> also lookup methods from factories will reliably lookup >>> ArrayList when bean definition has attribute >>> dependency-check="object" but wont lookup a collection of primitives such >>> as int []PrimitiveDataTypeVariable even when the bean definition specified >>> dependency-check="simple" >>> >>> http://static.springsource.org/spring/docs/1.2.9/reference/beans.html >>> >>> thanks, >>> Martin Gainty >>> __ >>> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité >>> >>> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene >>> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte >>> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht >>> dient lediglich dem Austausch von Informationen und entfaltet keine >>> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von >>> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. >>> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le >>> destinataire prévu, nous te demandons avec bonté que pour satisfaire >>> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie >>> de ceci est interdite. Ce message sert à l'information seulement et n'aura >>> pas n'importe quel effet légalement obligatoire. Étant donné que les email >>> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter >>> aucune responsabilité pour le contenu fourni. >>> >>> >>> >>> >>> From: josiah.d.hasw...@hp.com To: u...@commons.apache.org Date: Tue, 2 Nov 2010 18:42:29 + Subject: RE: [Primitives] Does anyone use this? Gnu Trove includes a set of benchmarks vs. the JCF. I don't understand why this is so controversial; a developer should be able to assess the suitability of a library for his or her purposes without it turning into a huge debate. If dependency-management is an issue, Trove is available from numerous Ivy/Maven repositories. Joe H. | HP Software -Original Message- From: Martin Gainty [mailto:mgai...@hotmail.com] Sent: Tuesday, November 02, 2010 11:41 AM To: u...@commons.apache.org Subject: RE: [Primitives] Does anyone use this? Brian how does primitive collections implementation perform better than JDK collections? thanks, Martin __ please do not alter or disrupt this transmission. thank you > Subject: Re: [Primitives] Does anyone use this? > From: br...@pontarelli.com > Date: Tue, 2 Nov 2010 11:32:01 -0600 > To: u...@commons.apache.org > > I would assume once you get out of the autoboxing caches the performance > will get even worse. It really depends on the application, but I've found > a number of spots where primitive collections work much better than > autoboxing and JDK collections. > > -bp > > > On Nov 2, 2010, at 11:25 AM, James Carman wrote: > >> Yet another dependency to add to the mix. >> >> On Tue, Nov 2, 2010 at 1:17 PM, Cogen, David - 1008 - MITLL >> wrote: >>> >>> >>> From: jcar...@carmanconsulting.com [jcar...@carmanconsulting.com] On >>> Behalf Of James Carman [ja...@carmanconsulting.com] >>> Sent: Tuesday, November 02, 2010 12:30 PM >>> To: Commons Users
Re: [SANSELAN] Status and future of Sanselan?
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 from Apache Incubator to Commons status? I'm not sure what you mean? Has the code changed? No. > Are there any plans to release more complete Sanselan documentation? Agreed, this is (also) long overdue. > Are there any known issues concerning discrepancies between the current version (0.97) of Sanselan and the latest release (2.3, April 26, 2010) of the EXIF standard? I haven't had a chance to look at this at all. Matthew On Sun, Nov 7, 2010 at 2:14 PM, Henri Yandell wrote: > 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 JIRA. > > Having discovered the pain of the iPod iThmb format, I find myself > wanting Sanselan to support that :) > > Hen > > -- Forwarded message -- > From: > Date: Sun, Oct 31, 2010 at 10:51 AM > Subject: [SANSELAN] Status and future of Sanselan? > To: Commons Users List > Cc: jeff_rothenb...@acm.org, n...@dad.org > > > Does anyone know if a new release of Sanselan, after the current > sanselan-0.97-incubator, is in the works? If so, are the > features, enhancements, and status of the forthcoming version > described anywhere? > > What are the implications of Sanselan's having been elevated from > Apache Incubator to Commons status? > > Are there any plans to release more complete Sanselan > documentation? > > Are there any known issues concerning discrepancies between the > current version (0.97) of Sanselan and the latest release (2.3, > April 26, 2010) of the EXIF standard? > > Norman Shapiro > > > - > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > For additional commands, e-mail: user-h...@commons.apache.org > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
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 Commons VFS 2.0 >>> >>> +1 >>> >>> - I don't think that "has warnings" is a problem >>> - If deprecated APIs are still around, we can always remove them later. >> >> Yes, release early, release often. >> >> I would encourage work to proceed immediately to implement this, generics, >> and whatever Java 5 changes we can take advantage of. > > I've already done the main annotations (@Override and @Deprecation) > > I've started looking at generics. > > There's rather a lot of changes to fix all the Java 1.5 warnings, so > it will probably have to be done in stages, but I can start committing > soon Great news. It would be nice to release early release often a la XP with a 2.1 themed release 'java 5 optimized' Gary > >> Gary >> >>> >>> -h >>> >>> On Fri, Nov 5, 2010 at 13:12, Ralph Goers >>> wrote: This is a vote to release Apache Commons VFS 2.0. Since the last candidate the jdk version has been changed to 1.5 and the >>> requirement has been added to the web site main page. The test file for >>> LargeTarTestCase has been added to the test-data directory, greatly >>> improving >>> the build time. Many of the messages from the test cases have been removed. [ ] +1 release it [ ] +0 go ahead I don't care [ ] -1 no, do not release it because... Ralph tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- >>> project-2.0/ (revision 1031749) site: http://people.apache.org/~rgoers/commons-vfs/index.html The following artifacts have been staged to the Apache Nexus Staging >>> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) >>> https://repository.apache.org/content/repositories/orgapachecommons-038/ commons-vfs-examples-2.0.jar commons-vfs-examples-2.0.pom commons-vfs-examples-2.0-javadoc.jar commons-vfs-examples-2.0-sources.jar commons-vfs-examples-2.0.jar.asc commons-vfs-examples-2.0-sources.jar.asc commons-vfs-examples-2.0.pom.asc commons-vfs-examples-2.0-javadoc.jar.asc commons-vfs-2.0-tests.jar commons-vfs-2.0-test-sources.jar.asc commons-vfs-2.0-sources.jar.asc commons-vfs-2.0.jar commons-vfs-2.0.pom commons-vfs-2.0-test-sources.jar commons-vfs-2.0-javadoc.jar commons-vfs-2.0-javadoc.jar.asc commons-vfs-2.0-tests.jar.asc commons-vfs-2.0.pom.asc commons-vfs-2.0-sources.jar commons-vfs-2.0.jar.asc commons-vfs-sandbox-2.0-tests.jar.asc commons-vfs-sandbox-2.0-sources.jar commons-vfs-sandbox-2.0-tests.jar commons-vfs-sandbox-2.0-test-sources.jar.asc commons-vfs-sandbox-2.0-sources.jar.asc commons-vfs-sandbox-2.0.jar.asc commons-vfs-sandbox-2.0-test-sources.jar commons-vfs-sandbox-2.0-javadoc.jar commons-vfs-sandbox-2.0.pom commons-vfs-sandbox-2.0.jar commons-vfs-sandbox-2.0-javadoc.jar.asc commons-vfs-sandbox-2.0.pom.asc commons-vfs-distribution-2.0-src.zip commons-vfs-distribution-2.0.pom commons-vfs-distribution-2.0-src.tar.gz.asc commons-vfs-distribution-2.0-src.tar.gz commons-vfs-distribution-2.0-bin.zip commons-vfs-distribution-2.0-bin.zip.asc commons-vfs-distribution-2.0-bin.tar.gz commons-vfs-distribution-2.0-src.zip.asc commons-vfs-distribution-2.0-bin.tar.gz.asc commons-vfs-distribution-2.0.pom.asc commons-vfs-project-2.0-site.xml.asc commons-vfs-project-2.0.pom commons-vfs-project-2.0-site.xml commons-vfs-project-2.0.pom.asc >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Fwd: How can I get Commons-net-2.1 Source and Binaries
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 October 2010 13:31, James Carman wrote: > Why does the site list it in the release notes? Because that was correct at the time the site was updated, i.e. before 2.1 was even proposed for release. Note that there is no date associated with the release. However, it's a bit misleading now, so I'll change it to 2.2. > Do we need to move all of the jira issues to 2.2? Possibly. Sounds like a discussion for the dev list. > On Oct 14, 2010 3:36 AM, "Jörg Schaible" wrote: >> 陳雪傑 wrote: >> >>> >>> Hi all >>> >>> How can I get Commons-net-2.1 Source and Binaries? >>> >>> I want get publiced Commons-net-2.1 Source and Binaries from apache, >>> but the page (http://commons.apache.org/net/download_net.cgi) do not >>> provide it. >> >> You cannot, since it was never officially released. So, yes, there is a > tag >> in Subversion, but nobody knows, who spread it into public, what it > actually >> contains and you're on your own using this code. Therefore you cannot >> download any binaries or tar balls, it has no direct support here. > Actually >> you should use version 2.0 until we release the next version which will be > >> 2.2. >> >> - Jörg >> >> >> - >> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org >> For additional commands, e-mail: user-h...@commons.apache.org >> > - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Fwd: [SANSELAN] Status and future of Sanselan?
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 JIRA. Having discovered the pain of the iPod iThmb format, I find myself wanting Sanselan to support that :) Hen -- Forwarded message -- From: Date: Sun, Oct 31, 2010 at 10:51 AM Subject: [SANSELAN] Status and future of Sanselan? To: Commons Users List Cc: jeff_rothenb...@acm.org, n...@dad.org Does anyone know if a new release of Sanselan, after the current sanselan-0.97-incubator, is in the works? If so, are the features, enhancements, and status of the forthcoming version described anywhere? What are the implications of Sanselan's having been elevated from Apache Incubator to Commons status? Are there any plans to release more complete Sanselan documentation? Are there any known issues concerning discrepancies between the current version (0.97) of Sanselan and the latest release (2.3, April 26, 2010) of the EXIF standard? Norman Shapiro - To unsubscribe, e-mail: user-unsubscr...@commons.apache.org For additional commands, e-mail: user-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [VOTE] Release Commons VFS 2.0
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 that "has warnings" is a problem >> - If deprecated APIs are still around, we can always remove them later. > > Yes, release early, release often. > > I would encourage work to proceed immediately to implement this, generics, > and whatever Java 5 changes we can take advantage of. I've already done the main annotations (@Override and @Deprecation) I've started looking at generics. There's rather a lot of changes to fix all the Java 1.5 warnings, so it will probably have to be done in stages, but I can start committing soon. > Gary > >> >> -h >> >> On Fri, Nov 5, 2010 at 13:12, Ralph Goers wrote: >> > This is a vote to release Apache Commons VFS 2.0. >> > >> > Since the last candidate the jdk version has been changed to 1.5 and the >> requirement has been added to the web site main page. The test file for >> LargeTarTestCase has been added to the test-data directory, greatly improving >> the build time. Many of the messages from the test cases have been removed. >> > >> > [ ] +1 release it >> > [ ] +0 go ahead I don't care >> > [ ] -1 no, do not release it because... >> > >> > Ralph >> > >> > tag: https://svn.apache.org/repos/asf/commons/proper/vfs/tags/commons-vfs- >> project-2.0/ (revision 1031749) >> > >> > site: http://people.apache.org/~rgoers/commons-vfs/index.html >> > >> > The following artifacts have been staged to the Apache Nexus Staging >> repository org.apache.commons-038 (u:rgoers, a:38.101.196.246) >> https://repository.apache.org/content/repositories/orgapachecommons-038/ >> > >> > commons-vfs-examples-2.0.jar >> > commons-vfs-examples-2.0.pom >> > commons-vfs-examples-2.0-javadoc.jar >> > commons-vfs-examples-2.0-sources.jar >> > commons-vfs-examples-2.0.jar.asc >> > commons-vfs-examples-2.0-sources.jar.asc >> > commons-vfs-examples-2.0.pom.asc >> > commons-vfs-examples-2.0-javadoc.jar.asc >> > commons-vfs-2.0-tests.jar >> > commons-vfs-2.0-test-sources.jar.asc >> > commons-vfs-2.0-sources.jar.asc >> > commons-vfs-2.0.jar >> > commons-vfs-2.0.pom >> > commons-vfs-2.0-test-sources.jar >> > commons-vfs-2.0-javadoc.jar >> > commons-vfs-2.0-javadoc.jar.asc >> > commons-vfs-2.0-tests.jar.asc >> > commons-vfs-2.0.pom.asc >> > commons-vfs-2.0-sources.jar >> > commons-vfs-2.0.jar.asc >> > commons-vfs-sandbox-2.0-tests.jar.asc >> > commons-vfs-sandbox-2.0-sources.jar >> > commons-vfs-sandbox-2.0-tests.jar >> > commons-vfs-sandbox-2.0-test-sources.jar.asc >> > commons-vfs-sandbox-2.0-sources.jar.asc >> > commons-vfs-sandbox-2.0.jar.asc >> > commons-vfs-sandbox-2.0-test-sources.jar >> > commons-vfs-sandbox-2.0-javadoc.jar >> > commons-vfs-sandbox-2.0.pom >> > commons-vfs-sandbox-2.0.jar >> > commons-vfs-sandbox-2.0-javadoc.jar.asc >> > commons-vfs-sandbox-2.0.pom.asc >> > commons-vfs-distribution-2.0-src.zip >> > commons-vfs-distribution-2.0.pom >> > commons-vfs-distribution-2.0-src.tar.gz.asc >> > commons-vfs-distribution-2.0-src.tar.gz >> > commons-vfs-distribution-2.0-bin.zip >> > commons-vfs-distribution-2.0-bin.zip.asc >> > commons-vfs-distribution-2.0-bin.tar.gz >> > commons-vfs-distribution-2.0-src.zip.asc >> > commons-vfs-distribution-2.0-bin.tar.gz.asc >> > commons-vfs-distribution-2.0.pom.asc >> > commons-vfs-project-2.0-site.xml.asc >> > commons-vfs-project-2.0.pom >> > commons-vfs-project-2.0-site.xml >> > commons-vfs-project-2.0.pom.asc >> >> - >> 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: Komogorov distribution WASF Re: [jira] Commented: (MATH-431) New tests: Wilcoxon signed-rank test and Mann-Whitney U
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 failed in getting consent to release under ASL. So at this point, I am looking for an alternative good algorithm to implement. All suggestions / unencumbered patches welcome! See comments on the MATH-431 for other questions. Just to be sure of what you mean: Do you want to have a two-sample Kolmogorov-Smirnov test for equality of distributions in addition to the Mann-Whitney? Or do you need the Kolmogorov-Smirnov distribution (as stated for example at http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test#Kolmogorov_distribution ) in regards to the MATH-428? Sorry, but I'm at bit confused :-). The goal is to implement the KS test for equality of distributions (or homogeneity against a reference distribution). To do that we need at least critical values of the Kolmogorov distribution. The natural way for us to do that would be to implement the full distribution which would be nice to have in the distributions package. Phil Have you read "Evaluating Kolmogorov’s Distribution" by Marsaglia et al. available on http://www.jstatsoft.org/v08/i18/paper ? And do you think their approach would be the way to go? I am not sure it is best. See the comments here: http://www.iro.umontreal.ca/~lecuyer/myftp/papers/ksdist.pdf Phil Thanks. It looks quite thorough, indeed. Was it the Java implementation you didn't get a consent to release under ASL? Yes. I am interested in your and others' opinions on the various algorithms reviewed there. Could be the Marsaglia reference above is adequate for a start. Phil Interesting approach for the exact algorithm for Wilcoxon. If we stay with this, we should ack the original author of the algorithm in the javadoc. Looks OK to use. Agree - both on the approach and legal part! Does the author need to sign anything but write a mail? Regarding the difference from R, what I usually do in this case is look at the R sources to try to explain the difference. Most likely in this case, what is going on is they are using a different estimation algorithm for small n or treating ties differently. The ranking options that we use were largely adapted from R, so if that is the problem, it should be easy to test. We need to convince ourselves that ours is better or at least a legitimate alternative. I will take a close look this evening, but it looks like the algorithm you are using should be exact. If we can't reconcile the difference with R, it would be good to find a way to validate correct functioning of the algorithm by manufacturing reference data with known p. I'll try to investigate the difference, hopefully tomorrow, so that formal tests can be written and included. New tests: Wilcoxon signed-rank test and Mann-Whitney U --- Key: MATH-431 URL: https://issues.apache.org/jira/browse/MATH-431 Project: Commons Math Issue Type: New Feature Reporter: Mikkel Meyer Andersen Assignee: Mikkel Meyer Andersen Priority: Minor Attachments: MannWhitneyUTest.java, MannWhitneyUTestImpl.java, WilcoxonSignedRankTest.java, WilcoxonSignedRankTestImpl.java Original Estimate: 4h Remaining Estimate: 4h Wilcoxon signed-rank test and Mann-Whitney U are commonly used non-parametric statistical hypothesis tests (e.g. instead of various t-tests when normality is not present). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - 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: Komogorov distribution WASF Re: [jira] Commented: (MATH-431) New tests: Wilcoxon signed-rank test and Mann-Whitney U
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 to release under ASL. So at this point, I am looking for an alternative good algorithm to implement. All suggestions / unencumbered patches welcome! See comments on the MATH-431 for other questions. >>> Just to be sure of what you mean: >>> Do you want to have a two-sample Kolmogorov-Smirnov test for equality >>> of distributions in addition to the Mann-Whitney? Or do you need the >>> Kolmogorov-Smirnov distribution (as stated for example at >>> >>> >>> http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test#Kolmogorov_distribution >>> ) in regards to the MATH-428? Sorry, but I'm at bit confused :-). >> >> The goal is to implement the KS test for equality of distributions (or >> homogeneity against a reference distribution). To do that we need at >> least >> critical values of the Kolmogorov distribution. The natural way for us to >> do that would be to implement the full distribution which would be nice to >> have in the distributions package. >> >> Phil > > Have you read "Evaluating Kolmogorov’s Distribution" by Marsaglia et > al. available on http://www.jstatsoft.org/v08/i18/paper ? And do you > think their approach would be the way to go? > > I am not sure it is best. See the comments here: > http://www.iro.umontreal.ca/~lecuyer/myftp/papers/ksdist.pdf > > Phil Thanks. It looks quite thorough, indeed. Was it the Java implementation you didn't get a consent to release under ASL? > > >> >> Interesting approach for the exact algorithm for Wilcoxon. If we stay >> with this, we should ack the original author of the algorithm in the >> javadoc. Looks OK to use. > > Agree - both on the approach and legal part! Does the author need to > sign anything but write a mail? >> >> Regarding the difference from R, what I usually do in this case is >> look >> at the R sources to try to explain the difference. Most likely in >> this >> case, what is going on is they are using a different estimation >> algorithm >> for small n or treating ties differently. The ranking options that we >> use >> were largely adapted from R, so if that is the problem, it should be >> easy to >> test. We need to convince ourselves that ours is better or at least a >> legitimate alternative. I will take a close look this evening, but it >> looks >> like the algorithm you are using should be exact. If we can't >> reconcile the >> difference with R, it would be good to find a way to validate correct >> functioning of the algorithm by manufacturing reference data with >> known >> p. > > I'll try to investigate the difference, hopefully tomorrow, so that > formal tests can be written and included. >> >>> New tests: Wilcoxon signed-rank test and Mann-Whitney U >>> --- >>> >>> Key: MATH-431 >>> URL: https://issues.apache.org/jira/browse/MATH-431 >>> Project: Commons Math >>> Issue Type: New Feature >>> Reporter: Mikkel Meyer Andersen >>> Assignee: Mikkel Meyer Andersen >>> Priority: Minor >>> Attachments: MannWhitneyUTest.java, MannWhitneyUTestImpl.java, >>> WilcoxonSignedRankTest.java, WilcoxonSignedRankTestImpl.java >>> >>> Original Estimate: 4h >>> Remaining Estimate: 4h >>> >>> Wilcoxon signed-rank test and Mann-Whitney U are commonly used >>> non-parametric statistical hypothesis tests (e.g. instead of various >>> t-tests >>> when normality is not present). >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >> >> >> > > - > 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
Komogorov distribution WASF Re: [jira] Commented: (MATH-431) New tests: Wilcoxon signed-rank test and Mann-Whitney U
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 looking for an alternative good algorithm to implement. All suggestions / unencumbered patches welcome! See comments on the MATH-431 for other questions. Just to be sure of what you mean: Do you want to have a two-sample Kolmogorov-Smirnov test for equality of distributions in addition to the Mann-Whitney? Or do you need the Kolmogorov-Smirnov distribution (as stated for example at http://en.wikipedia.org/wiki/Kolmogorov%E2%80%93Smirnov_test#Kolmogorov_distribution ) in regards to the MATH-428? Sorry, but I'm at bit confused :-). The goal is to implement the KS test for equality of distributions (or homogeneity against a reference distribution). To do that we need at least critical values of the Kolmogorov distribution. The natural way for us to do that would be to implement the full distribution which would be nice to have in the distributions package. Phil Have you read "Evaluating Kolmogorov’s Distribution" by Marsaglia et al. available on http://www.jstatsoft.org/v08/i18/paper ? And do you think their approach would be the way to go? I am not sure it is best. See the comments here: http://www.iro.umontreal.ca/~lecuyer/myftp/papers/ksdist.pdf Phil Interesting approach for the exact algorithm for Wilcoxon. If we stay with this, we should ack the original author of the algorithm in the javadoc. Looks OK to use. Agree - both on the approach and legal part! Does the author need to sign anything but write a mail? Regarding the difference from R, what I usually do in this case is look at the R sources to try to explain the difference. Most likely in this case, what is going on is they are using a different estimation algorithm for small n or treating ties differently. The ranking options that we use were largely adapted from R, so if that is the problem, it should be easy to test. We need to convince ourselves that ours is better or at least a legitimate alternative. I will take a close look this evening, but it looks like the algorithm you are using should be exact. If we can't reconcile the difference with R, it would be good to find a way to validate correct functioning of the algorithm by manufacturing reference data with known p. I'll try to investigate the difference, hopefully tomorrow, so that formal tests can be written and included. New tests: Wilcoxon signed-rank test and Mann-Whitney U --- Key: MATH-431 URL: https://issues.apache.org/jira/browse/MATH-431 Project: Commons Math Issue Type: New Feature Reporter: Mikkel Meyer Andersen Assignee: Mikkel Meyer Andersen Priority: Minor Attachments: MannWhitneyUTest.java, MannWhitneyUTestImpl.java, WilcoxonSignedRankTest.java, WilcoxonSignedRankTestImpl.java Original Estimate: 4h Remaining Estimate: 4h Wilcoxon signed-rank test and Mann-Whitney U are commonly used non-parametric statistical hypothesis tests (e.g. instead of various t-tests when normality is not present). -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
[g...@vmgump]: Project commons-proxy-test (in module apache-commons) failed
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 issue affects 1 projects, and has been outstanding for 54 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-proxy-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven Settings in: /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/proxy/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/gump_work/build_apache-commons_commons-proxy-test.html Work Name: build_apache-commons_commons-proxy-test (Type: Build) Work ended in a state of : Failed Elapsed: 17 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/proxy/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/proxy] M2_HOME: /opt/maven2 - Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Running org.apache.commons.proxy.factory.util.TestMethodSignature Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.003 sec Running org.apache.commons.proxy.provider.TestConstantProvider Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec Running org.apache.commons.proxy.interceptor.TestFilteredInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.049 sec Running org.apache.commons.proxy.interceptor.filter.TestPatternFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Running org.apache.commons.proxy.interceptor.TestSerializingInterceptor Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.021 sec Running org.apache.commons.proxy.interceptor.TestInterceptorChain Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.009 sec Running org.apache.commons.proxy.invoker.TestNullInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.033 sec Running org.apache.commons.proxy.provider.remoting.TestBurlapProvider Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.commons.proxy.exception.TestDelegateProviderException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.invoker.TestChainInvoker Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.013 sec Running org.apache.commons.proxy.factory.javassist.TestJavassistProxyFactory Tests run: 37, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.242 sec Running org.apache.commons.proxy.exception.TestProxyFactoryException Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Running org.apache.commons.proxy.interceptor.filter.TestReturnTypeFilter Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.proxy.provider.TestBeanProvider Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.042 sec Results : Tests in error: testInvalidHandlerName(org.apache.commons.proxy.invoker.TestXmlRpcInvoker) Tests run: 179, Failures: 0, Errors: 1, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/proxy/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 16 seconds [INFO] Finished at: Sun Nov 07 11:08:47 UTC 2010 [INFO] Final Memory: 39M/93M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-proxy-test/rss.xml - Atom: http://vmgump.apache.org/gump/public
[g...@vmgump]: Project commons-jelly-tags-quartz (in module commons-jelly) failed
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 integration. This issue affects 1 projects, and has been outstanding for 3 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-jelly-tags-quartz : Commons Jelly Full details are available at: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-quartz/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -DEBUG- Sole jar output [commons-jelly-tags-quartz-07112010.jar] identifier set to project name -DEBUG- Dependency on logging-log4j-12 exists, no need to add for property maven.jar.log4j. -DEBUG- Dependency on xml-xerces exists, no need to add for property maven.jar.xerces. -DEBUG- Dependency on commons-jexl-1.x exists, no need to add for property maven.jar.commons-jexl. -DEBUG- (Gump generated) Maven Properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/build.properties -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/project.xml -DEBUG- Maven project properties in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/project.properties -INFO- Project Reports in: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/test-reports -WARNING- No directory [/srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/test-reports] -DEBUG- Extracted fallback artifacts from Gump Repository The following work was performed: http://vmgump.apache.org/gump/public/commons-jelly/commons-jelly-tags-quartz/gump_work/build_commons-jelly_commons-jelly-tags-quartz.html Work Name: build_commons-jelly_commons-jelly-tags-quartz (Type: Build) Work ended in a state of : Failed Elapsed: 7 secs Command Line: maven --offline jar [Working Directory: /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz] - java:compile: [echo] Compiling to /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/classes [javac] Compiling 7 source files to /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/target/classes [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:198: org.quartz.CronTrigger is abstract; cannot be instantiated [javac] CronTrigger trigger = new CronTrigger( getName(), [javac] ^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:201: cannot find symbol [javac] symbol : method setCronExpression(java.lang.String) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setCronExpression( getSpec() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:206: cannot find symbol [javac] symbol : method setJobName(java.lang.String) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setJobName( getJobName() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:207: cannot find symbol [javac] symbol : method setJobGroup(java.lang.String) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setJobGroup( getJobGroup() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/CronTriggerTag.java:208: cannot find symbol [javac] symbol : method setStartTime(java.util.Date) [javac] location: interface org.quartz.CronTrigger [javac] trigger.setStartTime( new Date() ); [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/JobTag.java:118: org.quartz.JobDetail is abstract; cannot be instantiated [javac] JobDetail detail = new JobDetail( getName(), [javac]^ [javac] /srv/gump/public/workspace/commons-jelly/jelly-tags/quartz/src/java/org/apache/commons/jelly/tags/quartz/JobTag.java:122: cannot find symbol [javac] symbol : method setDurability(boolean) [javac] location: interface org.quartz.JobDetail [javac] detail.setDurability( true ); [javac] ^ [javac] /srv/gump/public/wo
[g...@vmgump]: Project commons-scxml-test (in module apache-commons) failed
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 issue affects 1 projects, and has been outstanding for 54 runs. The current state of this project is 'Failed', with reason 'Build Failed'. For reference only, the following projects are affected by this: - commons-scxml-test : Apache Commons Full details are available at: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/index.html That said, some information snippets are provided here. The following annotations (debug/informational/warning/error messages) were provided: -WARNING- Overriding Maven settings: [/srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml] -DEBUG- (Gump generated) Maven Settings in: /srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml -INFO- Failed with reason build failed -DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/scxml/pom.xml -INFO- Project Reports in: /srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports The following work was performed: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/gump_work/build_apache-commons_commons-scxml-test.html Work Name: build_apache-commons_commons-scxml-test (Type: Build) Work ended in a state of : Failed Elapsed: 27 secs Command Line: /opt/maven2/bin/mvn --batch-mode --settings /srv/gump/public/workspace/apache-commons/scxml/gump_mvn_settings.xml test [Working Directory: /srv/gump/public/workspace/apache-commons/scxml] M2_HOME: /opt/maven2 - --- T E S T S --- Running org.apache.commons.scxml.invoke.InvokeTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.064 sec Running org.apache.commons.scxml.test.TestingTestSuite Tests run: 0, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec Running org.apache.commons.scxml.env.EnvTestSuite Tests run: 21, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.279 sec Running org.apache.commons.scxml.SCXMLTestSuite Tests run: 71, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 5.593 sec <<< FAILURE! Running org.apache.commons.scxml.issues.IssuesTestSuite Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.586 sec Running org.apache.commons.scxml.model.ModelTestSuite Tests run: 78, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 3.732 sec <<< FAILURE! Running org.apache.commons.scxml.env.faces.EnvFacesTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.007 sec Running org.apache.commons.scxml.semantics.SemanticsTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.005 sec Running org.apache.commons.scxml.env.jsp.EnvJspTestSuite Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.109 sec Running org.apache.commons.scxml.env.jexl.EnvJexlTestSuite Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.038 sec Running org.apache.commons.scxml.env.servlet.EnvServletTestSuite Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.004 sec Running org.apache.commons.scxml.io.IOTestSuite Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.57 sec Results : Failed tests: testNamespacePrefixedXPathsEL(org.apache.commons.scxml.NamespacePrefixedXPathsTest) testDatamodelSimultaneousJsp(org.apache.commons.scxml.model.DatamodelTest) Tests run: 228, Failures: 2, Errors: 0, Skipped: 0 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. Please refer to /srv/gump/public/workspace/apache-commons/scxml/target/surefire-reports for the individual test results. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 26 seconds [INFO] Finished at: Sun Nov 07 10:26:33 UTC 2010 [INFO] Final Memory: 41M/99M [INFO] - To subscribe to this information via syndicated feeds: - RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/rss.xml - Atom: http://vmgump.apache.org/gump/public/apache-commons/commons-scxml-test/atom.xml == Gump Tracking Only === Produced by Gump version 2.3. Gump Run 4607112010, vmgump.apache.org:vmgump:4607112010 Gump E-mail Identifier (unique within run) #17. -- Apache G
[g...@vmgump]: Project commons-vfs (in module apache-commons) failed
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 affects 47 projects,
and has been outstanding for 2 runs.
The current state of this project is 'Failed', with reason 'Missing Build
Outputs'.
For reference only, the following projects are affected by this:
- ant-contrib : Useful little Ant tasks
- ant-contrib-test : Useful little Ant tasks
- antbook-diary-core : Examples to go with Java Development with Ant
- antbook-sections : Examples to go with Java Development with Ant
- antbook-sections-tasks : Examples to go with Java Development with Ant
- cddlm : Configuration and Deployment of Grid Applications and System...
- commons-configuration : Apache Commons
- commons-configuration-test : Apache Commons
- commons-vfs : Apache Commons
- commons-vfs-sandbox : Apache Commons
- commons-vfs-test : Apache Commons
- excalibur-fortress-bean : Repository of reusable components.
- excalibur-fortress-container-impl : Repository of reusable components.
- excalibur-fortress-container-test : Repository of reusable components.
- excalibur-fortress-examples : Repository of reusable components.
- excalibur-fortress-migration : Repository of reusable components.
- excalibur-fortress-platform : Repository of reusable components.
- excalibur-fortress-testcase : Repository of reusable components.
- excalibur-monitor : Repository of reusable components.
- excalibur-sourceresolve : Repository of reusable components.
- excalibur-xmlutil : Repository of reusable components.
- excalibur-xmlutil-test : Repository of reusable components.
- forrest-core : Apache Forrest software is a publishing framework that
trans...
- forrest-rat : Apache Forrest software is a publishing framework that
trans...
- forrest-test : Apache Forrest software is a publishing framework that
trans...
- forrest-test-basic : Apache Forrest software is a publishing framework
that trans...
- fulcrum-cache : Services Framework
- fulcrum-cache-test : Services Framework
- fulcrum-configuration-impl : Services Framework
- fulcrum-security-memory : Services Framework
- fulcrum-security-nt : Services Framework
- invicta : Open-source build management tool.
- ivy : Ivy Core
- ivy-tests : Ivy is a tool for managing (recording, tracking, resolving
a...
- jakarta-turbine-jcs : Cache
- jcs : Cache
- jgroups : A Reliable Multicast Communication Toolkit for Java
- logging-log4j-chainsaw : Chainsaw log viewer
- org.apache.commons_commons-vfs : Apache Commons
- smartfrog : Smartfrog: Application Deployment from HP Laboratories
- smartfrog-components : Smartfrog: Application Deployment from HP
Laboratories
- smartfrog-tasks : Smartfrog: Application Deployment from HP Laboratories
- smartfrog-tasks-test : Smartfrog: Application Deployment from HP
Laboratories
- smartfrog-test : Smartfrog: Application Deployment from HP Laboratories
- smartfrog-testharness : Smartfrog: Application Deployment from HP
Laboratories
- testng : Java Unit test framework
- testng-deps : Java Unit test framework
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-vfs-2.0-SNAPSHOT.jar] identifier set to
project name
-DEBUG- (Gump generated) Maven Settings in:
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml
-DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/vfs/pom.xml
-INFO- Failed with reason missing build outputs
-ERROR- Missing Output:
/srv/gump/public/workspace/apache-commons/vfs/core/target/commons-vfs-2.0-SNAPSHOT.jar
-ERROR- See Directory Listing Work for Missing Outputs
-DEBUG- Extracted fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-vfs/gump_work/build_apache-commons_commons-vfs.html
Work Name: build_apache-commons_commons-vfs (Type: Build)
Work ended in a state of : Success
Elapsed: 59 secs
Command Line: /opt/maven2/bin/mvn --batch-mode -DskipTests=true --settings
/srv/gump/public/workspace/apache-commons/vfs/gump_mvn_settings.xml package
[Working Directory: /srv/gump/public/workspace/apache-commons/vfs]
M2_HOME: /opt/maven2
-
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources {execution: default-resources}]
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] C
[g...@vmgump]: Project commons-email (in module apache-commons) failed
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 affects 2 projects.
The current state of this project is 'Failed', with reason 'Missing Build
Outputs'.
For reference only, the following projects are affected by this:
- commons-email : Commons Email Package
- fulcrum-template : Services Framework
Full details are available at:
http://vmgump.apache.org/gump/public/apache-commons/commons-email/index.html
That said, some information snippets are provided here.
The following annotations (debug/informational/warning/error messages) were
provided:
-DEBUG- Sole jar output [commons-email-1.3-SNAPSHOT.jar] identifier set to
project name
-DEBUG- (Gump generated) Maven Settings in:
/srv/gump/public/workspace/apache-commons/email/gump_mvn_settings.xml
-DEBUG- Maven POM in: /srv/gump/public/workspace/apache-commons/email/pom.xml
-INFO- Failed with reason missing build outputs
-ERROR- Missing Output:
/srv/gump/public/workspace/apache-commons/email/target/commons-email-1.3-SNAPSHOT.jar
-ERROR- See Directory Listing Work for Missing Outputs
-DEBUG- Extracted fallback artifacts from Gump Repository
The following work was performed:
http://vmgump.apache.org/gump/public/apache-commons/commons-email/gump_work/build_apache-commons_commons-email.html
Work Name: build_apache-commons_commons-email (Type: Build)
Work ended in a state of : Success
Elapsed: 34 secs
Command Line: /opt/maven2/bin/mvn --batch-mode
-Dmaven.jar.mail=/srv/gump/packages/javamail-1.4/mail.jar --settings
/srv/gump/public/workspace/apache-commons/email/gump_mvn_settings.xml package
[Working Directory: /srv/gump/public/workspace/apache-commons/email]
M2_HOME: /opt/maven2
-
[INFO] Surefire report directory:
/srv/gump/public/workspace/apache-commons/email/target/surefire-reports
---
T E S T S
---
Running org.apache.commons.mail.HtmlEmailTest
log4j:WARN No appenders could be found for logger
(org.subethamail.smtp.server.CommandHandler).
log4j:WARN Please initialize the log4j system properly.
log4j:WARN See http://logging.apache.org/log4j/1.2/faq.html#noconfig for more
info.
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.313 sec
Running org.apache.commons.mail.EmailLiveTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.325 sec
Running org.apache.commons.mail.SendWithAttachmentsTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.092 sec
Running org.apache.commons.mail.DataSourceResolverTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.016 sec
Running org.apache.commons.mail.util.MimeMessageParserTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.162 sec
Running org.apache.commons.mail.EmailTest
Tests run: 40, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.329 sec
Running org.apache.commons.mail.EmailAttachmentTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.47 sec
Running org.apache.commons.mail.ImageHtmlEmailTest
Tests run: 18, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.754 sec
Running org.apache.commons.mail.DefaultAuthenticatorTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.012 sec
Running org.apache.commons.mail.util.URLFactoryTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.006 sec
Running org.apache.commons.mail.SimpleEmailTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.026 sec
Running org.apache.commons.mail.MultiPartEmailTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.049 sec
Running org.apache.commons.mail.InvalidInternetAddressTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
Running org.apache.commons.mail.InvalidAddressTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.008 sec
Results :
Tests run: 107, Failures: 0, Errors: 0, Skipped: 0
[INFO] [jar:jar {execution: default-jar}]
[INFO] Building jar:
/srv/gump/public/workspace/apache-commons/email/target/commons-email-1.3.1-SNAPSHOT.jar
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 33 seconds
[INFO] Finished at: Sun Nov 07 08:58:43 UTC 2010
[INFO] Final Memory: 53M/128M
[INFO]
-
To subscribe to this information via syndicated feeds:
- RSS: http://vmgump.apache.org/gump/public/apache-commons/commons-email/rss.xml
- Atom:
http://
Re: [Collections] Generic Fork
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 sign an ICLA. >> >> When signing an ICLA, your company may want to sign a CCLA - it's >> entirely up to your employer and not required by us. > > It may protect him in case his employer later consider the code did not > initially belong to him and he did not have the right to contribute it > to an Apache project. Sure, it may (or may not). It also might tie things up in red tape, especially as we don't negotiate the CCLA, something that might be novel to some legal departments. It's up to the committer/contributor and their employer whether they want to sign it; we stay out of it. Hen - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
