[PROPOSAL] Refactor Shale Deliverables

[Craig McClanahan <cr...@apache.org>]

Based on feedback from the user list, and a desire expressed on the dev list
to separate validator support into a separate JAR as well, I hereby propose
that we so some splitting up on the current contents of shale-core.jar,
before the next release.  The motivations include:

* Allow apps to only include the pieces of Shale that they want (such as
folks who
  don't need view controller support, but need to run on Servlet 2.3).

* Enable x.y.z.patch releases of individual JARs if we need to, at a fine
grained level.

* Narrow down shale-core.jar (possibly eventually) to just be common shared
utility
  classes.

* Minimize intra-JAR dependencies within Shale functional jars to reduce
  impacts of changes in one area on functionality in others.

Specifically, I propose creating the following new artifacts under the
"frameworks" directory, taking existing content from the package names
specified in shale-core:

* shale-application -- Application Controller support (
org.apache.shale.application,
  org.apache.shale.faces).

* (shale-dialog-xxx -- This will be a separate [PROPOSAL] thread).

* shale-validator -- Commons Validator support
(org.apache.shale.validatorand portions of
  org.apache.shale.{component,renderer,taglib}).  This will also require a
new tag library
  for the tags; we'll probably need to leave them declared in the original
TLD for at least a
  while to assist in transitions.  The JSF component stuff will need to be
repackaged under
  something like org.apache.shale.validator.faces for the component,
renderer, and tag classes.

* shale-view -- View Controller support (org.apache.shale.view,
org.apache.shale.view.faces,
  org.apache.shale.view.impl).

At the same time, we should do some changes to the website pages:

* The "features" page for things that are in a separate artifact should
become the
  home page for that artifact's generated website, with pointers in the
features list
  updated to point there instead of a page in the top level website.

* Update the API Stability page to improve its usefulness:

  - Split the packages intended for application developer use away from
those
    intended for people modifying the framework itself.  This will remove
the need
    for the "Target" column in each table.

  - Consider combining all the entries for each target into a single table
(adding a
    column for which JAR contains that package), and sort the tables by
package name.

  - See where we stand with respect to aggregated javadocs (IIRC there was
an
    outstanding Maven issue in this area).  At a minimum, make sure that the
package
    names link to the correct javadocs in the overall website.

  - Update the details to reflect the latest breakdown of jars and packages.

If there are no objections, I propose to start on this tomorrow (Friday) and
get it done before the weekend -- therefore before I head down to the Bay
Area to speak at the AJAX World Conference.

Thoughts?

Craig

PS:  While in Prague earlier this week, I had a chance to have dinner with
Jason van Zyl of Maven fame.  It sounds like the issue we have with
resolution of transitive dependencies are going to get addressed in Maven
2.1, and he plans to have some test builds available for us (and others) to
try later this year.

Re: [PROPOSAL] Refactor Shale Deliverables

[Greg Reddin <gr...@apache.org>]

On Oct 2, 2006, at 10:28 PM, Craig McClanahan wrote:

> In general I suspect we'll just do overall releases (a.b.c) as a  
> matter of
> course -- but we could release an a.b.c.d version of a particular  
> library,
> say, to fix a security vulnerability or something.

That was my big question (that I ran out of time to ask :-)  Under  
those criteria I'm definitely +1 for this proposal.

Greg

Re: [PROPOSAL] Refactor Shale Deliverables

[Craig McClanahan <cr...@apache.org>]

On 10/2/06, Sean Schofield <se...@gmail.com> wrote:
>
> So split things up like the Spring project?  That sounds fine but its
> a bit more work to manage all of those seperate releases.  On the
> other hand, the projects are fairly small and in theory, shouldn't
> require too many releases.


In general I suspect we'll just do overall releases (a.b.c) as a matter of
course -- but we could release an a.b.c.d version of a particular library,
say, to fix a security vulnerability or something.

I was starting to wonder about the view controller and what made it so
> special that it should be part of the "core."


One could make the same argument about dialogs, or the application
controller :-).

Sean


Craig


On 9/28/06, Craig McClanahan <cr...@apache.org> wrote:
> > On 9/28/06, Wendy Smoak <ws...@gmail.com> wrote:
> > >
> > > On 9/28/06, Craig McClanahan <cr...@apache.org> wrote:
> > >
> > > > If there are no objections, I propose to start on this tomorrow
> (Friday)
> > > > and get it done before the weekend -- therefore before I head down
> to
> > > > the Bay Area to speak at the AJAX World Conference.
> > >
> > > No objections, and I'll be around this weekend and Monday to make
> > > minor adjustments if necessary.
> > >
> > > > PS:  While in Prague earlier this week, I had a chance to have
> dinner
> > > with
> > > > Jason van Zyl of Maven fame.  It sounds like the issue we have with
> > > > resolution of transitive dependencies are going to get addressed in
> > > Maven
> > > > 2.1, and he plans to have some test builds available for us (and
> others)
> > > to
> > > > try later this year.
> > >
> > > Neat. :)  Did you talk about integration testing also?
> >
> >
> > I went into the dinner hoping too ... but Czech beer is pretty good
> stuff
> > :-).
> >
> > Actually, I've started (a little) to buy into the argument that
> integration
> > tests are sufficiently complicated that they deserve their own project
> --
> > or, more precisely, projects.  The advantage of a separation is that you
> can
> > have more than one suite of integration tests, each of which might be
> > focused on different aspects -- and it will be more motivating to the
> > developer to actually run the tests at all if he/she can choose the ones
> > focused on a particular functional area.
> >
> > That being said, we're currently doing a combination of integrated and
> > separated integration tests -- the "itest" profile for something like
> > shale-blank or shale-usecases does integration testing on the app, while
> the
> > "itest" profile for shale-test-xxxxx type apps are really integration
> tests
> > for the framework modules that correspond to xxxxx.
> >
> > This is definitely a topic that deserves more discussion in
> Maven-land.  It
> > may well be that I have a minority opinion -- but it's worth exploring
> in
> > more detail (if it hasn't been rehashed ad nauseum before).
> >
> >
> > --
> > > Wendy
> > >
> >
> >
> > Craig
> >
> >
>

Re: [PROPOSAL] Refactor Shale Deliverables

[Sean Schofield <se...@gmail.com>]

So split things up like the Spring project?  That sounds fine but its
a bit more work to manage all of those seperate releases.  On the
other hand, the projects are fairly small and in theory, shouldn't
require too many releases.

I was starting to wonder about the view controller and what made it so
special that it should be part of the "core."

Sean

On 9/28/06, Craig McClanahan <cr...@apache.org> wrote:
> On 9/28/06, Wendy Smoak <ws...@gmail.com> wrote:
> >
> > On 9/28/06, Craig McClanahan <cr...@apache.org> wrote:
> >
> > > If there are no objections, I propose to start on this tomorrow (Friday)
> > > and get it done before the weekend -- therefore before I head down to
> > > the Bay Area to speak at the AJAX World Conference.
> >
> > No objections, and I'll be around this weekend and Monday to make
> > minor adjustments if necessary.
> >
> > > PS:  While in Prague earlier this week, I had a chance to have dinner
> > with
> > > Jason van Zyl of Maven fame.  It sounds like the issue we have with
> > > resolution of transitive dependencies are going to get addressed in
> > Maven
> > > 2.1, and he plans to have some test builds available for us (and others)
> > to
> > > try later this year.
> >
> > Neat. :)  Did you talk about integration testing also?
>
>
> I went into the dinner hoping too ... but Czech beer is pretty good stuff
> :-).
>
> Actually, I've started (a little) to buy into the argument that integration
> tests are sufficiently complicated that they deserve their own project --
> or, more precisely, projects.  The advantage of a separation is that you can
> have more than one suite of integration tests, each of which might be
> focused on different aspects -- and it will be more motivating to the
> developer to actually run the tests at all if he/she can choose the ones
> focused on a particular functional area.
>
> That being said, we're currently doing a combination of integrated and
> separated integration tests -- the "itest" profile for something like
> shale-blank or shale-usecases does integration testing on the app, while the
> "itest" profile for shale-test-xxxxx type apps are really integration tests
> for the framework modules that correspond to xxxxx.
>
> This is definitely a topic that deserves more discussion in Maven-land.  It
> may well be that I have a minority opinion -- but it's worth exploring in
> more detail (if it hasn't been rehashed ad nauseum before).
>
>
> --
> > Wendy
> >
>
>
> Craig
>
>

Re: [PROPOSAL] Refactor Shale Deliverables

[Craig McClanahan <cr...@apache.org>]

On 9/28/06, Wendy Smoak <ws...@gmail.com> wrote:
>
> On 9/28/06, Craig McClanahan <cr...@apache.org> wrote:
>
> > If there are no objections, I propose to start on this tomorrow (Friday)
> > and get it done before the weekend -- therefore before I head down to
> > the Bay Area to speak at the AJAX World Conference.
>
> No objections, and I'll be around this weekend and Monday to make
> minor adjustments if necessary.
>
> > PS:  While in Prague earlier this week, I had a chance to have dinner
> with
> > Jason van Zyl of Maven fame.  It sounds like the issue we have with
> > resolution of transitive dependencies are going to get addressed in
> Maven
> > 2.1, and he plans to have some test builds available for us (and others)
> to
> > try later this year.
>
> Neat. :)  Did you talk about integration testing also?


I went into the dinner hoping too ... but Czech beer is pretty good stuff
:-).

Actually, I've started (a little) to buy into the argument that integration
tests are sufficiently complicated that they deserve their own project --
or, more precisely, projects.  The advantage of a separation is that you can
have more than one suite of integration tests, each of which might be
focused on different aspects -- and it will be more motivating to the
developer to actually run the tests at all if he/she can choose the ones
focused on a particular functional area.

That being said, we're currently doing a combination of integrated and
separated integration tests -- the "itest" profile for something like
shale-blank or shale-usecases does integration testing on the app, while the
"itest" profile for shale-test-xxxxx type apps are really integration tests
for the framework modules that correspond to xxxxx.

This is definitely a topic that deserves more discussion in Maven-land.  It
may well be that I have a minority opinion -- but it's worth exploring in
more detail (if it hasn't been rehashed ad nauseum before).


--
> Wendy
>


Craig

Re: [PROPOSAL] Refactor Shale Deliverables

[Wendy Smoak <ws...@gmail.com>]

On 9/28/06, Craig McClanahan <cr...@apache.org> wrote:

> If there are no objections, I propose to start on this tomorrow (Friday)
> and get it done before the weekend -- therefore before I head down to
> the Bay Area to speak at the AJAX World Conference.

No objections, and I'll be around this weekend and Monday to make
minor adjustments if necessary.

> PS:  While in Prague earlier this week, I had a chance to have dinner with
> Jason van Zyl of Maven fame.  It sounds like the issue we have with
> resolution of transitive dependencies are going to get addressed in Maven
> 2.1, and he plans to have some test builds available for us (and others) to
> try later this year.

Neat. :)  Did you talk about integration testing also?

-- 
Wendy

RE: [PROPOSAL] Refactor Shale Deliverables

["Kito D. Mann" <km...@virtua.com>]

+1 

Excellent idea... What's great is that this will make it easier to discern
which parts of Shale are really popular, and which aren't, which will in
turn make it easier to determine what makes sense for JSF 2.0...

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Kito D. Mann (kmann@virtua.com)
Author, JavaServer Faces in Action
http://www.virtua.com - JSF/Java EE consulting, training, and mentoring
http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info
 

> -----Original Message-----
> From: craigmcc@gmail.com [mailto:craigmcc@gmail.com] On 
> Behalf Of Craig McClanahan
> Sent: Thursday, September 28, 2006 9:33 PM
> To: Shale Developers List
> Subject: [PROPOSAL] Refactor Shale Deliverables
> 
> Based on feedback from the user list, and a desire expressed 
> on the dev list to separate validator support into a separate 
> JAR as well, I hereby propose that we so some splitting up on 
> the current contents of shale-core.jar, before the next 
> release.  The motivations include:
> 
> * Allow apps to only include the pieces of Shale that they 
> want (such as folks who
>   don't need view controller support, but need to run on Servlet 2.3).
> 
> * Enable x.y.z.patch releases of individual JARs if we need 
> to, at a fine grained level.
> 
> * Narrow down shale-core.jar (possibly eventually) to just be 
> common shared utility
>   classes.
> 
> * Minimize intra-JAR dependencies within Shale functional 
> jars to reduce
>   impacts of changes in one area on functionality in others.
> 
> Specifically, I propose creating the following new artifacts 
> under the "frameworks" directory, taking existing content 
> from the package names specified in shale-core:
> 
> * shale-application -- Application Controller support ( 
> org.apache.shale.application,
>   org.apache.shale.faces).
> 
> * (shale-dialog-xxx -- This will be a separate [PROPOSAL] thread).
> 
> * shale-validator -- Commons Validator support 
> (org.apache.shale.validatorand portions of
>   org.apache.shale.{component,renderer,taglib}).  This will 
> also require a new tag library
>   for the tags; we'll probably need to leave them declared in 
> the original TLD for at least a
>   while to assist in transitions.  The JSF component stuff 
> will need to be repackaged under
>   something like org.apache.shale.validator.faces for the 
> component, renderer, and tag classes.
> 
> * shale-view -- View Controller support 
> (org.apache.shale.view, org.apache.shale.view.faces,
>   org.apache.shale.view.impl).
> 
> At the same time, we should do some changes to the website pages:
> 
> * The "features" page for things that are in a separate 
> artifact should become the
>   home page for that artifact's generated website, with 
> pointers in the features list
>   updated to point there instead of a page in the top level website.
> 
> * Update the API Stability page to improve its usefulness:
> 
>   - Split the packages intended for application developer use 
> away from those
>     intended for people modifying the framework itself.  This 
> will remove the need
>     for the "Target" column in each table.
> 
>   - Consider combining all the entries for each target into a 
> single table (adding a
>     column for which JAR contains that package), and sort the 
> tables by package name.
> 
>   - See where we stand with respect to aggregated javadocs 
> (IIRC there was an
>     outstanding Maven issue in this area).  At a minimum, 
> make sure that the package
>     names link to the correct javadocs in the overall website.
> 
>   - Update the details to reflect the latest breakdown of 
> jars and packages.
> 
> If there are no objections, I propose to start on this 
> tomorrow (Friday) and get it done before the weekend -- 
> therefore before I head down to the Bay Area to speak at the 
> AJAX World Conference.
> 
> Thoughts?
> 
> Craig
> 
> PS:  While in Prague earlier this week, I had a chance to 
> have dinner with Jason van Zyl of Maven fame.  It sounds like 
> the issue we have with resolution of transitive dependencies 
> are going to get addressed in Maven 2.1, and he plans to have 
> some test builds available for us (and others) to try later this year.
>