incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <>
Subject Re: Clean up of some IP issues - Round 2
Date Tue, 23 Aug 2011 12:29:10 GMT

Le 8 août 2011 à 17:21, Stefan Bodewig a écrit :

> On 2011-08-06, Nicolas Lalevée wrote:
>> So we did a first clean up. And we did more review on the diff-to-device.txt
> A big thank you and sorry for not helping more or being more responsive.

I'm not that responsive either. And your help is as always greatly appreciated.

>> So here is the second round of the remaining stuff to clean up. Still 3 categories:
>> * to keep. Please mentors review the diff-to-keep-2.txt
> OK with me.
>> * and the remaining IP to clean up : diff-to-decide-2.txt
> Revs that look as if they should be removed to me:
> - 487 (this is not only performance, the change to RepositoryReport
>  adds support for a selectable resolver, or so it seems).

It seems the key point in the performance improvement is about not searching in every resolver,
so the selectable resolver. Am I right, do you confirm Jean-Louis ?
And since I suggest later to get rid of the RepositoryReport, we would be OK to just revert

> - 484 and 485 - I'm not exactly sure what the JarResolver does, but it
>  applies to the jar: protocol only.  It shouldn't be too hard to
>  rewrite that without looking at the current code if you can give a
>  proper description of its interface and expected behavior.

Now I have looked closer to the current implementation, something seems wrong to me. The jar
resolver seems to generically handle any jar url. So i can handle files in any jar. the pattern
used could potentially make the jar we are looking into change. Seems to much and I think
we can do simpler.
Probably the jar resolver could handle only one jar, and the ivy pattern would be only about
paths within the specified jar. So instead of specifying this:
        <jar name="easyant-core-modules">
            <ivy pattern="jar:file:/tmp/myjar.jar!/myrepo/[organisation]/[module]/[revision]/[module].ivy"/>
We would write:
        <jar name="easyant-core-modules" jar="file:/tmp/myjar.jar">
            <ivy pattern="/myrepo/[organisation]/[module]/[revision]/[module].ivy"/>

Ok if you reimplement it that way ?
And by the way, no objection if we write this resolver in Ivy instead of Easyant ?

>  I happen to know the ZIP and JAR specs pretty well, BTW ;-)

noted. Now every question I'll have about theses spec will be for you :)

>  But those same revisions also change quite a few things in the reporting
>  part (XslReport), I haven't completely figured out how much of this is
>  just a change in indentation and how mach changes functionality.
>  If it is only indentation then revert the change and run your Eclipse
>  (or whatever you use) formatter again.

humm, another thing I missed.
I would say that since it is not important for easyant to run, you should get rid of this
ant task. Objections ?

> - 428 revert and re-implement it from a spec of what it tests.

Any objection if I just remove it for now ?

> I'm totally willing to be more lenient with docs and CSS changes so
> would be OK with keeping the rest.



View raw message