Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-15 Thread Brett Porter
Wendy Smoak wrote:
 Not to mention that it's an interface, so instantiating it would be
 pretty difficult.

Right, though a converter would know to instantiate a useful
implementation using an artifactFactory.

 No problem... though it does seem like duplication, I think because
 DefaultArtifact exists.  But this isn't really _the_ Artifact, it's
 just a container for the properties that will be used to create it.  I
 think.  (First plugin... still trying to figure this all out.)

I actually agree. I'd prefer Artifact to be a bean. It has too much
functionality and indeterminate state right now.

 One more question.  Your factory.createArtifact(...) call is missing
 the 'scope' parameter.  Do I just hard-code it like the type?
 
 Artifact artifact = factory.createArtifact( 
 docletArtifact.getGroupId(),
docletArtifact.getArtifactId(),
 docletArtifact.getVersion(), compile, jar );

There are some constants on the Artifact interface you can use for
scope. I think null is actually a valid scope here.

 
 Thanks.  I suppose you're going to want to see a patch after doing all
 this work. :)

Please! :D

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-14 Thread Wendy Smoak
On 1/10/06, Brett Porter [EMAIL PROTECTED] wrote:

 docletArtifact
   groupIdumlgraph/groupId
   artifactIdumlgraph/artifactId
   version4.2/version
 /docletArtifact

 Then in the javadoc plugin:

 /** @component */
 private ArtifactResolver resolver;

 /** @component */
 private ArtifactFactory factory;

 /** @parameter expression=${localRepository} */
 private ArtifactRepository localRepository;

 /** @parameter expression=${project.remoteArtifactRepositories} */
 private List remoteRepositories;

What about the declaration for docletArtifact itself?  What type
should it be?  I would think, 'Artifact' except that you wrote:

 Artifact artifact = factory.createArtifact( docletArtifact.getGroupId(),
 docletArtifact.getArtifactId(), docletArtifact.getVersion(), jar );

And yet... all the methods you're calling on docletArtifact look like
the ones from the Artifact interface.  I'm lost.  How does this work?

I think all I'm missing is this part and it should just work:

/** @something */
private SomeType docletArtifact;

 I did this recently in the site plugin for skins as an example. It takes
 care of all the repository stuff. Any volunteers to write this up as a
 howto? :)

I'm looking at SiteMojo.java but can't quite match up the pieces.

Thanks,
--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-14 Thread Brett Porter
Wendy Smoak wrote:
 What about the declaration for docletArtifact itself?  What type
 should it be?  I would think, 'Artifact' except that you wrote:
 
 Artifact artifact = factory.createArtifact( docletArtifact.getGroupId(),
 docletArtifact.getArtifactId(), docletArtifact.getVersion(), jar );
 
 And yet... all the methods you're calling on docletArtifact look like
 the ones from the Artifact interface.  I'm lost.  How does this work?

There is no plexus configuration handler for the Artifact type. So it
can't create it (you could pass implementation=o.a.m.a.DefaultArtifact,
but it has no default constructor so in this case it won't work and
that's verbose in the POM anyway).

You need to create your own class in the same package as the plugin with
the given fields. Sorry I omitted that information :)

 I'm looking at SiteMojo.java but can't quite match up the pieces.

Actually, I just remembered though I did this originally, I moved the
configuration of the skin out to the site descriptor, so its different
for configuring (though the usage is the same).

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-14 Thread Wendy Smoak
On 1/14/06, Brett Porter [EMAIL PROTECTED] wrote:

  And yet... all the methods you're calling on docletArtifact look like
  the ones from the Artifact interface.  I'm lost.  How does this work?

 There is no plexus configuration handler for the Artifact type.

Not to mention that it's an interface, so instantiating it would be
pretty difficult.

 You need to create your own class in the same package as the plugin with
 the given fields. Sorry I omitted that information :)

No problem... though it does seem like duplication, I think because
DefaultArtifact exists.  But this isn't really _the_ Artifact, it's
just a container for the properties that will be used to create it.  I
think.  (First plugin... still trying to figure this all out.)

One more question.  Your factory.createArtifact(...) call is missing
the 'scope' parameter.  Do I just hard-code it like the type?

Artifact artifact = factory.createArtifact( docletArtifact.getGroupId(),
   docletArtifact.getArtifactId(),
docletArtifact.getVersion(), compile, jar );

Thanks.  I suppose you're going to want to see a patch after doing all
this work. :)

--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-10 Thread Wendy Smoak
(Moving this to from user@ to dev@)

I'm trying to use an alternate doclet, and I tried to configuring the
javadoc plugin,
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
configuration
   docletgr.spinellis.umlgraph.doclet.UmlGraph/doclet
 
docletPathc:\java\m2-repository\umlgraph\UMLGraph\4.2-SNAPSHOT\UMLGraph-4.2-SNAPSHOT.jar/docletPath
additionalParam-views/additionalParam
/configuration
 /plugin

 But I get:
[INFO] An error has occurred in JavaDocs report generation.
Embedded error: Exit code: 1 - javadoc: error - invalid flag: -sourcePath

The usage information that prints out includes:
-sourcepath pathlist Specify where to find the source files

Making the following change in JavadocReport.java fixes the problem:

-addArgIfNotEmpty( arguments, -sourcePath,
quotedPathArgument( sourcePath.toString() ) );
+addArgIfNotEmpty( arguments, -sourcepath,
quotedPathArgument( sourcePath.toString() ) );

Do you consider this is a problem with the UMLGraph doclet, or with
the Javadoc plugin?

Thanks,
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-10 Thread Brett Porter
javadoc problem (maybe it is already fixed?)

Also, I think the doclet path should be an artifact reference instead,
which could be added as a plugin dependency.

- Brett

Wendy Smoak wrote:
 (Moving this to from user@ to dev@)
 
 I'm trying to use an alternate doclet, and I tried to configuring the
 javadoc plugin,
 plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-javadoc-plugin/artifactId
 configuration
docletgr.spinellis.umlgraph.doclet.UmlGraph/doclet
  
 docletPathc:\java\m2-repository\umlgraph\UMLGraph\4.2-SNAPSHOT\UMLGraph-4.2-SNAPSHOT.jar/docletPath
 additionalParam-views/additionalParam
 /configuration
  /plugin
 
  But I get:
 [INFO] An error has occurred in JavaDocs report generation.
 Embedded error: Exit code: 1 - javadoc: error - invalid flag: -sourcePath
 
 The usage information that prints out includes:
 -sourcepath pathlist Specify where to find the source files
 
 Making the following change in JavadocReport.java fixes the problem:
 
 -addArgIfNotEmpty( arguments, -sourcePath,
 quotedPathArgument( sourcePath.toString() ) );
 +addArgIfNotEmpty( arguments, -sourcepath,
 quotedPathArgument( sourcePath.toString() ) );
 
 Do you consider this is a problem with the UMLGraph doclet, or with
 the Javadoc plugin?
 
 Thanks,
 Wendy
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-10 Thread Wendy Smoak
On 1/10/06, Brett Porter [EMAIL PROTECTED] wrote:

 javadoc problem (maybe it is already fixed?)

Today, apparently!  Sorry for the noise.

 Also, I think the doclet path should be an artifact reference instead,
 which could be added as a plugin dependency.

Can you expand on that? :)  I gather this would keep me from having to
give the path to the jar file (which is obviously not portable, but I
was in just make it work mode at that point.)

--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-10 Thread Brett Porter
Wendy Smoak wrote:
 Can you expand on that? :)  I gather this would keep me from having to
 give the path to the jar file (which is obviously not portable, but I
 was in just make it work mode at that point.)

Yep, exactly.

eg:
docletArtifact
  groupIdumlgraph/groupId
  artifactIdumlgraph/artifactId
  version4.2/version
/docletArtifact

Then in the javadoc plugin:

/** @component */
private ArtifactResolver resolver;

/** @component */
private ArtifactFactory factory;

/** @parameter expression=${localRepository} */
private ArtifactRepository localRepository;

/** @parameter expression=${project.remoteArtifactRepositories} */
private List remoteRepositories;

...

Artifact artifact = factory.createArtifact( docletArtifact.getGroupId(),
docletArtifact.getArtifactId(), docletArtifact.getVersion(), jar );

resolver.resolve( artifact, remoteRepositories, localRepository );

String docletPath = artifact.getFile().getAbsolutePath();

I did this recently in the site plugin for skins as an example. It takes
care of all the repository stuff. Any volunteers to write this up as a
howto? :)

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-10 Thread Wendy Smoak
On 1/10/06, Brett Porter [EMAIL PROTECTED] wrote:

 I did this recently in the site plugin for skins as an example. It takes
 care of all the repository stuff. Any volunteers to write this up as a
 howto? :)

Thanks!  Before I go too much further... is this going to work?  At
this point I've reconfigured the javadoc plugin, and UMLGraph is
producing the .dot files, but now I've lost the normal html
Javadoc.  Can I get the maven-javadoc-plugin to run twice during the
build?

Thanks,
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-10 Thread Brett Porter
there's two paths to take here - put it with the users to define
multiple executions (this can be done with reportSets if it is part of
the reporting section), or allow multiple doclets to be given in the
javadoc configuration and do the rerun there.

Since different doclets probably change other options, I'm inclined to
go with the first.

- Brett

Wendy Smoak wrote:
 On 1/10/06, Brett Porter [EMAIL PROTECTED] wrote:
 
 I did this recently in the site plugin for skins as an example. It takes
 care of all the repository stuff. Any volunteers to write this up as a
 howto? :)
 
 Thanks!  Before I go too much further... is this going to work?  At
 this point I've reconfigured the javadoc plugin, and UMLGraph is
 producing the .dot files, but now I've lost the normal html
 Javadoc.  Can I get the maven-javadoc-plugin to run twice during the
 build?
 
 Thanks,
 Wendy
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-10 Thread Wendy Smoak
On 1/10/06, Brett Porter [EMAIL PROTECTED] wrote:
 there's two paths to take here - put it with the users to define
 multiple executions (this can be done with reportSets if it is part of
 the reporting section), or allow multiple doclets to be given in the
 javadoc configuration and do the rerun there.

 Since different doclets probably change other options, I'm inclined to
 go with the first.

I agree.  So I tried the reporting section, adding this:
   reporting
  plugins
 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
reportSets
   reportSet
  configuration
 docletgr.spinellis.umlgraph.doclet.UmlGraph/doclet

docletPathc:\java\m2-repository\umlgraph\UMLGraph\4.2-SNAPSHOT\UMLGraph-4.2-SNAPSHOT.jar/docletPath
 additionalParam-views/additionalParam
  /configuration
   /reportSet
/reportSets
 /plugin
  /plugins
   /reporting

The maven-model page says that the reports will be run when the user
executes 'maven site'. (so does that apply to m2?)

With 'mvn site', nothing Javadoc-related happens at all, just the
usual 'project info' type reports.  I do have a site.xml file with
${reporting} in it.  Do I have to add something somewhere else?

Thanks,
--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-10 Thread Brett Porter
You need:

reports
  reportjavadoc/report
/reports

Inside the report set.

I think this portion needs to be better documented, and should run all
reports by default (in contrast to build executions). Would you like to
file a JIRA for this?

- Brett

Wendy Smoak wrote:
 On 1/10/06, Brett Porter [EMAIL PROTECTED] wrote:
 there's two paths to take here - put it with the users to define
 multiple executions (this can be done with reportSets if it is part of
 the reporting section), or allow multiple doclets to be given in the
 javadoc configuration and do the rerun there.

 Since different doclets probably change other options, I'm inclined to
 go with the first.
 
 I agree.  So I tried the reporting section, adding this:
reporting
   plugins
  plugin
 groupIdorg.apache.maven.plugins/groupId
 artifactIdmaven-javadoc-plugin/artifactId
 reportSets
reportSet
   configuration
  docletgr.spinellis.umlgraph.doclet.UmlGraph/doclet
 
 docletPathc:\java\m2-repository\umlgraph\UMLGraph\4.2-SNAPSHOT\UMLGraph-4.2-SNAPSHOT.jar/docletPath
  additionalParam-views/additionalParam
   /configuration
/reportSet
 /reportSets
  /plugin
   /plugins
/reporting
 
 The maven-model page says that the reports will be run when the user
 executes 'maven site'. (so does that apply to m2?)
 
 With 'mvn site', nothing Javadoc-related happens at all, just the
 usual 'project info' type reports.  I do have a site.xml file with
 ${reporting} in it.  Do I have to add something somewhere else?
 
 Thanks,
 --
 Wendy
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-10 Thread Wendy Smoak
On 1/10/06, Brett Porter [EMAIL PROTECTED] wrote:
 You need:
 reports
   reportjavadoc/report
 /reports

 Inside the report set.

 I think this portion needs to be better documented, and should run all
 reports by default (in contrast to build executions). Would you like to
 file a JIRA for this?

Thanks for the tip on reports.  I'm not sure what you mean in the
second part, but if you'll tell me what code/section in JIRA I'll
paste that in.

Unfortunately, it's still not cooperating.  With this:

   reporting
  plugins
 plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-javadoc-plugin/artifactId
reportSets
   reportSet
  configuration
 docletgr.spinellis.umlgraph.doclet.UmlGraph/doclet

docletPathc:\java\m2-repository\umlgraph\UMLGraph\4.2-SNAPSHOT\UMLGraph-4.2-SNAPSHOT.jar/docletPath
 additionalParam-views/additionalParam
 destDirtarget/uml/destDir
  /configuration
  reports
 reportjavadoc/report
 /reports
   /reportSet
   !--reportSet
  configuration/
  reports
 reportjavadoc/report
 /reports
   /reportSet--
/reportSets
 /plugin
  /plugins
   /reporting

I get target/apidocs/graph.dot, plus the css and images.  I don't need
the css and images, and It's ignoring destDir.  There's a comment in
the javdoc plugin code about being in site-embedded report mode
which I assume is the case here, and it uses the directory that Doxia
has set, plus 'apidocs', always.

If I uncomment that second reportSet, which was intended to make it
generate the normal html Javadoc, then it does NOT generate the
graph.dot file anymore, it just runs the default html javadoc twice.

Was the javadoc plugin intended to be used this way?  If UMLGraph
really needs its own plugin, that's an acceptable answer.  But if this
is supposed to work, then I'll press on.

Thanks for your patience,
--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-10 Thread Brett Porter
Wendy Smoak wrote:
 Thanks for the tip on reports.  I'm not sure what you mean in the
 second part, but if you'll tell me what code/section in JIRA I'll
 paste that in.
 

I just meant that you might like to file a JIRA to say that omitting
reports/ in a reportSet should include all reports, not none. And
maybe one for documenting reportSets in the first place.

 I get target/apidocs/graph.dot, plus the css and images.  I don't need
 the css and images, and It's ignoring destDir.  There's a comment in
 the javdoc plugin code about being in site-embedded report mode
 which I assume is the case here, and it uses the directory that Doxia
 has set, plus 'apidocs', always.

I'd need to look into that in more detail. It really should accept your
configuration if you give it.

 
 If I uncomment that second reportSet, which was intended to make it
 generate the normal html Javadoc, then it does NOT generate the
 graph.dot file anymore, it just runs the default html javadoc twice.

Try adding an id / to one. Sorry if the output wasn't helpful here -
another jira issue!

 
 Was the javadoc plugin intended to be used this way?  If UMLGraph
 really needs its own plugin, that's an acceptable answer.  But if this
 is supposed to work, then I'll press on.

I thought the same thing myself. It would mean factoring out the javadoc
execution into a library used by both plugins. Really, it should be a
simple configuration so it should be the same plugin. I think you are on
the right track.

 
 Thanks for your patience,

Thanks for yours!

- Brett

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Re: [m2] Javadoc plugin - using alternate UMLGraph doclet?

2006-01-10 Thread Wendy Smoak
On 1/10/06, Brett Porter [EMAIL PROTECTED] wrote:

 I just meant that you might like to file a JIRA to say that omitting
 reports/ in a reportSet should include all reports, not none. And
 maybe one for documenting reportSets in the first place.

:)  I'll see if I can come up with some coherent requests tomorrow;
I'm about done for the night.

 I'd need to look into that in more detail. It really should accept your
 configuration if you give it.
...
 Try adding an id / to one. Sorry if the output wasn't helpful here -
 another jira issue!

That worked, thanks.  And the fact that both reportSets are going to
the same directory masks the issue with it copying in the css and
images when it runs the UMLGraph doclet.  Maybe I'll just call it a
feature and link to the .dot files from the generated images, like
they do on the UMLGraph site, so you can see how they were produced.
:)

The next part *will* require a plugin, I think... I have to execute
the Graphviz 'dot' executable on each of those .dot files that
UMLGraph generated, to get a .png file.

Thanks,
--
Wendy

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]