Re: [buckminster-dev] Naming of components that are not projects

["ken1" <kenneth@xxxxxxxxx>]

> Well, since it apparently is common practice for other plugins to use a 
> .<something> as special, I would consider it pretty save to follow that 
> crowd. We can document that naming a project '.buckminster' would be an 
> extremely bad idea. Just as naming it '.metadata' would.

So in your opinion 2+n wrongs == 1 right?

How scalable is this? Every plugin in the world may decide to store 
.pick-your-name in the ws root and then document it as being a very bad idea 
to create projects with that name. Where did the structured naming concept 
go? Can everybody use the name .foo? With the specific example of 
'.metadata' that's quite ok - Eclipse manages that area and thus can control 
what goes in there and, as the case may be, to disallow certain special 
names (The funny thing here is that Eclipse actually *does* allow you to 
create a project called '.metadata'! What a hoot :-) It doesn't show up 
among the projects either, but it definitively stuffs a '.project' in the 
.metadata directory. I consider this to be a bug file a bug report...).

The point is that while other plugins may use naming like '.something' they 
probably do *not* do that in the *workspace* just willy-nilly.
If you re-read Knut's comments there is one instance of storing .ivy-cache 
in the users home (i.e. completely outside any workspace), and another 
instance of storing things in a *project* in the workspace called 
.JETEmitters (i.e. they apparently use Eclipse to create a project with that 
name, allowing Eclipse to manage that space, just as my suggestion).

The fact that it's easy to find the workspace root and do nasty things in 
there is just implicit since it's just the normal filesystem. It's not 
implied that it's a good thing to actually do them, though.

> Because it's certanly *not* metadata.

IMO you interpret the name '.metadata' in the wrong context. It is from 
Eclipse's viewpoint that there is metadata about the workspace in the 
.metadata directory. But Eclipse also allows plugins to carve a slice in 
there to store workspace & plugin specific things in an orderly and 
structured manner. From this it doesn't follow that Buckminster must store 
something that fits a specific notion of 'metadata' in that spot (and what 
notion is that? if a plugin want's to store a little temporary database in 
the workspace, does it then have to have a top level called .database???).

 In fact, a plugin is of course not even strictly aware that it is below a 
location called .metadata. It just trusts Eclipse to give it a location that 
it can manage for its own odds and ends. For that purpose, the notion of 
storing extcomponents there is quite ok.

> The sole reason why I want this in the workspace is that we use the 
> workspace as 'scope' for the materialization. If we don't, then we must 
> manage ext components globally on the machine. That implies that we also 
> must manage the meta-data that describes the materialization and binding 
> of those components globally. We then run into difficulties with 
> concurrent versions or concurrent incarnations (pre-built, source, etc) in 
> use by different workspaces.

Yes, this is pretty much what I said - storing it outside a workspace mainly 
comes up if it's really a place that should be easy to find for a user. I 
understand that you don't intend that - from your next comment I infer that 
you really consider this a place which is totally and completely Buckminster 
managed. Again, in that case it makes perfect sense to stuff it in a 
location that is intended for plugin managed things, i.e. where Eclipse 
tells you to do it.,

>
>> Theoretically, we could get the desired effect by actually creating a 
>> '.buckminster' project the regular/programmatic way and we would then of 
>> course be free to muck around inside such a project just like anyone 
>> else.
>>
> I think that would be a bad idea. 'mocking around' means you destroy stuff 
> that Buckminster manages for you. I think it would be a mistake to 
> encourage that for the same reason that the .metadata is hidden.
>

Exactly. In my comment above the 'we' in '...we would then of course...' I 
really mean Buckminster (or more accurately, the core component of course). 
Thus, exactly (as I understand it) as the JET thingy, Buckminster can create 
a '.buckminster' project and then use that for it's own purposes. But it is 
totally unnecessary since there already is a better solution that suits us 
fine.

ken1