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]
