[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: AW: AW: [jwt-dev] Project Tree Organisation
|
Hi all,
>> I don't have any objection about removing jwt-we-sample-*
Okay, I changed that, now its a little bit more structured again.
>> 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.
Hmm, I'm not so sure. Especially when we have dozens of examples (e.g. for
different extension points of one plugin, which will be the case more
often), then it gets unstructured. I agree with you if there is one plugin,
one test and one example, that then it might be okay to leave that all in
the same directory.
>> 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.
Marc and I agreed that it would be good to have some pages on the wiki for
integrators, integrations and process engines which will be linked directly
from the main web site, so people can see where to go and where they might
find some applications that are predefined (JBoss, Bull, Scarbo, AgilPro,
etc.).
Have a nice weekend to all of you,
Florian
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
>
_______________________________________________
jwt-dev mailing list
jwt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/jwt-dev
