He Jorn,
Thanks for that.
I thought to use my DD's as basis for the end configuration, but you're
right, in that ABCD-case the D-module DD would contain the module
A-stuff twice ! (not necesserally the code itself twice).
Now, to satisfy both needs, i guess i could do something like this:
1) provide an artifact which can be used to put together a
'product' as you call it. This artifact could have a naming convention
like 'ejb-mystuff-*-0.1', where * could be 'raw', 'module' or component.
Every product could link this one as a dependency (in its pom).
2) provide another ready to use, artifact (an EJBJAR for
instance). I could use a naming convention like 'ejb-mystuff-*-0.1',
where * could be 'end' (or 'product'). This is then ready-to-use for
those who need no (re-)configuration of the product (except they can do
it manually if they wish).
After the merging, i could apply my specific needs, like 'adding' and
'overriding' via custom XSL stylesheets.
I guess this could be my final solution. What do you think ?
-wil-
-----Oorspronkelijk bericht-----
Van: J�rn Gebhardt [mailto:[EMAIL PROTECTED]
Verzonden: vrijdag 26 maart 2004 14:17
Aan: Maven Users List
Onderwerp: AW: EJB Deployment descriptor configuration
Hi Wim,
the advantage of your suggestion is - as you said - that you can deploy
each
module of its own.
However there exists at least one disadvantages/problem you have to
solve
using your approach:
Imagine you have 4 EJB modules A, B, C and D. B and C depend on A and D
depends on B and C:
B
/ \
A D
\ /
C
If Module B and C contain the EJBs of Module A and you merge them to
module
D you would have the EJBs of module A two times in module D.
In our approach module D is configued to have dependencies to module A,
B
and C:
A
\
B - D
/
C
A, B and C contain only those EJBs in their DD that are defined within
them
(i.e. B and C do not contain those of module A, and D doesn't contain
those
of A, B or C). If we want to create for D a deployable jar (or ear) we
call
a different goal that creates one jar 'D-ejb.jar' that contains only a
META-INF directory with the merged DDs and a manifest.mf referencing
A.jar,
B.jar, C.jar and D.jar. We put all these jars into one deployable EAR.
Note that we distinguish between a product and a module in our approach.
A
module is a 'normal' jar whereas a product is an EJB jar or EAR that can
be
deployed.
Comments or suggestions are always welcome,
J�rn
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
