On Thu, 18 Aug 2016 23:40:17 +0200, Bernd Eckenfels
<e...@zusammenkunft.net> wrote:
Hello,
the proposal looks fine (if the scope system will be that open).
Yes, that's the idea. If some plugin needs artifacts which needs different
handling, that plugin is free to introduce its own scope. The example of
the maven-javadoc-plugin is hopefully clear enough about that.
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>
...
I've been thinking about a transitive-flag, but I don't think that's
correct. In case of classified artifacts I'm wondering if those artifacts
should be transitive. Right now I think that only the main-artifact should
have transitive dependencies, attached artifacts never.
Anyhow, the annotation will need a filter-attribute. That's also in line
with the idea that plugins shouldn't be aware of Aether of other Artifact
Resolution API.
I suggest to watch the issue to see if the implementation can support all
kind of usecases, even the rare ones.
thanks,
Robert
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
