Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "ATF/Building"

< ATF
m
(adding remonder about pde build platform specific configs flags definition)
 
(13 intermediate revisions by the same user not shown)
Line 2: Line 2:
  
 
== Contact ==
 
== Contact ==
You can send an email toi the atf-dev mailing list to get help with this build.
+
You can send an email to the atf-dev mailing list to get help with this build.
This is an early work in progress.
+
  
== Packaging ==
 
The selected way to distribute the ATF binaries is a zipped update site. The rationale is that there are third party dependencies (like Mozilla XPCOM and some Ajax Toolkits libraries which have not been approved for re-distribution by Eclipse). Using an update site allows to provide update site pointers to install the missing pieces from remote sites like Mozilla.org in one pass.
 
  
== Build process ==
+
== Things left to do ==
 +
*Upgrade all the versions numbers of the plugins and features to use the ".qualifier" convention, as in [[http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tasks/pde_version_qualifiers.htm]]
 +
*Finish split at build-time of the Mozilla fragment in one frgament per platform. For that, each platform specific source tree will be copied to its respective fragment module (which does not contain yet any sources) in the post fetch phase of the PDE build. Once that is done, the build can continue normally.
 +
*Add zipped update site generation
 +
*Add live update site generation
 +
*Update all bundles Execution Environment to Java 1.4, and ensure that 1.4 is installed and used for the build.
 +
*Add source feature generation
 +
*Add Javadoc generation
 +
*Add build results publishing
 +
 
 +
 
 +
== ATF packaging for download==
 +
The preferred way to distribute the ATF binaries is a zipped update site. The rationale is that there are third party dependencies (like Mozilla XPCOM and some Ajax Toolkits libraries which have not been approved for re-distribution by Eclipse). Using an update site allows to provide update site pointers to install the missing pieces from remote sites like Mozilla.org in one pass.
 +
 
 +
== ATF build process overview ==
 
The build is using PDE Build.
 
The build is using PDE Build.
 +
 
The sequence for that build is:
 
The sequence for that build is:
*Download a reference environment to build against: in this phase a complete reference Eclipse SDK (using the web tools all in one drop) is retrieved, extracted and layed for use in PDE build. This guarantees that the build is made against a well known stable Eclipse environment. A few other dependencies (Mozilla, Zimbra, etc) which are required for compilation but are not shipped with ATF are also downloaded, extracted and set to participate in the build. THE FIRST TIME YOU RUN THE BUILD, THIS DOWNLOAD CAN TAKE A WHILE, there are about ~250MB of software that are downloaded. Those downloads are ached.
+
*Download a reference environment to build against: in this phase a complete reference Eclipse SDK (using the web tools all in one drop) is retrieved, extracted and layed for use in PDE build. '''This guarantees that the build is made against a well known stable Eclipse environment.''' A few other dependencies (Mozilla, Zimbra, etc) which are required for compilation but are not shipped with ATF are also downloaded, extracted and set to participate in the build. THE FIRST TIME YOU RUN THE BUILD, THIS DOWNLOAD CAN TAKE A WHILE, there are about ~250MB of software that are downloaded. Those downloads are cached.
 
*From then on the regular PDE build sequence is followed:   
 
*From then on the regular PDE build sequence is followed:   
 
**each feature and plugin is fetched from CVS using a directory or map file, (for now pointing to HEAD as opposed to specific labels)
 
**each feature and plugin is fetched from CVS using a directory or map file, (for now pointing to HEAD as opposed to specific labels)
Line 17: Line 29:
 
**compilation is performed
 
**compilation is performed
 
**etc
 
**etc
*At the end of the PDE build sequence the built plugins are assembled is archives.
+
*At the end of the PDE build sequence the built plugins are assembled in archives (check for thsoe somewhere at the root of the build folder)
  
 +
NB: for now the build is using a build feature, that is a feature used only for building. The packaging still need some polishing to assemble other features, not the feature used for build.
  
== Work in progress ==
 
You can check the work in progress on the build there:
 
http://easyeclipse.cvs.sourceforge.net/easyeclipse/easyeclipse/easyeclipse/org.nexb.easyeclipse.vendors/eclipse-atf/plugins/org.eclipse.atf.releng/
 
  
 +
== Getting started ==
 +
To try this build yourself, follow those instructions:
  
== Getting Started ==
+
*Install Sun Java 1.4.2 and Eclipse 3.3.0 (SDK) (or better the WTP all in one 3.3.0)
*Using Eclipse 3.2.1, create a bew CVS repo connection to: :pserver:anonymous@easyeclipse.cvs.sourceforge.net:/cvsroot/easyeclipse
+
*In Eclipse create a new CVS repo connection to: :pserver:anonymous@dev.eclipse.org:/cvsroot/webtools then check out this project:  
*Check out this project: easyeclipse/easyeclipse/org.nexb.easyeclipse.vendors/eclipse-atf/plugins/org.eclipse.atf.releng/
+
org.eclipse.atf/components/org.eclipse.atf.releng (or use your favorite command line CVS to get the same result)
 +
*Define environment variables: ECLIPSE_HOME pointing to the root of your Eclipse install and JAVA_HOME pointing to the root of your JAVA install.
 
*Open a shell or command line prompt, and navigate to the org.eclipse.atf.releng directory  
 
*Open a shell or command line prompt, and navigate to the org.eclipse.atf.releng directory  
*Copy the file build.properties.template to the directory <user home>/eclipse-atf/build.properties and edit it following the instructions in that file.
+
*Copy the file build.properties to the directory <user home>/eclipse-atf/build.properties and edit it following the instructions in that file, to make sure that the build knows about a few platform specific locations
*Type "anteclipse main" and watch things unfold.
+
*Type "anteclipse all" and watch things unfold.  
 +
(Or if you are familiar with PDE build you can launch it the usual way. I have committed a convenience build.xml to bootstrap the build, and a convenience shell utility "anteclipse", wrapper to invoke Eclipse Ant runner. )
  
  
 +
== ATF Mozilla browser fragments split specifics ==
 +
ATF provided a Mozilla-based SWT browser widget for every supported platform. It now relies on the SWT Mozilla browser widget.
 +
One platform specifc bundle is used for each platform specific Xulrunner, which provides the behavior for the Mozilla browser widget. One other bundle (org.mozilla.xpcom) contains the the Mozilla XPCOm interfaces for bridging Xulrunner with Java.
  
 +
Those bundles are available for MacOS, Windows and Linux/GTK 32 bits at Mozilla.org.
 +
The latest version is here: ftp://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/eclipse
  
  
== Mozilla browser fragments specifics ==
 
The current CVS and plugin layout is to have one fragment to SWT: org.eclipse.atf.mozilla.browser that has one common source tree, and one source tree for each supported platform specific source code. This is similar to the Platform SWT layout.
 
Until now, the build has been performed using manual exports, exporting two versions with the exact same IDs, one for Linux and one for Windows. Once completed the setup will be identical at design time. Yet at build time, one platform specifc fragment will be built for each piece of platform specific code (which is no more than once class (MozillaBrowser) for now).
 
  
Provisional fragments can be studied here, until they get included in the Eclipse.org CVS repo:
+
== Getting platform specific fragments and plugins to build correctly with PDE build ==
*[mac fragment| http://easyeclipse.cvs.sourceforge.net/easyeclipse/easyeclipse/easyeclipse/org.nexb.easyeclipse.vendors/eclipse-atf/plugins/org.eclipse.atf.mozilla.swt.browser.carbon.macosx/]
+
Those seem to be treated differently:  the fetch phase fetches correctly but they are forgotten in the generated assemble script
*[win32 fragment| http://easyeclipse.cvs.sourceforge.net/easyeclipse/easyeclipse/easyeclipse/org.nexb.easyeclipse.vendors/eclipse-atf/plugins/org.eclipse.atf.mozilla.swt.browser.win32.win32.x86/]
+
This applies to plugins defined in features such as
*[linux/gtk/x86 fragment| http://easyeclipse.cvs.sourceforge.net/easyeclipse/easyeclipse/easyeclipse/org.nexb.easyeclipse.vendors/eclipse-atf/plugins/org.eclipse.atf.mozilla.swt.browser.gtk.lilnux.x86/]
+
<plugin   
*[linux/gtk/x86_64 fragment| http://easyeclipse.cvs.sourceforge.net/easyeclipse/easyeclipse/easyeclipse/org.nexb.easyeclipse.vendors/eclipse-atf/plugins/org.eclipse.atf.mozilla.swt.browser.gtk.linux.x86_64/]
+
id="org.eclipse.atf.mozilla.swt.browser.gtk.linux.x86
 +
os="linux
 +
ws="gtk"   
 +
arch="x86" />
 +
 +
To get those bits built, we need to explicitly set the build.properties "configs" to a list  of platforms. the default *,*,* does not cut it
 +
So using:
  
The proposed layout is a workable situation (similar to that of SWT) where design time requires to use a checkout from CVS and some copy of a classpath file, and runtime gets proper fragments for each platform with their Eclipse platform filters defined, that are merged in SWT.
+
configs=win32, win32, x86 & \
 
+
linux, gtk, x86 & \
 
+
macosx, carbon, ppc & \
 
+
macosx, carbon, x86
 
+
is the way
 
+
== Things to do ==
+
*Upgrade all the versions numbers of the plugins and features to use the ".qualifier" convention, as in [[http://help.eclipse.org/help32/index.jsp?topic=/org.eclipse.pde.doc.user/guide/tasks/pde_version_qualifiers.htm]]
+
*Finish split at build-time of the Mozilla fragment in one frgament per platform. For that, each platform specific source tree will be copied to its respective fragment module (which does not contain yet any sources) in the post fetch phase of the PDE build. Once that is done, the build can continue normally.
+

Latest revision as of 16:11, 6 March 2008

Part of ATF Ajax Toolkit Framework

Contact

You can send an email to the atf-dev mailing list to get help with this build.


Things left to do

  • Upgrade all the versions numbers of the plugins and features to use the ".qualifier" convention, as in [[1]]
  • Finish split at build-time of the Mozilla fragment in one frgament per platform. For that, each platform specific source tree will be copied to its respective fragment module (which does not contain yet any sources) in the post fetch phase of the PDE build. Once that is done, the build can continue normally.
  • Add zipped update site generation
  • Add live update site generation
  • Update all bundles Execution Environment to Java 1.4, and ensure that 1.4 is installed and used for the build.
  • Add source feature generation
  • Add Javadoc generation
  • Add build results publishing


ATF packaging for download

The preferred way to distribute the ATF binaries is a zipped update site. The rationale is that there are third party dependencies (like Mozilla XPCOM and some Ajax Toolkits libraries which have not been approved for re-distribution by Eclipse). Using an update site allows to provide update site pointers to install the missing pieces from remote sites like Mozilla.org in one pass.

ATF build process overview

The build is using PDE Build.

The sequence for that build is:

  • Download a reference environment to build against: in this phase a complete reference Eclipse SDK (using the web tools all in one drop) is retrieved, extracted and layed for use in PDE build. This guarantees that the build is made against a well known stable Eclipse environment. A few other dependencies (Mozilla, Zimbra, etc) which are required for compilation but are not shipped with ATF are also downloaded, extracted and set to participate in the build. THE FIRST TIME YOU RUN THE BUILD, THIS DOWNLOAD CAN TAKE A WHILE, there are about ~250MB of software that are downloaded. Those downloads are cached.
  • From then on the regular PDE build sequence is followed:
    • each feature and plugin is fetched from CVS using a directory or map file, (for now pointing to HEAD as opposed to specific labels)
    • build scripts are generated
    • compilation is performed
    • etc
  • At the end of the PDE build sequence the built plugins are assembled in archives (check for thsoe somewhere at the root of the build folder)

NB: for now the build is using a build feature, that is a feature used only for building. The packaging still need some polishing to assemble other features, not the feature used for build.


Getting started

To try this build yourself, follow those instructions:

  • Install Sun Java 1.4.2 and Eclipse 3.3.0 (SDK) (or better the WTP all in one 3.3.0)
  • In Eclipse create a new CVS repo connection to: :pserver:anonymous@dev.eclipse.org:/cvsroot/webtools then check out this project:

org.eclipse.atf/components/org.eclipse.atf.releng (or use your favorite command line CVS to get the same result)

  • Define environment variables: ECLIPSE_HOME pointing to the root of your Eclipse install and JAVA_HOME pointing to the root of your JAVA install.
  • Open a shell or command line prompt, and navigate to the org.eclipse.atf.releng directory
  • Copy the file build.properties to the directory <user home>/eclipse-atf/build.properties and edit it following the instructions in that file, to make sure that the build knows about a few platform specific locations
  • Type "anteclipse all" and watch things unfold.

(Or if you are familiar with PDE build you can launch it the usual way. I have committed a convenience build.xml to bootstrap the build, and a convenience shell utility "anteclipse", wrapper to invoke Eclipse Ant runner. )


ATF Mozilla browser fragments split specifics

ATF provided a Mozilla-based SWT browser widget for every supported platform. It now relies on the SWT Mozilla browser widget. One platform specifc bundle is used for each platform specific Xulrunner, which provides the behavior for the Mozilla browser widget. One other bundle (org.mozilla.xpcom) contains the the Mozilla XPCOm interfaces for bridging Xulrunner with Java.

Those bundles are available for MacOS, Windows and Linux/GTK 32 bits at Mozilla.org. The latest version is here: ftp://ftp.mozilla.org/pub/mozilla.org/xulrunner/releases/1.8.1.3/contrib/eclipse


Getting platform specific fragments and plugins to build correctly with PDE build

Those seem to be treated differently: the fetch phase fetches correctly but they are forgotten in the generated assemble script This applies to plugins defined in features such as <plugin id="org.eclipse.atf.mozilla.swt.browser.gtk.linux.x86" os="linux" ws="gtk" arch="x86" />

To get those bits built, we need to explicitly set the build.properties "configs" to a list of platforms. the default *,*,* does not cut it So using:

configs=win32, win32, x86 & \

linux, gtk, x86 & \
macosx, carbon, ppc & \
macosx, carbon, x86

is the way

Back to the top