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
