MEAR-85 (http://jira.codehaus.org/browse/MEAR-85) is a
"Minor/Improvement" JIRA that seems to be flying under the radar. In it,
the maven-ear-plugin, faced with a dependency on an ejb-client, always
packages it in the root directory of your ear, unless you explicitly
tell it otherwise, for that specific artifact. defaultLibBundleDir does
not affect this choice at all.
In the defect, there are comments to the effect that one can easily work
around this in one of two ways:
(1) Putting something in the ear project pom to tell it to package the
specific ejb client artifact in the ear directory of your choosing
(2) changing the dependency from <type>ejb-client</type> to
<classifier>client</classifier>
This seems viable, if a bit awkward, until you get to the case of
transitive dependencies. If there are two layers of dependencies on
ejb-client, and you don't control the transitive one, you're pretty much
up a creek. That's the situation I have in my project.
Let's suppose that I have an ear project, which depends a jar project,
which depends on the client artifact of a separate ejb project, which in
turn depends on another client ejb, like so:
ear-project DEPENDS ON
jar-project DEPENDS ON
ejb-project-1-client DEPENDS ON
ejb-project-2-client
ejb-project-1-client's dependency on ejb-project-2-client uses
<type>ejb-client</type>. I need the ejb-project-2-client jar in the
APP-INF/lib directory of my ear. So what are my options for getting it
there.
The only one I've thought of is to explicitly list every transitive
dependency, either in every ear I build that includes jar-project, or in
jar-project itself, in order to either force the packaging location or
force the nature of the dependency. Having to enumerate transitive
dependencies, one level up, seems to go against everything Maven is
about.
In the MEAR-85 comments, I propose a fix, which is to add
defaultEjbClientBundleDir, so that Maven users get the same sort of
control over ejb client jars, as they currently have over regular jars.
An advantage of this would be that it could be done in completely back
compatible fashion. Another advantage is that the maven-ear-plugin seems
poised to accept such a thing; it would just be a matter of adding a
parameter and passing it along, in place of null, when the object
representing the ejb client is constructed.
Does anyone see, under the existing ear plugin, and with the assumption
of no control over ejb-project-1-client's dependencies, any way to work
around this, that does not require enumerating transitive dependencies?
Thanks,
-- Bryan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
