Re: Upcoming Classpath Changes

From: Mike Schrag (mschra..dimension.com)
Date: Sat Jan 19 2008 - 12:19:04 EST

  • Next message: Gavin Eadie: "Re: Upcoming Classpath Changes"

    > Worse... we found that when another developer checks out the project
    > from svn and imports into Eclipse that WOLips *silently* removes
    > from the classpath any references to frameworks not installed on
    > that particular system. That's really bad.
    Yeah this happened to me just recently. This explicitly works
    properly now. You will get a classpath binding error now, but it will
    be preserved.

    >> Solutions #1, #2, and #3 - Project vs Framework, Classpath
    >> Ordering, and Live Change Detection
    >> Welcome to our first convention over config -- Framework
    >> precedence. Project, External Build Root, User Frameworks, Local
    >> Frameworks, System Frameworks. This is the order frameworks resolve
    >> when referenced by name. Period.
    >
    > Should we include /Network as the last stop?
    Does Network come before System, maybe?

    >> JavaWOExtensions comes from Library if you use Wonder. It always
    >> overrides JavaWOExtensions from System. If you don't want that,
    >> rename your conflicting framework.
    >
    > How do you deal with differing versions installed on different
    > machines? i.e., how to validate that the version installed has the
    > assumed fixes?
    >
    > Perhaps if we could have a preference saved with the project that
    > could optionally define a custom domain/dir where frameworks could
    > optionally be resolved. So that would mean something like:
    > Project, External Build Root, *Custom Frameworks as defined by
    > Project*, *Custom Frameworks as defined by Workspace*, User
    > Frameworks, Local Frameworks, System Frameworks.
    This is not a bad idea ... By default it uses the roots from
    wolips.properties, but maybe you can define a woproject/
    wolips.properties that can define overrides. This will take a little
    juggling to make sure everyone down the chain has the project context
    necessary to pull that off. It does present some kind of weird issues
    for cascading dependencies, but I guess the first one would win (i.e.
    if app defines /My/Lib/Fram and some dependency defines /Lib/Fram and
    both have the same framework in them). This MIGHT get a little bit
    funky when it tries to build the launch classpath ..... I'll have to
    think on it some.

    >> And now the big overhauls inside Eclipse ... Frameworks resolve
    >> dynamically. If your application depends on ERExtensions and you
    >> have the ERExtensions project checked out, we resolve against the
    >> project. If you close the project, we switch and resolve against /
    >> Library/Frameworks/ERExtensions.framework.
    >
    > I'm hoping you meant 'we switch to resolve against whichever is
    > found first... ~/Library/Frameworks/ERExtensions.framework, /Library/
    > Frameworks/ERExtensions.framework... etc. Same goes for
    > JavaWOExtensions (even if using WOnder).
    This is fully generic and fully driven by that precedent stack ...
    There's nothing Wonder-specific, that was just the obvious example
    that comes up all the time for people using Wonder.
    Project=>User=>Local=>System, which might now be Project=>Project
    Frameworks=>User=>Local=>System.

    >> If you don't have the project checked out and you check it out of
    >> Wonder's CVS, all of your projects will switch on-the-fly touse the
    >> checked out version. No more juggling because some team members use
    >> the installed version and some use the project ones.
    >
    > Sure. Any suggestions on being able to enforce a minimum or exact
    > version of a framework?
    I'm not addressing versioning at the moment ... This might require
    coordination between Pierre and us. Obviously OS X does the /Versions
    folder inside the framework, which is an option for us as well, but it
    would require runtime changes to support nicely. If we do Versions in
    separate folders, we could pull this off without runtime support, but
    I would want to discuss this with Apple in case they're thinking about
    the version issue as well, so we don't deviate. I think I will not
    address this for now, but I think something like the change above to
    support a per-project framework folder might alleviate this also.

    >> Because WOLips is now managing framework projects, you may need to
    >> modify your build paths to remove duplicate project references the
    >> old style (though the classpath converter should automatically do
    >> this when you open a project using the new build).
    >
    > Nice.
    >
    > Something to think about... it's fairly standard practice nowadays
    > to embed all frameworks, including wo-system ones, in a deployed app
    > so as to avoid having to simultaneously update applications that
    > depend on one or more frameworks of the same name when those
    > framework versions change.
    >
    > On a development machine, however, where its common to regularly
    > jump between, or have the projects for these disparate applications
    > open simultaneously within Eclipse.... how might this be achieved
    > with minimal pain? e.g., one project could depend on WO5.4 and
    > WOnder for WO5.4, and another for WO5.3 etc.
    >
    > This is the problem with the assumption, I suppose, that the
    > frameworks are, often, assumed to be in /Library.
    >
    > It'd be really nice to be able to have two such projects open at the
    > same time without a constant need of closing one down, running some
    > script to update the OS installation, etc.
    >
    > So that raises a question about the above suggestion of
    > automatically using the Project if it's open, say for ERExtensions
    > vs the installed one. Should there be an easy way to switch that on/
    > off for a project (like a switch/flag) so you don't have to
    > continually close/open something in order to test different
    > conditions?
    I think project frameworks would address this for built frameworks. I
    don't have any answer for this for source projects -- it becomes very
    tricky very fast. I think the answer I would suggest right now is
    that you should maintain multiple workspaces that contain the closed
    graph of dependencies.

    ms



    This archive was generated by hypermail 2.0.0 : Sat Jan 19 2008 - 12:20:12 EST