Home » Eclipse Projects » Plugin Development Environment (PDE) » PDE Build (Ant) Mucking With Bundle MANIFEST.MF
|
| Re: PDE Build (Ant) Mucking With Bundle MANIFEST.MF [message #39593 is a reply to message #39314] |
Thu, 08 January 2009 21:36   |
 Mark Melvin
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 |
Eclipse User |
|
|
|
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 #587953 is a reply to message #39314] |
Thu, 08 January 2009 21:36 |
Mark Melvin
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 |
Eric Rizzo
Messages: 3070
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.
>
|
|
| |
Goto Forum:
Current Time: Thu Dec 26 15:15:39 GMT 2024
Powered by FUDForum. Page generated in 0.04306 seconds |
] 
Search
Help
Register
Login
Home
