RE: [eclipselink-dev] Maven Updates

["Markus Karg" <markus.karg@xxxxxxx>]

Tom,

thank you for the explanation.

I checked the API
http://java.sun.com/javaee/6/docs/api/index.html?javax/persistence/Persisten
ce.html and understand what you mean. I just think it is strange that there
is no standard implementation but the provider will come up with it's own.
The way the spec is made, there can only be one JPA provider ever. This
might not be a problem right now, but I wonder why the authors did not
decide that there could be plenty at the same time, providing a standard
Persistence class that servers as a registry.

Anyways, the spec is like it is, we have to just accept it (as so often).
;-)

Thanks
Markus

> -----Original Message-----
> From: eclipselink-dev-bounces@xxxxxxxxxxx [mailto:eclipselink-dev-
> bounces@xxxxxxxxxxx] On Behalf Of Tom Ware
> Sent: Donnerstag, 14. Januar 2010 21:02
> To: Dev mailing list for Eclipse Persistence Services
> Subject: Re: [eclipselink-dev] Maven Updates
> 
> Hi Markus,
> 
>    The interfaces you compile against will be the same between vendors.
> They
> are defined in the specification.  The classes that may be different
> are the
> classes with actual implementation.
> 
>    In the javax.persistence package there are two classes,
> javax.persistence.Persistence and
> javax.persistence.spi.PersistenceProviderResolverHolder.  The
> implementations of
> these classes is not set out by the spec and as such may be different
> between
> vendors.  We have been instructed by various spec leads that that is
> the way
> this spec is designed and that the spec does not provide the
> implementation of
> these classes.
> 
>    We also include a couple of classes that enable OSGi usage, but they
> are in
> org.eclipse.persistence.* packages.
> 
>    The bottom line is that if you only depend on interfaces, if you
> ever have a
> compile issue moving between vendors, it will be a bug in the code of
> one of the
> vendors since those interfaces are part of the spec.
> 
> -Tom
> 
> Markus Karg wrote:
> > Tom,
> >
> > thank you for your comments, see more below.
> >
> >>    For the group id issue - due to the way the specification is
> >> designed, there
> >> are implementations in the javax.persistence classes (i.e. code that
> >> will be
> >> run, rather than just interfaces - e.g. Persistence.class,
> >> ProviderResolverHolder.class + some Provider resolves)  The
> >> javax.persistence
> >> jar we produce is truly an EclipseLink version of javax.persistence.
> I
> >> would
> >> expect that different implementers of javax.persistence have
> different
> >> code in
> >> several of the classes because of the way the spec classes are
> defined.
> >> For
> >> that reason, it seems as if the eclipselink group is a reasonable
> place
> >> for that
> >> bundle.
> >
> > But how can get guaranteed then that when I compile my project
> against
> > EclipseLink's persistence API it will run also on a different
> > implementation?
> >
> > Thanks
> > Markus
> >
> > _______________________________________________
> > eclipselink-dev mailing list
> > eclipselink-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
> _______________________________________________
> eclipselink-dev mailing list
> eclipselink-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev