Re: [eclipselink-dev] Facilitating migration from Toplink / Toplink Esse

[Mitesh Meswani <Mitesh.Meswani@xxxxxxx>]

Thanks Shaun for bringing this up. I will add this to scope of the work. 
Do we have list of such changes that we can refer against?

From discussions so far, the only outstanding issue is about packaging. 
We have following options on table from current discussion. Can you 
please vote with the option you prefer.

1. Ship this as part of eclipselink.jar and 
org.eclipse.persistence.jpa.jar and enable the compatibility mode with a 
system property
   Pros :
   -Toplink JPA applications work against Eclipselink without requiring 
any additional artifacts
   -Fits within current build infrastructure
   Cons:
   -Conceptually not as "clean" approach as option 2 below

2. Ship as a separate jar.
   Pros:
   -Conceptually cleaner approach
   Cons:
   -Users would need additional artifacts to run Toplink applications

Thanks,
Mitesh
     
Shaun Smith wrote:
> Behavioral difference between TopLink Essentials and EclipseLink have 
> to be dealt with in this "auto migration" initiative.  For example, 
> the handling of zero id values for primitive data types (i.e, int, 
> long) [1] [2].  This one is easy to deal with by defining the property 
> eclipselink.allow-zero-id=true.
>
>    Shaun
>
> [1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=277804
> [2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=278216
>
> Mitesh Meswani wrote:
> > Bill Shannon wrote:
> > > Mitesh Meswani wrote on 08/28/09 10:28:
> > > > Tom Ware wrote:
> > > > > I am not fond of having a default version of EclipseLink ever 
> > > > > allow itself to be selected when the user has specifically 
> > > > > requested TopLink Essentials in their persistence.xml.
> > > > >
> > > > > Bill's suggestion of some kind of an add-on is more palatable to 
> > > > > me if we decide   we want to have a way of having EclipseLink 
> > > > > select itself in place of Essentials.
> > > > I think I am not clear about what that means in terms of 
> > > > implementation. Can we explore that a bit. Here is my understanding 
> > > > if we go that route:
> > > >
> > > >     * Add (say) org.eclipse.persistence.jpa.ToplinkPersistenceProvider
> > > >       that extends org.eclipse.persistence.jpa.PersistenceProvider and
> > > >       related PersistenceInitializationHelper (say)
> > > >       ToplinkPersistenceInitializationHelper
> > > >     * ToplinkPersistenceInitializationHelper would wire up a 
> > > > subclass of
> > > >       JavaSECMPInitializer that would accept Toplink as provider
> > > >     * Will above classes be part of default eclipselink 
> > > > distribution as
> > > >       part of eclipselink.jar and org.eclipse.persistence.jpa.jar?
> > >
> > > I was thinking that the class would have the exact class name of the
> > > TopLink provider - oracle.toplink.essentials.whatever.  No magic would
> > > be needed to translate the class name in the application to the actual
> > > class being used.  Ideally, that new class would be the one that would
> > > translate the property names, but I don't know how this all fits 
> > > together
> > > to know if that's the right place to put that functionality.
> > That would be cleanest. However, AFAIK, the properties are processed 
> > at place in code that is not aware of how it is being invoked. We 
> > should look into having this implemented as above once we get into 
> > code to implement this.
> >
> > Thanks,
> > Mitesh
> >
> > > These new classes would be packaged in a separate jar file, a separate
> > > OSGi module, that depends on the EclipseLink module.  A user could
> > > uninstall that module and install the real TopLink module if they
> > > wanted to.
> > >
> > > Does that work?
> > _______________________________________________
> > eclipselink-dev mailing list
> > eclipselink-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>
> --
> Oracle <http://www.oracle.com>
> Shaun Smith | Principal Product Manager
> Phone: +19055023094
> Oracle Server Technologies, Oracle TopLink
> ORACLE Canada | 110 Matheson Boulevard West, Suite 100, Mississauga, 
> Ontario | L5R 3P4
> Green Oracle <http://www.oracle.com/commitment> Oracle is committed to 
> developing practices and products that help protect the environment
> ------------------------------------------------------------------------
>
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>