Re: Upcoming Classpath Changes

From: Mike Schrag (mschra..dimension.com)
Date: Sat Jan 19 2008 - 16:33:06 EST

  • Next message: Peter Pritchard: "Re: Upcoming Classpath Changes"

    This has already be added in, so it doesn't matter ... each project
    can define a project framework folder -- if it's a relative path, it
    is relative to the project (i.e. inside) if it's an absolute path, it
    will be on the filesystem. This is named "Project Local Frameworks",
    and loads AFTER projects, but BEFORE User and Local.

    ms

    On Jan 19, 2008, at 4:17 PM, Peter Pritchard wrote:

    > I didn't mean to sound judgemental ... just pushing my own agenda ...
    >
    > I'm game for whatever changes come my way ...
    >
    > I'm just impressed so much with wolips/woproject/wonder, as is ...
    > so maybe I'm just being greedy ...
    >
    >
    > - pj
    >
    > Sent from my iPhone
    >
    > On Jan 19, 2008, at 3:24 PM, Anjo Krank <kran..ogicunited.com> wrote:
    >
    >> Dude, it's not like I just work all by myself.
    >>
    >> We have several project with several versions of Wonder and our
    >> core frameworks. All this sounds more like you need some reasonable
    >> release mngt... I see no real reason to have QA run an app in dev
    >> mode under Eclipse?
    >>
    >> Also, you could more or less do this by having different workspaces
    >> for the various sets of frameworks you use and *never* actually
    >> install anything on the dev-machines but just use checked-out
    >> copies from your version control. Then you won't have a conflict in
    >> dev-mode and for deployment your should use embedded builds in the
    >> first place.
    >>
    >> And numerous solutions the 5.3/5.4 version problem have been posted
    >> before. I use the setting in wobuild.properties (which actually
    >> should be a workspace setting).
    >>
    >> Cheers, Anjo
    >>
    >> Am 19.01.2008 um 20:04 schrieb Peter Pritchard:
    >>
    >>> Good point, which is why you would ONLY resort to putting
    >>> frameworks in there if you entire team, say, relies on version 4.0
    >>> of the Ajax framework ... but each team member has a different
    >>> version in their /Library/Frameworks/ folder ... and there is a
    >>> different version on the testing server ... and a different
    >>> version on the production server ...
    >>>
    >>> Or ... if you were developing a framework AND an application at
    >>> the same time ... then you might want to have version 1.5.0 of the
    >>> framework (while 1.6 is being worked on) ... when work on the
    >>> framework is complete, it could be installed to /Library/
    >>> Frameworks on everybody's machine and everone lives happily ever
    >>> after ...
    >>>
    >>>
    >>> In a full QA/embedded dev team, often time we need to 'know'
    >>> exactly which version of what is being run ... otherwise there is
    >>> no point discovering bugs ... if you can't explain how to
    >>> replicate it ... and that includes WebServerResources ... maybe
    >>> version 1.5 includes prototype.js version 1.5.1 ... and version
    >>> 1.6 includes prototype v. 1.6.0 ... API differences make a big
    >>> difference, even in JS files ... and some of us (all of us?) have
    >>> version 1.5.0 rc1, 1.5.0 final, 1.5.0, scriptaculous 1.7.0 rc1,
    >>> etc ...
    >>>
    >>>
    >>> If you are a lone programmer (with no QA) or work in a small-ish
    >>> team ... most of this doesn't matter ... but even with a team of
    >>> two ... I like using the nightly build (because I think it's more
    >>> stable), but my other half likes to find a version that works and
    >>> stick with it ... even if new functionality is exposed with the
    >>> new version (because he thinks it's more stable) ... we all have
    >>> our reasons ...
    >>>
    >>> - PJ
    >>>
    >>>
    >>> btw >>> this method would allow me to use my svn:externals trick
    >>> without enforcing it on anyone else, allow for capturing a
    >>> specific version of a framework to be used for an application for
    >>> those interested in that, and when (if) Apple ever decides to
    >>> introduce some versioning system (which they won't) ... it won't
    >>> conflict ... no tricky NSBundle stuff, just a place to look for
    >>> WOFrameworks before User/Local/System
    >>>
    >>> btw 2 >>> You could use this trick to bring along WO 5.3 system/
    >>> local frameworks, etc, on a system where all the frameworks in the
    >>> regular spots are WO 5.4 based ... etc ...
    >>>
    >>>
    >>>
    >>> On Jan 19, 2008, at 1:19 PM, Anjo Krank wrote:
    >>>
    >>>> So you want like 40 copies of your frameworks in your projects?
    >>>> Brr... this will be a total nightmare to keep in sync.
    >>>>
    >>>> Cheers, Anjo
    >>>>
    >>>> Am 19.01.2008 um 19:14 schrieb Peter Pritchard:
    >>>>
    >>>>> Probably misinterpreting well intentioned sarcasm ...
    >>>>>
    >>>>> But to be clear ...
    >>>>>
    >>>>> MyGreatProject/
    >>>>> Sources/
    >>>>> Components/
    >>>>> WebServerResources/
    >>>>> Resources/
    >>>>> Libraries/
    >>>>> Frameworks/ *** this 1st in search order ***
    >>>>>
    >>>>> - pj
    >>>>>
    >>>>>
    >>>>> Sent from my iPhone
    >>>>>
    >>>>> On Jan 19, 2008, at 1:03 PM, Anjo Krank <kran..ogicunited.com>
    >>>>> wrote:
    >>>>>
    >>>>>> How would that work? None of the projects I use are in my
    >>>>>> workspace. They are scattered all over the disk. Relative to
    >>>>>> what?
    >>>>>>
    >>>>>> Cheers, Anjo
    >>>>>>
    >>>>>> Am 19.01.2008 um 18:57 schrieb Peter Pritchard:
    >>>>>>
    >>>>>>> All I really want is a project-relative Frameworks folder ...
    >>>>>>> everything else is a bonus ...
    >>>>>>
    >>>>
    >>>
    >>> - Peter Pritchard
    >>> pjpritc..ac.com
    >>>
    >>>
    >>>
    >>



    This archive was generated by hypermail 2.0.0 : Sat Jan 19 2008 - 16:34:06 EST