[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [buckminster-dev] Naming of components that are not projects
|
ken1 wrote:
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.
Honestly, do you really think we are going to create conflicts by
introducing a '.buckminster' directory in the workspace root? I
certainly don't, and that is all that this part of the discussion boils
down to. But even if we would talk naming conventions in general (which
we don't as far as I'm concerned), I still would not consider the
convention to use dot prefixed name for "hidden" things wrong. It is a
*very* common practice and following common practices is often the right
thing to do.
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.
And how is Eclipse viewpoint different from ours?
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?
'meta-data' is data that somehow describes or controls 'data'. It's
often sane to keep the two separate. External jar files, just as project
contents, represent 'data'. I admit that the boundaries can be fuzzy
sometimes but for this discussion my definition holds true.
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???).
That depends on the context in which that database was used. If it
contains meta-data for a plugin, it should be under .metadata. If not,
then perhaps some other location is more appropriate. The name
'.database' seems a bit presumptuous though.
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.
I'm not arguing that we *can* put it there but (and I quote what you
wrote) "It's not implied that it's a good thing to actually do that,
though".
And the location does become visible. If you for instance click on the
ClasspathContainer, it will list each jar file that it references with
a full path. I'd rather avoid extremely long names containing
'.metadata/.plugins/org.eclipse.buckminster.core' if I can help it.
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.,
Using that line of reasoning, the CVS plugin should materialize the
stuff that it manages under .metadata. It doesn't. It does however store
a lot of info that describes the data and the CVS repositories in
different ways.
No, I think it's time for me to perform a volte-face. The more I think
about a the idea of using a special-purpose project, the better it gets.
We could prevent that a user fiddles with it from the IDE (well not
completely perhaps, but we could issue warnings etc.), we could even
allow some fiddling and ensure that Buckminster keeps needed listeners
updated. We can attach properties such as the Buckminster component ID
to the resources. Future enhancements could introduce markers to denote
that newer versions exists for download etc.
So how about a special-purpose '.buckminster' Eclipse project?
- thomas
