Hi,

These are just brief notes of what we discussed at the meetup @ ApacheCon last 
night. Typed on an ipod, so perhaps kind of brief - others might want to 
annotate.

Attended:
Committers: Brian, Ralph, Brett, Carlos
Others: Lennart Jörelid, Ray Whitmer

Started late due to keysigning.

* What should be on the roadmap?

API vs Implementation in repository (specification dependencies)
- opportunity to be doing something to force some best practices

This led to talking about what gets stored in the repository.

Locking down the ranges/properties in the deployed POM
- reproducibility
- retain more for better conflict resolution

Ability to reproduce exactly the build, contrasted ability to not have to 
update so often for versions and utilize ranges to get newer.

Configurable conflict resolution strategy - newest, oldest that satisfies
Enforcer rule to lock down above
Importance of specificity, not magic - break the build if conflicting versions, 
not try and solve it
Be deterministic is maven's strength

Brian wants to flatten the inheritance and interpolation for the metadata in 
the repository since it's never different and it's more efficient
Causes more duplication and loses some information (also wouldn't work with 
snapshots)
Some suggestion doing the same of dependencies but it's a more complex problem 
and needs some extra info

Maybe build section should be separated

What versions of maven 2 do we support in the maven 3 repo if we make changes? 
Opinion is 2.0.9+

Ignoring new metadata may not be the solution for backwards compat. if the new 
info changes behaviour

* POM

No need to discuss much - thread is already on the dev't list (once caught up 
after ApacheCon)

Ralph likes original model improvements in Maven 3 - might help with 
versionless parent

Carlos mentioned using namespaces to introduce new POM elements. Several 
potential problems raised due to not knowing about the namespaces before 
loading plugins. Maybe better to extend through plugin configuration, though 
XSD namespaces for that might help for hand editors.

* Plugin Testing

Lennart is writing custom plugins, unit and integration testing - there's still 
multiple suggested solutions and wants the one true way. Lennart to prod dev 
list.

Documentation needs to improve on plugin dev't - is out of date. Good 
documentation might lead to better quality of plugins / better practices.

* Other

Having a clearer roadmap might help encourage contribution or work to happen.

Concerns about git complexity for users, but recognised benefits of some of the 
features (particularly those on github). Reviewboard might help.

- Brett

--
Brett Porter
[email protected]
http://brettporter.wordpress.com/


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to