Message-ID: <1764483860.41240.1371647235272.JavaMail.email@example.com> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_41239_1198745081.1371647235272" ------=_Part_41239_1198745081.1371647235272 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
Over the course of the past year or so, Jason van Zyl, Jeff McAffer (IBM= / Equinox), Kim Moir (IBM / Platform), and John Casey (among others) have = had a series of conversations about supporting Eclipse builds through Maven= . Since both Maven and Eclipse have somewhat similar ideas about distributi= on of plugins and dependency components, and because Eclipse is a large and= diverse community who could benefit from build standardization, it seems n= atural to pursue the goal of having Eclipse itself build using Maven.
The following are a list of issues relayed to me (John) from Jeff and co= mpany, by way of Kim. These are seen as key features that Maven will have t= o support in order for Eclipse's various projects (particularly RCP/platfor= m/equinox) to build:
Maven must support reading project information directly from plugins.xml= , features.xml, and manifests in order to avoid the need to maintain manual= ly two pieces of metadata per eclipse project.
During a normal Eclipse PDE build, plugins which are already in the IDE = instance are used as dependencies for projects as needed. Maven should supp= ort resolving against installed plugins, features, etc. of an existing buil= d environment.
Some dependencies are platform-specific, such as SWT. Maven would have t= o allow expression of this, and handle it correctly.
NOTE: This might be feasible using profiles...need to c= heckout the RCP build to try it.
In some builds, dependency features are resolved in source form from SCM= and built prior to the main build running.
NOTE: We've done something like this for c-builds, and = may be able to make it a little more elegant using Buckminster's materializ= ation code.
When building certain projects, parts of the project are "fragment= ed" off into platform-specific sub-project builds that only run if the= platform is correct. Maven must support such conditional sub-project build= s to support Eclipse.
NOTE: This sounds like a set of profiles that inject mo= dules, much like the profiles in the Maestro build, but with different acti= vation.
Some builds require that certain sub-builds be constructed using one JVM= , while other sub-builds use a different JVM. Since these must build from a= single command-line, Maven must support the notion of JVM-per-project conf= iguration to support this.
NOTE: We might be able to work around this initially by= using maven-invoker.
feature.xml, one of the proposed sources of POM information, may in some= cases need to be filtered to set versions based on some external property.= I'm assuming that these filtered values would then make their way into the= live build process...
Many plugin builds involve bundling dependency jars within the plugin ja= r itself.
NOTE: This should be a breeze with the assembly plugin,= but we may want to make a descriptorRef available via a plugin-dependency = or something to support this better.
Two things related to this: