[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dali-dev] Dali and Public API changes
|
Massive is probably a good word to describe the changes to Dali this
year. We have made major improvements to our model in the area of
concurrency, reusability, maintainability, and performance. Some of
these changes were driven by our addition of JAXB persistence tooling.
We think these changes will greatly benefit Dali and the adopters of
Dali, but as with all things, there is a cost.
Do you have any tips on how adopters are meant to use Dali and support it across of Eclipse 3.7/3.8 ?
I don't think it would be feasible to have a product that extends Dali
3.0.x (Indigo) and Dali 3.2.x (Juno) at the same time. The changes
between the two are many, and as a result, a number of provisional API's
have changed.
How do your own adopters at Oracle do this?
I think there is a lot of variability on this among the entire adopter
community. Some adopters choose to build on top of a specific release
train version of Eclipse, without trying to maintain compatibility with
other versions within the same code base. Where support for multiple
release trains is needed in a particular release, multiple code streams
and packages are used. Some adopters have seen this cost as worthwhile
for the adoption of rapidly improving and expanding components.
Is there any chance that latest Dali release can run on both 3.7 and 3.8/4.2 and we could do it that way ?
(i.e. depend on Dali M7 from both 3.7 and 3.8 codebases)
Actually, you could potentially run our latest release (Dali 3.1 - Dec
2011) on both Eclipse 3.7 and 3.8. There is some compatibility code in
the 3.1 release to allow Dali clients to use the same code for 3.0 and
3.1. This was done because 3.1 was not based on a new release train,
but instead it was based on the same Indigo train. This could not be
done with 3.2M7.
All of that said, this has made me think of something that we should be
doing. In addition to doing a new and noteworthy that covers end-user
functionality, we need a new and noteworthy specifically for Dali
adopters. This would be a per milestone summary of the types of changes
that will specifically benefit/be of interest to adopters. This would
more easily allow adopters to be aware of (and perhaps encourage
participation in) some of the larger scale changes to our model. It
would go hand in hand with a migration guide to help adopters move to
the new code. This would be in addition to the existing weekly status
emails.
This also raises the question of what we can do moving forward regarding
a public API for Dali. This has been a hot topic of late, and I can
assure everyone that this will be a large discussion point for our
planning meetings for Dali Kepler. I would guess that some of you
will be in attendance to ensure this is discussed. : )
This is all a balancing act, and I hope we can find the right point on
the scale to ensure that Dali continues to evolve and improve while
making sure our adopters can benefit from those improvements.
As always, we welcome you thoughts and contributions.
Neil
On 4/24/2012 1:50 AM, Max Rydahl Andersen wrote:
<rant>
Dali is almost always the API we cannot support across eclipse versions with the same codebase - normally in all other API's we've been able to use
proper interfaces or a in a few places a bit of reflection to work around it - but for Dali the changes are just too massive.
</rant>
Do you have any tips on how adopters are meant to use Dali and support it across of Eclipse 3.7/3.8 ?
How do your own adopters at Oracle do this ?
Is there any chance that latest Dali release can run on both 3.7 and 3.8/4.2 and we could do it that way ?
(i.e. depend on Dali M7 from both 3.7 and 3.8 codebases)
/max
On Apr 18, 2012, at 16:14 , Neil Hauge wrote:
Sorry about this Dmitry. There were indeed a lot of changes this year, and we could have done a better job detailing the changes in the New Help for Old Friends wiki. We are making this a major focus for the next release, where we hope to declare a lot of provisional API as public, and also document provisional API changes as they occur.
We have a number of these changes you mentioned documented in various places, so expect a number of replies pointing you to this info. I will make sure this info gets rolled up into the Old Friends wiki.
Thanks,
Neil
On 4/18/2012 5:54 AM, Dmitry Geraskov wrote:
Hi, guys,
as you probably know hibernate depends on the JPT plugins. And almost every change in provisional API affects us.
Would be nice if you try to describe the changes more carefully.
On the page where they are expected to be found
http://wiki.eclipse.org/New_Help_for_Old_Friends_VII
I see only 2 issues which changed provisional API (the author is Karen Butzke in both). And the list for sure is not complete. I found the following not described changes:
Classes which were removed?
org.eclipse.jpt.common.utility.model.value.WritablePropertyValueModel;
org.eclipse.jpt.jpa.core.context.java.JavaStructureNodes;
org.eclipse.jpt.jpa.ui.navigator.JpaNavigatorProvider;
org.eclipse.jpt.jpa.core.context.Table.Owner;
org.eclipse.jpt.jpa.core.resource.java.AnnotationContainer;
org.eclipse.jpt.jpa.core.resource.java.JavaResourcePersistentAttribute
org.eclipse.jpt.jpa.ui.structure.JpaStructureProvider
org.eclipse.jpt.jpa.core.resource.java.NamedQueriesAnnotation
org.eclipse.jpt.jpa.core.resource.java.NamedNativeQueriesAnnotation
org.eclipse.jpt.jpa.core.resource.java.AttributeOverridesAnnotation
org.eclipse.jpt.jpa.core.resource.java.AssociationOverridesAnnotation
Disappeared
JptJpaCorePlugin.rebuildJpaProject(getProject());
JavaPersistentAttribute.getResourcePersistentAttribute()
Chaged
JavaGeneratorContainer.Owner, OrmJoinColumn.Owner and other "owners"
JpaJpqlQueryHelper made abstract
JavaResourceAnnotatedElement.addAnnotation(int, string, string)
Iterable->Iterator
JavaResourceAnnotatedElement.annotations(String, String)
PersistentType.attributes()
PersistenceUnit.mappingFileRefsContaining(...)
Dmitry Geraskov,
Hibernate tools developer
_______________________________________________
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
