Service provider module resolution <was> Re: Services/configuration/context webrevs

[Paul Sandoz]

On Aug 25, 2012, at 12:23 AM, mark.reinhold at oracle.com wrote:

> 2012/8/1 7:46 -0700, paul.sandoz at oracle.com:
>> http://cr.openjdk.java.net/~psandoz/jigsaw/resolver-services/webrev.4/
> 
> Overall this looks very good, and the resulting behavior will definitely
> be more intuitive.
> 

Thanks. I will send another webrev tomorrow.


> Resolver.java
> 
>  [84-94] Please follow the local convention of using "//" to introduce
>  comments on implementation internals.  This makes it easy to
>  distinguish them from actual doc comments.
> 
>  [88] s/synthesizedServiceDependencies/synthesizedServiceDependences/
>  Dependencies and dependences are different things.  You're talking
>  about the latter here.
> 
>  [432-444] //
> 
>  [445-473] dependencies -> dependences
> 
>  [455,460] s/: / : /
> 
>  [514-556] This code is crying out to be placed in its own method, say
>  `resolveServices`.
> 

OK. 


> As to the tests, I'm not comfortable with splitting what's logically a
> single test, which happens to involve a bunch of small files, into a
> bunch of actual small files.  That just makes the test harder to read and
> harder to maintain.

Some intents:

- make it easier to edit the tests in an IDE. I actually have the service runtime loaded as a project in NetBeans. From that perspective I find it much easier to read and maintain.

- add other runtime-based tests to this project e.g. i wanted to add one that iterated when there was an exception on construction of a service provider class, but this does require more service interface/provider modules which really should be derived from a template, like those other ones.

- i marked the this out as one to update to using TestNG, for example i could define one test that uses a data provider supplying the 5 class loader values.


>  I agree that the current shell hackery has issues,
> particularly around portability, but we can address that in other ways.
> Please use existing mechanisms and conventions for now, until we have
> something better.
> 

OK, i will sully myself with the shell hackery :-)


> (One idea (just discussed with Jon and Mandy here in the hallway) is to
> write a test library that understands a simple "snippet" file format.
> When run it would extract each snippet into a separate source file,
> possibly doing some template expansion along the way, and then perform
> the requested actions on them.  This is, however, for another day.)
> 

Thoughts:

- perhaps we could use annotation processors to generate modules/code.

- there are some compiler tricks performed by the lambda TestNG suite, dunno if they are relevant.

- it would be nice if the code that performed the tests/assertions could be edited in an IDE. For example, we may be able to declare from a unified source base how it is split into modules e.g. the test module, a service interface module, and generated service provider modules from templates.

Paul.