[vwnc] Bundles

On his Blog, Jim asked about Store Bundles:

    *  Do you use bundles?
    * If so, how do you use them, and why?
    * If setting explicit pre-reqs was easier, would you still use bundles?

I do use bundles.

I use nested bundles with an outer master bundle for every project.

Even if setting preq versions were easier I probably still use
bundles.  I like the explicit containment.

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

We use bundles purely as means of organizing a tree of packages by
meaning, not by isolated functionality blocks or anything fancy like
that. For example, basic tree of categories would do just fine and we'd
probably just have 2-3 packages in total then: main codebase, web stuff,
development+tests each specifying their external prerequisites such as
Seaside, RuntimePackager, SUnitToo etc.

-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: [hidden email] [mailto:[hidden email]] On
Behalf
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hi,
Yes, I use bundles, also nested one. They just give me different granularity when defining close relationship for classes and class extensions.
(and also probably because on  VSE I had cluster on Team/V for long time, so probably the concept of two level of packaging was already digested).
I suppose I will use it in any case.





_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I use bundles to keep my work both together and near the top in the  
browser. I would prefer a better namespace-hierarchy view in the  
browser, and possibly an organisation within packages ala the multiple  
source folders in Eclipse projects. In which case I probably wouldn't  
use bundles, but would instead use Namespaces to organize the  
functional breakdown of my projects.

As I said on my blog: IMO Bundles are a confusing amalgam of  
references-as-pseudo-containment, hierarchical organisational device,  
and packaging convenience. I use them primarily because it keeps my  
packages grouped at the top of the RB browser.

I vote you get rid of them and provide a better code-organizing/
grouping/delimiting tools. Also I would vote for a facility in the RB  
to bring a certain group of packages to the top of the list ala  
Eclipse's working sets.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

The fact that an opinion has been widely held is no evidence whatever  
that it is not utterly absurd.
   -- Bertrand Russell


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

We use bundles to separate packages along image lines. Our product is
distributed among multiple images so it is helpful to bundle that which is
common and that which is specific to image goals.

Yes, we will use bundles regardless of prereq behavior.

Bundles can be likened to config maps from Envy and config maps were
indispensable then just as bundles are now.

ControlWORKS is a large application, but our customers go well beyond the
framework in creating their own applications. Bundles help to organize an
enormous library.

However, bundles are an image management construct. It is not helpful as the
primary view on the RB. When I work on code it is at the package level. For
this reason, I would like an RB that lists the packages in "my defined
order" and leaves the bundle management to another tool or view.

Regards,
Charles Adams
Adventa Control Technologies, Inc.
http://www.adventact.com


----- Original Message -----
From: "Bruce Badger" <[hidden email]>
To: "VW NC" <[hidden email]>
Sent: Monday, May 12, 2008 5:41 PM
Subject: [vwnc] Bundles


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Hello,

I use bundles.

I use them to cluster packages that go together, e.g. Hash Analysis Tool
bundle.  I also use them to cluster things inside bundles, e.g.: the
hash functions bundle inside the Hash Analysis Tool bundle.

Even if managing prerequisites was easy (note: not "easier" but "easy"),
bundles would probably make sense from the POV of Envy's configuration
maps.  In other words, prerequisites describe necessary conditions (if
this is not present, then that won't work), but not necessarily
sufficient ones (if this is not present, then the software works but it
does not meet the requirements of the user because module such is
missing).

Andres.

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On
Behalf Of Bruce Badger
Sent: Monday, May 12, 2008 3:42 PM
To: VW NC
Subject: [vwnc] Bundles

On his Blog, Jim asked about Store Bundles:

    *  Do you use bundles?
    * If so, how do you use them, and why?
    * If setting explicit pre-reqs was easier, would you still use
bundles?

I do use bundles.

I use nested bundles with an outer master bundle for every project.

Even if setting preq versions were easier I probably still use bundles.
I like the explicit containment.

--
Make the most of your skills - with OpenSkills
http://www.openskills.org/
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

We use bundles -- exactly two of them
    - framework and tools
    - applications (business apps)
It makes it simple to pair one version of apps with a different
version of framework.
Also, different people looking after each.



Bruce Badger wrote:
--
Dennis Smith                         +1 416.798.7948
Cherniak Software Development Corporation   Fax: +1 416.798.0948
509-2001 Sheppard Avenue East        [hidden email]
Toronto, ON M2J 4Z8              sip:[hidden email]
Canada         http://www.CherniakSoftware.com
Entrance off Yorkland Blvd south of Sheppard Ave east of the DVP

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

I use bundles, but I'm not sure you could say I *use* bundles. More
like, I abuse them. I often have a top level bundle which acts as a
configuration map - then there may be bundles underneath that to act as
a grouping mechanism for my packages.

For the top level, versioning that information is essential. However,
actually having in my image gets in the way often.. it has properties on
it that I have to manually maintain, such as prerequisites.. and if I
want to parcel it out, all heck breaks loose. If I need to change it
because it's unloadable, I have to fallback to some pretty crude tools.
Once I've got my top level bundle loaded, it serves to group things
together at the top of the RB, but beyond that it's dead-weight, another
tree click I have to perform.

For the second level, versioning and merging that information is a
burden. It's also not multifaceted, which is what I really want.. for
example, I have packages which I'd classify as: seaside, component,
contributed, to do that right now, I group said packages together in to
a bundle called SeasideImportedComponents. This is pretty suboptimal
when I want to reorganize things.

Michael

Bruce Badger wrote:
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

We don't use bundles at all.  I find they just get in the way when I'm trying to develop simple little add-on tools.
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

We have been experimenting with the use of bundles in different ways. What
has turned out to work best is the approach to use an all in one bundle for
the project composed of sub bundles mostly composed of packages, seldom of
sub sub bundles.

Besides structuring, we use versioning (mainly of the super bundle, at
milestones with common version numbers for all sub compoments), and sequence
of loading.

Georg

Georg Heeg eK, Dortmund und Köthen, HR Dortmund A 12812
Tel. +49-3496-214328, Fax +49-3496-214712


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

When I re-read my statement I saw that I had forgotten to mention the team
aspect: We use top bundle versioning to communicate progress in the team.

Georg

Georg Heeg eK, Dortmund und Köthen, HR Dortmund A 12812
Tel. +49-3496-214328, Fax +49-3496-214712


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Good question. My products consist of 140+ packages, 8 top-level  
bundles, 25 subordinate bundles (more used like categories rather than  
independent modules).

I never felt safe including the same packages/bundles in more than one  
top-level bundle, and failed to make use of bundles when archiving  
"product build configurations", so the actual benefit of bundles for  
me is to have the packages easily browseable -- that's all.

Generally I hate that I am forced to publish a top-level bundle every  
time one of its components changed (because I use them like categories).

I would much prefer a good prerequisite mechanism, if a suitable tool  
would be avaiable to maintain the prerequisite tree (e.g. easily  
update all prerequisites of a package to the most current versions and  
be able to browse or visualize the tree in some form).

Andre


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 13.05.2008 um 01:25 schrieb Antony Blakey:

> I vote you get rid of them and provide a better code-organizing/
> grouping/delimiting tools. Also I would vote for a facility in the RB
> to bring a certain group of packages to the top of the list ala
> Eclipse's working sets.

+1

The bundle concept was a nice idea, but IMO it turned out to be mostly  
redundant and semantically ambiguous.

Andre
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

may I restate your answer: "if the bundle concept would be unambigious and non-redundant I would use bundles more happily"

and summarize what I read from all the answers: people have the need for
- grouping together code for delivery: configuration maps
- categorizing code in arbitrary ways: tags or multi-catgories
- a better view on the code currently worked on
- team communication
- tools to achieve and manage the above
- probably many things that I missed
-- e. g. what I can think of: team management, test management
.

Which role could bundles play within this picture? As I see it especially configuration maps and the last, not yet clearly defined point. The rest asks for a resurrectiion of the notion of categories as Tags. And for best-in-class tools.

All in all we have a very diverse user base from one person shops to world wide distributed teams. Of course each one has his own needs. Thus it is IMO rather a "let's get it right" than a "let's get rid of it" strategy.

My 2 € Cents
Helge

-----Ursprüngliche Nachricht-----
Von: [hidden email] [mailto:[hidden email]] Im Auftrag von Andre Schnoor
Gesendet: Dienstag, 13. Mai 2008 10:41
An: Antony Blakey
Cc: VW NC
Betreff: Re: [vwnc] Bundles


Am 13.05.2008 um 01:25 schrieb Antony Blakey:

> I vote you get rid of them and provide a better code-organizing/
> grouping/delimiting tools. Also I would vote for a facility in the RB
> to bring a certain group of packages to the top of the list ala
> Eclipse's working sets.

+1

The bundle concept was a nice idea, but IMO it turned out to be mostly redundant and semantically ambiguous.

Andre
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Between the lines of several message I read about the interesting effort
needed to put a bundle on disk. Typically putting everything in a single
parcel does not work and setting up a bunch of parcels with prerequisite
structure is painful.

In ObjectStudio 8.0, 8.1 and VisualWorks 7.6 you find something called
Smalltalk Archives which solves this problem: A bundle saved as Smalltalk
Archive saves it in a way that the same loading sequence and the same
sequence of asking for prerequisites and all actions of off contained
bundles and all packages are executed in the same sequence as loading from a
Store repository.

It helped us a lot.

Georg

Georg Heeg eK, Dortmund und Köthen, HR Dortmund A 12812
Tel. +49-3496-214328, Fax +49-3496-214712



_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Bruce Badger wrote:
> On his Blog, Jim asked about Store Bundles:
>
>     *  Do you use bundles?
>  
No, I documented some of the reasons several years ago on Travis' blog:
 
http://www.cincomsmalltalk.com/userblogs/travis/blogView?showComments=true&entry=3265388740


R
-

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

Am 13.05.2008 um 11:38 schrieb Nowak, Helge:

> may I restate your answer: "if the bundle concept would be  
> unambigious and non-redundant I would use bundles more happily"

Yes. I would rather see bundles in their "configuration map" role,  
i.e. associate a specific set of packages (with versions) and their  
load order for the purpose of loading products into an image and for  
deploying them.

Bundles should be safe for archiving: Loading an older product from an  
archived configuration map for maintenance should be possible even  
after years (maybe it already is and I missed something).

IMO categorizing and browsing nested units of code inside packages is  
more a matter of GUI tools. Technically, this organization does not  
necessarily need to be part of the prerequisite/loading mechanism. I  
could live fine with less and bigger (flat) packages, if they provided  
a means for hierarchically organizing their contents in the GUI.  
Bundles would still aggregate packages, but no longer in the deeply  
nested fashion like now.

Andre

_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

On 13/05/2008, at 7:08 PM, Nowak, Helge wrote:

> - grouping together code for delivery: configuration maps

I'm not familiar with Envy, but when I see the word configuration I  
assume a view of configuration management that includes a more  
sophisticated relationship algebra than simple dependencies on either  
a fixed or wildcard version of a fixed package.

In as much as a given Bundle represents one (of many possible)  
resolutions according to that algebra, then I guess a Bundle is  
useful. OTOH, I've had a bugger of a time when a package is in more  
than one Bundle, which goes against this interpretation. And in any  
case, a configuration algebra requires a lot more tools support.

> - categorizing code in arbitrary ways: tags or multi-catgories

Yes, although I would prefer to use namespaces to organise my code,  
with better tools for navigating and browsing according to namespaces,  
both globally and delimited according to package, which is how I use  
Eclipse. Even after delivering a system in VW and, I still prefer it.

> - a better view on the code currently worked on

My requirements are very simple - so simple that it could be whipped  
up in a day. What I'd like is an option for the package list to show a  
section at the top containing a) all linked dirty packages/bundles and  
b) all packages/bundles that match a list of names (with wildcards)  
that would be set as an option setting. In my case I would specify:  
ASB*, Nitro-*, Surf-*, XMLPullParser etc. The logical extension is to  
allow named sets of these patterns so that you can switch between  
them, but it's still useful without that. There's an issue of saving  
and loading them for configuring a new image, but that's easy to deal  
with.

BTW: the need to restrict it to linked dirty items is because every  
unlinked item in my browser is marked as dirty.

> Thus it is IMO rather a "let's get it right" than a "let's get rid  
> of it" strategy.

Sure. My reaction to get rid of them is because they do a number of  
things not very well. Of course you're not going to get rid of them.

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

Some defeats are instalments to victory.
   -- Jacob Riis


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

  > I never felt safe including the same
packages/bundles in more than one
> top-level bundle, and failed to make use of bundles when archiving  
> "product build configurations", so the actual benefit of bundles for  
> me is to have the packages easily browseable -- that's all.

Same here.

Cheers,
             Andrés
_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc

To be more specifice about bundles as config maps;
There are 2 way in which you would use them.
1) After a bundle, as a map, has been defined you do not want to be
required to publish it every time a subcomponent is published in
order for the subcomponent to be loaded next time you load the bundle,
i.e. an open config map.
2) But you do want to have a "closed" bundle whose contents cannot
be updated so when you load it you get just the published versions
of its subcomponents.



Terry
 
===========================================================
Terry Raymond
Crafted Smalltalk
80 Lazywood Ln.
Tiverton, RI  02878
(401) 624-4517      [hidden email]
<http://www.craftedsmalltalk.com>
===========================================================


_______________________________________________
vwnc mailing list
[hidden email]
http://lists.cs.uiuc.edu/mailman/listinfo/vwnc