Hello, the proposal looks fine (if the scope system will be that open). How would you differentiate between artifacts and artifact archives (i.e. those you want to explode)?
BTW: just a usecase: In our buildsystem I have POMs which produce articles which can contain dozent of files. They are in a classifier=distribution type=zip file. An aggregator project depends on them and unpacks them: <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-dependency-plugin</artifactId> <executions> <execution> <id>create-distribution</id> <phase>package</phase> <goals> <goal>unpack-dependencies</goal> </goals> <configuration> <outputDirectory>${project.build.directory}/distribution</outputDirectory> <excludeArtifactIds>junit,hamcrest-core</excludeArtifactIds> <classifier>distribution</classifier> <type>zip</type> <reResolve>false</reResolve> <resolutionFuzziness>groupId</resolutionFuzziness> <failOnMissingClassifierArtifact>true</failOnMissingClassifierArtifact> </configuration> </execution> </executions> </plugin> So I only need to add a dependency to that classifier/type. Those dependencies are in a POM. The only problem there is that I need to define a wildcard exclude for each of them or the build step will pull in all those transitive dependencies for no reason. When I import them in a dedicated scope it would be good if that can be avoided (and dependencies-plugin can still enumerate them) <dependency> <groupId>groupX</groupId> <artifactId>permission-api</artifactId> <version>${version.groupX.permission-api}</version> <exclusions> <exclusion> <groupId>*</groupId> <artifactId>*</artifactId> </exclusion> </exclusions> </dependency> ... Gruss Bernd Am Thu, 18 Aug 2016 23:06:30 +0200 schrieb "Robert Scholte" <rfscho...@apache.org>: > On Thu, 18 Aug 2016 21:27:38 +0200, Paul Benedict > <pbened...@apache.org> wrote: > > > On Thu, Aug 18, 2016 at 11:53 AM, Robert Scholte > > <rfscho...@apache.org> wrote: > > > >> IMO any artifact with the compile-scope should end up on the > >> classpath. If > >> such artifact shouldn't end up there, that artifact should have a > >> different > >> scope. > >> All current scopes are related to the classpath, which is > >> certainly too strict. > > > > > > Agreed. So far, as of today, Maven only has scopes that relate to a > > code. > > > > > >> You've just described a case where a zip-file should not end up on > >> the classpath, but it should have a scope recognizable by the > >> maven-war-plugin > >> to understand what it should do with that artifact. > >> > > > > Agreed, but only if your understanding of "do" includes do nothing. > > I wouldn't expect the maven-war-plugin to assume it knows what to > > do with my > > resource-only artifacts. Do you think it should do something? And, > > if so, is that a justifiable assumption? > > > > Based on my proposal of MPLUGIN-302 I would expect something like: > > /** > * Content of archives is places in the root of the war > */ > @Dependencies( scope="overlay" ) > private List<Artifact> staticContentArchives; > > The name of the scope could be anything. Since every plugin > requiring artifacts must specify the scopes in which it is > interested, plugin designer could choose its own scopes. It is up to > us if we can identify commons usage of artifacts besides > classpath(/modulepath) and can specify a general scope for it. > > >> I don't think the types matter. > > > > > > Sorry, I was unclear on my point. I was kind of straying onto a > > different topic but it is closely related. Let me try again.... > > > > Since MNG-5567 is introducing a new "zip" type, POMs will then be > > publishable with <packaging>zip</packaging>. Christian wisely noted > > there are really two types of resources: archived (like a zip) and > > non-archived (I'll call these "raw" for now). I'm just trying to > > stretch my thoughts here and wonder aloud if the packaging type is > > too specific --- should it really be about any resource in general? > > Every packaging type has an ArtifactHandler which holds an Archiver > and an UnArchiver (besides pom). Based on that you know what you can > do with the resource and how to handle it. > > Robert > > > > > Cheers, > > Paul > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org