--- "MacLeod, Colin" <[EMAIL PROTECTED]> wrote: > Hi everyone, > > The project I'm working on just now > (http://openportal.info) is split into 5 main > subprojects, some of which are interdependent. > > These subprojects each generate an EJB jar file, and > they are all merged together in a separate process > to create one big project EJB jar file. A maven > plugin does the jar file merging, by adding all > classes from the subprojects and merging the > contents of the XML descriptor files. > > This lets me just rebuild those parts which have > changed, and let's me re-use one of the subprojects > in another separate project in a happy way (I use > maven to reference a specific version and it gets > downloaded automatically.) > > > Till now, I've been manually creating value objects > for these EJBs, but I recently found the excellent > value-object XDoclet subtask and want to convert to > using that instead. > > The problem is that, when I create a value object in > subproject B with a CMR referencing a value object > in subproject A, I get the following error: > "The Bean class is needed but not found in Xdoclet > source path for interface"
Hmm, subproject b ejb jar will need also all the classes from subproject a - to be packaged together in ejb jar. > This is fair enough - it doesn't have the source > code from subproject A. The snag is, I can add > subproject A's source path, but I don't want to > generate the remote interfaces or add this > subproject's details to the XML descriptors. > > I realize getting my desired functionality will > require me to extend XDoclet a bit, and I'm not > sure what the best approach would be. I can think of > 2 ways to add this functionality: > - add an "ignore" pattern to the other subtasks > (local interfaces/cmp/etc) > - add filesets to the value-object subtask, > specifying source code which can be referenced but > not acted upon > > Can anyone advise what would fit best with XDoclet > philosophy? Is there another, better way to achieve > the same thing? That's tricky. And extending olg ( 1.2 ) xdoclet will require you to dive deep in a lot of code. AFAIK, xdoclet will need source code of those classes - because it needs not only original bean class, but also naming conventions from another project. You may also try token replacement in respective classes - but this will be very tricky... regards, ===== ----[ Konstantin Pribluda ( ko5tik ) ]---------------- Zu Verst�rkung meines Teams suche ich ab Sofort einen Softwareentwickler[In] f�r die Festanstellung. Arbeitsort: Mainz Skills: Programieren, Kentnisse in OpenSource-Bereich ----[ http://www.pribluda.de ]------------------------ __________________________________ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ xdoclet-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/xdoclet-user
