Bundle / Package Question
Locked
 
|
Hi,
While loading a bundle I am getting the error "My subclass should have
overridden one of my messages"
How would I get rid of this error? If I move this Application around in the
bundle I get additional errors that say other applications cannot be loaded
since
my "Parent" application is not loaded.
Thanks!!
Michael Gross Solution
Center Office: 800-253-3449 / 585-464-8035
(x207) |
|
|
You should include the stack dump. In the debugger select Stack->Copy
Stack Report. I reported a problem which might be related if you use Store on PostgreSQL. The title was: "VW 7.3.1 PostgreSQLServerBroker class>>alreadyExistErrors missing (minor bug)" Runar Jordahl |
Re: Bundle / Package Question
|
|
In reply to this post by Michael Gross-4
On Apr 12, 2007, at 13:05, Michael Gross wrote:
Michael, I avoid this problem by not using Bundles. Seriously. I use prerequisites on packages. And I use the public package "NewPrerequisiteEngine" to compute prerequisites between them and it rarely leads me astray. Then I get packages which can all be loaded and have the proper dependencies to avoid this kind of thing. You usually end up with a lightweight package that "prereqs" all of the different pieces in. -- Travis Griggs Objologist "Every institution finally perishes by an excess of its own first principle." - Lord Acton |
Re: Bundle / Package Question
|
|
In reply to this post by Michael Gross-4
Try using the "Validate" button in the Edit
Bundle Specification dialog. This will examine the package load order for
inconsistances.
|
RE: Bundle / Package Question
|
|
Diane
<sarcastic>
So the response to the fact that the publish
dialog will let you save a bundle in an inconsitant state from which
recovery may take take a lot of time and effort is to blame the user. Silly
user, you didn't remember to open the Bundle Editor and validate the bundle
before publishing.
</sarcastic>
This approach is just bad. Imagine if Word asked you to
open another dialog and press "validate document" before saving on pain of
loosing your work! Even worse it is gratuitously bad. If the publish dialog
would only validated the bundle before publishing the issue could be avoided
(and yes I know that avoiding bundles and using pre-requisites will also avoid
the issue). We've modifled PublishPundleDialog to do just this. And
before anyone asks, yes Publish does take longer... about a second long.
Here is the implementation (looking at this I don't even
know if it should let you proceed).
One new method:
PublishPundleDialog ->
validateLoadOrder
| errs |
errs := Store.BundleModel validateLoadOrder: (items list collect: [:each| each pundle]). ^errs isEmpty ifTrue: [true] ifFalse: [Dialog confirm: 'Bundle load order is invalid. Publish anyway?']. And one modified method:
PublishPundleDialog ->
accept
"publish...." self validateParcelOptions ifFalse: [ ^self ]. self validateFileOptions ifFalse: [ ^self ]. self validateLoadOrder ifFalse: [^self]. self newGlobalState.
[ self publishFromUserData ] on: Store.DbRegistry errorSignals do: [ :exp | exp return ]. retry ifTrue: [ ^self ].
callBackBlock == nil
ifFalse: [ callBackBlock value: items list ]. ^self closeAndUnschedule
|
RE: Bundle / Package Question
|
|
Amen! This comes up time and time again, yet the official response is
"well, you didn't validate, silly". Considering how easy it is to prevent invalid bundles from publishing it sounds like endless effort is being thrown at resisting a change whereas the effort required to implement it is virtually zero (and Joerg included a snippet for it too, that is if anyone cares to pay attention). Sigh ;) -Boris -- +1.604.689.0322 DeepCove Labs Ltd. 4th floor 595 Howe Street Vancouver, Canada V6C 2T5 http://tinyurl.com/r7uw4 [hidden email] CONFIDENTIALITY NOTICE This email is intended only for the persons named in the message header. Unless otherwise indicated, it contains information that is private and confidential. If you have received it in error, please notify the sender and delete the entire message including any attachments. Thank you. > -----Original Message----- > From: Joerg Beekmann [mailto:[hidden email]] > Sent: Thursday, April 12, 2007 3:11 PM > To: Diane Savereide; Michael Gross; [hidden email] > Subject: RE: Bundle / Package Question > > Diane > > <sarcastic> > So the response to the fact that the publish dialog will let you save > bundle in an inconsitant state from which recovery may take take a lot of > time and effort is to blame the user. Silly user, you didn't remember to > open the Bundle Editor and validate the bundle before publishing. > </sarcastic> > > This approach is just bad. Imagine if Word asked you to open another > dialog and press "validate document" before saving on pain of loosing your > work! Even worse it is gratuitously bad. If the publish dialog would only > validated the bundle before publishing the issue could be avoided (and yes > I know that avoiding bundles and using pre-requisites will also avoid the > issue). We've modifled PublishPundleDialog to do just this. And before > anyone asks, yes Publish does take longer... about a second long. > > > Here is the implementation (looking at this I don't even know if it should > let you proceed). > > One new method: > PublishPundleDialog -> > validateLoadOrder > | errs | > errs := Store.BundleModel validateLoadOrder: (items list collect: [:each| > each pundle]). > ^errs isEmpty > ifTrue: [true] > ifFalse: [Dialog confirm: 'Bundle load order is invalid. Publish > anyway?']. > > And one modified method: > PublishPundleDialog -> > accept > "publish...." > self validateParcelOptions > ifFalse: [ ^self ]. > self validateFileOptions > ifFalse: [ ^self ]. > self validateLoadOrder > ifFalse: [^self]. > > self newGlobalState. > [ self publishFromUserData ] > on: Store.DbRegistry errorSignals > do: [ :exp | exp return ]. > > retry ifTrue: [ ^self ]. > > callBackBlock == nil > ifFalse: [ callBackBlock value: items list ]. > ^self closeAndUnschedule > > > > > > > > ________________________________ > > From: Diane Savereide [mailto:[hidden email]] > Sent: April 12, 2007 2:31 PM > To: Michael Gross; [hidden email] > Subject: Re: Bundle / Package Question > > > Try using the "Validate" button in the Edit Bundle Specification > dialog. This will examine the package load order for inconsistances. > > > > Hi, > While loading a bundle I am getting the > "My subclass should have overridden one of my messages" > How would I get rid of this error? If I move this > Application around in the bundle I get additional errors that say other > applications cannot be loaded since my "Parent" application is not > loaded. > > > Thanks!! > > Michael Gross > > Solution Center > Blue Heron Consulting > 90 Airpark Dr, Suite 200 > Rochester, NY 14624 > > www.BlueHeron-Consulting.com <http://www.blueheron- > consulting.com/> > > Office: 800-253-3449 / 585-464-8035 (x207) > Fax: 800-464-9901 / 585-464-9760 > > |
|
|
In reply to this post by Travis Griggs-3
Travis wrote:
> I avoid this problem by not using Bundles. Seriously. I use prerequisites on > packages. Bundles' main function is to "line up" a set of *versioned* packaged (and other sub- bundles). Being able to do this is required if you want to keep track of which versions of your components went into a software release. For any project that need to know about its past, a functionality like bundles is needed. If a customer calls in with a bug in "release 2", you better know how to load that release into VisualWorks! For such a project, having prerequisites that do not point to versions of the packages is useless, as you only know the lineup of the latest build. Using prerequisites it is possible to replicate the bundle's lineup-function by making each prerequisite point to a specific version of the package. I have seen this described, but it was mainly done to be able to have Store overrides within a project. A bundle does not allow overrides within it. This technique is also used as bundles do not allow open editions (like Envy). Read more about these issues here: http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&entry=3265388740 To me, using packages as described above is mostly a hack to work around the limits of bundles. Letting bundles support overrides should be implemented and a concept similar to Envy's "open editions" should be added. Then bundles could work perfect for their intent. Cincom should look at these issues. If packages are used for lineups, it seems like a common practice is to have a single loading package that loads all other packages. The loading package is left empty and contains no classes. This shows that a fixed up bundle can fulfill these requirements better. The original intent of the bundle is after all to refer a set of versioned packages. Having some "special" packages that need to be without code is only confusing. Packages should contain code and not take another, unrelated function. Prerequisites should of course be defined on the individual packages of the project. The version field can be left empty (meaning any version is probably OK) or it could specify a set or a range of accepted versions. The latter is not support in Store, but should be added by Cincom too. However, this information cannot be used to make a line-up. Here is what I wrote about this earlier: http://www.cincomsmalltalk.com/userblogs/runarj/blogView?showComments=true&entry=3327662342 Runar |
|
|
Runar Jordahl wrote:
> Bundles' main function is to "line up" a set of *versioned* packaged > (and other sub- bundles). [...] Yes! For source code management of fairly large systems, this is required. > Letting bundles support overrides should > be implemented This would be nice, and make bundles less awkward. > and a concept similar to Envy's "open editions" should > be added. I'm actually somewhat against adding "open editions" to Store. Open editions, by definition, lose information about the intermediate states published into them. So you can't do things like get the differences between the open edition as it is now versus how it was a few hours ago, or load the exact code that a test failure occurred on, because the information is just not there. I've come to view open editions as Envy's way of getting around its limited hierarchy. Since Store bundles can contain other bundles, you can create a deeper hierarchy in Store. So, for instance, what we do here is have a "Development" bundle that encompasses all of our product code. Anytime a team member publishes any code change, a new version of the Development bundle is published that contains it. This makes a record of that publish, no matter how many or few packages are involved. The Development bundle has integer versions (except for branches). When we release code outside the development group, we publish a version of the "Releases" bundle. This contains nothing but the "Development" bundle. It is versioned with the release numbers that our customers see. If I need to know, which is rare, it's very easy for me to look in Store and see that Releases '7.1.1' consists of Development '818'. This makes a pretty nice system. The main thing wrong with it is having to do Store merges, which are much worse than they should be. Merges are painfully slow and dirty packages they have no reason to dirty. Merges are somewhat improved in the forthcoming VW7.5, but still don't really handle bundle merges properly. I'd like to see Cincom put some effort in this direction. Regards, -Martin |
|
|
I, too, miss the open edition concept for config maps (bundles). I'm getting
along without it, but some of my customers will be hard pressed to make the change. We have all been working with Envy for over 10 years. We tend to rely on things and not give them much thought until they aren't there anymore. Like class versions, for instance. My customers keep asking me the same question: "I need to change something in a package. What version of the package do I make my change to?" Without open editions and with a cadre of some 30-odd programmers in just one company, the answer gets more difficult to get right. So, now we lean on blessing levels, version strings and timestamps. But somehow it just doesn't feel as solid as Envy's open editions. Regards, Charlie ----- Original Message ----- From: "Martin McClure" <[hidden email]> To: "Runar Jordahl" <[hidden email]> Cc: "Travis Griggs" <[hidden email]>; "VW NC" <[hidden email]> Sent: Monday, April 16, 2007 2:55 PM Subject: Re: Bundle / Package Question > Runar Jordahl wrote: > > >> Bundles' main function is to "line up" a set of *versioned* packaged >> (and other sub- bundles). [...] > > Yes! For source code management of fairly large systems, this is required. > >> Letting bundles support overrides should >> be implemented > > This would be nice, and make bundles less awkward. > >> and a concept similar to Envy's "open editions" should >> be added. > > I'm actually somewhat against adding "open editions" to Store. Open > editions, by definition, lose information about the intermediate states > published into them. So you can't do things like get the differences > between the open edition as it is now versus how it was a few hours ago, > or load the exact code that a test failure occurred on, because the > information is just not there. > > I've come to view open editions as Envy's way of getting around its > limited hierarchy. Since Store bundles can contain other bundles, you can > create a deeper hierarchy in Store. So, for instance, what we do here is > have a "Development" bundle that encompasses all of our product code. > Anytime a team member publishes any code change, a new version of the > Development bundle is published that contains it. This makes a record of > that publish, no matter how many or few packages are involved. The > Development bundle has integer versions (except for branches). > > When we release code outside the development group, we publish a version > of the "Releases" bundle. This contains nothing but the "Development" > bundle. It is versioned with the release numbers that our customers see. > If I need to know, which is rare, it's very easy for me to look in Store > and see that Releases '7.1.1' consists of Development '818'. > > This makes a pretty nice system. The main thing wrong with it is having to > do Store merges, which are much worse than they should be. Merges are > painfully slow and dirty packages they have no reason to dirty. Merges are > somewhat improved in the forthcoming VW7.5, but still don't really handle > bundle merges properly. I'd like to see Cincom put some effort in this > direction. > > Regards, > > -Martin > > |
Re: Bundle / Package Question
|
|
On 17/04/07, Charles Adams <[hidden email]> wrote:
I, too, miss the open edition concept for config maps (bundles). I'm getting I'm hearing a lot of 'open editions' conversation going on. First of all, I disagree with Martin wrt to Open Editions. I disagree for two reasons: a) They're quite useful b) VisualWorks has them Yes, that's right. I'm blowing the whistle here. Store and VisualWorks has the concept of an open edition - it's your image. You load code, you make whatever changes you want to it. You can even share it around. So, if you're still missing open editions after realising that your image is your open edition, then I'm curious why :) Cheers, Michael |
|
|
Are you serious? Share images? Please tell me you don't mean
it.
Because its not the way we have worked for the last 10 years.
We do not typically share images. We typically load from the database the lineup
we want. Open editions has always told us unequivocally what the lineup
was.
To a very real degree, I take some ownership in my image. If I
need a component from someone else, I load it; I don't get someone else's
image.
Look, I'm not trying to start a fight. And I know I'm not
going to get Cincom to change one iota of Store. But seriously, a nod to the
development process enjoyed by thousands for the last 10 or 15 years would at
least be something.
|
Re: Bundle / Package Question
|
|
On 17/04/07, Charles Adams <[hidden email]> wrote:
I didn't mean it in the way you interpreted it, that's for sure :) By share images I mean we make our team image and every one copies it around. When you're doing work, it's "open" for you to do whatever you want. Any structural changes you make exist in your image until you're ready to publish them.
Exactly. Your image is your open edition.
Oh I agree. The whole 'sync to the head' approach employed by SVN, CVS, SourceSafe.. goodness the list goes on.. it's a very good way of doing development and I wish Store did it better. Time will tell :) Cheers, Michael
|
Re: Bundle / Package Question
|
|
In reply to this post by Charles Adams
On Apr 16, 2007, at 15:15, Charles Adams wrote:
Having an open editions model would be a Good Thing (tm). I find I get by without it, but would like/prefer to have it. I know you can devise schemes to approximate them using only packages. It works, but it's not the same thing if you prefer the "open config map" thing. Bundles really aren't any better at approximating this than the use-only-package approximations. They're just a different approximation, possibly a little more available at first blush. The thing that it seems we'd all like is something along these lines: A) no "ordering" of the subelements (sort alphabetical or by prereq when displaying, but it's just a display thing) B) versionable in place (if desired). What I mean be this is the ability to republish it with changed contents. Some might never use this. Some might use this in the same we used to "release a package to a config map". C) Get rid of the things that make it look like a package (pre/post load/unload actions). Don't publish them as parcels. I say "all" tongue in cheek. There are some/many that would resist this, because the bundle is the main element, and packages are just categories. In that style, the fact that your code has to be categorized, and your cateogories have to be ordered, both in such a way to make the bundle loadable, is seen as a nuisance, but doesn't seem to be a complete deterrent to charging ahead in this fashion. -- Travis Griggs Objologist "Dying men never wish they'd spent more time at the office" |
Re: Bundle / Package Question
|
|
And to this particular point I raise my opinion once more that we should have more human categorisation available to us with Store. We can categorise our methods with 'protocols' - we should be able to do the same with classes and again with packages. If we could do that, then many of us (myself included) could stop using bundles as a way of grouping packages together and having circular dependencies between packages because they're broken up purely for human categorisation. And since i'm on the human kick here.. why not allow us to categorise by more than one category.. tagging I believe this is called. Tagging is extremely useful for quick navigation and narrowing/filtering. Cheers, Michael |
«
Return to VisualWorks
|
1 view|%1 views
| Free forum by Nabble | Edit this page |