[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [wtp-pmc] Pave framework proposal
|
Hi
David,
Thank
you for the valuable feedback!
It is
easier for us to have just one project (and proposal). So, the idea of
positioning the Java EE patterns in the initial contribution as exemplary
patterns within the proposal of the Pave framework will solve my conceptual
problem.
Please, find attached a new revision of the Pave proposal. It is merged
with the secondary one about the Java EE patterns.
I also
added more descriptive information how the Pave framework extends the features
of the WTP Data Model Wizard Framework. Here is this new
text:
The implementation of the Pave framework strongly depends on the
WTP Data Model Wizard Framework. However, the latter is not a necessary
requirement for defining new patterns. The Pave framework extends the features
of the WTP Data Model Wizard Framework by adding a next level of abstraction for
operations – patterns. The following is a summary of all noticeable
features that the Pave framework introduces on top of the WTP Data Model Wizard
Framework.
- The
Pave framework provides an easier way of composing operations. Such sequences
are called patterns and
are defined in extension points.
- Patterns are context sensitive – they are applicable for certain
input. The applicable rules are described declaratively in the enablement
_expression_ of the extension point.
- An external synchronizer class provides an easier way for
connecting the output of previous operations with the input of the following
operations in the pattern. This is done without modifying the operations
themselves. Synchronizer classes are described in the pattern extension
point.
- Validation of Data Model operations is extended to pattern
level. Additional validation classes are declared in the pattern extension
point to validate the execution of the whole sequence of operations. This
extended validation is possible again without altering any existing operations
that are reused in the pattern.
- Functions of the Data Model Operations (like validation) can be
overridden on pattern level to ensure better integration between the reused
operations in the pattern.
Greetings,
Kaloyan
> I have a conceptual problem with the proposal. Together
with the
> Pave framework we would like to contribute some patterns
related to
> Java EE application development. However, developing new
patterns is
> out of the Pave framework scope and it does not seem
appropriate to
> include this contribution in the Pave proposal. We are
thinking
> about proposing another project in the WTP Incubator - "Java
EE
> Patterns", which will include these patterns we want to contribute.
> The Java EE Patterns project will depend on the Pave project and
> will in fact exemplify how the latter can be used.
Kaloyan, I think these are some very interesting proposals and
support their
submission.
I'm not sure it is worth having two projects, though. or at least
not clear to me
much is gained by having two instead of one. You say
"developing new
patterns is out of the Pave framework scope" but, it is
normal -- expected
even -- that projects in Eclipse not only provide API,
but also some exemplary use.
The one Pattern you mention in Pave (a Pattern
for a Pattern) is kind of
abstract for an example,
so perhaps there's a more concrete example that
could be included in Pave? Perhaps an example pattern to create a new
plugin?
Or a "hello world" Java Application?
Another reason for one project instead of two,
if I'm following the proposals, the
same committers
are being proposed for each ... so, is the same team initially.
And long term, I would not anticipate each
consumer of Pave would be a separate project, but
would, more likely, simply
be part of some other project (e.g. patterns used in DTP,
patterns used in BIRT) and not that a whole separate project would
live on that had as
it's scope to be a repository
for Patterns. [feel free to correct me ... what's why
I write all this down :) ]
I'd of
course understand keeping them as separately installable features. And,
when the work would eventually graduate, could see
them "splitting up" then ...
Pave framework (and Data Operations) going to
WTP Common, or Tools perhaps,
and Java EE patterns
going to WTP Java EE project.
I could imagine
some arguments to have two projects instead of one, but think
those should be spelled out instead of left to my imagination.
Perhaps I even
listed one? (The fact they are
anticipated to end-up in different spots?). Perhaps
another is you want to avoid the perception that Pave is "tied to"
WTP? Whereas
Java EE obviously would be. (But since
Pave does depend on Data Operations,
it is sort of
tied right now ... until all that get's sorted out). If you do want to
stick to two project proposals, that's fine, but
think the current Eclipse Foundation
infrastructure
(mostly) supports have sub-sub-projects, so they could be under
WTP Common and WTP Java EE (instead of WTP Incubator)?
As a more general comment on the Pave proposal:
As I read it, I was looking for
some sentence that
explained "How is this different from an Eclipse Operation?" or
"How is this different from a WTP Data Operation?" Perhaps it's there
already and
more knowledgeable readers would
understand it right away. Just thought
I'd comment
on my missing it, so you could consider making it more obvious
to other readers.
I hope something
I've written above will useful to improve the proposals,
but even if not I support these efforts in what ever form you settle
on.
Thank you,
"Raev,
Kaloyan" ---04/24/2009 09:32:37 AM---Hello,
 From: |
 "Raev, Kaloyan"
<kaloyan.raev@xxxxxxx> |
 To: |
 "WTP PMC communications (including
coordination, announcements, and Group discussions)"
<wtp-pmc@xxxxxxxxxxx> |
 Date: |
 04/24/2009 09:32 AM |
 Subject: |
 RE: [wtp-pmc] Pave framework
proposal |
 Sent by: |
 wtp-pmc-bounces@xxxxxxxxxxx |
Hello, I attach a draft of the
secondary proposal for Java EE Patterns that will be based on the Pave
framework. Greetings,Kaloyan
From:
wtp-pmc-bounces@xxxxxxxxxxx [mailto:wtp-pmc-bounces@xxxxxxxxxxx] On Behalf Of Raev, Kaloyan
Sent: Thursday, April 23, 2009 7:13 PM
To:
wtp-pmc@xxxxxxxxxxx
Subject: [wtp-pmc] Pave framework proposal
Hello WTP PMC,
I am sending you a draft of the proposal for the Pave
framework I have presented on Tuesday.
<<Pave.pdf>>
The
project is proposed under the Eclipse WTP top-level project. We are looking for
mentors of the project.
I have a conceptual problem with the proposal. Together with
the Pave framework we would like to contribute some patterns related to Java EE
application development. However, developing new patterns is out of the Pave
framework scope and it does not seem appropriate to include this contribution in
the Pave proposal. We are thinking about proposing another project in the WTP
Incubator - "Java EE Patterns", which will include these patterns we want to
contribute. The Java EE Patterns project will depend on the Pave project and
will in fact exemplify how the latter can be used.
Is this approach meaningful?
Greetings,
Kaloyan [attachment "Java_EE_Patterns.pdf"
deleted by David M Williams/Raleigh/IBM]
_______________________________________________
wtp-pmc mailing
list
wtp-pmc@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-pmc
Attachment:
Pave.pdf
Description: Pave.pdf