jar task with duplicate="preserve"

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

jar task with duplicate="preserve"

Dave Brosius-5
Hi folks,


I have an ant task using ant 1.10.8, that includes use of the <jar> task
as such:


         <jar destfile="${target.dir}/aspects.jar" *update="true"
**duplicate="preserve"*>
             <zipfileset src="${target.dir}/pre_aspects.jar"
includes="**/*" />
             <manifest>
                 <attribute name="Bundle-ManifestVersion" value="2" />
                 <attribute name="Bundle-Name"
value="${ant.project.name}" />
                 <attribute name="Bundle-SymbolicName"
value="${ant.project.name}" />
                 <attribute name="Bundle-Version"
value="${release.version}" />
                 <attribute name="Import-Package"
value="${bundle.importpackages}" />
                 <attribute name="Export-Package"
value="${bundle.exportpackages}" />
                 <attribute name="Revision" value="${revision}" />
                 <attribute name="Implementation-Version"
value="${acme.specification.version}" />
             </manifest>
         </jar>

There are in fact file collsions between the two jars.

When i run this from linux, with the -d parameter, ant outputs the
correct list of files it is copying, ie, those files that don't already
exist in the target jar.

When i run this from windows, with the -d parameter, ant outputs a much
longer list of files it is copying, including files that are being
overwritten.


So on linux it is working as expected, but windows does something different.

Is it possible that on windows, there is some problem with directory
separators, maybe / vs \ that is causing the jar task to think these are
new files. Or perhaps something else? Has anything like this been reported?

thanks,

dave

Reply | Threaded
Open this post in threaded view
|

Re: jar task with duplicate="preserve"

Stefan Bodewig
On 2020-09-15, Dave Brosius wrote:

> I have an ant task using ant 1.10.8, that includes use of the <jar>
> task as such:

>         <jar destfile="${target.dir}/aspects.jar" *update="true"
> **duplicate="preserve"*>
>             <zipfileset src="${target.dir}/pre_aspects.jar"
> includes="**/*" />
>             <manifest>
>                 ...
>             </manifest>
>         </jar>

> There are in fact file collsions between the two jars.

> When i run this from linux, with the -d parameter, ant outputs the
> correct list of files it is copying, ie, those files that don't
> already exist in the target jar.

> When i run this from windows, with the -d parameter, ant outputs a
> much longer list of files it is copying, including files that are
> being overwritten.

Are there any "\"s reported as part of the file names?

> Is it possible that on windows, there is some problem with directory
> separators, maybe / vs \ that is causing the jar task to think these
> are new files. Or perhaps something else? Has anything like this been
> reported?

None that I was aware of.

In your example bot aspects.jar and pre_aspects.jar are ZIPs and thus
should contain "/"s as separators anyway.

One more thing to look out for is timestamp granularity. On Linux Ant
assumes file timestamps are accurate up to the second on Windows it
assumes a granularity of two seconds. This may lead to files being
considered out-of-date on one but not the other. At the same time, ZIPs
only support a granularity of two seconds themselves. The roundup
attribute may make a difference if things are time and not file name
related.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: jar task with duplicate="preserve"

Dave Brosius-5

On 9/21/20 4:32 AM, Stefan Bodewig wrote:

> On 2020-09-15, Dave Brosius wrote:
>
>> I have an ant task using ant 1.10.8, that includes use of the <jar>
>> task as such:
>>          <jar destfile="${target.dir}/aspects.jar" *update="true"
>> **duplicate="preserve"*>
>>              <zipfileset src="${target.dir}/pre_aspects.jar"
>> includes="**/*" />
>>              <manifest>
>>                  ...
>>              </manifest>
>>          </jar>
>> There are in fact file collsions between the two jars.
>> When i run this from linux, with the -d parameter, ant outputs the
>> correct list of files it is copying, ie, those files that don't
>> already exist in the target jar.
>> When i run this from windows, with the -d parameter, ant outputs a
>> much longer list of files it is copying, including files that are
>> being overwritten.
> Are there any "\"s reported as part of the file names?
>
I didn't see anything like that

>> Is it possible that on windows, there is some problem with directory
>> separators, maybe / vs \ that is causing the jar task to think these
>> are new files. Or perhaps something else? Has anything like this been
>> reported?
> None that I was aware of.
>
> In your example bot aspects.jar and pre_aspects.jar are ZIPs and thus
> should contain "/"s as separators anyway.
>
> One more thing to look out for is timestamp granularity. On Linux Ant
> assumes file timestamps are accurate up to the second on Windows it
> assumes a granularity of two seconds. This may lead to files being
> considered out-of-date on one but not the other. At the same time, ZIPs
> only support a granularity of two seconds themselves. The roundup
> attribute may make a difference if things are time and not file name
> related.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

In the end i just wrote my own custom ant task to do what jar was
supposed to do. What i noticed was that one of the jars had

     1) no entries for the directories themselves

     2) items out of alphabetical order.

Don't know if that confused the ant jar task or not, not sure why it
would be different between windows and linux tho.


-dave



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: jar task with duplicate="preserve"

Stefan Bodewig
Hi Dave

On 2020-09-21, Dave Brosius wrote:

> In the end i just wrote my own custom ant task to do what jar was
> supposed to do. What i noticed was that one of the jars had

>     1) no entries for the directories themselves

>     2) items out of alphabetical order.

> Don't know if that confused the ant jar task or not, not sure why it
> would be different between windows and linux tho.

Is there any chance you can distill some sort of example project out of
this that exhibits what you have observed?

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: jar task with duplicate="preserve"

Dave Brosius-5
The "abnormal" jar was created with the iajc ant task (aspectj)

I'll see if i can get something together.

On 9/22/20 2:10 AM, Stefan Bodewig wrote:

> Hi Dave
>
> On 2020-09-21, Dave Brosius wrote:
>
>> In the end i just wrote my own custom ant task to do what jar was
>> supposed to do. What i noticed was that one of the jars had
>>      1) no entries for the directories themselves
>>      2) items out of alphabetical order.
>> Don't know if that confused the ant jar task or not, not sure why it
>> would be different between windows and linux tho.
> Is there any chance you can distill some sort of example project out of
> this that exhibits what you have observed?
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]