Details
-
Type:
New Feature
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 2.0.9
-
Fix Version/s: 3.2
-
Component/s: Dependencies
-
Labels:None
-
Complexity:Intermediate
-
Number of attachments :
Description
Currently, a dependency's version or a dependency's version and scope can be managed in dependency management, but a dependency's scope alone cannot be managed. For example, we cannot express the following:
<dependencies>
<dependency>
<groupId>javax.mail</groupId>
<artifactId>mail</artifactId>
<scope>provided</scope>
</dependency>
</dependencies>
Of course it does work if we also specify a version, but there are times when we want to merely control the scope and not change the resolved version. When we try the above example we get:
[INFO] ------------------------------------------------------------------------
[ERROR] FATAL ERROR
[INFO] ------------------------------------------------------------------------
[INFO] An invalid artifact was detected.
This artifact might be in your project's POM, or it might have been included transitively during the resolution process.
Here is the information we do have for this artifact:
o GroupID: javax.mail
o ArtifactID: mail
o Version: <<< MISSING >>>
o Type: jar
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.artifact.InvalidArtifactRTException: For artifact {javax.mail:mail:null:jar}: The version cannot be empty.
at org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:147)
at org.apache.maven.artifact.DefaultArtifact.<init>(DefaultArtifact.java:122)
at org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:158)
at org.apache.maven.artifact.factory.DefaultArtifactFactory.createDependencyArtifact(DefaultArtifactFactory.java:58)
at org.apache.maven.project.DefaultMavenProjectBuilder.createManagedVersionMap(DefaultMavenProjectBuilder.java:452)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:912)
at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506)
at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198)
at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583)
at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461)
at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Just some thoughts... maybe completely OT
How do you know its provided until you actually try to deploy it? The container of choice may change over time or even be multiple and as such the 'provided' depdendency might not make any sense.
I prefer to build one distributable that does not change across containers cause that way you know its the same one that ends up in production. Perhaps the containers need to filter out the relevant artifacts at load time....perhaps using the implementation details in the manifest?