First I'd like to say that automation of commands and easy composition of
high-level actions into even more higher-level actions is a functional
area that is sorely missing from Eclipse.

Having said that, I am concerned about the way this project is positioned
and the implementation choices (WTP Data Model Wizard Framework) that are
described. In order for a facility such as this to be truly effective, it
should not be tied to WTP. While your initial uses for the framework are
WTP-based, placing this technology into WTP and making it have WTP
dependencies would artificially constrain the scope of the potential
community and permanently limit its reach. Then if in the future, command
scripting is added to Eclipse Platform, this framework and all users of it
instantly become obsolete.

I would make two suggestions:

1. Re-evaluate your dependency on WTP-specific technologies (such as the
data model wizard framework) and see whether you can achieve your goals
without it.

2. Move the project proposal from WTP Incubator to Technology project or
even the Platform Incubator. Co-ordinate your activities with the platform
team.

The relationship to the Eclipse Command Framework needs to be rationalized
as the commands already represent encapsulated high-level actions. In
effect, you are proposing a framework that would compose even higher-level
commands out of other commands. I would recommend that you solicit
feedback from the platform team. Also consider that in the future, this
technology might need to expand into scripting and recording.

First we absolutely agree that the framework should in the end go in the
platform. But we also think that the WTP Data Model framework should go
there. The PAVE framework depends only on the data model framework from
WTP, so we intend to create a separate downloadable with DMF as a first
step.
And if the PAVE framework gets enough attention we can try to push it in
the platform.

I will try to explain our vision for the framework, thus I think answering
most of your questions.
The idea behind the framework is actually easy sequencing of operations
existing and non-existing ones. We want to build a data model with all of
the data needed for all operations and then execute them in a single pass.
Also UI should be reusable, one and the same page could be used for
gathering data for creating a java class for instance and in the same time
to be reused in one of the steps of a certain pattern. Reusability is one
of our top priorities.

We want these operations to be able to be executed in headless mode, so
there can be multiple actions for executing one and the same pattern (drag
and drop, within other frameworks, separate actions), since the framework
itself will be invisible for the regular user. The developer should see
only the patterns that are contributed.

Scripting of operations is a think worth thinking of and we can include it
in future versions.

> The idea behind the framework is actually easy sequencing of operations
> existing and non-existing ones. We want to build a data model with all of
> the data needed for all operations and then execute them in a single pass.
> Also UI should be reusable, one and the same page could be used for
> gathering data for creating a java class for instance and in the same time
> to be reused in one of the steps of a certain pattern. Reusability is one
> of our top priorities.

> We want these operations to be able to be executed in headless mode, so
> there can be multiple actions for executing one and the same pattern (drag
> and drop, within other frameworks, separate actions), since the framework
> itself will be invisible for the regular user. The developer should see
> only the patterns that are contributed.

Just forgot to add that most of these features already exist in DMF plus
more really useful features for ui synchronization that make creating of
wizards really easy, the model is completely separated from the UI that is
something that is missing in platform as well. And having in mind there 2
things can greatly benefit from each other.

As someone who has learned this the hard way (faceted project framework),
starting technology out in WTP with intentions of moving it lower in the
stack at a later date sounds good in theory, but is exceptionally costly
approach in practice.

It is significantly cheaper to start without WTP dependencies (including
dependencies on WTP namespaces (org.eclipse.jst and org.eclipse.wst)) than
it is to start out this way and then try to pull out, while maintaining
backwards compatibility for WTP. You also have to consider how you plan to
build a community around this. Again speaking from experience, it doesn't
matter how good your technology is, you will not get adoption and grow
your community beyond the sphere of adopters who build on top of WTP
already while this technology is part of WTP. Providing a separate
download will not change this situation in a meaningful way as perception
of positioning, influence and tie-ins factor in significantly in adoption
decisions. Further, you are always in danger of someone undermining all of
your work by building something similar in function lower in the stack (or
at least outside of confines of any one particular vertical tooling
project).

I would recommend that you guys at least discuss this with the Platform
team. I appreciate that you already have a code base built on the data
model framework, but if that's the only reason that you can't start out
outside of WTP then you are selling your technology short. In the long
run, it would be better for you to invest the time to remove your
dependency on the data model framework so that you can start immediately
positioned to maximize your potential community.

Not sure where in the Platform this may end up but how about a call before
the creation review to get to know each other, and what you are trying to
accomplish? If the proposed technology is already implemented in a product,
you could even give a demo of it. Just set up a poll on doodle.ch with
suggested times...

Boris

"Konstantin Komissarchik" <konstantin.komissarchik@oracle.com> wrote in
message news:4e80f83e0e86aee8b6da48456251f61e$1@www.eclipse.org...
> As someone who has learned this the hard way (faceted project framework),
> starting technology out in WTP with intentions of moving it lower in the
> stack at a later date sounds good in theory, but is exceptionally costly
> approach in practice.
> It is significantly cheaper to start without WTP dependencies (including
> dependencies on WTP namespaces (org.eclipse.jst and org.eclipse.wst)) than
> it is to start out this way and then try to pull out, while maintaining
> backwards compatibility for WTP. You also have to consider how you plan to
> build a community around this. Again speaking from experience, it doesn't
> matter how good your technology is, you will not get adoption and grow
> your community beyond the sphere of adopters who build on top of WTP
> already while this technology is part of WTP. Providing a separate
> download will not change this situation in a meaningful way as perception
> of positioning, influence and tie-ins factor in significantly in adoption
> decisions. Further, you are always in danger of someone undermining all of
> your work by building something similar in function lower in the stack (or
> at least outside of confines of any one particular vertical tooling
> project).
> I would recommend that you guys at least discuss this with the Platform
> team. I appreciate that you already have a code base built on the data
> model framework, but if that's the only reason that you can't start out
> outside of WTP then you are selling your technology short. In the long
> run, it would be better for you to invest the time to remove your
> dependency on the data model framework so that you can start immediately
> positioned to maximize your potential community.
>
> - Konstantin
>

I agree that the right place of the new project is in the platform. All
your points with regards to positioning and adoption are valid. I just
have some concerns with regards to removing dependencies from Data Model
Wizard framework. Doing so well have to build similar functionality in
the platform which means redundancy and all the consequences it will
bring.

First we absolutely agree that the framework should in the end go in the
platform. But we also think that the WTP Data Model framework should go
there. The PAVE framework depends only on the data model framework from
WTP, so we intend to create a separate downloadable with DMF as a first
step.
And if the PAVE framework gets enough attention we can try to push it in
the platform.

I will try to explain our vision for the framework, thus I think answering
most of your questions.
The idea behind the framework is actually easy sequencing of operations
existing and non-existing ones. We want to build a data model with all of
the data needed for all operations and then execute them in a single pass.
Also UI should be reusable, one and the same page could be used for
gathering data for creating a java class for instance and in the same time
to be reused in one of the steps of a certain pattern. Reusability is one
of our top priorities.

We want these operations to be able to be executed in headless mode, so
there can be multiple actions for executing one and the same pattern (drag
and drop, within other frameworks, separate actions), since the framework
itself will be invisible for the regular user. The developer should see
only the patterns that are contributed.

Scripting of operations is a think worth thinking of and we can include it
in future versions.

> The idea behind the framework is actually easy sequencing of operations
> existing and non-existing ones. We want to build a data model with all of
> the data needed for all operations and then execute them in a single pass.
> Also UI should be reusable, one and the same page could be used for
> gathering data for creating a java class for instance and in the same time
> to be reused in one of the steps of a certain pattern. Reusability is one
> of our top priorities.

> We want these operations to be able to be executed in headless mode, so
> there can be multiple actions for executing one and the same pattern (drag
> and drop, within other frameworks, separate actions), since the framework
> itself will be invisible for the regular user. The developer should see
> only the patterns that are contributed.

Just forgot to add that most of these features already exist in DMF plus
more really useful features for ui synchronization that make creating of
wizards really easy, the model is completely separated from the UI that is
something that is missing in platform as well. And having in mind there 2
things can greatly benefit from each other.

As someone who has learned this the hard way (faceted project framework),
starting technology out in WTP with intentions of moving it lower in the
stack at a later date sounds good in theory, but is exceptionally costly
approach in practice.

It is significantly cheaper to start without WTP dependencies (including
dependencies on WTP namespaces (org.eclipse.jst and org.eclipse.wst)) than
it is to start out this way and then try to pull out, while maintaining
backwards compatibility for WTP. You also have to consider how you plan to
build a community around this. Again speaking from experience, it doesn't
matter how good your technology is, you will not get adoption and grow
your community beyond the sphere of adopters who build on top of WTP
already while this technology is part of WTP. Providing a separate
download will not change this situation in a meaningful way as perception
of positioning, influence and tie-ins factor in significantly in adoption
decisions. Further, you are always in danger of someone undermining all of
your work by building something similar in function lower in the stack (or
at least outside of confines of any one particular vertical tooling
project).

I would recommend that you guys at least discuss this with the Platform
team. I appreciate that you already have a code base built on the data
model framework, but if that's the only reason that you can't start out
outside of WTP then you are selling your technology short. In the long
run, it would be better for you to invest the time to remove your
dependency on the data model framework so that you can start immediately
positioned to maximize your potential community.

Not sure where in the Platform this may end up but how about a call before
the creation review to get to know each other, and what you are trying to
accomplish? If the proposed technology is already implemented in a product,
you could even give a demo of it. Just set up a poll on doodle.ch with
suggested times...

Boris

"Konstantin Komissarchik" <konstantin.komissarchik@oracle.com> wrote in
message news:4e80f83e0e86aee8b6da48456251f61e$1@www.eclipse.org...
> As someone who has learned this the hard way (faceted project framework),
> starting technology out in WTP with intentions of moving it lower in the
> stack at a later date sounds good in theory, but is exceptionally costly
> approach in practice.
> It is significantly cheaper to start without WTP dependencies (including
> dependencies on WTP namespaces (org.eclipse.jst and org.eclipse.wst)) than
> it is to start out this way and then try to pull out, while maintaining
> backwards compatibility for WTP. You also have to consider how you plan to
> build a community around this. Again speaking from experience, it doesn't
> matter how good your technology is, you will not get adoption and grow
> your community beyond the sphere of adopters who build on top of WTP
> already while this technology is part of WTP. Providing a separate
> download will not change this situation in a meaningful way as perception
> of positioning, influence and tie-ins factor in significantly in adoption
> decisions. Further, you are always in danger of someone undermining all of
> your work by building something similar in function lower in the stack (or
> at least outside of confines of any one particular vertical tooling
> project).
> I would recommend that you guys at least discuss this with the Platform
> team. I appreciate that you already have a code base built on the data
> model framework, but if that's the only reason that you can't start out
> outside of WTP then you are selling your technology short. In the long
> run, it would be better for you to invest the time to remove your
> dependency on the data model framework so that you can start immediately
> positioned to maximize your potential community.
>
> - Konstantin
>

I agree that the right place of the new project is in the platform. All
your points with regards to positioning and adoption are valid. I just
have some concerns with regards to removing dependencies from Data Model
Wizard framework. Doing so well have to build similar functionality in
the platform which means redundancy and all the consequences it will
bring.