The problem with another group-id is that it then cannot be searched for
as default, so it's no longer mvn javadoc:javadoc, thats something I
want to avoid - it just confuses the user. Marking my local repo as a
proxy, when it isn't looks dangeriou, or maybe I'm misunderstanding.
How long till my fix will be rolled into the javadoc plugin, and plugin
released? I'd saving having a b0rked javadoc doclet plugin is good
enough reason for a quick update :)
Mark
Carlos Sanchez wrote:
i think in that doc it says that it can't be in two repos and you need
to use a proxy (so the maven-metadata.xml is merged)
or you put your plugin under another groupId, which should be the most
correct solution
On 3/14/07, Mark Proctor <[EMAIL PROTECTED]> wrote:
After finding a bug I'm trying to make our build system work with a
patched version of the javadoc plugin, as discussed here
http://docs.codehaus.org/display/MAVENUSER/Patching+Maven+Plugins.
I have changed the pom of the patched javadoc plugin from 2.2 to
2.2-INTERNAL-r502215, the parent pom is still 8-SNAPSHOT. I have placed
the patched dependency in the local build system and updated the plugin
in the project pom.xml to use the INTERNAL version, but it still insists
on downloading and installing 2.2
Here is the pom.xml
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/pom.xml
Here is the location of the patched dependency:
http://anonsvn.labs.jboss.com/labs/jbossrules/trunk/repository/org/apache/maven/plugins/maven-javadoc-plugin/2.2-INTERNAL-r502215/
It is checkout as part of the main project which has a "repository"
directory. Which is made available with the following two settings:
<repository>
<id>basedir</id>
<url>file://${basedir}/repository</url>
</repository>
and
<pluginRepository>
<id>basedir</id>
<url>file://${basedir}/repository</url>
</pluginRepository>
This works for all the other dependencies that are local repository
directory.
Mark
Mark Proctor wrote:
> I have discovered the bug, logged it and provided a fix. please fix
> and release asap :)
> http://jira.codehaus.org/browse/MJAVADOC-115
>
> Mark
> Mark Proctor wrote:
>> I'm trying to use the javadoc plugin with ydoc. If I specify the jars
>> as artifiacts it cannot use the docletPath setting to find the
>> resources directory, as its one or the other:
>>
>> *if* ( ( docletArtifact != *null* ) && (
>> StringUtils.isNotEmpty( docletArtifact.getGroupId() ) )
>> && ( StringUtils.isNotEmpty(
>> docletArtifact.getArtifactId() ) )
>> && ( StringUtils.isNotEmpty( docletArtifact.getVersion() )
>> ) )
>> {
>> path.append( getArtifactAbsolutePath( docletArtifact ) );
>> }
>> *else* *if* ( docletArtifacts != *null* )
>> {
>> *for* ( *int* i = 0; i < docletArtifacts.length; i++ )
>> {
>> *if* ( docletArtifacts[i] != *null* )
>> {
>> path.append( getArtifactAbsolutePath(
>> docletArtifacts[i] ) );
>>
>> *if* ( i < docletArtifacts.length - 1 )
>> {
>> path.append( File.pathSeparator );
>> }
>> }
>> }
>> }
>> *else*
>> {
>> path.append( docletPath );
>> }
>>
>> *if* ( StringUtils.isEmpty( path.toString() ) )
>> {
>> getLog().warn(
>> *"No docletpath option was found. Please
>> review <docletpath/> or <docletArtifact/>"*
>> + *" or <doclets/>."* );
>> }
>>
>> Maybe docletPath should be allowed ontop of artifacts? Also the
>> extdirs property is not used anywhere, shouldn't that get put into
>> the put onto the path?
>>
>> If I don't specify any artifacts and instead put everything into
>> <docletPath> then I always get the error at the end,
>> it's like the docletPath value is not getting injected.
>>
>> Mark
>>
>>
>>
>>
>
>
> ---------------------------------------------------------------------
> 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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
