Re: WO Frameworks Location & Multiple Versions
Re: WO Frameworks Location & Multiple Versions
- Subject: Re: WO Frameworks Location & Multiple Versions
- From: David Avendasora <email@hidden>
- Date: Thu, 18 Jun 2009 18:01:43 -0400
On Jun 18, 2009, at 5:19 PM, Chuck Hill wrote:
On Jun 18, 2009, at 12:47 PM, David Avendasora wrote:
Hi All,
I've been throwing something around in my head
Well, lots of room for that!
You know, one of these days...
since pre-WOWODC and now especially with the changes in store for
WO. I think it is going to become the norm for developers to have
more than one install of WO and any associated versions of WOnder
and other frameworks and the current method of handling multiple
versions is okay, but I think we can improve it.
Here's my ideas:
1) Right now you can't change the location where WO will install
itself,
I am not sure if we can assume that WO will continue to be supplied
as an installable package. So that may become a moot point.
Well, then even more importantly we should have a plan for how to move
forward into the new era!
and it will always overwrite the previous version installed there.
Obviously with a new version coming out soon this is going to
become much more of an issue for users with more than one project.
Upgrade! :-)
What version are most of your customers currently have deployed,
Chuck? I thought so.
What I'd like to do is to embrace and extend the woswitch.sh
install concept
I think that with New Hotness that Mike no longer uses this. He
uses multiple work spaces.
Yes, but that script would download and install WO 5.3 in a directory
named WebObjects53, that's what I meant. Pascal pointed me to
WOInstaller.jar which I did not know about, so never-mind on this
point since this seems to be a good starting point.
by having the installer default to asking for the location, and
have the suggested location be something along the lines of:
/Developer/WebObjects/Versions/WebObjectsXXXX
This would allow for concepts like:
/Developer/WebObjects/Versions/WebObjects (the default)
/Developer/WebObjects/Versions/WebObjects53
/Developer/WebObjects/Versions/WebObjectsNightly
/Developer/WebObjects/Versions/WebObjectsCustomerName
/Developer/WebObjects/Versions/WebObjectsProjectName
etc.
Obviously this is a change someone at Apple will have to make to a
future WO installer - this probably isn't even realistic, but a guy
can dream, can't he? Otherwise, users would need to manually move
installed frameworks into this directory structure.
If there is no WO installer then there is nothing to change. If it
comes from something like a Maven repository, then this is easily
achieved:
mvn mumbo:jumbo gobbledy:gook -Dmaven.install.path=/Developer/
WebObjects/Versions/WebObjectsProjectNam
See, easy! :-P
Well, if someone just extends WOInstall.jar to handle newer versions,
then davida$ sudo java -jar WOInstaller.jar 5.4.3 WebObjects55 will
work well enough.
2) Users would install any third-party frameworks (Wonder, etc)
into these directories also.
3) The default wolips.properties file would then point to the
default location above, which if didn't exist could be setup as a
symlink to "/" to keep existing installs working.
4) The Eclipse -> Preferences -> WOLips -> Build -> WOLips
Properties File value should be defaulted to show
"wolips.properties" instead of blank. Also adding validation to
verify that the file actually exists would be helpful too.
5) Have the build.properties file contain the
wolips.properties=wolips.properties property by default and have it
managed by the Eclipse -> Preferences -> WOLips -> Build -> WOLips
Properties File value. This will allow users who use WOLips Ant
Tools -> Install to deploy their application to automatically use a
customized wolips.properties file (keep incremental and Ant as
similar as possible)
I think that covers the WOLips setup, and I have some ideas on how
we could leverage this same setup to make setting up Hudson even
more simple that what Mike made it with his setupWorkspace.sh script.
1) Adjust the recommended default default Hudson setup like so:
/Developer/Hudson/Dependencies/WebObjects/Versions/
/Developer/Hudson/Dependencies/woproject.jar
/Developer/Hudson/Home/
2) If the user were to use SVN to manage their WebObjects/Versions
directories, then Hudson could automatically keep them in sync just
as it does for their project files and if you changed any of the
frameworks it would automatcially trigger a new Hudson build. In
this situation the WO versions would be in (for example):
/Developer/Hudson/Home/jobs/JobName/workspace/WebObjects53
We could then either modify Mike's setupWorkspace.sh script, or
simply eliminate it in favor of the following Ant settings:
-propertyfile /Developer/Hudson/Dependencies/
wolips.woversion.properties -lib /Developer/Hudson/Dependencies/
woproject.jar clean build
I'm not sure how all of this would change for people doing WO
development on Windows or Linux though...
What is everyone's honest opinion on these ideas? All of this can
be accomplished manually, it's how I now have my development and
hudson environments setup, but I think with a few tweaks to WOLips
and the WO installer it would be so much easier.
I am thinking of doing a screencast on the manual setup, so if you
see any major holes, please let me know.
It all seems reasonable and not far from what some are doing now. I
suspect what we will end up with is more of a Convention rather than
an enforced configuration.
Well, I was meaning something along the lines of the Fluffy Bunny
project layout. If you follow the "standard" and you have problems,
people will probably care. If you do it differently and have problems,
you may be on your own.
Not a hard and fast rule, but it is in your best interest.
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