THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
- Transactionality and Shutdown Safety
- Having a mechanism that writes all files out atomically where we have shutdown hooks to make sure everything is done safely. If all i/o operations pass through a simple Tx manager and the Tx manager is associated with a shutdown hook then we can make sure we don't end up with corrupted files.
- Backward Compatibility
- Provide layer of adapters for plugin backward compatibility,
to avoid immediate necessity to recode entire suite of
plugins and reports for 2.1 compat.
- Provide layer of adapters for plugin backward compatibility,
- Integrity checking
- Don't allow builds where versions come from non-project
sources like local settings and CLI parameters - JC: Don't allow builds where versions come from profiles that
have to be activated manually
- Don't allow builds where versions come from non-project
- Queryable Lifecycle
- The most important change in the embedding environment. You
can actually query Maven for the complete execution before it
happens - I would like to hook in the artifact resolution ghosting to
this- JC: This tends more toward simulating an entire build,
and should include simulating additions to source roots
and resources, IMO...but not in the core, in a simulator
mojo
- JC: This tends more toward simulating an entire build,
- The most important change in the embedding environment. You
- Toolchains
- Some preliminary work has been done on a branch by Milos and
myself, we're basically going to steal all the profile work
from Netbeans - JC: Do we even have specific requirements documented for
this? Where are they? - mkleint: the work we've done is not more than a gross sketch. Not sure what is there to be stolen/copied. The usecase for toolchains is basically this:
- Have a way for plugins to discover what JDK (or other tools) are to be used, without configuring the plugins. The current Maven way of achieving this is to run maven itself with the required JDK. After toolchains, the JDK that maven is running within, shall be irrelevant to the project in question.
- Some preliminary work has been done on a branch by Milos and
- Plugin Testing
- Results from ApacheCon discussion
- JC: Posted where?
- We Kenney's and Johns tools which are complementary embedder
inside the invoker
- Results from ApacheCon discussion
- Java5 Annotations
- We have two implementations for mojos which will be merged
- We have two implementations for plexus components
- Integration Testing
- Still not entirely happy with the current setup but it's
working and relatively easy to update - Too many tools
- IT plugins: john's with kenney goodies and fold john's
into the IT plugins as well - Invokers
- Verifiers
- IT plugins: john's with kenney goodies and fold john's
- JC: IMO, this would benefit greatly from having a decoupled
plugin invoker, since it would be really nice to orchestrate
several plugins for an IT setup, using a single IT plugin- thinking about the component-it-plugin, invoker-plugin,
and maybe verifier plugin or similar...
- thinking about the component-it-plugin, invoker-plugin,
- Still not entirely happy with the current setup but it's
- Custom Components
- Allowing easy plugging in of new resolvers and such
- Kenney has finished this and it's working in 2.1
- JC: IMO we need to address this as a first-class citizen
of the container, not simply rewriting the component
descriptor for the existing component.
- Specification Dependencies
- POM Changes
- tags/categories
- source: Maven, hand bombed and put in the metadata
- JC: What does this mean? Where the POM came from. A Maven build versus someone doing it manually
- Coding standard for project
- dependency excludes && symmetry (JC: consistency?) in the
plugins - terse attribute based format for the POM
- properties on dependencies and it was for a C build
- JC: What was for a C build? What do we need these
properties for? If we're thinking that would be a good
place to specify prefix for a C dependency, it's not a
very scalable approach...
- JC: What was for a C build? What do we need these
- tags for dependencies being used by different plugins
- JC: Can we deprecate scope in favor of this, then? Or, at
least trim it back? It seems to me that test scope falls
into the tagged-for-surefire category. - JC: We should also consider tagging for plugin-execution
since a single plugin could be used in multiple ways
(think surefire +integration-testing)
- JC: Can we deprecate scope in favor of this, then? Or, at
- the profile for an execution environment: development versus
production and getting the right specification dependencies,
packaging problems
...