Hi J�rn,
Thanks for your fast reply.
The ['raw'-jars with seperate DD] (configurable via XSLT) approach
could be a satisfying solution. We could split de DD in changeable and
un-changeble pieces. De end-deployers can access de changeable pieces of
the DD OR even better, provide there own overriden version. And then
it's easy to assemble then just-in-time (At this point it would be nice
to do so verification of the EJBJAR, using a 'verifier' (jboss). Maybe
we need a plugin for that, or make one ...).
How do you handle the XSLtransformation, i mean, the nice way would be
to have a maven XSLT plugin, but there is none for moment.
I've posted the same question on the xdoclet-users mailinglist
(since this could be a xdoclet issue too). I've received a reply and
like to bounce it to you too:
[Hi Wim,
> Of course, the latter, involves some unjar/rejar too, but it should be
> ideal that configuration takes place in an automated manner IN the
> current project.
I had almost exactly the same situation in ivata op - the open source
groupware project I'm working on. In my case I had several EJB jar files
I wanted to combine into one. Each EJB jar has a separate subproject,
with a maven build that is combined using the multiproject mechanism.
My solution was to develop a maven plugin. This takes the ejbs from the
repositories and merges them together. Then the XML descriptors are
extracted and I use dom4j to combine those and jar them into the
combined target.
The maven plugin is quite separate to the rest of my project. If you
download the source package from http://ivata.org (click on the download
link at the top), you should be able to see what I mean.
The plugin lives in thirdparty/maven/ejbmerge and it depends on another
jar project in thirdparty/maven/merge.
If you want an example of how I used it, look in openportal/ejb. You'll
see there is a file in openportal/ejb/src/xml/XMLMerger.xml which tells
the merge process how to combine the descriptors.
Take a look. Hope this can help you out.
Cheers,
Colin
__________________________________________________
Colin MacLeod
[EMAIL PROTECTED]
ivata.org - open source enterprise groupware]
-----Oorspronkelijk bericht-----
Van: J�rn Gebhardt [mailto:[EMAIL PROTECTED]
Verzonden: woensdag 24 maart 2004 11:19
Aan: Maven Users List
Onderwerp: AW: EJB Deployment descriptor configuration
Hi Wim,
we have a very similar issue. We have many modules containing EJBs, each
in
a separate Maven project. We are combining these modules to a product
and
merge the deployment descriptors using XSLT. To achieve this, each
module is
a normal jar (i.e. has no META-INF directory) that contains a special
configuration directory that contains the deployment descriptors
(ejb-jar,
jboss.xml etc.) generated by XDoclet.
When creating a product that is composed of some modules we first
generate
an EJB jar that contains only the merged deployment descriptors and the
classpath references in the manifest, and afterwards we build the EAR
that
contains the normal modules jars and the just created EJB jar.
However this approach doesn't include your product specific changes in
the
EJB DDs of the modules. Here an additional step would be needed (most
likely
in the merged DD).
Best regards,
J�rn
> -----Urspr�ngliche Nachricht-----
> Von: Wim Lambrecht [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 24. M�rz 2004 10:57
> An: [EMAIL PROTECTED]
> Betreff: EJB Deployment descriptor configuration
>
>
> Hi there,
>
> This is actually a 'configuration' issue.
>
> i have the following situation:
> I want to assemble an J2EE application (ear) which consist of 2
> EJB-JARS.
> One of de EJB-JARS contains 'common' stuff (let's say, like
> user-management, authentication, authorisation) and is an artifact
> created via a seperate maven project (so, is independant of
> my project).
> Let's call this one the COMMON-EJB.jar. Its contains all the usual
> stuff, including the corresponding deployment descriptor "DD"
> (which is
> the configurable part).
>
> Now, this COMMON-EJB.jar is used in my current project and will be
> packaged in the final production EAR. But, and this is the
> issue, i want
> to re-configure the deployment descriptor (in my application context)
> just before the EAR-packaging. I know that, if done manually,
> this is no
> problem, but i'm looking for an automated way.
> Manually i should take the COMMON-EJB.jar, unjars it, change the DD to
> my wishes, jar it again, and then use it in my EAR. 'Automated' is
> something like: the desired changes for the DD are described
> somewhere,
> and some script (plugin, pregoal, whatever) applies those
> changes to the
> original DD (by the way, DD doesn't support inheritance, like the
> properties-cascade in Maven does). Which is then used in the
> production
> EAR.
> Of course, the latter, involves some unjar/rejar too, but it should be
> ideal that configuration takes place in an automated manner IN the
> current project.
> So, in the end (in my project built), type 'maven' in the
> command line,
> and that's it.
>
> Any ideas, feelings, ...?
>
> t i a
> -wil-
>
> P.S.
> 1. the EJB-jars in the common and in my project are built
> with the maven
> xdoclet plugin. No problem in that matter.
> 2. what re-configurations do i have in mind ? Well: change
> transaction-types on bean-methods ; add resourcerefs - like
> DataSources
> - on enterprise beans, ... the usual stuff a deployer does, ... The
> session-bean <> entity bean relations (ejbrefs) for instance
> can remain
> xdoclet-generated IMHO. but here i don't want to (xdoclet)generate the
> common beans things again, they should still be provided as a EJBJAR
> generated in that other project earlier).
> 3. in fact, i guess this is a common issue, no ? Not only EJB
> Deployment
> Descriptors, but all configurable things linked to (packaged inside) a
> deliverable (properties-files, EAR DD's, WAR web-inf, etc.),
> will sooner
> or later in de deploy-proces needs some re-configuration. But
> it should
> be nice that this configurations be applied automatically.
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
