date:20161127

Re: Maven Classloader issue at Wagon

2016-11-27 Thread Dan Tran

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/
> DefaultWagonFactory.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.
> unsynchronizedLoadClass(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.
> AbstractConfigurationConverter.getClassForImplementatio
> nHint(AbstractConfigurationConverter.java:121)
>
>
> Advice is very much appreciated
>
> -Dan
>
>
>

Maven Classloader issue at Wagon

2016-11-27 Thread Dan Tran

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/DefaultWagonFactory.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.unsynchronizedLoadClass(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.AbstractConfigurationConverter.getClassForImplementatio
nHint(AbstractConfigurationConverter.java:121)


Advice is very much appreciated

-Dan

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

2016-11-27 Thread 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

On Sun, 27 Nov 2016 19:44:05 +0100, Karl Heinz Marbaise  
 wrote:



Hi,

On 27/11/16 18:34, Hervé BOUTEMY wrote:
yes, reverting MRESOURCES-223 seems reasonable since it has drawbacks  
that

were not envisioned IMHO


Yes this is a problem...

So this should be changed...I think of introducing an option to simply  
disable escaping...which will keep the behaviour of current 3.X line but  
gives the freedom to change it if needed...like deactivate escaping in  
some situations...


Or reverting the change will also be an option...

The idea was having a default value which was often used which  
unfortunately has the drawback of not being simply to be disabled...the  
solution "" looks  hacky ;-( ...so I would introduce an option to  
disable escaping...




Kind regards
Karl Heinz



Karl Heinz, since you worked on MRESOURCES-223, what do you think about  
it?


Regards,

Hervé

Le vendredi 25 novembre 2016, 14:24:15 CET Christian Schulte a écrit :

Hi,

the maven-resources-plugin has enabled escaping by default in version
3.0.0 - see MRESOURCES-223 [1]. Prior to version 3.0.0, users wanting  
to

make use of any escaping needed to set the 'escapeString' parameter to
some value. This parameter starts to default to the backslash as of
version 3.0.0. This has led to various issues. MRESOURCES-230 [2] and
MRESOURCES-231 [3].

MRESOURCES-230: Can't escape the escape string

I created an issue against maven-filtering - MSHARED-599 [4]. There is  
a

testcase in maven filtering testing that the escape string does not get
escaped. There is no way to allow escaping the escape string without
updating that test case. Starting to escape the escape string
potentionally breaks filtering resources relying on '\\' (two
backslashes) to be preserved after filtering. In practice, if we "fix"
maven-filtering to support escaping the escape string, properties
resources and any resources using backshlashes themselves for escaping,
will be broken after filtering. That means - there is no way to fix
MRESOURCES-230 [2] and MSHARED-599 [4] without introducing issues
mentioned above.

MRESOURCES-231: Can't disable escaping

Solution to this is to set the 'escapeString' parameter to  to
disable escaping. That means every user upgrading from a
maven-resources-plugin version < 3.0.0 will need to disable escaping,  
to

get the plugin behave the same way it did before. Users having used
escaping before, will have set the 'escapeString' parameter, so will  
not

notice anything.

I would like to make a release of the maven-resources-plugin (3.1.0 or
3.0.2?) and make the 'escapeString' parameter default to 'null' again.
WDYT? Users upgrading from < 3.0.0 to > 3.0.1 will not need to do
anything. If they have been using escaping before, they will have set
that parameter already, if they have not been using escaping before,
they will not need to do anything as escaping will no longer be enabled
by default due to the upgrade.


[1] 
[2] 
[3] 
[4] 


-
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: Restore default escaping in maven-resources-plugin?

2016-11-27 Thread Karl Heinz Marbaise


Hi,

On 27/11/16 18:34, Hervé BOUTEMY wrote:

yes, reverting MRESOURCES-223 seems reasonable since it has drawbacks that
were not envisioned IMHO


Yes this is a problem...

So this should be changed...I think of introducing an option to simply 
disable escaping...which will keep the behaviour of current 3.X line but 
gives the freedom to change it if needed...like deactivate escaping in 
some situations...


Or reverting the change will also be an option...

The idea was having a default value which was often used which 
unfortunately has the drawback of not being simply to be disabled...the 
solution "" looks  hacky ;-( ...so I would introduce an option to 
disable escaping...




Kind regards
Karl Heinz



Karl Heinz, since you worked on MRESOURCES-223, what do you think about it?

Regards,

Hervé

Le vendredi 25 novembre 2016, 14:24:15 CET Christian Schulte a écrit :

Hi,

the maven-resources-plugin has enabled escaping by default in version
3.0.0 - see MRESOURCES-223 [1]. Prior to version 3.0.0, users wanting to
make use of any escaping needed to set the 'escapeString' parameter to
some value. This parameter starts to default to the backslash as of
version 3.0.0. This has led to various issues. MRESOURCES-230 [2] and
MRESOURCES-231 [3].

MRESOURCES-230: Can't escape the escape string

I created an issue against maven-filtering - MSHARED-599 [4]. There is a
testcase in maven filtering testing that the escape string does not get
escaped. There is no way to allow escaping the escape string without
updating that test case. Starting to escape the escape string
potentionally breaks filtering resources relying on '\\' (two
backslashes) to be preserved after filtering. In practice, if we "fix"
maven-filtering to support escaping the escape string, properties
resources and any resources using backshlashes themselves for escaping,
will be broken after filtering. That means - there is no way to fix
MRESOURCES-230 [2] and MSHARED-599 [4] without introducing issues
mentioned above.

MRESOURCES-231: Can't disable escaping

Solution to this is to set the 'escapeString' parameter to  to
disable escaping. That means every user upgrading from a
maven-resources-plugin version < 3.0.0 will need to disable escaping, to
get the plugin behave the same way it did before. Users having used
escaping before, will have set the 'escapeString' parameter, so will not
notice anything.

I would like to make a release of the maven-resources-plugin (3.1.0 or
3.0.2?) and make the 'escapeString' parameter default to 'null' again.
WDYT? Users upgrading from < 3.0.0 to > 3.0.1 will not need to do
anything. If they have been using escaping before, they will have set
that parameter already, if they have not been using escaping before,
they will not need to do anything as escaping will no longer be enabled
by default due to the upgrade.


[1] 
[2] 
[3] 
[4] 


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

Re: Fwd: Build failed in Jenkins: maven-enforcer #245

2016-11-27 Thread Hervé BOUTEMY

look at the begining of the console output: "Building remotely on jenkins-
test-2e6"
looks like some tests: I launched the build and it's now ok, and I just asked 
for information on these slaves [1]

Regards,

Hervé

[1] https://lists.apache.org/thread.html/
9b5040d35b9e05e21493184be5b307039bb8f350d2f761cc45ef6f7a@%3Cbuilds.apache.org
%3E

Le samedi 26 novembre 2016, 23:56:28 CET Guillaume Boué a écrit :
> Hmm, the error is
> 
> java.lang.IllegalArgumentException
>  ption>: /home/jenkins/tools/maven/apache-maven-3.0.5 doesn't have a 'lib'
> subdirectory - thus cannot be a valid maven installation!
> 
> Could someone take a look at the maven-enforcer job on Jenkins? The last
> build went fine, but it seems there was a change in the Maven
> installation used?
> 
> Thanks,
> Guillaume
> 
> 
>  Message transféré 
> Sujet :   Build failed in Jenkins: maven-enforcer #245
> Date :Sat, 26 Nov 2016 22:50:25 + (UTC)
> De :  Apache Jenkins Server 
> Pour :notificati...@maven.apache.org, gb...@apache.org
> 
> 
> 
> See 
> 
> Changes:
> 
> [gboue] [MENFORCER-247] Add a "require file checksum" rule
> Submitted by: Lyubomyr Shaydariv
> 
> New RequireFileChecksum, rule that is non cacheable and inherits from
> AbstractNonCacheableEnforcerRule. This closes #18.
> 
> --
> [...truncated 280 lines...]
> A
> enforcer-api/src/custom-rule-sample/src/main/java/org/apache/maven/enforcer
> A
> enforcer-api/src/custom-rule-sample/src/main/java/org/apache/maven/enforcer
> /rule AU   
> enforcer-api/src/custom-rule-sample/src/main/java/org/apache/maven/enforcer
> /rule/MyCustomRule.java AU   
> enforcer-api/src/custom-rule-sample/pom.xml
> AUenforcer-api/src/custom-rule-sample/usage-pom.xml
> AUenforcer-api/pom.xml
> AUpom.xml
> A README.TXT
> A enforcer-rules
> A enforcer-rules/src
> A enforcer-rules/src/main
> A enforcer-rules/src/main/java
> A enforcer-rules/src/main/java/org
> A enforcer-rules/src/main/java/org/apache
> A enforcer-rules/src/main/java/org/apache/maven
> A enforcer-rules/src/main/java/org/apache/maven/plugins
> A enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer
> AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireRelea
> seDeps.java A
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireUpper
> BoundDeps.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractVers
> ionEnforcer.java A
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BanDistribut
> ionManagement.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedDepend
> encies.java A
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedReposi
> tories.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireFileC
> hecksum.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractStan
> dardEnforcerRule.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireFiles
> DontExist.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireSnaps
> hotVersion.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/DefaultEnfor
> cementRuleHelper.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireEnvir
> onmentVariable.java A
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireSameV
> ersions.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/NoSnapshots.
> java A
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BanTransitiv
> eDependencies.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireNoRep
> ositories.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractRequ
> ireFiles.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireRelea
> seVersion.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequirePlugi
> nVersions.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AlwaysPass.j
> ava AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireActiv
> eProfile.java A
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/BannedPlugin
> s.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/RequireFiles
> Size.java AU   
> enforcer-rules/src/main/java/org/apache/maven/plugins/enforcer/AbstractBanD
> ependencies.java AU   
>

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

2016-11-27 Thread Hervé BOUTEMY

yes, reverting MRESOURCES-223 seems reasonable since it has drawbacks that 
were not envisioned IMHO

Karl Heinz, since you worked on MRESOURCES-223, what do you think about it?

Regards,

Hervé

Le vendredi 25 novembre 2016, 14:24:15 CET Christian Schulte a écrit :
> Hi,
> 
> the maven-resources-plugin has enabled escaping by default in version
> 3.0.0 - see MRESOURCES-223 [1]. Prior to version 3.0.0, users wanting to
> make use of any escaping needed to set the 'escapeString' parameter to
> some value. This parameter starts to default to the backslash as of
> version 3.0.0. This has led to various issues. MRESOURCES-230 [2] and
> MRESOURCES-231 [3].
> 
> MRESOURCES-230: Can't escape the escape string
> 
> I created an issue against maven-filtering - MSHARED-599 [4]. There is a
> testcase in maven filtering testing that the escape string does not get
> escaped. There is no way to allow escaping the escape string without
> updating that test case. Starting to escape the escape string
> potentionally breaks filtering resources relying on '\\' (two
> backslashes) to be preserved after filtering. In practice, if we "fix"
> maven-filtering to support escaping the escape string, properties
> resources and any resources using backshlashes themselves for escaping,
> will be broken after filtering. That means - there is no way to fix
> MRESOURCES-230 [2] and MSHARED-599 [4] without introducing issues
> mentioned above.
> 
> MRESOURCES-231: Can't disable escaping
> 
> Solution to this is to set the 'escapeString' parameter to  to
> disable escaping. That means every user upgrading from a
> maven-resources-plugin version < 3.0.0 will need to disable escaping, to
> get the plugin behave the same way it did before. Users having used
> escaping before, will have set the 'escapeString' parameter, so will not
> notice anything.
> 
> I would like to make a release of the maven-resources-plugin (3.1.0 or
> 3.0.2?) and make the 'escapeString' parameter default to 'null' again.
> WDYT? Users upgrading from < 3.0.0 to > 3.0.1 will not need to do
> anything. If they have been using escaping before, they will have set
> that parameter already, if they have not been using escaping before,
> they will not need to do anything as escaping will no longer be enabled
> by default due to the upgrade.
> 
> 
> [1] 
> [2] 
> [3] 
> [4] 
> 
> -
> 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: Maven Classloader issue at Wagon

Maven Classloader issue at Wagon

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

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

Re: Fwd: Build failed in Jenkins: maven-enforcer #245

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

6 matches

Site Navigation

Mail list logo

Footer information