On 2010-11-01 23:12, Jason van Zyl wrote: > On Nov 1, 2010, at 11:01 PM, Dennis Lundberg wrote: > >> On 2010-11-01 22:48, Jason van Zyl wrote: >>> On Nov 1, 2010, at 10:41 PM, Dennis Lundberg wrote: >>> >>>> On 2010-11-01 13:41, Jason van Zyl wrote: >>>>> In much the same way we have a little sub-project for releasing I think >>>>> it's time to have one for the site generation. Take the maven-site-plugin >>>>> and any related plugins and move them into their own tree. What I'm >>>>> trying to do here is cull the set of plugins we have is to keep the ones >>>>> that are part of the core lifecycles and super popular plugins that get >>>>> maintained like the dependency plugin and enforcer plugin. >>>> >>>> I'm not sure I understand what we would gain by doing this, if we cull >>>> all the dead/inactive plugins. Can you elaborate some more? >>>> >>> >>> That we have a set of plugins that is actively maintained, released more on >>> a regular basis. Reduce the surface area of what we have to make great >>> because we honestly don't do a great job of releasing core plugins often >>> enough. We should focus on the plugins in the core lifecycles, and we >>> should be doing this well. Anything else we should really let a community >>> have better access to and push it out to Mojo or Github. Plugins that are >>> here people naturally, for whatever reason, assume we actively maintain >>> them and we don't. I would rather do fewer things well. >> >> I agree with you that we need to be able to support the stuff that we >> house. If we can't maintain it we need to let it go. >> >> But what has that got to do with site generation and reporting plugins? >> > > First, to fully decouple build from site. That I'm not saying to nuke those > plugins but to separation. Look how easy the plugins themselves conflate > concerns and look how easily we polluted the core with site generating and > reporting. I think fully separation of the housing of the plugins and the > logic within plugins is a good separation of concerns. Additionally I think > we can all agree that the build related plugins are an absolute must to > maintain. I for one think the site plugin will see it's demise with static > documentation being sourced from wikis a la WikiModel and projects like > WikiText at Eclipse and trending information being produced by Sonar. That's > just my opinion, but the separation of concerns I believe is reason enough to > separate them. Is this not exactly what we did the release tooling? I think > it only follows what we've already started.
The separation of concerns is a worthy goal. Like I wrote in another mail I think some B+R plugins have their build and reporting code intertwined. Splitting that up might be difficult and we could end up with a bunch of new shared components, say for example a checkstyle-commons. Before we decide how to store the plugins in an SCM, we should work through the "tainted" plugins one at a time, and try to split build from reporting. The result of the split might look different than we first expected it to. When it comes to the importance and future we have different opinions, but then again that is nothing new :) >>> >>>>> Thanks, >>>>> >>>>> Jason >>>>> >>>>> ---------------------------------------------------------- >>>>> Jason van Zyl >>>>> Founder, Apache Maven >>>>> http://twitter.com/jvanzyl >>>>> --------------------------------------------------------- >>>>> >>>>> You are never dedicated to something you have complete confidence in. >>>>> No one is fanatically shouting that the sun is going to rise tomorrow. >>>>> They know it is going to rise tomorrow. When people are fanatically >>>>> dedicated to political or religious faiths or any other kind of >>>>> dogmas or goals, it's always because these dogmas or >>>>> goals are in doubt. >>>>> >>>>> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Dennis Lundberg >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> Thanks, >>> >>> Jason >>> >>> ---------------------------------------------------------- >>> Jason van Zyl >>> Founder, Apache Maven >>> http://twitter.com/jvanzyl >>> --------------------------------------------------------- >>> >>> the course of true love never did run smooth ... >>> >>> -- Shakespeare >>> >>> >>> >>> >> >> >> -- >> Dennis Lundberg >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > --------------------------------------------------------- > > Our achievements speak for themselves. What we have to keep track > of are our failures, discouragements and doubts. We tend to forget > the past difficulties, the many false starts, and the painful > groping. We see our past achievements as the end result of a > clean forward thrust, and our present difficulties as > signs of decline and decay. > > -- Eric Hoffer, Reflections on the Human Condition > > > > -- Dennis Lundberg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
