Dan Allen wrote:
After spending some time reviewing and working with the two new ShrinkWrap APIs, it got me thinking: if descriptors is a separate repository, then why isn't resolvers? In fact, I sort of see the ShrinkWrap project having three distinct APIs at this point:
If we split out the repositories in this way, I think it would make things a lot clearer.
Yes, Resolvers are almost indenpendent on the rest of ShrinkWrap (apart from Archive<?> cast).
I'd also like to change Arquillian such that only ShrinkWrap archives is pulled in as a transitive dependency. It's possible to use Arquillian without using descriptors and resolvers, and it keeps dependencies to a minimum. I don't see it as that inconvenient to add the latter two artifacts as they are needed.
I'm not sure if that's possible(that easy now). MavenDependencyResolver is used in Arquillian internals, such as ContainerRegistry and few container modules as well.
I think we're confusing the nature of dependencies and separate repositories.
Separate modules within a source tree may still define their own dependencies. Resolvers, then, to me is a very natural ShrinkWrap extension; they depend upon Archives (unless we break that stuff out).
Descriptors, on the other hand, have no natural relation to Archives. They live under the ShrinkWrap heading as part of project branding only, and the scope of that project is simply to define an object API for metadata. So they very naturally would be in another repo, and the bridge between ShrinkWrap and Descriptors is provided by the extension-descriptors module of ShrinkWrap (which defines DescriptorAsset).
Separate repositories come with dependency management overhead, and in my view should be used whenever we want to explicitly decouple a release cycle. In this vein, the ShrinkWrap Container Adaptors are destined to move OUTSIDE the ShrinkWrap tree. In this fashion they may depend upon a locked ShrinkWrap API, and then get new releases whenever we want to update Jetty, GlassFish, VFS3, etc. Each ShrinkWrap Container Adaptor will get its own repo to support the release cyce of the backing container (unless the container in question adopts this code into their own codebase).
So I forsee the following repos:
1) ShrinkWrap API, SPI, Impl Base, and Extensions
2) ShrinkWrap Container Repositories
...only if the Dependency Resolution stuff is made entirely ShrinkWrap-independent do I think it makes sense in its own repo.