Re: Handling of unrecognised version qualifiers
Le vendredi 27 mai 2011, John Casey a écrit : Again, something like this should be formalized in our version spec. Our version comparison spec is both the ComparableVersion javadoc [1] and the proposal on the Wiki [2] I just updated them both to be explicit about this change Regards, Hervé [1] http://maven.apache.org/ref/3.0.3/maven- artifact/apidocs/org/apache/maven/artifact/versioning/ComparableVersion.html [2] https://cwiki.apache.org/confluence/display/MAVENOLD/Versioning - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
a good candidate for a proposal? [1] Yes, improving logging and its documentation would be useful. Regards, Hervé [1] https://cwiki.apache.org/confluence/display/MAVEN/Proposals Le vendredi 10 juin 2011, Ralph Goers a écrit : On Jun 9, 2011, at 2:45 PM, Benson Margulies wrote: I'd like to offer a small suggestion. One of the big barriers to maven happiness is the difficulty of understanding, in some cases, why it does what it does. This suggests to me three efforts that might offer an opportunity to learn core code without drowning. 1: take up slf4j, and thus allow component (indeed class) by component log control as an alternative to the giant -X spew. Now that is an interesting idea. For the past year I have been working on creating Log4j 2.0 pretty much by myself. This would be a great way to integrate it into something useful. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Get thee to the Core...
Hi all, Long time lurker, I'm de-lurking because I like to harp on a bit about how to run a successful open source project (based off Karl Fogel's teachings at http://producingoss.org) - got to love opinionated lurkers right? ;p My comments in-line below: * Open up access to the community somehow (suggested by Kristian) * Draw in more developers to core (suggested by John) I typically see this being successful when there are readily accessible issue trackers, documentation, developer guidelines, a community manager (or several) and more. In order to not scare a new developer away from something difficult (like Maven core), you want them to grok it in a day or so by supplying: * A 30,000 foot view * A how to build and run the core * A list of _really_ simple bug fixes that new developers can try out so they can follow the development process. My favourite is to say Hey, we just switched on Findbugs - and there are 3 issues to fix in class X. The feeling of accomplishment that a new developer will get from successfully making a change is really, really important. * Crucially they need some really patient community leads/managers/whatever to be there for them in real-time. This is the hardest part. Maven already has some of this stuff covered, which is great! But I think it's perhaps lacking a little in the documentation around the core and maybe some more dedicated community managers/leads/whatever wouldn't go amiss either. A really good example of great interaction is with the ossrh mailing list with Juven as the de-facto community manager. He's so quick and polite to respond to issues that users volunteers start responding in kind and get involved (in my case the tiniest of doc patches, but hey I wouldn't have normally bothered). Remember, every user/developer is a potential volunteer :-). * apply patches from people that genuinely can help (suggested by Brett) I think the applying or rejecting of patches could be sped up (from my anecdotal watching of JIRAs over the past year). It can help to have a dedicated person for this, quick response times to patches means a much higher chance of having that user/developer join the project! I think we need to create documentation that is accessible from the main site. Perhaps the tooling isn't quite there to do that easily. Personally I'd love to see a beginners walkthrough of how maven is architected with diagrams and links to the code. This would be brilliant. Yes, documentation is the bane of most open-source projects...and we certainly have a weakness there. Part of the documentation needs to be fueled by a wish list from the community though...I'm too close to things personally to know which parts aren't easy to understand. :-) blatantly looking a SonatypeInterns can be really useful in these sorts of situations (where you have to play catch-up on the docs)/blatantly looking at Sonatype Feel free to ignore any of the above - I just couldn't resist sticking my nose in. Cheers, Martijn - (Maven fan - most of the time ;p) - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
WHOOPS, please ignore my previous message
I typed 'perform' instead of 'prepare'. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[REDUX] Java Service Wrappers (JSW) unfortunate license change
(This is continuation of a thread from 2008[1]. It's now impacting the release of Apache James 3. If the topic is too far OT please shout ;-) The JSW artifacts in Maven Central [2] now seem to lack a public license (in other words, a unilateral license allowing the public to distribute and download the artifact) AFACT (please jump in if there's anything I've missed or misunderstood) to fix this particular problem the community needs to * Remove JSW runtime dependency from appassembler * Remove the artifact from maven central * Fork the source and release replacement artifacts with clean IP * Cut a new appassembler release My computer time is limited ATM so if any help would be really appreciated... In this brave new world of retroactive license changes, this is a good example of an important problem. The licenses issued by the original authority for an artifact may change over time, and the license which a downstream consumer of that artifact may rely upon may no longer be issued by the upstream authority for that artifact. This allows bait-and-switch tactics by upstream producers. To avoid potential issues in the future for downstream users and those operating Maven central, I think the Maven community needs to start thinking about this problem now. More specifically, reliable write-license meta-data in the repository could be used to verify at release time that the dependencies have licenses that satisfy some sort of policy. This is the sort of fits with Rat but Rat has stalled in the Incubator since there's no obvious way home after graduation. My recovery continues but my computer time is still limited. Suggestions, opinions, ideas and offers for help welcomed. (Out of time) Robert [1] http://www.mail-archive.com/dev@maven.apache.org/msg74005.html [2] http://search.maven.org/#search|gav|1|g%3A%22tanukisoft%22%20AND%20a%3A%22wrapper-delta-pack%22 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[VOTE] Release maven shared parent version 20
Hi, We solved 1 issues: ** Improvement * [MPOM-11] - Update to compile with/for java1.5 There are no open JIRAs against the maven shared POM. Staging repo: https://repository.apache.org/content/repositories/maven-071/ Staging site: N/A Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [REDUX] Java Service Wrappers (JSW) unfortunate license change
just an idea: what about extending the maven-release-plugin to ask for a license if the pom doesn't contain a license section? LieGrue, strub --- On Sun, 6/12/11, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: From: Robert Burrell Donkin robertburrelldon...@gmail.com Subject: [REDUX] Java Service Wrappers (JSW) unfortunate license change To: Maven Developers List dev@maven.apache.org Date: Sunday, June 12, 2011, 3:26 PM (This is continuation of a thread from 2008[1]. It's now impacting the release of Apache James 3. If the topic is too far OT please shout ;-) The JSW artifacts in Maven Central [2] now seem to lack a public license (in other words, a unilateral license allowing the public to distribute and download the artifact) AFACT (please jump in if there's anything I've missed or misunderstood) to fix this particular problem the community needs to * Remove JSW runtime dependency from appassembler * Remove the artifact from maven central * Fork the source and release replacement artifacts with clean IP * Cut a new appassembler release My computer time is limited ATM so if any help would be really appreciated... In this brave new world of retroactive license changes, this is a good example of an important problem. The licenses issued by the original authority for an artifact may change over time, and the license which a downstream consumer of that artifact may rely upon may no longer be issued by the upstream authority for that artifact. This allows bait-and-switch tactics by upstream producers. To avoid potential issues in the future for downstream users and those operating Maven central, I think the Maven community needs to start thinking about this problem now. More specifically, reliable write-license meta-data in the repository could be used to verify at release time that the dependencies have licenses that satisfy some sort of policy. This is the sort of fits with Rat but Rat has stalled in the Incubator since there's no obvious way home after graduation. My recovery continues but my computer time is still limited. Suggestions, opinions, ideas and offers for help welcomed. (Out of time) Robert [1] http://www.mail-archive.com/dev@maven.apache.org/msg74005.html [2] http://search.maven.org/#search|gav|1|g%3A%22tanukisoft%22%20AND%20a%3A%22wrapper-delta-pack%22 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [REDUX] Java Service Wrappers (JSW) unfortunate license change
There's no such thing as a 'retroactive license change', though perhaps the Tanuki-person has managed a sufficient approximation. Is there? Once upon a time, he/they released some version of JSW under a friendly licence, and it pushed to central. The grant of that license to that version is effectively irrevocable. Subsequent versions may have different licenses, and the author might have removed the old version -- though if it was really licensed with a permissive license some other person could put it back. On Sun, Jun 12, 2011 at 11:32 AM, Mark Struberg strub...@yahoo.de wrote: just an idea: what about extending the maven-release-plugin to ask for a license if the pom doesn't contain a license section? LieGrue, strub --- On Sun, 6/12/11, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: From: Robert Burrell Donkin robertburrelldon...@gmail.com Subject: [REDUX] Java Service Wrappers (JSW) unfortunate license change To: Maven Developers List dev@maven.apache.org Date: Sunday, June 12, 2011, 3:26 PM (This is continuation of a thread from 2008[1]. It's now impacting the release of Apache James 3. If the topic is too far OT please shout ;-) The JSW artifacts in Maven Central [2] now seem to lack a public license (in other words, a unilateral license allowing the public to distribute and download the artifact) AFACT (please jump in if there's anything I've missed or misunderstood) to fix this particular problem the community needs to * Remove JSW runtime dependency from appassembler * Remove the artifact from maven central * Fork the source and release replacement artifacts with clean IP * Cut a new appassembler release My computer time is limited ATM so if any help would be really appreciated... In this brave new world of retroactive license changes, this is a good example of an important problem. The licenses issued by the original authority for an artifact may change over time, and the license which a downstream consumer of that artifact may rely upon may no longer be issued by the upstream authority for that artifact. This allows bait-and-switch tactics by upstream producers. To avoid potential issues in the future for downstream users and those operating Maven central, I think the Maven community needs to start thinking about this problem now. More specifically, reliable write-license meta-data in the repository could be used to verify at release time that the dependencies have licenses that satisfy some sort of policy. This is the sort of fits with Rat but Rat has stalled in the Incubator since there's no obvious way home after graduation. My recovery continues but my computer time is still limited. Suggestions, opinions, ideas and offers for help welcomed. (Out of time) Robert [1] http://www.mail-archive.com/dev@maven.apache.org/msg74005.html [2] http://search.maven.org/#search|gav|1|g%3A%22tanukisoft%22%20AND%20a%3A%22wrapper-delta-pack%22 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [REDUX] Java Service Wrappers (JSW) unfortunate license change
The old versions are LGPL On Sun, Jun 12, 2011 at 11:40 AM, Benson Margulies bimargul...@gmail.com wrote: There's no such thing as a 'retroactive license change', though perhaps the Tanuki-person has managed a sufficient approximation. Is there? Once upon a time, he/they released some version of JSW under a friendly licence, and it pushed to central. The grant of that license to that version is effectively irrevocable. Subsequent versions may have different licenses, and the author might have removed the old version -- though if it was really licensed with a permissive license some other person could put it back. On Sun, Jun 12, 2011 at 11:32 AM, Mark Struberg strub...@yahoo.de wrote: just an idea: what about extending the maven-release-plugin to ask for a license if the pom doesn't contain a license section? LieGrue, strub --- On Sun, 6/12/11, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: From: Robert Burrell Donkin robertburrelldon...@gmail.com Subject: [REDUX] Java Service Wrappers (JSW) unfortunate license change To: Maven Developers List dev@maven.apache.org Date: Sunday, June 12, 2011, 3:26 PM (This is continuation of a thread from 2008[1]. It's now impacting the release of Apache James 3. If the topic is too far OT please shout ;-) The JSW artifacts in Maven Central [2] now seem to lack a public license (in other words, a unilateral license allowing the public to distribute and download the artifact) AFACT (please jump in if there's anything I've missed or misunderstood) to fix this particular problem the community needs to * Remove JSW runtime dependency from appassembler * Remove the artifact from maven central * Fork the source and release replacement artifacts with clean IP * Cut a new appassembler release My computer time is limited ATM so if any help would be really appreciated... In this brave new world of retroactive license changes, this is a good example of an important problem. The licenses issued by the original authority for an artifact may change over time, and the license which a downstream consumer of that artifact may rely upon may no longer be issued by the upstream authority for that artifact. This allows bait-and-switch tactics by upstream producers. To avoid potential issues in the future for downstream users and those operating Maven central, I think the Maven community needs to start thinking about this problem now. More specifically, reliable write-license meta-data in the repository could be used to verify at release time that the dependencies have licenses that satisfy some sort of policy. This is the sort of fits with Rat but Rat has stalled in the Incubator since there's no obvious way home after graduation. My recovery continues but my computer time is still limited. Suggestions, opinions, ideas and offers for help welcomed. (Out of time) Robert [1] http://www.mail-archive.com/dev@maven.apache.org/msg74005.html [2] http://search.maven.org/#search|gav|1|g%3A%22tanukisoft%22%20AND%20a%3A%22wrapper-delta-pack%22 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [REDUX] Java Service Wrappers (JSW) unfortunate license change
Um, so that's not a problem as a dependency at codehaus?, but it might have always been an unpleasant surprise for people who suddenly discovered themselves aggregated with it. On Sun, Jun 12, 2011 at 11:55 AM, Brian Fox bri...@infinity.nu wrote: The old versions are LGPL On Sun, Jun 12, 2011 at 11:40 AM, Benson Margulies bimargul...@gmail.com wrote: There's no such thing as a 'retroactive license change', though perhaps the Tanuki-person has managed a sufficient approximation. Is there? Once upon a time, he/they released some version of JSW under a friendly licence, and it pushed to central. The grant of that license to that version is effectively irrevocable. Subsequent versions may have different licenses, and the author might have removed the old version -- though if it was really licensed with a permissive license some other person could put it back. On Sun, Jun 12, 2011 at 11:32 AM, Mark Struberg strub...@yahoo.de wrote: just an idea: what about extending the maven-release-plugin to ask for a license if the pom doesn't contain a license section? LieGrue, strub --- On Sun, 6/12/11, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: From: Robert Burrell Donkin robertburrelldon...@gmail.com Subject: [REDUX] Java Service Wrappers (JSW) unfortunate license change To: Maven Developers List dev@maven.apache.org Date: Sunday, June 12, 2011, 3:26 PM (This is continuation of a thread from 2008[1]. It's now impacting the release of Apache James 3. If the topic is too far OT please shout ;-) The JSW artifacts in Maven Central [2] now seem to lack a public license (in other words, a unilateral license allowing the public to distribute and download the artifact) AFACT (please jump in if there's anything I've missed or misunderstood) to fix this particular problem the community needs to * Remove JSW runtime dependency from appassembler * Remove the artifact from maven central * Fork the source and release replacement artifacts with clean IP * Cut a new appassembler release My computer time is limited ATM so if any help would be really appreciated... In this brave new world of retroactive license changes, this is a good example of an important problem. The licenses issued by the original authority for an artifact may change over time, and the license which a downstream consumer of that artifact may rely upon may no longer be issued by the upstream authority for that artifact. This allows bait-and-switch tactics by upstream producers. To avoid potential issues in the future for downstream users and those operating Maven central, I think the Maven community needs to start thinking about this problem now. More specifically, reliable write-license meta-data in the repository could be used to verify at release time that the dependencies have licenses that satisfy some sort of policy. This is the sort of fits with Rat but Rat has stalled in the Incubator since there's no obvious way home after graduation. My recovery continues but my computer time is still limited. Suggestions, opinions, ideas and offers for help welcomed. (Out of time) Robert [1] http://www.mail-archive.com/dev@maven.apache.org/msg74005.html [2] http://search.maven.org/#search|gav|1|g%3A%22tanukisoft%22%20AND%20a%3A%22wrapper-delta-pack%22 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [REDUX] Java Service Wrappers (JSW) unfortunate license change
Nah sorry, I think I was not clear enough: What I was talking about: IF a lot more artifacts would have an explicit license section in their poms, then it would be easier for tools (e.g. apache-rat and the maven-dependency-plugin) to check those dependencies and list/evaluate em. By asking the user for the licenses (a numbered bullet list like we have in the archetype plugin + an option for a free string entry) we could possibly heavily increase the amount of artifacts with a license section. This would certainly take some time, but after 1 year, this should really take off. Another way would be to parse for META-INF/Manifest info and LICENSE files inside the artifacts and propagate it to the poms. But this is rather delicate to handle... I know this is not directly solving your current problem, but it could help to preventing us from getting this problem in the future. LieGrue, strub --- On Sun, 6/12/11, Benson Margulies bimargul...@gmail.com wrote: From: Benson Margulies bimargul...@gmail.com Subject: Re: [REDUX] Java Service Wrappers (JSW) unfortunate license change To: Maven Developers List dev@maven.apache.org Date: Sunday, June 12, 2011, 3:40 PM There's no such thing as a 'retroactive license change', though perhaps the Tanuki-person has managed a sufficient approximation. Is there? Once upon a time, he/they released some version of JSW under a friendly licence, and it pushed to central. The grant of that license to that version is effectively irrevocable. Subsequent versions may have different licenses, and the author might have removed the old version -- though if it was really licensed with a permissive license some other person could put it back. On Sun, Jun 12, 2011 at 11:32 AM, Mark Struberg strub...@yahoo.de wrote: just an idea: what about extending the maven-release-plugin to ask for a license if the pom doesn't contain a license section? LieGrue, strub --- On Sun, 6/12/11, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: From: Robert Burrell Donkin robertburrelldon...@gmail.com Subject: [REDUX] Java Service Wrappers (JSW) unfortunate license change To: Maven Developers List dev@maven.apache.org Date: Sunday, June 12, 2011, 3:26 PM (This is continuation of a thread from 2008[1]. It's now impacting the release of Apache James 3. If the topic is too far OT please shout ;-) The JSW artifacts in Maven Central [2] now seem to lack a public license (in other words, a unilateral license allowing the public to distribute and download the artifact) AFACT (please jump in if there's anything I've missed or misunderstood) to fix this particular problem the community needs to * Remove JSW runtime dependency from appassembler * Remove the artifact from maven central * Fork the source and release replacement artifacts with clean IP * Cut a new appassembler release My computer time is limited ATM so if any help would be really appreciated... In this brave new world of retroactive license changes, this is a good example of an important problem. The licenses issued by the original authority for an artifact may change over time, and the license which a downstream consumer of that artifact may rely upon may no longer be issued by the upstream authority for that artifact. This allows bait-and-switch tactics by upstream producers. To avoid potential issues in the future for downstream users and those operating Maven central, I think the Maven community needs to start thinking about this problem now. More specifically, reliable write-license meta-data in the repository could be used to verify at release time that the dependencies have licenses that satisfy some sort of policy. This is the sort of fits with Rat but Rat has stalled in the Incubator since there's no obvious way home after graduation. My recovery continues but my computer time is still limited. Suggestions, opinions, ideas and offers for help welcomed. (Out of time) Robert [1] http://www.mail-archive.com/dev@maven.apache.org/msg74005.html [2] http://search.maven.org/#search|gav|1|g%3A%22tanukisoft%22%20AND%20a%3A%22wrapper-delta-pack%22 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail:
Automatic Proxy Configuration
I am having problems with Automatic Proxy Configuration in maven. Apparently, maven only does the standard proxy configuration with host/port/user/password. This option does not work at all for me at work. If anyone can tell me how I can get maven to work with an Authomatic Proxy Configuation on Windows, let me know. thanks Jason - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [REDUX] Java Service Wrappers (JSW) unfortunate license change
On Sun, Jun 12, 2011 at 4:40 PM, Benson Margulies bimargul...@gmail.com wrote: There's no such thing as a 'retroactive license change', though perhaps the Tanuki-person has managed a sufficient approximation. Is there? IMO enough of a sufficient approximation to worry :-/ (more detail in line) Once upon a time, he/they released some version of JSW under a friendly licence, and it pushed to central. AFAICT The compressed artifact lacks substantial license information. The license meta-data indicates that the artifact is licensed under the Tanuki Software license. This is not a license but a reference to a web page where a license might be obtained from Tanuki Software. AIUI this trick means that maven central does not have a license but people can obtain a license by visiting that page. The grant of that license to that version is effectively irrevocable. Subsequent versions may have different licenses, and the author might have removed the old version -- though if it was really licensed with a permissive license some other person could put it back. AIUI a rights holder could just stop issuing public licenses for an artifact at any time, and require new licensees agree new terms. Anyone who previously obtained a public license from Tanuki Software could publish the artifact under the old public license. Issuing a public license directly to maven central would therefore protect everyone downstream. This doesn't seem to have happened in this case :-/ (FWIW I doubt Tanuki Software would act against maven central under US copyright law. I'm more worried about liability for maven users in places (like England) with different copyright laws where justice is pay-to-play.) Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [REDUX] Java Service Wrappers (JSW) unfortunate license change
On Sun, Jun 12, 2011 at 4:32 PM, Mark Struberg strub...@yahoo.de wrote: just an idea: what about extending the maven-release-plugin to ask for a license if the pom doesn't contain a license section? In principle, this would be a good feature to add to a verification tool like Rat. In this case, JSW has a license section but that license contains meta-licensing information (a way for a user to obtain a license, rather than a direct license) Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [REDUX] Java Service Wrappers (JSW) unfortunate license change
So, the lesson I take from this is that the appassembler would never have been releasable at Apache, and that releasing it at codehaus without getting the author (who happens to be in Japan) to provide an unambiguous license was perhaps ill-advised. On Sun, Jun 12, 2011 at 1:54 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Sun, Jun 12, 2011 at 4:32 PM, Mark Struberg strub...@yahoo.de wrote: just an idea: what about extending the maven-release-plugin to ask for a license if the pom doesn't contain a license section? In principle, this would be a good feature to add to a verification tool like Rat. In this case, JSW has a license section but that license contains meta-licensing information (a way for a user to obtain a license, rather than a direct license) Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
org.codehaus.plexus.util.CollectionUtils.intersection
I think I've written a unit test for the contract of this function as
written in the javadoc, but it fails. The intersection function
returns an empty collection when the inputs most definitely have a
non-null intersection. What am I missing?
@SuppressWarnings( rawtypes )
@Test
public void testIntersection() throws Exception {
CollectionString c1 = new ArrayListString();
CollectionString c2 = new ArrayListString();
/*
* An exhaustive black box test here
* would involve generating a great deal of data,
* perhaps even different sizes and collection classes.
*/
c1.add(red);
c1.add(blue);
c1.add(green);
c1.add(socialist);
c1.add(red);
c1.add(purple);
c1.add(porpoise);
c1.add(green);
c1.add(blue);
c1.add(gray);
c1.add(blue);
c1.add(12);
c1.add(15);
c1.add(blue);
c1.add(porpoise);
c1.add(33.3);
c1.add(jabberwock);
MultisetString correct = HashMultiset.create();
correct.add( blue );
correct.add( blue );
correct.add( porpoise );
@SuppressWarnings( unchecked )
CollectionString res = CollectionUtils.intersection( c1, c2 );
MultisetString actual = HashMultiset.create();
actual.addAll(res);
assertEquals( correct, actual );
}
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: org.codehaus.plexus.util.CollectionUtils.intersection
Sure enough. Thanks.
On Sun, Jun 12, 2011 at 3:26 PM, Peter Janes pet...@peterjanes.ca wrote:
Maybe it's that you're not adding anything to c2?
On 12/06/11 03:23 PM, Benson Margulies wrote:
I think I've written a unit test for the contract of this function as
written in the javadoc, but it fails. The intersection function
returns an empty collection when the inputs most definitely have a
non-null intersection. What am I missing?
@SuppressWarnings( rawtypes )
@Test
public void testIntersection() throws Exception {
CollectionString c1 = new ArrayListString();
CollectionString c2 = new ArrayListString();
/*
* An exhaustive black box test here
* would involve generating a great deal of data,
* perhaps even different sizes and collection classes.
*/
c1.add(red);
c1.add(blue);
c1.add(green);
c1.add(socialist);
c1.add(red);
c1.add(purple);
c1.add(porpoise);
c1.add(green);
c1.add(blue);
c1.add(gray);
c1.add(blue);
c1.add(12);
c1.add(15);
c1.add(blue);
c1.add(porpoise);
c1.add(33.3);
c1.add(jabberwock);
MultisetString correct = HashMultiset.create();
correct.add( blue );
correct.add( blue );
correct.add( porpoise );
@SuppressWarnings( unchecked )
CollectionString res = CollectionUtils.intersection( c1, c2 );
MultisetString actual = HashMultiset.create();
actual.addAll(res);
assertEquals( correct, actual );
}
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: org.codehaus.plexus.util.CollectionUtils.intersection
On 12 June 2011 20:23, Benson Margulies bimargul...@gmail.com wrote:
I think I've written a unit test for the contract of this function as
written in the javadoc, but it fails. The intersection function
returns an empty collection when the inputs most definitely have a
non-null intersection. What am I missing?
@SuppressWarnings( rawtypes )
@Test
public void testIntersection() throws Exception {
CollectionString c1 = new ArrayListString();
CollectionString c2 = new ArrayListString();
/*
* An exhaustive black box test here
* would involve generating a great deal of data,
* perhaps even different sizes and collection classes.
*/
c1.add(red);
c1.add(blue);
c1.add(green);
c1.add(socialist);
c1.add(red);
c1.add(purple);
c1.add(porpoise);
c1.add(green);
c1.add(blue);
c1.add(gray);
c1.add(blue);
c1.add(12);
c1.add(15);
c1.add(blue);
c1.add(porpoise);
c1.add(33.3);
c1.add(jabberwock);
MultisetString correct = HashMultiset.create();
correct.add( blue );
correct.add( blue );
correct.add( porpoise );
@SuppressWarnings( unchecked )
CollectionString res = CollectionUtils.intersection( c1, c2 );
MultisetString actual = HashMultiset.create();
actual.addAll(res);
assertEquals( correct, actual );
I hate the bog standard assertEquals on collections... if you'd used
the new style assertThat( actual, ... ) with the appropriate matcher
you'd have better debug info ;-)
}
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: org.codehaus.plexus.util.CollectionUtils.intersection
Next class. I haven't learned that one yet.
On Sun, Jun 12, 2011 at 3:39 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 12 June 2011 20:23, Benson Margulies bimargul...@gmail.com wrote:
I think I've written a unit test for the contract of this function as
written in the javadoc, but it fails. The intersection function
returns an empty collection when the inputs most definitely have a
non-null intersection. What am I missing?
@SuppressWarnings( rawtypes )
@Test
public void testIntersection() throws Exception {
CollectionString c1 = new ArrayListString();
CollectionString c2 = new ArrayListString();
/*
* An exhaustive black box test here
* would involve generating a great deal of data,
* perhaps even different sizes and collection classes.
*/
c1.add(red);
c1.add(blue);
c1.add(green);
c1.add(socialist);
c1.add(red);
c1.add(purple);
c1.add(porpoise);
c1.add(green);
c1.add(blue);
c1.add(gray);
c1.add(blue);
c1.add(12);
c1.add(15);
c1.add(blue);
c1.add(porpoise);
c1.add(33.3);
c1.add(jabberwock);
MultisetString correct = HashMultiset.create();
correct.add( blue );
correct.add( blue );
correct.add( porpoise );
@SuppressWarnings( unchecked )
CollectionString res = CollectionUtils.intersection( c1, c2 );
MultisetString actual = HashMultiset.create();
actual.addAll(res);
assertEquals( correct, actual );
I hate the bog standard assertEquals on collections... if you'd used
the new style assertThat( actual, ... ) with the appropriate matcher
you'd have better debug info ;-)
}
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: org.codehaus.plexus.util.CollectionUtils.intersection
At the very leaset
assertThat(actual, is(expected));
gives better diagnostics
then there is
assertThat(actual, not(is(unexpected));
nice ones are
assertThat(actual, hasItems(expectedContents));
On 12 June 2011 20:43, Benson Margulies bimargul...@gmail.com wrote:
Next class. I haven't learned that one yet.
On Sun, Jun 12, 2011 at 3:39 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 12 June 2011 20:23, Benson Margulies bimargul...@gmail.com wrote:
I think I've written a unit test for the contract of this function as
written in the javadoc, but it fails. The intersection function
returns an empty collection when the inputs most definitely have a
non-null intersection. What am I missing?
@SuppressWarnings( rawtypes )
@Test
public void testIntersection() throws Exception {
CollectionString c1 = new ArrayListString();
CollectionString c2 = new ArrayListString();
/*
* An exhaustive black box test here
* would involve generating a great deal of data,
* perhaps even different sizes and collection classes.
*/
c1.add(red);
c1.add(blue);
c1.add(green);
c1.add(socialist);
c1.add(red);
c1.add(purple);
c1.add(porpoise);
c1.add(green);
c1.add(blue);
c1.add(gray);
c1.add(blue);
c1.add(12);
c1.add(15);
c1.add(blue);
c1.add(porpoise);
c1.add(33.3);
c1.add(jabberwock);
MultisetString correct = HashMultiset.create();
correct.add( blue );
correct.add( blue );
correct.add( porpoise );
@SuppressWarnings( unchecked )
CollectionString res = CollectionUtils.intersection( c1, c2 );
MultisetString actual = HashMultiset.create();
actual.addAll(res);
assertEquals( correct, actual );
I hate the bog standard assertEquals on collections... if you'd used
the new style assertThat( actual, ... ) with the appropriate matcher
you'd have better debug info ;-)
}
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Anyone want to help?
In the case of CollectionUtils, I don't see why we shouldn't keep the
existing implementation. In most cases, it would be better to replace
the use of this class with Guava, but, to the extent that we are using
it, we're not going to find a better implementation in 'commons' that
replaces Olivier's thing.
On Tue, May 24, 2011 at 5:28 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I'm working on providing a compatibility layer for plexus-utils that
uses the commons-* stuff to provide the implementation.
If anyone is interested in helping please shout out.
Most of the work is actually writing the crazy test cases, everything
else should be simple shims through to existing commons functionality.
You can join in here if you are an Apache Committer (sandbox is open
to all Apache Committers)
https://svn.apache.org/repos/asf/maven/sandbox/trunk/plexus-utils-commons-bridge
Pick a plexus-utils class, and start creating tests... better still
write the tests black box (that's what I am doing!)
Then when you have some tests written in the TCK module, create the
implementation class with all the methods:
{ throw new UnsupportedOperationException(Not implemented yet!); }
and then you can knock off implementations and see your test pass rate
rise in the bridge module.
I'm tackling IOUtil first and then PropertyUtils.
To stake your claim, commit the test case class first and then unless
you tell us otherwise you are working on that class!
-Stephen
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
/plexus-utils/src/main/java/org/codehaus/plexus/util/FastMap.java
This is just a copy of a class from javolution with the package name changed. Javolution is BSD licensed. So, I propose to add the dependency, create a pass-through class in the plexus package, and write no tests, on the theory that the javolution people have adequate tests for themselves. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Anyone want to help?
if guava is a better replacement and is ASL, i'm fine with it as a good fit
On 12 June 2011 20:52, Benson Margulies bimargul...@gmail.com wrote:
In the case of CollectionUtils, I don't see why we shouldn't keep the
existing implementation. In most cases, it would be better to replace
the use of this class with Guava, but, to the extent that we are using
it, we're not going to find a better implementation in 'commons' that
replaces Olivier's thing.
On Tue, May 24, 2011 at 5:28 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I'm working on providing a compatibility layer for plexus-utils that
uses the commons-* stuff to provide the implementation.
If anyone is interested in helping please shout out.
Most of the work is actually writing the crazy test cases, everything
else should be simple shims through to existing commons functionality.
You can join in here if you are an Apache Committer (sandbox is open
to all Apache Committers)
https://svn.apache.org/repos/asf/maven/sandbox/trunk/plexus-utils-commons-bridge
Pick a plexus-utils class, and start creating tests... better still
write the tests black box (that's what I am doing!)
Then when you have some tests written in the TCK module, create the
implementation class with all the methods:
{ throw new UnsupportedOperationException(Not implemented yet!); }
and then you can knock off implementations and see your test pass rate
rise in the bridge module.
I'm tackling IOUtil first and then PropertyUtils.
To stake your claim, commit the test case class first and then unless
you tell us otherwise you are working on that class!
-Stephen
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1134972 - in /maven/sandbox/trunk/plexus-utils-commons-bridge: plexus-utils-commons-bridge/pom.xml plexus-utils-commons-bridge/src/main/java/org/codehaus/plexus/util/CollectionUtils.j
pom formatting got changed there
On 12 June 2011 20:57, bimargul...@apache.org wrote:
Author: bimargulies
Date: Sun Jun 12 19:57:40 2011
New Revision: 1134972
URL: http://svn.apache.org/viewvc?rev=1134972view=rev
Log:
Take existing CollectionUtils as new implementation.
Added:
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/src/main/java/org/codehaus/plexus/util/CollectionUtils.java
(with props)
Modified:
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/pom.xml
Modified:
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml
URL:
http://svn.apache.org/viewvc/maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml?rev=1134972r1=1134971r2=1134972view=diff
==
---
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml
(original)
+++
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml
Sun Jun 12 19:57:40 2011
@@ -1,63 +1,68 @@
?xml version=1.0 encoding=UTF-8?
-project xmlns=http://maven.apache.org/POM/4.0.0;
- xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
- xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
- modelVersion4.0.0/modelVersion
-
- parent
- artifactIdplexus-utils-commons-bridge-parent/artifactId
- groupIdorg.apache.maven.sandbox/groupId
- version0.1-SNAPSHOT/version
- /parent
-
- artifactIdplexus-utils-commons-bridge/artifactId
-
- namePlexus Utils to Apache Commons bridge/name
- descriptionA bridge/shim that implements Plexus Utils using Apache
Commons/description
-
- dependencies
- dependency
- groupIdcommons-io/groupId
- artifactIdcommons-io/artifactId
- /dependency
- dependency
- groupIdcommons-codec/groupId
- artifactIdcommons-codec/artifactId
- /dependency
- dependency
- groupIdjunit/groupId
- artifactIdjunit/artifactId
- scopetest/scope
- /dependency
- dependency
- groupIdorg.apache.maven.sandbox/groupId
- artifactIdplexus-utils-tck/artifactId
- version${project.parent.version}/version
- typetest-jar/type
- scopetest/scope
- /dependency
- /dependencies
-
- build
- plugins
- plugin
- artifactIdmaven-dependency-plugin/artifactId
- executions
- execution
- phasegenerate-test-resources/phase
- goals
- goalunpack-dependencies/goal
- /goals
- configuration
- includeTypestest-jar/includeTypes
- excludeTransitivetrue/excludeTransitive
-
outputDirectory${project.build.testOutputDirectory}/outputDirectory
- /configuration
- /execution
- /executions
- /plugin
- /plugins
- /build
+project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
+ modelVersion4.0.0/modelVersion
+
+ parent
+ artifactIdplexus-utils-commons-bridge-parent/artifactId
+ groupIdorg.apache.maven.sandbox/groupId
+ version0.1-SNAPSHOT/version
+ /parent
+
+ artifactIdplexus-utils-commons-bridge/artifactId
+
+ namePlexus Utils to Apache Commons bridge/name
+ descriptionA bridge/shim that implements Plexus Utils using Apache
Commons/description
+
+ dependencies
+ dependency
+ groupIdcommons-io/groupId
+ artifactIdcommons-io/artifactId
+ /dependency
+ dependency
+ groupIdcommons-codec/groupId
+ artifactIdcommons-codec/artifactId
+ /dependency
+ dependency
+ groupIdjunit/groupId
+ artifactIdjunit/artifactId
+ scopetest/scope
+ /dependency
+ dependency
+ groupIdorg.apache.maven.sandbox/groupId
+ artifactIdplexus-utils-tck/artifactId
+ version${project.parent.version}/version
+ typetest-jar/type
+ scopetest/scope
+ /dependency
+ dependency
+ groupIdcom.google.guava/groupId
+ artifactIdguava/artifactId
+ versionr09/version
+ scopetest/scope
+ /dependency
+ /dependencies
+
+ build
+ plugins
+
Re: /plexus-utils/src/main/java/org/codehaus/plexus/util/FastMap.java
why not copy their tests... or are you suggesting that the replacement is to use the class directly? On 12 June 2011 21:01, Benson Margulies bimargul...@gmail.com wrote: This is just a copy of a class from javolution with the package name changed. Javolution is BSD licensed. So, I propose to add the dependency, create a pass-through class in the plexus package, and write no tests, on the theory that the javolution people have adequate tests for themselves. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Anyone want to help?
The static functions in CollectionUtils are substitutes for the
Multi-collections in Guava. So, to substitute Guava, you have to
rewrite the callers to actually use Multiset (or whatever) and not
need these functions at all. That could get fiddly. So keeping this
class in the bridge seems reasonable to me to give us more
flexibility.
On Sun, Jun 12, 2011 at 4:07 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
if guava is a better replacement and is ASL, i'm fine with it as a good fit
On 12 June 2011 20:52, Benson Margulies bimargul...@gmail.com wrote:
In the case of CollectionUtils, I don't see why we shouldn't keep the
existing implementation. In most cases, it would be better to replace
the use of this class with Guava, but, to the extent that we are using
it, we're not going to find a better implementation in 'commons' that
replaces Olivier's thing.
On Tue, May 24, 2011 at 5:28 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I'm working on providing a compatibility layer for plexus-utils that
uses the commons-* stuff to provide the implementation.
If anyone is interested in helping please shout out.
Most of the work is actually writing the crazy test cases, everything
else should be simple shims through to existing commons functionality.
You can join in here if you are an Apache Committer (sandbox is open
to all Apache Committers)
https://svn.apache.org/repos/asf/maven/sandbox/trunk/plexus-utils-commons-bridge
Pick a plexus-utils class, and start creating tests... better still
write the tests black box (that's what I am doing!)
Then when you have some tests written in the TCK module, create the
implementation class with all the methods:
{ throw new UnsupportedOperationException(Not implemented yet!); }
and then you can knock off implementations and see your test pass rate
rise in the bridge module.
I'm tackling IOUtil first and then PropertyUtils.
To stake your claim, commit the test case class first and then unless
you tell us otherwise you are working on that class!
-Stephen
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: /plexus-utils/src/main/java/org/codehaus/plexus/util/FastMap.java
The later, I think. Is it reasonable to simply ditch FastMap from the bridge, and plan to add a javolution dependency to each place we find a use of FastMap? That would be my recommendation now that you ask. On Sun, Jun 12, 2011 at 4:08 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: why not copy their tests... or are you suggesting that the replacement is to use the class directly? On 12 June 2011 21:01, Benson Margulies bimargul...@gmail.com wrote: This is just a copy of a class from javolution with the package name changed. Javolution is BSD licensed. So, I propose to add the dependency, create a pass-through class in the plexus package, and write no tests, on the theory that the javolution people have adequate tests for themselves. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Anyone want to help?
I'm more saying if you want to use guava as the back end for the new impl,
On 12 June 2011 21:11, Benson Margulies bimargul...@gmail.com wrote:
The static functions in CollectionUtils are substitutes for the
Multi-collections in Guava. So, to substitute Guava, you have to
rewrite the callers to actually use Multiset (or whatever) and not
need these functions at all. That could get fiddly. So keeping this
class in the bridge seems reasonable to me to give us more
flexibility.
On Sun, Jun 12, 2011 at 4:07 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
if guava is a better replacement and is ASL, i'm fine with it as a good fit
On 12 June 2011 20:52, Benson Margulies bimargul...@gmail.com wrote:
In the case of CollectionUtils, I don't see why we shouldn't keep the
existing implementation. In most cases, it would be better to replace
the use of this class with Guava, but, to the extent that we are using
it, we're not going to find a better implementation in 'commons' that
replaces Olivier's thing.
On Tue, May 24, 2011 at 5:28 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I'm working on providing a compatibility layer for plexus-utils that
uses the commons-* stuff to provide the implementation.
If anyone is interested in helping please shout out.
Most of the work is actually writing the crazy test cases, everything
else should be simple shims through to existing commons functionality.
You can join in here if you are an Apache Committer (sandbox is open
to all Apache Committers)
https://svn.apache.org/repos/asf/maven/sandbox/trunk/plexus-utils-commons-bridge
Pick a plexus-utils class, and start creating tests... better still
write the tests black box (that's what I am doing!)
Then when you have some tests written in the TCK module, create the
implementation class with all the methods:
{ throw new UnsupportedOperationException(Not implemented yet!); }
and then you can knock off implementations and see your test pass rate
rise in the bridge module.
I'm tackling IOUtil first and then PropertyUtils.
To stake your claim, commit the test case class first and then unless
you tell us otherwise you are working on that class!
-Stephen
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1134972 - in /maven/sandbox/trunk/plexus-utils-commons-bridge: plexus-utils-commons-bridge/pom.xml plexus-utils-commons-bridge/src/main/java/org/codehaus/plexus/util/CollectionUtils.j
I assumed that the incoming POM had been formatted with the eclipse
format from the standard maven rules, so that I could run
source/format safely. Apparently I made a bad assumption.
Shall I put it back?
On Sun, Jun 12, 2011 at 4:08 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
pom formatting got changed there
On 12 June 2011 20:57, bimargul...@apache.org wrote:
Author: bimargulies
Date: Sun Jun 12 19:57:40 2011
New Revision: 1134972
URL: http://svn.apache.org/viewvc?rev=1134972view=rev
Log:
Take existing CollectionUtils as new implementation.
Added:
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/src/main/java/org/codehaus/plexus/util/CollectionUtils.java
(with props)
Modified:
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/pom.xml
Modified:
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml
URL:
http://svn.apache.org/viewvc/maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml?rev=1134972r1=1134971r2=1134972view=diff
==
---
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml
(original)
+++
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml
Sun Jun 12 19:57:40 2011
@@ -1,63 +1,68 @@
?xml version=1.0 encoding=UTF-8?
-project xmlns=http://maven.apache.org/POM/4.0.0;
- xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
- xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
- modelVersion4.0.0/modelVersion
-
- parent
- artifactIdplexus-utils-commons-bridge-parent/artifactId
- groupIdorg.apache.maven.sandbox/groupId
- version0.1-SNAPSHOT/version
- /parent
-
- artifactIdplexus-utils-commons-bridge/artifactId
-
- namePlexus Utils to Apache Commons bridge/name
- descriptionA bridge/shim that implements Plexus Utils using Apache
Commons/description
-
- dependencies
- dependency
- groupIdcommons-io/groupId
- artifactIdcommons-io/artifactId
- /dependency
- dependency
- groupIdcommons-codec/groupId
- artifactIdcommons-codec/artifactId
- /dependency
- dependency
- groupIdjunit/groupId
- artifactIdjunit/artifactId
- scopetest/scope
- /dependency
- dependency
- groupIdorg.apache.maven.sandbox/groupId
- artifactIdplexus-utils-tck/artifactId
- version${project.parent.version}/version
- typetest-jar/type
- scopetest/scope
- /dependency
- /dependencies
-
- build
- plugins
- plugin
- artifactIdmaven-dependency-plugin/artifactId
- executions
- execution
- phasegenerate-test-resources/phase
- goals
- goalunpack-dependencies/goal
- /goals
- configuration
- includeTypestest-jar/includeTypes
- excludeTransitivetrue/excludeTransitive
-
outputDirectory${project.build.testOutputDirectory}/outputDirectory
- /configuration
- /execution
- /executions
- /plugin
- /plugins
- /build
+project xmlns=http://maven.apache.org/POM/4.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
+ modelVersion4.0.0/modelVersion
+
+ parent
+ artifactIdplexus-utils-commons-bridge-parent/artifactId
+ groupIdorg.apache.maven.sandbox/groupId
+ version0.1-SNAPSHOT/version
+ /parent
+
+ artifactIdplexus-utils-commons-bridge/artifactId
+
+ namePlexus Utils to Apache Commons bridge/name
+ descriptionA bridge/shim that implements Plexus Utils using Apache
Commons/description
+
+ dependencies
+ dependency
+ groupIdcommons-io/groupId
+ artifactIdcommons-io/artifactId
+ /dependency
+ dependency
+ groupIdcommons-codec/groupId
+ artifactIdcommons-codec/artifactId
+ /dependency
+ dependency
+ groupIdjunit/groupId
+ artifactIdjunit/artifactId
+ scopetest/scope
+ /dependency
+ dependency
+ groupIdorg.apache.maven.sandbox/groupId
+ artifactIdplexus-utils-tck/artifactId
+ version${project.parent.version}/version
+ typetest-jar/type
+ scopetest/scope
+ /dependency
+
Re: Anyone want to help?
There's no good way to use Guava to replace the existing code from
olamy inside of CollectionUtils.
The situation is this:
Existing code makes plain java.util.Collections objects, and uses
CollectionUtils to perform some multi-set-ish operations on them.
Hopeful future code would use Guava multi-collection objects, and just
use their native methods for mult-set-is operations.
Guava doesn't have a superior mechanism for starting with plain
collections and doing this stuff.
On Sun, Jun 12, 2011 at 4:12 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I'm more saying if you want to use guava as the back end for the new impl,
On 12 June 2011 21:11, Benson Margulies bimargul...@gmail.com wrote:
The static functions in CollectionUtils are substitutes for the
Multi-collections in Guava. So, to substitute Guava, you have to
rewrite the callers to actually use Multiset (or whatever) and not
need these functions at all. That could get fiddly. So keeping this
class in the bridge seems reasonable to me to give us more
flexibility.
On Sun, Jun 12, 2011 at 4:07 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
if guava is a better replacement and is ASL, i'm fine with it as a good fit
On 12 June 2011 20:52, Benson Margulies bimargul...@gmail.com wrote:
In the case of CollectionUtils, I don't see why we shouldn't keep the
existing implementation. In most cases, it would be better to replace
the use of this class with Guava, but, to the extent that we are using
it, we're not going to find a better implementation in 'commons' that
replaces Olivier's thing.
On Tue, May 24, 2011 at 5:28 AM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
I'm working on providing a compatibility layer for plexus-utils that
uses the commons-* stuff to provide the implementation.
If anyone is interested in helping please shout out.
Most of the work is actually writing the crazy test cases, everything
else should be simple shims through to existing commons functionality.
You can join in here if you are an Apache Committer (sandbox is open
to all Apache Committers)
https://svn.apache.org/repos/asf/maven/sandbox/trunk/plexus-utils-commons-bridge
Pick a plexus-utils class, and start creating tests... better still
write the tests black box (that's what I am doing!)
Then when you have some tests written in the TCK module, create the
implementation class with all the methods:
{ throw new UnsupportedOperationException(Not implemented yet!); }
and then you can knock off implementations and see your test pass rate
rise in the bridge module.
I'm tackling IOUtil first and then PropertyUtils.
To stake your claim, commit the test case class first and then unless
you tell us otherwise you are working on that class!
-Stephen
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Truly awful code in plexus...
There are some deprecated classes in here that are completely busted with respect to char encoding. Do we replace them with undeprecated versions with the same bugs? Or with calls to commons IO that do things right? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1134972 - in /maven/sandbox/trunk/plexus-utils-commons-bridge: plexus-utils-commons-bridge/pom.xml plexus-utils-commons-bridge/src/main/java/org/codehaus/plexus/util/CollectionUtils.j
I'll run in through the intellij rules again, see if there is a difference
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 12 Jun 2011 21:14, Benson Margulies bimargul...@gmail.com wrote:
I assumed that the incoming POM had been formatted with the eclipse
format from the standard maven rules, so that I could run
source/format safely. Apparently I made a bad assumption.
Shall I put it back?
On Sun, Jun 12, 2011 at 4:08 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
pom formatting got changed there
On 12 June 2011 20:57, bimargul...@apache.org wrote:
Author: bimargulies
Date: Sun Jun 12 19:57:40 2011
New Revision: 1134972
URL: http://svn.apache.org/viewvc?rev=1134972view=rev
Log:
Take existing CollectionUtils as new implementation.
Added:
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/src/main/java/org/codehaus/plexus/util/CollectionUtils.java
(with props)
Modified:
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/pom.xml
Modified:
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml
URL:
http://svn.apache.org/viewvc/maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml?rev=1134972r1=1134971r2=1134972view=diff
==
---
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml
(original)
+++
maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-commons-bridge/pom.xml
Sun Jun 12 19:57:40 2011
@@ -1,63 +1,68 @@
?xml version=1.0 encoding=UTF-8?
-project xmlns=http://maven.apache.org/POM/4.0.0;
- xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
- xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
- modelVersion4.0.0/modelVersion
-
- parent
-artifactIdplexus-utils-commons-bridge-parent/artifactId
-groupIdorg.apache.maven.sandbox/groupId
-version0.1-SNAPSHOT/version
- /parent
-
- artifactIdplexus-utils-commons-bridge/artifactId
-
- namePlexus Utils to Apache Commons bridge/name
- descriptionA bridge/shim that implements Plexus Utils using Apache
Commons/description
-
- dependencies
-dependency
- groupIdcommons-io/groupId
- artifactIdcommons-io/artifactId
-/dependency
-dependency
- groupIdcommons-codec/groupId
- artifactIdcommons-codec/artifactId
-/dependency
-dependency
- groupIdjunit/groupId
- artifactIdjunit/artifactId
- scopetest/scope
-/dependency
-dependency
- groupIdorg.apache.maven.sandbox/groupId
- artifactIdplexus-utils-tck/artifactId
- version${project.parent.version}/version
- typetest-jar/type
- scopetest/scope
-/dependency
- /dependencies
-
- build
-plugins
- plugin
-artifactIdmaven-dependency-plugin/artifactId
-executions
- execution
-phasegenerate-test-resources/phase
-goals
- goalunpack-dependencies/goal
-/goals
-configuration
- includeTypestest-jar/includeTypes
- excludeTransitivetrue/excludeTransitive
-
outputDirectory${project.build.testOutputDirectory}/outputDirectory
-/configuration
- /execution
-/executions
- /plugin
-/plugins
- /build
+project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=
http://www.w3.org/2001/XMLSchema-instance;
+ xsi:schemaLocation=http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd;
+ modelVersion4.0.0/modelVersion
+
+ parent
+
artifactIdplexus-utils-commons-bridge-parent/artifactId
+ groupIdorg.apache.maven.sandbox/groupId
+ version0.1-SNAPSHOT/version
+ /parent
+
+ artifactIdplexus-utils-commons-bridge/artifactId
+
+ namePlexus Utils to Apache Commons bridge/name
+ descriptionA bridge/shim that implements Plexus Utils using
Apache Commons/description
+
+ dependencies
+ dependency
+ groupIdcommons-io/groupId
+ artifactIdcommons-io/artifactId
+ /dependency
+ dependency
+ groupIdcommons-codec/groupId
+ artifactIdcommons-codec/artifactId
+ /dependency
+ dependency
+ groupIdjunit/groupId
+ artifactIdjunit/artifactId
+ scopetest/scope
+ /dependency
+ dependency
+ groupIdorg.apache.maven.sandbox/groupId
+
Re: Truly awful code in plexus...
here is my thoughts, for first release we need to have a drop in replacement that works exactly the same as the original... that gives us a way to kill the old version (otherwise people will just say, I'm not going to fix my code when it works fine with plexus utils... ok maybe I'll fix it later) we will mark every method and class in the bridge as deprecated, but we need the recommendations for each replacement to put in the deprecated tags. for the second release we flip the @reproducesplexusbug rule and fix all those test cases for the third release, everything is deprecated - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 12 Jun 2011 21:24, Benson Margulies bimargul...@gmail.com wrote:
Re: Truly awful code in plexus...
Then we will need the bridged FastMap I described. I'll take care of it. On Sun, Jun 12, 2011 at 6:03 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: here is my thoughts, for first release we need to have a drop in replacement that works exactly the same as the original... that gives us a way to kill the old version (otherwise people will just say, I'm not going to fix my code when it works fine with plexus utils... ok maybe I'll fix it later) we will mark every method and class in the bridge as deprecated, but we need the recommendations for each replacement to put in the deprecated tags. for the second release we flip the @reproducesplexusbug rule and fix all those test cases for the third release, everything is deprecated - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 12 Jun 2011 21:24, Benson Margulies bimargul...@gmail.com wrote: - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Truly awful code in plexus...
strategy added in the proposal [1], for future reference Regards, Hervé [1] https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement Le lundi 13 juin 2011, Stephen Connolly a écrit : here is my thoughts, for first release we need to have a drop in replacement that works exactly the same as the original... that gives us a way to kill the old version (otherwise people will just say, I'm not going to fix my code when it works fine with plexus utils... ok maybe I'll fix it later) we will mark every method and class in the bridge as deprecated, but we need the recommendations for each replacement to put in the deprecated tags. for the second release we flip the @reproducesplexusbug rule and fix all those test cases for the third release, everything is deprecated - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 12 Jun 2011 21:24, Benson Margulies bimargul...@gmail.com wrote: - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Truly awful code in plexus...
thanks - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 12 Jun 2011 23:25, Hervé BOUTEMY herve.bout...@free.fr wrote: strategy added in the proposal [1], for future reference Regards, Hervé [1] https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement Le lundi 13 juin 2011, Stephen Connolly a écrit : here is my thoughts, for first release we need to have a drop in replacement that works exactly the same as the original... that gives us a way to kill the old version (otherwise people will just say, I'm not going to fix my code when it works fine with plexus utils... ok maybe I'll fix it later) we will mark every method and class in the bridge as deprecated, but we need the recommendations for each replacement to put in the deprecated tags. for the second release we flip the @reproducesplexusbug rule and fix all those test cases for the third release, everything is deprecated - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 12 Jun 2011 21:24, Benson Margulies bimargul...@gmail.com wrote: - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Truly awful code in plexus...
If we want to keep the broken behavior of these already @Deprecated classes, then I'd think we'd just copy them wholesale from plexus to the bridge. There's no advantage in replacing an old broken version with a new broken, and they're already deprecated, and the right thing to do to callers is to make them use modern methods. On Sun, Jun 12, 2011 at 6:33 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: thanks - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 12 Jun 2011 23:25, Hervé BOUTEMY herve.bout...@free.fr wrote: strategy added in the proposal [1], for future reference Regards, Hervé [1] https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement Le lundi 13 juin 2011, Stephen Connolly a écrit : here is my thoughts, for first release we need to have a drop in replacement that works exactly the same as the original... that gives us a way to kill the old version (otherwise people will just say, I'm not going to fix my code when it works fine with plexus utils... ok maybe I'll fix it later) we will mark every method and class in the bridge as deprecated, but we need the recommendations for each replacement to put in the deprecated tags. for the second release we flip the @reproducesplexusbug rule and fix all those test cases for the third release, everything is deprecated - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 12 Jun 2011 21:24, Benson Margulies bimargul...@gmail.com wrote: - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [REDUX] Java Service Wrappers (JSW) unfortunate license change
If you open up the wrapper-delta-pack that the appassembler depends on, doc/license.txt describes the license it was released under. It is not GPL or LGPL as asserted in this thread. None of this discussion is really relevant for this list... except maybe that pointing to a URL for a license in the POM is not a good idea. If someone wants to take up that issue, I would recommend changing it to a reference within the repository, so that we can ensure some list of immutable licenses. - Brett On 13/06/2011, at 4:03 AM, Benson Margulies wrote: So, the lesson I take from this is that the appassembler would never have been releasable at Apache, and that releasing it at codehaus without getting the author (who happens to be in Japan) to provide an unambiguous license was perhaps ill-advised. On Sun, Jun 12, 2011 at 1:54 PM, Robert Burrell Donkin robertburrelldon...@gmail.com wrote: On Sun, Jun 12, 2011 at 4:32 PM, Mark Struberg strub...@yahoo.de wrote: just an idea: what about extending the maven-release-plugin to ask for a license if the pom doesn't contain a license section? In principle, this would be a good feature to add to a verification tool like Rat. In this case, JSW has a license section but that license contains meta-licensing information (a way for a user to obtain a license, rather than a direct license) Robert - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: org.codehaus.plexus.util.CollectionUtils.intersection
With what JUnit version? I just tested is() and hasItems() and the
failure reporting message is 99% the same as assertEquals() with JUnit
4.8.2. They both display toString()s of the expected and actuals,
just prefixed with different names/words. What am I missing?
On Sun, Jun 12, 2011 at 2:52 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
At the very leaset
assertThat(actual, is(expected));
gives better diagnostics
then there is
assertThat(actual, not(is(unexpected));
nice ones are
assertThat(actual, hasItems(expectedContents));
On 12 June 2011 20:43, Benson Margulies bimargul...@gmail.com wrote:
Next class. I haven't learned that one yet.
On Sun, Jun 12, 2011 at 3:39 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On 12 June 2011 20:23, Benson Margulies bimargul...@gmail.com wrote:
I think I've written a unit test for the contract of this function as
written in the javadoc, but it fails. The intersection function
returns an empty collection when the inputs most definitely have a
non-null intersection. What am I missing?
@SuppressWarnings( rawtypes )
@Test
public void testIntersection() throws Exception {
CollectionString c1 = new ArrayListString();
CollectionString c2 = new ArrayListString();
/*
* An exhaustive black box test here
* would involve generating a great deal of data,
* perhaps even different sizes and collection classes.
*/
c1.add(red);
c1.add(blue);
c1.add(green);
c1.add(socialist);
c1.add(red);
c1.add(purple);
c1.add(porpoise);
c1.add(green);
c1.add(blue);
c1.add(gray);
c1.add(blue);
c1.add(12);
c1.add(15);
c1.add(blue);
c1.add(porpoise);
c1.add(33.3);
c1.add(jabberwock);
MultisetString correct = HashMultiset.create();
correct.add( blue );
correct.add( blue );
correct.add( porpoise );
@SuppressWarnings( unchecked )
CollectionString res = CollectionUtils.intersection( c1, c2 );
MultisetString actual = HashMultiset.create();
actual.addAll(res);
assertEquals( correct, actual );
I hate the bog standard assertEquals on collections... if you'd used
the new style assertThat( actual, ... ) with the appropriate matcher
you'd have better debug info ;-)
}
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Release Maven Indexer version 4.1.1
+1 checked the signature and RAT, and that the source release built successfully. On 10/06/2011, at 12:26 AM, Tamás Cservenák wrote: Hi, Current 4.1.1 version is mostly bugfix release for latest 4.0.1 improving indexer robustness, lessen unnecessary IO burden and smaller POM fixes regarding site publishing. We solved 5 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=12112version=17410 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truemode=hidejqlQuery=project+%3D+MINDEXER+AND+resolution+%3D+Unresolved+ORDER+BY+updated+DESC Staging repo: https://repository.apache.org/content/repositories/maven-060/ Guide to testing staged releases: http://maven.apache.org/guides/development/guide-testing-releases.html Vote open for 72 hours. [ ] +1 [ ] +0 [ ] -1 Thanks, ~t~ - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Truly awful code in plexus...
if we knew the provenance of the plexus code, yes... but we don't - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 13 Jun 2011 00:12, Benson Margulies bimargul...@gmail.com wrote: If we want to keep the broken behavior of these already @Deprecated classes, then I'd think we'd just copy them wholesale from plexus to the bridge. There's no advantage in replacing an old broken version with a new broken, and they're already deprecated, and the right thing to do to callers is to make them use modern methods. On Sun, Jun 12, 2011 at 6:33 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: thanks - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 12 Jun 2011 23:25, Hervé BOUTEMY herve.bout...@free.fr wrote: strategy added in the proposal [1], for future reference Regards, Hervé [1] https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement Le lundi 13 juin 2011, Stephen Connolly a écrit : here is my thoughts, for first release we need to have a drop in replacement that works exactly the same as the original... that gives us a way to kill the old version (otherwise people will just say, I'm not going to fix my code when it works fine with plexus utils... ok maybe I'll fix it later) we will mark every method and class in the bridge as deprecated, but we need the recommendations for each replacement to put in the deprecated tags. for the second release we flip the @reproducesplexusbug rule and fix all those test cases for the third release, everything is deprecated - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 12 Jun 2011 21:24, Benson Margulies bimargul...@gmail.com wrote: - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
