Re: Jenkins and Framework build path dependency
Re: Jenkins and Framework build path dependency
- Subject: Re: Jenkins and Framework build path dependency
- From: David Avendasora <email@hidden>
- Date: Fri, 09 Mar 2012 08:21:07 +0800
On Mar 9, 2012, at 4:32 AM, Pascal Robert wrote:
>
> Le 2012-03-08 à 14:34, Daniel Roy a écrit :
>
>> Hi,
>>
>> I've setup Jenkins in test to start building our frameworks and applications. WOJenkins is excellent - thank you so much for providing this David Avendasora (and anyone else who may have helped)!
>>
>> We build our own ERPrototypes because we have some custom types we need to use. Our frameworks use this ERPrototypes framework instead of the vanilla Wonder ERPrototypes. We reference our ERPrototypes framework as a Project dependency in the build path instead of a Library (framework) dependency. This works fine in Eclipse because Eclipse can magically account for the linked project and include the linked project's files in the build process. However, Jenkins can't resolve the dependency.
>>
>> Using the scripts provided in WOJenkins, the build process never pulls in the required framework because the .classpath entry in the affected Eclipe project is as follows:
>>
>> <classpathentry combineaccessrules="false" exported="true" kind="src" path="/ERPrototypes"/>
>>
>> I've tried modifying the WOJenkins setup script to unpack the ERPrototypes framework into the correct location of the affected project, but that doesn't make any difference during build time because ant doesn't know about the dependency.
>>
>> Does anyone have any ideas how the build can be accomplished? I could modify the .classpath file of the affected project after it's pulled down from SVN and change the ERPrototypes line to be the standard "WOFramework/ERPrototypes", since our ERPrototype is build before all other frameworks in the Jenkins build process. Or, is there possibly another way?
>
> One way to achieve this would be to change the grep that is done by WOJenkins on .classpath so that it works for frameworks defined as projects would work.
The latest version of the WOJenkins scripts should have no problem finding other jobs with names the same as the framework.
I modified the setupWonderProjectWorkspace.sh script to work with all-in-one jobs as well and created an example job config: https://github.com/avendasora/WOJenkins_Job_WOProject_AllInOne_Git
But no matter what, if he's modifying Wonder, then he should have his own fork of the Github repository with his modifications and simply be building that instead of "true" wonder. No sense in building something and then going and replacing parts of it. Just build what you want in the first place.
Dave
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden