Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Plugin Development Environment (PDE) » PDE Build (Ant) Mucking With Bundle MANIFEST.MF
PDE Build (Ant) Mucking With Bundle MANIFEST.MF [message #39314] Wed, 07 January 2009 21:35 Go to next message
Mark Melvin is currently offline Mark MelvinFriend
Messages: 118
Registered: July 2009
Senior Member
Hi,

I am integrating my plugin builds into a continuous integration type
system. I've noticed that the difference between the bundle JARs produced
with my new build system and those produced by my old, monolithic PDE
build is that the new JARs have had their bundle manifests molested at
some point by Ant. They now contain the following lines:

Ant-Version: Apache Ant 1.7.0
Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)

First off, I'd like to know why this is happening now and it never has
before. The generated build.xml files that PDE build is using look the
same (the call to the Ant <jar ..> task is identical). Does anyone know
what prevents this from happening in a normal PDE build, or what may
trigger it to happen in general?
Second, are these lines going to screw up my bundle? I don't think they
are, but I would like to prevent them from appearing anyway.

Thanks in advance,
Mark.
Re: PDE Build (Ant) Mucking With Bundle MANIFEST.MF [message #39593 is a reply to message #39314] Thu, 08 January 2009 21:36 Go to previous messageGo to next message
Mark Melvin is currently offline Mark MelvinFriend
Messages: 118
Registered: July 2009
Senior Member
<sigh>

Well it took me almost two days of wading through PDE build scripts and
logs but I found the root cause of this issue. If you try to execute
targets directly from the generated build.xml file (which I must do for
continuous integration purposes), you get different results than the full
PDE build would produce. This is because the full, feature-based PDE
build uses *other* generated assembly files that happen to do things
slightly different. For example, the "build.update.jar" target in a
generated build.xml for a given bundle looks like this:

<target name="build.update.jar" depends="init" description="Build the
plug-in: my.plugin.id for an update site.">
<delete dir="${temp.folder}"/>
<mkdir dir="${temp.folder}"/>
<antcall target="build.jars"/>
<antcall target="gather.bin.parts">
<param name="destination.temp.folder" value="${temp.folder}/"/>
</antcall>
<jar destfile="${plugin.destination}/my.plugin.id_1.0.0.HEAD.jar "
basedir="${temp.folder}/my.plugin.id_1.0.0.HEAD" filesetmanifest="merge"/>
<delete dir="${temp.folder}"/>
</target>

However, if you look at the mess of generated assembly scripts in the
top-level PDE build directory and examine the one that *actually* builds
the plugin's update JAR in a full-fledged PDE build scenario, you will
find the following targets:

<target name="jarUp" description="Create a jar from the given location.">
<available property="${source}/${elementName}_exists"
file="${source}/${elementName}"/>
<available property="jaringManifest"
file="${source}/${elementName}/META-INF/MANIFEST.MF"/>
<condition property="jaringTask" value="jarIng"
else="jarIng_NoManifest" >
<isset property="jaringManifest"/>
</condition>
<antcall target="${jaringTask}">
<param name="source" value="${source}"/>
<param name="elementName" value="${elementName}"/>
</antcall>
</target>

<target name="jarIng" if="${source}/${elementName}_exists">
<jar destfile="${source}/${elementName}.jar"
basedir="${source}/${elementName}"
manifest="${source}/${elementName}/META-INF/MANIFEST.MF"
filesetmanifest="skip"/>
<delete dir="${source}/${elementName}"/>
</target>
<target name="jarIng_NoManifest" if="${source}/${elementName}_exists">
<jar destfile="${source}/${elementName}.jar"
basedir="${source}/${elementName}" filesetmanifest="merge"/>
<delete dir="${source}/${elementName}"/>
</target>


The "main" target in the assembly script only uses the "gather.bin.parts"
target from the the bundle's generated build.xml, and then proceeds to
call this specially-generated "jarUp" target, which contains a special
case for a bundle that contains a manifest file, calling the Ant <jar ..>
task in a different way. Interesting. Looks like I am off to Bugzilla.
The generated build.xml should contain similar logic in my opinion. There
are lots of cases where people will want to use the targets in a generated
build.xml directly, and there isn't a easy way around this problem for my
particular situation that I can see.

So back to my original question then: Do the extra, crufty lines that Ant
sticks into my MANIFEST.MF files screw up anything related to OSGi bundles?

Mark.


On Wed, 07 Jan 2009 16:35:16 -0500, Mark Melvin <mark.melvin@onsemi.com>
wrote:

> Hi,
>
> I am integrating my plugin builds into a continuous integration type
> system. I've noticed that the difference between the bundle JARs
> produced with my new build system and those produced by my old,
> monolithic PDE build is that the new JARs have had their bundle
> manifests molested at some point by Ant. They now contain the following
> lines:
>
> Ant-Version: Apache Ant 1.7.0
> Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
>
> First off, I'd like to know why this is happening now and it never has
> before. The generated build.xml files that PDE build is using look the
> same (the call to the Ant <jar ..> task is identical). Does anyone know
> what prevents this from happening in a normal PDE build, or what may
> trigger it to happen in general?
> Second, are these lines going to screw up my bundle? I don't think they
> are, but I would like to prevent them from appearing anyway.
>
> Thanks in advance,
> Mark.
Re: PDE Build (Ant) Mucking With Bundle MANIFEST.MF [message #39684 is a reply to message #39593] Fri, 09 January 2009 14:49 Go to previous messageGo to next message
Eclipse UserFriend
Originally posted by: eclipse-news.rizzoweb.com

If you file any bug reports, please post them links here so we can
follow them.


On 1/8/2009 4:36 PM, Mark Melvin wrote:
> <sigh>
>
> Well it took me almost two days of wading through PDE build scripts and
> logs but I found the root cause of this issue. If you try to execute
> targets directly from the generated build.xml file (which I must do for
> continuous integration purposes), you get different results than the
> full PDE build would produce. This is because the full, feature-based
> PDE build uses *other* generated assembly files that happen to do things
> slightly different. For example, the "build.update.jar" target in a
> generated build.xml for a given bundle looks like this:
>
> <target name="build.update.jar" depends="init" description="Build the
> plug-in: my.plugin.id for an update site.">
> <delete dir="${temp.folder}"/>
> <mkdir dir="${temp.folder}"/>
> <antcall target="build.jars"/>
> <antcall target="gather.bin.parts">
> <param name="destination.temp.folder" value="${temp.folder}/"/>
> </antcall>
> <jar destfile="${plugin.destination}/my.plugin.id_1.0.0.HEAD.jar "
> basedir="${temp.folder}/my.plugin.id_1.0.0.HEAD" filesetmanifest="merge"/>
> <delete dir="${temp.folder}"/>
> </target>
>
> However, if you look at the mess of generated assembly scripts in the
> top-level PDE build directory and examine the one that *actually* builds
> the plugin's update JAR in a full-fledged PDE build scenario, you will
> find the following targets:
>
> <target name="jarUp" description="Create a jar from the given location.">
> <available property="${source}/${elementName}_exists"
> file="${source}/${elementName}"/>
> <available property="jaringManifest"
> file="${source}/${elementName}/META-INF/MANIFEST.MF"/>
> <condition property="jaringTask" value="jarIng" else="jarIng_NoManifest" >
> <isset property="jaringManifest"/>
> </condition>
> <antcall target="${jaringTask}">
> <param name="source" value="${source}"/>
> <param name="elementName" value="${elementName}"/>
> </antcall>
> </target>
>
> <target name="jarIng" if="${source}/${elementName}_exists">
> <jar destfile="${source}/${elementName}.jar"
> basedir="${source}/${elementName}"
> manifest="${source}/${elementName}/META-INF/MANIFEST.MF"
> filesetmanifest="skip"/>
> <delete dir="${source}/${elementName}"/>
> </target>
> <target name="jarIng_NoManifest" if="${source}/${elementName}_exists">
> <jar destfile="${source}/${elementName}.jar"
> basedir="${source}/${elementName}" filesetmanifest="merge"/>
> <delete dir="${source}/${elementName}"/>
> </target>
>
>
> The "main" target in the assembly script only uses the
> "gather.bin.parts" target from the the bundle's generated build.xml, and
> then proceeds to call this specially-generated "jarUp" target, which
> contains a special case for a bundle that contains a manifest file,
> calling the Ant <jar ..> task in a different way. Interesting. Looks
> like I am off to Bugzilla. The generated build.xml should contain
> similar logic in my opinion. There are lots of cases where people will
> want to use the targets in a generated build.xml directly, and there
> isn't a easy way around this problem for my particular situation that I
> can see.
>
> So back to my original question then: Do the extra, crufty lines that
> Ant sticks into my MANIFEST.MF files screw up anything related to OSGi
> bundles?
>
> Mark.
>
>
> On Wed, 07 Jan 2009 16:35:16 -0500, Mark Melvin <mark.melvin@onsemi.com>
> wrote:
>
>> Hi,
>>
>> I am integrating my plugin builds into a continuous integration type
>> system. I've noticed that the difference between the bundle JARs
>> produced with my new build system and those produced by my old,
>> monolithic PDE build is that the new JARs have had their bundle
>> manifests molested at some point by Ant. They now contain the
>> following lines:
>>
>> Ant-Version: Apache Ant 1.7.0
>> Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
>>
>> First off, I'd like to know why this is happening now and it never has
>> before. The generated build.xml files that PDE build is using look the
>> same (the call to the Ant <jar ..> task is identical). Does anyone
>> know what prevents this from happening in a normal PDE build, or what
>> may trigger it to happen in general?
>> Second, are these lines going to screw up my bundle? I don't think
>> they are, but I would like to prevent them from appearing anyway.
>>
>> Thanks in advance,
>> Mark.
>
Re: PDE Build (Ant) Mucking With Bundle MANIFEST.MF [message #39715 is a reply to message #39684] Fri, 09 January 2009 15:07 Go to previous message
Eclipse UserFriend
Originally posted by: mark_melvin.amis.com

Eric Rizzo wrote:

> If you file any bug reports, please post them links here so we can
> follow them.

Just finished.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=260550

Mark.
Re: PDE Build (Ant) Mucking With Bundle MANIFEST.MF [message #587953 is a reply to message #39314] Thu, 08 January 2009 21:36 Go to previous message
Mark Melvin is currently offline Mark MelvinFriend
Messages: 118
Registered: July 2009
Senior Member
<sigh>

Well it took me almost two days of wading through PDE build scripts and
logs but I found the root cause of this issue. If you try to execute
targets directly from the generated build.xml file (which I must do for
continuous integration purposes), you get different results than the full
PDE build would produce. This is because the full, feature-based PDE
build uses *other* generated assembly files that happen to do things
slightly different. For example, the "build.update.jar" target in a
generated build.xml for a given bundle looks like this:

<target name="build.update.jar" depends="init" description="Build the
plug-in: my.plugin.id for an update site.">
<delete dir="${temp.folder}"/>
<mkdir dir="${temp.folder}"/>
<antcall target="build.jars"/>
<antcall target="gather.bin.parts">
<param name="destination.temp.folder" value="${temp.folder}/"/>
</antcall>
<jar destfile="${plugin.destination}/my.plugin.id_1.0.0.HEAD.jar "
basedir="${temp.folder}/my.plugin.id_1.0.0.HEAD" filesetmanifest="merge"/>
<delete dir="${temp.folder}"/>
</target>

However, if you look at the mess of generated assembly scripts in the
top-level PDE build directory and examine the one that *actually* builds
the plugin's update JAR in a full-fledged PDE build scenario, you will
find the following targets:

<target name="jarUp" description="Create a jar from the given location.">
<available property="${source}/${elementName}_exists"
file="${source}/${elementName}"/>
<available property="jaringManifest"
file="${source}/${elementName}/META-INF/MANIFEST.MF"/>
<condition property="jaringTask" value="jarIng"
else="jarIng_NoManifest" >
<isset property="jaringManifest"/>
</condition>
<antcall target="${jaringTask}">
<param name="source" value="${source}"/>
<param name="elementName" value="${elementName}"/>
</antcall>
</target>

<target name="jarIng" if="${source}/${elementName}_exists">
<jar destfile="${source}/${elementName}.jar"
basedir="${source}/${elementName}"
manifest="${source}/${elementName}/META-INF/MANIFEST.MF"
filesetmanifest="skip"/>
<delete dir="${source}/${elementName}"/>
</target>
<target name="jarIng_NoManifest" if="${source}/${elementName}_exists">
<jar destfile="${source}/${elementName}.jar"
basedir="${source}/${elementName}" filesetmanifest="merge"/>
<delete dir="${source}/${elementName}"/>
</target>


The "main" target in the assembly script only uses the "gather.bin.parts"
target from the the bundle's generated build.xml, and then proceeds to
call this specially-generated "jarUp" target, which contains a special
case for a bundle that contains a manifest file, calling the Ant <jar ..>
task in a different way. Interesting. Looks like I am off to Bugzilla.
The generated build.xml should contain similar logic in my opinion. There
are lots of cases where people will want to use the targets in a generated
build.xml directly, and there isn't a easy way around this problem for my
particular situation that I can see.

So back to my original question then: Do the extra, crufty lines that Ant
sticks into my MANIFEST.MF files screw up anything related to OSGi bundles?

Mark.


On Wed, 07 Jan 2009 16:35:16 -0500, Mark Melvin <mark.melvin@onsemi.com>
wrote:

> Hi,
>
> I am integrating my plugin builds into a continuous integration type
> system. I've noticed that the difference between the bundle JARs
> produced with my new build system and those produced by my old,
> monolithic PDE build is that the new JARs have had their bundle
> manifests molested at some point by Ant. They now contain the following
> lines:
>
> Ant-Version: Apache Ant 1.7.0
> Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
>
> First off, I'd like to know why this is happening now and it never has
> before. The generated build.xml files that PDE build is using look the
> same (the call to the Ant <jar ..> task is identical). Does anyone know
> what prevents this from happening in a normal PDE build, or what may
> trigger it to happen in general?
> Second, are these lines going to screw up my bundle? I don't think they
> are, but I would like to prevent them from appearing anyway.
>
> Thanks in advance,
> Mark.
Re: PDE Build (Ant) Mucking With Bundle MANIFEST.MF [message #587986 is a reply to message #39593] Fri, 09 January 2009 14:49 Go to previous message
Eric Rizzo is currently offline Eric RizzoFriend
Messages: 3071
Registered: July 2009
Senior Member
If you file any bug reports, please post them links here so we can
follow them.


On 1/8/2009 4:36 PM, Mark Melvin wrote:
> <sigh>
>
> Well it took me almost two days of wading through PDE build scripts and
> logs but I found the root cause of this issue. If you try to execute
> targets directly from the generated build.xml file (which I must do for
> continuous integration purposes), you get different results than the
> full PDE build would produce. This is because the full, feature-based
> PDE build uses *other* generated assembly files that happen to do things
> slightly different. For example, the "build.update.jar" target in a
> generated build.xml for a given bundle looks like this:
>
> <target name="build.update.jar" depends="init" description="Build the
> plug-in: my.plugin.id for an update site.">
> <delete dir="${temp.folder}"/>
> <mkdir dir="${temp.folder}"/>
> <antcall target="build.jars"/>
> <antcall target="gather.bin.parts">
> <param name="destination.temp.folder" value="${temp.folder}/"/>
> </antcall>
> <jar destfile="${plugin.destination}/my.plugin.id_1.0.0.HEAD.jar "
> basedir="${temp.folder}/my.plugin.id_1.0.0.HEAD" filesetmanifest="merge"/>
> <delete dir="${temp.folder}"/>
> </target>
>
> However, if you look at the mess of generated assembly scripts in the
> top-level PDE build directory and examine the one that *actually* builds
> the plugin's update JAR in a full-fledged PDE build scenario, you will
> find the following targets:
>
> <target name="jarUp" description="Create a jar from the given location.">
> <available property="${source}/${elementName}_exists"
> file="${source}/${elementName}"/>
> <available property="jaringManifest"
> file="${source}/${elementName}/META-INF/MANIFEST.MF"/>
> <condition property="jaringTask" value="jarIng" else="jarIng_NoManifest" >
> <isset property="jaringManifest"/>
> </condition>
> <antcall target="${jaringTask}">
> <param name="source" value="${source}"/>
> <param name="elementName" value="${elementName}"/>
> </antcall>
> </target>
>
> <target name="jarIng" if="${source}/${elementName}_exists">
> <jar destfile="${source}/${elementName}.jar"
> basedir="${source}/${elementName}"
> manifest="${source}/${elementName}/META-INF/MANIFEST.MF"
> filesetmanifest="skip"/>
> <delete dir="${source}/${elementName}"/>
> </target>
> <target name="jarIng_NoManifest" if="${source}/${elementName}_exists">
> <jar destfile="${source}/${elementName}.jar"
> basedir="${source}/${elementName}" filesetmanifest="merge"/>
> <delete dir="${source}/${elementName}"/>
> </target>
>
>
> The "main" target in the assembly script only uses the
> "gather.bin.parts" target from the the bundle's generated build.xml, and
> then proceeds to call this specially-generated "jarUp" target, which
> contains a special case for a bundle that contains a manifest file,
> calling the Ant <jar ..> task in a different way. Interesting. Looks
> like I am off to Bugzilla. The generated build.xml should contain
> similar logic in my opinion. There are lots of cases where people will
> want to use the targets in a generated build.xml directly, and there
> isn't a easy way around this problem for my particular situation that I
> can see.
>
> So back to my original question then: Do the extra, crufty lines that
> Ant sticks into my MANIFEST.MF files screw up anything related to OSGi
> bundles?
>
> Mark.
>
>
> On Wed, 07 Jan 2009 16:35:16 -0500, Mark Melvin <mark.melvin@onsemi.com>
> wrote:
>
>> Hi,
>>
>> I am integrating my plugin builds into a continuous integration type
>> system. I've noticed that the difference between the bundle JARs
>> produced with my new build system and those produced by my old,
>> monolithic PDE build is that the new JARs have had their bundle
>> manifests molested at some point by Ant. They now contain the
>> following lines:
>>
>> Ant-Version: Apache Ant 1.7.0
>> Created-By: 1.5.0_06-b05 (Sun Microsystems Inc.)
>>
>> First off, I'd like to know why this is happening now and it never has
>> before. The generated build.xml files that PDE build is using look the
>> same (the call to the Ant <jar ..> task is identical). Does anyone
>> know what prevents this from happening in a normal PDE build, or what
>> may trigger it to happen in general?
>> Second, are these lines going to screw up my bundle? I don't think
>> they are, but I would like to prevent them from appearing anyway.
>>
>> Thanks in advance,
>> Mark.
>
Re: PDE Build (Ant) Mucking With Bundle MANIFEST.MF [message #587996 is a reply to message #39684] Fri, 09 January 2009 15:07 Go to previous message
Mark Melvin is currently offline Mark MelvinFriend
Messages: 118
Registered: July 2009
Senior Member
Eric Rizzo wrote:

> If you file any bug reports, please post them links here so we can
> follow them.

Just finished.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=260550

Mark.
Previous Topic:How to change icon of menuContribution conditionally?
Next Topic:Feature dependency match rules
Goto Forum:
  


Current Time: Sat Jun 12 21:42:02 GMT 2021

Powered by FUDForum. Page generated in 0.02440 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top