RE: EJB Deployment descriptor configuration
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]
RE: EJB Deployment descriptor configuration
Jörn,
In a previous reply you mentioned "... 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. ...".
Say that you don't use the 'normal jar' approach, but the real 'ejb-jar'
one. I guess you could easy adjust your goals to manipulate the
ejb-jar.xml files.
The extra advantage would be that each EJB-jar would have a default
configuration present and one could use it directly in a project. In
your case you always have to rebuilt al the EJB-jars.
e.g. the people for the hint below (ivata, Colin MacLeod) use this
approach.
What do you think ?
Greetings
-wil-
-Oorspronkelijk bericht-
Van: Jörn Gebhardt [mailto:[EMAIL PROTECTED]
Verzonden: woensdag 24 maart 2004 15:59
Aan: Maven Users List
Onderwerp: AW: EJB Deployment descriptor configuration
Hi Wil,
thanks for the hint you got in the XDoclet mailing list (I didn't take a
closer look at it right now, but I definitely will...).
As mentioned before do we not use arch4j but XSLT.
Our plugin contains the following two goals for merging DDs. Here's the
Jelly script part for merging ejb-jar.xml files (jboss.xml and
jbosscmp-jdbc.xml are very similar).
${file.toString()}
The following xsl style sheet is used for the merge process (very simple
approach that contains no validations or other merge logic:
http://www.w3.org/1999/XSL/Transform";
version="1.0">
http://java.sun.com/dtd/ejb-jar_2_0.dtd";
doctype-public="-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans
2.0//EN"
cdata-section-elements="description ejb-ql"/>
Generated by XDoclet
List of all EJBs
Session Beans
Entity Beans
Message Driven Beans
Relationships
Assembly Descriptor
Hope this helps,
Jörn
> -Ursprüngliche Nachricht-
> Von: Wim Lambrecht [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 24. März 2004 12:19
> An: 'Maven Users List'
> Betreff: RE:AW:EJB Deployment descriptor configuration
>
>
> 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 d
Re: RE: EJB Deployment descriptor configuration
Hi Wim, > Was that the/a reason to develop your own plugin (because you needed > merging & overriding) ? Well, yes. I wanted to separate the EJB subprojects, so they can be used independently of one another. This meant I could make a change in the addressbook module (say) and then just build that subproject, followed by the openportal multiproject. It saves me from having to rebuild the whole thing. Other (external) projects which also use addressbook (say) need not build the EJBs for this module at all - they can merge them "prebuilt" with their own. Cheers, Colin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: EJB Deployment descriptor configuration
Hi Colin, ... > One solution, of course, is to make sure that the required tags are > already (as placeholders) in the source file. But still, i will have tot > replace (override it via the config file) the whole > section, so adding a single to the already present ones > won't work, i guess. Hmm - not sure I really get this, Wim. Can you please expand on this? = PLACEHOLDERS= - Only elements who are present in the source file are examined, (since all nodes al traversed one by one), right ? - if there no such element in the config, the element is copied to the target, without examination. Which is a good thing, but here we which to trigger the examination, because we want to merge or override ... - so, we can trigger the examination of the source-element by adding it explicit in the source file. - in the config file, i put the desired element, fully configured, using the merge="false" attribute of your plugin. But again, this will only with elements that group, like . So, you'll still have the same problem in the cases where there is more than one element of that kind possible. E.g. when i have more than one ). = XDOCLET (again) = == With Xdoclet you can use so called 'MERGE-POINTS'. In case of EJB and Jboss tasks, you can specify a 'mergedir' property (points to a map of your choise). In that map you can provide special files: entity-beans.xml, session-beans.xml, ..., jboss-beans.xml, etc. Xdoclet uses your provided information to generate e.g. the DD for an EJB-JAR. In that story i could use these files as configs (XMLMerger-like) (put them in a seperate or extra deliverables). The 'end'-project (the one that needs assembling and configuration) can put the desired dependencies in the project's pom. And finally you can package all the dependant EJB-parts, after running xdoclet to built its deployment descriptor. But i didn't dig too deep in that because i soon noticed, that i e.g. could only provide 'entire' entity-bean or session-bean tags, not 'parts' (sub-elements) of the entity bean. Maybe i need to dig deeper (i do know that there are some possibilities to use your own tags, which then can point element in that config*.xml files). Was that the/a reason to develop your own plugin (because you needed merging & overriding) ? CU -wil- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: EJB Deployment descriptor configuration
Hi Wim, > 1) if a tag is mentioned in the configfile (XMLMerger.xml) then there's > a test if it already appears in the targetfile. If so, it won't be > copied to the target file (again). This works fine for tags that only > appear once in the sourcefile (ejb-jar.xml), like . > When i want to merge some , which are related to my > entity beans, i have tell de XMLMerger (via the config file) that i want > to expand my -bean configuration. There is no > -tag in my original source ejb-jar.xml. > Can i do this with the standard plugin ? Aha. The only way I can think of (using the current verison) is to put the tags you need to have in the target file beforehand. That way they will be appended to, and will always be there. If this doesn't work for some reason, another (dirtier) solution is to add a "dummy" ejb jar dependency which only contains the target result you want to achieve. > One solution, of course, is to make sure that the required tags are > already (as placeholders) in the source file. But still, i will have tot > replace (override it via the config file) the whole > section, so adding a single to the already present ones > won't work, i guess. Hmm - not sure I really get this, Wim. Can you please expand on this? > 2) I want to override/merge a ''specific'' entity of session bean (or > whatever 'element' in my ejb-jar.xml. I guess that current > XMLMerger.java util will have to be extended to do something like: > source-element=config-element AND it's source attribute-'ID'=the > config's attribute-'ID'. No, you're right, I'm afraid - there is no way to do this at present. I think it would be best if we add something like a select using XPath in XSLT to specify an element which should be overridden and not merged. Thanks for your considerate and kind words, Wim. It sounds like the ejbmerge plugin could be extended to do exactly what you're looking for, though it won't do it "as is". I'm really busy today/tomorrow but, if you like, I could code you a solution on Saturday, if you send me 2 sample input files and a sample target result. Just send the files to the mail address below and I'll do it as soon as I can :-) Cheers, Colin __ Colin MacLeod [EMAIL PROTECTED] ivata.org - open source enterprise groupware - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: EJB Deployment descriptor configuration
Jörn,
Thanks for your code, i'll look into it.
I'm currently evaluating the ejbmerge-plugin from ivata (the one Colin
gave me). I'll give some feedback on the list on that one, interesting
for you also, i guess.
CU
-wil-
-Oorspronkelijk bericht-
Van: Jörn Gebhardt [mailto:[EMAIL PROTECTED]
Verzonden: woensdag 24 maart 2004 15:59
Aan: Maven Users List
Onderwerp: AW: EJB Deployment descriptor configuration
Hi Wil,
thanks for the hint you got in the XDoclet mailing list (I didn't take a
closer look at it right now, but I definitely will...).
As mentioned before do we not use arch4j but XSLT.
Our plugin contains the following two goals for merging DDs. Here's the
Jelly script part for merging ejb-jar.xml files (jboss.xml and
jbosscmp-jdbc.xml are very similar).
${file.toString()}
The following xsl style sheet is used for the merge process (very simple
approach that contains no validations or other merge logic:
http://www.w3.org/1999/XSL/Transform";
version="1.0">
http://java.sun.com/dtd/ejb-jar_2_0.dtd";
doctype-public="-//Sun Microsystems, Inc.//DTD Enterprise
JavaBeans
2.0//EN"
cdata-section-elements="description ejb-ql"/>
Generated by XDoclet
List of all EJBs
Session Beans
Entity Beans
Message Driven Beans
Relationships
Assembly Descriptor
Hope this helps,
Jörn
> -Ursprüngliche Nachricht-
> Von: Wim Lambrecht [mailto:[EMAIL PROTECTED]
> Gesendet: Mittwoch, 24. März 2004 12:19
> An: 'Maven Users List'
> Betreff: RE:AW:EJB Deployment descriptor configuration
>
>
> 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
