| Maven optional and test dependencies not needed [message #375618] |
Tue, 11 March 2008 07:11  |
Eclipse User |
|
|
|
Hi!
I try to "Buckminsterize" one of my Eclipse projects that uses dom4j, junit,
log4j and xml-apis. I decided to materialize these jars from a Maven
repository.
Because I have a simple Eclipse project with .project and .classpath I have
created a cspex with dependencies like this (for example to use junit 3.8.2
instead of 4.4):
....
<cs:dependency name="junit" versionDesignator="[3.8,4.0)"
versionType="OSGi"/>
<cs:dependency name="log4j"/>
<cs:dependency name="xml-apis"/>
....
Everything works great until I add dom4j to the dependencies.
ERROR [0003] : No suitable provider for component
stax/stax-ri/[1.0,1.1.0.a)#Triplet was found in searchPath default
(In the http://repo1.maven.org/maven2 repository dom4j has a lot of
dependencies which I don't need, one of them is stax and it seems to have a
bug in the dom4j POM.)
My first questions is: how to tell Buckminster that I do not need those
optional or test scoped dependencies from Maven?
The second question is theoretical: Suppose I have two or more Java projects
that depend on dom4j. How can I tell Buckminster to materialize dom4j in a
common place from where all of the project share the same file? Now I use
the same method as in org.demo.xml.provider and place the jars in a jars
folder of my project.
Best regards,
Gabor
|
|
|
|
|
| Re: Maven optional and test dependencies not needed [message #375656 is a reply to message #375655] |
Tue, 11 March 2008 18:20  |
| Eclipse User |
|
|
|
Kövér Gábor wrote:
>> You add an advisor node to the CQUERY where you declare that the component
>> should be skipped.
> Thanks for the tip. I'd prefer to put it in the component specification
> instead. I think it is something like prerequisite in Buckminster. (For
> example xalan and xerces only needs for testing but not for compiling and
> running dom4j.)
Buckminster can do this already. You can resolve based on an cspec attribute and "prune" the
resolution to only bring in what's needed in order to satisfy that attribute. You can define actions
or groups that are specific to test, compile, run, etc. and then prune your based on them.
The problem is often that the component specification that controls the dependencies in question are
out of reach. It might be several transitions away from a specification that you can control. Here
you do require dom4j, but you cannot alter the component specification for dom4j. We are
experimenting with "overlays" that would allow such alterations but it's not fully supported at this
point.
> This generates an other question:
> Although Buckminster seems to select the most appropriate version of a
> component, but when there is no single choice it materializes both
> componenst.
> For example for junit [3.8,4.0) and [3.8,3.8.2) results to 3.8.1.
> But for [3.8,4.0) and 4.0 both the 3.8.2 and 4.4 will be selected.
> Is it possible to tell Buckminster that this situarion is prohibited and
> make it an error for me? I do not want duplicate entries on my classpath.
>
To be honest, I thought that was the default behavior :-)
In any case, I can see situations when both approaches would be valid and where it indeed would be
desirable to allow/disallow such duplicates. Please add a bugzilla enhancement request for this.
Regards,
Thomas Hallgren
|
|
|
Powered by
FUDForum. Page generated in 0.46535 seconds
Home