Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [] Evolving plugin/feature names

Hi Ed,

El 06/02/2012 20:05, Ed Willink escribió:
Hi Adolfo
At least we have got an agreement, the current impact analyzer should be promoted to org.eclipse.ocl.ecore :)
I do not know what you mean, so I cannot be in agreement.

I don't see the Impact Analyzer as part of the org.eclipse.ocl.ecore plugin; we must not add so much code to existing functionality.

I don't see the Impact Analyzer as part of the org.eclipse.ocl.ecore feature; we must not add so much code to existing functionality.

I do see the Impact Analyzer as part of the Core build.

I see promotion as dependent on a satisfactory review, so I do not yet agree that the current Impact Analyzer should be promoted.

I also see promotion as dependent on a decision on namespace issues.

I should have said "promoted under org.eclipse.ocl.ecore" namespace, that is, org.eclipse.ocl.ecore.impact*, which was originally your proposition. However, I misread that you changed  to "org.eclipse.ocl.impact" so, as you said we are not in any agreement after all ;P

I've always seen the OCL Tools components as those UI-based components which rely on a OCL Core infrastructure, as they were thought and we had been developed in the currently terminated OCL Tools project. Whereas the OCL Core components could sensibly work in stand-alone mode, the Tools components could probably need some Eclipse UI platform to run. Remember the namespace used to distinct bundles between the "MDT/UML" project and the "MDT/UML Tools" one.
The MDT/UML2 split is easy; the UML project supports just models in UML, CMOF and Ecore forms. Everything else is a tool.

MDT/OCL already has some tools as core; the parser, analyzer and evaluator are 'tools'. The Impact Analyzer is a tool.

I see a Tool as a coherent module of additional functionality, which may or may not have a UI. The Impact Analyzer just happens to have no UI at present. I suspect that some profiling might support interactive optimisation.

Being fussy, most Java classes could be a tool as well. I'm not going to go into such a pedantic discussion. To me, as final Eclipse user I prefer to consider a Tool something I can interact with, i.e. ui-based stuff. To do a simil, JGit would be the Core, EGit (which will probably have its core components) would be the Tool.

On the one hand, distinguishing Tools components with a prefix does quite sense to me. Looking at a Juno installation, excepting the "org.eclipse.e4.emf.xpath" bundle, every bundle of the "new" e4 project are categorized in a "core" / "ui" fashion. On the other hand, projects like EMF have its UI components categorized in the respective feature as you suggests.
In my hypothetical 'proof' tool I tried to address this. UI/not-UI is a different issue to Core/Tools.

Yes they are different, but that's what I want to map. Non-ui stuff prefixed with core and packaged as Core components, Ui stuff prefixed with ui, and packaged as UI components.

All the xtext editors come as two plugins; a non-UI and a UI one. So every Xtext editor splits across your Core/Tools boundary.

Indeed, as I originally suggested. On the other hand, I'm fearing that the "core" (non-ui) part of the current editors (basically the parsers and evaluators) may depend on Xtext infrastructure, hence, there would not be any chance to include the new languages/parsers/evaluators into our Core distribution. So the mapping I mentioned above is not so clear.

I prefer the "core/tools" prefixes since it clearly distinguish core from UI-based components, apart from the benefits I mentioned in my previous post. Perhaps "ui" sounds better for you. Perhaps we could not introduce the "core" prefix, but at least use "tools/ui" one.
(I don't like '.ui' but anything else would now be worse.)

Note that EMF uses suffixes: ".edit", ".editor", ".impl" not prefixes.

What is your definition of 'Core'? I suspect it is what is packaged in the Core build. Packaging can change, tools change much less, so I don't like naming tools according to today's packaging policy. Whether EMF's ".edit", ".editor" are  in separate plugins is a packaging decision that can be changed without renaming.

If you still have doubts what Core means to me/how we should organize components, have a look to the e4 bundles namespace.

Perhaps a useful analogy is with emf and m2m and mdt. Projects started with a prefix org.eclipse.emf.ocl, org.eclipse.m2m.qvt.declarative and then lost it; org.eclipse.ocl. org.eclipse.qvtd... A few well-chosen names keep things orthogonal. It would be very confusing to have different emf.mtf, m2m.mtf, mdt.mtf projects so the prefix is not needed. Projects can be regrouped without renaming. emf and m2m and mdt are selectively redundant packaging names.

With my suggestion all Impact Analyzer contributions start org.eclipse.ocl.impact; you're adding a ".tools" and maybe more.

As commented, I want to mainly distinguish between core (non-ui) and ui (let's no mention "tools" if it's more clear) functionality in the bundles namespace (as e4 does), as long as we want to package core (non-ui) in the Core distribution and the UI in the Tools one. The main reasons:

1. Ease the building and packaging for the releng.
2. Clearly distinct the every Core components (probably run in standalone) and the Ui one (requires the Eclipse UI platform to run).

If you prefer the EMF approach rather than the e4 one, it's ok to me, specially if we can't effectively map the core components at +1 and the ui ones at +3. From the releng point of view, I'm already managing to package the proper content in the different distributions, so it's not a problem to me at all.

Finally I would like to better understand the/understand more inconvenients of my proposal. Your first argument doesn't suffice to me: we would be suffering of the same issue if we had had to deal with a separate OCL Tools project, and the Eclipse "Working Sets" help to organize the bundles in the workspace (for instance to group bundles concerning the same feature/tool, regardless its namespace).
If we added a 'proof' component to a separate Tools project we would not be able to modify the Core project, so if the 'proof' component has a run-time, we would have to create Tools-runtime and Tools-ui features to separate them. Users would need to access one or two of Core/Tool-runtime/Tools-ui. With the merged project, users just choose one of Core/Tools.

If we had a separate independent OCL Tools project we might be promoting* to*.

If we had a separate collaborative OCL Tools project we might be promoting o.e.o.examples.impact* to o.e.o.impact* which is just what we have with an integrated Tools project.

A 'proof' component would have its core and ui parts, the design for that component would imply having bundles under o.e.o.core and

Anyways, to resume... I think that all the alternatives are on the table. As commented, it's OK to me if your final decision is not separating the core and ui (what I expect for tools) components via prefixes.



El 04/02/2012 11:59, Ed Willink escribió:
Hi Adolfo

Thanks, it's much easier to move forward once you have a stake in the ground.

Uniform core/tools prefixes seems attractive but, to avoid confusion from existing facilities, consider what would happen if we added a new symbolic proof tool.

With uniform core/tools prefixes we might have:

whereas if we group by tool rather than delivery we might have


If we need to use examples as an incubation area, during the examples phase we have no problem with


But if we find we need three categories of build rather than two, using the build category as a package prefix is unhelpful.

Also, I'm not sure that users want to have core/tools as part of their imported package path.

For tools at least I think we need a clear tool name as the first name. Subsequent names we can try to make regular to so that *.doc.*, *.tests.*, *.examples.*, *.runtime.* makes releng partitioning fairly easy.

For the current plugins "ecore" and "uml" can be regarded as tool names, so "ecore.tests" and "uml.tests" are regular names.

For the Impact Analyzer then "impact" is short and snappy, so perhaps we want "impact.ecore.runtime", "impact.ecore.analyzer", "impact.common.analyzer", "impact.tests", "impact.examples", "impact.doc"

For the Console, I would look towards and so we might be looking at "debugger.input", "debugger.variables", "debugger.breakpoints", ... once we eventually promote from examples.

For the Xtext editors, "editor..." is probably ok, unless we want to split as "parser" and "editor". We can decide this later.

The Pivot model seem the hardest bit, because there is the neutral domain model. Perhaps "vm.runtime", "vm.model", "vm.library" so that "pivot" is left with a fairly similar purpose to "ecore" and "uml".

So we have the following top level 'tools':
common (may not reference any other 'tool')

and the only plugins that do not comply are org.eclipse.ocl and org.eclipse.ocl.tests

Tool-specific facilities are in ...tests..., ...examples..., ...doc.... Cross-tool integration is in tests..., examples..., doc...

The above is for plugin/package names.

I think Core/Tool prefixes would be good for feature names since if we need to have three deliveries we probably need to re-arrange features anyway.



On 03/02/2012 16:15, Adolfo Sánchez-Barbudo Herrera wrote:
Hi Ed,

Today is quite easy to identify OCL Tools components, that is:


The problems come when identifying Core components, unless we consider Core everything is not o.e.o.examples.* (However, this doesn't help from the point of view of the regular expressions which are used, anyway).

From a releng (and any user) perspective it would be quite easy identify components if we had:

- org.eclipse.ocl.core.*  for Core components.
-* for Tools components.

This distinction could help, if we desired to have documentation, examples and tests for both Core and Tools components:

- org.eclipse.ocl.core.doc for Core API usage  documentation/help.
- org.eclipse.ocl.core.examples.* for Core API usage examples.
- org.eclipse.ocl.core.tests.* for Core API tests.
- for Tools documentation/help.
-* for Tools examples.
-* for (probably UI-based) tests.

This namespace could also help to identify the future components of the project. Everything not scoped in org.eclipse.ocl.core/tools should probably be deprecated and eventually deleted in future releases. I imagine something like the following:
org.eclipse.ocl                                       -> mature, deprecated code
org.eclipse.ocl.uml                               -> mature, deprecated code
org.eclipse.ocl.ecore                            -> mature, deprecated code
org.eclipse.ocl.ecore.impactanalysis[1]  -> impact analysis for the mature deprecated code
org.eclipse.ocl.core.pivot                          -> new pivot implementation
org.eclipse.ocl.core.essentialocl               -> new pivot-based Essential OCL Implementation
org.eclipse.ocl.core.completeocl              -> new pivot-based Complete OCL Implementation
org.eclipse.ocl.core.impactanalysis         -> impact analysis for the new pivot-based implementation
org.eclipse.ocl.core.doc                             -> documentation for the Core API usage
org.eclipse.ocl.core.examples.*                -> Examples for Core API usage.
org.eclipse.ocl.core.tests.*                        -> tests for Core API.                     -> OCL Console.   -> Editor for Essential OCL  -> Editor for Complete OCL                            -> documentation/help for Tools.*               -> examples for Tools.*                       -> (probably UI-based) tests for Tools.

... and such [2].

Again, this is a suggestion, which could make sense since we are now distinguising and exposing different Core and Tools components. It's not a necessity at all.

Adding a new/good features organization, we could finally distribute Core components in a pure Core Repository, and the Tools components in a pure Tools Repository. We could also distribute the current (deprecated and removed in the future) Core components in a "Deprecated Repository".

Nowadays, because of the current feature organization, the Core Repository contains only Core Components, however, the Tools repository contains both Core and Tools components.

Note: [1] Just to name the impact analyzer. This obviously could be organized as Axel requires/expects.
Note: [2] I know that I'm missing a lot of plugins, but I hope the idea is caught.

Best Regards,

El 03/02/2012 14:18, Ed Willink escribió:
Hi Adolfo

Would you like to put together a proposal for revised feature and plugin names and hierarchy, since your releng perspective gives you slightly different interests? 4.0.0 is a major version so we can totally reorganize if absolutely necessary - I hope not.

From a modeling perspective, a Feature contain Features or Plugins so a simple indented list is sufficient to identify the intended location of all plugins and features and Update Site Names.

feature X (Descriptive Name for X)
   plugin Y
   feature Z (Descriptive Name for Z)
      plugin A

For the sake of future proofing, assign names as if all plugins are promoted from examples now; we'll just defer renaming examples plugins until they are actually promoted.



On 03/02/2012 13:58, Adolfo Sánchez-Barbudo Herrera wrote:
Finally, I would like to remark (I've not thought about it) the importance of the new namespace from the point of view of another stakeholder: The releng :). It could be interesting to avoid problems like [1] or further changes in the releng stuff configuration to accomodate new plugins, having a "coherent" or "uniform" namespace to distinguish Core components from the Tools one.


El 03/02/2012 12:03, Ed Willink escribió:
plugin and other global names
These obviously change. The simplest change is just delete ".examples". Do we want to do something else?
It would be nice if the event plugins went to EMF, but that doesn't look likely, so they too need review.
It would be nice to have names that can accommodate the pivot model sometime. I would like to try to partition the code into the run-time code that performs (re-)evaluation and the meta-run-time code that maintains the control objects that make IA so good. If this is possible, then we want corresponding names. Perhaps
I hope that migration of the run-time code to align with the code generated Java can be done quite easily, since the code generated Java makes no use of any form of the OCL meta-model; just the polymorphic Values and polymorphic Domain model for which there is direct and Reflective Ecore support. Perhaps
Migration of the meta-run-time code will be harder because that obviously makes use of the OCL meta-model. Perhaps
In order to avoid code duplication, code that is independent of Ecore/UML/Pivot should be in perhaps
It may also be appropriate to place some declarations independent of Ecore/UML/Pivot such as extension points in
We cannot easily use org.eclipse.ocl since that is highly Ecore/UML dependent.
NB being independent of Ecore does not prohibit use of EObject, EObject.eClass() etc. I hope that the external API facade can be Ecore/UML/Pivot independent and so in org.eclipse.ocl.common.impact.

_______________________________________________ mailing list

Open Canarias, S.L.
Adolfo Sánchez-Barbudo Herrera
C/Elías Ramos González, 4, ofc. 304
Tel.: +34 922 240231

_______________________________________________ mailing list

No virus found in this message.
Checked by AVG -
Version: 2012.0.1913 / Virus Database: 2112/4781 - Release Date: 02/02/12

_______________________________________________ mailing list

Open Canarias, S.L.
Adolfo Sánchez-Barbudo Herrera
C/Elías Ramos González, 4, ofc. 304
Tel.: +34 922 240231

_______________________________________________ mailing list

No virus found in this message.
Checked by AVG -
Version: 2012.0.1913 / Virus Database: 2112/4792 - Release Date: 02/06/12

_______________________________________________ mailing list

Open Canarias, S.L.
Adolfo Sánchez-Barbudo Herrera
C/Elías Ramos González, 4, ofc. 304
Tel.: +34 922 240231

Back to the top