maven-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bryan Loofbourrow (JIRA)" <j...@codehaus.org>
Subject [jira] Issue Comment Edited: (MEAR-85) ejb-client dependencies should be placed in defaultLibBundleDir
Date Fri, 02 May 2008 15:38:46 GMT

    [ 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

        

Mime
View raw message