Sorry I am so late to this party.
I find that Apache Maven 3.4.0-SNAPSHOT
(90f26c279af9738735be8f84f60dcf21b6244e24; 2016-07-22T11:23:04-04:00)
prefers .mvn/maven.config options instead of specifically listed
parameters. This is surprising to me. I expect the .mvn/maven.config
options to be
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
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"
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?
>
Hello,
I found this ticket : https://issues.apache.org/jira/browse/MNG-5909 to match
one of my current problems.
I have 3 profiles (A, B and C) each activated on file existence criteria. I
need to change it so that : - if fileA is missing, none of these profiles must
be active - if file A is
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,
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
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,