Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (athena.apache.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-Id:From:To:In-Reply-To:Content-Type:Content-Transfer-Encoding:Mime-Version:Subject:Date:References:X-Mailer;
  b=ob55tIII+uK4jUAuP0u0oGAAD2n0EylA7xicKb6K7HitwvFdASydpYXWaE4M2OTeXm6gcpwTOszxiUcyUU2/6zvxEoPj59qxXSLZXZ331Lxytphd82fGagolKaUFWg6p3CBqvZqtfSoKl9VcqAQs+2BI6Z/ONyNjY2smulpsfmQ=
  ;
Message-Id: <9034BF15-724D-47F2-8983-24A0F1E9C1B5@yahoo.com>
From: David Jencks <david_jencks@yahoo.com>
To: dev@geronimo.apache.org
In-Reply-To: <485173C6.3070505@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: sample applications
Date: Thu, 12 Jun 2008 14:16:08 -0700
References: <48514FC7.5030009@gmail.com> <48515A85.5030701@earthlink.net>
 <485173C6.3070505@gmail.com>


On Jun 12, 2008, at 12:06 PM, Hernan Cunico wrote:

> Joe Bohn wrote:
> <snip>
> ...
>>> Plugins are a way to distribute these applications, a convenience  
>>> to install the sample binaries once the samples get released.  
>>> Plugins should not be a requirement for sample applications, it  
>>> should be an option.
>> I agree that plugins are distribution mechanism.  There are 2 main  
>> differences regarding plugins with the latest sample changes:
>> 1) The datasource definitions have been provided in a plugin rather  
>> than requiring the user to create the definitions via the admin  
>> console based on the system database.  In that sense ... you could  
>> look at the admin console and manual directions earlier as our  
>> "distribution mechanism". We have to pick something for this  
>> purpose and I think the plugin is perhaps easier for the user.  I  
>> don't think manually creating the DB configurations adds any value  
>> to the samples.  If there is value then we can come up with some  
>> more manual steps ... but I think that might be more confusing for  
>> the users.
>
> I agree, creating a database or connection pool does not make the  
> sample app but rather complements it and it is already covered in  
> other sections of the doc. So yes, it make sense to have a "Sample  
> applications prerequisite plugin" that would be common to all  
> samples, creates a sample database, connection pools and defines any  
> other configuration that might be required by some of the samples.
>
>> 2) The Geronimo deployment plans are created as a result of  
>> building the plugins rather that included as pure source.  This is  
>> a little more difficult for the user IMO because the user must  
>> build to see the plan.
>
> That's one of my biggest points. The plans are created automatically  
> by the car-maven-plugin, but for that you need to provide at least a  
> plan.xml and don't really know what else. That is as far as I know  
> about the maven plugin. This is links back to my previous comment  
> about requiring a new user to be familiar with the Geronimo plugin  
> architecture and the car-maven-plugin in particular.

um, how does typing
mvn clean install
require you to know anything about maven or our c-m-p plugin or our  
plugin architecture?

Do you find the instructions on http://cwiki.apache.org/confluence/display/GMOxDOC21/Sample+applications 
  insufficiently clear about how to build the samples and find the  
completed plan in case you want to deploy the sample by hand?

BTW IMO the samples space should link to this page rather than having  
a list of links to the individual samples.

>
>
>> However, we have started adding adding a copy of the plan into the  
>> documentation (where we had included a copy of the plans earlier).   
>> I think a user that doesn't want to build can take the distributed  
>> artifacts (ears, wars) and distribute them with the plans that we  
>> include in the doc if they want to avoid the plugins.
>
> So, would this require the user to repackage the binaries to include  
> the plans?

um, no.  Dealing with plans included in javaee artifacts is a  
proprietary extension, not javaee behavior.  The javaee spec way to  
deploy something is with an external plan, per jsr-88.  I suggest we  
use it.

thanks
david jencks

>
>
>>>
>>> what do others think?
>> What are the alternatives?
>
> Why not keeping the sample apps as just that, sample apps. Let's fix/ 
> improve them where needed, keep an ear being an ear, a war being a  
> war..... If we don't offer simple sample applications then we should  
> provide some sections in the doc for adapting/migrating applications  
> to Geronimo and include less specialized samples there.
>
> Cheers!
> Hernan
>
>>>
>>> Cheers!
>>> Hernan
>>>