RE: jelly:xml question

[Wim Lambrecht]

It seems that there is a dom4j 1.5 beta1 released !
And the bug you've reported has been fixed in that one (see release
notes: 
http://sourceforge.net/project/shownotes.php?release_id=226425)

I'll try that one to see i my problem is solved.

-wil-


-Oorspronkelijk bericht-
Van: KRÁLIK Vladimír [mailto:[EMAIL PROTECTED] 
Verzonden: donderdag 6 mei 2004 16:42
Aan: Maven Users List
Onderwerp: RE: jelly:xml question

Maybe it's this bug in dom4j :
http://sourceforge.net/tracker/index.php?func=detailaid=787428group_id
=16035atid=116035

It was fixed only in CVS :
http://cvs.sourceforge.net/viewcvs.py/dom4j/dom4j/src/java/org/dom4j/tre
e/AbstractProcessingInstruction.java

vlk

 -Original Message-
 From: Wim Lambrecht [mailto:[EMAIL PROTECTED]
 Sent: Thursday, May 06, 2004 9:49 AM
 To: [EMAIL PROTECTED]
 Subject: jelly:xml question
 
 
 Hi,
 
 I want to use the x:set tag, but i have a problem with the 
 select= part,
 more specifically when i want to use a string-variable there.
 
 1) When i hard-code my xpath-expression, everything works fine
 ($reconfigdoc is a DOM object constructed via the x:parse-tag. No
 problem there since i get the desired result in the statement below)
 
 x:set var=hardcodetype
 select=string($reconfigdoc/deployment-profile/[EMAIL PROTECTED]'0
100']/type)/
 !-- OK --
 
 2) When i want to pass an earlier made variable, i.c. 
 $file.name (which is
 something like file1.properties) in the select part, the xpath
 evaluation returns nothing. And file.name actually has a value.
 
 x:set var=hardcodetype
 select=string($reconfigdoc/deployment-profile/[EMAIL PROTECTED]'$
{file.name}']/type)/
 !-- OK --
 
 BTW the 'select' attribuut expects an Object of type org.jaxen.XPath,
 althought all examples i've found so far just pass a String 
 to it. (or is
 conversion handled by the taglib ?)
 
 Thanks for any help.
 
 -wil-
 
 
 
 
 
 -
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]
 
 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: jelly:xml question

[Wim Lambrecht]

Hi Sean,

A little misunderstanding:
${file} is my original variable
${file.name} is the 'name' property of ${file}, which works fine in
non-expath situation.

Thanks anyway.
-wil-

-Oorspronkelijk bericht-
Van: W. Sean Hennessy [mailto:[EMAIL PROTECTED] 
Verzonden: donderdag 6 mei 2004 17:18
Aan: 'Maven Users List'
Onderwerp: RE: jelly:xml question

eliminate the dot from the variable name
$file-name instead of $file.name?

-Original Message-
From: Wim Lambrecht [mailto:[EMAIL PROTECTED] 
Sent: Thursday, May 06, 2004 12:51 AM
To: [EMAIL PROTECTED]
Subject: Re: jelly:xml question


Sorry,

The second !-- OK -- should be !-- NOT OK -- of course. Problem
stays the same 

-wil-


 Hi,

 I want to use the x:set tag, but i have a problem with the select= 
 part, more specifically when i want to use a string-variable there.

 1) When i hard-code my xpath-expression, everything works fine 
 ($reconfigdoc is a DOM object constructed via the x:parse-tag. No 
 problem there since i get the desired result in the statement below)

 x:set var=hardcodetype 
 select=string($reconfigdoc/deployment-profile/[EMAIL PROTECTED]'0100']/ty
 pe)/
 !-- OK --

 2) When i want to pass an earlier made variable, i.c. $file.name 
 (which is something like file1.properties) in the select part, the 
 xpath evaluation returns nothing. And file.name actually has a value.

 x:set var=hardcodetype 
 select=string($reconfigdoc/deployment-profile/[EMAIL PROTECTED]'${file.na
 me}']/type)/
 !-- OK --

 BTW the 'select' attribuut expects an Object of type org.jaxen.XPath, 
 althought all examples i've found so far just pass a String to it. (or

 is conversion handled by the taglib ?)

 Thanks for any help.

 -wil-





 - 
 To unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

jelly:xml question

[Wim Lambrecht]

Hi,

I want to use the x:set tag, but i have a problem with the select= part,
more specifically when i want to use a string-variable there.

1) When i hard-code my xpath-expression, everything works fine
($reconfigdoc is a DOM object constructed via the x:parse-tag. No
problem there since i get the desired result in the statement below)

x:set var=hardcodetype
select=string($reconfigdoc/deployment-profile/[EMAIL PROTECTED]'0100']/type)/
!-- OK --

2) When i want to pass an earlier made variable, i.c. $file.name (which is
something like file1.properties) in the select part, the xpath
evaluation returns nothing. And file.name actually has a value.

x:set var=hardcodetype
select=string($reconfigdoc/deployment-profile/[EMAIL 
PROTECTED]'${file.name}']/type)/
!-- OK --

BTW the 'select' attribuut expects an Object of type org.jaxen.XPath,
althought all examples i've found so far just pass a String to it. (or is
conversion handled by the taglib ?)

Thanks for any help.

-wil-





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: jelly:xml question

[Wim Lambrecht]

Sorry,

The second !-- OK -- should be !-- NOT OK -- of course.
Problem stays the same 

-wil-


 Hi,

 I want to use the x:set tag, but i have a problem with the select=
 part, more specifically when i want to use a string-variable there.

 1) When i hard-code my xpath-expression, everything works fine
 ($reconfigdoc is a DOM object constructed via the x:parse-tag. No
 problem there since i get the desired result in the statement below)

 x:set var=hardcodetype
 select=string($reconfigdoc/deployment-profile/[EMAIL PROTECTED]'0100']/type)/
 !-- OK --

 2) When i want to pass an earlier made variable, i.c. $file.name (which
 is something like file1.properties) in the select part, the xpath
 evaluation returns nothing. And file.name actually has a value.

 x:set var=hardcodetype
 select=string($reconfigdoc/deployment-profile/[EMAIL 
 PROTECTED]'${file.name}']/type)/
 !-- OK --

 BTW the 'select' attribuut expects an Object of type org.jaxen.XPath,
 althought all examples i've found so far just pass a String to it. (or
 is conversion handled by the taglib ?)

 Thanks for any help.

 -wil-





 - To
 unsubscribe, e-mail: [EMAIL PROTECTED]
 For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

dynamically plugable build.properties

[Wim Lambrecht]

Hi,
 
I don't want to put my build.properties -file in the home directory of
my project (normally at the same place as the project.properties -file).

 
project1
|- project.xml
|- maven.xml
|- project.properties
|- CONFIG1/build.properties
|- CONFIG2/build.properties
 
So, i want to dynamically switch (copy a config*/build.properties to the
'live' project home directory or something like that via a preGoal in
maven.xml) to a build.properties based on the type of config (config 1
or config2). I want to set this type as a property in the
'project.properties'-file.
 
The problem is that the maven-engine (proces) is already started at the
time of copying, so the copied build.properties isn't used at all.
 
Is this the right way or are there alternatieves ?
 
The reason i'm doing this is dat the properties in the build.properties
are totally different for each CONFIG.
 
TIA
-wil-

RE: EJB Deployment descriptor configuration

[Wim Lambrecht]

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

[Wim Lambrecht]

  enterprise-beans
 !-- Session Beans --
 xsl:commentSession Beans/xsl:comment
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/enterprise-beans/session/
 /xsl:for-each
 
 !-- Entity Beans --
 xsl:commentEntity Beans/xsl:comment
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/enterprise-beans/entity/
 /xsl:for-each
 
 !-- Message Driven Beans --
 xsl:commentMessage Driven Beans/xsl:comment
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/enterprise-beans/message-driven/
 /xsl:for-each
  /enterprise-beans
  
  
  !--  Relationships  -- 
  xsl:commentRelationships/xsl:comment
  relationships
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/relationships/ejb-relation/
 /xsl:for-each
  /relationships
  
  
  !--  Assembly Descriptor  -- 
  xsl:commentAssembly Descriptor/xsl:comment
  assembly-descriptor
 !-- security roles --
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/assembly-descriptor/security-role/
 /xsl:for-each  
 
 !-- method permissions --
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/assembly-descriptor/method-permission/
 /xsl:for-each  
 
 !-- container transaction --
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/assembly-descriptor/container-transaction/
 /xsl:for-each   
  /assembly-descriptor  
   /ejb-jar 
/xsl:template
/xsl:stylesheet


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 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

RE: AW: EJB Deployment descriptor configuration

[Wim Lambrecht]

Colin,

I'm busy evaluating your ejbmerge plugin.
I've got it up and running and it's a nice concept.
At first sight this could be a solution for me, but i did notice
something that will cause some problems for me:
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 enterprise-beans.
When i want to merge some resource-refs, which are related to my
entity beans, i have tell de XMLMerger (via the config file) that i want
to expand my entity-bean configuration. There is no
resource-refs-tag in my original source ejb-jar.xml. 
Can i do this with the standard plugin ?

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 resource-refs
section, so adding a single resource-ref to the already present ones
won't work, i guess.

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'.

I know that you've made the plugin for merging serveral ejb.jars (and
their DD's) together. And for that case, it does the job (very wel, i
must add). I my case, i need some extra.
What i most certainly like about the plugin is that the source ejb-jar
deliverable is there, ready to use, which fits nice in the whole maven
thinking.

What do you think about the stated 'problems' ?
-wil-

-Oorspronkelijk bericht-
Van: MacLeod, Colin [mailto:[EMAIL PROTECTED] 
Verzonden: woensdag 24 maart 2004 16:44
Aan: Maven Users List
Onderwerp: Re: AW: EJB Deployment descriptor configuration

Hi Wim,

 1) XMLMerger.xml
 -a) tag enterprise-beans: in my original Dep. Descripter there's an
 entity bean with no resource refs (refs to Datasources e.g.). Is it
 possible to put the resource-ref tags somewhere in de XMLMerger.xml
so
 that they get merged with the earlier entity-info. Here's an
example:

Well the way it works is that every tag which is in the XMLMerger.xml
file will be merged. If a tag does not appear, it will be appended
within 
one of the to be merged tags.

Using this

file name=ejb-jar.xml
ejb-jar
description/
display-name/
enterprise-beans/
relationships/
assembly-descriptor/
/ejb-jar
/file

for the ejb-jar will cause the contents of the ejb-jar/description,
ejb-jar/display-name, ejb-jar/enterprise-beans, etc to be appended
from one ejb jar to the next.


Likewise for jboss,

file name=jboss.xml
jboss
enterprise-beans/
resource-managers/
/jboss
/file

causes the contents of ejb-jar/enterprise-beans and
ejb-jar/resource-managers from one ejb jar to be appended to the next


 -c) what about 'overriding' tags ?

Well I did do this with the attribute merge=false.
jbosscmp-jdbc
defaults merge=false
datasourcejava:/portalDS/datasource
datasource-mappingPostgreSQL 7.2/datasource-mapping
create-tablefalse/create-table
remove-tablefalse/remove-table
/defaults

Basically, this tells the program not to merge the contents but to use
those explicity listed, so any defaults will be ignored from the DDs
to be merged.

 2) what 'license agreement' is there on your plugin ?

The whole project is GPL.
Does this do what you want it to?

Cheers,
Colin
__
Colin MacLeod
[EMAIL PROTECTED]
ivata.org - open source enterprise groupware


On 24 March, at 2:54 PM, you wrote:

Hi Colin,

I haven't test it yet (had some meeting first), sorry.
But i did take a look at the openportal/ejb/src/xml/XMLMerger.xml
already.
I like the concept, but some questions though:
1) XMLMerger.xml
-a) tag enterprise-beans: in my original Dep. Descripter there's an
entity bean with no resource refs (refs to Datasources e.g.). Is it
possible to put the resource-ref tags somewhere in de XMLMerger.xml so
that they get merged with the earlier entity-info. Here's an example:

==
Original ejb-jar.xml (extraction):
...
  entity 
 display-nameAuthenticationMethodEJB/display-name
 ejb-namesfc/AuthenticationMethodEb/ejb-name
 
local-homebe.schaubroeck.prj.sfc.ejb.aa.authentication.AuthenticationM
ethodEbLocalHome/local-home
 
localbe.schaubroeck.prj.sfc.ejb.aa.authentication.AuthenticationMethod
EbLocal/local

 
ejb-classbe.schaubroeck.prj.sfc.ejb.aa.authentication.AuthenticationMe
thodEbBMP/ejb-class
 persistence-typeBean/persistence-type
 

RE: EJB Deployment descriptor configuration

[Wim Lambrecht]

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 resource-refs
 section, so adding a single resource-ref 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
enterprise-beans. 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 resource-ref).

= 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

[Wim Lambrecht]

 doctype-system=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/  
xsl:template match=/
   
   ejb-jar
  description![CDATA[No Description.]]/description
  display-nameGenerated by XDoclet/display-name
  
  !-- List of all EJBs --
  xsl:commentList of all EJBs/xsl:comment
  enterprise-beans
 !-- Session Beans --
 xsl:commentSession Beans/xsl:comment
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/enterprise-beans/session/
 /xsl:for-each
 
 !-- Entity Beans --
 xsl:commentEntity Beans/xsl:comment
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/enterprise-beans/entity/
 /xsl:for-each
 
 !-- Message Driven Beans --
 xsl:commentMessage Driven Beans/xsl:comment
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/enterprise-beans/message-driven/
 /xsl:for-each
  /enterprise-beans
  
  
  !--  Relationships  -- 
  xsl:commentRelationships/xsl:comment
  relationships
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/relationships/ejb-relation/
 /xsl:for-each
  /relationships
  
  
  !--  Assembly Descriptor  -- 
  xsl:commentAssembly Descriptor/xsl:comment
  assembly-descriptor
 !-- security roles --
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/assembly-descriptor/security-role/
 /xsl:for-each  
 
 !-- method permissions --
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/assembly-descriptor/method-permission/
 /xsl:for-each  
 
 !-- container transaction --
 xsl:for-each select=files/file
xsl:variable name=file select=document(text())/
xsl:copy-of
select=$file/ejb-jar/assembly-descriptor/container-transaction/
 /xsl:for-each   
  /assembly-descriptor  
   /ejb-jar 
/xsl:template
/xsl:stylesheet


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 it depends 
 on another
 jar project in thirdparty/maven/merge. 
 
 If you want an example