[Middlegen-user] What's the Big Picture

Discussion:

Kuntz, Tim

2003-02-20 21:33:04 UTC

I am looking at rolling out Middlegen to a team of developers at my company.
During my evaluation I have become a little confused as to the end-goal of
Middlegen. I guess my question is, "Is Middegen's focus on
continuous-integration or a one-time creation of source that gets fed into
the continuous-integration stream?".

My observation is that in order to run Middlegen, I need to use Ant to
specify a majority if not all of the information required to generate the
sources. If I choose to display the GUI as the sample build file does, then
I can modify the Middlegen task settings prior to continuing with the code
generation, but the modifications I make are not saved to a new Ant build
file. So on the one hand, I have a Ant script that can be run again should I
add new tables or addtional plugins but it is not complete. On the other
hand, if I never plan on running that particular build file again I would
prefer just setting everything up in the GUI without having to know anything
at all about the underlying Middlegen task.

Please, this is not a criticism of the project as I think it has evolved
nicely and I plan on using it as part of my development. I would just like
to know that any extensions I perform locally are not at odds with the
future direction or goals of the project.

thanks,
tim

Eivind Waaler

2003-02-21 14:30:31 UTC

Permalink

Hi there, some things have been implemented to help achieve a more
"continous-integration" method of working with Middlegen. You might want
to take a look at:

1. Preferences file. The changes you do in the GUI are saved to a
preferences file. Check out samples/src/airline-prefs.properties for the
example application. The location of this file is given by the prefsdir
attribute of the middlegen ant task. Next time you run middlegen, your
changes from last time should be in there. This file can be edited
manually, or by opening the GUI again and making more changes.

2. Merge files. The code generated can be altered by adding merge files:
http://boss.bekk.no/boss/middlegen/plugins/cmp20.html#example

There are different kinds of merge files, take a look at them. Quite
useful.

Not very much is actually controlled by the ant build file. I think the
preferences functionality should be the solution to your "issues" below.

.eivind

Post by Kuntz, Tim
I am looking at rolling out Middlegen to a team of developers at my company.
During my evaluation I have become a little confused as to the end-goal of
Middlegen. I guess my question is, "Is Middegen's focus on
continuous-integration or a one-time creation of source that gets fed into
the continuous-integration stream?".
My observation is that in order to run Middlegen, I need to use Ant to
specify a majority if not all of the information required to generate the
sources. If I choose to display the GUI as the sample build file does, then
I can modify the Middlegen task settings prior to continuing with the code
generation, but the modifications I make are not saved to a new Ant build
file. So on the one hand, I have a Ant script that can be run again should I
add new tables or addtional plugins but it is not complete. On the other
hand, if I never plan on running that particular build file again I would
prefer just setting everything up in the GUI without having to know anything
at all about the underlying Middlegen task.
Please, this is not a criticism of the project as I think it has evolved
nicely and I plan on using it as part of my development. I would just like
to know that any extensions I perform locally are not at odds with the
future direction or goals of the project.
thanks,
tim
-------------------------------------------------------
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
https://lists.sourceforge.net/lists/listinfo/middlegen-user

Kyle F. Downey

2003-02-21 15:15:16 UTC

Permalink

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

Kuntz, Tim

2003-02-21 16:06:16 UTC

Permalink

Thanks, Eivind. I think I have a clearer picture of integration. The
preferences and merge points allow me to run my code-generation multiple
times without having to specify everything in the Ant file. Then at some
point, I leave the Middlegen specific artifacts behind (pref and merge
files) and work manually with the code that gets fed into the
continuous-integration with XDoclet.

tim

-----Original Message-----
From: Eivind Waaler [mailto:***@tihlde.org]
Sent: Friday, February 21, 2003 10:28 AM
To: 'middlegen-***@lists.sourceforge.net'
Subject: Re: [Middlegen-user] What's the Big Picture

Hi there, some things have been implemented to help achieve a more
"continous-integration" method of working with Middlegen. You might want
to take a look at:

1. Preferences file. The changes you do in the GUI are saved to a
preferences file. Check out samples/src/airline-prefs.properties for the
example application. The location of this file is given by the prefsdir
attribute of the middlegen ant task. Next time you run middlegen, your
changes from last time should be in there. This file can be edited
manually, or by opening the GUI again and making more changes.

2. Merge files. The code generated can be altered by adding merge files:
http://boss.bekk.no/boss/middlegen/plugins/cmp20.html#example

There are different kinds of merge files, take a look at them. Quite
useful.

Not very much is actually controlled by the ant build file. I think the
preferences functionality should be the solution to your "issues" below.

.eivind

Post by Kuntz, Tim
I am looking at rolling out Middlegen to a team of developers at my

company.

Post by Kuntz, Tim
During my evaluation I have become a little confused as to the end-goal of
Middlegen. I guess my question is, "Is Middegen's focus on
continuous-integration or a one-time creation of source that gets fed into
the continuous-integration stream?".
My observation is that in order to run Middlegen, I need to use Ant to
specify a majority if not all of the information required to generate the
sources. If I choose to display the GUI as the sample build file does,

then

Post by Kuntz, Tim
I can modify the Middlegen task settings prior to continuing with the code
generation, but the modifications I make are not saved to a new Ant build
file. So on the one hand, I have a Ant script that can be run again should

Post by Kuntz, Tim
add new tables or addtional plugins but it is not complete. On the other
hand, if I never plan on running that particular build file again I would
prefer just setting everything up in the GUI without having to know

anything

Post by Kuntz, Tim
at all about the underlying Middlegen task.
Please, this is not a criticism of the project as I think it has evolved
nicely and I plan on using it as part of my development. I would just like
to know that any extensions I perform locally are not at odds with the
future direction or goals of the project.
thanks,
tim

Rod Macpherson

2003-02-21 16:23:06 UTC

Permalink

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:***@amberarcher.com]
Sent: Friday, February 21, 2003 9:14 AM
To: middlegen-***@lists.sourceforge.net
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 middlegen-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/middlegen-user

Michael Bushe

2003-02-21 16:24:08 UTC

Permalink

I'm still new to Middlegen, but I'd like to comment, for what it's
worth. :-)

As far as the one-big-ejb-package is concerned, you could break your
project up into many ant files, each with their own package.

W.r.t. the scattering of code, it seems like the beauty of Middlegen (or
perhaps just EJB's via XDoclet), is that you define everything in one
EJB Bean file. Sure, you have two files when putting critical code in
merge files (which I have yet to try), but that doesn't seem to much to
bear. Without Middlegen you have scattering of a worse sort - finders
in descriptors, etc.

Large projects generally have contention points when the db is rev'ed
(or the close-to-db components are rev'ed). Looked at another way,
instead of a just rolling out a new db schema and handling the changes
by hand, Middlegen gives you the ability to roll out new schema,
Entities, and lots more all at once. Customizations SHOULD be placed at
extension points in this process - via merge and properties files. This
isolates custom changes to well-known locations. So you trade in the
headache of dealing with db revs on the middle tier(s) for the (I think
smaller) headache of getting used to dealing with new framework
customization points (merge files, properties).

Michael Bushe
President/Chief Software Architect
Bushe Enterprises, Inc.
***@bushe.com
508-625-1235 phone
10 Valleywood Road
Hopkinton, MA 01748

Post by Kuntz, Tim
-----Original Message-----

[mailto:middlegen-user-

Post by Kuntz, Tim
Sent: Friday, February 21, 2003 12:14 PM
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

Post by Kuntz, Tim
with having critical logic, finders and other elements scattered in a
lot of source code fragments. If you're using Middlegen to just

generate

Post by Kuntz, Tim
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

Post by Kuntz, Tim
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
https://lists.sourceforge.net/lists/listinfo/middlegen-user

Kyle F. Downey

2003-02-21 18:03:06 UTC

Permalink

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

Post by Kuntz, Tim
-----Original Message-----
Of Rod Macpherson
Sent: Friday, February 21, 2003 1:23 PM
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-----
Sent: Friday, February 21, 2003 9:14 AM
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
_______________________________________________
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
_______________________________________________
https://lists.sourceforge.net/lists/listinfo/middlegen-user

Rod Macpherson

2003-02-21 19:12:13 UTC

Permalink

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:***@amberarcher.com]
Sent: Friday, February 21, 2003 12:02 PM
To: middlegen-***@lists.sourceforge.net
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

Russell Black

2003-02-21 19:31:10 UTC

Permalink

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" <***@verilet.com>
To: <middlegen-***@lists.sourceforge.net>
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:***@amberarcher.com]
Sent: Friday, February 21, 2003 12:02 PM
To: middlegen-***@lists.sourceforge.net
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

Rod Macpherson

2003-02-21 19:17:02 UTC

Permalink

BTW, I am not suggesting that you beat your head against a wall until
you get continuously integrated changes:) I think your one-shot approach
is perfectly reasonable but that perhaps if you can use your own
top-level script and ditch merge files you might achieve the desired
result. Also, any rational criticism of projects/products can only be
considered healthy. We need more of that. Sometimes people hesitate
because the developers are doing such a fantastic thing in providing
these open source tools for us, but I think Alsak appreciates
constructive criticism.

Rod Macpherson

2003-02-21 19:35:10 UTC

Permalink

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:***@iarchives.com]
Sent: Friday, February 21, 2003 1:31 PM
To: middlegen-***@lists.sourceforge.net
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" <***@verilet.com>
To: <middlegen-***@lists.sourceforge.net>
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:***@amberarcher.com]
Sent: Friday, February 21, 2003 12:02 PM
To: middlegen-***@lists.sourceforge.net
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

Post by Kuntz, Tim
-----Original Message-----
Macpherson
Sent: Friday, February 21, 2003 1:23 PM
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-----
Sent: Friday, February 21, 2003 9:14 AM
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
_______________________________________________
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
_______________________________________________
https://lists.sourceforge.net/lists/listinfo/middlegen-user

Russell Black

2003-02-21 19:55:19 UTC

Permalink

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" <***@verilet.com>
To: <middlegen-***@lists.sourceforge.net>
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:***@iarchives.com]
Sent: Friday, February 21, 2003 1:31 PM
To: middlegen-***@lists.sourceforge.net
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" <***@verilet.com>
To: <middlegen-***@lists.sourceforge.net>
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:***@amberarcher.com]
Sent: Friday, February 21, 2003 12:02 PM
To: middlegen-***@lists.sourceforge.net
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

-------------------------------------------------------
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 middlegen-***@lists.sourceforge.net
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 middlegen-***@lists.sourceforge.net
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 middlegen-***@lists.sourceforge.net
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

Rod Macpherson

2003-02-21 20:18:18 UTC

Permalink

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:***@iarchives.com]
Sent: Friday, February 21, 2003 1:55 PM
To: middlegen-***@lists.sourceforge.net
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" <***@verilet.com>
To: <middlegen-***@lists.sourceforge.net>
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:***@iarchives.com]
Sent: Friday, February 21, 2003 1:31 PM
To: middlegen-***@lists.sourceforge.net
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" <***@verilet.com>
To: <middlegen-***@lists.sourceforge.net>
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:***@amberarcher.com]
Sent: Friday, February 21, 2003 12:02 PM
To: middlegen-***@lists.sourceforge.net
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

Post by Kuntz, Tim
-----Original Message-----
Macpherson
Sent: Friday, February 21, 2003 1:23 PM
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-----
Sent: Friday, February 21, 2003 9:14 AM
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
_______________________________________________
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
_______________________________________________
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 middlegen-***@lists.sourceforge.net
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 middlegen-***@lists.sourceforge.net
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 middlegen-***@lists.sourceforge.net
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 middlegen-***@lists.sourceforge.net
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 middlegen-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/middlegen-user