Re: [pde-build-dev] How to properly use configs= property

[Mark_Melvin@xxxxxxxx]

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