Bug 201947

Comment 1 Christian Damus 2007-09-10 11:34:31 EDT

In the case of EMF's usage of the workspace API for creating markers, this is only in the ValidateAction internally.  For clients of the ValidateAction, if they are deployed without the workspace, then obviously they don't need the action to create markers as a side-effect.

However, in the EMF Validation case, the MarkerUtil is API.  Clients invoking it expect it to create markers.  The workspace is implicit in this API's contract.  This API possibly should have been defined in the org.eclipse.emf.validation.ui.ide plug-in, which has other dependencies on the IDE.

I'm not sure that it is as easy as just having this utility fail to create markers if the workspace isn't available, silently pretending to succeed.  The problem is in the MarkerUtil::createMarkers(...) variant that accepts an IMarkerConfigurator argument.  This interface uses the IMarker interface in its API, and some VMs' class verification will cause the initialization of the MarkerUtil class to fail because of it.  The workspace can't be made optional for the IMarkerConfigurator API.

Ideas?

Comment 2 Will Horn 2007-09-18 17:06:14 EDT

(In reply to comment #1)
> In the case of EMF's usage of the workspace API for creating markers, this is
> only in the ValidateAction internally.  For clients of the ValidateAction, if
> they are deployed without the workspace, then obviously they don't need the
> action to create markers as a side-effect.
> 
> However, in the EMF Validation case, the MarkerUtil is API.  Clients invoking
> it expect it to create markers.  The workspace is implicit in this API's
> contract.  This API possibly should have been defined in the
> org.eclipse.emf.validation.ui.ide plug-in, which has other dependencies on the
> IDE.
> 
> I'm not sure that it is as easy as just having this utility fail to create
> markers if the workspace isn't available, silently pretending to succeed.  The
> problem is in the MarkerUtil::createMarkers(...) variant that accepts an
> IMarkerConfigurator argument.  This interface uses the IMarker interface in its
> API, and some VMs' class verification will cause the initialization of the
> MarkerUtil class to fail because of it.  The workspace can't be made optional
> for the IMarkerConfigurator API.
> 
> Ideas?
> 

Thanks for looking into it, Christian.  I'm new to the Validation plugin, so I'm not too familiar with how it works.  Are you saying it is required to have a workspace for Validation to work or just that you can't make the marker functionality optional since it's public API?

Do you have a suggested workaround for an RCP application that does not have a workspace?  Can I just include the org.eclipse.core.resources plugin (and dependecies) without using it?

Thanks again.

Comment 3 Christian Damus 2007-09-18 17:14:42 EDT

(In reply to comment #2)
> Thanks for looking into it, Christian.  I'm new to the Validation plugin, so
> I'm not too familiar with how it works.  Are you saying it is required to have
> a workspace for Validation to work or just that you can't make the marker
> functionality optional since it's public API?

That's right.  Validation doesn't actually need the workspace for anything but the MarkerUtil and its related APIs.  The Validation framework, itself, doesn't use this utility.  I suppose that might mean that the dependency can just be marked as optional, and it's up to clients to know whether they can invoke this utility or not based on whether they have resources?

> Do you have a suggested workaround for an RCP application that does not have a
> workspace?  Can I just include the org.eclipse.core.resources plugin (and
> dependecies) without using it?

That would certainly work, yes, but would be truly useless bloat :-(

Comment 4 Will Horn 2007-09-18 17:31:46 EDT

(In reply to comment #3)
> (In reply to comment #2)
> > Thanks for looking into it, Christian.  I'm new to the Validation plugin, so
> > I'm not too familiar with how it works.  Are you saying it is required to have
> > a workspace for Validation to work or just that you can't make the marker
> > functionality optional since it's public API?
> 
> That's right.  Validation doesn't actually need the workspace for anything but
> the MarkerUtil and its related APIs.  The Validation framework, itself, doesn't
> use this utility.  I suppose that might mean that the dependency can just be
> marked as optional, and it's up to clients to know whether they can invoke this
> utility or not based on whether they have resources?
> 

What's the long term vision for this plugin?  Is there a chance of refactoring the marker functionality to the org.eclipse.emf.validation.ui.ide plugin?  I might try changing the dependency to optional to see if I can workaround the problem without adding the bloat, but I realize it's not ideal as a permanent solution.

> > Do you have a suggested workaround for an RCP application that does not have a
> > workspace?  Can I just include the org.eclipse.core.resources plugin (and
> > dependecies) without using it?
> 
> That would certainly work, yes, but would be truly useless bloat :-(
> 

Comment 5 Christian Damus 2007-12-02 01:40:09 EST

On further investigation, I noticed that the org.eclipse.emf.validation plug-in does not re-export the org.eclipse.core.resources plug-in despite using IMarker in the IMarkerConfigurator API, so I committed a fix for that.

However, because IMarker is in the API, it is not possible to mark the resource dependency as optional.

The only recourse will be to split the validation plug-in into two new plug-ins:

  - org.eclipse.emf.validation.core
  - org.eclipse.emf.validation.ide

the latter one to contain the org.eclipse.emf.validation.marker package and the former the others.  The plugin.xml extension point definitions and extensions would likewise be distributed amongst these plug-ins.

The current org.eclipse.emf.validation would become a hollow shell that just requires and re-exports both of these new plug-ins (and continues to support the existing extension points in its namespace).

Your thoughts, Ed?

Comment 6 Ed Merks 2007-12-02 07:37:01 EST

That seems like a reasonable approach.  When the platform split out org.eclipse.ui.ide I think they just forced people to depend on it instead of org.eclipse.ui.  I'm not sure about that though.  What you suggest sounds less painful for clients.

Comment 7 Christian Damus 2008-11-24 09:52:09 EST

Cleaning up after the milestones were all deranged.

Comment 8 Pierre-Charles David 2022-05-14 09:53:12 EDT

Eclipse EMF Validation is moving away from this bugs.eclipse.org issue tracker to https://github.com/eclipse/emf-validation.

If this issue is relevant to you and still present in the latest release:

* Create a new issue at https://github.com/eclipse/emf-validation/issues/.
  * Use as title in GitHub the title of this Bugzilla ticket (may include the bug number or not, at your own convenience)
  * In the GitHub description, start with a link to this bugzilla ticket
  * Optionally add new content to the description if it can helps towards resolution
* Update bugzilla ticket
  * Add to "See also" property (up right column) the link to the newly created GitHub issue
  * Add a comment "Migrated to <link-to-newly-created-GitHub-issue>"
  * Set status as CLOSED MOVED

All issues that remain open will be automatically closed next week or so. Then the Bugzilla component for EMF Validation will be archived and made read-only.