Service provider module resolution <was> Re: Services/configuration/context webrevs
Paul Sandoz
paul.sandoz at oracle.com
Mon Aug 27 09:19:57 PDT 2012
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.
More information about the jigsaw-dev
mailing list