Kevin, Another option is to exclude the few files (AnnotationProcessor6.java, CompileTimeLogger.java, SourceAnnotationHandler.java) which require Java 6 from the Eclipse source path. A bit clumsy and not terribly helpful if you plan to modify these files, though.
-Jeremy On Wed, Aug 5, 2009 at 10:54 AM, Kevin Sutter <[email protected]> wrote: > I agree that we need to do something. Running with our current module > setup > requires additional configuration to ensure that everything compiles > cleanly > [1]. Right now, I have to change openjpa-jdbc, openjpa-persistence, and > openjpa-persistence-jdbc to Java 6 in order to get a clean compile within > Eclipse. This is due to the JDBC 4 requirements and the annotation > processor changes. I'm okay with only doing the proposed compiler update > change for these three modules to start with. As it stands right now, it > looks and feels clumsy... > > Kevin > > [1] http://openjpa.apache.org/building.html > > On Wed, Aug 5, 2009 at 10:34 AM, Michael Dick <[email protected] > >wrote: > > > Resurrecting this thread. > > > > We're nearing the EOL for the non business version of Java SE 5.0 > (business > > edition will be available for quite a while - unless the new management > > changes the plan) [1] . > > > > When 5.0 goes out of service I'd propose upgrading OpenJPA to require JDK > > 6.0 to compile. The compiled bytecode can be set to 1.5 if that's a > > concern. > > I'd prefer to have all the modules use jdk 6 to avoid some of the > headaches > > we had in OpenJPA 1.0.x with supporting 1.4 but we can restrict it to > only > > the ones that need it (persistence, persistence-jdbc) if that's more > > amenable. > > > > In addition we can set up a new integration module which runs a subset of > > tests with Java 5. It will be optional (since Java 5 won't be readily > > available in 3 months), but at least we'd have some barometer for whether > > OpenJPA works in that environment. We'll have to do some classpath > > swizzling > > (like we did for 1.4 in the 1.0.x stream) but it *should* be possible. > > > > Thoughts, objections, stuff I've missed? > > > > [1] http://java.sun.com/products/archive/eol.policy.html > > > > -mike > > > > On Tue, Mar 31, 2009 at 2:29 PM, Michael Dick <[email protected] > > >wrote: > > > > > > > > > > > On Tue, Mar 31, 2009 at 2:07 PM, Pinaki Poddar <[email protected]> > > wrote: > > > > > >> > > >> Hi Craig, > > >> > This also meets my needs for a stable platform to run a new > > >> > personality without the new Java 6 dependencies. > > >> The current update in trunk runs a configuration that builds OpenJPA > > >> libraries with JDK6 compiler. But other configuration compiles and > runs > > our > > >> test corpus with JDK5. I do not think we have a configuration that > > compiles > > >> OpenJPA with JDK6, compiles test cases with JDK5 and runs test cases > > with > > >> JDK5. May be we should create one. Such configuration will simulate > the > > >> target JDK5 user environment with JDK6-compiled OpenJPA where the test > > case > > >> will play the equivalent role of user application. > > >> (Mike/Jeremy, are you tuned to this channel?) > > >> > > > > > > This is easier said than done. Depending on how strict one wants to be. > > If > > > we rely on the compiler settings (source=1.5, target=1.5) when we > compile > > > the testcases then at worst we'd have to add a separate maven module > for > > > JDK5 testcases. > > > > > > As we've seen in the past with JDK 1.4 this won't necessarily suffice. > We > > > may need to do some additional tweaking to put the 1.5 class libraries > on > > > the classpath, or (even more strict) we may need to rebuild with > maven's > > > JAVA_HOME set differently. > > > > > > I'd be fine with the first approach as part of a normal build (provided > > it > > > doesn't double execution time). Either of the later two would need to > be > > > optional (like we did with jdk 1.4). > > > > > > > > >> > mission statement for OpenJPA > > >> > "to the implementation of object persistence, including, but not > > >> > limited to, Java Persistence API, for distribution at no charge to > the > > >> public;" > > >> > > >> I fully agree and support this view. Compliance to a spec is a > necessary > > >> but not sufficient condition for sustainable interest in a project of > > >> OpenJPA's scope and breadth. Also one of the strongest feature of > > OpenJPA is > > >> its 'agnostic architecture' to promote the above charter. > > >> As a group we will benefit if we keep the charter in mind and consider > > >> possibilities to augment OpenJPA functionality that are beyond a > > standard > > >> specification. > > >> > > > > > > I agree that the agnostic architecture is a strength of OpenJPA and one > > > that we can leverage to promote additional solutions in the ORM space. > > That > > > said we are a JPA provider first and foremost and there are limits to > the > > > contortions that the "core" OpenJPA engine should make to support other > > > persistence frameworks. Especially those that have not been contributed > > to > > > Apache. > > > > > > To put it another way, our default behavior should be as JPA-like as > > > possible with the option for other frameworks to change the > configuration > > to > > > suit their needs. > > > > > > <snip> > > > > > > > > >> > 3. If the above appears to be a worthwhile target scenario to > > >> > support, then the dynamic class construction approach perhaps can > > >> > prove useful than hand-coding JDBC 4 dependency. > > >> > > >> > 4. We take a decision regarding these aspects by mid-April and > > >> > announce it to be effective from, say, mid-June. I am not keen on > > >> > exact duration of the prior notice but 2 months looked to be > > >> > reasonable. > > >> > > > > > > Fair enough. My concern lies mainly with the dynamic class construction > > and > > > the impact on performance. Introducing additional code path in order to > > > support a backleveled JDK seems wrong to me. Maybe I'm too anxious to > be > > on > > > the bleeding edge. > > > > > > -mike > > > > > > <more message history snipped> > > > > > > > > >
