On Thu, 18 Aug 2016 23:40:17 +0200, Bernd Eckenfels
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
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
On Thu, 18 Aug 2016 21:27:38 +0200, Paul Benedict
wrote:
On Thu, Aug 18, 2016 at 11:53 AM, Robert Scholte
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 sco
Bernd, okay, I find that sensible. Thanks for pointing that out.
Cheers,
Paul
On Thu, Aug 18, 2016 at 3:05 PM, Bernd Eckenfels
wrote:
> Am Thu, 18 Aug 2016 14:27:38 -0500
> schrieb Paul Benedict :
> > Agreed, but only if your understanding of "do" includes do nothing. I
> > wouldn't expect the
Am Thu, 18 Aug 2016 14:27:38 -0500
schrieb Paul Benedict :
> 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 jus
On Thu, Aug 18, 2016 at 11:53 AM, Robert Scholte
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
> s
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 no
Christian, I am in agreement. Do you have a suggestion on how to identify
the resource file name? Right now the 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.
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,
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 ad
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 l
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
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 s
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 fi
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
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
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,
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
18 matches
Mail list logo