Yes, somehow that got missed in the jpt.common.core plugin addition.
I updated that and the enablement variables, which actually don't
include "jpaPlatform" or "jpaPlatformGroup", but do include
"config", which gives a JptLibraryProviderInstallOperationConfig.
There are property testers "jpaPlatform" and "jpaPlatformGroup"
registered for the sub-type
JpaLibraryProviderInstallOperationConfig.
Thanks,
- Paul
On 4/22/2011 8:19 AM, Dmitry Geraskov wrote:
Thanks, Paul,
I try to implement our Library Validator and noticed that your
information about extension point
org.eclipse.jpt.common.core.libraryValidators is obsolete.
Look at libraryValidators.exsd.
It references to old
org.eclipse.jpt.core.libval.LibraryValidator (package
should be changed)
and jpaPlatform which was removed and will be added in M7 again,
It doesn't mention supported jpaPlatformGroup property.
Probably you would like to know/fix this.
Thanks, Dmitry.
22/04/2011 14:23, Paul Fullbright wrote:
Sorry,
that should be:
"You should only need one user library *provider* (the base one
in jpa.core) from now on. "
- Paul
On 4/22/2011 7:21 AM, Paul Fullbright wrote:
Yes, we did this to remove just this
problem, multiple instances of "User Library" appearing in the
drop down. This could also have occurred when changing the
facet version or platform if there are multiple user library
providers just for *your* platform.
You shouldn't need to implement anything checking for generic
JPA classes. Library validators are cumulative in that you'll
automatically get the generic JPA library validator, but then
you'll also get your library validator checking for Hibernate
classes. Our EclipseLink library validator only looks for a
version value in the library, no JPA classes.
Also note that any existing supported library providers might
be deprecated if you have multiple to support. You should
only need one user library validator (the base one in
jpa.core) from now on.
- Paul
On 4/22/2011 7:08 AM, Dmitry Geraskov wrote:
Thanks, Paul,
Sorry, I wrote the name from memory. They are really named
"User Library".
This means I need to remove our library provider extension
and use validator extension instead to configure your
library provider for our platform, right?
Yes, I can use the validator extension.
Dmitry
22/04/2011 13:59, Paul Fullbright wrote:
We don't have one that says "Library
Provider". Do you mean "User Library"?
I could see that being a problem, if so. Is it a
possibility for you to add a "Library Validator"
extension? You can check out our
"eclipseLinkLibraryValidator" extension for what would be
necessary.
- Paul
On 4/22/2011 6:51 AM, Dmitry Geraskov wrote:
They are named just "Library Provider" (in new jpa
project wizard).
One of them is our Library Provider - extension of
"wtp-user-library-provider"
And another is yours.
Dmitry Geraskov
22/04/2011 13:38, Paul Fullbright wrote:
Which of our library providers
appears for Hibernate?
What are the two library providers with the same name?
- Paul
On 4/22/2011 4:01 AM, Dmitry Geraskov wrote:
Hi, Neil,
I noticed that yours "Library Provider" appears for
Hibernate platform now. The problem with it that it
doesn't validate presence of hibernate-specific
annotations in class path. Is this a bug?
Also because of this for Hibernate platform I have 2
Library Providers with the same name.
Should now extend your Library Provider somehow with
my validator (if it is possible?) instead of
providing my own Library Provider?
Thanks for help,
Dmitry Geraskov
14/04/2011 17:25, Neil Hauge wrote:
Yep, you should be able to
leave your lib providers as they are.
Neil
Dmitry Geraskov<dgeraskov@xxxxxxxxxx>
wrote:
Thanks, Nail for the help.
It is too late with renames ;) (it seems I have
found all the
associations between old and new classes)
And as you restored the platform property I'll
be able to use my old
library provider without alters?
Thanks,
Dmitry Geraskov
14/04/2011 16:44, Neil Hauge wrote:
Dmitry,
Please pick up the latest WTP I-build and you
will find the platform variable restored. As
for provisional API changes, please let us
know if you run into any difficulties figuring
things out and we will help with the
migration. Unfortunately we were not able to
document every method level change for this
release.
Neil
Dmitry Geraskov<dgeraskov@xxxxxxxxxx>
wrote:
Hey, Neil,
I see the "New Help for Old Friends VI"
updated but it is too superficial.
It doesn't say about any API rename, methods
updates and so on.
JavaJoinColumnEnabledRelationshipReference->JavaMappingJoinColumnRelationship
JavaJoinTableEnabledRelationshipReference
->JavaMappingJoinTableRelationship
JavaRelationshipReference->JavaMappingRelationship
JavaOneToManyRelationshipReference2_0->JavaOneToManyRelationship2_0
...
also some methods were renamed.
We created our own library provider for
hibernate platform. But you
reimplemented library providers and not
there is no variable
"jpa_platform" which was used for
restricting provider to platform.
What should I do to restrict out library
provider to hibernate platform?
Thanks,
Dmitry
01/04/2011 18:35, Neil Hauge wrote:
Dmitry,
We tend to publish our changes in
real-time on the dali-dev mailing
list (for most changes). I can gather the
links to these posts and
update the migration wiki. But you are
right...the wiki should be
updated as well.
Neil
On 4/1/2011 7:16 AM, Dmitry Geraskov
wrote:
Hey, guys,
you changed API much in Indigo version,
but the changes are not
reflected in http://wiki.eclipse.org/New_Help_for_Old_Friends_VI.
Did you forget about it?
Dmitry Geraskov.
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
_______________________________________________
dali-dev mailing list
dali-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dali-dev
--
Paul Fullbright
Eclipse Java Persistence Tools (Dali) Development
Oracle
|
