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
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 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
>> 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 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
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
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 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
> 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 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
>>> 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: 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
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 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
>> 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: 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 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
> 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: 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
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
Re: Anyone want to help?
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" wrote: > 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 signatures. (it would help with > the coverage anyway) > > > On Tue, May 24, 2011 at 12:25 PM, Kristian Rosenvold < > kristian.rosenv...@gmail.com> wrote: > >> >> > 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 sense for the stuff mentioned in >> http://jira.codehaus.org/browse/PLXUTILS-21 other than that I think it >> makes sense to rework the dependencies or keep them as-is. Plexus-utils >> is a bit of a flea market functionality wise and some of it may be >> totally unused for all I know. >> >> But if the intention of the shim is to ensure/validate compatibility it >> will often just delegate directly to another method. So if I was >> upgrading to the shim I'd almost certainly inline the method invocations >> so I'd just be left with clean dependencies on the real implementations. >> So in this respect I could just use the shim as a transitional measure. >> >> >> Kristian >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >>
Re: Anyone want to help?
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 signatures. (it would help with the coverage anyway) On Tue, May 24, 2011 at 12:25 PM, Kristian Rosenvold < kristian.rosenv...@gmail.com> wrote: > > > 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 sense for the stuff mentioned in > http://jira.codehaus.org/browse/PLXUTILS-21 other than that I think it > makes sense to rework the dependencies or keep them as-is. Plexus-utils > is a bit of a flea market functionality wise and some of it may be > totally unused for all I know. > > But if the intention of the shim is to ensure/validate compatibility it > will often just delegate directly to another method. So if I was > upgrading to the shim I'd almost certainly inline the method invocations > so I'd just be left with clean dependencies on the real implementations. > So in this respect I could just use the shim as a transitional measure. > > > Kristian > > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Anyone want to help?
> 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 sense for the stuff mentioned in http://jira.codehaus.org/browse/PLXUTILS-21 other than that I think it makes sense to rework the dependencies or keep them as-is. Plexus-utils is a bit of a flea market functionality wise and some of it may be totally unused for all I know. But if the intention of the shim is to ensure/validate compatibility it will often just delegate directly to another method. So if I was upgrading to the shim I'd almost certainly inline the method invocations so I'd just be left with clean dependencies on the real implementations. So in this respect I could just use the shim as a transitional measure. Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Anyone want to help?
On 24 May 2011 16:05, Kristian Rosenvold 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 without looking at the >> plexus-utils code so that the tests are somewhat clean-room, but there >> is no hard requirement in this case... the desire is more to ensure >> that they are good tests) >> >> That will give us a good test coverage of plexus-utils... >> > > Quite a lot of plexus-utils code has decent test coverage, so you may > consider using that as a starting point - all depending on how much > wheel you prefer reinventing ;) > 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. > Kristian > > > - > 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?
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 clean-room, but there > is no hard requirement in this case... the desire is more to ensure > that they are good tests) > > That will give us a good test coverage of plexus-utils... > Quite a lot of plexus-utils code has decent test coverage, so you may consider using that as a starting point - all depending on how much wheel you prefer reinventing ;) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Anyone want to help?
Oups, moved to https://cwiki.apache.org/confluence/display/MAVEN/Plexus-utils+replacement 2011/5/24 Olivier Lamy > 2011/5/24 nicolas de loof : > >> > >> +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 > http://twitter.com/olamy | http://www.linkedin.com/in/olamy > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Anyone want to help?
2011/5/24 nicolas de loof : >> >> +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 http://twitter.com/olamy | http://www.linkedin.com/in/olamy - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Anyone want to help?
> > +1 and Nike it: Just do it(tm) > http://docs.codehaus.org/display/MAVENUSER/Plexus-utils+replacement
Re: Anyone want to help?
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 clean-room, but there
is no hard requirement in this case... the desire is more to ensure
that they are good tests)
That will give us a good test coverage of plexus-utils...
Then we implement a new plexus-utils that passes all the tests but has
a completely different implementation (one which just calls through to
the commons-* code that does similar/same)
When all the tests pass on our new implementation, we have a drop in
replacement for plexus-utils.
We can then work on replacing plexus-utils with the commons-* code
directly (IntelliJ IDEA can really help here if you just take a copy
of the shim and request to inline each of the statics and remove
intermediates from your delegation chains... when done you remove the
now defunct copy of the shim)
So the real aim is to get the replacement for all the legacy code (and
in so doing we work out how to replace it) and then once we are there
we can rip out plexus-utils from the trunk and leave the shim for any
old versions of plugins.
-Stephen
On 24 May 2011 12:15, Mark Struberg wrote:
> 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 wrote:
>
>> From: Martin Gainty
>> 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
>> __
>> 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.
>>
>>
>>
>>
>> > Date: Tue, 24 May 2011 10:28:13 +0100
>> > Subject: 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 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: Anyone want to help?
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 wrote:
> From: Martin Gainty
> 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
> __
> 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.
>
>
>
>
> > Date: Tue, 24 May 2011 10:28:13 +0100
> > Subject: 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 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
Re: Anyone want to help?
On 24 May 2011 11:45, nicolas de loof 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 svn repo to github / apache extras so that non-apache
> contributors can help (I'm an optimistic naive guy :P)
+0 need to ensure this is all under ASL, so need signed CLAs on file
(I'm not -1 as technically the test cases do not have to have the CLA,
but to get those test cases into the apache svn server they would have
to)
>
> Cheers,
> Nicolas
>
> 2011/5/24 Stephen Connolly
>
>> 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
Re: Anyone want to help?
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)
Cheers,
Nicolas
2011/5/24 Stephen Connolly
> 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
>
>
RE: Anyone want to help?
isnt the job of the software engineer to write test-cases to prove their
software works?
Martin
__
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.
> Date: Tue, 24 May 2011 10:28:13 +0100
> Subject: 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 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
>
Re: Anyone want to help?
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 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
