Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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

Back to the top