On Tuesday 16 Sep 2003 07:51, Andrew Stevens wrote:
> Well, I don't mind applying patches, but I don't use the maven plugin
> myself so the main problem is testing it. Same thing with Erik and that
> Struts stuff that came up in -user recently - it's not something he uses
> himself, and he's reluctant to change stuff he can't test. So long as
> you're happy to test stuff and answer any stupid questions I may have
> about stuff I think looks strange, then go for it.
I don't mind testing stuff if it fixes problems i've had :-)
> > To me there doesn't seem much point in
> > having something in your codebase if your not going to support it - and
> > similarly not much point in me generating a patch when you may ignore it
> > anyway since its for something you're not supporting :-(
>
> Which is the main reason we're separating out the plugins for XDoclet 2,
> in the hopes that vendors (or their own user communities) will create &
> maintain their own plugins.
Sounds like a good idea :-) Have we got any timescales on XDoclet2 ? (to give
me an idea of whether to leave plugin modifications til then)
> > I've raised various JIRA issues before (without patches, but with
> > specific details of what needed changing) and they are sat there. I could
> > easily write a patch for the maven plugin, but my patch would be to the
> > jelly file that is the plugin (since I'm familiar with jelly scripts etc)
> > ... but I gather you generate that :-) from some xdt file or something.
>
> It is indeed generated, so any patch would have to be to the template
> that generates it. If you could be a bit more specific about what you
> want to change in the output file, we can point you at the relevant bit
> of the template.
I've looked at the template ... and sadly everything useful is obfuscated out
elsewhere. In Maven we have goals which do things particular to particular
aspects of the software ... in this template it wants to copy blocks of text
the same for every goal (why ? all of the common stuff could have gone in a
Maven "init" goal and have this as the prereq of the other goals). If I want
to modify something for the jdodoclet goal I don't want to change things for
the ejbdoclet goal for example. How do I trace back to the individual goal ?
I'll give you a few examples of what I want to do ...
a). In the current 1.2b3 (or 1.2b4 if you use the version on the file), it has
a param with "Version" with capital V ... that should be lowercase v to be
consistent with the rest of XDoclet and its own docs. This features nowhere
in the template and is presumably from some other template ... but I don't
know where
b). In the template there is "${pom.build.sourceDirectory}". I want this to be
settable as a plugin parameter with it taking the
${pom.build.sourceDirectory}" as the default (in the resultant
plugin.properties). I cannot see the link between this template and where the
Maven files are generated - how do I get something in the plugin.properties
file that is generated ?.
c). There are inherent dependencies in XDoclet and it should load its own
dependencies itself (at the moment users have to put all sorts of seemingly
random dependencies of xdoclet jars in their project.xml, which is wrong) ...
The plugin does this with lines like setting up the classpath to include
<pathelement path="${plugin.getDependencyPath('xdoclet+xjavadoc')}"/>
however it ignores things like ejbdoclet at the moment. I want to do this
differently for each goal (no point loading ejbdoclet in the jdodoclet goal
!) ... the template won't currently allow that as it is now.
These 3 things would fix the majority of the problems people have had with the
Maven plugin.
--
Andy
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
xdoclet-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/xdoclet-devel
