On 1/6/2015 8:01 AM, Mic Bowman wrote:
Updating the Dispatcher and RemoteControl modules to match this
uncovered a couple issues... First, do we have naming conventions for
files? Collisions are quite possible (e.g. "README" and "LICENSES").
At this point, the example dumps all package files into the bin
directory.
That is a problem, but not as bad as you may think. Let me explain when
it's a problem and when it is not.
- Not a problem: when addins are installed from binary packages, each
addin is placed in its own subfolder under RegistryLocation/addins. So
files like READMEs, LICENSES, etc are all safe from collisions. I'm
assuming the addin developers don't move those files anywhere else; if
they do, it's their responsibility to know what the heck they're doing.
- Problem: configuration files (.inis) are placed in ConfigDirectory,
and this may, indeed, result in collisions. My only suggestion is to
name the ini very closely to the name of the addin.
- Problem-that-isn't: collisions may occur in addin names themselves,
but that is something that I don't think will happen in practice. All
3rd party package systems (yum, apt-get, npm, ...) suffer from the same
potential problem, and communities seem to find ways to avoid name
collisions, because they don't benefit anyone.
- Problem: when you, as addin developer, develop several addins under
the same source tree, and you send all these files indiscriminately to
bin for packaging, you may end up with collisions. This can be easily
solved in prebuild.xml: copy the files to their own subfolders instead
of copying them to bin. The example in the instructions copies the files
to bin, but that doesn't need to be the case; you can copy them
anywhere. The only important thing for mautil to be able to pack
everything correctly is that the files need to be in the paths given in
the addin directives you write in the assembly package. So you can do
this for each addin:
(a) send the dlls to bin, if you want, because the changes of name
collision are null
(b) send all non-dlls to a subfolder of bin, say addin1-files
(c) in the addin directives write something like this:
[assembly: ImportAddinFile("addin1-files/LICENSE.txt")]
If you do this, the final package will have a similar folder structure,
i.e. people will see
RegistryLocation/addin/YourAddin/
dlls
RegistryLocation/addin/YourAddin/addin1-files/
LICENSE.txt
Its easy enough to put things into package directories... just might
be good to ensure thats part of the conventions.
Yes. I don't think we need to make a convention on that. The main
problem (the last one on my list above) is internal to addin developers.
Second, is there a way to identify previously installed dependencies?
E.g. I have a third party module for parsing JSON that might be
installed by other modules.
In my tests, mono addins does the right thing with dependencies! For
example, Diva.Wifi (which is now an addin) depends on another addin
Diva.Interfaces (this one defines an extension point for Wifi -- I have
extra packages that aren't in the free distribution of Wifi). When you
install Diva.Wifi, it correctly installs Diva.Interfaces automatically.
The interface is very similar to yum or apt-get, it lets you know about
the dependencies, and asks you if you want to proceed.
_______________________________________________
Opensim-dev mailing list
[email protected]
http://opensimulator.org/cgi-bin/mailman/listinfo/opensim-dev
