Re: Restore default escaping in maven-resources-plugin?

2016-11-28 Thread Christian Schulte
Am 11/27/16 um 22:04 schrieb Robert Scholte:
> Hi,
> 
> it all depends if the introduced escape character is really a good default  
> and/or if we should have 2 parameters regarding escaping.
> I prefer having only 1 parameter and I think that the chosen escape  
> character is not default enough to mark it as _the_ default.
> 
> just my 2 cents
> Robert

What character do you have in mind? I though about using some unicode
character known to not conflict with any escaping mechanism. Like:

U+241B SYMBOL FOR ESCAPE
U+2410 SYMBOL FOR DATALINK ESCAPE

But that cannot be used with resources not using a unicode capable
encoding. This maybe needs more thinking in general. Maybe "force" the
resources to be unicode in the 'src/' folders and provide a way to
specify a different output encoding, for example. Just reverting to the
default prior 3.0.0 would make the most sense for now, IMHO.



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



Re: Maven Classloader issue at Wagon

2016-11-28 Thread Dan Tran
I went ahead to deploy the fix for user to try out


-Dan

On Sun, Nov 27, 2016 at 10:48 PM, Dan Tran  wrote:

> I got it working by switching
>
> componentConfigurator.configureComponent( wagon, plexusConf, 
> container.getContainerRealm()
> );
>
> for
>
> componentConfigurator.configureComponent( wagon, plexusConf,
> (ClassRealm)this.getClass().getClassLoader() );
>
> Thoughts?
>
> -Dan
>
> On Sun, Nov 27, 2016 at 9:34 PM, Dan Tran  wrote:
>
>>
>> I am interested fixing the long waited issue
>> https://issues.apache.org/jira/browse/WAGON-454 ( since introduction of
>> Maven 3)
>>
>> where  a wagon user can configure additional wagon provider configuration
>>  at maven settings
>>
>> It boils down to this line
>>
>> https://github.com/mojohaus/wagon-maven-plugin/blob/master/
>> src/main/java/org/codehaus/mojo/wagon/shared/DefaultWagon
>> Factory.java#L211
>>
>> where plexus not able load the desired class
>>
>> Caused by: java.lang.ClassNotFoundException:
>> org.apache.maven.wagon.providers.ssh.knownhost.NullKnownHostProvider
>> at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.
>> loadClass(SelfFirstStrategy.java:50)
>> at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchroni
>> zedLoadClass(ClassRealm.java:271)
>> at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(
>> ClassRealm.java:247)
>> at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(
>> ClassRealm.java:239)
>> at org.codehaus.plexus.component.configurator.converters.Abstra
>> ctConfigurationConverter.getClassForImplementatio
>> nHint(AbstractConfigurationConverter.java:121)
>>
>>
>> Advice is very much appreciated
>>
>> -Dan
>>
>>
>>
>


[GitHub] maven-surefire issue #136: [SUREFIRE-1295] Attribute JVM crashes to tests

2016-11-28 Thread michaeltandy
Github user michaeltandy commented on the issue:

https://github.com/apache/maven-surefire/pull/136
  
I've checked this against my integration test, and it looks OK to me.

My change reported which test method was running at the time of the crash, 
rather than reporting only the class but for my application that doesn't matter 
as most of our test classes contain a single test method.

If you want to merge my integration test into this, I pushed it to 
https://github.com/michaeltandy/maven-surefire/tree/SUREFIRE-1295-tests-for-Tibor17


---
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 issue #130: [SUREFIRE-1295] Attribute JVM crashes to tests

2016-11-28 Thread Tibor17
Github user Tibor17 commented on the issue:

https://github.com/apache/maven-surefire/pull/130
  
@michaeltandy 
I was inspired by your PR. Can you make a code review 
https://github.com/apache/maven-surefire/pull/136?
I would like to run all IT tests and include yours.


---
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 #136: [SUREFIRE-1295] Attribute JVM crashes to t...

2016-11-28 Thread Tibor17
GitHub user Tibor17 opened a pull request:

https://github.com/apache/maven-surefire/pull/136

[SUREFIRE-1295] Attribute JVM crashes to tests

I have 4 tests ATest.java .. DTest.java, and CTest fails like this:

```
@Test
public void x() {
Runtime.getRuntime().halt( 0 );
}
```
Here is the result, see "Crashed tests".
```
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-surefire-plugin:2.19.2-SNAPSHOT:test 
(default-test) on project b: Execution default-test of goal 
org.apache.maven.plugins:maven-surefire-plugin:2.19.2-SNAPSHOT:test failed: The 
forked VM terminated without properly saying goodbye. VM crash or System.exit 
called?
[ERROR] Command was cmd.exe /X /C ""D:\Program 
Files\Java\jdk1.8.0_112\jre\bin\java" -jar 
D:\vcs\zmaz6\target\surefire\surefirebooter8109843199172464014.jar 
D:\vcs\zmaz6\target\surefire\surefire4550764212193522341tmp 
D:\vcs\zmaz6\target\surefire\surefire_07316673656092271862tmp"
[ERROR] Process Exit Code: 0
[ERROR] Crashed tests:
[ERROR] pkg.CTest
[ERROR] -> [Help 1]
```

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Tibor17/maven-surefire SUREFIRE-1295

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/136.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 #136


commit 364b0c9e8ae56916f0b9aead2a26f07ed57befca
Author: Tibor17 
Date:   2016-11-28T22:16:20Z

[SUREFIRE-1295] Attribute JVM crashes to tests




---
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



Propagate configuration to lifecycle mapping's plugins

2016-11-28 Thread Mario Krizmanić
Hello,

I'd like to create a maven plugin that provides a custom lifecycle mapping 
(META-INF/plexus/components.xml) for a custom packaging type that maps other 
maven plugins' goals to lifecycle phases and then to use the created maven 
plugin in a project - what's a so common scenario.

The plugin configuration propagates well to its own mojos, but does not to the 
other dependent maven plugins' mojos.

If the above issue description is not so clear, the concrete issue may be seen 
on my github fork: [1]

short sample explanation:
- plugin-a has the mojo class: [2]
- plugin-b defines the lifecycle mapping: [3]
- project references to project-b and provides the plugin configuration: [4]
- and the issue is that the provided plugin configuration is not passed to the 
mojo class: [2]

and so, how I think the issue may be solved:
- add a originPlugin (org.apache.maven.model.Plugin) field to the LifecycleMojo
- afterward merge originPlugin's configuration to a created PluginExecution 
from the LifecycleMojo

because the connection between the maven plugin that provides a custom 
lifecycle mapping and the defined lifecycle mojos does not exist at the moment 
during runtime

An alternative solution may be to copy, or to subclass the mojos to the new 
maven plugin, but I'd rather consider a 'cleaner' solution.

WDYT?

Regards,
Mario

[1] 
https://github.com/mkrizmanic/maven-integration-testing/commit/58b0af38da1174e7c415d041d0c4e8a203ff95cb
 

[2] 
https://github.com/mkrizmanic/maven-integration-testing/blob/MNG-/core-it-suite/src/test/resources/mng-/plugin-a/src/main/java/org/apache/maven/its/mnga/plugin/TestMojo.java
 

[3] 
https://github.com/mkrizmanic/maven-integration-testing/blob/MNG-/core-it-suite/src/test/resources/mng-/plugin-b/src/main/resources/META-INF/plexus/components.xml
 

[4] 
https://github.com/mkrizmanic/maven-integration-testing/blob/MNG-/core-it-suite/src/test/resources/mng-/project/pom.xml