geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Warner" <jaw...@gmail.com>
Subject Re: [DISCUSS] Geronimo 2.1 samples
Date Thu, 13 Mar 2008 19:50:16 GMT
On Thu, Mar 13, 2008 at 3:44 PM, Hernan Cunico <hcunico@gmail.com> wrote:

> Migration samples should definitively not go into svn because the source
> environment, the start point for those apps is intended to be a different
> platform, not Geronimo. There would be no point in keeping them into svn and
> adding them as a part of the release process.


You're suggesting the migration samples exist solely in the wiki?  The makes
them a little difficult to maintain, doesn't it?


>
> However there are a whole bunch of other sample apps in the doc and are G
> specific and those are the ones we are discussing here. Or I need to start
> reading the whole thread again :P
>

That's kind of what I was getting at.  There's really two classes of samples
here and I think everyone is just lumping them together.  Maybe they aren't
doing it intentionally, but I think some people are talking from the point
of view of migration samples and some from the sample applications.



> Cheers!
> Hernan
>
> Jason Warner wrote:
> > I wasn't sure which thread to put this in, so I'll throw it in here.  So
> > far, it seems that when we've been discussing samples, we're lumping the
> > sample applications and the migration samples in together.  Is this
> > something we want to do?  In my mind, they aren't really the same and
> > shouldn't necessarily be in the same place.  AFAIK, a sample application
> > is supposed to be able to be checked out, built, and deployed on
> > geronimo straight away to highlight some feature or functionality.  The
> > migration samples, though, are meant to be fiddled with before they can
> > be deployed on Geronimo.  If we lump them all in together, how is a user
> > supposed to know which is which when browsing svn?  Would it make sense
> > to keep the migration samples in a separate space?
> >
> > On Thu, Mar 13, 2008 at 3:13 PM, Hernan Cunico <hcunico@gmail.com
> > <mailto:hcunico@gmail.com>> wrote:
> >
> >     David Jencks wrote:
> >      >
> >      > On Mar 13, 2008, at 11:47 AM, Joe Bohn wrote:
> >      >
> >      >> Joe Bohn wrote:
> >      >>> David Jencks wrote:
> >      >>>>
> >      >>>> On Mar 12, 2008, at 7:12 AM, Joe Bohn wrote:
> >      >>>>
> >      >>>>> Donald Woods wrote:
> >      >>>>>> Joe Bohn wrote:
> >      >>>>>>>
> >      >>>>>>> 2) When to release the samples?  I think we should
make an
> >     effort
> >      >>>>>>> to release the samples concurrent with each Geronimo
> release.
> >      >>>>>>> This is important because the jsp & servlet
examples are
> >      >>>>>>> referenced from within the welcome page on Geronimo.
 I
> suppose
> >      >>>>>>> we could remove that reference and eliminate the
need to
> >     release
> >      >>>>>>> concurrently.
> >      >>>>>> why not move the samples back under geronimo/server,
so they
> are
> >      >>>>>> maintained and versioned with each release and can
then be
> >     used as
> >      >>>>>> additional testsuite tests?  If not, releasing right
after a
> >      >>>>>> server release is fine.
> >      >>>>>
> >      >>>>> I was thinking about doing this.  It seems everybody thinks
> we
> >      >>>>> should release them together anyway so what is the real
value
> >     with
> >      >>>>> them being split out?  Does anybody object to moving them
> >     back with
> >      >>>>> the server?
> >      >>>>
> >      >>>> well, since I thought our next goal with the server build
was
> to
> >      >>>> separate it into independently released plugins, I think
> >     putting the
> >      >>>> samples in with the main server build would be a big step
> >     backwards.
> >      >>> Well, I agree that it would appear to be a step backwards from
> that
> >      >>> perspective.  However, it would ensure the following:
> >      >>> 1) The samples would get released (not forgotten as has been
> >     the case
> >      >>> with 2.1)
> >      >>> 2) The samples would be released concurrent with the Geronimo
> >     release
> >      >>> so that they are available for use, education, and
> >     documentation from
> >      >>> day 1.  It seems almost everybody is in favor of this.
> >      >>> 3) They could be leveraged in the testsuite tests (as Donald
> >     pointed
> >      >>> out) to help validate our build and find problems earlier.
> >      >>> I fail to see too many negatives from a practical perspective
> >     but I'm
> >      >>> certainly open to discussion .... I want to do what is best.
> >      >>> Perhaps we need to refine our plugin strategy.  There are
> >     situations
> >      >>> where it makes sense to split things apart but there are also
> >      >>> situations where it might make sense to bundle things.
> >      >>> Joe
> >      >>
> >      >> Would those folks that feel strongly about not pulling these
> samples
> >      >> back into the server repo please provide some rationale for
> their
> >      >> argument as I have done for including them?  It appears that the
> >      >> samples were removed without much thought given to how they
> might
> >      >> eventually be released in conjunction with a server release.  I
> like
> >      >> the idea of modularity but in this case I don't see clear
> >     benefits to
> >      >> keeping them separate.
> >      >>
> >      >> Please keep in mind that including the samples in the server
> source
> >      >> branch and releasing them concurrent with the server does not
> mean
> >      >> that they are bundled with the server.  They are still
> independent
> >      >> artifacts.  However, it would ensure that they are vetted with
> the
> >      >> server release and are available when the server release is
> >      >> available.  The samples are really only there to show value on
> >     top of
> >      >> a Geronimo server and they are tied to a specific server release
> (at
> >      >> least that is how we have managed and documented them thus far)
> so
> >      >> having released independent of the server doesn't appear to
> >     bring any
> >      >> value.
> >      >>
> >      >> I looked back through a number of old email threads and these
> >     samples
> >      >> were included in the welcome page with a lot of support at the
> time
> >      >> (with a desire to have even more samples included or
> >     downloadable from
> >      >> the welcome page) ... several folks stating that they should be
> >      >> included with the server image itself.  I certainly don't want
> to
> >      >> bundle the samples with the server image but having the released
> >     with
> >      >> the server makes sense to me.
> >      >
> >      > I'm speculating a bit here.
> >      >
> >      > This might be similar to the testsuite being a bit monolithic.
> >      >
> >      > As a thought experiment, what if we...
> >      > - made the welcome page a plugin, and the piece of build
> including it
> >      > also builds the samples
> >      > - the maven generated site includes the stuff you need to
> >     download (zips
> >      > etc) (I think this is doable)
> >
> >     Are we using any maven site today? what type of info goes there? who
> >     consumes it?
> >
> >     .zip samples download shouldn't be any different from the other
> >     downloads we have, right?
> >
> >     Cheers!
> >     Hernan
> >
> >      > - the welcome page links to the maven  generated site
> >      > - this leaves the door open to making the welcome page + samples
> >      > independently versioned in the future, and possibly to selenium
> >     testing.
> >      >
> >      > - we split up the testsuite into integration tests for "plugins"
> or
> >      > plugin groups, and they assemble the servers they need on the fly
> >      >
> >      > - assemblies may or may not include the welcome page plugin.
> >      >
> >      > dunno how practical this is for 2.1.1
> >      >
> >      > thanks
> >      > david jencks
> >      >
> >      >
> >      >
> >      >>
> >      >> Joe
> >      >>
> >      >>
> >      >
> >      >
> >
> >
> >
> >
> > --
> > ~Jason Warner
>



-- 
~Jason Warner

Mime
View raw message