Value objects (at least the ones produced by xdoclet) don't contain any CMR fields. How can I replace my ejbCreate(cmp1, cmp2, cmr1, cmr2) with a value object which doesn't know the cmrs?
----- Original Message ----- From: "Rod Macpherson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 21, 2003 2:35 PM Subject: RE: [Middlegen-user] What's the Big Picture Here's the straight-up on those create methods: ditch 'em. All of my EJBs have a single create method taking a value-object. The value objects are created with a velocity script using Middlgen's "java" sub-task - really did not have any luck with the built-in value object and had a production model I had to adhere to anyway. Since using my own top-level velocity script my generated beans are way cleaner. -----Original Message----- From: Russell Black [mailto:[EMAIL PROTECTED] Sent: Friday, February 21, 2003 1:31 PM To: [EMAIL PROTECTED] Subject: Re: [Middlegen-user] What's the Big Picture I'm attempting to use middlegen for continuous integration, and have found it to work well with one exception: When you change the number of tables, the ejbCreate method signatures change, even on entity beans which aren't affected by the new tables. Specifically, the ordering of the cmr parameters in the ejbCreate constructor change. I can only guess that they are pulled out in some random order, as from a hash map, and when the number of tables change, the order changes. This is a bit of a pain to go through all my code, and change the signature. But that's my only complaint for continuous integration. It's certainly worth the time it saves me. ----- Original Message ----- From: "Rod Macpherson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Friday, February 21, 2003 2:12 PM Subject: RE: [Middlegen-user] What's the Big Picture I cannot really speak to merge files because I do not use them. Instead I use my own velocity script so everything is customizable. Middlegen gives me all of the data structures I need in the velocity context. Multiple scripts or some sort of switch in the velocity context should do the trick for you. As for multiple ant tasks, that is a good point but since I handle everything with a single customized velocity script I process all tables at once. I think a well documented velocity script for entity-cmp-20.velocity would go a long way. I think you should consider that route if possible: no merge files required. BTW, you could easily switch on which tables you process on each "run" of middlegen while providing middlegen with a full list of tables each time. I agree with your observations but I think the issues are relatively straightforward to resolve with your own entity-cmp-20 script. Heck, I am changing field types dynamically based on a target customer switch, generating my own value-objects and so on. Works great. -----Original Message----- From: Kyle F. Downey [mailto:[EMAIL PROTECTED] Sent: Friday, February 21, 2003 12:02 PM To: [EMAIL PROTECTED] Subject: RE: [Middlegen-user] What's the Big Picture I'm all for continuous integration--hand-integrating the schema changes as the project evolves has been a big headache. I disagree with both people who pointed out separate ant targets will do the trick, unless I'm missing something. Middlegen needs to "see" all the tables to create relationships. Distinct invocations don't share cross-references. So yes you can break into packages, but you can't do CMR across packages. Thus, you're stuck with repackaging after a single-shot generate or stuck with one monster package. I also personally am not wild about the merge files used by XDoclet and adopted by Middlegen. A method here and a method there in little text files is still a nightmare, and it encourages poor object design: treating Entity EJBs as just a persistence layer, rather than as persistent objects: data + operations on that data. Worst of all, it's your business rules and logic that are scattered in those files: arguably the code you want to be easiest to find. Subclassing is one way to get around adding some code by mergepoints, but not all, and again it breaks the continuous integration aspect because you need to hand-change deployment descriptors when you subclass. Do not get me wrong: I love Middlegen--it has saved countless hours on several very large (40+ table, lots of relationships) projects already--but I feel it's not adequate for continuous integration for large, complex projects unless you're willing to sacrifice OO, easy-to-read code and good namespace maintenance. For code that has to be around for years, I am afraid I can't sacrifice those things. --kd > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Rod > Macpherson > Sent: Friday, February 21, 2003 1:23 PM > To: [EMAIL PROTECTED] > Subject: RE: [Middlegen-user] What's the Big Picture > > > Continuously generating entity beans with middlegen is actually quite > practical. In my opinion the tool should provide a separate > stand-alone example of what is arguably the most useful and common > application: entity EBJs. Having a monster pacakage is a result of > processing everything with a single ant target. Break it up into small > groups and you should have all of the flexibility you need. Use the > entity-cmp-20 template as the basis for your own and you will > have all the flexibility you need. Velocity in combination > with the data structures provided by middlegen is a powreful > combination. Having said that the one-shot approach is not a > bad idea either and you can use the output of middlegen right > out of the box and go from there. The continuous approach > incorporates all the database schema changes automatically. I > will receive numerous database change notifications over time > that break the beans. I just push a button and, poof, new > entity beans! Otherwise you have to have a change-control > process to trigger work on the part of bean developers when > the schema changes. Nothing new with that and not an > unreasonable strategy. > > -----Original Message----- > From: Kyle F. Downey [mailto:[EMAIL PROTECTED] > Sent: Friday, February 21, 2003 9:14 AM > To: [EMAIL PROTECTED] > Subject: RE: [Middlegen-user] What's the Big Picture > > > After a good try, in our company we decided to use Middlegen one-shot > rather than through continuous integration due to dissatisfaction with > the merge mechanism. In short, the senior developers were > uncomfortable with having critical logic, finders and other elements > scattered in a lot of source code fragments. If you're using Middlegen > to just generate a simple persistence layer (the "easier than JDBC > model"), it's great, but if you want to generate code that > will be maintained over time by many developers continuous > integration isn't realistic. The fact that all EJBs end up in > the same monster package isn't very good for big projects either. > > If anyone has suggestions on ways to get around this, I'm all ears, as > I would really prefer continuous integration. > > --kd > > > > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The > most comprehensive and flexible code editor you can use. Code faster. > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > middlegen-user mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/middlegen-user > > > ------------------------------------------------------- > This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The > most comprehensive and flexible code editor you can use. Code faster. > C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. > www.slickedit.com/sourceforge > _______________________________________________ > middlegen-user mailing list [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/middlegen-user > ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ middlegen-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/middlegen-user ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ middlegen-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/middlegen-user ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ middlegen-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/middlegen-user ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ middlegen-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/middlegen-user ------------------------------------------------------- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge _______________________________________________ middlegen-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/middlegen-user
