You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Jason van Zyl <ja...@maven.org> on 2010/11/01 13:41:35 UTC
Moving all reporting to a site project
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.
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
Re: Moving all reporting to a site project
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-11-01 23:18, 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?
>>
>
> Additionally I think it would be stellar if we had core build lifecycle plugins, heavily used but not lifecycle related, and the site stuff. Augment the release tooling so that we could make consistent releases across a tree for plugins that have changed on a known 6 week cycle. The release plugin would have to be changed but this would make it easier to prepare for a release cycle, and push out all related plugins together. Then users will come to expect these regular release cycles which I think have been a great benefit at Eclipse whose process I'm copying. Projects are not allowed to survive very long missing release schedules in the real world. Even though this is an open source project we can do the same. We simply reduce the surface to the size we can honestly manage that process. It's more honest and better for users.
This is interesting stuff. Can you start a new thread about this, so it
doesn't get buried here in this site/reporting thread. Perhaps a
proposal in Confluence?
>
>>>
>>>>> 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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
>
> -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
>
>
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving all reporting to a site project
Posted by Jason van Zyl <ja...@maven.org>.
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?
>
Additionally I think it would be stellar if we had core build lifecycle plugins, heavily used but not lifecycle related, and the site stuff. Augment the release tooling so that we could make consistent releases across a tree for plugins that have changed on a known 6 week cycle. The release plugin would have to be changed but this would make it easier to prepare for a release cycle, and push out all related plugins together. Then users will come to expect these regular release cycles which I think have been a great benefit at Eclipse whose process I'm copying. Projects are not allowed to survive very long missing release schedules in the real world. Even though this is an open source project we can do the same. We simply reduce the surface to the size we can honestly manage that process. It's more honest and better for users.
>>
>>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.
-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
Re: Moving all reporting to a site project
Posted by Stephen Connolly <st...@gmail.com>.
On 1 November 2010 22:26, Dennis Lundberg <de...@apache.org> wrote:
> 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.
+1 on this. I would rather work on splitting the B+R concerns and
then spin out the reporting, than push out the B+R plugins and have to
pull back in stuff which we really should
>
> When it comes to the importance and future we have different opinions,
> but then again that is nothing new :)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving all reporting to a site project
Posted by Dennis Lundberg <de...@apache.org>.
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: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>
>>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving all reporting to a site project
Posted by Jason van Zyl <ja...@maven.org>.
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.
>>
>>>> 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: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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
Re: Moving all reporting to a site project
Posted by Dennis Lundberg <de...@apache.org>.
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?
>
>>> 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: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving all reporting to a site project
Posted by Jason van Zyl <ja...@maven.org>.
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.
>> 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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
the course of true love never did run smooth ...
-- Shakespeare
Re: Moving all reporting to a site project
Posted by Dennis Lundberg <de...@apache.org>.
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?
> 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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving all reporting to a site project
Posted by Hervé BOUTEMY <he...@free.fr>.
Le lundi 1 novembre 2010, Jason van Zyl a écrit :
> I think they are primarily used as site plugin and as such they should move
> with the site plugin. I agree there is a conflation of concerns. If
> someone wants to decouple build logic from reporting logic that would be
> great.
AFAIK, code for simultaneous build+reporting logic has been factored out in
AbstractMavenReport in maven-reporting-impl [1]
even if few plugins have integrated this base class
HTH
Regards
Hervé
[1] http://maven.apache.org/shared/maven-reporting-
impl/apidocs/org/apache/maven/reporting/AbstractMavenReport.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving all reporting to a site project
Posted by Jason van Zyl <ja...@maven.org>.
On Nov 1, 2010, at 6:37 PM, Brett Porter wrote:
> +1 to consolidating the site stuff (under doxia?)
>
> -0 to moving plugins that have non-site-specific capabilities (pmd, checkstyle, etc.). Though these could be in a separate plugins tree for "tool support", if they aren't going to be held by the official projects.
>
I think they are primarily used as site plugin and as such they should move with the site plugin. I agree there is a conflation of concerns. If someone wants to decouple build logic from reporting logic that would be great.
> On 01/11/2010, at 9:42 AM, Olivier Lamy wrote:
>
>> +1.
>> I can be a volunteer for site stuff..
>>
>> Question : what do we do with site plugin 2.x and 3.x branch ?
>>
>> Personnally : I'd like to move only 3.x branch in this new project.
>>
>>
>> 2010/11/1 Jason van Zyl <ja...@maven.org>:
>>> 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.
>>>
>>> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> http://twitter.com/olamy
>> http://www.linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> --
> Brett Porter
> brett@apache.org
> http://brettporter.wordpress.com/
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Simplex sigillum veri. (Simplicity is the seal of truth.)
Re: Moving all reporting to a site project
Posted by Brett Porter <br...@apache.org>.
+1 to consolidating the site stuff (under doxia?)
-0 to moving plugins that have non-site-specific capabilities (pmd, checkstyle, etc.). Though these could be in a separate plugins tree for "tool support", if they aren't going to be held by the official projects.
On 01/11/2010, at 9:42 AM, Olivier Lamy wrote:
> +1.
> I can be a volunteer for site stuff..
>
> Question : what do we do with site plugin 2.x and 3.x branch ?
>
> Personnally : I'd like to move only 3.x branch in this new project.
>
>
> 2010/11/1 Jason van Zyl <ja...@maven.org>:
>> 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.
>>
>> 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
>>
>>
>>
>>
>
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy
> http://www.linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving all reporting to a site project
Posted by Jason van Zyl <ja...@maven.org>.
Your call, you're doing the work. Not sure we have any precedent, but I imagine full support of the site plugin will require patches the 2.x version.
On Nov 1, 2010, at 2:42 PM, Olivier Lamy wrote:
> +1.
> I can be a volunteer for site stuff..
>
> Question : what do we do with site plugin 2.x and 3.x branch ?
>
> Personnally : I'd like to move only 3.x branch in this new project.
>
>
> 2010/11/1 Jason van Zyl <ja...@maven.org>:
>> 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.
>>
>> 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
>>
>>
>>
>>
>
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy
> http://www.linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
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
Re: Moving all reporting to a site project
Posted by Dennis Lundberg <de...@apache.org>.
On 2010-11-01 22:33, Jason van Zyl wrote:
> On Nov 1, 2010, at 2:42 PM, Olivier Lamy wrote:
>
>> +1.
>> I can be a volunteer for site stuff..
>>
>> Question : what do we do with site plugin 2.x and 3.x branch ?
>>
>> Personnally : I'd like to move only 3.x branch in this new project.
>>
>>
>
> I would suggest these are the plugins that go as part of the site generation:
To see which plugins are on the table go to
http://maven.apache.org/plugins/index.html
and check the "Type" column. If a plugin has an "R" in that column it is
site related.
Plugins that have "B+R" can be difficult to divide into two plugins in
an easy way. Parts of the code is shared between the "build" part and
the "reporting" part of the plugin. If the code is splitable, the
reporting part could form a new plugin called "Old Name *Report*
Plugin", like we have for Surefire.
> maven-changelog-plugin
> maven-changes-plugin
No sure how to handle the announcement stuff in there.
> maven-checkstyle-plugin
Contains possible build-breaking hooks.
> maven-doap-plugin
> maven-javadoc-plugin
For me this is part of the build as much as it is the site, since we
attach the javadocs when deploying artifacts.
> maven-linkcheck-plugin
> maven-pdf-plugin
> maven-pmd-plugin
Contains possible build-breaking hooks.
> maven-project-info-reports-plugin
> maven-site-plugin
> maven-source-plugin
Has nothing to do with the site.
>
>> 2010/11/1 Jason van Zyl <ja...@maven.org>:
>>> 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.
>>>
>>> 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
>>>
>>>
>>>
>>>
>>
>>
>>
>> --
>> Olivier Lamy
>> http://twitter.com/olamy
>> http://www.linkedin.com/in/olamy
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder, Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
>
>
>
>
--
Dennis Lundberg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving all reporting to a site project
Posted by Jason van Zyl <ja...@maven.org>.
Yup. Cut/paste error.
On Nov 1, 2010, at 10:49 PM, Benjamin Bentmann wrote:
> Jason van Zyl wrote:
>
>> I would suggest these are the plugins that go as part of the site generation:
>> [...]
>> maven-source-plugin
>
> I think the maven-source-plugin is misclassified here, it doesn't have any reporting code.
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: Moving all reporting to a site project
Posted by Benjamin Bentmann <be...@udo.edu>.
Jason van Zyl wrote:
> I would suggest these are the plugins that go as part of the site generation:
> [...]
> maven-source-plugin
I think the maven-source-plugin is misclassified here, it doesn't have
any reporting code.
Benjamin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving all reporting to a site project
Posted by Jason van Zyl <ja...@maven.org>.
On Nov 1, 2010, at 2:42 PM, Olivier Lamy wrote:
> +1.
> I can be a volunteer for site stuff..
>
> Question : what do we do with site plugin 2.x and 3.x branch ?
>
> Personnally : I'd like to move only 3.x branch in this new project.
>
>
I would suggest these are the plugins that go as part of the site generation:
maven-changelog-plugin
maven-changes-plugin
maven-checkstyle-plugin
maven-doap-plugin
maven-javadoc-plugin
maven-linkcheck-plugin
maven-pdf-plugin
maven-pmd-plugin
maven-project-info-reports-plugin
maven-site-plugin
maven-source-plugin
> 2010/11/1 Jason van Zyl <ja...@maven.org>:
>> 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.
>>
>> 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
>>
>>
>>
>>
>
>
>
> --
> Olivier Lamy
> http://twitter.com/olamy
> http://www.linkedin.com/in/olamy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------
Re: Moving all reporting to a site project
Posted by Olivier Lamy <ol...@apache.org>.
+1.
I can be a volunteer for site stuff..
Question : what do we do with site plugin 2.x and 3.x branch ?
Personnally : I'd like to move only 3.x branch in this new project.
2010/11/1 Jason van Zyl <ja...@maven.org>:
> 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.
>
> 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
>
>
>
>
--
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Moving all reporting to a site project
Posted by Arnaud Héritier <ah...@gmail.com>.
+1
On Nov 1, 2010, at 1:41 PM, 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.
>
> 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
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org