[
http://jira.codehaus.org/browse/MEAR-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=133344#action_133344
]
bryanloof edited comment on MEAR-85 at 5/2/08 10:38 AM:
----------------------------------------------------------------
The situation I have, simplified, looks like this:
ear-project DEPENDS ON
jar-project DEPENDS ON
ejb-project-1-client DEPENDS ON
ejb-project-2-client
In the ear project, jars are supposed to go into APP-INF/lib. I use
<defaultLibBundleDir>, and it works for most things, but not ejb-client
dependencues. Apparently, the maven-ear-plugin takes any dependency specified
with a classifier of ejb-client, and puts it into the root ot the ear, unless
you tell it to do otherwise, for a specific artifact. This behavior contrasts
with the usual jar-packaging behavior, in that defaultLibBundleDir permits
specifying a default location for jars in general.
As James Olsen says, specifying the jar-project's dependency as client instead
of ejb-client evades the maven-ear-plugin's classification of the dependency as
an ejb client, and therefore permits it to be packaged where
defaultLibBundleDir says it should. That's all very fine for the jar-project
DEPENDS ON ejb-project-1 case above. But what about the transitive dependency
in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may
or may not control that dependency, and to the extent that I do not, what are
my options?
If the only option at that point is to explicitly list all of the ejb-client
artifacts on which I transitively depend, in the pom of every ear I build from
jars that depend on clients with such transitive dependencies, then I suggest
that this issue may be of greater import than its present classification of
"Minor/Improvement." Forcing projects to violate the hiding of transitive Maven
dependencies seems reasonably serious.
Also, I've had a look in the maven-ear-plugin code, and it seems very easy to
fix, at least if you agree with me about the right way to address it. Given
that there's a defaultLibBundleDir for specifying the default location of jar
files, and given that someone seems to have found a reason for putting ejb
client jars somewhere else regardless of this setting, why not add a
defaultEjbClientBundleDir parameter? It looks to me as though the code change
would be nearly trivial. There's even already a parameter for passing on a
default packaging location, in constructing the object representing the
ejb-client. It's just that it's always set to null at present.
was (Author: bryanloof):
The situation I have, simplified, looks like this:
ear-project DEPENDS ON jar-project DEPENDS ON OF ejb-project-1-client DEPENDS
ON ejb-project-2-client
In the ear project, jars are supposed to go into APP-INF/lib. I use
<defaultLibBundleDir>, and it works for most things, but not ejb-client
dependencues. Apparently, the maven-ear-plugin takes any dependency specified
with a classifier of ejb-client, and puts it into the root ot the ear, unless
you tell it to do otherwise, for a specific artifact. This behavior contrasts
with the usual jar-packaging behavior, in that defaultLibBundleDir permits
specifying a default location for jars in general.
As James Olsen says, specifying the jar-project's dependency as client instead
of ejb-client evades the maven-ear-plugin's classification of the dependency as
an ejb client, and therefore permits it to be packaged where
defaultLibBundleDir says it should. That's all very fine for the jar-project
DEPENDS ON ejb-project-1 case above. But what about the transitive dependency
in my example above. ejb-project1-client DEPENDS-ON ejb-project-2-client? I may
or may not control that dependency, and to the extent that I do not, what are
my options?
If the only option at that point is to explicitly list all of the ejb-client
artifacts on which I transitively depend, in the pom of every ear I build from
jars that depend on clients with such transitive dependencies, then I suggest
that this issue may be of greater import than its present classification of
"Minor/Improvement." Forcing projects to violate the hiding of transitive Maven
dependencies seems reasonably serious.
Also, I've had a look in the maven-ear-plugin code, and it seems very easy to
fix, at least if you agree with me about the right way to address it. Given
that there's a defaultLibBundleDir for specifying the default location of jar
files, and given that someone seems to have found a reason for putting ejb
client jars somewhere else regardless of this setting, why not add a
defaultEjbClientBundleDir parameter? It looks to me as though the code change
would be nearly trivial. There's even already a parameter for passing on a
default packaging location, in constructing the object representing the
ejb-client. It's just that it's always set to null at present.
> ejb-client dependencies should be placed in defaultLibBundleDir
> ---------------------------------------------------------------
>
> Key: MEAR-85
> URL: http://jira.codehaus.org/browse/MEAR-85
> Project: Maven 2.x Ear Plugin
> Issue Type: Improvement
> Affects Versions: 2.3.1
> Reporter: James Olsen
> Priority: Minor
>
> ejb-client jars should be placed in the defaultLibBundleDir when specified.
> They're just standard jar dependencies not J2EE artifacts so should be
> treated the same as other jars. They're currently being placed in the root
> directory.
> A workaround is to add an ejbClientModule entry to override the bundleDir:
> <modules>
> <ejbClientModule>
> <groupId>...</groupId>
> <artifactId>...</artifactId>
> <bundleDir>lib</bundleDir>
> </ejbClientModule>
> </modules>
--
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
