Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 324292

Summary:

Type of packages with only abstract classes can not be determined

Product:

[Modeling] EMF

Reporter:

Egidijus Vaisnora <vaisegid>

Component:

cdo.core

Assignee:

Eike Stepper <stepper>

Status:

CLOSED WONTFIX

QA Contact:

Eike Stepper <stepper>

Severity:

normal

Priority:

CC:

stepper

Version:

4.2

Flags:

stepper: review-

Target Milestone:

---

Hardware:

All

OS:

All

Whiteboard:

Attachments:

Description	Flags
patch v1	none

Description Egidijus Vaisnora

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

2010-09-02 07:40:46 EDT

Do you know how we can better determine isGenerated() from an EPackage?

Comment 2 Egidijus Vaisnora

2010-09-02 08:40:53 EDT

Created attachment 178036 [details]
patch v1

isGenerated when type is not DYNAMIC

Comment 3 Egidijus Vaisnora

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

2010-09-02 08:56:34 EDT

For instance we already know that UNKNOWN means generated

Comment 5 Eike Stepper

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

2011-06-23 04:27:36 EDT

Moving all open problem reports to 4.0

Comment 7 Eike Stepper

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

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

2012-10-31 07:31:32 EDT

No activity or ping here for years. Please reopen this bug if you feel a need.