On 12.8.2014 20:27, Jess Sightler wrote:
For the most part, we should be using absolute (canonicalized) paths
internally, as otherwise path comparisons can become difficult.
I don't think
so.
We basically only have these paths:
* User input (archives, source dirs, server dirs) - should be kept both
relative and absolute. [1]
* Any path under these - should be kept relative.
* Unzipped archives temp dirs - should be kept absolute.
* Any path under these - should be kept relative.
[1] - the user will put relative path to the archive, e.g. bin/windup.sh
../apps/MyApp.war
and may expect to see this path in the report, too.
Reasons to keep the paths relative:
1) Shorter, more effective to store.
2) Shorter, less space wasted.
3) No need to relativize paths across different archives.
4) Path comparisons of relative sub-paths are as difficult as doing that
with absolute paths.
5) The paths in archives are given by the archive, not by location of
our unzipped temp file. Showing relative path makes it less transparent.
Working with absolute and then cutting them by the temp dir doesn't give
any advantage.
my2c,
Ondra
You are
definitely right that we need to track things like archive
relationships, though (we already do this), as we need to be able to
figure out the relative paths later on.
Fortunately, we already do that. :)
On 08/12/2014 01:11 AM, Ondrej Zizka wrote:
> Yes, in the end, it's for presentation.
> But that means we need to use them internally too, otherwise they would
> get lost on the way.
>
> For example:
> We have archive foo.war.
> Extract it to $CWD/tmp/appsExtracted/foo.war/ (made up)
> It has a lib.jar, to be extracted to
> $CWD/tmp/appsExtracted/foo.war-lib.jar (made up).
> To keep the relative information, we need to carry the relative paths,
> and the context of what belongs under what.
> Otherwise we would have to re-compute the paths during reporting phase,
> which would be even harder to do right, IMO.
>
> Ondra
>
>
> On 11.8.2014 16:38, Jess Sightler wrote:
>> For presentation to the user, I agree. I assume that is what you are
>> talking about here?
>>
>> On 08/10/2014 11:00 PM, Ondrej Zizka wrote:
>>> Hi,
>>>
>>> I suggest we use relative paths.
>>> For the reports, using full paths may get overly verbose and make the
>>> reports unreadable.
>>> Relative paths are usually not, that much.
>>> Compare e.g.:
>>>
>>> INFO: Unzipping
>>>
/home/ondra/work/Migration/Windup/tests/core/target/../../../test-files/Windup1x-javaee-example.war
>>> to
>>>
/home/ondra/work/Migration/Windup/tests/core/target/windupreport/archives/Windup1x-javaee-example.war
>>>
>>> vs.
>>>
>>> INFO: Unzipping ../../../test-files/Windup1x-javaee-example.war to
>>> windupreport/archives/Windup1x-javaee-example.war
>>>
>>> The base path may be stated just once somewhere else.
>>>
>>> From my experience, using relative paths may get tricky, needing to
>>> carry the base path(s) along with the relative, but still, is worth the
>>> work.
>>>
>>> my2c,
>>> Ondra
>>>
>>> _______________________________________________
>>> windup-dev mailing list
>>> windup-dev(a)lists.jboss.org
>>>
https://lists.jboss.org/mailman/listinfo/windup-dev
>> _______________________________________________
>> windup-dev mailing list
>> windup-dev(a)lists.jboss.org
>>
https://lists.jboss.org/mailman/listinfo/windup-dev
> _______________________________________________
> windup-dev mailing list
> windup-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev