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: domain of hcunico@gmail.com designates
 74.125.46.31 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:subject:references
         :in-reply-to:content-type:content-transfer-encoding;
        b=hQPmEzTAP9TnWKqOMcUf9o1eSJjQXiKKt9MQVlxo7w5m2SsglLrBwHfpRuNl4lw07i
         3vZmZj9OiCo9DjebnSv9BKiLLaxc3bjmRG9P97ZxKGMXZ+3VCskhCVeGQqyjB6hi7qAc
         ukQcDyI4INCgZcknpNarMnN766sd4BRgEhD/s=
Message-ID: <485168DB.7090605@gmail.com>
Date: Thu, 12 Jun 2008 14:20:11 -0400
From: Hernan Cunico <hcunico@gmail.com>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: dev@geronimo.apache.org
Subject: Re: sample applications
References: <48514FC7.5030009@gmail.com>
 <B84246E3-17A5-479D-8479-2E3A769DB957@yahoo.com>
In-Reply-To: <B84246E3-17A5-479D-8479-2E3A769DB957@yahoo.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

At this very moment I'm not being able to build the samples so I can't really comment on the current binaries structure.

If the samples were not working I think we should have fixed the specific errors, same thing goes for the docs. In previous releases, the samples worked.

I like the idea of having a Geronimo Best Practices section in the doc; but again, I would rather have the samples as simple as possible. Stick to the very basics, what are the minimum requirements any given application needs to run on Geronimo. Plugins is gravy on top. This is just my very personal opinion.

A Best Practices section would be fantastic, it would also be great to have other sections for creating specific plugins (configurations, applications, custom server assemblies, etc). There is where I think would be best to have all these differentiating features in Geronimo.

My considerations with maven are just as arguable if you will and it's based on first impressions. For example, building a very basic web sample app (let's say 1 jsp), it may take some time to build depending connectivity speed and availability of the repos; actually the first few times it is likely to fail. This last one in particular is why I can't build the samples at this moment. 5th attempt now and failing at different intervals. If this is annoying to me, it must be for others as well. So again, I think simple is better.

I was not suggesting to include the samples source and binaries in Confluence. I'm saying that's what we had in the past and it was pretty easy for the readers to get the source and/or binaries. I agree, neither the doc nor the sample code was perfect but those samples, AFAICT, worked.

To get the source and binaries out of Confluence all we needed to do was to put the source in svn, fix the issues with the code and docs and make the binaries available the same way we do with the server binaries.

Sorry for keep repeating myself but I still don't see why we need to do such a huge transformation to these very simple sample apps.

Cheers!
Hernan

David Jencks wrote:
> 
> On Jun 12, 2008, at 9:33 AM, 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".
>>
>> 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.
>>
>> 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.
>>
>> 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.
>>
>> what do others think?
> 
> I think some realism about our capabilities for maintaining the 
> documentation is called for.  If the samples had been being kept up to 
> date, working, adapted to latest geronimo, etc, I'd say you might have a 
> point.  However they didn't work, the documentation was full of 
> misleading statements and errors, and they didn't demonstrate best 
> practices in geronimo.  One of my main goals working on the samples is 
> to produce something simple and automated enough so we have some slight 
> chance of keeping it up to date: even with the simplifications I've 
> introduced I don't have a lot of hope for this.
> 
> When the samples are released, if we stick with the current setup based 
> on plugins, we will be publishing the javaee application artifacts and 
> the plugins.  The plans to deploy the artifacts independently are inside 
> the plugins.  While this is not the most convenient location the plans 
> will be available.
> 
> I also don't think that requiring users to build the sample projects 
> with maven is unreasonable.  We certainly don't provide any other way of 
> building the applications, and I don't see any reason or argument why we 
> should.  If you build the apps you get the plans in 
> <sample>-[jetty|tomcat]/target/resources/META-INF/plan.xml. I've tried 
> to state this clearly in the top level samples documentation.
> 
> If you are suggesting including source and binary attachments in 
> confluence I think that is a bad idea -- they will never get updated -- 
> but could be considered after we release the samples.  We certainly 
> can't do that before a release vote.
> 
> thanks
> david jencks
> 
>>
>>
>> Cheers!
>> Hernan
> 
>