Message-ID: <389059343.42536.1371729188963.JavaMail.firstname.lastname@example.org> Subject: Exported From Confluence MIME-Version: 1.0 Content-Type: multipart/related; boundary="----=_Part_42535_1172469745.1371729188963" ------=_Part_42535_1172469745.1371729188963 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Content-Location: file:///C:/exported.html
During 2.x development, the Maven-eclipse-plugin became more and= more complex with addition of support for many variants of Eclipse (RAD, M= yEclipse, ...) and support for various users request. The 2.5.x series intr= oduced nice integration with eclipse with detection of projects present in = workspace, with the cost of yet more code. In the same time, many users are= still not happy with the way this plugin configures the workspace, with re= quest to support many tools configuration, that exist both as maven and ecl= ipse plugins.
This proposal goal is to define a new architecture for the maven-eclipse= -plugin 3.x , based on a limited and extensible core, completed by loosely = coupled components to analyse the workspace and setup eclipse to match user= environement. Custom extension can be added to the plugin simply by adding= a dependency to the plugin configuration. This will encourage other plugin= developpers to create maven-eclipse-plugin extension that can be used with= no delay, and could be later included in the plugin itself if supported by= the community.
Please note this proposal is early draft
The maven-eclipse-plugin will define a public contributor API, as a dedi= cated artifact that any extension will depend on. This API consist of :
The contributor will receive the workspace location path and can extract= from there any relevant information (eclipse variant, installed features, = ...)
The contributor will receive the MavenProject model object to be analyze= d ant extract maven configuration that may be translated to eclipse
The contributor will get invoked after workspace and project analysis, a= nd can then add / contribute configuration objets in the context
The context will contain informations extracted from the environment (ec= lipse workspace + maven project) and configuration objects
At contributor-API level, this is not related to files beeing writen but=
only to abstract configuration objects. Only the core plugin will convert =
those classes to configuration files. The plugin offers a default set of Co=
nfiguration objects for standard eclipse configuration files (.classpath, .=
project, .settings ...)
A contributor can then detect if the feature it supports is enabled/supp= orted (and share the info with other contributors), contribute configuratio= n objets and define new ones.
The maven-eclipse-plugin itself will package many contributors for the f= eatures supported by the 2.5.x series. The code from this branch will be re= factored to the new architecture.
to be investigated
one option is to declare all contributors as nested <extension> el= ements in the plugin configuration, but this may create huge/ugly configura= tion blocs.
another option is for the plugin to share a global Tree-style configurat=
ion object, with some default entries ("workspace" for the eclips=
e workspace location) an some contributor dedicated ones ("spring.cont=
ext.includes" =3D */applicationContext.xml) that will=
be used only by the contributors.