Hi Mickael,
Thank you for your additions.
Since the custom property descriptor works fine and there doesn't seem to be
any development on an official EMF implementation, I think that this feature
would also be a great addition to the upcoming release (what are your
opinions Marc, Florian?).
Concerning Bug 240502 (custom listener):
I didn't think about this in detail, but possibly this could be implemented
by adding kind of a CustomListenerAdapter to the ResourceSet when the model
is loaded (compare Palette.java) that collects all registered custom
listener from the extension and delegates the notification if the
notification-eclass-type equals the ext.point-eclass-type.
A current problem that could emerge when restructuring the applications in
the meta model is the conversion of old workflow files to the new format.
This is because, unfortunately, the current converter implementation is
based on EMF, meaning that it can handle only old files that can be loaded
into the new meta model structure (and then apply changes to them),
otherwise it will completely fail to load the old model. A possible solution
would be to use another (syntax-based) update mechanism (I'm thinking of
e.g. JET or XSLT).
Regards,
Chris
-----Ursprüngliche Nachricht-----
Von: Mickael Istria [mailto:mickael.istria@xxxxxxxxxxx]
Gesendet: Dienstag, 16. September 2008 14:21
An: Christian Saad; Java Workflow Toolbox
Betreff: Re: AW: AW: AW: AW: AW: metamodel extension prototype available
Hi all,
I am sorry for not having time to take a deeper look into metamodels
extensions and aspects, I am currently working on another project for
Open Wide and never get enough time to try this.
Just a few add-on to the list of feature to be added in JWT 0.5 in my
opinion
- bug 240499 (custom PropertyDescriptor in properties sheet), and the
sample for Java Application could be integrated, if the implementation I
proposed is OK for you.
- I'll try to spend some time on bug 240502 (extensions to add listener
when a property is modified) and find an elegant way to implement this
extension in JWT. If I succeed to do it in time, this feature could also
be integrated in JWT 0.5
- I really think it would be better to have refactored Application
Package for release 0.5. I'll also try to design a diagram on this topic
as soon as possible to propose some modifications, hoping again that
I'll get enough time.
Regards,
Mickael
Christian Saad a écrit :
Hi Marc, Mickael, Flo,
I think the images capture the basic concept of the conf-model nicely.
They
should probably be included in the documentation or the wiki with
information about the semantics of the new classes/attributes.
Making the aspect-mechanism independent of JWT would certainly be a
powerful
extension to various meta models, but as you wrote, in the case of JWT it
would come at the cost of reduced UI integration. A possible compromise
could be to view the JWT-aspects as a specific implementation of the
generic
aspects-algorithm and keep them compatible with the general concept.
Concerning the serialization of aspects, I'm voting for an approach where
each aspect's or profile's instances are stored in separate files
(basically
rendering the embedded configuration unnecessary) for the following
reasons:
* prevent cluttering of model file with old/incompatible aspect instances
* make the internal versioning and management of aspect profiles easier
* restrict the model file to instances of core elements (as discussed,
this
could also apply in the future to information specific for visual
representation)
* make the base model file completely independent from extensions and
allow
users to freely exchange different aspect definitions/instances without
affecting the core model
- the drawback would certainly be an increased number of files per model
What is your opinion on this?
To add several options for the visual representation of aspects is a very
good idea. We'll definitely need a new preference page for aspects. If we
decide to source out the aspect management code into a plugin (what is the
status of this decision?), the page should probably be inserted by this
plugin.
Another important addition for this release, in my opinion, would be a new
editor tab which contains the aspect management UI.
I've looked through the open bugs on bugzilla, and there seem to be no
other
major tasks for this release aside from aspects (as I understood,
restructuring the application class is planned for the 0.6 release?).
Until
now, on my personal todo list, there are just some small fixes and
enhancements which should not take very much time.
As far as I can see the following points are still open for 0.5 (please
correct me if I missed something important):
- aspect integration
- source out meta model?
- internal conversion to 0.5 (updater etc.)
- some small fixes/additions
- update the wiki pages
I can certainly assist in the integration and implementation of the aspect
code, but I think we should first discuss this matter very carefully
before
making major changes in the main branch
Regards,
Chris
-----Ursprüngliche Nachricht-----
Von: Florian Lautenbacher
[mailto:florian.lautenbacher@xxxxxxxxxxxxxxxxxxxxxxxxxx]
Gesendet: Montag, 15. September 2008 16:31
An: 'Marc Dutoo'; 'Christian Saad'
Cc: 'Mickael Istria'
Betreff: AW: AW: AW: AW: AW: metamodel extension prototype available
Hi Marc, Mickael, Chris,
thanks for your last description about the metamodel extensions. I now
tried
to summarize all the changes you've made in two graphical models in order
to
allow us an easier discussion about the used concepts. The first one
WE_Metamodel ist about the changes that have been made to the Core package
of the metamodel, the second one JWT_ConfModel is about the configuration
metamodel you've added.
I very much like the conf-model: it includes nearly everything and is
itself
not dependent on the jwt-metamodel, but could simply be added to every
other
metamodel (such as BPMN.ecore, STPIM.ecore, etc.). Alas at the moment it
is
only useful in the context of JWT. A discussion we had here at the
university was whether this mechanism of extending a (workflow) metamodel
could be made so independent of JWT, that it could also be used within
other
Eclipse tools. That would mean on the one side that we don't need changes
in
the WE-metamodel (such as AspectInstance or ConfModel) and on the other
hand
that we need to include in the Conf-model which metamodel we are
configuring
(e.g. in including an additional property configuredModel:EClassifier in
ConfModel). What do you think about that?
On the other hand that would make it very difficult to react to changes in
selection of model elements (how can an external plugin know that
currently
an Action, a Role or the whole Activity of JWT or a Task in BPMN has been
selected!?). So for the moment and for usability a connection between the
ConfModel and JWT WE seems perfect, but I'm not sure whether it is 100 per
cent necessary. Maybe we can already consider that in our development
during
the next weeks.
Now for the upcoming weeks till end of September we should try to
integrate
your changes of the branch into the head revision of CVS if we like to
have
a release review at the end of September. For that we should discuss
whether
the aspects will be stored in a separate file or included in the workflow
file itself. Did we already have a consens on this? I don't think so!?
Here is a suggestion to simplify how aspect data is displayed :
* display all aspect data in slightly grayed mode
* add a checkbox in the outline allowing to hide all aspect data
* possibly even customize which profiles are displayed or not in the
outline, just like you can do with a working set
The idea of displaying the aspects in gray is great! I'm not sure whether
it
is that easy to have a checkbox in the outline, but it could be a page in
the preferences where one could select which color the aspects should have
and whether they should be shown at all. So probably we'll need a
completely
new preferences page if we also like the user to customize which profiles
should be displayed and which don't.
Chris, maybe you might be able in the next days to work on the aspects?
Let's discuss this internally at Augsburg and via phone with France on
Friday.
Best regards,
Florian
-----Ursprüngliche Nachricht-----
Von: Marc Dutoo [mailto:marc.dutoo@xxxxxxxxxxx]
Gesendet: Montag, 18. August 2008 17:44
An: Florian Lautenbacher
Cc: 'Mickael Istria'; 'Christian Saad'
Betreff: Re: AW: AW: AW: metamodel extension prototype available
Hi Florian, Chris
Wow, our souls just met :)
I mainly agree with what you say. My comments below.
Some more :
* I'm not completely sure of my migration of the EMF templates
concerning the code that looks for images and resources. I know you
made it work in many different situations, and I'm not sure I covered
all the bases.
* I'm also interested by feedback on its use. Typically I'm
surprised you didn't suffer while trying to use the profile manager UI
;)
Regards,
Marc
Florian Lautenbacher a écrit :
Hi Marc,
Chris and myself met each other last Thursday and went through your
code
and
discussed it some time. Please find below our thoughts (Chris, please
correct me or add things that I missed now):
-a removal of the metamodel from jwt-we would be something we should
definitely work on (however, I'm not sure whether we should do this
for
the
September release or only after that)
OK, we've got enough work besides that.
-it would be good to combine jwt-we-conf-model and
jwt-we-conf-model.edit into one plugin. There's no added value in
separating these two plugins,
is
there?
Well, I just tried the default way, which knowledgeable EMF users like
Stéphane and other STP projects use, if you look at their CVS. I think
it is the way it is meant to be used, but I'll ask him.
The added value could be to allow people to use jwt-we-conf-model as a
library in their own application (or connector or engine...) to open
and read a jwtconf file...
-the jwt-we-conf-model.editor is a good possibility for companies to
create
and edit their conf-model in the future; maybe we might extend this
after
a
while and have an own conf-model-editor (but for now, the EMF tree
editor
is
more than enough)
I wanted to try it, but I admit it doesn't bring much. OK for removing
it. The right editor might actually be a repackaging of the JWT tree
editor (under another button).
-just for our understanding: now each Model can have one ConfModel;
each ConfModel consists of * Profiles and each Profile is a set of
Aspects?
Yep. A profile is an activable set of consistent features. Versions,
aspect import etc. are managed at the profile level.
-we need to have a proper description about the samples, what each
one
does,
how it is created, etc.
This can be found in the bugzilla. I'll extract the words and put them
in doc.txt files for each of them.
-we think it might be good to remove Property from the core metamodel
and maybe make an own plugin out of this extension. Additionally the
CustomProperties-tab should only be part of another plugin and not of
the root-plugin. Would you agree?
That's nice idea. This way vendors providing their own aspects could
disable properties.
-WE: The directories under modelext are somehow confusing: there we
got editors (which should go under we.editors afterwards),
actions.external shall be we.editors.actions.external and
emf.edit.command does not fit
into
any of the existing packages right now probably
Yep, I wasn't sure where to put all that, especially because my
propertypropertytab is such an ugly hack (copy paste). You're right
for moving editors and actions.external. emf.edit.command is actually
the package of a bit of EMF I need to override for "New child aspects"
to work, I'll move it.
-Why did you divide sample-aspectschildextender and
sample-aspectschildextender.edit as well as sample-staticaspect and
sample-staticaspect.edit? This only makes it more difficult to
understand what's happening in each example.
Same as above, to do as everybody does...
-Filenames: maybe we might change .conf to .jwtconf in order for
other projects to understand where this file comes from?
Good idea !
-Concerning CVS:
we probably might have the following structure on CVS:
org.eclipse.jwt
transformations [...]
wam [...]
we
jwt-we
jwt-we-plugins
jwt-we-action-doc
jwt-we-action-sample
jwt-plugin-sample (btw: what's the difference
between the last
two?)
jwt-we-views
jwt-we-vieweditor (former jwt-view, is currently
developed)
jwt-we-view-example (rename to jwt-we-view-sample?)
jwt-we-view-uml
maybe sometimes jwt-we-view-bpmn in the future...??
jwt-metamodel
jwt-metamodel-core (to be extracted from jwt-we)
jwt-confmodel (was jwt-we-conf-model +
jwt-we-conf-model.edit)
jwt-confmodel-editor (an own plugin based on
jwt-we-conf-model.editor)
jwt-metamodelsample-aspectschildextender (was
jwt-we-sample-
aspectschildextender+.edit)
jwt-metamodelsample-registereddynamicaspect (was
jwt-we-sample-reg...)
jwt-metamodelsample-staticaspect (was
jwt-we-sample-stat...+.edit)
It's good, but why not put together all we plugin samples in their own
we/jwt-we-samples ? Because else there would be sample plugins in
jwt-we-plugins and others in jwt-we-metamodel... Or on the opposite
should metamodel go out of we/ ?
Probably jwt-we-deploy as well as jwt-we-update-site and
jwt-we-feature
may
not be hosted on this site, but could also be hosted on the website
repository of the CVS. But I'm not sure about that yet. Opinions?
These are my points for the moment.
Best regards,
Florian
-----Ursprüngliche Nachricht-----
Von: Marc Dutoo [mailto:marc.dutoo@xxxxxxxxxxx]
Gesendet: 17 August 2008 13:40
An: Florian Lautenbacher
Cc: Mickael Istria; Christian Saad
Betreff: Re: AW: AW: metamodel extension prototype available
Hi Florian, Christian, Mickael I urge you to take a look at the
latest version (committed on the 4th of August) of the METAMODELEXT
branch,
because
in my opinion it has all the required core features. However, many
improvements in usability still remain to be done ;) So I'd very
much
like
you to give your feedback on it !! Moreover, you can review it on a
technical point of view, as well as names of EMF elements, CVS
organisation
etc. Regards, Marc On Wed, 23 Jul 2008 15:47:04 +0200, "Florian
Lautenbacher" <florian.lautenbacher@xxxxxxxxxxxxxxxxxxxxxxxxxx>
wrote: >
Hi
Marc, > > okay, I ignore the exception and by changing the view (I
had
the
UML view > and therefore didn't see anything...) I can now also see
that under > Model->Profile there are aspects defined (e.g. in >
activity_staticaspect.workflow or in
activity_property__saved.workflow) > and > in the activity_property I
can now also see that there are new properties > under the "My
Action" which have been defined using the aspects. But I > didn't
find where the static or dynamic aspects have been woven in!? > >
Thanks, > > Florian > > -----Ursprüngliche
Nachricht-----
Von: Marc Dutoo [mailto:marc.dutoo@xxxxxxxxxxx] > Gesendet: 23 July
2008
14:29 > An: Florian Lautenbacher > Cc: 'Mickael Istria'; 'Christian
Saad'
Betreff: Re: AW: metamodel extension prototype available > > Hi > >
Maybe
there were a few problems with the new jwt-we-conf EMF plugin >
configuration. > > I've patched it, added a static aspect sample
(check
out
the new projects > org.eclipse.jwt/we/jwt-we-sample-staticaspect* out
of
the
branch), and > retagged it METAMODEL_STATICASPECT . It should work. >
I've completed my tests on child extenders, it costs almost nothing
to > enable so I'll commit them along with a sample. Then, if it
still doesn't
work for you, I'll do a full workspace checkout to have a look at it.
> Regards, > Marc > > Florian Lautenbacher a écrit : >> Hi Marc,
thanks
for your implementation for the metamodel extension. The last >>
days
have
been busy, but now I managed to have a look at it; however, >> it
does
not
work on my PC: when I open the activity_property.workflow, >> it
stops
with
an exception, can't find conf_Directory_name (see >> stacktrace below).
Probably there is an entry missing in the >> plugin.properties:
where
shall
this point to? To the whole path where >> I downloaded the
jwt-we-conf-model to or to conf-model.edit? Does this >> path always
need to be set manually? Right now I cannot even see the > original
model
without
the extensions. >> >> As soon as it works on my PC, I will start
going through the code in >> order to get a better understanding of
how it
works
and to see what >> might be changed/improved. >> >> Thanks and best
regards, >> >> Florian >> >> --- >> >> >> 2008-07-23 11:07:46.250
org.eclipse.jwt.we.PluginProperties getString >> WARNING: The resource
conf_Directory_name is missing. >> (java.util.MissingResourceException:
Can't find resource for bundle >>
org.eclipse.osgi.framework.internal.core.ManifestLocalization$Localiz
a >> tionRe sourceBundle, key conf_Directory_name) >> 23-Jul-2008
11:07:46 org.eclipse.jwt.we.PluginProperties getString >> WARNING:
The resource conf_Directory_name is missing. >>
java.util.MissingResourceException:
Can't
find resource for bundle >>
org.eclipse.osgi.framework.internal.core.ManifestLocalization$Localiza
tionRe >> sourceBundle, key conf_Directory_name >> at
java.util.ResourceBundle.getObject(ResourceBundle.java:386) >> at
java.util.ResourceBundle.getObject(ResourceBundle.java:383) >> at
java.util.ResourceBundle.getObject(ResourceBundle.java:383) >> at
java.util.ResourceBundle.getString(ResourceBundle.java:346) >> at
org.eclipse.emf.common.EMFPlugin$InternalHelper.getString(EMFPlugin.ja
va:363 >> ) >> at >>
org.eclipse.emf.common.ui.EclipseUIPlugin.getString(EclipseUIPlugin.ja
va:106 >> ) >> at >>
org.eclipse.jwt.we.PluginProperties.getString(PluginProperties.java:8
8) >> at >>
org.eclipse.jwt.we.modelext.aspects.Aspects.<clinit>(Aspects.java:115)
-----Ursprüngliche Nachricht----- >> Von: Marc Dutoo
[mailto:marc.dutoo@xxxxxxxxxxx] >> Gesendet: 19 July 2008 17:44 >> An:
Florian Lautenbacher >> Cc: Mickael Istria; Christian Saad >> Betreff:
metamodel extension prototype available >> >> Hi >> >> Here is a
first prototype, still ugly but functional, and a single >> sample
using an embedded conf model and showcasing three properties. >>
Aspects should be
OK
once the code to load dynamic EMF extensions is >> done (soon). >>
Migration to Ganymede 3.4 including EMF templates works, but code for
finding text and images still need to be adapted from JWT. >> >>
I'll
put
this in the bugzilla & wiki properly. >> >> Try it : >> * get a new
eclipse workspace >> * from JWT CVS, check out branch CVS
BRANCH_METAMODEL_080710 of >> org.eclipse.jwt >> * to find it,
open
the CVS brows repository perspective >> * there, refresh the
branches
of the JWT root ; if not found, >> choose "use deep CVS search" >>
*
check it out to a local project "org.eclipse.jwt_MMEXT", by >> using
the
"check out as" command >> * import its project in the workspace
(jwt-we, >> jwt-we-conf-model, >> jwt-we-conf-model.edit) >> * from
JWT
CVS, check out the HEAD of org.eclipse.jwt >> * import in your
workspace all projects that are still missing >> to give you a
complete
JWT
WE >> * start JWT WE using "run as... > Eclipse application" on the
jwt-we project >> * open and use the sample workflow : >>
jwt-we/samples/mmext/property/activity_property.workflow >> * it
uses
an embedded ConfModel defining two typed properties on >> Action,
and
one
on Action and also Activity >> * right-click > new Child...
displays
available new child >> commands accordingly >> * the embedded
ConfModel is available in the outline under the > root >> * if it
is
modified, available new child commands will change >> accordingly in
realtime >> >> >> TODO (see Aspects.java) >> * move to the right
place,
extract itf, refactor >> * use loaded models, tag declared ones vs
autodiscovered >> * write custom aspect sample >> * merge base and
embedded models, specify how it works : a single >> merged ConfModel
built
on load, or a multilayered cache ? >> * model : types should be
EClassifier rather than string >> * model : refactor dependancies and
extends between jwt mm and >> jwt-we-conf mm >> * use EMF child
extenders to handle non-Property Aspects rather >> than our own ??
*
behaviours : use implemented onCreated / singleton, design a >>
pluggable
architecture >> * better ModelElementImpl.java using javajetinc or
adapter, than >> merely using in
collectNewChildDescriptors@generated
NOT
* merge with Views >> * separate model from we UI >> * write
jwt-we-conf-ui plugin : graphical editor for jwt-we-conf >> model >> >>
commit time dev notes : >> >> jwt-we : >> * see commit comment :
added
jwt-we-conf mmm with aspects, poc impl >> (in package modelext) and
sample
* added dependency to jwt-conf-model* >> * jwt mm : added
embeddedconf containment reference in Model and >> ExtensibleElement,
Aspect, Property >> * new icons (TODO ?) >> * WEEditor : added
ConfItemProviderAdapterFactory , allowing to >> edit conf mm >> *
hacked
ModelElementItemProvider.java : >> * to
collectNewChildDescriptors(),
removed mere Property >> childdesx and added call to
collectNewChildAspectDescriptors() >> * written
createChildAspectParameter() , >> createCreateChildAspectCommand() and
overriden createCommand() to >> handle child aspect case >> * using
own
Aspect-aware EMF edit extensions : >> * AspectCommandParameter
(knows
the Aspect id) >> * CreateChildAspectCommand (can use the Aspect
id
to
describe > itself) >> * sample : activity_property.workflow >> >>
jwt-we-conf-model and jwt-we-conf-model.edit : >> * written m3 i.e.
jwt-we-conf mm : ConfModel, Profile, Aspect >> * created EMF model
and
edit plugins, using new EMF project wizard >> >> migration to ganymede :
* plugin properties with additional EMF generated _UI_* props >> *
WEConfMetaModelEditPlugin : added itself as Resource in >>
constructor >>
Regards, >> Marc >> >> Marc Dutoo a écrit : >> >>> Hi >>> >>>
Congrats
& good choice Chris ! I look forward to further working with >>> you
^^
I agree on the public part, the release schedule and cvs management.
We could indeed ask about a sandbox. >>> >>> Finally I've designed
a
"metametamodel" yesterday (named it >>> ConfModel, contains profiles
and their aspects definitions) and >>> started using it in the
branch. Still proxied http till friday so >>> can't commit yet ;_;
I've got a philosophical question : should the JWT model
import the >>>
metametamodel
and store its embedded instances in Model, or the >>> metametamodel
import
the JWT model and extend PackageableElement, so >>> it can also be
stored under Model ? I prefer the second because it >>> allows the
metamodel extensions to refer to other JWT elements, but >>> I'm not
sure it is compliant with your "PackageableElement" >>> philosophy.
And a packageable ConfModel could even allow to manage >>> embedded
confs in your existing package UI... >>> >>> About extension confs, I
propose we store and autodiscover them in a >>> given "conf"
directory and its subdirectories, allowing to classify >>> them.
This subdirectory tree could be mirrored
by
packages (if using >>> above solution 2) when embedding the
extension
confs
in the Model. >>> Declaring them on an extension point in plugin.xml
would still be >>> optional, but would allow "vendor-like"
packaging,
i.e.
belong
not to >>> "autodiscovered" ones but to "installed" extensions that
have
to
be >>> explicitly installed (ex. downloaded as a plugin), typically
because
only having the metamodel extension through an embedded conf would
not be enough to have the whole feature set of the installed extension.
I also had the idea of a (extension point providing a) pluggable
version update mechanism (along a conf incompatibility detection >>>
mechanism), allowing vendors to provide code that patches their own
old
extension models up to a newest version, and a default >>>
implementation that merely changes the version number and goes back
through the
extension metamodel to create the missing new dynamic >>> >>
properties
and aspects. >> >>> Will put all of this in bugzilla and CVS ^^ >>>
Regards, >>> Marc >>> >>> >> Marc Dutoo a écrit : >> >>> Hi
all
I've started the branch for the metamodel extension : >>>
BRANCH_METAMODELEXT_20080710 . >>> >>> Obviously, I'll ask you to
refrain from changing the metamodel in the >>> following times, save
in the
branch
! >>> >>> For now the only change I've committed is that I've removed
the empty >>> DataType in the events package, because it forbids
model regeneration. >>> This will be done in the HEAD when merging
back the branch. >>> >>> I've tried Ganymede (Eclipse 3.4) and it has
a lot of cool features. >>> I think it's a good opportunity to
switch, so I'm also migrating to >>> ganymede on the branch. >>> >>>
In my workspace I've already done said the forecast basic changes to
the metamodel.
However
I've had problems, probably because of changes >>> in Ganymede
(ItemProvider.getImage() returns URL and not Image). So >>>
currently I'm first busy updating the EMF templates to Ganymede's,
without killing any Augsburg adaptations though ;) >>> >>> I hope
I'll have something
working by the end of the week. >>> >>> Regards, >>> Marc >>> >> >>
