[jsr294-modularity-eg] Expressing module dependencies

[Peter Kriens]

On 14 apr 2009, at 01:28, Alex Buckley wrote:

> Peter Kriens wrote:
>> Hmm, I think the following does not look too bad for me as a  
>> replacement or the OSGi manifest:
>> @Bundle(
>>        require_bundle      = "com.acme.foo; version='[2.1,3)',"
>>                            + "com.acme.foo2,"
>>                            + "com.aQute.bndlib; version='2.1'",
>>        bundle_symbolicname = "biz.aQute.bnd",
>>        bundle_name         = "Bnd Annotations",
>>        bundle_description  = "Provides annotations to OSGi bundles",
>>        bundle_docurl       = "http://www.aQute.biz",
>>        bundle_copyright    = "Copyright aQute SARL (c) 2002-2009"
>> )
>> @Jigsaw(
>>  ...
>> )
>> module aQute.bnd.annotation;
>
> What is @Bundle?
An annotation ... :-) What else?

> What is @Jigsaw? You're missing some import statements, unless  
> you're proposing that these annotation types are handled specially  
> in the JLS and javac's name interpretation logic. At that point,  
> they're basically keywords.
Nope, they are standard annotations, I tested it.

>> Java had to change the meaning of volatile several times before  
>> they got it right, I am pretty confident a require will a similar  
>> fate because a lot of things are happening in this area, both in  
>> research and with practioners.
> Please identify these things so JSR 294 can be better informed.
I think I already did in a previous mail.
>> Anyway, I also expect that any module will need more directives  
>> than just require. Will we encode those in language constructs as  
>> well?
> The tentative 294 spec published in early February had a 'permits'  
> keyword too. If modules A and B are nodes in a directed graph, then  
> 'requires' is an edge from A to B, while 'permits' is an edge from B  
> to A. There is no mystery about the need for "reverse" dependencies  
> as expressed by 'permits' - it's an encoding of the "provider  
> determines compatibility" idea we discussed at the EclipseCon BOF.
But you do not think you need information like a readable  
(localizable) name, a description, copyright info, etc? Where will you  
store those?


Kind regards,

	Peter Kriens

> Also there is the entrypoint of a module (the 'class' keyword  
> suffices for that) and the aliases of a module ('provides').
>
> Alex
> _______________________________________________
> jsr294-modularity-eg mailing list
> jsr294-modularity-eg at cs.oswego.edu
> http://cs.oswego.edu/mailman/listinfo/jsr294-modularity-eg