Directory layout, and overriding goals...

[dv...@clever-age.com]

Hi all,

I'm working on an aggregator plugin as all of my projects are splitted in
multiple parts (not sub projects). My long term goal is to replace the
xdoc plugin by a forrest-enabled one plugin.
I'm facing two global problems in maven design.

1) It seems that not all the plugin do use the plugin context that is
offered to them via the current building project object model. Some of
them do for example access the maven.gen.docs directly. Is this normal ???
Does this way of accessing maven.gen.docs do internaly/implicitelly use
the plugin context ??? Or at contrary is this a global setting for the
current pom ???
What i would like to propose is to have a DirectoryLayout object per
plugin. A DirectoryLayout would have generic named physical locations. For
instance most if not all of the plugins do have a source, work, and ouput
(or generated)...
This would give each plugin clear informations about where they can find
information they need to process, where to put generated content...
This would also enable a cleaner pipelining between each plugin. And more
over this would enable to extend more easily Maven's plugin relationships.
As i see it, with DirectoryLayout, i could easily configure my aggregator
to say things like:
"
- I want an "overall" javadoc with package groups for each project part, and
- I want "separated" xref for each project part
"

Then separated artifacts would be aggregated on per-type basis or per-part
basis. For example, if parts of my projects are apis, implementation, and
examples, aggregation of separated artifacts on per-type basis:
Reports
-- ...
-- Source Xref
----- APIs
----- Implementation
----- Examples
-- ...

aggregation of separated artifacts on per-part basis:

Reports
-- ...
-- APIs
----- Source Xref
----- ...
-- Implementation
----- Source Xref
----- ...
-- Examples
----- Source Xref
----- ...
-- ...

2) It seems that werks do not provide any mean to replace a goal. So what
if i want to replace xdoc plugin with another plugin when all the other
plugins refers to it.
What i propose here is generic empty goals for major phases of the maven
build process. Like so, xdoc would be written with preGoals and postGoals
rather than normal goals.
Like this, another doc plugin could be loaded instead of xdoc. Loading of
the plugin would add postGoals to the generic documentation phases goals
and implement the different jelly tags required by other plugins. And then
the other plugins would just do as now without any problems.
Does anyone has any ideas to resolve those two issues???
Thanks for your comments. A+. Didier.



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org

Re: Directory layout, and overriding goals...

[Jason van Zyl <ja...@zenplex.com>]

On Fri, 2003-04-11 at 10:56, dvillevalois@clever-age.com wrote:
> Hi all,
> 
> I'm working on an aggregator plugin as all of my projects are splitted in
> multiple parts (not sub projects). My long term goal is to replace the
> xdoc plugin by a forrest-enabled one plugin.
> I'm facing two global problems in maven design.
> 
> 1) It seems that not all the plugin do use the plugin context that is
> offered to them via the current building project object model. Some of
> them do for example access the maven.gen.docs directly. Is this normal ???

Some of the plugins vary but the property should be defined in one place
and the value should be retrieved from that one place. In the case of
maven.gen.docs, that value is defined in the xdoc plugin so the value
should be retrieved from there. If some plugins still define their own
maven.gen.docs that needs to be corrected.

> Does this way of accessing maven.gen.docs do internaly/implicitelly use
> the plugin context ??? Or at contrary is this a global setting for the
> current pom ???

Sorry, what was that? By using the plugin context we're just grabbing
the plugin object which contains properties as defined
plugin.properties.

${pom.getPluginContext('maven-xdoc-plugin').getVariable('maven.gen.docs')}

Is what is standard way.

> What i would like to propose is to have a DirectoryLayout object per
> plugin. A DirectoryLayout would have generic named physical locations. For
> instance most if not all of the plugins do have a source, work, and ouput
> (or generated)...

If you are talking about a different structure for the layout of a
plugin then -1. These are for the plugin sources. If you're talking
about where resultant artifacts are placed as a result of the plugins
action then that's not impossible at this stage either.

> This would give each plugin clear informations about where they can find
> information they need to process, where to put generated content...

This is all fairly standard now. There is a plugin-resources directory
where all resources for plugin are placed. That's the standard place and
I would be very loath to change that.

> This would also enable a cleaner pipelining between each plugin. And more
> over this would enable to extend more easily Maven's plugin relationships.
> As i see it, with DirectoryLayout, i could easily configure my aggregator
> to say things like:
> "
> - I want an "overall" javadoc with package groups for each project part, and
> - I want "separated" xref for each project part
> "
> 
> Then separated artifacts would be aggregated on per-type basis or per-part
> basis. For example, if parts of my projects are apis, implementation, and
> examples, aggregation of separated artifacts on per-type basis:
> Reports
> -- ...
> -- Source Xref
> ----- APIs
> ----- Implementation
> ----- Examples
> -- ...
> 
> aggregation of separated artifacts on per-part basis:
> 
> Reports
> -- ...
> -- APIs
> ----- Source Xref
> ----- ...
> -- Implementation
> ----- Source Xref
> ----- ...
> -- Examples
> ----- Source Xref
> ----- ...
> -- ...

This I could probably do with what's available now, but I'm all for more
clarity.

> 2) It seems that werks do not provide any mean to replace a goal. So what
> if i want to replace xdoc plugin with another plugin when all the other
> plugins refers to it.

That's a bug. You should be able to replace a goal if you so desire.

> What i propose here is generic empty goals for major phases of the maven
> build process. Like so, xdoc would be written with preGoals and postGoals
> rather than normal goals.

Yes, you want a join point basically. We've discussed briefly though I'm
not sure if this is really necessary. If you don't want to use the
current xdoc plugin then you could change your <reports/> element to
simply point at another plugin of your own creation to do the processing
you wish. You could use any of the existing goals in the xdoc plugin so
you don't have to write the whole thing over again. I think for the most
part your use-case will be the exception. Especially when we provide
tools that work in a more reactor friendly way.

This would work now, as for a more complicated AOP approach ... not sure
it's required to be honest.

> Like this, another doc plugin could be loaded instead of xdoc. Loading of
> the plugin would add postGoals to the generic documentation phases goals
> and implement the different jelly tags required by other plugins. And then
> the other plugins would just do as now without any problems.

For fun I will try and work through your use case above as an example.

> Does anyone has any ideas to resolve those two issues???
> Thanks for your comments. A+. Didier.
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
-- 
jvz.

Jason van Zyl
jason@zenplex.com
http://tambora.zenplex.org

In short, man creates for himself a new religion of a rational
and technical order to justify his work and to be justified in it.
  
  -- Jacques Ellul, The Technological Society


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org