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
