I don't use the one's produced by xdoclet and instead generate my own
using middlegen and its <java> subtask. Say you had a value-object
package called "foo.bar.model" and you used the table name plus Model as
the name. Then you have a velocity script called, say, model.vtl. I
should really generalize my script and submit it as an example.
<java name="model" destination="${build.source}"
package="foo.bar.model">
<fileproducer filename="_{0}Model.java"
destination="${build.source}" template="./scripts/model.vtl"/>
</java>
-----Original Message-----
From: Russell Black [mailto:[EMAIL PROTECTED]
Sent: Friday, February 21, 2003 1:55 PM
To: [EMAIL PROTECTED]
Subject: Re: [Middlegen-user] What's the Big Picture
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
-------------------------------------------------------
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
