On 10/2/06, Sean Schofield <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote:
> On 9/28/06, Wendy Smoak <[EMAIL PROTECTED]> wrote:
> >
> > On 9/28/06, Craig McClanahan <[EMAIL PROTECTED]> 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
>
>

Reply via email to