Re: Classpath problem

From: Mike Schrag (mschra..dimension.com)
Date: Mon Sep 19 2005 - 10:46:55 EDT

  • Next message: Mike Schrag: "Re: xcode/xcode builder"

    No apologies necessary -- Nightly builds are generally considered
    unstable builds. All of us have caused various breaking problems at
    one point or another :) For everyone downloading those builds: as a
    rule, we obviously don't want to break things for people, but just be
    aware that you're downloading alpha or beta quality code for the most
    part. I suspect when 3.1.1 final comes out, we might want to shoot
    for an official 2.0 release, but in the meantime, you should be
    prepared to roll back. Incidentally, if you're updating with
    eclipse's updater, it doesn't delete old versions -- it just adds to
    the plugins and features folders. So to roll back should just be
    deleting the latest versions of the plugins and features for
    org.objectstyle.* (and possibly doing an eclipse -clean startup -- i
    never know when it does this automagically and when it doesn't).

    Re: the bug I saw w/ classpath ... I reall don't know any of the
    classpath mgmt code (ui or otherwise), but I believe the code you
    worked on is used by the front-end somehow (fairly certain of it,
    actually, because when I backed out those changes, the problem I saw
    with double-selection went away). I'm not sure how that interaction
    works, though -- Ulrich's your man for that.

    The versions of those files with your patches integrated in are:

    http://cvs.sourceforge.net/viewcvs.py/woproject/woproject/projects/
    wolips/plugins/org.objectstyle.wolips.launching/java/org/objectstyle/
    wolips/launching/classpath/WORuntimeClasspathProvider.java?
    rev=1.4&view=markup

    and

    http://cvs.sourceforge.net/viewcvs.py/woproject/woproject/projects/
    wolips/plugins/org.objectstyle.wolips.launching/java/org/objectstyle/
    wolips/launching/delegates/
    WOJavaLocalApplicationLaunchConfigurationDelegate.java?
    rev=1.5&view=markup

    Thanks Garry!
    ms

    On Sep 19, 2005, at 10:24 AM, Watkins, Garry wrote:

    > First of all I want to apologize to those that had problems. However,
    > that is what can happen when you live on the bleeding edge ;) I
    > know it
    > has happened to me many times.
    >
    > Would you send me what you patched into the build? I will try to get
    > the environment set up again, so I can test it. This might take me a
    > while to get to.
    >
    > I guess that I never tested the external jar thing. What I
    > normally do
    > is build a wrapper framework around things like jdbc drivers. Kind of
    > like the ERJars.framework. That way I make sure that the deployment
    > environment is running the same stuff as my development environment.
    >
    > Are you referring to when you edit the WOClasspath container where you
    > select which frameworks to use? If so my code has nothing to do with
    > the front end code. It only uses the information to generate the
    > runtime classpath when you launch an application. If you look at the
    > WOClasspath container in a .classpath file it looks something like
    > this:
    >
    > <classpathentry kind="con"
    > path="org.objectstyle.wolips.WO_CLASSPATH/CMPBusinessLogic/
    > ERDirectToWeb
    > /ERExtensions/ERJars/ERNeutralLook/JavaWOExtensions/MRExtensions/
    > MRJars/
    > OpenOffice/SQLServer/WOOgnl/XSLFO/JavaDirectToWeb/JavaDTWGeneration/
    > Java
    > EOAccess/JavaEOControl/JavaEOProject/JavaFoundation/JavaJDBCAdaptor/
    > Java
    > WebObjects/JavaXML"/>
    >
    > As you can see there is nothing about whether it is in a
    > Library/Frameworks or System/Library/Frameworks.
    >
    > My code uses the following priorities of adding frameworks to the
    > runtime classpath
    > 1) If there is an eclipse framework project that is connected
    > to the application project it uses it first
    > 2) If the framework exists in /Local/Library/Frameworks it will
    > use it second
    > 3) If the framework exists in /System/Library/Frameworks it
    > will use it last
    >
    > For example my project called CMP uses the classpath above.
    > CMP
    > -> CMPBusinessLogic (Project and Local Lib) which
    > references MRExtensions **
    > -> MRExtensions (Project and Local Lib)
    > -> Rest are Local and System
    >
    > Therefore it will generate a classpath like this
    > CMP (Project)
    > CMPBusinessLogic (Project)
    > MRExtensions (Project)
    > Everything else from Local Lib or System Lib
    >
    > ** This is what the bug is in the current version of the runtime
    > classpath genration code. It will include the MRExtensions framework
    > twice in the classpath. Once from the project and once from the Local
    > Lib. And it puts the local lib version first.
    >
    >
    > One of the shortcomings of the WOClasspath container is that it
    > does not
    > allow any sense of ordering of the frameworks within the container.
    > E.g. I cannot guarantee CMPBusinessLogic come before MRExtensions.
    >
    > A better design of the gui for the class path container manager should
    > be something like this
    >
    > Left Side - Should have the tree like the current thing has
    >
    > Middle should have an Add button. When an item on the left is
    > selected
    > and the add button is clicked, it should move to the right side. Then
    > it should disable or remove the selected item on the left side.
    >
    > Right Side - should have a list of all of the frameworks selected.
    > Should have up and down buttons to order the frameworks within the
    > classpath.
    >
    > I hope this helps. If there is anyone that can work on the GUI
    > component of the WOClasspath container it would be appreciated.
    > Maybe I
    > will add a bug report to Jira.
    >
    > Thanks
    > Garry
    >
    > -----Original Message-----
    > From: Mike Schrag [mailto:mschra..dimension.com]
    > Sent: Monday, September 19, 2005 8:55 AM
    > To: woproject-de..bjectstyle.org
    > Subject: Re: Classpath problem
    >
    > OK I went ahead and rolled back ... Incidentally, I saw an anomaly
    > with
    > classpath management as well where it appears that an old bug came bug
    > -- the one where if you have the same named framework in /
    > Library/Frameworks and /System/Library/Frameworks, both will be
    > checked.
    > So Garry -- if you could take another look at that patch and maybe
    > redo
    > it based off of the current HEAD version rather than the original
    > version you patched from, that would be probably make for a smoother
    > transition.
    >
    > On Sep 19, 2005, at 8:32 AM, Mike Schrag wrote:
    >
    >
    >> So this didn't happen before the new classpath code? Garry -- any
    >> ideas? I'm thinking we should roll back to the old version until
    >> Garry gets a chance to look into this.
    >>
    >> On Sep 19, 2005, at 5:46 AM, Guido Neitzer wrote:
    >>
    >>
    >>
    >>> On 19.09.2005, at 10:43 Uhr, Guido Neitzer wrote:
    >>>
    >>>
    >>>
    >>>
    >>>> This doesn't fix anything here - it's just a different kind of
    >>>> thing. Again: I'm not talking about frameworks. There I had the
    >>>> same
    >>>>
    >
    >
    >>>> thing you have described a few days ago. But this is not my current
    >>>> problem.
    >>>>
    >>>>
    >>>>
    >>>
    >>> So, just for the record ...
    >>>
    >>> I'm up and running again. Have recovered a WOLips v2.0.0.47 from my
    >>> backup and installed this. So, my classpath issues are resolved and
    >>> also Eclipse is working as expected.
    >>>
    >>> Lost 4 hours, but that's life.
    >>>
    >>> cug
    >>>
    >>>
    >>>
    >>
    >>
    >>
    >
    >
    >
    >
    >
    >
    > Confidential & Privileged
    >
    > Unless otherwise indicated or obvious from its nature, the
    > information contained in this communication is attorney-client
    > privileged and confidential information/work product. This
    > communication is intended for the use of the individual or entity
    > named above. If the reader of this communication is not the
    > intended recipient, you are hereby notified that any dissemination,
    > distribution or copying of this communication is strictly
    > prohibited. If you have received this communication in error or
    > are not sure whether it is privileged, please immediately notify us
    > by return e-mail and destroy any copies--electronic, paper or
    > otherwise--which you may have of this communication.
    >
    >
    >
    >



    This archive was generated by hypermail 2.0.0 : Mon Sep 19 2005 - 10:47:02 EDT