Pakaging

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Pakaging

Ian Bartholomew-3
I've been having a quick look at the way packaging works now, relating to
loading packages containing classes already in the image.

I set up -

package X containing classes A and B
package Y containing class A

If I file in package A followed by package B I now get the warning dialog.
If I continue then I immediately get to a state where

- the PackageBrowser tells me that class A is in both package X and package
Y.
- the CHB tell me that class A is in package Y.
- the SystemBrowser tells me that there are two class As, both in package Y
- in the PackageBrowser removing the class from Package X actually removes
it from Y

A warning dialog that allows you to continue is a good idea, it obviously
allows you to continue in situations where you would previously have needed
to fiddle around a bit, but the above behaviour makes it a bit more
complicated and error prone than it might be.

I was wondering, and I haven't looked at the code so it may be too
complicated, if it might be safer moving clashing classes (and methods?)
into the _Uncomitted state?

Regards
    Ian


Reply | Threaded
Open this post in threaded view
|

Re: Packaging

Ian Bartholomew-3
> I was wondering, and I haven't looked at the code so it may be too
> complicated, if it might be safer moving clashing classes (and methods?)
> into the _Uncomitted state?

I added that bit as an afterthought and, after thought, decided it's
probably not a good idea either - too easily leading to packages being saved
without the classes they were supposed to contain.

Ian


Reply | Threaded
Open this post in threaded view
|

Re: Pakaging

Ian Bartholomew-3
In reply to this post by Ian Bartholomew-3
> A warning dialog that allows you to continue is a good idea, it obviously
> allows you to continue in situations where you would previously have
> needed to fiddle around a bit, but the above behaviour makes it a bit
> more complicated and error prone than it might be.

Whoops. If I had taken the time to read what the dialog was actually telling
me rather than just clicking the button then I would have seen that I was
supposed to remove the clashing classes/methods from their existing packages
before continuing.

Sorry all, for the waste of bandwidth.

It does raise a question though. If you choose to continue and file in the
package why can't the operation automatically remove the clashes from their
existing packages for you?.

Regards
    Ian


Reply | Threaded
Open this post in threaded view
|

Re: Pakaging

Blair McGlashan
"Ian Bartholomew" <[hidden email]> wrote in message
news:[hidden email]...
> > A warning dialog that allows you to continue is a good idea, it
obviously
> > allows you to continue in situations where you would previously have
> > needed to fiddle around a bit, but the above behaviour makes it a bit
> > more complicated and error prone than it might be.
>
> Whoops. If I had taken the time to read what the dialog was actually
telling
> me rather than just clicking the button then I would have seen that I was
> supposed to remove the clashing classes/methods from their existing
packages
> before continuing.
>
> Sorry all, for the waste of bandwidth.
>
> It does raise a question though. If you choose to continue and file in the
> package why can't the operation automatically remove the clashes from
their
> existing packages for you?.

I think that is what it was supposed to do, but the change was never fully
completed. I will record it as a defect (it seems the change to allow the
user to continue the load is not in our change tracking DB, as it ought to
be mentioned in the release notes but isn't).

Regards

Blair