[
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:
Your suggestion to use a .buckminster directory sounds good. I think we
will use <wsroot>/.buckminster/externalComponents. Some more answers
inline.
Either I'm missing something completely or this reasoning is not sound to my
ears...?
There is nothing prohibiting a user creating a project called
'.buckminster', thus creating confusion. I'd prefer regarding the root of
the ws as a strictly Eclipse managed entity - i.e. we shouldn't be doing
*anything* there unless it's through regular Eclipse mechanisms.
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.
By similar reasoning, the directory we speak of here is something
buckminster managed & opaque to users, right (perhaps this is where I'm
missing it - should this dir be generally available for 'user perusal &
mucking with'?)?
See below.
And, since Eclipse already has a way to give plugins their
own managed space inside the workspace (i.e. the
.metadata/.plugins/org.eclipse.buckminster.core/... part), why shouldn't it
go in there?
Because it's certanly *not* metadata.
If the ext components dir should, in fact, be generally available to the
user, I think it would be somewhat better to keep it outside of the
workspace altogether if at all possible.
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.
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.
But if possible I think it'd be
better to store such a 'cache' elsewhere. Defaults to
${user.home}/.buckminster/<something> but configurable of course. The trick
then would I guess be to correctly share some components between workspaces
but make sure others are private to certain workspaces (hooking them up
isn't that hard, but there could later be a garbage collection problem...).
?
True, but such a cache would need to be pretty advanced. Not only must
it be able to maintain different versions of the same component, it must
also maintain different incarnations of such a version (pre-compiled,
etc.). Question is if that cache would reside on your local machine, on
a server in your LAN, or both (as a federated cache). In any case, I
think that's beyond what we do for M1 and probably for M2 as well. The
simple mechanism (workspace scoped cache) works out of the box today.
- thomas
