You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@ant.apache.org by Sean Landis <Se...@Motorola.com> on 2003/01/03 16:48:02 UTC

Different behavior 1.4.1 - 1.5.1

We noticed an important difference in behavior between 1.4.1  and 1.5.1
regarding the jar built-in. The difference is demonstrated in the
following
build file fragment:

  <jar jarfile="${service-dl.jars}/controller-surrogate.jar"
         basedir="${build}"  includesfile="tmp"/>
  <jar jarfile="${service-dl.jars}/controller-surrogate.jar"
        manifest="${manifests}/controller-surrogate.mf"
         update="true"
         basedir="${service-dl.jars}"
         includes="service-surrogate.jar"/>

In 1.4.1, the first jar command would create the jar and the second
would
update the jar file. In 1.5.1, the first would create, but the second
would
be skipped. With -debug, a message is printed that states the second
command was skipped because the jar file was up to date.

This seems to be a bug in 1.5.1 since the 'update="true"' ought to
force update regardless of the state of the jar file.

Is this a bug to be fixed?

If not, is there a correct way to do what we want?

If so, is there a work-around technique to get what we want?

Thanks,
Sean


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Different behavior 1.4.1 - 1.5.1 (adding files to existing jar files)

Posted by Sean Landis <Se...@Motorola.com>.
Thanks.
Sean

Antoine Levy-Lambert wrote:

> Dear Sean,
> there is awareness about this issue,
> see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10755
> in this web page Peter Hale suggested a workaround of touching the jar file,
> setting its date in the past.
> You should try this.
> I have tried to suggest fixes of the code actually this morning, but you
> should probably try to use the workaround first, and wait until the bug is
> officially fixed by one of the ant commiters.
>
> Antoine
>
> >>I was able to workaround the problem by adding a <touch> task between the
> <jar>
> >>and <zip> tasks using a date that I know is in the past.
>
>     <target name="jar" depends="compile" description="Create client jar
> file">
>         <jar destfile="${jar.file.name}.jar" includes="**"
> basedir="${dest.dir}" manifest="ant/dashclient-nosign.mf" update="true" />
>         <touch file="${jar.file.name}.jar" datetime="06/28/2000 2:02 pm"/>
>         <zip destfile="${jar.file.name}.jar" update="true" >
>             <zipfileset src="shared/Cnnxn/CnnxnUtils.jar" excludes="META-
> INF/MANIFEST.MF" />
>         </zip>
>     </target>
>
> >> Peter Hale phale@cnnxn.com
>
> ----- Original Message -----
> From: "Sean Landis" <Se...@Motorola.com>
> To: "Ant User List (E-mail)" <an...@jakarta.apache.org>;
> <Se...@Motorola.com>
> Sent: Friday, January 03, 2003 4:48 PM
> Subject: Different behavior 1.4.1 - 1.5.1
>
> > We noticed an important difference in behavior between 1.4.1  and 1.5.1
> > regarding the jar built-in. The difference is demonstrated in the
> > following
> > build file fragment:
> >
> >   <jar jarfile="${service-dl.jars}/controller-surrogate.jar"
> >          basedir="${build}"  includesfile="tmp"/>
> >   <jar jarfile="${service-dl.jars}/controller-surrogate.jar"
> >         manifest="${manifests}/controller-surrogate.mf"
> >          update="true"
> >          basedir="${service-dl.jars}"
> >          includes="service-surrogate.jar"/>
> >
> > In 1.4.1, the first jar command would create the jar and the second
> > would
> > update the jar file. In 1.5.1, the first would create, but the second
> > would
> > be skipped. With -debug, a message is printed that states the second
> > command was skipped because the jar file was up to date.
> >
> > This seems to be a bug in 1.5.1 since the 'update="true"' ought to
> > force update regardless of the state of the jar file.
> >
> > Is this a bug to be fixed?
> >
> > If not, is there a correct way to do what we want?
> >
> > If so, is there a work-around technique to get what we want?
> >
> > Thanks,
> > Sean
> >
> >
> > --
> > To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> > For additional commands, e-mail: <ma...@jakarta.apache.org>
> >
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


ejbjar dependency=full

Posted by Karen Schaper <Ka...@danzas.com>.
I am using ant 1.5.1

I am using ejbjar.  How does the dependency = full attribute work?  I can't
seem to get it to include class files needed that are located in jars on the
classpath.  We don't use ear files so I need to include these in the jar.

Thanks for your help.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: ejbjar and including another jar

Posted by Karen Schaper <Ka...@danzas.com>.
...Were not using ear files...

-----Original Message-----
From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
Sent: Wednesday, January 08, 2003 3:28 AM
To: Ant Users List
Subject: Re: ejbjar and including another jar


Karen Schaper wrote:
> Hi,
>
> I am using ant 1.5.1. Using the ejbjar task, I can set the dependency to
> full and the jar includes most files.  But it is not including files that
I
> need from netcomponents.jar.

Can't you just bundle that jar with the EJBs into an ear.

Conor


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: ejbjar and including another jar

Posted by Karen Schaper <Ka...@danzas.com>.

-----Original Message-----
From: Conor MacNeill [mailto:conor@cortexebusiness.com.au]
Sent: Wednesday, January 08, 2003 3:28 AM
To: Ant Users List
Subject: Re: ejbjar and including another jar


Karen Schaper wrote:
> Hi,
>
> I am using ant 1.5.1. Using the ejbjar task, I can set the dependency to
> full and the jar includes most files.  But it is not including files that
I
> need from netcomponents.jar.

Can't you just bundle that jar with the EJBs into an ear.

Conor


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: ejbjar and including another jar

Posted by Conor MacNeill <co...@cortexebusiness.com.au>.
Karen Schaper wrote:
> Hi,
> 
> I am using ant 1.5.1. Using the ejbjar task, I can set the dependency to
> full and the jar includes most files.  But it is not including files that I
> need from netcomponents.jar.  

Can't you just bundle that jar with the EJBs into an ear.

Conor


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


ejbjar and including another jar

Posted by Karen Schaper <Ka...@danzas.com>.
Hi,

I am using ant 1.5.1. Using the ejbjar task, I can set the dependency to
full and the jar includes most files.  But it is not including files that I
need from netcomponents.jar.  If files from a jar need to be included is
there something different you have to do?  I usually update the jar using a
zipfileset task but want to avoid update existing jars until the bug is
fixed.  Can a jar file be included in the support tag? I couldn't get that
to work either.

Thanks in advance for your help.

Karen



-----Original Message-----
From: Antoine Levy-Lambert [mailto:levylambert@tiscali-dsl.de]
Sent: Saturday, January 04, 2003 9:17 AM
To: Ant Users List
Subject: Re: Different behavior 1.4.1 - 1.5.1 (adding files to existing
jar files)


Dear Sean,
there is awareness about this issue,
see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10755
in this web page Peter Hale suggested a workaround of touching the jar file,
setting its date in the past.
You should try this.
I have tried to suggest fixes of the code actually this morning, but you
should probably try to use the workaround first, and wait until the bug is
officially fixed by one of the ant commiters.

Antoine


>>I was able to workaround the problem by adding a <touch> task between the
<jar>
>>and <zip> tasks using a date that I know is in the past.

    <target name="jar" depends="compile" description="Create client jar
file">
        <jar destfile="${jar.file.name}.jar" includes="**"
basedir="${dest.dir}" manifest="ant/dashclient-nosign.mf" update="true" />
        <touch file="${jar.file.name}.jar" datetime="06/28/2000 2:02 pm"/>
        <zip destfile="${jar.file.name}.jar" update="true" >
            <zipfileset src="shared/Cnnxn/CnnxnUtils.jar" excludes="META-
INF/MANIFEST.MF" />
        </zip>
    </target>

>> Peter Hale phale@cnnxn.com


----- Original Message -----
From: "Sean Landis" <Se...@Motorola.com>
To: "Ant User List (E-mail)" <an...@jakarta.apache.org>;
<Se...@Motorola.com>
Sent: Friday, January 03, 2003 4:48 PM
Subject: Different behavior 1.4.1 - 1.5.1


> We noticed an important difference in behavior between 1.4.1  and 1.5.1
> regarding the jar built-in. The difference is demonstrated in the
> following
> build file fragment:
>
>   <jar jarfile="${service-dl.jars}/controller-surrogate.jar"
>          basedir="${build}"  includesfile="tmp"/>
>   <jar jarfile="${service-dl.jars}/controller-surrogate.jar"
>         manifest="${manifests}/controller-surrogate.mf"
>          update="true"
>          basedir="${service-dl.jars}"
>          includes="service-surrogate.jar"/>
>
> In 1.4.1, the first jar command would create the jar and the second
> would
> update the jar file. In 1.5.1, the first would create, but the second
> would
> be skipped. With -debug, a message is printed that states the second
> command was skipped because the jar file was up to date.
>
> This seems to be a bug in 1.5.1 since the 'update="true"' ought to
> force update regardless of the state of the jar file.
>
> Is this a bug to be fixed?
>
> If not, is there a correct way to do what we want?
>
> If so, is there a work-around technique to get what we want?
>
> Thanks,
> Sean
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: Different behavior 1.4.1 - 1.5.1 (adding files to existing jar files)

Posted by Antoine Levy-Lambert <le...@tiscali-dsl.de>.
Dear Sean,
there is awareness about this issue,
see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=10755
in this web page Peter Hale suggested a workaround of touching the jar file,
setting its date in the past.
You should try this.
I have tried to suggest fixes of the code actually this morning, but you
should probably try to use the workaround first, and wait until the bug is
officially fixed by one of the ant commiters.

Antoine


>>I was able to workaround the problem by adding a <touch> task between the
<jar>
>>and <zip> tasks using a date that I know is in the past.

    <target name="jar" depends="compile" description="Create client jar
file">
        <jar destfile="${jar.file.name}.jar" includes="**"
basedir="${dest.dir}" manifest="ant/dashclient-nosign.mf" update="true" />
        <touch file="${jar.file.name}.jar" datetime="06/28/2000 2:02 pm"/>
        <zip destfile="${jar.file.name}.jar" update="true" >
            <zipfileset src="shared/Cnnxn/CnnxnUtils.jar" excludes="META-
INF/MANIFEST.MF" />
        </zip>
    </target>

>> Peter Hale phale@cnnxn.com


----- Original Message -----
From: "Sean Landis" <Se...@Motorola.com>
To: "Ant User List (E-mail)" <an...@jakarta.apache.org>;
<Se...@Motorola.com>
Sent: Friday, January 03, 2003 4:48 PM
Subject: Different behavior 1.4.1 - 1.5.1


> We noticed an important difference in behavior between 1.4.1  and 1.5.1
> regarding the jar built-in. The difference is demonstrated in the
> following
> build file fragment:
>
>   <jar jarfile="${service-dl.jars}/controller-surrogate.jar"
>          basedir="${build}"  includesfile="tmp"/>
>   <jar jarfile="${service-dl.jars}/controller-surrogate.jar"
>         manifest="${manifests}/controller-surrogate.mf"
>          update="true"
>          basedir="${service-dl.jars}"
>          includes="service-surrogate.jar"/>
>
> In 1.4.1, the first jar command would create the jar and the second
> would
> update the jar file. In 1.5.1, the first would create, but the second
> would
> be skipped. With -debug, a message is printed that states the second
> command was skipped because the jar file was up to date.
>
> This seems to be a bug in 1.5.1 since the 'update="true"' ought to
> force update regardless of the state of the jar file.
>
> Is this a bug to be fixed?
>
> If not, is there a correct way to do what we want?
>
> If so, is there a work-around technique to get what we want?
>
> Thanks,
> Sean
>
>
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>