[jsr294-modularity-eg] Simple Module System Proposal

[Sam Pullara]

My position hasn't changed.  The primary issue that I think we should  
be solving is source code level versioned module membership and  
dependency declarations with identical compile and runtime resolution  
of those modules so that we can get rid of the classpath.  Others  
think that there is some need to further constrain the visibility and  
accessibility between modules -- I'm not that interested in that use  
case though if it is -simple- I'm not against having it in the  
specification.

Sam

On Sep 29, 2009, at 10:49 AM, Peter Kriens wrote:

> I think we're having a bit of a dead lock. Is there an anyway we can  
> have a call to discuss these issues? I also like to know where Bob  
> and Sam think.
>
> Kind regards,
>
> 	Peter Kriens
>
> On 29 sep 2009, at 18:55, Alex Buckley wrote:
>
>> Richard S. Hall wrote:
>>> On 9/24/09 20:16, Alex Buckley wrote:
>>>> If Maven suffices for versioning and dependency tracking - not  
>>>> "real" modularity but still of some value, in your view - why  
>>>> does the Simple Module System claim the same ground by  
>>>> standardizing versions and dependencies in the language?
>>> To me, this line of discussion completely misses the important  
>>> point. If 294 modules are required to be loaded by a single class  
>>> loader, then they are useless in any environments that are either  
>>> dynamic or support side-by-side versions, which throws their reuse  
>>> out the window. Thus, there is very little benefit of the SMS  
>>> proposal over the "big hook" approach.
>>
>> "big hook" approach?
>>
>> Alex
>> _______________________________________________
>> jsr294-modularity-eg mailing list
>> jsr294-modularity-eg at cs.oswego.edu
>> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg
>
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg