geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Improve geronimo samples use experience
Date Mon, 13 Oct 2008 17:05:05 GMT

On Oct 13, 2008, at 9:47 AM, Lin Sun wrote:

> I agree.  It would be nice if we can provide users a downlodable
> sample bundle, which contains the prebuilt artifacts and their plans.
> This would save users from learning svn, maven and digging around for
> the plans.

This seems like a reasonable approach to me.  I think that publishing  
the plans as attached artifacts with a "plan" classifier will be the  
most maven-friendly way to make them available to the assembly plugin  
when putting together this bundle.

I wish we had a way to get a geronimo-plugin.xml into the car file  
when just deploying an app.  That way users could construct a plugin  
equivalent to ours just by deploying the app.  However this might not  
be too easy to do and shouldn't hold up moving forward on some kind of  

david jencks

> Lin
> On Mon, Oct 13, 2008 at 12:35 PM, Donald Woods <>  
> wrote:
>> I'd like to see us generate a source + prebuilt artifacts (WAR/EAR +
>> deployment plans) as a downloadable assembly off our Downloads page.
>> Requiring users to checkout the Samples source from SVN is not  
>> friendly to
>> those that don't have a svn client installed (Windows and some  
>> default Linux
>> installs) and requiring them to build the Samples just so they can  
>> look at
>> the deployment plans requires more work than most average users  
>> will be
>> willing to spend.
>> -Donald
>> Joe Bohn wrote:
>>> I too agree that a new user should not need to deal with plugins  
>>> initially
>>> unless they really want to.
>>> I think they can already do this today ... but perhaps not as  
>>> cleanly as
>>> we would like (and not without the user seeing the word "plugin").
>>> The important thing (as David mentioned) is that they need to  
>>> build the
>>> samples first.  I don't think that is an unreasonable request.  In  
>>> fact,
>>> until our recent release of samples, a user had no choice but to  
>>> build the
>>> samples locally as there were no published artifacts.
>>> Once a user has built samples they can do the following if they  
>>> don't want
>>> to leverage the plugins:
>>> - Install any necessary prereqs (such as the sample-datasource).   
>>> There
>>> are a number of ways to do this for the datasource (if  
>>> necessary) ....
>>> documented in the wiki.  The easiest is to install the plugin but  
>>> a user
>>> doesn't have to go that route. See
>>> - Install the specific sample artifact built locally using the  
>>> archive and
>>> the appropriate plan from the
>>> <sample>-tomcat/target/resources/META-INF/plan.xml (or jetty  
>>> equivalent).
>>> It's a little difficult to get the plan from that location (esp  
>>> since the
>>> user must choose the correct plan for the server image they want  
>>> to use) but
>>> I'm not convinced it is any worse than having to pull it from a  
>>> maven repo.
>>> It would be ideal if we could:
>>> - Produce a single plan in the build that could work with either  
>>> tomcat or
>>> jetty to accompany the ear/war
>>> - Put that plan in a more "user friendly" location (but somewhere  
>>> under
>>> target rather than src).
>>> - If we do anything more, we must keep the content from polluting  
>>> the src
>>> tree.  Part of the work necessary to get samples to a state where  
>>> they could
>>> be released was to remove the special build processing that ended  
>>> up adding
>>> various items into the src tree which caused problems for the  
>>> maven release
>>> process.
>>> Joe
>>> David Jencks wrote:
>>>> On Oct 12, 2008, at 9:47 PM, Forrest_Xia wrote:
>>>>> Generating standalone and deployment-ready war or ear ball will  
>>>>> make
>>>>> geronimo
>>>>> samples more easier for first try, and will improve user's use
>>>>> experience.
>>>>> For currently generated war or ear of samples 2.1.2 release,  
>>>>> user should
>>>>> supply an external deployment plan.xml to make it deployable. I  
>>>>> think it
>>>>> will lead user bad use experience when first trying a simple  
>>>>> sample war
>>>>> or
>>>>> ear ball.
>>>>> Of course, I believe geronimo plugin is a good stuff to try those
>>>>> samples,
>>>>> but it takes time for user to build up geronimo plugin knowledge.
>>>>> For an experienced JEE developer, he/she is used to consider  
>>>>> a .ear or
>>>>> .war
>>>>> ball is a ready-to-deploy artifact. Suppose that, If they  
>>>>> finally find
>>>>> they
>>>>> need to learn more about geronimo in order to make a simple  
>>>>> sample's
>>>>> .ear or
>>>>> .war deployed succussfully, what feeling will they have?
>>>>> I think well considering user's use habit and ensuring first-try  
>>>>> success
>>>>> experience is very important to attract new user to stay with  
>>>>> our JEE
>>>>> server
>>>>> and consequently work with it.
>>>>> So I would suggest we add back geronimo specific deployment plan  
>>>>> into
>>>>> packaged war or ear balls. What do you think of this?
>>>> Well, the _only_ javaee compliant location for a plan that I know  
>>>> of is
>>>> _outside_ the javaee artifact... see jsr88.  Any time you include  
>>>> a plan
>>>> inside a javaee artifact you are using a proprietary extension.
>>>> I'm not familiar with what other container recommend, are you?
>>>> Most of the samples do need a plan to indicate at least the  
>>>> dependency on
>>>> the samples datasource.  I'm not really convinced that hiding  
>>>> this plan
>>>> inside the javaee artifact will make it clear to users that the  
>>>> dependency
>>>> is required.
>>>> I'm not completely opposed to including a plan if we can provide  
>>>> some
>>>> automated way to make sure it is at least as functional as the  
>>>> related plans
>>>> in the plugin subprojects.  Do you have any ideas on how to  
>>>> assure this?  Is
>>>> it worth the extra effort?
>>>> Another possibility might be to publish the completed plans from  
>>>> the
>>>> plugin subprojects as additional attached artifacts with say  
>>>> classifier
>>>> "plan".  That way the plans would be available through maven just  
>>>> as the
>>>> javaee artifacts are.  To me the main problem with deploying the  
>>>> javaee
>>>> artifacts is that you have to build the plugins anyway to get the  
>>>> completed
>>>> plan, and making the plans as available as the javaee artifacts  
>>>> might solve
>>>> this problem.
>>>> thanks
>>>> david jencks
>>>>> Forrest
>>>>> --
>>>>> View this message in context:
>>>>> Sent from the Apache Geronimo - Dev mailing list archive at  

View raw message