[
http://jira.codehaus.org/browse/MECLIPSE-370?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=134865#action_134865
]
Michael Johns commented on MECLIPSE-370:
----------------------------------------
We encountered the following situation:
- Project A depended on Library B with a scope of "test."
- Library B depended on Library C with a scope of "runtime."
- Project A added some code that needed Library C.
- Since the eclipse plugin pulled in all transitive dependencies, regardless
of scope, Project A compiled in Eclipse just fine.
- Project A failed when running "mvn compile."
If I am reading the comments above correctly, setting all artifacts as
"exported" will only exacerbate my problem, not help it. I might be missing
something key, but it seems to me that the plugin should not put dependencies
that are "runtime" scoped into the classpath, transitive or otherwise. They
belong in the manifest, but not the classpath. I'm coming at this from a J2EE
perspective, so perhaps I'm missing something in the non-J2EE world. That's
one issue.
Also, even if Library C wasn't scoped "runtime," it would have been pulled into
Project A anyway due to the fact that Library B depended on it. This is
Maven's basic transitive behavior; no surprise here. But I'd be left with the
same problem. Seems to me that the problem here is that Eclipse doesn't have a
concept of a "test" classpath, so all artifacts, test scope or otherwise, end
up in the classpath.
Anyway, I don't think exporting dependencies is the answer. In fact, I think
that would just do more harm, giving people (like me) more false positive
builds in Eclipse.
> Option to rely on transitive dependencies
> -----------------------------------------
>
> Key: MECLIPSE-370
> URL: http://jira.codehaus.org/browse/MECLIPSE-370
> Project: Maven 2.x Eclipse Plugin
> Issue Type: New Feature
> Components: Core : Dependencies resolution and build path
> Affects Versions: 2.4
> Reporter: Ben Peacock
>
> The generated .classpath file contains all transitive dependencies of a
> project. It is impossible to tell within Eclipse which dependencies are the
> immediate dependencies, without examining the pom.xml.
> With a large number of projects and a deep dependency tree, dependencies of a
> low-level project are duplicated in many other project classpaths. If I want
> to test a change to these dependencies, I cannot just change the low-level
> project's build path in Eclipse and see what happens, I have to change the
> pom.xml and regenerate all the other Eclipse projects.
> I would like an option for the .classpath to contain only the immediate
> dependencies of a project, i.e. those explicit in the project's pom.xml,
> marked as exported if the scope is not provided or test. This would keep each
> Eclipse project classpath as simple as its pom.xml, making it easy to see and
> change the dependency tree within Eclipse.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
