Re: Improve geronimo samples use experience
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 bundle. thanks david jencks Lin On Mon, Oct 13, 2008 at 12:35 PM, Donald Woods <[EMAIL PROTECTED]> 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 http://cwiki.apache.org/GMOxDOC21/sample-applications.html - Install the specific sample artifact built locally using the archive and the appropriate plan from the -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
Re: Improve geronimo samples use experience
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. Lin On Mon, Oct 13, 2008 at 12:35 PM, Donald Woods <[EMAIL PROTECTED]> 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 >> http://cwiki.apache.org/GMOxDOC21/sample-applications.html >> - Install the specific sample artifact built locally using the archive and >> the appropriate plan from the >> -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
Re: Improve geronimo samples use experience
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 http://cwiki.apache.org/GMOxDOC21/sample-applications.html - Install the specific sample artifact built locally using the archive and the appropriate plan from the -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:
Re: Improve geronimo samples use experience
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 http://cwiki.apache.org/GMOxDOC21/sample-applications.html - Install the specific sample artifact built locally using the archive and the appropriate plan from the -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: http://www.nabble.com/Improve-geronimo-samples-use-experience-tp19948784s134p19948784.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
Re: Improve geronimo samples use experience
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: http://www.nabble.com/Improve-geronimo-samples-use-experience-tp19948784s134p19948784.html Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.
