Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [aether-users] Getting Aether to understand packaging types

Graeme Rocher wrote:

So by default readPom is 'false' so the code, flawed or not, doesn't come
into play in my case.

And what about other code spots that might follow the same anti-pattern? E.g. https://github.com/grails/grails-core/blob/master/grails-aether/src/main/groovy/org/codehaus/groovy/grails/resolve/maven/aether/AetherDependencyManager.groovy#L514, does dependency.pattern actually refer to file extensions or dependency types like a Maven POM?

And if readPom is false for the troublesome case, where exactly are the dependencies for the CollecRequest constructed from? The ArtifactTypeRegistry is used by the repo system when it processes POMs, any artifact instances one passes in as request parameters are left as-is and are expected to specify the actual file extension.


         final artifactTypeRegistry = new DefaultArtifactTypeRegistry()
         artifactTypeRegistry.add(new DefaultArtifactType('grails-plugin',
'zip', '', 'none'))
         artifactTypeRegistry.add(new DefaultArtifactType('grails-app',
'war', '', 'none'))
         artifactTypeRegistry.add(new
DefaultArtifactType('grails-binary-plugin', 'war', '', 'none'))
         session.setArtifactTypeRegistry(artifactTypeRegistry)

As I mentioned before, this code sets a type registry that knows only about your grails-* types and nothing else, in particular, it doesn't support any of the usual Maven types like "ejb-client" or "test-jar".

BTW, unless you want to resolve the dependencies of those WARs/ZIPs in addition to the files themselves, you might want to employ the DefaultArtifactType constructor with includesDependencies=true.


Benjamin


Back to the top