Oh, and I'd love to get some Github pull requests with any improvements. These work for me. I tried to make them general-purpose, but I don't believe that there is any such thing as a "standard" build process with WO. Everyone has some weird stuff that they do.
A lot of the stuff that the jobs ask for at startup could be hard-coded, but I wanted it to be easy for people to use their own clones of Wonder and the Job Configs without needing to dive into the Job Config. Dave On Jan 25, 2012, at 12:26 PM, David Avendasora wrote: > Hi David, David, > > Okay, Okay! You have pulled me out of my hiding in darkest Borneo. > > Yes, I have some completely updated scripts / job configs for building > Git-based projects & frameworks in my Github repository. > > The job config repositories assume that you will be using the Git for Wonder, > but there are different configs if your actual WO Project is stored in SVN or > Git: > > https://github.com/avendasora/WOJenkins_Job_WOProject_SVN > https://github.com/avendasora/WOJenkins_Job_WOProject_Git > > They both are dependent upon WebObjects and Wonder having been installed on > the Jenkins server using this Job Config: > > https://github.com/avendasora/WOJenkins_Job_InstallWOAndWOnder > > All of these Job Configs are intended to be cloned directly into your > JENKINS_HOME/jobs/ directory. You can then call http://myJenkinsServer/reload > on Jenkins to get it to see the new job definitions. > > The WOJenkins_Job_InstallWOAndWOnder job will take care of _everything_ > related to downloading and installing WebObjects and Wonder on your Jenkins > server, which is nice. > > If you already have WO and/or WOnder installed, **you will still need to use > this job** as it installs them in a location specifically for Jenkins to use > and the other jobs depend on them being there. > > These installs of WebObjects and WOnder will not conflict with other installs > you may have of WebObjects and Wonder, unless you have been using my scripts > already. In fact, they allow you to have WO 5.3.3 and WO 5.4.3 installed > simultaneously, along with any number of different versions of Wonder. So you > can easily have one Jenkins job build against WO 5.3.3 with a 4-year-old > version of Wonder and another Job building against WO 5.4.3 and the Head of > Wonder Master. > > Dave > > On Jan 25, 2012, at 2:46 AM, David Holt wrote: > >> Hi David, >> >> I believe the newer stuff is on his GitHub account. >> >> https://github.com/avendasora >> >> David >> >> On 2012-01-24, at 10:21 AM, David LeBer wrote: >> >>> Does anyone have details on migrating from David's original scripts (that >>> use SVN) to using git for Wonder? >>> >>> D >>> >>> -- >>> David LeBer >>> Codeferous Software >>> >>> On 2012-01-24, at 1:06 PM, Pascal Robert wrote: >>> >>>> Look like I forgot to add a link to this presentation on the Screencasts >>>> page, but it's in the RSS feed. Anyway, direct link: >>>> >>>> http://www.wocommunity.org/podcasts/wowodc/east09/WOWODC09E-MultipleVersionsWO.mov >>>> >>>>> Dave Avendasora made a great presentation (available on the podcast) that >>>>> demonstrates how to set up Hudson(Now Jenkins) to build wonder and your >>>>> own apps. It's titled Practical Builds (WOWODC East 2009). >>>>> >>>>> Ramsey >>>>> >>>>> On Jan 24, 2012, at 9:05 AM, Gino Pacitti wrote: >>>>> >>>>>> Sounds cool... is there more info on the wocommunity site wiki as to >>>>>> implementation etc... >>>>>> >>>>>> Gino >>>>>> On 24 Jan 2012, at 16:02, Daniel Beatty wrote: >>>>>> >>>>>>> Greetings Gino, >>>>>>> The benefits I have found with Hudson and its little brother Jenkins is >>>>>>> one gets a consistent and automated build and installation system. >>>>>>> Its integration into the version control repository be it Subversion, >>>>>>> Git, or whatever is your pick tends to support a wide variety software >>>>>>> engineering models. >>>>>>> >>>>>>> Other qualities I have benefited from is the consistency with things >>>>>>> like permissions and all of the little things that act like weeds if >>>>>>> one is trying to build these things from the developer's environment to >>>>>>> the next. It also frees up a project from the quirks of individual >>>>>>> development environments which can vary from person to person and >>>>>>> project to project. >>>>>>> >>>>>>> In the end, the benefit list is a list of little things. If those >>>>>>> little things matter, then the answer is clear. For my production >>>>>>> environment, it does and it makes sense. >>>>>>> >>>>>>> V/R, >>>>>>> >>>>>>> >>>>>>> Dan Beatty, ABD >>>>>>> Ph.D. Student >>>>>>> Texas Tech University >>>>>>> dan.bea...@mac.com >>>>>>> http://web.me.com/danielbeatty/My_Home_Page/Welcome.html >>>>>>> (806)438-6620 >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Jan 24, 2012, at 5:04 AM, Gino Pacitti wrote: >>>>>>> >>>>>>>> Hi Paul >>>>>>>> >>>>>>>> What are the benefits? >>>>>>>> >>>>>>>> Gino >>>>>>>> On 24 Jan 2012, at 13:04, Paul Yu wrote: >>>>>>>> >>>>>>>>> Gino >>>>>>>>> >>>>>>>>> I would highly recommend setting up a Jenkins build server, even if >>>>>>>>> it is on your development machine to do your production builds. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Paul Yu >>>>>>>>> Sent with Sparrow >>>>>>>>> >>>>>>>>> On Tuesday, January 24, 2012 at 7:51 AM, Gino Pacitti wrote: >>>>>>>>> >>>>>>>>>> Currently builds from eclipse result in the startup script being non >>>>>>>>>> executable unless changed to appserver user... >>>>>>>>>> >>>>>>>>>> I am moving from xcode to eclipse and just wanted a convenience >>>>>>>>>> method >>>>>>>>>> of not having to keep manually changing the owner to appserver and >>>>>>>>>> instead making the startup script the same as I had it on xcode... >>>>>>>>>> >>>>>>>>>> Gino >>>>>>>>>> On 24 Jan 2012, at 12:47, Pascal Robert wrote: >>>>>>>>>> >>>>>>>>>>> But why do you need to do that? Execute permissions is already set >>>>>>>>>>> for the owner and the group. I guess you want to give "other" >>>>>>>>>>> execute permissions too? Don't forget that it can be a security >>>>>>>>>>> risk... >>>>>>>>>>> >>>>>>>>>>>> Hi All >>>>>>>>>>>> >>>>>>>>>>>> I got some great advice on ANT replacement for a permission >>>>>>>>>>>> variable that was in XCode... >>>>>>>>>>>> >>>>>>>>>>>> It was: >>>>>>>>>>>> >>>>>>>>>>>> <chmod file="${dest.dir}/${build.app.name}" perm="ugo+rx"/> >>>>>>>>>>>> >>>>>>>>>>>> But I am not an expert in where it would go in the build.xml >>>>>>>>>>>> file... >>>>>>>>>>>> >>>>>>>>>>>> Can anyone point me in the right direction? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Gino >>>>>>>>>>>> _______________________________________________ >>>>>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca >>>>>>>>>>>> >>>>>>>>>>>> This email sent to prob...@macti.ca >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/pyu%40mac.com >>>>>>>>>> >>>>>>>>>> This email sent to p...@mac.com >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/danielbeatty%40mac.com >>>>>>>> >>>>>>>> This email sent to danielbea...@mac.com >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Do not post admin requests to the list. They will be ignored. >>>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>>> Help/Unsubscribe/Update your Subscription: >>>>>>> https://lists.apple.com/mailman/options/webobjects-dev/ginokris%40me.com >>>>>>> >>>>>>> This email sent to ginok...@me.com >>>>>> >>>>>> _______________________________________________ >>>>>> Do not post admin requests to the list. They will be ignored. >>>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>>> Help/Unsubscribe/Update your Subscription: >>>>>> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.com >>>>>> >>>>>> This email sent to rgur...@smarthealth.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> Do not post admin requests to the list. They will be ignored. >>>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>>> Help/Unsubscribe/Update your Subscription: >>>>> https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca >>>>> >>>>> This email sent to prob...@macti.ca >>>> >>>> >>>> _______________________________________________ >>>> Do not post admin requests to the list. They will be ignored. >>>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>>> Help/Unsubscribe/Update your Subscription: >>>> https://lists.apple.com/mailman/options/webobjects-dev/dleber_wodev%40codeferous.com >>>> >>>> This email sent to dleber_wo...@codeferous.com >>>> >>> >>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/webobjects-dev/programmingosx%40mac.com >>> >>> This email sent to programming...@mac.com >> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com >> >> This email sent to webobje...@avendasora.com >> >> > > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > https://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com > > This email sent to webobje...@avendasora.com > > _______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
