Hello all, On 11/15/2010 04:27 AM, Brett Porter wrote: [znip]
> > We use quite a few nonstandard patterns and components within > the Maven3 core - so let me suggest some refactoring ideas, > which I believe will simplify and augment Maven's internals > in upcoming releases. > > Model improvements: > a) Xpp3 --> JAXB. > We use Xpp3 to move entities to/from XML. > This isn't quite the right comparison. Xpp3 is a pull parser, a precursor > to StAX. There was this issue to migrate: http://jira.codehaus.org/browse/MNG-2255. However I have a feeling it was undone in the process of Maven 3 dev't. This is still worth doing IMO, > though as Nicolas says we need to keep the old API around since plugins depend on > it. I realise that we base our POJO --> XML --> POJO conversions on the Xpp3 pull parser, and that it has more in common with StAX than JAXB. However, my point is more that JAXB's framework performs the same function, while also being the JSE standard for Serialization/Deserialization of POJOs to XML. This implies more people know how to handle themselves gracefully around JAXB... which is good for bugfixing and idea spawning. Since I believe we have a few simplifications to do WRT the Maven core in general, I wanted to toss the idea to the list as an appetizer; I'm well aware of the workload required to move to the JSE standard. However, I think we should consider moving in the general direction of using JSE standards in most or all parts of the Maven core. We need to facilitate understanding and increase code quality. 2010/11/16 Jesse Glick <[email protected]> > > > On a tangent, I agree with Lennart's complaints about the quality of the > interfaces generated by Modello, but at least I can refer back to the schema for explanation; the hand-written interfaces in Maven are > just as bad as regards null safety, bean "pattern" abuse, and Javadoc, but in a less predictable way. My experiences embedding > Maven 3 in an IDE go something like this: [bit of rather funny rant/read znipped out] All right ... I believe we have a problem with opaqueness / lack of transparency in the Maven core. It would appear we have a few rather evident issues that we would need to handle sooner, rather than later. Let me make a few suggestions here: a) *Suggestion:* perscribe / use / enforce some rudimentary design patterns for the Maven core. *Purpose:* increase code quality, facilitate understanding *Benefit:* increase the informed developer base to increase improvement influx to the project. We simply need more folks who cares enough to make improvement suggestions and patches. Some parts of the core certainly could use some TLC. I'll take a shot at some initial design patterns in a following posting to the list. Everyone are encouraged to provide suggestions before or after mine hit the list. b) *Suggestion:* Refactor the Plugin structure, simplify plugin testing, provide more specific Abstract plugin classes that encapsulate common problems. *Purpose:* Increase development pace and quality of plugin development. *Benefit:* Reduce the number of unmaintained plugins. Reduce the barrier to develop and maintain plugins. Increase quality of plugins. I have developed a number of plugins for quite a few projects lately. Each of these projects have developed their own custom plugin framework with inhouse abstract classes and testing frameworks... since the plugin framework and testing structure provided by in Maven has proven inadequate or overly complex for some reason. I'll take a shot at suggesting improvements in an upcoming posting to the list. Everyone are encouraged to provide suggestions before or after mine hit the list. -- Best regards, Lennart Jörelid
