[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: [jwt-dev] Project Tree Organisation
|
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
