[kepler-dev] Getting rid of CreateModulesBundle

[David Welker]

Hi Chad,

For now, I would like to keep kepler-tasks.jar relatively high in the 
hierarchy, so that less of Kepler depends on it until it becomes more 
stable. Of course, I agree that as soon as we move it lower, we should 
definitely delete it in higher priority modules to avoid redundancy. You 
can imagine how it would become harder to refactor as more of Kepler 
came to depend on it.

I don't want to make the build-area module a formal module for now, nor 
do I want a process by which kepler-tasks.jar is automatically moved to 
the lib of a module. I like not having to worry about breaking anything 
in Kepler with changes to the build-area module. (As it is, such changes 
sometimes cause problems associated with building without also causing 
bugs in Kepler itself.)

So, anyway, if we need a modules list lower in Kepler now. Fine, lets 
move kepler-tasks.jar to a lower priority area. But, if it can be 
delayed a little bit, lets do that.

David
> I'd like to get away from including kepler-tasks.jar in several 
> different locations.  Maybe build-area should just become a normal 
> module so other modules can use kepler-tasks.jar since it has become 
> critical to the execution of kepler.  Or the build could put 
> kepler-tasks.jar into common/lib/jar so that all modules could use it 
> there.  I'm trying to clean up the jar mess right now, so it'd be good 
> if we worked to remove our own redundancies.
>
> chad
>
> Daniel Crawl wrote:
>>
>> Hi Chad and David,
>>
>> Thanks, ModuleTree looks promising.
>>
>> I would like to access it in org.kepler.loader.Kepler, which
>> is in the util module, but kepler-tasks.jar is in the loader
>> module.
>>
>> We could move kepler-tasks.jar to util or lower.
>>
>> Alternatively, org.kepler.loader.Kepler could be moved to
>> the loader module. (This would additionally permit merging it
>> with org.kepler.core.loader.Loader resulting in one less
>> startup class). However, I did something similar earlier this
>> year, but had to revert since it broke 1.0 compatibility.
>> Is the loader module still used for 1.0?
>>
>> What do you suggest?
>>
>> Thanks,
>>
>>  --dan
>>
>>
>> David Welker wrote:
>>> Actually, ModuleTree is a singleton. The moduleTree instance in 
>>> ModulesTask is just a convenience.
>>>
>>> So, the code you would need to use is:
>>>
>>> ModuleTree.init();
>>>
>>> for( Module m : ModuleTree.instance() )
>>>   // Your work
>>>
>>> or
>>>
>>> for( Module m : ModulesTree.instance().reverse() )
>>>  // Your work. But iterate in reverse order of priority.
>>>
>>> -David
>>>> If you extend ModulesTask, you can use the local variable 
>>>> modulesTree and increment through that.  If you need to access that 
>>>> in kepler, we might need to make a singleton instance or something 
>>>> that you can get at.
>>>>
>>>> chad
>>>>
>>>>
>>>> Daniel Crawl wrote:
>>>>>
>>>>> Hi David,
>>>>>
>>>>> I'm happy to remove it, if you can please suggest an
>>>>> alternative: how can I get a list of modules used
>>>>> (inside a running Kepler)?
>>>>>
>>>>> Thanks,
>>>>>
>>>>>  --dan
>>>>>
>>>>>
>>>>> David Welker wrote:
>>>>>> Hi Daniel,
>>>>>>
>>>>>> I was wondering whether, since CreateModulesBundle is not really 
>>>>>> necessary, whether or not you could remove it in the near future?
>>>>>>
>>>>>> Thanks!
>>>>>> David
>>>>>
>>>>> _______________________________________________
>>>>> Kepler-dev mailing list
>>>>> Kepler-dev at kepler-project.org
>>>>> http://mercury.nceas.ucsb.edu/kepler/mailman/listinfo/kepler-dev
>>>>>
>>>>
>>
>