Community
Participate
Working Groups
Some clients are using just the observables part of the data binding plugin. Also, when running in constrained environments (e.g. SWT BE, GWT), some of the dependencies of the converter/validator code such as BigDecimal are not available (see bug 252290 for an example). We should create a new smaller plug-in org.eclipse.core.databinding.observables which would have to be re-exported from org.eclipse.core.databinding for backwards compatibility.
McQ, +1?
There are some compiled-in dependencies in core to com.ibm.icu (even though it is listed as an optional dependency). In my test environments I always get runtime errors if these plugins are missing. We should find a way to dynamically discover whether they are available and use them if so, or use the java.text formats otherwise.
(In reply to comment #2) Do you get test failures, or compile errors? This code was added to properly convert from BigDecimal objects to String values , working around the broken support in the Java class libraries prior to 1.5 (see bug 180392 comment 27).
very cool
(In reply to comment #3) > (In reply to comment #2) > Do you get test failures, or compile errors? > > This code was added to properly convert from BigDecimal objects to String > values , working around the broken support in the Java class libraries prior to > 1.5 (see bug 180392 comment 27). > I get ClassNotFoundException at runtime, because core has one package from com.ibm.icu listed as an optional dependency, and another as a required dependency (I think com.ibm.icu.text)
(In reply to comment #5) > I get ClassNotFoundException at runtime You need the ICU4J replacement jar (look for "com.ibm.icu.base" on any Eclipse SDK build download page) which is 0.17 MB, or the full ICU4J. The optional dependency is optional because the replacement jar does not contain the referenced type(s).
I don't have enough time to do this for M5. Affects API so should be done before M6.
Created attachment 127519 [details] Patch
Created attachment 127520 [details] mine
Created attachment 127525 [details] new patch I messed with CVS history (by copying files over to the new plug-in project). Can you load org.eclipse.core.databinding.observables from HEAD and then apply this patch?
Created attachment 127532 [details] updated Some minor tweaks
IStatus is exposed as API in core.databinding, so we should re-export the equinox.common dependency
(In reply to comment #12) > IStatus is exposed as API in core.databinding, so we should re-export the > equinox.common dependency No, we don't re-export in cases like this. The only good reason for re-exporting is when you split plug-ins - the old plug-in will have to re-export the pieces that got split off to maintain backwards compatibility.
(In reply to comment #11) > Created an attachment (id=127532) > updated > > Some minor tweaks +1
Created attachment 127578 [details] even better This patch includes the changes for bug 267101 (split off properties). We will have to make a few more changes tomorrow when (hopefully) the webmaster will have renamed the directories for us. The separation is looking good, but there is one remaining issue: BindingException is being used in databinding.core.beans - do you think we can throw some other exception instead if we cannot find a getter or setter method?
I'm thinking either IllegalArgumentException or UnsupportedOperationException
Created attachment 127579 [details] Even more betterer Using IllegalArgumentException instead of BindingException
(In reply to comment #16) > I'm thinking either IllegalArgumentException or UnsupportedOperationException Depends on when we throw the exception - if it happens eagerly, right when observables are created, IllegalArgumentException would be appropriate. On the other hand, if any of these can happen later, when calling getValue() or setValue(), we should be using UnsupportedOperationException.
(In reply to comment #18) > Depends on when we throw the exception - if it happens eagerly, right when > observables are created, IllegalArgumentException would be appropriate. On the > other hand, if any of these can happen later, when calling getValue() or > setValue(), we should be using UnsupportedOperationException. Eagerly--it is thrown in BeanPropertyHelper.getPropertyDescriptor() when a bean lacks the named property for a particular bean class. The method is consulted before creating observables. The latest patch already uses IllegalArgumentException.
*** Bug 257786 has been marked as a duplicate of this bug. ***
Changes are in HEAD. I have requested a test build.
Marking fixed. The test build worked.
