Patrick also mentioned writing an IDEA plug-in (not sure if that's the right
name) that would do the enhancement. I believe he ran into a few snags
getting access to IntelliJ jars. This or something similar might be a good
solution for you. Ideally we'll have Eclipse, IDEA and NetBeans plugins
someday.
I've worked out the snags, actually. Need to figure out how to publish
it now, since it has some dependencies on IDEA jars.
-Patrick
On 5/17/07, Michael Dick <[EMAIL PROTECTED]> wrote:
Hi James,
I don't know how easy this is to do with IDEA, but what I've done in Eclipse
is to create the project via mvn eclipse:eclipse then create a run
definition for org.apache.openjpa.enhance.PCEnhancer. With no other
classpath tweaking it enhances the entities in the output directory and I'm
up and running.
Another alternative would be to use dynamic enhancement when you run in your
IDE. In eclipse you can just add -javaagent:${path.to.openjpa-xxx.jar} as a
vm argument and you won't have to run the enhancer at all.
Patrick also mentioned writing an IDEA plug-in (not sure if that's the right
name) that would do the enhancement. I believe he ran into a few snags
getting access to IntelliJ jars. This or something similar might be a good
solution for you. Ideally we'll have Eclipse, IDEA and NetBeans plugins
someday.
Eclipse also allows user defined builders to be run in addition to the
default java compiler. The builders can be ant scripts or java programs -
either one should be able to enhance your entities. I have never used IDEA,
but I suspect it includes a similar concept.
All that being said I'm not trying to dismiss your idea of adding a cglib
interface - I'm just sharing what has worked for me and some ideas that
might also work for you. It's a bit specific to Eclipse, but from what I've
heard IDEA is a very good IDE and I suspect it can do them as well.
-Mike
On 5/17/07, James.Strachan <[EMAIL PROTECTED]> wrote:
>
>
> Firstly before I start, openjpa is a great piece of software; I'm
> particularly fond of the documentation and in particular the query
> language
> parts. The CSS for the site is also awesome :)
>
> However compared to hibernate, openjpa is still pretty painful to use from
> an end users perspective and I don't think this should be the case; plus I
> don't think it'll take much time to fix. While the pain is still fresh in
> my
> mind I thought I'd post on how much more painful openjpa is to use in a
> project. If you're short on time, the basic idea is its that bytecode post
> processing stuff thats to blame :). Yes I know its probably faster that
> way
> - its just so painful for Java programmers to work with. (And yes I know
> one
> day we'll all have IDE plugins that hide the bytecode stuff etc etc).
>
> So the first thing is having to mess with your build (ant or maven) to get
> the post processing properly integrated. Depending on if you have
> persistent
> entities in your main or test area this can often trip you up a little (as
> it did me). I don't know about folks on this list but the whole idea of
> having to mess with my maven build gives me the jitters :). When you get
> that far & the maven planets are aligned with openjpa, the next hurdle you
> hit is how do you run stuff in your IDE. If like me you use IDEA and maven
> 2, the project gets auto-created by default for all projects you work on.
> However these don't work when you use openjpa as you hit the dreaded
> 'cannot
> function at all as you've not run the up front bytecode post processor you
> dummy!' type error when trying to run stuff in your IDE.
>
> So you then add the maven-generated classes to the front of the classpath
> in
> your project. Hooray, after a day or two's work, you can now actually use
> openjpa in your IDE and your build. YAY! The downside is that now when
> navigating around your Java code, whenever you navigate into an entity
> bean,
> IDEA shows you the bytecode - not the source code as its confused since
> the
> bytecode generated stuff is different to the source code it knows about.
> So
> now you're faced with a dilemma - choose between navigating nicely around
> your source code - or being able to actually run/debug your application. I
> won't even get into the refactoring pain or having to continuously run
> maven
> builds while developing code to avoid getting code completion/compile
> errors
> etc. (I prefer to keep in my IDE where possible).
>
> Compare this whole malarkey with hibernate. You add hibernate to your pom,
> generate your project and you're good to go. No messing with your project
> build; no messing with some secret ninja IDE stuff to be able to actually
> run & debug your code while still being able to actually navigate the
> source. It just works. Now it might work in a crappy & slow way and
> openjpa
> might be way way more efficient and powerful and whatnot - but I'd rather
> have a cheap car that just works than a ferrari that you can only drive on
> a
> tuesday if its sunny, but not too hot and refuses to even start if its
> wet.
>
> FWIW I've just given up using openjpa for development; its just way too
> painful. (I'm even hacking projects I work on so I use openjpa in the
> maven
> build but explicitly switch to hibernate in development mode; yeah its
> more
> work but at least I can use my IDE properly again).
>
> I'm cool with putting post processing into the build system (though that
> should really only be an optimisation); but please can we have some
> inefficient but usable reflection/cglib type approach so folks can easily
> switch from hibernate to openjpa (and stay there) without pulling out our
> hair & swearing too much - or sneaking back at the first opportunity to
> get
> an easy life?
>
> Please don't take this mail the wrong way - I truly want openjpa to be a
> success, its a great piece of software. Its just a bit too hard to use out
> of the box right now. I'd truly like it to be trivial to switch from
> hibernate to openjpa and never have to go back.
>
> How hard is it to add a reflection/cglib type alternative to the upfront
> bytecode generation (like hibernate does) to save us from the
> development-time pain?
>
> --
> James
> -------
> http://macstrac.blogspot.com/
>
> --
> View this message in context:
>
http://www.nabble.com/the-pain-of-post-processing-bytecode-%28another-beg-for-a-simple-reflection-cglib-alternative-like-hibernate%29-tf3770760.html#a10660986
> Sent from the open-jpa-dev mailing list archive at Nabble.com.
>
>
--
Patrick Linskey
202 669 5907
