| JDO integration (Please comment) [message #37394] |
Sun, 08 December 2002 18:22  |
Eclipse User |
|
|
|
Originally posted by: jwoolsey.activation.net
I am starting an Open Source JDO project and have been thinking heavily
about how to integrate this with Eclipse (My favourite J2EE editor).
There seems to be two ways to do JDO. Either Byte Code editing or source
code editing. I am thinking Source Code editing is simpler for both the
JDO code and the person using it. With Open Source there are no issues
with proprietary code. So here are my thoughts of how to integrate JDO
with Eclipse.
1) Make all JDO files source .jdo. Set up something that compiles .jdo
into .java. I think both can be made visible from Eclipse. Thus allowing
you to edit the .jdo file and view the .java file to see what hooks JDO
put in.
2) Parse the .java file and add the hooks automatically. Thus somehow
you define this class as JDO and every time you save it checks the JDO
hooks and moves them into the right position or adds them if they are
missing. This may be the best interface to JDO from a programmer
perspective.
3) Use 1 but with file names .jdo.java and .java.
I am very interested into input about which one of these ideas is the
best and which would be the easiest to integrate into Eclipse. If you
have a better idea I would love to hear it.
If you care my current thoughts of a design/development path are:
1) Write a compliant interface with JDO integrated with Eclipse.
2) Work on as many programmer features as possible. Things to make
developing in JDO faster and easier.
3) Once all of the standard JDO features are implemented write a
production library that concentrates on speed. (Caching assumes VM
specific caching, possibly support for 30 second caching)
4) Write a second production clustered library that is dependent on JMS.
- thanx - JAW
|
|
|
| Re: JDO integration (Please comment) [message #39306 is a reply to message #37394] |
Tue, 24 December 2002 07:20  |
| Eclipse User |
|
|
|
Originally posted by: rhill.wanadoo.fr
hi john,
i too am writing a jdo implementation, based on aspectj (much more like a
poc : http://sf.net/projects/ajdo). i have not yet committed to a
persistence back-end but i'm seriously
thinking about xml, coupled with xquery since there already are lots of
jdo-sql implementations - tho there are some drawbacks.. however my point
was this one :
* i think that the preprocess step might be transparent for the user, so
imho direct java_to_jdo_bytecode seems better to me. Also this transparency
isnot achieved today since most of jdo implementation integrate the
preprocess step into ides through ant build files. this is perfect if your
build process is based on ant ; however if not it's really a pain. My idea
is that a JdoBuilder plugin should be the key to the said transparency
(that is just like the JavaBuilder : the "Build Project" option should 1.
compile the .java, 2. enhance bytecode). THe java to enhanced java might
remain an alternative option - not recommended : user shouldnot look at what
is generated - for more info, user should read the specs.
* however if you really want to do source processing, proposition 2 seems
better to me at first sight. Tho it is _not_ the case. Indeed the programmer
will be "confused" since the source he's working will be altered. A 1-like
solution might then be preferable. this solution might be quite elegant
since it will enable incremental preprocessing. But if i were the user i
would be kinda annoyed seeing my project polluted by many files (imagine you
have a quite big domain - say 150 or 200 business entities !
my 2 cents thoughts..
regards,
-- gd
"John Woolsey" <jwoolsey@activation.net> wrote in message
news:3DF38DDC.B26E235D@activation.net...
> I am starting an Open Source JDO project and have been thinking heavily
> about how to integrate this with Eclipse (My favourite J2EE editor).
> There seems to be two ways to do JDO. Either Byte Code editing or source
> code editing. I am thinking Source Code editing is simpler for both the
> JDO code and the person using it. With Open Source there are no issues
> with proprietary code. So here are my thoughts of how to integrate JDO
> with Eclipse.
>
> 1) Make all JDO files source .jdo. Set up something that compiles .jdo
> into .java. I think both can be made visible from Eclipse. Thus allowing
> you to edit the .jdo file and view the .java file to see what hooks JDO
> put in.
>
> 2) Parse the .java file and add the hooks automatically. Thus somehow
> you define this class as JDO and every time you save it checks the JDO
> hooks and moves them into the right position or adds them if they are
> missing. This may be the best interface to JDO from a programmer
> perspective.
>
> 3) Use 1 but with file names .jdo.java and .java.
>
> I am very interested into input about which one of these ideas is the
> best and which would be the easiest to integrate into Eclipse. If you
> have a better idea I would love to hear it.
>
> If you care my current thoughts of a design/development path are:
> 1) Write a compliant interface with JDO integrated with Eclipse.
> 2) Work on as many programmer features as possible. Things to make
> developing in JDO faster and easier.
> 3) Once all of the standard JDO features are implemented write a
> production library that concentrates on speed. (Caching assumes VM
> specific caching, possibly support for 30 second caching)
> 4) Write a second production clustered library that is dependent on JMS.
>
> - thanx - JAW
|
|
|
| Re: JDO integration (Please comment) [message #587930 is a reply to message #37394] |
Tue, 24 December 2002 07:20 |
| Eclipse User |
|
|
|
Originally posted by: rhill.wanadoo.fr
hi john,
i too am writing a jdo implementation, based on aspectj (much more like a
poc : http://sf.net/projects/ajdo). i have not yet committed to a
persistence back-end but i'm seriously
thinking about xml, coupled with xquery since there already are lots of
jdo-sql implementations - tho there are some drawbacks.. however my point
was this one :
* i think that the preprocess step might be transparent for the user, so
imho direct java_to_jdo_bytecode seems better to me. Also this transparency
isnot achieved today since most of jdo implementation integrate the
preprocess step into ides through ant build files. this is perfect if your
build process is based on ant ; however if not it's really a pain. My idea
is that a JdoBuilder plugin should be the key to the said transparency
(that is just like the JavaBuilder : the "Build Project" option should 1.
compile the .java, 2. enhance bytecode). THe java to enhanced java might
remain an alternative option - not recommended : user shouldnot look at what
is generated - for more info, user should read the specs.
* however if you really want to do source processing, proposition 2 seems
better to me at first sight. Tho it is _not_ the case. Indeed the programmer
will be "confused" since the source he's working will be altered. A 1-like
solution might then be preferable. this solution might be quite elegant
since it will enable incremental preprocessing. But if i were the user i
would be kinda annoyed seeing my project polluted by many files (imagine you
have a quite big domain - say 150 or 200 business entities !
my 2 cents thoughts..
regards,
-- gd
"John Woolsey" <jwoolsey@activation.net> wrote in message
news:3DF38DDC.B26E235D@activation.net...
> I am starting an Open Source JDO project and have been thinking heavily
> about how to integrate this with Eclipse (My favourite J2EE editor).
> There seems to be two ways to do JDO. Either Byte Code editing or source
> code editing. I am thinking Source Code editing is simpler for both the
> JDO code and the person using it. With Open Source there are no issues
> with proprietary code. So here are my thoughts of how to integrate JDO
> with Eclipse.
>
> 1) Make all JDO files source .jdo. Set up something that compiles .jdo
> into .java. I think both can be made visible from Eclipse. Thus allowing
> you to edit the .jdo file and view the .java file to see what hooks JDO
> put in.
>
> 2) Parse the .java file and add the hooks automatically. Thus somehow
> you define this class as JDO and every time you save it checks the JDO
> hooks and moves them into the right position or adds them if they are
> missing. This may be the best interface to JDO from a programmer
> perspective.
>
> 3) Use 1 but with file names .jdo.java and .java.
>
> I am very interested into input about which one of these ideas is the
> best and which would be the easiest to integrate into Eclipse. If you
> have a better idea I would love to hear it.
>
> If you care my current thoughts of a design/development path are:
> 1) Write a compliant interface with JDO integrated with Eclipse.
> 2) Work on as many programmer features as possible. Things to make
> developing in JDO faster and easier.
> 3) Once all of the standard JDO features are implemented write a
> production library that concentrates on speed. (Caching assumes VM
> specific caching, possibly support for 30 second caching)
> 4) Write a second production clustered library that is dependent on JMS.
>
> - thanx - JAW
|
|
|
Powered by
FUDForum. Page generated in 0.02931 seconds
] 
Search
Help
Register
Login
Home
