ShrinkWrap Resolver Metadata API

dev
#1

Continuing the discussion from Reading Maven POM metadata with ShrinkWrap Resolver:

Similar https://issues.jboss.org/browse/SHRINKRES-218

The wish to support more then just resolving Artifact(jar, war, etc) via the ShrinkWrap Resolver API’s keep popping up… With the current API’s it’s only semi possible and fairly hackish.

Internally today we have the ParsedPomFile which wraps the Maven Model.

  • The ParsedPomFile is a API interface
  • Not available in an exposed interface in the chain only via casting
  • Only expose parts of the Maven Model
  • No direct access to the Maven Model

In my mind, it sounds like to resolve the artifact or the metadata will reuse 99% of the configuration etc so I don’t think we need a new top level like Maven.metadata() or similar. And I think we want to be able to resolve multiple or single and off different type of objects as we do when resolving Artifacts.

One possible option would be to add a metadata chain to the same level as resolve so we get something like:

File f = Maven.resolver()
             .resolve("org.wildfly:wildfly-dist:zip:8.2.0.Final")
             .withoutTransitivity()
             .asSingleFile();

ParsedPomFile f = Maven.resolver()
             .resolveMetadata("org.wildfly:wildfly-dist:zip:8.2.0.Final")
             .withoutTransitivity()
             .asParsedPomFile();

Model f = Maven.resolver()
             .resolveMetadata("org.wildfly:wildfly-dist:zip:8.2.0.Final")
             .withoutTransitivity()
             .asSingle(Model.class);

Model f = Maven.resolver()
             .resolveMetadata("org.wildfly:wildfly-dist:pom:8.2.0.Final")
             .withoutTransitivity()
             .asSingle(Model.class);

List<Model> f = Maven.resolver()
             .resolveMetadata("org.wildfly:wildfly-dist:zip:8.2.0.Final")
             .as(Model.class);
  • I think using PackagingType zip|jar|war or pom in the resolveMetadata method should all work the same, just rewrite to pom

Any better API solutions?

#2

I believe that withoutTransitivity() in the call actually does not make much sense. Metadata will always be resolved with the transitivity - as Maven needs them to build the effective pom users are interested in.

ResolutionStrategy hence affects only resolution of artifacts.

One thing I don’t see in API is resolvingMetadata of a localfile

Maven.resolver().resolveMetadata(new File("pom.xml"))

does not seems following the rest of API. Other approach could be to make these calls independent of Maven.resolver() entry point such as MavenImporter. That is creating a shim on to of current casting calls.

#3

Seems we have two strategies here; Effective POM and ‘Simple’ Metadata POM.

Resolve POM vs Read XML i guess…

#4

I’m not going Read XML way by any means ;-). That’s too much of replication. If user really want to just parse xml file, he should do that on its own.

Effective model is essential - it contains resolved property placeholders, content from parents etc.

#5

Effective POM will only resolve the parent chain, right? Not child/modules?

#6

Note that it appears that the Model from Aether does not have all useful info, such as “description”.

#7 
org.apache.maven.model.Model.getDescription()

?

#8

OK, my mistake. Why didn’t I find it the other day? No idea.

#9

Yes, no childs/modules are resolved.

1 Like