[kepler-dev] on your next kepler update

[Aaron Schultz]

I think it's ok to have that file in the project root, alongside all of 
the read-only module jars, the installer could initially generate the 
file, but we still need the runtime mechanism for development purposes.  
It also increases the reliability quite a bit, imagine if I had to rerun 
my installer just because I deleted that one file...

Aaron


David Welker wrote:
> If you are going to have a file that uniquely identifies an 
> installation and that file is going to be written to kepler.modules (I 
> think a better location would be in a subfolder of the build-area 
> folder where it not likely to be seen very often), then it must be 
> written by the installer and not by any other process. In general, 
> Kepler is likely to be installed in a read-only area of disk, so such 
> a file must be generated only once at installation time.
>
> David
>>
>> I thought that would work (and actually moved it there yesterday) but 
>> the problem arises that if you have two different installations of 
>> Kepler on the same machine they both end up using the 
>> .kepler/InstanceAuthNamespace file and therefore the same cache.  Now 
>> this may be what you want but may not be what you want.  Say I have a 
>> kepler base configuration installation and a Kepler WRP installation, 
>> there are cases where I may want them to use the same cache or I may 
>> not want to use the same cache.  If the InstanceAuthNamespace is in 
>> .kepler then they both MUST use the same cache.  If the 
>> InstanceAuthNamespace file is stored at the project root then they 
>> can both use different caches or they can both use the same cache (by 
>> copying the InstanceAuthNamespace file to both project root 
>> directories).
>>
>> Aaron
>>
>> Chad Berkley wrote:
>>> Could it go in the root of the .kepler directory so the system will 
>>> know where to find it?  Or maybe in some 'common' directory in 
>>> .kepler that doesn't rely on the unique id system?
>>>
>>> chad
>>>
>>>
>>> Aaron Schultz wrote:
>>>>
>>>> Hi Chad,
>>>>
>>>> The InstanceAuthNamespace file contains a java serialized string 
>>>> for the unique authority and namespace of any given kepler 
>>>> installation (which is either retrieved from a webservice or 
>>>> assigned via UUID).
>>>>
>>>> For each installation of kepler on a given machine there would be 
>>>> (actually there now is) a subdirectory in the .kepler directory 
>>>> that was named using the authority and namespace.
>>>> Each of these .kepler/instance directories would contain it's own 
>>>> cache as we discussed yesterday....
>>>>
>>>> So we need that one file to find all the other files for any given 
>>>> installation of kepler...
>>>>
>>>> Aaron
>>>>
>>>> Chad Berkley wrote:
>>>>> Hi Aaron,
>>>>>
>>>>> I've been seeing this file appear and wondering what it was.  I 
>>>>> think things like this should be written to .kepler or some other 
>>>>> user directory.  I agree with David that the kepler project 
>>>>> directory should probably not be written to in general.  Maybe 
>>>>> this type of file should be written to the cache so that it could 
>>>>> be programatically purged if and when it needs to be.
>>>>>
>>>>> thanks,
>>>>> chad
>>>>>
>>>>>
>>>>> David Welker wrote:
>>>>>> Hi Aaron,
>>>>>>
>>>>>> In general, you need to avoid writing anything to the 
>>>>>> kepler.modules project root directory. In the general case, this 
>>>>>> directory is likely to be stored in a read-only area of disk.
>>>>>>
>>>>>> David
>>>>>>>
>>>>>>> You will want to delete the InstanceAuthNamespace file in your 
>>>>>>> project root directory.
>>>>>>>
>>>>>>> Otherwise you will have troubles getting proper object ids for 
>>>>>>> LSIDs.
>>>>>>>
>>>>>>> Aaron
>>>>>>> _______________________________________________
>>>>>>> Kepler-dev mailing list
>>>>>>> Kepler-dev at kepler-project.org
>>>>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Kepler-dev mailing list
>>>>>> Kepler-dev at kepler-project.org
>>>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>>>>
>>>>
>>>>
>>
>>
>