Re: MNG-5930 - lack of system properties expansion
Hi Karl,
In our case this is mostly a matter of the paradigm where (hundreds of)
projects are simple to setup & contribute, part of it is to have entire
configuration in the repository - close to the source code. From maven
perspective to have project specific settings.xml to adjust mirrors (yes -
there are projects with their own repository manager), servers and
sometimes proxies (things that cannot be defined in a pom.xml). Project
specific settings.xml (-s) allows also to avoid problems with users
specific overrides, (i.e. from multiple other projects) in their
.m2/settings.xml, for frequent switches between projects. MNG-4686
describes very similar use case except I prefer to have single settings.xml
file in .mvn directory to indicate project specific settings.xml by
convention.
The problem with .mvn/maven.config now is that settings.xml location must
be absolute to be able to invoke mvn command from sub-project level -
MNG-5859/MNG-5790. MNG-5930 is not my use case since I need only
${maven.multiModuleProjectDirectory}
expansion to effectively access all files in the repository. Generally
would like to have .mvn/settings.xml location treated the same like
extensions.xml / jvm.config / maven.config however the approach with
maven.config and ${maven.multiModuleProjectDirectory} property / all system
properties expansion seems to be less intrusive and slightly more generic.
Regards,
NW
On Thu, Aug 11, 2016 at 9:08 PM, Karl Heinz Marbaise
wrote:
> Hi,
>
> can you explain why you have the need for different
> mirrors to be defined ?
>
> Are you using a repository manager ?
>
> Related to MNG-4686[1] I'm thinking what's the reason to have a different
> local caches?
>
>
> Kind regards
> Karl Heinz
>
> [1]: https://issues.apache.org/jira/browse/MNG-4686
>
>
> On 10/08/16 01:16, Norbert Wnuk wrote:
>
>> Hi All,
>> I was wondering whether the statement that lack of system properties
>> expansion in maven.config has be done by design and it is rather unlikely
>> to change it is still valid (MNG-5930, commented by Jason). Below a link
>> to
>> the tiny change that would help me with i.e. MNG-4686, even the more
>> narrow
>> filtering as described in MNG-5859 would be sufficient for me (mainly to
>> allow for project specific settings.xml files with i.e. different mirrors
>> that cannot be defined in pom.xml).
>> Wanted to confirm how desirable this change is / which approach would be
>> more likely to be accepted if at all.
>>
>> https://github.com/norbertwnuk/maven/commit/c0d7b260a5a04158
>> 4b4b71e428030f37af3102bb
>>
>> Regards,
>> Norbert
>>
>>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
MNG-5930 - lack of system properties expansion
Hi All, I was wondering whether the statement that lack of system properties expansion in maven.config has be done by design and it is rather unlikely to change it is still valid (MNG-5930, commented by Jason). Below a link to the tiny change that would help me with i.e. MNG-4686, even the more narrow filtering as described in MNG-5859 would be sufficient for me (mainly to allow for project specific settings.xml files with i.e. different mirrors that cannot be defined in pom.xml). Wanted to confirm how desirable this change is / which approach would be more likely to be accepted if at all. https://github.com/norbertwnuk/maven/commit/c0d7b260a5a041584b4b71e428030f37af3102bb Regards, Norbert
Re: Account on issues.apache.org/jira
My account was assigned to someone else, decided to sent an email to infrastruct...@apache.org to clarify this situation. NW On Thu, Aug 27, 2015 at 1:22 AM, Martin Gainty wrote: > Norbert > > what is a *non-standard problem* > > ? > Martin > > > > From: norbertw...@gmail.com > > Date: Wed, 26 Aug 2015 19:02:39 +0200 > > Subject: Account on issues.apache.org/jira > > To: dev@maven.apache.org > > > > Hi, > > What is the email address to report (non standard) problems with the JIRA > > account? > > > > Regards, > > NW > >
Account on issues.apache.org/jira
Hi, What is the email address to report (non standard) problems with the JIRA account? Regards, NW
Re: Surefire Plugin does not handle workingDirectory in fork mode properly
SUREFIRE-1136 finally integrated, thx for the support. Regards, NW On Sat, Jan 31, 2015 at 10:37 AM, Norbert Wnuk wrote: > Hi Tibor & Andreas, > Surefire855, it was only a remark - I was not touching it. > New pull request attached - > https://github.com/apache/maven-surefire/pull/84 > > Regards, > NW > > On Fri, Jan 30, 2015 at 6:16 PM, Tibor Digana > wrote: > >> Hi Norbert, >> >> Definitely we should make notes about Maven 2 limitations. >> After you have opened new PR in GitHub we would add a text in our docu. >> >> I had a reason to use easytesting in Surefire855 IT - it's only IT, the >> main >> code is not affected, just upgrade to JDK6. I can skip this test in JDK5, >> do >> you want me to do that? We will switch to JDK 6 in Maven 3 - I hope soon. >> >> >> >> -- >> View this message in context: >> http://maven.40175.n5.nabble.com/Surefire-Plugin-does-not-handle-workingDirectory-in-fork-mode-properly-tp5824054p5825274.html >> Sent from the Maven Developers mailing list archive at Nabble.com. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >
Re: Surefire Plugin does not handle workingDirectory in fork mode properly
Hi Tibor & Andreas, Surefire855, it was only a remark - I was not touching it. New pull request attached - https://github.com/apache/maven-surefire/pull/84 Regards, NW On Fri, Jan 30, 2015 at 6:16 PM, Tibor Digana wrote: > Hi Norbert, > > Definitely we should make notes about Maven 2 limitations. > After you have opened new PR in GitHub we would add a text in our docu. > > I had a reason to use easytesting in Surefire855 IT - it's only IT, the > main > code is not affected, just upgrade to JDK6. I can skip this test in JDK5, > do > you want me to do that? We will switch to JDK 6 in Maven 3 - I hope soon. > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Surefire-Plugin-does-not-handle-workingDirectory-in-fork-mode-properly-tp5824054p5825274.html > Sent from the Maven Developers mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Surefire Plugin does not handle workingDirectory in fork mode properly
Seems that entire surefire.forkNumber feature does not work on MVN 2.2.1
since for working directory expansion variables that are not yet defined
during initial plug-in execution are set to 'null' value. Later on both
baseDir and current working directory will be invalid, other parts of the
plug-in (e.g. argLine) are affected too. I would prefer to add note about
this limitation to JIRA / IT test description since it is something outside
of the plug-in itself plus affects deprecated maven version only. If so,
what is the preferred way to disable this IT test in maven-2.2.1 profile?
${project.name
}_${NotYetDefined}_${surefire.forkNumber}
/home/norbert/src/maven-surefire/surefire-integration-tests/target/Surefire1136CwdPropagationInForkedModeIT_testTestNgAndJUnitTogether/cwd_null_null
at
org.apache.maven.plugin.surefire.AbstractSurefireMojo.setWorkingDirectory(AbstractSurefireMojo.java:2654)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.setValueUsingSetter(ComponentValueSetter.java:177)
at
org.codehaus.plexus.component.configurator.converters.ComponentValueSetter.configure(ComponentValueSetter.java:212)
at
org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:137)
at
org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:56)
at
org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1357)
at
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:724)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:468)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at
sun.reflect.NativeMethodAccessorImpl.invoke0(NativeMethodAccessorImpl.java:-1)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:592)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Additional observation is that there are other test with fest library usage
(like i did originally) that cannot work on JDK 1.5:
[ERROR]
/home/norbert/src/maven-surefire/surefire-integration-tests/target/Surefire855AllowFailsafeUseArtifactFileIT_osgiBundleShouldUseFile/src/test/java/jiras/surefre855/bundle/FooIT.java:[32,-1]
cannot access org.fest.assertions.api.Assertions
bad class file:
/home/norbert/src/maven-surefire/surefire-integration-tests/../surefire-setup-integration-tests/target/it-repo/org/easytesting/fest-assert-core/2.0M9/fest-assert-core-2.0M9.jar(org/fest/assertions/api/Assertions.class)
class file has wrong version 50.0, should be 49.0
NW
On Wed, Jan 28, 2015 at 11:28 AM, Norbert Wnuk
wrote:
> Yes, will do that shortly. I would like to aggregate fixes for unit and
> integration test in one pull request, the link was only to show the
> progress.
>
> NW
>
> On Wed, Jan 28, 2015 at 8:51 AM, Andreas Gudian
> wrote:
>
>> Thanks, Norbert!
>>
>> Could you also create a new Pull-Request for it? Then I can fetch it more
>> easily :-)
>>
>>
>> Am Mittwoch, 28. Januar 2015 schrieb Norbert Wnuk :
>>
>> > Link after pushing amended commit -
>> >
>> >
>> https://g
Re: Surefire Plugin does not handle workingDirectory in fork mode properly
Yes, will do that shortly. I would like to aggregate fixes for unit and integration test in one pull request, the link was only to show the progress. NW On Wed, Jan 28, 2015 at 8:51 AM, Andreas Gudian wrote: > Thanks, Norbert! > > Could you also create a new Pull-Request for it? Then I can fetch it more > easily :-) > > > Am Mittwoch, 28. Januar 2015 schrieb Norbert Wnuk : > > > Link after pushing amended commit - > > > > > https://github.com/norbertwnuk/maven-surefire/commit/d6a8af593fc03e12ecf2dc8047669472f7ca263b > > > > On Wed, Jan 28, 2015 at 3:10 AM, Norbert Wnuk > > wrote: > > > > > Hi Tibor / Andreas, > > > I found a time to address problem with unit test, will take a look at > > > integration test tomorrow. > > > > > > > > > https://github.com/norbertwnuk/maven-surefire/commit/44b6ffaddc93c34c3e76abd4ea5fd3b8d837a130 > > > > > > NW > > > > > > On Sun, Jan 25, 2015 at 1:32 AM, Tibor Digana > > > > > wrote: > > > > > >> Hi Norbert, > > >> I have updaated PR #82 with comment on GitHub. > > >> The Ubuntu builds fail. > > >> I would prefer keeping the test anyway. > > >> Try to find a solution for Ubuntu as well; otherwise use JUnit > > assumption > > >> statement > > >> assumeThat( os, anyOf( is( "Windows" ), is( "Ubuntu1" ) ) ) > > >> in the particular IT method, possibly unit test. > > >> > > >> > > >> > > >> > > >> -- > > >> View this message in context: > > >> > > > http://maven.40175.n5.nabble.com/Surefire-Plugin-does-not-handle-workingDirectory-in-fork-mode-properly-tp5824054p5824683.html > > >> Sent from the Maven Developers mailing list archive at Nabble.com. > > >> > > >> - > > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > > >> For additional commands, e-mail: dev-h...@maven.apache.org > > > > >> > > >> > > > > > >
Re: Surefire Plugin does not handle workingDirectory in fork mode properly
Link after pushing amended commit - https://github.com/norbertwnuk/maven-surefire/commit/d6a8af593fc03e12ecf2dc8047669472f7ca263b On Wed, Jan 28, 2015 at 3:10 AM, Norbert Wnuk wrote: > Hi Tibor / Andreas, > I found a time to address problem with unit test, will take a look at > integration test tomorrow. > > https://github.com/norbertwnuk/maven-surefire/commit/44b6ffaddc93c34c3e76abd4ea5fd3b8d837a130 > > NW > > On Sun, Jan 25, 2015 at 1:32 AM, Tibor Digana > wrote: > >> Hi Norbert, >> I have updaated PR #82 with comment on GitHub. >> The Ubuntu builds fail. >> I would prefer keeping the test anyway. >> Try to find a solution for Ubuntu as well; otherwise use JUnit assumption >> statement >> assumeThat( os, anyOf( is( "Windows" ), is( "Ubuntu1" ) ) ) >> in the particular IT method, possibly unit test. >> >> >> >> >> -- >> View this message in context: >> http://maven.40175.n5.nabble.com/Surefire-Plugin-does-not-handle-workingDirectory-in-fork-mode-properly-tp5824054p5824683.html >> Sent from the Maven Developers mailing list archive at Nabble.com. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >
Re: Surefire Plugin does not handle workingDirectory in fork mode properly
Hi Tibor / Andreas, I found a time to address problem with unit test, will take a look at integration test tomorrow. https://github.com/norbertwnuk/maven-surefire/commit/44b6ffaddc93c34c3e76abd4ea5fd3b8d837a130 NW On Sun, Jan 25, 2015 at 1:32 AM, Tibor Digana wrote: > Hi Norbert, > I have updaated PR #82 with comment on GitHub. > The Ubuntu builds fail. > I would prefer keeping the test anyway. > Try to find a solution for Ubuntu as well; otherwise use JUnit assumption > statement > assumeThat( os, anyOf( is( "Windows" ), is( "Ubuntu1" ) ) ) > in the particular IT method, possibly unit test. > > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Surefire-Plugin-does-not-handle-workingDirectory-in-fork-mode-properly-tp5824054p5824683.html > Sent from the Maven Developers mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Surefire Plugin does not handle workingDirectory in fork mode properly
Hi Andreas, My pull request seems to be unusually problematic ... I was running all tests on Ubuntu (and Windows too) but apparently assumption that '\0' cannot be used in directory name on Linux might not be always true: https://builds.apache.org/job/maven-surefire/1386/ https://builds.apache.org/job/maven-surefire-mvn-2.2.1/1539/ http://stackoverflow.com/questions/1976007/what-characters-are-forbidden-in-windows-and-linux-directory-names Are you able to recreate the behavior? Not sure how it is related to the fact that I was forced to swap to first characters in directory name: "?\0InvalidDirectoryName" after last refactoring (removing nio API) since leading '\0' just after '\' in the path name started to affect getCanonicalPath on Windows (it was terminating path name at this position). Need one day more to clarify unit test and additionally re-run integration test with maven 2.x. Regards, NW On Thu, Jan 22, 2015 at 1:52 AM, Norbert Wnuk wrote: > Pull request with the fix - > https://github.com/apache/maven-surefire/pull/82 > > NW > > On Wed, Jan 21, 2015 at 9:27 PM, Tibor Digana > wrote: > >> This is a traditional problem with animal-sniffer-maven-plugin. >> We had the same issue in JUnit project. Alrerady reported in JIRA >> http://jira.codehaus.org/browse/MANIMALSNIFFER-54 >> http://jira.codehaus.org/browse/MANIMALSNIFFER-40 >> I would like to have the check-test goal or a new parameter. >> It's still assigned to @stephenc. >> I would appreciate it working and utilized in Maven and JUnit projects. >> >> >> >> -- >> View this message in context: >> http://maven.40175.n5.nabble.com/Surefire-Plugin-does-not-handle-workingDirectory-in-fork-mode-properly-tp5824054p5824348.html >> Sent from the Maven Developers mailing list archive at Nabble.com. >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org >> For additional commands, e-mail: dev-h...@maven.apache.org >> >> >
Re: Surefire Plugin does not handle workingDirectory in fork mode properly
Pull request with the fix - https://github.com/apache/maven-surefire/pull/82 NW On Wed, Jan 21, 2015 at 9:27 PM, Tibor Digana wrote: > This is a traditional problem with animal-sniffer-maven-plugin. > We had the same issue in JUnit project. Alrerady reported in JIRA > http://jira.codehaus.org/browse/MANIMALSNIFFER-54 > http://jira.codehaus.org/browse/MANIMALSNIFFER-40 > I would like to have the check-test goal or a new parameter. > It's still assigned to @stephenc. > I would appreciate it working and utilized in Maven and JUnit projects. > > > > -- > View this message in context: > http://maven.40175.n5.nabble.com/Surefire-Plugin-does-not-handle-workingDirectory-in-fork-mode-properly-tp5824054p5824348.html > Sent from the Maven Developers mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
Re: Surefire Plugin does not handle workingDirectory in fork mode properly
Hi Andreas,
The JDK API level is not enforced during build so that my accidental usage
of JDK 1.7 API in tests was not discovered till recent Jenkins build:
https://builds.apache.org/job/maven-surefire/1385/ Should I create new pull
request / what is the procedure after closing original pull request?
Regards,
NW
On Tue, Jan 20, 2015 at 1:24 AM, Norbert Wnuk wrote:
> JIRA created, pull request with more mature fix attached (including
> integration test).
>
> https://jira.codehaus.org/browse/SUREFIRE-1136
> https://github.com/apache/maven-surefire/pull/80
>
> Regards,
> NW
>
> On Mon, Jan 19, 2015 at 8:03 AM, Karl Heinz Marbaise
> wrote:
>
>> Hi Norbert,
>>
>> It's great that you asking for permission to create a jira but you don't
>> need to just create one and describe the situation etc. why and how it went
>> wrong or what can be improved and of course your patch is really
>> great...but it would be much easier if you could either provide a test for
>> your patch or at least add an example project which shows the wrong
>> behaviour...
>>
>> Thanks in advance
>>
>> Kind regards
>> Karl Heinz Marbaise
>>
>>
>> On 1/18/15 10:56 PM, Norbert Wnuk wrote:
>>
>>> Hi All,
>>> Not sure whether this is a proper place however Surefire webpage
>>> redirects to this mailing group.
>>> Recently we found two issues in Surefire plugin related to
>>> surefire.forkNumber variable and ability to define separate working
>>> directory per forked JVM. First issue is that the same directory is set
>>> for each of forked JVMs, the second problem is that surefire.forkNumber
>>> is expanded only for user.dir property and not for actual working
>>> directory (it leads to the situations like described here:
>>> http://stackoverflow.com/questions/1234795/why-is-the-
>>> user-dir-system-property-working-in-java).
>>> Attaching patch that resolves both problems for us (without test cases
>>> yet). Asking for a permission to create a JIRA.
>>>
>>> directory_${surefire.forkNumber}
>>>
>>> Regards,
>>> Norbert
>>>
>>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
>>
>
Re: Surefire Plugin does not handle workingDirectory in fork mode properly
JIRA created, pull request with more mature fix attached (including
integration test).
https://jira.codehaus.org/browse/SUREFIRE-1136
https://github.com/apache/maven-surefire/pull/80
Regards,
NW
On Mon, Jan 19, 2015 at 8:03 AM, Karl Heinz Marbaise
wrote:
> Hi Norbert,
>
> It's great that you asking for permission to create a jira but you don't
> need to just create one and describe the situation etc. why and how it went
> wrong or what can be improved and of course your patch is really
> great...but it would be much easier if you could either provide a test for
> your patch or at least add an example project which shows the wrong
> behaviour...
>
> Thanks in advance
>
> Kind regards
> Karl Heinz Marbaise
>
>
> On 1/18/15 10:56 PM, Norbert Wnuk wrote:
>
>> Hi All,
>> Not sure whether this is a proper place however Surefire webpage
>> redirects to this mailing group.
>> Recently we found two issues in Surefire plugin related to
>> surefire.forkNumber variable and ability to define separate working
>> directory per forked JVM. First issue is that the same directory is set
>> for each of forked JVMs, the second problem is that surefire.forkNumber
>> is expanded only for user.dir property and not for actual working
>> directory (it leads to the situations like described here:
>> http://stackoverflow.com/questions/1234795/why-is-the-
>> user-dir-system-property-working-in-java).
>> Attaching patch that resolves both problems for us (without test cases
>> yet). Asking for a permission to create a JIRA.
>>
>> directory_${surefire.forkNumber}
>>
>> Regards,
>> Norbert
>>
>>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>
Surefire Plugin does not handle workingDirectory in fork mode properly
Hi All,
Not sure whether this is a proper place however Surefire webpage redirects
to this mailing group.
Recently we found two issues in Surefire plugin related to
surefire.forkNumber variable and ability to define separate working
directory per forked JVM. First issue is that the same directory is set for
each of forked JVMs, the second problem is that surefire.forkNumber is
expanded only for user.dir property and not for actual working directory
(it leads to the situations like described here:
http://stackoverflow.com/questions/1234795/why-is-the-user-dir-system-property-working-in-java).
Attaching patch that resolves both problems for us (without test cases
yet). Asking for a permission to create a JIRA.
directory_${surefire.forkNumber}
Regards,
Norbert
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
