Thanks a lot for both of your responses, Pascal. It helps a *lot*. I'll have another kick at it today - that should be enough to keep me going.
Mark.
----------------------------------------------------------
-----pde-build-dev-bounces@xxxxxxxxxxx wrote: -----
To: "Eclipse PDE Build developers list." <pde-build-dev@xxxxxxxxxxx>
From: Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
Sent by: pde-build-dev-bounces@xxxxxxxxxxx
Date: 12/01/2005 11:19PM
cc: "Eclipse PDE Build developers list." <pde-build-dev@xxxxxxxxxxx>, pde-build-dev-bounces@xxxxxxxxxxx
Subject: Re: [pde-build-dev] How to properly use configs= property
There are no problems with the approach
you are describing and this is what I would recommend.
In the SDK team we build our update
site by first doing a normal build and then running a little tool that
Sonia wrote but it is not available to the public because we don't want
to have the burden to maintain it. We are looking into making it part of
PDE and would actually welcome any help on that.
PaScaL
Mark_Melvin@xxxxxxxx
Sent by: pde-build-dev-bounces@xxxxxxxxxxx
12/01/2005 05:19 PM
Please respond to "Eclipse PDE Build developers list."
|
| To
| "Eclipse PDE Build developers
list." <pde-build-dev@xxxxxxxxxxx>
| cc
|
| Subject
| Re: [pde-build-dev] How to
properly use configs= property
|
|
Well, with a little more investigation it appears that Eclipse 3.1 PDE
build provides a new property called "outputUpdateJars". Since
all I want to do is build the update sites, and it appears that the "build.update.jar"
target in the feature's build.xml doesn't work, or at least doesn't account
for the current os/ws setting, I'm thinking I should just edit my scripts
to take advantage of the "outputUpdateJars" property. If
I can get at the final archives for the features (which shouldn't be too
hard), I can just inflate it into a directory for my update site. This
would be a lot quicker as well because I wouldn't have to re-assemble anything.
Can anyone see any problems with this approach? Also - why is it
that the actual assemble step succeeds in creating an update site jar,
but the "build.update.jar" target in each feature's build.xml
does not work? Is this perhaps a bug?
Also, how the heck does Eclipse.org create update sites? I can't
seem to find any sample code in CVS.
Thanks,
Mark.
----------------------------------------------------------
Mark_Melvin@xxxxxxxx
Sent by: pde-build-dev-bounces@xxxxxxxxxxx
12/01/2005 04:03 PM
Please respond to "Eclipse PDE Build developers list." <pde-build-dev@xxxxxxxxxxx>
|
| To
| pde-build-dev@xxxxxxxxxxx
| cc
|
| Subject
| [pde-build-dev] How to properly use
configs= property
|
|
Hi Everyone,
I have been using PDE build to build an Eclipse-based product for a couple
years, and we are now getting into multi-architecture builds. I have
always had *issues* with this before, but a quick hack a couple years ago
was enough to keep me happy. That is no longer good enough and I
would like to figure this out once and for all. I've spent most of
the day looking at the features and build scripts in the Eclipse CVS repository
and frankly I am no further ahead. What I am trying to do is quite
simple, so I'll try to explain it in the hopes that someone can help me
out.
We have a product made up of 11 features. We do not have a single,
top-level feature containing all of these (like Eclipse has with the SDK),
and I do not have the option to go to this hierarchy, so...I have 11 features.
Of these 11 features, a couple have platform-specific plugins and
fragments. So, in the grand scheme of things, my features are all
platform-neutral except for a few. Let's simplify this down to 2
features then, 1 that is good for all platforms (feature1) and one that
is platform specific (feature2). Currently, let's say I *just* want
to build a win32 version of my platform.
Now, my features are not declared to be platform specific in any way (which
is the way Eclipse does it, it appears), but the platform-specific feature
contains a win32 version of a plugin and a linux version of a plugin, that
are each declared platform-specific as required. So, I assume building
the feature will do the right thing depending on what configuration I am
building.
In my customTargets.xml I have the following:
<target name="allElements">
<!-- Generic feature -->
<ant antfile="${genericTargets}" target="${target}"
>
<property name="type"
value="feature" />
<property name="id"
value="com.amis.feature1" />
</ant>
<!-- Platform-specific feature -->
<ant antfile="${genericTargets}" target="${target}"
>
<property name="type"
value="feature" />
<property name="id"
value="com.amis.feature2" />
</ant>
</target>
<!-- Generic feature -->
<target name="assemble.com.amis.feature1">
<property name="archiveName" value="amis-feature1-${buildId}.zip"/>
<ant antfile="${assembleScriptName}"/>
</target>
<!-- Platform-specific feature -->
<target name="assemble.com.amis.feature2.win32.win32.x86">
<property name="archiveName" value="amis-feature2-win32-${buildId}.zip"/>
<ant antfile="${assembleScriptName}"/>
</target>
OK, fine. I *just* want to build a win32 version of my platform so
I run my build with -Dconfigs=win32,win32,x86 and the build makes it to
the assemble stage and fails with the error:
C:\Temp\eclipse\assemble.com.amis.feature1.all.xml:7: The following error
occurred while executing this line:
Target `assemble.com.amis.feature1.win32.win32.x86' does not exist in this
project.
So, apparently the assemble targets must match the
configs
property...not
reflect what the feature itself supports. OK, well I don't understand
why would I want to build a "win32" version of a completely platform-neutral
plugin. Alright, so I go ahead and change my assemble targets to
be:
<target name="assemble.com.amis.feature1.win32.win32.x86">
<property name="archiveName" value="amis-feature1-win32-${buildId}.zip"/>
<ant antfile="${assembleScriptName}"/>
</target>
<!-- Platform-specific feature -->
<target name="assemble.com.amis.feature2.win32.win32.x86">
<property name="archiveName" value="amis-feature2-win32-${buildId}.zip"/>
<ant antfile="${assembleScriptName}"/>
</target>
I run the build again with configs=win32,win32,x86 and the build makes
it all the way through to my post-build step where if fails when generating
the update site (my code) with the following error:
C:\Temp\eclipse\features\com.amis.feature1\build.xml:74: The following
error occurred while executing this line:
Target `rootFiles*_*_*' does not exist in this project.
OK, now hang on a minute. Why is it building an update site using
*_*_*, when it is supposed to only be doing win32,win32,x86?? My
Ant call that creates the update site is as follows:
<antcall target="allElements">
<param name="genericTargets" value="${customTargets}"/>
<param name="target" value="updateSiteExport"/>
<param name="updateSiteExport.outputDir"
value="${updateSite.dir}" />
</antcall>
where updateSiteExport is:
<target name="updateSiteExport">
<mkdir dir="${updateSiteExport.outputDir}"/>
<mkdir dir="${updateSiteExport.outputDir}/features"/>
<mkdir dir="${updateSiteExport.outputDir}/plugins"/>
<!-- Build and stage the jars for the site -->
<ant antfile="build.xml" dir="${buildDirectory}/features/${id}/"
target="build.update.jar">
<property name="feature.destination"
value="${updateSiteExport.outputDir}/features"/>
<property name="plugin.destination"
value="${updateSiteExport.outputDir}/plugins"/>
</ant>
</target>
It looks like everything is building properly. Why is it failing
on the update site? FWIW, the hack I have had in place for years
is to basically build both the *,*,* AND win32,win32,x86 configurations,
adding BOTH assemble targets for each feature to customTargets.xml - but
this is just dumb.
I guess a main question I am left with is what the heck is *,*,* ever used
for? It looks like that is what you would want to use for features
that are not platform-specific, but how do you NOT use it for the platform-specific
features (if that makes any sense at all...).
Thanks for any help,
Mark.
_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev
_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev
_______________________________________________
pde-build-dev mailing list
pde-build-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/pde-build-dev