| Siva Velusamy | eec615b | 2014-03-25 17:39:09 -0700 | [diff] [blame] | 1 | Summary: |
| 2 | |
| 3 | To generate p2 artifacts from jars, run: |
| 4 | $ mvn --no-snapshot-updates --offline p2:site \ |
| 5 | -Dmaven.repo.local=../../out/host/maven/localrepo |
| 6 | The folder ${build.directory}/repository contains the resultant |
| 7 | p2 repository. ${build.directory} is defined inside pom.xml |
| 8 | |
| 9 | Details: |
| 10 | |
| 11 | The Eclipse plugins in $root/sdk/eclipse/plugins depend on a number |
| 12 | of jar files from: |
| 13 | $root/tools/base |
| 14 | $root/tools/swt |
| 15 | $root/prebuilts/tools/common/m2/repository |
| 16 | |
| 17 | In earlier versions, a script (create_all_symlinks.sh) knew about |
| 18 | which plugins depended on which jars, and when executed, it would |
| 19 | copy over those jars into the plugin's libs folder. Each plugin |
| 20 | included the jars from its libs folder as part of its classpath, |
| 21 | and the entire libs folder was bundled inside the plugin. |
| 22 | |
| 23 | Such a scheme has a number of issues: |
| 24 | - bundling jars inside libs/ folder inside each plugin is not |
| 25 | recommended by Eclipse. This causes performance degradation |
| 26 | at runtime. |
| 27 | - at build time, the script modifies the source folders to add |
| 28 | the contents inside libs folder. Ideally, the source folders |
| 29 | shouldn't be modified during build. |
| 30 | - the script has to maintain state about which plugin depends |
| 31 | on which jars. |
| 32 | |
| 33 | The approach suggested by Eclipse is to replace the regular jars |
| 34 | with OSGI bundles, and for each plugin to explicitly add a dependency |
| 35 | to the required OSGI bundles. In essence, this makes each of the |
| 36 | jars to be similar to a plugin. |
| 37 | |
| 38 | This folder contains scripts that can be used to convert a set |
| 39 | of jars into OSGI bundles using the p2-maven-plugin |
| 40 | (https://github.com/reficio/p2-maven-plugin). |
| 41 | |
| 42 | $ mvn --no-snapshot-updates \ |
| 43 | --offline \ |
| 44 | -Dmaven.repo.local=../../out/host/maven/localRepo \ |
| 45 | p2:site |
| 46 | |
| 47 | The pom.xml file lists the set of jars to be processed. The |
| 48 | runtime options to Maven include: |
| 49 | --offline: We don't want Maven to fetch anything from the internet. |
| 50 | All required dependencies must be checked into git. |
| 51 | --no-snapshot-updates: If the tools artifacts have a -SNAPSHOT |
| 52 | in them, Maven will attempt to re-download those artifacts, |
| 53 | which would fail since we are running in offline mode. This |
| 54 | option instructs Maven to not attempt to download these |
| 55 | snapshots and use whatever is available in the local repositories. |
| 56 | -Dmaven.repo.local=path to the local repository that should be |
| 57 | used by maven. Without this, it'll use $HOME/.m2. This should |
| 58 | be initialized with all the necessary artifacts if running in |
| 59 | offline mode. |
| 60 | |
| 61 | Additional considerations for running in offline mode: |
| 62 | |
| 63 | When running in online mode, there are 3 sources from which files |
| 64 | are downloaded by Maven: |
| 65 | 1 Maven Central |
| 66 | 2 the repository where the tools/base and tools/swt artifacts are |
| 67 | generated |
| 68 | 3 the prebuilts/tools/common/m2 repository (this is a subset of 1). |
| 69 | Even though 2 and 3 are available locally, we cannot just use them |
| 70 | in offline mode since Maven treats repositories with file:/// urls |
| 71 | as remote as well. As a result, the only way to run offline is to |
| 72 | first explicitly copy the contents of 2 and 3 into the local repository |
| 73 | (-Dmaven.repo.local) before initiating an offline build. |