[GitHub] maven-surefire issue #81: Create better report for AssumptionFailure
Github user jimma commented on the issue: https://github.com/apache/maven-surefire/pull/81 @Tibor17 Thanks for review. Please look at if this is OK now. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Discussion: Resource-only artifacts
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven pull request #92: MNG-5909 : Add combined expression evaluator to file...
GitHub user lbndev opened a pull request: https://github.com/apache/maven/pull/92 MNG-5909 : Add combined expression evaluator to file activation property Suggested solution for MNG-5909 : the file activation element will understand basic boolean expressions such as and(file1,file2) or(file3,!file4) etc... Please see added unit test for expression examples. If you think this could benefit to other activators (property, os, ...) please say so and I will happily modify them too. I will also post a message on maven dev mailing list. You can merge this pull request into a Git repository by running: $ git pull https://github.com/lbndev/maven MNG-5909 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/maven/pull/92.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #92 commit 2efe3d2d3b92685d83c2598a7f85c39ebdd59ebc Author: Loïc B Date: 2016-08-16T09:21:52Z Add combined expression evaluator to file activation property --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[GitHub] maven-surefire pull request #81: Create better report for AssumptionFailure
Github user Tibor17 commented on a diff in the pull request:
https://github.com/apache/maven-surefire/pull/81#discussion_r75205391
--- Diff:
surefire-providers/common-junit4/src/main/java/org/apache/maven/surefire/common/junit4/JUnit4RunListener.java
---
@@ -128,11 +128,11 @@ protected StackTraceWriter createStackTraceWriter(
Failure failure )
@SuppressWarnings( { "UnusedDeclaration" } )
public void testAssumptionFailure( Failure failure )
{
-this.reporter.testAssumptionFailure( createReportEntry(
failure.getDescription() ) );
+this.reporter.testAssumptionFailure( SimpleReportEntry.ignored(
getClassName( failure.getDescription() ) ,
--- End diff --
@jimma
Can you please introduce a new constructor `public SimpleReportEntry(
String source, String name, String message )` and call it instead of
`SimpleReportEntry.ignored`? Can you call that constructor in
`SimpleReportEntry.ignored` as well? Thx.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Discussion: Resource-only artifacts
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 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 >> 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 >>> 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-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 > >
[GitHub] maven-surefire issue #81: Create better report for AssumptionFailure
Github user Tibor17 commented on the issue: https://github.com/apache/maven-surefire/pull/81 @jimma This maybe can be. Did you run ```mvn install ``` ? It should take 30-40 minutes including integration tests. Is there any failure? Can you update your project and merge the conflicts? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. --- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Discussion: Resource-only artifacts
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 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 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-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
Re: Discussion: Resource-only artifacts
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 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 >> 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-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 > >
Re: Discussion: Resource-only artifacts
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 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-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
Re: Discussion: Resource-only artifacts
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 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-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Discussion: Resource-only artifacts
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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Discussion: Resource-only artifacts
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 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 > 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-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Discussion: Resource-only artifacts
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 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-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
New Maven Model version (was Re: Preleminary Maven 3.4.0-SNAPSHOT Testing (Take 3))
Moving this discussion to the dev@ list... My advice is for the team to introduce the full functional consumption of a 4.1 POM in Maven 4.0. What should go in the 3.x branch is the appropriate forward-compatible handling -- warning or error -- to allow 3.x users to receive sensible diagnostic messages. I see that as the best sole reason to increase Maven's major version. The 3.x has always been held back to using the current POM model. It sounds like the future is almost here and I wouldn't set the bar any higher for a Maven 4.0 release. That sounds like the feature that should drive tomorrow. Cheers, Paul On Tue, Aug 16, 2016 at 9:57 PM, Christian Schulte wrote: > Am 08/17/16 um 04:09 schrieb Mark Derricutt: > > On 17 Aug 2016, at 12:32, Christian Schulte wrote: > > > >> There is an easy way to solve this. Maven validates the model version in > >> the POM to match "4.0.0". Based on that version, Maven can decide how to > >> behave. I am thinking about introducing model version "4.1.0" in Maven > >> 3.4. All existing 4.0.0 POMs will work the same way as before. Model > > > > Would the deployed POM be a 4.1.0 or 4.0.0 Model? I seem to recall a > long time ago when we were doing the Google Hangouts discussions about a > mental separation of build/deploy POM. > > Deployed as 4.1.0. Yes, that means POMs will start to appear not useable > with Maven < 3.4. Tools parsing the POMs themselves (not using > maven-model-builder) would need to support that as well. > > > > > If deployed as 4.1.0 then you'd be forcing all consumers of that > dependency to use Maven 3.4.0 itself ( IMHO not in itself a bad idea ), but > that might hurt any consuming applications like Sonar, Jenkins, or other > build tools. > > > > That's the drawback I am seeing as well. It's the same syntax with > different semantics. That's why Maven < 3.4 would need to abort. > Everything < 3.4 cannot provide the behaviour for that model version and > thus must not e.g. silently ignore XML elements leading to e.g. > different dependency trees when used with >= 3.4. It's a question of how > to progress Maven core when it comes to changes in behaviour making > sense. "Has always been that way -> must not change." Means we can never > change anything and must provide new features for changing things (e.g. > keep the import scope the way it always has been and introduce an > include scope with the new behaviour and document the import scope is > considered deprecated). It's not always possible to introduce a change > as a new feature. We recently discussed the addition of some kind of > feature toggles or knobs. That won't work, in my opinion, because Maven > would behave differently based on command line options. It's not > possible to deploy a POM to central whose correct/intended behaviour > depends on a specical command line option in use. I see no other way to > incrementing the model version for such things. Maven needs to know how > to behave solely based on what is in the POM. Nothing syntax related. > > Regards, > -- > Christian > > > - > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org > For additional commands, e-mail: users-h...@maven.apache.org > >
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
