maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Mismatch by inherited dependencies
Date Tue, 14 May 2013 09:29:44 GMT
When referencing bits of the pom.xml it is easier to reference the elements
via XPath as the pom.xml is XML and the easiest way to reference a
sub-element in XML is XPath.

If you look in your pom.xml at the XPath I suggested you will find that you
have a dependency on the javadoc plugin...

If you cannot find it I suggest you solve the following quadratic equation
and the line number is one of the roots

x^2 - 56x -1065

-Stephen


On 14 May 2013 10:15, Sven Bauhan <sven.bauhan@ast.dfs.de> wrote:

> Hmm, I don't know what you mean. I don't set any xpath explicitly.
> But I can attach the complete pom.
>
>
> On 05/14/13 10:48, Stephen Connolly wrote:
>
>> Well without seeing your parent tree's xpath:/project/dependencies and
>> your
>> project's xpath:/project/dependencies we cannot say anything as what you
>> have provided there should *never* end up on the transitive dependency
>> tree, so you are looking at the wrong part of the pom.
>>
>>
>> On 14 May 2013 09:39, Sven Bauhan <sven.bauhan@ast.dfs.de> wrote:
>>
>>  Ok, perhaps you can tell me what I did wrong.
>>> I included the javadoc plugin by:
>>>              <plugin>
>>> <groupId>org.apache.maven.****plugins</groupId>
>>> <artifactId>maven-javadoc-****plugin</artifactId>
>>>
>>>                  <version>2.9</version>
>>>                  <configuration>
>>>                      <author>false</author>
>>>                      <linksource>true</linksource>
>>> <docfilessubdirs>true</****docfilessubdirs>
>>>                      <sourceFileExcludes>
>>> <exclude>*Adapter*.java</****exclude>
>>> <exclude>*ObjectFactory.java</****exclude>
>>> <exclude>*ContextComponent.****java</exclude>
>>> <exclude>*Configuration.java</****exclude>
>>> <exclude>*SendController.java<****/exclude>
>>>                      </sourceFileExcludes>
>>> <sourcepath>${basedir}/src/****main/java/de/dfs/msg/atsm;${**
>>> basedir}/target/generated-****sources/xjc/de/dfs/msg/atsm</***
>>> *sourcepath>
>>>
>>>                  </configuration>
>>>                  <executions>
>>>                      <execution>
>>>                          <id>attach-javadocs</id>
>>>                          <goals>
>>>                              <goal>jar</goal>
>>>                          </goals>
>>>                      </execution>
>>>                  </executions>
>>>              </plugin>
>>>
>>> I did not define an explicit dependency to javadoc, but in "mvn
>>> dependency:tree" I can see it.
>>>
>>> Thanks, Sven
>>>
>>>
>>> On 05/14/13 10:18, Stephen Connolly wrote:
>>>
>>>  I think you are doing it wrong if you are adding <dependency> for
>>>> plugins.
>>>> The xpath:/project/dependencies are about specifying the classpath
>>>> dependencies during different scopes. The
>>>> xpath:/project/build/plugins/****plugin entries are about specifying
>>>> what
>>>>
>>>> build
>>>> tools to use when building the artifact... such build tools are not
>>>> passed
>>>> to dependent projects.
>>>>
>>>> I am 99.99999999999% certain that you have made a mistake adding
>>>> maven-javadoc-plugin as a dependency
>>>>
>>>>
>>>> On 14 May 2013 09:09, Sven Bauhan <sven.bauhan@ast.dfs.de> wrote:
>>>>
>>>>   Hi, I have another question:
>>>>
>>>>> I have two projects, one java library and a swing application using
>>>>> this
>>>>> library. For the library I use the apache maven-javadoc-plugin to
>>>>> create
>>>>> an
>>>>> API documentation, cause this library shall be used by various
>>>>> applications.
>>>>>
>>>>> The swing application has a dependency to this library and so it also
>>>>> gets
>>>>> an inherited dependency to the javadoc plugin. With this also log4j is
>>>>> inherited as dependency, but with an old version.
>>>>> In the application also log4j is used, but the latest version. So we
>>>>> have
>>>>> a version conflict.
>>>>>
>>>>> We could solve this yet by excluding the javadoc plugin in the
>>>>> dependency
>>>>> description:
>>>>>       <dependency>
>>>>>         <groupId>de.dfs.msg.atsm</******groupId>
>>>>>         <artifactId>atsm-camel</******artifactId>
>>>>>         <version>0.1-SNAPSHOT</******version>
>>>>>         <exclusions>
>>>>>           <exclusion>
>>>>>             <artifactId>maven-javadoc-******plugin</artifactId>
>>>>>             <groupId>org.apache.maven.******plugins</groupId>
>>>>>
>>>>>
>>>>>           </exclusion>
>>>>>         </exclusions>
>>>>>       </dependency>
>>>>> But this is not a good way to do, cause this has to be done by all
>>>>> applications using the library.
>>>>>
>>>>> Is there a way to define the dependency in the library pom not to be
>>>>> inherited?
>>>>> I saw there is a scope definition for dependencies, but I did not
>>>>> understand this concept yet. Would this be a solution?
>>>>>
>>>>> Thanks,
>>>>> Sven
>>>>>
>>>>>
>>>>> ------------------------------******--------------------------**--**
>>>>> --**---------
>>>>> To unsubscribe, e-mail: users-unsubscribe@maven.****apac**he.org<
>>>>> http://apache.org**>
>>>>> <users-unsubscribe@**maven.**apache.org <http://maven.apache.org><
>>>>> users-unsubscribe@**maven.apache.org<users-unsubscribe@maven.apache.org>
>>>>> >
>>>>>
>>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>  ------------------------------****----------------------------**
>>> --**---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apac**he.org<http://apache.org>
>>> <users-unsubscribe@**maven.apache.org<users-unsubscribe@maven.apache.org>
>>> >
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message