Re: Another samples issue ... how much does a user have to build?
samples/trunk also updated to use the server/trunk/repository files. -Donald Donald Woods wrote: I just upgraded the 2.1 samples branch (r683972) to use the updated genesis-1.5-SNAPSHOT build (which turns off the unique timestamps on snapshot artifacts.) I'll work on updating the build to use the server's private repo artifacts later today and then will work on merging all these changes into the samples trunk. -Donald Joe Bohn wrote: In the past we had asserted that a user should be able to pick up an individual sample and build it. Because of a recent change in the samples this is no longer possible (at least not until we release some artifacts that can be downloaded without building locally - see details on the issue below). I personally think it is acceptable to provide some general directions on building samples that require a user (at least the first time) to checkout the entire samples svn tree and build from the top level. It takes about 5 minutes to build all of the samples. Following that initial build a user could choose to build just one sample at a time. We can also provide some more complicated directions for users that have some issue with building all of the samples. If I don't hear any strong objections (along with solutions to the current issue that requires a top level build) then I will go ahead and change the doc accordingly. Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp & servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun-plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323). In addition to the issue above, there are other general build steps required which will benefit from a common build process rather than including them in each sample description. For example, we need to make the svn repository artifacts for the specific server release available in the user's local maven repo. I'd rather not have to include those steps in each sample but rather point to a common build. Thanks, Joe smime.p7s Description: S/MIME Cryptographic Signature
Re: Another samples issue ... how much does a user have to build?
I just upgraded the 2.1 samples branch (r683972) to use the updated genesis-1.5-SNAPSHOT build (which turns off the unique timestamps on snapshot artifacts.) I'll work on updating the build to use the server's private repo artifacts later today and then will work on merging all these changes into the samples trunk. -Donald Joe Bohn wrote: In the past we had asserted that a user should be able to pick up an individual sample and build it. Because of a recent change in the samples this is no longer possible (at least not until we release some artifacts that can be downloaded without building locally - see details on the issue below). I personally think it is acceptable to provide some general directions on building samples that require a user (at least the first time) to checkout the entire samples svn tree and build from the top level. It takes about 5 minutes to build all of the samples. Following that initial build a user could choose to build just one sample at a time. We can also provide some more complicated directions for users that have some issue with building all of the samples. If I don't hear any strong objections (along with solutions to the current issue that requires a top level build) then I will go ahead and change the doc accordingly. Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp & servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun-plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323). In addition to the issue above, there are other general build steps required which will benefit from a common build process rather than including them in each sample description. For example, we need to make the svn repository artifacts for the specific server release available in the user's local maven repo. I'd rather not have to include those steps in each sample but rather point to a common build. Thanks, Joe smime.p7s Description: S/MIME Cryptographic Signature
Re: Another samples issue ... how much does a user have to build?
I agree with you that converting to a maven plugin will have the same issue. Since this only affect snapshot, I don't think this is a big deal. Lin On Thu, Jul 31, 2008 at 11:54 AM, Joe Bohn <[EMAIL PROTECTED]> wrote: > Lin Sun wrote: >> >> I thought of converting this to a maven plugin today, but Joe, do you >> think this will still be an issue after we release the sample and >> publish the buildutil to a public maven repo? > > I don't think this will be an issue for the 2.1.2 samples once we have them > published. It will continue to be an issue for any samples that are > currently under development (SNAPSHOTs). For snapshots I think it is > reasonable to expect the user to build from the top level first. > > I'm not sure if creating a maven plugin will improve things much. This > plugin would still have to be built and released via some mechanism. If it > ends up being similar to the car-maven-plugin on the server a bootstrap or > something similar would be required prior to building an individual sample. > From a user perspective, I don't see that being much different than what we > have now. > > Joe > > >> >> Lin >> >> On Fri, Jul 18, 2008 at 1:35 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: >>> >>> Specifics on why this is an issue: >>> - We had to add in the building of a tomcat utility (Txt2Html included in >>> buildutil). This is used to generate html from java source and jsp >>> files. >>> The html is then included with the jsp & servlet samples and can be >>> displayed when running the samples (we might want to consider this for >>> some >>> of our other samples as well). The utility is run via ant and so we are >>> using the maven-antrun-plugin. When the configuration for the execution >>> of >>> the utility was included in the specific sample it worked great for just >>> that one sample but produced errors when attempting to build from a >>> higher >>> level. This is apparently because of the way the the maven plugin is >>> resolved and loaded. To get the build working from the top level we had >>> to >>> move the dependency of the antrun-plugin on buildutil up under >>> pluginmanagement. However, this has the effect of now requiring >>> buildutil >>> to be available for all samples even if it is not used (since most >>> samples >>> use the antrun-plugin for other purposes). There is a maven issue that >>> describes our problem (and indicates that it is fixed in maven 2.1.* but >>> not >>> 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323). >> > >
Re: Another samples issue ... how much does a user have to build?
Lin Sun wrote: I thought of converting this to a maven plugin today, but Joe, do you think this will still be an issue after we release the sample and publish the buildutil to a public maven repo? I don't think this will be an issue for the 2.1.2 samples once we have them published. It will continue to be an issue for any samples that are currently under development (SNAPSHOTs). For snapshots I think it is reasonable to expect the user to build from the top level first. I'm not sure if creating a maven plugin will improve things much. This plugin would still have to be built and released via some mechanism. If it ends up being similar to the car-maven-plugin on the server a bootstrap or something similar would be required prior to building an individual sample. From a user perspective, I don't see that being much different than what we have now. Joe Lin On Fri, Jul 18, 2008 at 1:35 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp & servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun-plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323).
Re: Another samples issue ... how much does a user have to build?
I thought of converting this to a maven plugin today, but Joe, do you think this will still be an issue after we release the sample and publish the buildutil to a public maven repo? Lin On Fri, Jul 18, 2008 at 1:35 PM, Joe Bohn <[EMAIL PROTECTED]> wrote: > Specifics on why this is an issue: > - We had to add in the building of a tomcat utility (Txt2Html included in > buildutil). This is used to generate html from java source and jsp files. > The html is then included with the jsp & servlet samples and can be > displayed when running the samples (we might want to consider this for some > of our other samples as well). The utility is run via ant and so we are > using the maven-antrun-plugin. When the configuration for the execution of > the utility was included in the specific sample it worked great for just > that one sample but produced errors when attempting to build from a higher > level. This is apparently because of the way the the maven plugin is > resolved and loaded. To get the build working from the top level we had to > move the dependency of the antrun-plugin on buildutil up under > pluginmanagement. However, this has the effect of now requiring buildutil > to be available for all samples even if it is not used (since most samples > use the antrun-plugin for other purposes). There is a maven issue that > describes our problem (and indicates that it is fixed in maven 2.1.* but not > 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323).
Re: Another samples issue ... how much does a user have to build?
David Jencks wrote: On Jul 18, 2008, at 10:35 AM, Joe Bohn wrote: In the past we had asserted that a user should be able to pick up an individual sample and build it. Because of a recent change in the samples this is no longer possible (at least not until we release some artifacts that can be downloaded without building locally - see details on the issue below). I personally think it is acceptable to provide some general directions on building samples that require a user (at least the first time) to checkout the entire samples svn tree and build from the top level. It takes about 5 minutes to build all of the samples. Following that initial build a user could choose to build just one sample at a time. We can also provide some more complicated directions for users that have some issue with building all of the samples. If I don't hear any strong objections (along with solutions to the current issue that requires a top level build) then I will go ahead and change the doc accordingly. I'm fine with this except I don't think we need to provide error-prone instructions that are likely to stop working soon for people who don't want to build all the samples. Agree. Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp & servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun-plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323). I wonder if we should write a maven plugin to do this text to html conversion? I haven't looked at what is going on or the problem at all. It's hard to believe there is no solution available now. In addition to the issue above, there are other general build steps required which will benefit from a common build process rather than including them in each sample description. For example, we need to make the svn repository artifacts for the specific server release available in the user's local maven repo. I'd rather not have to include those steps in each sample but rather point to a common build. Maybe we should rethink our svn repository strategy. It doesn't really work with the idea of plugins. How about if we do something like shading the tomcat jars to another package and releasing them with our groupId? Disagree. I see shading as a evil hack, as it complicates users who want to integrate Geronimo into other solutions and still be able to easily determine all the dependencies we include for their own legal requirements. Why are we not doing like OpenEJB and just adding a pointer to a svn backed repo, since we need to have these private/pinned artifacts around for Samples and Plugin builds? -Donald thanks david jencks Thanks, Joe smime.p7s Description: S/MIME Cryptographic Signature
Re: Another samples issue ... how much does a user have to build?
David Jencks wrote: On Jul 18, 2008, at 10:35 AM, Joe Bohn wrote: In the past we had asserted that a user should be able to pick up an individual sample and build it. Because of a recent change in the samples this is no longer possible (at least not until we release some artifacts that can be downloaded without building locally - see details on the issue below). I personally think it is acceptable to provide some general directions on building samples that require a user (at least the first time) to checkout the entire samples svn tree and build from the top level. It takes about 5 minutes to build all of the samples. Following that initial build a user could choose to build just one sample at a time. We can also provide some more complicated directions for users that have some issue with building all of the samples. If I don't hear any strong objections (along with solutions to the current issue that requires a top level build) then I will go ahead and change the doc accordingly. I'm fine with this except I don't think we need to provide error-prone instructions that are likely to stop working soon for people who don't want to build all the samples. I'm fine with eliminating the more complicated directions. Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp & servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun-plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323). I wonder if we should write a maven plugin to do this text to html conversion? I haven't looked at what is going on or the problem at all. It's hard to believe there is no solution available now. In addition to the issue above, there are other general build steps required which will benefit from a common build process rather than including them in each sample description. For example, we need to make the svn repository artifacts for the specific server release available in the user's local maven repo. I'd rather not have to include those steps in each sample but rather point to a common build. Maybe we should rethink our svn repository strategy. It doesn't really work with the idea of plugins. How about if we do something like shading the tomcat jars to another package and releasing them with our groupId? I think it would be great if we could release these images under some other package so that they can be downloaded. However, I wonder if there are dependencies that might be broken if we did something like that (I mean apart from dependencies we create). At the moment we only change the version # for our artifacts so any reference from poms would not be affected unless the version number itself was included in the reference. thanks david jencks Thanks, Joe
Re: Another samples issue ... how much does a user have to build?
On Jul 18, 2008, at 10:35 AM, Joe Bohn wrote: In the past we had asserted that a user should be able to pick up an individual sample and build it. Because of a recent change in the samples this is no longer possible (at least not until we release some artifacts that can be downloaded without building locally - see details on the issue below). I personally think it is acceptable to provide some general directions on building samples that require a user (at least the first time) to checkout the entire samples svn tree and build from the top level. It takes about 5 minutes to build all of the samples. Following that initial build a user could choose to build just one sample at a time. We can also provide some more complicated directions for users that have some issue with building all of the samples. If I don't hear any strong objections (along with solutions to the current issue that requires a top level build) then I will go ahead and change the doc accordingly. I'm fine with this except I don't think we need to provide error-prone instructions that are likely to stop working soon for people who don't want to build all the samples. Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp & servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun- plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323 ). I wonder if we should write a maven plugin to do this text to html conversion? I haven't looked at what is going on or the problem at all. It's hard to believe there is no solution available now. In addition to the issue above, there are other general build steps required which will benefit from a common build process rather than including them in each sample description. For example, we need to make the svn repository artifacts for the specific server release available in the user's local maven repo. I'd rather not have to include those steps in each sample but rather point to a common build. Maybe we should rethink our svn repository strategy. It doesn't really work with the idea of plugins. How about if we do something like shading the tomcat jars to another package and releasing them with our groupId? thanks david jencks Thanks, Joe
Another samples issue ... how much does a user have to build?
In the past we had asserted that a user should be able to pick up an individual sample and build it. Because of a recent change in the samples this is no longer possible (at least not until we release some artifacts that can be downloaded without building locally - see details on the issue below). I personally think it is acceptable to provide some general directions on building samples that require a user (at least the first time) to checkout the entire samples svn tree and build from the top level. It takes about 5 minutes to build all of the samples. Following that initial build a user could choose to build just one sample at a time. We can also provide some more complicated directions for users that have some issue with building all of the samples. If I don't hear any strong objections (along with solutions to the current issue that requires a top level build) then I will go ahead and change the doc accordingly. Specifics on why this is an issue: - We had to add in the building of a tomcat utility (Txt2Html included in buildutil). This is used to generate html from java source and jsp files. The html is then included with the jsp & servlet samples and can be displayed when running the samples (we might want to consider this for some of our other samples as well). The utility is run via ant and so we are using the maven-antrun-plugin. When the configuration for the execution of the utility was included in the specific sample it worked great for just that one sample but produced errors when attempting to build from a higher level. This is apparently because of the way the the maven plugin is resolved and loaded. To get the build working from the top level we had to move the dependency of the antrun-plugin on buildutil up under pluginmanagement. However, this has the effect of now requiring buildutil to be available for all samples even if it is not used (since most samples use the antrun-plugin for other purposes). There is a maven issue that describes our problem (and indicates that it is fixed in maven 2.1.* but not 2.0.*) - MNG-1323 (http://jira.codehaus.org/browse/MNG-1323). In addition to the issue above, there are other general build steps required which will benefit from a common build process rather than including them in each sample description. For example, we need to make the svn repository artifacts for the specific server release available in the user's local maven repo. I'd rather not have to include those steps in each sample but rather point to a common build. Thanks, Joe
