Hi Chris,
somehow I got a deja'vu: didn't we discuss the naming
conventions for plugins already? I would like to stay with the current folder
structure since we also described it in several places (e.g. [1,2]) and I would
not like to change all of these (despite we probably won't find all references
anymore...).
Therefore, I'm against moving /we/jwt-we-plugins to
/plugins/*. Since these plugins are all concerned about the workflow editor,
they should stay under /we/ in my opinion with other plugins building on
existing transformations, the wam or runtime being under those
folders...
Concerning jwt-we-action example vs. sample: we agreed to
use the -example at the end and I already agreed to remove the -sample once
which I now finally did ;-)
jwt-view: Yes, we now got a new view editor plugin, but I
don't won't to delete this project from CVS, since it is still functional and
maybe we can reuse it sometime later. But probably we should describe on the
wiki that there is a newer project that we use and that this project is more or
less deprecated.
Concerning the tags: Yes, there are several and there was
not really a naming convention for that. We have some as Galileo_0_6_RC*
but also JWT_GALILEO_M* as well as TAG_METAMODEL_*. I guess all the METAMODELEXT
tags can be removed now the metamodel extensions work fine, but I would like to
leave the Galileo tags. Does anybody know whether the JWT_0_6 tag includes all
plugins at the release of Galileo? Or maybe only the plugins that were released
as part of Galileo (which is a huge difference!)?
Concerning the view_multiple branch: is there still only
one plugin there? I thought with your last email, Chris, that there should now
be some more? At least on my PC it only shows me jwt-we...
Best regards,
Florian
Hi
all,
the remaining plugins
should now be adapted so that they work together with the new version of the
workflow editor. Where no branch exists, the old version of the corresponding
plugin still works without adaptions. Before finally moving everything into the
head, we should allow ourselves a few weeks to test everything to see if any
major errors or complications surface.
Additionally, I’d
like to hear your opinions on some refactoring ideas for the
CVS:
- move
/we/jwt-we-plugins/* to /plugins/*
Reason: I find it a
bit confusing that there is an additional directory inside the we folder on the
same layer as the plugin projects. The /plugins directory could hold all
optional plugins identified by their component prefix (e.g. jwt-we-…
)
-
jwt-we-action-example vs jwt-we-action-sample
I guess one is
redundant/out of date
-
sample/example
A common naming
strategy should be enforced
-
jwt-view
The old view editor
probably isn’t needed anymore
- remove outdated
tags
There are a lot of
tags which aren’t used anymore
When everything is
ready for the switch of the branch, we should create a branch for v0.6.0 so that
this state of the development isn’t lost and can finally work again in the HEAD
;)
Regards,
Chris
Von:
jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im Auftrag
von Florian Lautenbacher Gesendet: Dienstag, 28. Juli 2009
14:38 An: 'Java Workflow Toolbox' Betreff: AW: [jwt-dev]
HEAD <-> branch
Hi
Chris,
just one
question: does the multiple-views branch only contain the project jwt-we? What
about the other plugins (e.g. jwt-metamodel or jwt-converter) - are they not
part of the branch yet?
Best
regards,
Florian
Von:
jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im Auftrag
von Christian Saad Gesendet: 02 July 2009 18:25 An:
'Java Workflow Toolbox' Betreff: [jwt-dev] HEAD <->
branch
Hi all,
I’ve transferred all recent changes from
HEAD to the views_multiple branch of the Workflow Editor. Therefore no changes
should be made anymore in the head but only in the branch. It would be great if
you could switch your local copies to this version and report any problems that
haven’t existed before.
For other plugins that don’t work anymore
with the new version we also have to create branches so that we can at one time
switch them all to HEAD.
Regards,
Chris
|