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]
