Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cross-project-issues-dev] Building update jars


The way the eclipse platform build works is that we basically build the update jars zip first, this zip is conditioned and packed.  Then the base builder unzips that update zip and uses the pde.build package.xml to repackage it into the zips for download.
This way, the conditioning is only done the once.

If the package.xml wasn't used to repackage the update zip, then yes, I think that you would need 2 passes.

-Andrew



David M Williams <david_williams@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

05/03/2006 01:18 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
Re: [cross-project-issues-dev] Building update jars






Thanks Pascal and can you confirm ... using ouputUpdateJars basically implies two passes, right? One to produce the jars, one to produce the zips?


I think that's the "rub" in having a central, simple place to "pack" the jars .. once produced the jars need to be treated in one step after the other (not replace) ... though, I guess, they could be "conditioned" in the pass for the zips, and then conditioned and packed for the update jars case?






Pascal Rapicault <Pascal_Rapicault@xxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

05/03/2006 12:45 PM

Please respond to
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>

To
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>, cross-project-issues-dev-bounces@xxxxxxxxxxx
Subject
Re: [cross-project-issues-dev] Building update jars








The build.update.jar target generated in build.xml for plugin and feature is deprecated and should not be used (see bug #139268).

In order to produce jars for an update site you should be setting the property called outputUpdateJars


Richard Gronback <richard.gronback@xxxxxxxxxxx>
Sent by: cross-project-issues-dev-bounces@xxxxxxxxxxx

05/03/2006 12:18 PM

Please respond to
Cross project issues


To
Cross project issues <cross-project-issues-dev@xxxxxxxxxxx>
cc
Subject
[cross-project-issues-dev] Building update jars









As I mentioned on the call, the generated build scripts for
plugins/features from pde basebuilder includes a build.update.jar target
(see generated build.xml for your features/plugins).  This is what the
GMF build uses (and I assumed most/all projects used).

To me, the pack200 steps could be included in what's generated by the
basebuilder (although honestly, I haven't looked into the details of it
yet).

In a customTarget.xml file, you can call this target using something
like this:

<!-- ===================================================================== -->
 <!-- Steps to do after the build is done. -->
 <!-- ===================================================================== -->
 <target name="postBuild">
     <antcall target="gatherLogs" />
     <!-- A temporary directory leftover? -->
     <delete dir="${buildDirectory}/org.eclipse.gmf"
failonerror="false"/>
     <antcall target="publish"/>      
     <antcall target="generateUpdateSite"/>
 </target>

 <!-- ===================================================================== -->
 <!-- Update the update site. -->
 <!-- ===================================================================== -->  
 <target name="generateUpdateSite">
       <!-- Create the directory structure -->
       <mkdir dir="${buildUpdateSitePath}/features"/>
       <mkdir dir="${buildUpdateSitePath}/plugins"/>
       <!-- Build the jar files -->
       <antcall target="allElements">
         <param name="genericTargets"
value="${builder}/customTargets.xml"/>
         <param name="target" value="updateSiteExport"/>
       </antcall>
 </target>

 <target name="updateSiteExport">
   <ant antfile="build.xml" dir="${buildDirectory}/features/${id}/"
target="build.update.jar">
     <property name="feature.destination"
value="${buildUpdateSitePath}/features"/>
     <property name="plugin.destination"
value="${buildUpdateSitePath}/plugins"/>
       <!-- Override the default temp.folder location, as it is too deep by default               on Windows, causing missing files in jars. -->
       <property name="temp.folder" value="${buildRoot}/temp.folder"/>
   </ant>
 </target>

I'll post this to the tips section on the wiki.

Best,
Rich
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev


Back to the top