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"
<[email protected]>:
> On Thu, 18 Aug 2016 21:27:38 +0200, Paul Benedict
> <[email protected]> wrote:
>
> > On Thu, Aug 18, 2016 at 11:53 AM, Robert Scholte
> > <[email protected]> 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: [email protected]
> For additional commands, e-mail: [email protected]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
