incubator-easyant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicolas Lalevée <nicolas.lale...@hibnet.org>
Subject Re: Clean up of some IP issues - Round 2
Date Sun, 04 Sep 2011 21:53:02 GMT

Le 23 août 2011 à 14:29, Nicolas Lalevée a écrit :

> 
> 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 it.
> 
>> - 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"/>
>        </jar>
> We would write:
>        <jar name="easyant-core-modules" jar="file:/tmp/myjar.jar">
>            <ivy pattern="/myrepo/[organisation]/[module]/[revision]/[module].ivy"/>
>        </jar>
> 
> WDYT ?
> Ok if you reimplement it that way ?
> And by the way, no objection if we write this resolver in Ivy instead of Easyant ?

I have implemented it in Ivy:
http://ant.apache.org/ivy/history/trunk/resolver/jar.html

So I guess we should try to use the Ivy one.

Nicolas

> 
>> 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.
> 
> ok.
> 
> Nicolas
> 


Mime
View raw message