geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <>
Subject Re: sample applications
Date Thu, 12 Jun 2008 17:19:01 GMT

I had some of the same concerns but I don't think we're very far off 
from the original goal as long as we address the documentation 
correctly.  Some more comments to your specific concerns below.

Hernan Cunico wrote:
> Hi All,
> I'm looking back into the sample apps (samples and docs) and I think we 
> are missing the point of the samples.
> We kinda had this discussion some time ago and I thought we were going 
> to go in a different way.
> The purpose of the sample applications was to demonstrate Geronimo 
> support/implementation of the different functionalities and features. To 
> provide some sort of transition path from any other app/platform to 
> Geronimo. Start easy with the basic requirements, understanding the 
> Geronimo specific deployment plans, etc. and then gradually involve the 
> different G specific "goodies".

No arguments here.  We should keep the source code as simple as possible 
to demonstrate the concepts and ensure that the user has an example as a 
way to kick-start their own development.

> If we require all users to understand and be familiar with Geronimo 
> plugins and maven so then they can get their hands on a sample 
> application for Geronimo; I think we are adding unnecessary barriers for 
> new users.

I don't think we are forcing them to be familiar with Geronimo plugins. 
   However, we are using the deployment plans created from the 
car-maven-plugin so we must point them at those plans.  The trick here 
is to point them at the plan without necessarily getting into the 
details of plugins.  BTW, we have also been including the target plans 
in the wiki doc itself ... so the user doesn't even need to build to see 
a plan unless they really want to do so.  IIRC the samples have always 
required maven to build (at least in the 2.0 timeframe).

> In the past, we provided the samples source and in most cases the 
> binaries ready to install, all along as part of the full sample 
> documentation. Users were not required to use svn, plugins, or maven if 
> all they wanted to do was to get familiar with how to implement JAX-WS 
> in Geronimo for instance.

If we can formally release the plugins, then binaries will still be 
available without the need to build them (no using maven, svn, or 
anything else).  However, I don't think the svn requirement is a 
critical issue given that we were already requiring maven.  If, for some 
reason, this is an issue we can always make a source distribution zip 
available along with the binaries.

The biggest thing that we need to avoid (IMO) is any attempt to use the 
wiki as a code repository.  We've already proven that isn't manageable.

> 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.
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. 
  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.

> what do others think?

What are the alternatives?

> Cheers!
> Hernan

View raw message