You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Paul Benedict <pb...@apache.org> on 2016/08/17 17:20:22 UTC
Discussion: Resource-only artifacts
I'm in in the thought process of MNG-6080 and MNG-5567, and I have an idea
to run by the dev folks here:
A ZIP file is a type of resource. A resource artifact gets a new scope to
remain in the reactor but does not contribute to the compiling process or
runtime environment. It's up to the build to determine how to consume it
(via some other mechanism like input into a plugin). But is a ZIP artifact
really any different from any other kind of non-functional artifact? What
about text files, markdown files, or any other kind of non-code resource
you want to share and use?
One such thought of mine was people who want to deploy OSS license files.
Instead of keeping a static copy in a project for distribution bundling, it
could be part of a project dependency and added. I am pretty sure there are
Maven plugins specifically built for this -- but are these plugin to
workaround the absence of native functionality?
So the big philosophical question is...
If a ZIP file is just a resource, then perhaps it's not a new Maven "zip"
type that should be supported... it should be a new Maven "resource" type
that can be any kind of file.
Thoughts?
Cheers,
Paul
Re: Discussion: Resource-only artifacts
Posted by Paul Benedict <pb...@apache.org>.
That's the plugin I had in mind when I first wrote :-) Thanks for sharing
the link!
This is the rub of the whole discussion. What we do with ZIP files will
lend an answer to how Maven should handle resource-only artifacts.
1) How is ZIP different than any other remote resource?
2) Should there be a new POM Type + Dependency Scope for a remote resource?
3) Are plugins (like the remote-resource-plugin) in existence because of
the lack of #2?
Cheers,
Paul
On Wed, Aug 17, 2016 at 12:34 PM, jieryn <ji...@gmail.com> wrote:
> https://maven.apache.org/plugins/maven-remote-resources-plugin/
>
> You bundle up your resources and then you can unbundle them whenever
> you want. Works nice for a lot of shared resources. Licenses, static
> code analysis configurations, velocity templates, etc etc etc.
>
> On Wed, Aug 17, 2016 at 1:20 PM, Paul Benedict <pb...@apache.org>
> wrote:
> > I'm in in the thought process of MNG-6080 and MNG-5567, and I have an
> idea
> > to run by the dev folks here:
> >
> > A ZIP file is a type of resource. A resource artifact gets a new scope to
> > remain in the reactor but does not contribute to the compiling process or
> > runtime environment. It's up to the build to determine how to consume it
> > (via some other mechanism like input into a plugin). But is a ZIP
> artifact
> > really any different from any other kind of non-functional artifact? What
> > about text files, markdown files, or any other kind of non-code resource
> > you want to share and use?
> >
> > One such thought of mine was people who want to deploy OSS license files.
> > Instead of keeping a static copy in a project for distribution bundling,
> it
> > could be part of a project dependency and added. I am pretty sure there
> are
> > Maven plugins specifically built for this -- but are these plugin to
> > workaround the absence of native functionality?
> >
> > So the big philosophical question is...
> > If a ZIP file is just a resource, then perhaps it's not a new Maven "zip"
> > type that should be supported... it should be a new Maven "resource" type
> > that can be any kind of file.
> >
> > Thoughts?
> >
> > Cheers,
> > Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Discussion: Resource-only artifacts
Posted by jieryn <ji...@gmail.com>.
https://maven.apache.org/plugins/maven-remote-resources-plugin/
You bundle up your resources and then you can unbundle them whenever
you want. Works nice for a lot of shared resources. Licenses, static
code analysis configurations, velocity templates, etc etc etc.
On Wed, Aug 17, 2016 at 1:20 PM, Paul Benedict <pb...@apache.org> wrote:
> I'm in in the thought process of MNG-6080 and MNG-5567, and I have an idea
> to run by the dev folks here:
>
> A ZIP file is a type of resource. A resource artifact gets a new scope to
> remain in the reactor but does not contribute to the compiling process or
> runtime environment. It's up to the build to determine how to consume it
> (via some other mechanism like input into a plugin). But is a ZIP artifact
> really any different from any other kind of non-functional artifact? What
> about text files, markdown files, or any other kind of non-code resource
> you want to share and use?
>
> One such thought of mine was people who want to deploy OSS license files.
> Instead of keeping a static copy in a project for distribution bundling, it
> could be part of a project dependency and added. I am pretty sure there are
> Maven plugins specifically built for this -- but are these plugin to
> workaround the absence of native functionality?
>
> So the big philosophical question is...
> If a ZIP file is just a resource, then perhaps it's not a new Maven "zip"
> type that should be supported... it should be a new Maven "resource" type
> that can be any kind of file.
>
> Thoughts?
>
> Cheers,
> Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Discussion: Resource-only artifacts
Posted by Paul Benedict <pb...@apache.org>.
Bernd, okay, I find that sensible. Thanks for pointing that out.
Cheers,
Paul
On Thu, Aug 18, 2016 at 3:05 PM, Bernd Eckenfels <ec...@zusammenkunft.net>
wrote:
> Am Thu, 18 Aug 2016 14:27:38 -0500
> schrieb Paul Benedict <pb...@apache.org>:
> > 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?
>
> It could have a config option for embedding/exploding such additional
> archives, just like assembly plugin or copy-deendencies can work on
> dependencies.
>
> Gruss
> Bernd
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Discussion: Resource-only artifacts
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
Am Thu, 18 Aug 2016 14:27:38 -0500
schrieb Paul Benedict <pb...@apache.org>:
> 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?
It could have a config option for embedding/exploding such additional
archives, just like assembly plugin or copy-deendencies can work on
dependencies.
Gruss
Bernd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Discussion: Resource-only artifacts
Posted by Robert Scholte <rf...@apache.org>.
On Thu, 18 Aug 2016 23:40:17 +0200, Bernd Eckenfels
<ec...@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"
> <rf...@apache.org>:
>
>> On Thu, 18 Aug 2016 21:27:38 +0200, Paul Benedict
>> <pb...@apache.org> wrote:
>>
>> > On Thu, Aug 18, 2016 at 11:53 AM, Robert Scholte
>> > <rf...@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-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Discussion: Resource-only artifacts
Posted by Bernd Eckenfels <ec...@zusammenkunft.net>.
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"
<rf...@apache.org>:
> On Thu, 18 Aug 2016 21:27:38 +0200, Paul Benedict
> <pb...@apache.org> wrote:
>
> > On Thu, Aug 18, 2016 at 11:53 AM, Robert Scholte
> > <rf...@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-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Discussion: Resource-only artifacts
Posted by Robert Scholte <rf...@apache.org>.
On Thu, 18 Aug 2016 21:27:38 +0200, Paul Benedict <pb...@apache.org>
wrote:
> On Thu, Aug 18, 2016 at 11:53 AM, Robert Scholte <rf...@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-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Discussion: Resource-only artifacts
Posted by Paul Benedict <pb...@apache.org>.
On Thu, Aug 18, 2016 at 11:53 AM, Robert Scholte <rf...@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?
> 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?
Cheers,
Paul
Re: Discussion: Resource-only artifacts
Posted by Robert Scholte <rf...@apache.org>.
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. 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.
I don't think the types matter: if somebody decides to specify an ear-file
as dependency to a jar-project, let the compiler (not
maven-compiler-plugin!) decide if it accepts that file. It is not up to
Maven to decide if a certain file belongs on the classpath or not, maybe
in the future there are more supported files. So it is up to the developer
and Maven should have a predictable outcome, without any magic.
best,
Robert
On Thu, 18 Aug 2016 17:49:57 +0200, Paul Benedict <pb...@apache.org>
wrote:
> Christian, I am in agreement. Do you have a suggestion on how to identify
> the resource file name? Right now the <type> implies the extension. I
> have
> an idea in mind, but don't want to bias anyone before they give their
> feedback. Thoughts? And if anyone else has a solution to propose, please
> respond, too. Thank you.
>
> Cheers,
> Paul
>
> On Wed, Aug 17, 2016 at 9:34 PM, Christian Schulte <cs...@schulte.it> wrote:
>
>> Am 08/17/16 um 21:57 schrieb Paul Benedict:
>> > to me... but it does raise the bigger issue regarding Maven and
>> > resource-only artifacts. Except for the "pom" packaging type, every
>> other
>> > type relates to code, no? The current core packaging values are: pom,
>> jar,
>> > maven-plugin, ejb, war, ear, rar, par. So I think it behooves us we
>> get
>> the
>> > first non-code type handled correctly. Just my 2 cents.
>>
>> In my opinion a resource only artifact should not be about any
>> file-format. It's just a file. Can be anything
>> (ZIP,txt,doc,tar,xz,avi,mpg,jpg,etc.). You end up wanting to create an
>> archive containing lots of these resource files so you do not need to
>> list 100+ dependencies in the POM for every single file. Choice of the
>> archive is up to you. Can be ZIP - can be something else. For plugins it
>> should be just a file to copy around without any file-format specific
>> handling like unpacking. If special handling like unpacking is needed,
>> it's no longer a resource only artifact but some kind of archive
>> artifact. The remote resources plugin is pretty much what users are
>> going to use for something like this.
>>
>> Regards,
>> --
>> Christian
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Discussion: Resource-only artifacts
Posted by Paul Benedict <pb...@apache.org>.
Christian, I am in agreement. Do you have a suggestion on how to identify
the resource file name? Right now the <type> implies the extension. I have
an idea in mind, but don't want to bias anyone before they give their
feedback. Thoughts? And if anyone else has a solution to propose, please
respond, too. Thank you.
Cheers,
Paul
On Wed, Aug 17, 2016 at 9:34 PM, Christian Schulte <cs...@schulte.it> wrote:
> Am 08/17/16 um 21:57 schrieb Paul Benedict:
> > to me... but it does raise the bigger issue regarding Maven and
> > resource-only artifacts. Except for the "pom" packaging type, every other
> > type relates to code, no? The current core packaging values are: pom,
> jar,
> > maven-plugin, ejb, war, ear, rar, par. So I think it behooves us we get
> the
> > first non-code type handled correctly. Just my 2 cents.
>
> In my opinion a resource only artifact should not be about any
> file-format. It's just a file. Can be anything
> (ZIP,txt,doc,tar,xz,avi,mpg,jpg,etc.). You end up wanting to create an
> archive containing lots of these resource files so you do not need to
> list 100+ dependencies in the POM for every single file. Choice of the
> archive is up to you. Can be ZIP - can be something else. For plugins it
> should be just a file to copy around without any file-format specific
> handling like unpacking. If special handling like unpacking is needed,
> it's no longer a resource only artifact but some kind of archive
> artifact. The remote resources plugin is pretty much what users are
> going to use for something like this.
>
> Regards,
> --
> Christian
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Discussion: Resource-only artifacts
Posted by Christian Schulte <cs...@schulte.it>.
Am 08/17/16 um 21:57 schrieb Paul Benedict:
> to me... but it does raise the bigger issue regarding Maven and
> resource-only artifacts. Except for the "pom" packaging type, every other
> type relates to code, no? The current core packaging values are: pom, jar,
> maven-plugin, ejb, war, ear, rar, par. So I think it behooves us we get the
> first non-code type handled correctly. Just my 2 cents.
In my opinion a resource only artifact should not be about any
file-format. It's just a file. Can be anything
(ZIP,txt,doc,tar,xz,avi,mpg,jpg,etc.). You end up wanting to create an
archive containing lots of these resource files so you do not need to
list 100+ dependencies in the POM for every single file. Choice of the
archive is up to you. Can be ZIP - can be something else. For plugins it
should be just a file to copy around without any file-format specific
handling like unpacking. If special handling like unpacking is needed,
it's no longer a resource only artifact but some kind of archive
artifact. The remote resources plugin is pretty much what users are
going to use for something like this.
Regards,
--
Christian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Discussion: Resource-only artifacts
Posted by Paul Benedict <pb...@apache.org>.
Okay, thanks for pointing that out. Well, I am trying to see your
perspective, but I don't share the sentiment changing scope somehow demotes
the reputation of a ZIP file. By it's very nature, it is merely a
container. It's nature should be how Maven treats it as default. If a
developer wants to add code semantics to it, then changing scope is how
that should be accomplished. Scope is always how Maven has controlled how
code-related artifacts behave throughout the build phase.
Cheers,
Paul
On Wed, Aug 17, 2016 at 3:14 PM, Michael Osipov <mi...@apache.org> wrote:
> Am 2016-08-17 um 22:05 schrieb Paul Benedict:
>
>> I am in agreement a ZIP file shouldn't be a "second-class type". I do not
>> want that either. However, it seems I may have said something that makes
>> you believe I am saying otherwise? Can you please let me know what you saw
>> in my explanation? I'd just like to know and make sure we're on the same
>> page. Thanks, Michael.
>>
>
> It was actually this statement:
> (2) or explicitly set a different scope to make it part of the class path
>
> All items shall be equal by default unless told otherwise.
>
>
> On Wed, Aug 17, 2016 at 3:00 PM, Michael Osipov <mi...@apache.org>
>> wrote:
>>
>> Am 2016-08-17 um 21:57 schrieb Paul Benedict:
>>>
>>> Yes, it is valid for a ZIP to contain class files. However, I don't
>>>> believe
>>>> Maven should create a bias here for Java. The ZIP file type, in its
>>>> objective form, has nothing to do with Java. It just so happens Java
>>>> chose
>>>> to support that file type as a source of classes.
>>>>
>>>> As as a consequence, a ZIP file could be either of the two use cases in
>>>> a
>>>> project.... and MNG-6080 explains how to handle that:
>>>> (1) default handling is to treat ZIP files as a mere container
>>>>
>>>>
>>> I agree here. No assumptions shall be made since this is a generic
>>> container but it does not mean that it doesn't has be to a second-class
>>> type of artifact in the system.
>>>
>>>
>>> On Wed, Aug 17, 2016 at 2:37 PM, Michael Osipov <mi...@apache.org>
>>>
>>>> wrote:
>>>>
>>>> Am 2016-08-17 um 19:20 schrieb Paul Benedict:
>>>>
>>>>>
>>>>> I'm in in the thought process of MNG-6080 and MNG-5567, and I have an
>>>>>
>>>>>> idea
>>>>>> to run by the dev folks here:
>>>>>>
>>>>>> A ZIP file is a type of resource. A resource artifact gets a new scope
>>>>>> to
>>>>>> remain in the reactor but does not contribute to the compiling process
>>>>>> or
>>>>>> runtime environment. It's up to the build to determine how to consume
>>>>>> it
>>>>>> (via some other mechanism like input into a plugin). But is a ZIP
>>>>>> artifact
>>>>>> really any different from any other kind of non-functional artifact?
>>>>>> What
>>>>>> about text files, markdown files, or any other kind of non-code
>>>>>> resource
>>>>>> you want to share and use?
>>>>>>
>>>>>> One such thought of mine was people who want to deploy OSS license
>>>>>> files.
>>>>>> Instead of keeping a static copy in a project for distribution
>>>>>> bundling,
>>>>>> it
>>>>>> could be part of a project dependency and added. I am pretty sure
>>>>>> there
>>>>>> are
>>>>>> Maven plugins specifically built for this -- but are these plugin to
>>>>>> workaround the absence of native functionality?
>>>>>>
>>>>>> So the big philosophical question is...
>>>>>> If a ZIP file is just a resource, then perhaps it's not a new Maven
>>>>>> "zip"
>>>>>> type that should be supported... it should be a new Maven "resource"
>>>>>> type
>>>>>> that can be any kind of file.
>>>>>>
>>>>>> Thoughts?
>>>>>>
>>>>>>
>>>>>> As per definition, ZIP files can also contain class files. Perfectly
>>>>> valid. Additionally, a lot of people are wating for MNG-1683 just like
>>>>> you
>>>>> and me. I would require to solve this issue first before we continue
>>>>> discussion.
>>>>>
>>>>> Michael
>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Discussion: Resource-only artifacts
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-08-17 um 22:05 schrieb Paul Benedict:
> I am in agreement a ZIP file shouldn't be a "second-class type". I do not
> want that either. However, it seems I may have said something that makes
> you believe I am saying otherwise? Can you please let me know what you saw
> in my explanation? I'd just like to know and make sure we're on the same
> page. Thanks, Michael.
It was actually this statement:
(2) or explicitly set a different scope to make it part of the class path
All items shall be equal by default unless told otherwise.
> On Wed, Aug 17, 2016 at 3:00 PM, Michael Osipov <mi...@apache.org> wrote:
>
>> Am 2016-08-17 um 21:57 schrieb Paul Benedict:
>>
>>> Yes, it is valid for a ZIP to contain class files. However, I don't
>>> believe
>>> Maven should create a bias here for Java. The ZIP file type, in its
>>> objective form, has nothing to do with Java. It just so happens Java chose
>>> to support that file type as a source of classes.
>>>
>>> As as a consequence, a ZIP file could be either of the two use cases in a
>>> project.... and MNG-6080 explains how to handle that:
>>> (1) default handling is to treat ZIP files as a mere container
>>>
>>
>> I agree here. No assumptions shall be made since this is a generic
>> container but it does not mean that it doesn't has be to a second-class
>> type of artifact in the system.
>>
>>
>> On Wed, Aug 17, 2016 at 2:37 PM, Michael Osipov <mi...@apache.org>
>>> wrote:
>>>
>>> Am 2016-08-17 um 19:20 schrieb Paul Benedict:
>>>>
>>>> I'm in in the thought process of MNG-6080 and MNG-5567, and I have an
>>>>> idea
>>>>> to run by the dev folks here:
>>>>>
>>>>> A ZIP file is a type of resource. A resource artifact gets a new scope
>>>>> to
>>>>> remain in the reactor but does not contribute to the compiling process
>>>>> or
>>>>> runtime environment. It's up to the build to determine how to consume it
>>>>> (via some other mechanism like input into a plugin). But is a ZIP
>>>>> artifact
>>>>> really any different from any other kind of non-functional artifact?
>>>>> What
>>>>> about text files, markdown files, or any other kind of non-code resource
>>>>> you want to share and use?
>>>>>
>>>>> One such thought of mine was people who want to deploy OSS license
>>>>> files.
>>>>> Instead of keeping a static copy in a project for distribution bundling,
>>>>> it
>>>>> could be part of a project dependency and added. I am pretty sure there
>>>>> are
>>>>> Maven plugins specifically built for this -- but are these plugin to
>>>>> workaround the absence of native functionality?
>>>>>
>>>>> So the big philosophical question is...
>>>>> If a ZIP file is just a resource, then perhaps it's not a new Maven
>>>>> "zip"
>>>>> type that should be supported... it should be a new Maven "resource"
>>>>> type
>>>>> that can be any kind of file.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>>
>>>> As per definition, ZIP files can also contain class files. Perfectly
>>>> valid. Additionally, a lot of people are wating for MNG-1683 just like
>>>> you
>>>> and me. I would require to solve this issue first before we continue
>>>> discussion.
>>>>
>>>> Michael
>>>>
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>>
>>>>
>>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Discussion: Resource-only artifacts
Posted by Paul Benedict <pb...@apache.org>.
I am in agreement a ZIP file shouldn't be a "second-class type". I do not
want that either. However, it seems I may have said something that makes
you believe I am saying otherwise? Can you please let me know what you saw
in my explanation? I'd just like to know and make sure we're on the same
page. Thanks, Michael.
Cheers,
Paul
On Wed, Aug 17, 2016 at 3:00 PM, Michael Osipov <mi...@apache.org> wrote:
> Am 2016-08-17 um 21:57 schrieb Paul Benedict:
>
>> Yes, it is valid for a ZIP to contain class files. However, I don't
>> believe
>> Maven should create a bias here for Java. The ZIP file type, in its
>> objective form, has nothing to do with Java. It just so happens Java chose
>> to support that file type as a source of classes.
>>
>> As as a consequence, a ZIP file could be either of the two use cases in a
>> project.... and MNG-6080 explains how to handle that:
>> (1) default handling is to treat ZIP files as a mere container
>>
>
> I agree here. No assumptions shall be made since this is a generic
> container but it does not mean that it doesn't has be to a second-class
> type of artifact in the system.
>
>
> On Wed, Aug 17, 2016 at 2:37 PM, Michael Osipov <mi...@apache.org>
>> wrote:
>>
>> Am 2016-08-17 um 19:20 schrieb Paul Benedict:
>>>
>>> I'm in in the thought process of MNG-6080 and MNG-5567, and I have an
>>>> idea
>>>> to run by the dev folks here:
>>>>
>>>> A ZIP file is a type of resource. A resource artifact gets a new scope
>>>> to
>>>> remain in the reactor but does not contribute to the compiling process
>>>> or
>>>> runtime environment. It's up to the build to determine how to consume it
>>>> (via some other mechanism like input into a plugin). But is a ZIP
>>>> artifact
>>>> really any different from any other kind of non-functional artifact?
>>>> What
>>>> about text files, markdown files, or any other kind of non-code resource
>>>> you want to share and use?
>>>>
>>>> One such thought of mine was people who want to deploy OSS license
>>>> files.
>>>> Instead of keeping a static copy in a project for distribution bundling,
>>>> it
>>>> could be part of a project dependency and added. I am pretty sure there
>>>> are
>>>> Maven plugins specifically built for this -- but are these plugin to
>>>> workaround the absence of native functionality?
>>>>
>>>> So the big philosophical question is...
>>>> If a ZIP file is just a resource, then perhaps it's not a new Maven
>>>> "zip"
>>>> type that should be supported... it should be a new Maven "resource"
>>>> type
>>>> that can be any kind of file.
>>>>
>>>> Thoughts?
>>>>
>>>>
>>> As per definition, ZIP files can also contain class files. Perfectly
>>> valid. Additionally, a lot of people are wating for MNG-1683 just like
>>> you
>>> and me. I would require to solve this issue first before we continue
>>> discussion.
>>>
>>> Michael
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>>
>>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Discussion: Resource-only artifacts
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-08-17 um 21:57 schrieb Paul Benedict:
> Yes, it is valid for a ZIP to contain class files. However, I don't believe
> Maven should create a bias here for Java. The ZIP file type, in its
> objective form, has nothing to do with Java. It just so happens Java chose
> to support that file type as a source of classes.
>
> As as a consequence, a ZIP file could be either of the two use cases in a
> project.... and MNG-6080 explains how to handle that:
> (1) default handling is to treat ZIP files as a mere container
I agree here. No assumptions shall be made since this is a generic
container but it does not mean that it doesn't has be to a second-class
type of artifact in the system.
> On Wed, Aug 17, 2016 at 2:37 PM, Michael Osipov <mi...@apache.org> wrote:
>
>> Am 2016-08-17 um 19:20 schrieb Paul Benedict:
>>
>>> I'm in in the thought process of MNG-6080 and MNG-5567, and I have an idea
>>> to run by the dev folks here:
>>>
>>> A ZIP file is a type of resource. A resource artifact gets a new scope to
>>> remain in the reactor but does not contribute to the compiling process or
>>> runtime environment. It's up to the build to determine how to consume it
>>> (via some other mechanism like input into a plugin). But is a ZIP artifact
>>> really any different from any other kind of non-functional artifact? What
>>> about text files, markdown files, or any other kind of non-code resource
>>> you want to share and use?
>>>
>>> One such thought of mine was people who want to deploy OSS license files.
>>> Instead of keeping a static copy in a project for distribution bundling,
>>> it
>>> could be part of a project dependency and added. I am pretty sure there
>>> are
>>> Maven plugins specifically built for this -- but are these plugin to
>>> workaround the absence of native functionality?
>>>
>>> So the big philosophical question is...
>>> If a ZIP file is just a resource, then perhaps it's not a new Maven "zip"
>>> type that should be supported... it should be a new Maven "resource" type
>>> that can be any kind of file.
>>>
>>> Thoughts?
>>>
>>
>> As per definition, ZIP files can also contain class files. Perfectly
>> valid. Additionally, a lot of people are wating for MNG-1683 just like you
>> and me. I would require to solve this issue first before we continue
>> discussion.
>>
>> Michael
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Discussion: Resource-only artifacts
Posted by Paul Benedict <pb...@apache.org>.
Yes, it is valid for a ZIP to contain class files. However, I don't believe
Maven should create a bias here for Java. The ZIP file type, in its
objective form, has nothing to do with Java. It just so happens Java chose
to support that file type as a source of classes.
As as a consequence, a ZIP file could be either of the two use cases in a
project.... and MNG-6080 explains how to handle that:
(1) default handling is to treat ZIP files as a mere container
(2) or explicitly set a different scope to make it part of the class path
From my perspective, I agree with that conceptual model. That seems right
to me... but it does raise the bigger issue regarding Maven and
resource-only artifacts. Except for the "pom" packaging type, every other
type relates to code, no? The current core packaging values are: pom, jar,
maven-plugin, ejb, war, ear, rar, par. So I think it behooves us we get the
first non-code type handled correctly. Just my 2 cents.
Cheers,
Paul
On Wed, Aug 17, 2016 at 2:37 PM, Michael Osipov <mi...@apache.org> wrote:
> Am 2016-08-17 um 19:20 schrieb Paul Benedict:
>
>> I'm in in the thought process of MNG-6080 and MNG-5567, and I have an idea
>> to run by the dev folks here:
>>
>> A ZIP file is a type of resource. A resource artifact gets a new scope to
>> remain in the reactor but does not contribute to the compiling process or
>> runtime environment. It's up to the build to determine how to consume it
>> (via some other mechanism like input into a plugin). But is a ZIP artifact
>> really any different from any other kind of non-functional artifact? What
>> about text files, markdown files, or any other kind of non-code resource
>> you want to share and use?
>>
>> One such thought of mine was people who want to deploy OSS license files.
>> Instead of keeping a static copy in a project for distribution bundling,
>> it
>> could be part of a project dependency and added. I am pretty sure there
>> are
>> Maven plugins specifically built for this -- but are these plugin to
>> workaround the absence of native functionality?
>>
>> So the big philosophical question is...
>> If a ZIP file is just a resource, then perhaps it's not a new Maven "zip"
>> type that should be supported... it should be a new Maven "resource" type
>> that can be any kind of file.
>>
>> Thoughts?
>>
>
> As per definition, ZIP files can also contain class files. Perfectly
> valid. Additionally, a lot of people are wating for MNG-1683 just like you
> and me. I would require to solve this issue first before we continue
> discussion.
>
> Michael
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
Re: Discussion: Resource-only artifacts
Posted by Michael Osipov <mi...@apache.org>.
Am 2016-08-17 um 19:20 schrieb Paul Benedict:
> I'm in in the thought process of MNG-6080 and MNG-5567, and I have an idea
> to run by the dev folks here:
>
> A ZIP file is a type of resource. A resource artifact gets a new scope to
> remain in the reactor but does not contribute to the compiling process or
> runtime environment. It's up to the build to determine how to consume it
> (via some other mechanism like input into a plugin). But is a ZIP artifact
> really any different from any other kind of non-functional artifact? What
> about text files, markdown files, or any other kind of non-code resource
> you want to share and use?
>
> One such thought of mine was people who want to deploy OSS license files.
> Instead of keeping a static copy in a project for distribution bundling, it
> could be part of a project dependency and added. I am pretty sure there are
> Maven plugins specifically built for this -- but are these plugin to
> workaround the absence of native functionality?
>
> So the big philosophical question is...
> If a ZIP file is just a resource, then perhaps it's not a new Maven "zip"
> type that should be supported... it should be a new Maven "resource" type
> that can be any kind of file.
>
> Thoughts?
As per definition, ZIP files can also contain class files. Perfectly
valid. Additionally, a lot of people are wating for MNG-1683 just like
you and me. I would require to solve this issue first before we continue
discussion.
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org