Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.
Bug 324292 - Type of packages with only abstract classes can not be determined
Summary: Type of packages with only abstract classes can not be determined
Status: CLOSED WONTFIX
Alias: None
Product: EMF
Classification: Modeling
Component: cdo.core (show other bugs)
Version: 4.2   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Eike Stepper CLA
QA Contact: Eike Stepper CLA
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-02 07:37 EDT by Egidijus Vaisnora CLA
Modified: 2012-10-31 07:31 EDT (History)
1 user (show)

See Also:
stepper: review-

Attachments
patch v1 (798 bytes, patch)
2010-09-02 08:40 EDT, Egidijus Vaisnora CLA 		no flags Details | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Egidijus Vaisnora CLA 2010-09-02 07:37:41 EDT 
I have EPackage which has one abstract EClass (lets call it BaseEClass and BaseEPacakge) and have other EClasses which depends on abstract one and are in different EPackages.
Problem is that created CDOPackageUnit for BaseEPacakge has type UNKNOWN (it has all classes inside abstract). If I load such EClass (name it EClass A) which extends BaseEClass from the server, class A has unresolved structure, because that BaseEClass was not resolved. Reason is in CDOSessionImpl.loadPackages method call packageUnit.getOriginalType().isGenerated() - it throws IllegalStateException because that state is UNKNOWN and BaseEPacakge become not loaded.
Comment 1 Eike Stepper CLA 2010-09-02 07:40:46 EDT 
Do you know how we can better determine isGenerated() from an EPackage?
Comment 2 Egidijus Vaisnora CLA 2010-09-02 08:40:53 EDT 
Created attachment 178036 [details]
patch v1

isGenerated when type is not DYNAMIC
Comment 3 Egidijus Vaisnora CLA 2010-09-02 08:55:45 EDT 
However additionally it makes some concerns about UNKNOWN type for me. Why is decided to put type UNKNOWN instead of NATIVE? in this case we for sure know that EPackage is not DYNAMIC (ePackage.getClass() != EPackageImpl.class), hence it is generated! Now we attempt to find out if it is LEGACY and we find out that LEGACY cannot be determined (EClass are abstract). Instead of leaving type NATIVE, which will show you that package is generated, we choose UNKNOWN type. Later this shall corrupt future work.
Comment 4 Egidijus Vaisnora CLA 2010-09-02 08:56:34 EDT 
For instance we already know that UNKNOWN means generated
Comment 5 Eike Stepper CLA 2010-09-03 07:21:06 EDT 
As discussed on Skype, we'll instead throw an exception rather than returning UNKNOWN. In case of this exception the user will know that he must either:

- Add the META-INF/CDO.MF marker file (empty) to indicate that it's a NATIVE model
- Manually register the desired type in the CDOPackageTypeRegistry (useful for standalone)
Comment 6 Eike Stepper CLA 2011-06-23 04:27:36 EDT 
Moving all open problem reports to 4.0
Comment 7 Eike Stepper CLA 2012-06-05 07:30:30 EDT 
Moving all open bug reports to 4.1 because the release is very near and it's hghly unlikely that there will be spare time to address 4.0 problems.

Please make sure that your patches can be applied against the master branch and that your problem is not already fixed there!!!
Comment 8 Eike Stepper CLA 2012-08-14 22:57:55 EDT 
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Comment 9 Eike Stepper CLA 2012-10-31 07:31:32 EDT 
No activity or ping here for years. Please reopen this bug if you feel a need.