Skip to main content

[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


From: wtp-pmc-bounces@xxxxxxxxxxx [mailto:wtp-pmc-bounces@xxxxxxxxxxx] On Behalf Of David M Williams
Sent: 24 април 2009 г. 18:37 ч.
To: WTP PMC communications (including coordination, announcements,and Group discussions)
Subject: RE: [wtp-pmc] Pave framework proposal

> 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,





Inactive hide details for "Raev, Kaloyan" ---04/24/2009 09:32:37 AM---Hello,"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


Back to the top