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
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
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
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
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
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
I've also set up a Jenkins job to track this:
https://builds.apache.org/hudson/view/M-R/view/Maven/job/maven-sandbox-plexus-utils-commons-bridge/
On 24 May 2011 10:28, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
I'm working on providing a compatibility layer for plexus-utils that
: Anyone want to help?
From: stephen.alan.conno...@gmail.com
To: dev@maven.apache.org
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
I'd be pleased to join,
(let's drop this dinosaur)
Should we setup a wiki page to know who is working on wich part, let
contributors pick-up tasks, and trace progess ?
Should we clone the svn repo to github / apache extras so that non-apache
contributors can help (I'm an optimistic naive guy :P)
On 24 May 2011 11:45, nicolas de loof nicolas.del...@gmail.com wrote:
I'd be pleased to join,
(let's drop this dinosaur)
Should we setup a wiki page to know who is working on wich part, let
contributors pick-up tasks, and trace progess ?
+1 and Nike it: Just do it(tm)
Should we clone the
Hi Martin!
The idea is about doing a misture between Test Driven Development and BlackBox
Testing / Unit Testing.
LieGrue,
strub
--- On Tue, 5/24/11, Martin Gainty mgai...@hotmail.com wrote:
From: Martin Gainty mgai...@hotmail.com
Subject: RE: Anyone want to help?
To: dev@maven.apache.org
wrote:
From: Martin Gainty mgai...@hotmail.com
Subject: RE: Anyone want to help?
To: dev@maven.apache.org
Date: Tuesday, May 24, 2011, 10:29 AM
isnt the job of the software engineer to write test-cases
to prove their software works?
Martin
+1 and Nike it: Just do it(tm)
http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement
2011/5/24 nicolas de loof nicolas.del...@gmail.com:
+1 and Nike it: Just do it(tm)
http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement
Thanks.
But personnally I would prefer we use Apache confluence :
https://cwiki.apache.org/confluence/display/MAVEN .
--
Olivier Lamy
Oups, moved to
https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement
2011/5/24 Olivier Lamy ol...@apache.org
2011/5/24 nicolas de loof nicolas.del...@gmail.com:
+1 and Nike it: Just do it(tm)
http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement
ti., 24.05.2011 kl. 12.23 +0100, skrev Stephen Connolly:
The general consensus is that Martin is a bot.
The idea is that we write tests that cover all the functionality of
plexus-utils (preference is to write tests without looking at the
plexus-utils code so that the tests are somewhat
On 24 May 2011 16:05, Kristian Rosenvold kristian.rosenv...@gmail.com wrote:
ti., 24.05.2011 kl. 12.23 +0100, skrev Stephen Connolly:
The general consensus is that Martin is a bot.
The idea is that we write tests that cover all the functionality of
plexus-utils (preference is to write tests
Hey if we could just copy the plexus source code in tree we wouldn't
be doing this would we? If you have the provenance of the code and it
is ASL license friendly, then fine copy paste.
That'd really be depending on the overall usage of a shim layer,
wouldn't it ? I think a shim makes
Not exactly clean room, but I have a feeling a lot of test cases could be
copied from the given commons-* projects such as:
http://svn.apache.org/viewvc/commons/proper/io/trunk/src/test/java/org/apache/commons/io/FileUtilsTestCase.java?view=markup
This should work for methods with the same
they are fine. if they pass for plexus, then they are in the tck
- 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 24 May 2011 18:53, Brian Demers brian.dem...@gmail.com
20 matches
Mail list logo
