maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brent N Atkinson (JIRA)" <j...@codehaus.org>
Subject [jira] Commented: (MNG-1991) Can't get transitive dependencies from a war pom when this war is added as a depdency of a project
Date Mon, 28 Jul 2008 22:41:27 GMT

    [ http://jira.codehaus.org/browse/MNG-1991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=143407#action_143407
] 

Brent N Atkinson commented on MNG-1991:
---------------------------------------

I believe the J2EE/JavaEE specifications designate packaging to an 'assembler' role for good
reason. The code for web module and resource adapters (a real connector, not simply a configured
JDBC pool) are managed well as plain jars. Dependencies are satisfied by external jars, and
you have fine grained control over reuse. IMHO, making wars, rars, and ears first-class maven
citizens seems a bit strange. The way you package them changes on the environment, Appserver,
et cetera. The compiled code doesn't change.

I have used the rar, ear and war plugins to build both skinny and full-fledged components.
I can appreciate why you would want to package the full fledged components (at least war and
rar) because they are reusable components much like the jar. They are intended to be boxed
up and reused. However, these components imply configuration and repackaging (Class-Path entries
in the manifests of modules, moving jars to ear-level, changing init-params, configuring security,
adding appserver specific descriptors, etc). This seems to indicate that they are not artifacts
in the traditional maven sense. They are not static like jars, so storing them as such doesn't
make much sense. It may not make sense to store them with the jar dependencies bundled; this
is like storing uberjars all over the place. Perhaps the realization of an war/ear with dependencies
is better deferred?

Wars and rars are ideally treated as components. So it may make sense to store them with their
external dependencies. However, I believe dependency meta data could be used. This would perhaps
be something like a dependency scope 'aggregate'? It would imply that transitivity blocks
at the artifact that aggregates them. Unfortunately, if dependency meta data isn't available
to dependent artifacts you can no longer identify or resolve conflicts, et cetera. If you
could use this meta data, then you could perhaps control the ultimate fate of the dependencies
through something like dependencyManagement. It may be enough information for an intelligent
assembly plugin to realize the aggregate dependencies and patch up bundled modules with Class-Path
manifest entries, et cetera.

> Can't get transitive dependencies from a war pom when this war is added as a depdency
of a project
> --------------------------------------------------------------------------------------------------
>
>                 Key: MNG-1991
>                 URL: http://jira.codehaus.org/browse/MNG-1991
>             Project: Maven 2
>          Issue Type: Bug
>          Components: Dependencies
>    Affects Versions: 2.0.2
>            Reporter: Emmanuel Venisse
>             Fix For: 2.1
>
>
> I have a project (continuum-core-it) that need to use all transitive dependencies of
a war (continuum-webapp). If i add the war as a dependency of the project with packaging war,
war dependencies aren't shown by project, maven doesn't try to resolve them and doesn't add
them in classpath.
> If if replace packaging from war to pom, all dependencies are resolved and added to classpath.

-- 
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

        

Mime
View raw message