- MavenProject instance references MavenProjectBuilder, ProjectBuilderConfiguration, RepositorySystem and, indirectly, PlexusContainer instance used to create the MavenProject instance. This means that MavenProject cache maintained by m2e will keep multiple plexus container instances in memory, unless m2e uses the same plexus container instance to populate project cache.
- Efficient execution individual mojos during incremental Eclipse build requires caching of maven plugin ClassRealms and plugin descriptors. This likely means that plexus container instances should be used to both create plugin ClassRealm and to execute mojos from that realm.
- m2e comes bundled with several external plexus containers (nexus-indexer, archetyper, dependency tree builder, maven-scm, doxia, maybe more). These components and their dependencies "leak" into maven embedder used to execute maven lifecycle in Eclipse JVM. TODO find JIRA(s)
- m2e uses buddy classloading to lookup plexus components in multiple osgi-bundles. This results in classloading deadlocks MNGECLIPSE-1140
- maven settings may not be consistently applied in all cases
Maven runtime used to configure and build Maven projects present in Eclipse workspace.
- read project with dependencies to populate m2e MavenProject cache
- execute Maven full or partial lifecycle during project import, configuration and Eclipse workspace build
- execute individual mojos (new in 0.9.9)
- introspect project build plan and mojo executions configuration
- workspace artifact resolution
Consumption of external plexus components (nexus-indexer, archetyper, dependency tree builder, maven-scm, doxia)
- external components are packaged with m2e
- m2e code has compile dependencies on these components
- m2e uses plexus APIs to lookup component instances
This is similar/identical to above, only components used are integral part Maven runtime
- resolve artifacts, to download sources, javadoc, pom.xml files, etc.
- read/write maven project Model, to support POM editor and pom.xml manipulation
- readProject and readProjectWithDependencies, to read arbitrary maven projects
- Global and User settings
- Local repository
- Network proxy
- Update snapshots
- Likely more
m2e uses maven code to parse/merge maven settings.
- m2e uses embedder.execute(install:install-file) to install artifacts to local repository.
- Stop using buddy classloading.
- Introduce permanent (for duration of eclipse session) "maven-core" plexus container in m2e.core bundle.
This container will use maven-embedder bundle classloader and thus will only see classes and components from maven core.
There are several ways to introduce additional components to maven.core plexus container (see below).
MavenProject and mojo caches will have to be populated using components from maven-core container.
- Introduce transient "m2e-utils" plexus container using m2e.core bundle classloader.
This container will see components from maven embedder and all other bundles m2e.core bundle depends on (nexus-indexer, archetyper, dependency-tree-builder)
- Introduce transient plexus containers in m2e.scm and m2e.pr bundles using their respective classloaders
This is similar to m2e.core and will allow lookup of scm and swizzle components
Tentatively, all maven configuration will be passed using MavenExecutionRequest properties.
As of 0.9.9, there is no hard need to introduce additional components to maven-core container. It would be nice to be able to add workspace artifact resolver as "live" component to maven-core container, but this is not strictly necessary.
In the future, integration with Tycho will require either ability to add new classrealms to existing container or, less desirable, will use fragment bundle to add Tycho jars to maven-embedder classpath. In the latter case, Tycho classes/components will become visible to all bundles that depend on maven-embedder and their plexus containers.
Remove the following classes