GFv3 Source Integration Objective The objective of the source integration is to gather all the dependencies and to be able to build GlassFish v3 from scratch. Limitations The source integration will only include dependencies that are used to build and run GFv3. And this includes source from both internal java.net projects as well as third-party external projects. Proposal Requirements Tools that are used to checkout and build GFv3 and external sources should be installed on the system that is building the source integration. Since GFv3 uses Maven version 2.0.9, JDK 1.6 and SVN, these tools must be installed and set in the path. The same local maven repository is used for all GFv3 and external artifacts. External Dependencies
- Third-Party Dependencies
- Port third-party sources to the GlassFish svn repository:
https://svn.java.net/svn/glassfish~svn/trunk/external/modules
See complete instructions on committing third-party source.
Only port the external sources that are not in a Sun controlled SCM repository (e.g. java.net, kenai).
- External dependencies in GFv3 workspace should be non-Snapshot versions and the source to check out is from a tagged workspace.
Bootstrap Ant Scripts The bootstrap ant build scripts check-out and build the external module and it's dependencies. It also publish the module's artifacts to the local maven repository. The build script is for each module and it is named module-name.xml. The default location for the source to check-out is base.dir/external. A build.properties file defines the scm location of the external modules. A top level build.xml script invokes each module's build script in the order of it's dependencies. The local maven repository defaults to $
Unknown macro: {user.home}
/.m2/repository, but can be altered with the environment variable, maven.repo.local. When all the external modules are built, then proceed with building GFv3 using the same local maven repository.
The build scripts are located in https://svn.java.net/svn/glassfish~svn/trunk/external/source-build/. The module owners are responsible for the module build scripts and keeping the version and scm location up-to-date in the build.properties file.
- Examples:
- External Module with no dependencies
In https://svn.java.net/svn/glassfish~svn/trunk/external/source-build/, there are build scripts for hk2, jsp, uel, grizzly and others. Respectively, the scripts are named as: hk2.xml, jsp.xml, uel.xml, grizzly.xml.
In the script for jsp module, https://svn.java.net/svn/glassfish~svn/trunk/external/source-build/jsp.xml, there are two goals: jsp.checkout and jsp.build. The goal, jsp.build checks out, build and publish the jps artifact to the maven local repository. This is the goal that the top level build.xml invokes. Please take a look at: https://svn.java.net/svn/glassfish~svn/trunk/external/source-build/build.xml. The build.properties file contain scm location of all the external modules: https://svn.java.net/svn/glassfish~svn/trunk/external/source-build/build.properties. This properties file must be updated if new revision of the external module is added to the GFv3 workspace.
-
- External Module with dependencies
In the weld module, there is a slf4j dependency. The sources for slfrj are committed to the internal glassfish-svn. Ant targets are created to check-out and build the dependency and lastly publish the artifact to the the local maven repository. The dependency must be built before building weld artifacts. Please see: https://svn.java.net/svn/glassfish~svn/trunk/external/source-build/weld.xml. File Layout * external/
*** hk2/
*** corba/
*** grizzly/
*** wsit/
*** asm/
*** bean-validator/
*** weld/
{{*** ... }}
* build.xml
* build.properties
* hk2.xml
* corba.xml
* grizzly.xml
* wsit.xml
* asm.xml
* bean-validator.xml
* weld.xml
* ,,, Flow Chart Cannot resolve external resource into attachment. Building External Source and GFv3 A Hudson job will be created to execute the top level build.xml file. The artifacts from building the external module are published to a local maven repository. The same local maven repository is used to build GFv3. Status List of v3 external modules is here.
Remaining Tasks .
Phases . Note that <local-maven-repo> must reference the same local maven repository.
Also see instructions on building v3 here. FAQ Q: My external module has dependencies on 10 other external source, do I need to port all the source to the internal glassfish SVN repo?
A: If the external source is not in a Sun controlled SCM repository, then yes, you'll need to port all the 10 dependencies and be able to build and publish it to the local maven repository.
Q: I could not find the SCM repository for the external module source. The source is a zip file from sourceforge.org. Do I still need to port it to glassfish internal svn?
A: It's preferably that the source is coming from a tagged SCM repository. It's possible that the source is no longer in any open source SCM repository. In that case, we will have to port the source from the zip to GlassFish repo. Please document where the source is coming from in a README file when committing the source in SCM.
Q: The external source do not use Maven 2.0 to build. How do I publish the artifact to the local maven repository?
A: You can use "mvn install-file...". Please see example in weld.xml https://svn.java.net/svn/glassfish~svn/trunk/external/source-build/weld.xml
Q: The external source requires an older version of JDK to compile. How do I build from ant if rest of the external module is using JDK 1.6?
A: You can use ant's exec task and specify the JAVA_HOME environment. You'll also need to specify the location of JDK in build.properties file. Please inform RE and Build Engg with the JDK requirement so the the machine that is setup to build source will have the version of JDK installed.
Q: The external source is in native C/C++. Do I need to build it on all the platforms supported by GFv3?
A: If possible, please avoid using native code. But if native code is a must, then you'll need provide the instructions to build the native code in all the platforms supported by GFv3. Please document the build instructions clearly and identify the tools required to build the native code.
Q: The external source uses Maven 1.0. How do I build and publish to a Maven 2.0 repository?
A: You can use Maven One Convert plugin http://maven.apache.org/plugins/maven-one-plugin/convert-mojo.html to convert Maven 1.0 project.xml to Maven 2.0 pom.xml. Please see example of this in weld.xml https://svn.java.net/svn/glassfish~svn/trunk/external/source-build/weld.xml Known Issues
If the external module (A) depends on a GFv3 module (B) and another GFv3 module (C) depends on (A). How do we determine the build order? For any further questions, please contact: jane.young@sun.com
|
