geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Bohn <joe.b...@earthlink.net>
Subject Re: Another samples issue ... how much does a user have to build?
Date Fri, 18 Jul 2008 21:32:52 GMT
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
>>
> 
> 


Mime
View raw message