Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: AW: AW: [jwt-dev] Project Tree Organisation 
Hello Florian, hello all,

* I don't have any objection about removing jwt-we-sample-*
* I don't think that having examples beside of feature and test may look unstructured while naming is clearly respected [feature]. [feature]-tests. [feature]-example... (assuming that feature == feature or plugin) ... It will become unstructured only when one the feature or plugin will have several examples, and that naming won't match exactly between examples and plugin/feature. Probably we could have [feature] and [feature]-test as Eclipde projects like there are currently, and have [feature]-examples that would be the unique folder for all examples about the feature/plugin. Then if there are several examples, they go *under* the [feature]-examples folder, and we ensure that there will not be one new folder at the same level as the feature for each test.
* I really like your proposal about the structure once the metamodel is extracted from we
* About a kind of "JWT application" (ie a standalone Eclipse which would only contain JWT and its dependencies, designed specially for JWT use), ** I've seen that some EMFT projects (such as Amalgam) can be downloaded in such "format" from eclipse.org. In such case, the JWT team can produce the "JWT application", and make it available to download on JWT website while it contains only Eclipse code. ** Vendors who want to integrate JWT in their products (ie JWT + specific features) will have to, and wish to, host their specific products on their sites, have their specific build process and release engineering for their product. They will build their products on JWT, just as JWT is built on EMF (ie as a dependency). But, to take benefit of their contributions, they will probably always depend on the latest stable build of JWT. ** Open Wide will probably (but not surely) use the same strategy as vendors in the context of the OW2 Scarbo project, but nothing is sure yet. ** The JWT website won't be allowed to host or advertise for non-Eclipse product. The best thing we may be able to do is to maintain on the wiki a list of products that are built on JWT. If vendors wish more visibility in the Eclipse consortium, they'll have to become members, and to pay the Eclipse Fundation for that... See http://www.eclipse.org/downloads/ "Distros" tab, and http://www.eclipse.org/membership/become_a_member/membershipTypes.php for more details. 


Regards,
Mickael



Florian Lautenbacher a écrit :

Hi there,

I just wanted to clean up the CVS and have seen that some things have
already been done:
-releng now consists of builder, jwt-feature, jwt-tests-feature,
jwt-tests-plugin and tester
-/we/ now does not contain jwt-we-feature or jwt-we-update-site anymore

However, there still exist the jwt-we-sample-* in org.eclipse.jwt/we/. Since
all of those are in /jwt-we-plugins/, too, I guess I can remove them from
/we? 
Marc said: Basically, I like the idea of having for an xxx plugin that is

somewhere, possible xxx-example and xxx-test project or plugins in the same
location.

Hmm, I'm not so sure. I agree with xxx-test, but having xxx-example in the
same location as the feature or extension point itself, will probably make
it very unstructured. I prefer having xxx and xxx-test in the same
directory, but have a single entry point for all examples (such as
jwt-we-plugins for jwt-we).

I agree that we should have something like examples in the menu, too. This
might be example processes, but also sample plugins showing the
functionality of an extension point. This requirement should probably go
into a new bug?


Marc said: I approve of aspects going in an aspects/ or conf/ directory

(or component), that would make things clearer, moreover aspects could be
used independently from we - save from jwt-we-conf.we, which is we-specific
and should stay in we.

What about the path of this directory? org.eclipse.jwt/we/conf/ had been my
first thought, but on the other side this is about the metamodel and not
specific to the workflow editor, so when we take the metamodel out of the
jwt-we plugin, then we'll need a place for that, too, and /we/conf/ is
closely related to that!?

One idea would be to have:

org.eclipse.jwt/metamodel
org.eclipse.jwt/metamodel/conf
org.eclipse.jwt/we
org.eclipse.jwt/we/jwt-conf
org.eclipse.jwt/we/jwt-* (all existing jwt-we things)

This would ease the usage of the metamodel alone without the workflow editor
and have one package where the metamodel extensions are (metamodel/conf) and
one where the workflow editor specific extensions of aspects are
(we/jwt-conf). What do you think about this structure? Would this also fit
the needs of other vendors? Bull, JBoss?

I like the idea of having a full installable build of Eclipse and JWT
plugins such as spagic or topcased, because I agree that in the future it
will be quite difficult for users to select specific plugins. But the
problem is who will host such a site? OpenWide, JBoss, Bull? On the other side the features that we build should include all necessary 
plugins so that the users are not confused too much when getting the plugins
from the update-site (which probably many users still will do!).

Best regards,
Florian 
-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im
Auftrag von Marc Dutoo
Gesendet: 07 January 2009 15:07
An: Java Workflow Toolbox
Betreff: Re: AW: [jwt-dev] Project Tree Organisation

Hello Florian

Sensible things from you and Mickaël.

My thoughts in the text below.

Florian Lautenbacher a écrit :

Hi Mickael,
I agree that the current CVS structure is already getting confusing again :-/ The tree structure that you suggested sounds good to me: /releng as a main folder with everything that is related to automatic build/tests and besides that the three main components WE, WAM and 
Transformations.
I also agree with Chris that under WE we should have a clear structure what is necessary at least, what are the additional plugins, what are aspect-related things, samples, etc.
Since the aspect samples are already in jwt-we-plugins, I guess we can remove the jwt-we-sample-* under /we? The only reason why I didn't do that already was that probably the aspect code on the branch is removed in parallel to that. But since the aspect feature is now nearly finished I guess this should not be a problem, am I right? 
Yep, on my side you can remove jwt-we-sample-* .

Basically, I like the idea of having for an xxx plugin that is somewhere,
possible xxx-example and xxx-test project or plugins in the same location.

On the topic of example files, we should think about improving their
packaging and release, because for now JWT comes without any by default, the
"example processes" zip on the JWT_Downloads page is not in the CVS...
Ex. put file examples in an example wizard (like the STP SCA editor has)
allowing to get them by default from the update-site and easily create them
in JWT, also provide templates, aspect decorated models and conf samples the
same way...
Concerning the aspects: now jwt-we is dependent on jwt-we-conf-model and jwt-we-conf-model.edit as I have read? So probably those should stay in the /we directory as well in order for newby's to find all plugins? Maybe we should also have a reference somewhere how and where to download org.jdom, since one of my students struggled with that before 
christmas...

These are two different topics.

A. I approve of aspects going in an aspects/ or conf/ directory (or
component), that would make things clearer, moreover aspects could be used
independently from we - save from jwt-we-conf.we, which is we-specific and
should stay in we.

B. On the other side, the right way of installing JWT plugins is by the
update-site. This is OK by newbies because it includes all plugins and
dependancies, even orbit ones like jdom.

I think we should even __drop__direct links to the jars on the download
page, because 1. there are so much plugins now it's too complex to install
by drop down 2. third-party vendor plugins like bull's, scarbo's, jboss'
will only complexify the picture 3. the latest eclipse's equinox p2 core
moves toward update-site only (according to Mickaël).
As a remplacement and for newbie users, we could additionally provide a
__full__ installable build of eclipse + jwt plugins (spagic, topcased and
others does that), or a zip of all plugins that must be added to a given
eclipse install (middle solution between update-site and full install, but I
don't like it, it's a bad compromise).

And for developers :
   * developers that are JWT users and only extend it without contributing
are fine with a regular JWT installation, using a JWT update-site.
   * developers that are in the JWT team and committers have doc in
http://wiki.eclipse.org/JWT_DeveloperFAQ . For instance, it rightfully links
to how to install jdom at http://wiki.eclipse.org/JWT_CVS#JDOM . Actually I also struggled on Monday with it, bug thanks to this doc I was 
able to do it.
When we remove jwt-we-feature from /we then we can probably also remove jwt-we-update-site from there, since this will be generated automatically in the future, am I right? 
Mickaël confirms this.
NB: We mustn't forget to update the information on the wiki concerning the CVS, so that every newcomer can understand all these changes. Perhaps we might upload a README.txt in org.eclipse.jwt-root with a link to that wiki page? 
Why not. I agree updating this information is critical, and the JWT_CVS wiki
page is the reference for such info.

Regards,
Marc

Best regards,

Florian
PS @Mickael: Have you seen all the bugs that Anne Jacko has raised concerning our yearly release, e.g. participate in a UI Best practices Working Group UI walkthrough (as the STP Policy editor did in December)? We probably need to work on this in the future as well... 


-----Ursprüngliche Nachricht-----
Von: jwt-dev-bounces@xxxxxxxxxxx [mailto:jwt-dev-bounces@xxxxxxxxxxx] Im Auftrag von Mickael Istria 
Gesendet: 07 January 2009 11:24
An: Java Workflow Toolbox
Betreff: [jwt-dev] Project Tree Organisation

Hi all,
I'm thinking on how to improve the JWT project tree organisation, and I suggest that JWT feature should be part of releng. CVS would look like 
that:
NB: names of folders are not real name, I changed them by laziness, I do not suggest anything about naming, only tree structure 

/releng
   / builder (current releng)
   / tester (testing utils and ant scrips)
   / feature (defines the set of plugins to be included in the release)
/ test feature (the test feature is necessary to have test run automatically at each build, it includes all test plugins related to the plugins that are in the feature, only useful for automated testing, not intended to be published) / jwt-master-test-plugin (the test plugin defines a test suite that runs all tests, it is the entry point for the automated testing framework) 
/we

   / jwt-we
   / jwt-we-test
   / jwt-plugins
      / jwt-plugin-1
      / jwt-plugin-1-test
      / jwt-plugin-2
      / jwt-plugin-2-test
      / ...
   / jwt-aspects
     / jwt-conf-model
     / ...
/ wam
/ transformation
   / jwt-transformation-base
   / jwt-transformation-base-test
   / jwt-transformation-xpdl
   / jwt-transformation-xpdl-test
   / ...
I think that this organization would better separate development, testing and release engineering part of JWT, and also encourage testing and facilitate release engineering. 

What do you think about that?
Mickael
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev

_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev

_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev

_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev

Back to the top