Hi Philippe,

It looks like your attachment was dropped by the mailing list so I'm
guessing a little here. I did try setting all of this up from scratch with
one of my Eclipse projects, here's what I did.

Downloaded openjpa-project-0.9.7-incubating-source.zip and
openjpa-project-0.9.7-incubating-binary.zip and extract them (directory
/home/mikedd/downloads in my case).

Add the openjpa-* jar to my Eclipse project's classpath as an external jar.
I'm cheating a bit and picking up the other dependencies from my maven
repository, but that shouldn't matter.

Create a run definition for your application. Add
-javaagent:/home/mikedd/download/openjpa-project-0.9.7-incubating/openjpa-
0.9.7-incubating.jar as a vm arg. On the source tab add the source
directories for each OpenJPA subproject (ie /home/mikedd/downloads/openjpa-
project-0.9.7-incubating-source/openjpa-persistence/src/main/java ).

I think that's about it then you should be able to run your application,
debug OpenJPA or your entities if you want, etc. The mailing list has
rejected my message whenever I attach screenshots so I'll send them directly
to you instead.

Hope this helps,
-Michael Dick

On 5/20/07, Philippe Alexis <[EMAIL PROTECTED]> wrote:

Hi Everyone,

Not meaning to hi-jack it, I'll piggy-back on this thread because I've
made some progress setting up
OpenJPA as an Eclipse project thanks to some tips below from Michael. It's
been a long arduous road
over the whole weekend...

I went for compile-time enhancement via an Ant script as a user-defined
builder because as per the
attached screenshot, Eclipse-VM-params.PNG, (I hope having that is not
against the list's policy)
dynamic enhancement via -javaagent:${path_to_openjpa-*.jar} hasn't worked
so far and yields the error
message as shown in Eclipse's Console window. Is it working? I doubt it.
There's no [openjpac] output by Ant.
At least, the end of it says "Build Successful".

The other screenshot, Eclipse-BrokerFactory-not-found.png, is where I've
reached stepping through the project
this far, running the Main.java of the Deity example.
"You did not name the factory class with the required property
openjpa.BrokerFactory.
 Normally this property defaults appropriately; have you forgotten to
include all the OpenJPA jars in your classpath?"

Where would that be defined by default?
Would anyone be so kind as to post a similar screenshot of what's required
as Source folders to successfully debug
OpenJPA under Eclipse? I'm probably not too far but it's... late.

J-Philippe.

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.




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.
> >
> >
>


Reply via email to