geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Erik B. Craig" <erik.cr...@gmail.com>
Subject Re: [DISCUSS] Geronimo 2.1 samples
Date Thu, 13 Mar 2008 20:52:52 GMT
On Thu, Mar 13, 2008 at 3:32 PM, Hernan Cunico <hcunico@gmail.com> wrote:

>
> Erik B. Craig wrote:
> >
> >
> > On Thu, Mar 13, 2008 at 3:08 PM, Jason Warner <jaw981@gmail.com
> > <mailto:jaw981@gmail.com>> wrote:
> >
> >
> >
> >     On Thu, Mar 13, 2008 at 4:01 PM, Hernan Cunico <hcunico@gmail.com
> >     <mailto:hcunico@gmail.com>> wrote:
> >
> >         Well, from the wiki -> Geronimo documentation, there are 3main
> >         sets of samples, well actually 3 now.
> >
> >         1- Migration samples
> >         2- Sample applications
> >         3- Tutorials
> >
> >         1- Migration samples. These should not be in svn unless we plan
> >         to maintain and test sample applications that are intended for
> >         JBoss, WebLogic, WAS, Tomcat or any other platform we want to
> >         explain how to migrate from. It could potentially include the
> >         need to maintain features/technologies we do not support or may
> >         never support.
> >
> >
> >     Isn't that what's already occurring?  I believe the migration
> >     samples have applications attached to them that are designed for
> >     JBoss and the sample explains how to convert it to Geronimo.  These
> >     would need to be updated based on the changes that occur both in
> >     JBoss and Geronimo.
> >
> >
> > Correct, this is what I'm working on because they haven't been really
> > kept up to date - and we don't want to get burned by someone trying to
> > get something going or migrated that we say we have support for but have
> > no supporting documentation or samples.
> > When rewriting sample apps and documentation for 2.0, they are all meant
> > to go from jboss to geronimo. The process involves validating
> > functionality on the latest JBoss release (4.2.2GA in that case),
> > updating documentation where necessary, updating code where necessary,
> > and then ensuring the migration steps are still valid, and making
> > changes to both documentation and code where needed.
> >
>
> Ok, so we all know what it'll take and agree to carry on with this. Then
> we should figure out a way to link what's on svn and the corresponding doc.
> Confluence still does not support svn so I haven't figured out an
> alternative way to ensure they are in sync. Any idea?
>

Well, as far as that goes I have came up with two solutions...
1. Reference a branch or tag and document checking the code out via SVN and
have this in the step-by-step in the document

2. Release versions as archives of the source code, that can be published
much as we do with the server and server sources, and linked to this in the
wiki articles


>
> Cheers!
> Hernan
>
> >
> >   ...
>
>


-- 
Erik B. Craig

Mime
View raw message