Using site even if build fails

[Robert Mark Bram]

Hi all,

Please excuse me if this is a double post - I couldn't be sure the
first one went through.

I am trying this command line:

mvn --fail-at-end -Plocal verify site

And I find that if an integration test fails, site is *not* being run
at all - even with --fail-at-end. This is my reporting element in
pom.xml:

  

  
org.apache.maven.plugins
maven-surefire-report-plugin
  
  
org.apache.maven.plugins
maven-javadoc-plugin
  

  

Have I misunderstood how site or  --fail-at-end works?

Rob
:)

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

Re: How to run multiple rounds of integration tests in one build

[Tecno Brain]

Separate attract build from integration tests.

In the integration test:
-Set up your system (cleanup,  install)
- run with the flag disabled
- run again with the flag disabled

I would use Jenkins build steps rather than maven profiles
On Mar 27, 2015 3:15 PM, "Stefan"  wrote:

> Hi guys,
>
> I've been banging my head over the following problem lately and wasn't
> able to find a solution at all on the interwebs.
>
> So, here's some context. I'm working on multiple RESTful APIs within a
> microservices architecture. Some of these applications can form separate
> stand alone sub-systems, which can safely be deployed on secured
> environments with API security turned off. Or, they can be deployed as
> public services, where some actions need proper authorization - i.e.
> addition and deletion of content, cluster management, etc.
>
> I want to be able to run 2 sets of, basically acceptance tests, within the
> build of each API. I need to start the APIs with different configurations
> and execute:
>
> 1. all tests against secured API
> 2. all tests - security tests against unsecured API
>
> The setup is also not trivial, as some of the APIs work with
> Solr/Cassandra/GraphDB, but at least it's the same for all tests and can be
> reused. The only change between test runs would be a single JVM parameter
> which turns security on and off.
>
> Basically, I want to be able to execute the /pre-integration-test ->
> integration-tests -> post-integration-test -> verify/ lifecycle phases
> multiple times.
>
> At the moment the best option I can see is to create multiple profiles and
> run the build multiple times. This has the obvious disadvantages of:
>
> 1. unnecessarily repackaging artifacts multiple times
> 2. can't run all tests with one command, which opens the door for
>errors on dev machines
> 3. Jenkins builds will become heavier and again, increased possibility
>of errors when configuring the jobs
>
> Do you have any better ideas?
>
> Thanks,
> Stefan
>
> --
> Stefan Enev
> Technical Architect, Publishing Platform
> Ontotext AD
>
>

How to run multiple rounds of integration tests in one build

[Stefan]

Hi guys,

I've been banging my head over the following problem lately and wasn't 
able to find a solution at all on the interwebs.


So, here's some context. I'm working on multiple RESTful APIs within a 
microservices architecture. Some of these applications can form separate 
stand alone sub-systems, which can safely be deployed on secured 
environments with API security turned off. Or, they can be deployed as 
public services, where some actions need proper authorization - i.e. 
addition and deletion of content, cluster management, etc.


I want to be able to run 2 sets of, basically acceptance tests, within 
the build of each API. I need to start the APIs with different 
configurations and execute:


1. all tests against secured API
2. all tests - security tests against unsecured API

The setup is also not trivial, as some of the APIs work with 
Solr/Cassandra/GraphDB, but at least it's the same for all tests and can 
be reused. The only change between test runs would be a single JVM 
parameter which turns security on and off.


Basically, I want to be able to execute the /pre-integration-test -> 
integration-tests -> post-integration-test -> verify/ lifecycle phases 
multiple times.


At the moment the best option I can see is to create multiple profiles 
and run the build multiple times. This has the obvious disadvantages of:


1. unnecessarily repackaging artifacts multiple times
2. can't run all tests with one command, which opens the door for
   errors on dev machines
3. Jenkins builds will become heavier and again, increased possibility
   of errors when configuring the jobs

Do you have any better ideas?

Thanks,
Stefan

--
Stefan Enev
Technical Architect, Publishing Platform
Ontotext AD

Re: AW: maven-release-plugin / SVN credentials

[Robert Scholte]

Hi Sebastian,

this is first of all more an svn commandline issue rather than a Maven /  
maven-release-plugin issue.
For that reason you should start by calling svn directly from the  
commandline. In the end, that's exactly what maven-release-plugin  
(actually the scm-svn-provider) does. Once it can be called from  
commandline, it should be a simple step to make it work with Maven.
"svn status" or "svn up" are easy to verify, but don't always require  
credentials (depends how the access is controlled by the svn server)

"svn commit" does require authentication.

How credentials are stored: that's all up the the svn client.

thanks,
Robert

Op Fri, 27 Mar 2015 10:35:51 +0100 schreef Sebastian Oerding  
:



Hi Robert,

- I have looked at the Maven SCM project but do not get my problem  
solved or more hints on it

- The maven-release-plugin is locked (with version 2.5, not 2.5.1)
- If running maven with -X according to console no credentials are  
provided when accessing the SVN
- If running maven with -Dusername / -Dpassword the credentials are  
shown (password masked) and it works, however changing the password at  
least monthly for each run configuration / bat file / ... is no real  
solution

- My colleagues encounter the same problem having switched to SVN 1.8
- How can I get a JIRA account to report a bug?
- I know that SVN really changes from 1.6 to 1.8, maybe this problem  
stems from there?
- I read that  the order of authentication mechanism changes, however  
trying parameter -Dsvnkit.http.methods=Basic,Digest,Negotiate,NTLM did  
not help
- Does the maven-scm-plugin should be able to access SVN with Windows 7  
+ Active Directory by using the system's Kerberos / NTLM ticket or was  
there any desupport of this feature?
- I also had the problem after the last password change but somehow  
managed it by doing a single commit with Tortoise, saving the  
credentials (deleting %USER%\AppData\Roaming\Subversion\auth before).  
Afterwards the maven-release worked as expected. Unfortunately this  
approach seems to work no more. Hence how can I check where are the  
credentials taken from? Is there some additional kind of extreme logging  
besides -e / -X switches?


Thanks in advance,
Sebastian

-Ursprüngliche Nachricht-
Von: Robert Scholte [mailto:rfscho...@apache.org]
Gesendet: Freitag, 27. März 2015 08:51
An: Maven Users List
Betreff: Re: maven-release-plugin / SVN credentials

Hi Sebastian,

since your issue has to do with svn, one needs to look at the Maven SCM  
project.[1] That's what the maven-release-plugin is using to the  
commits, tags and checkouts.
First ensure you've locked the version of the maven-release-plugin,  
preferably the lastest (i.e. 2.5.1).

If you run the plugin with logging level set to debug (by adding the -X
argument) you'll see the commandline
which is executed. You should be able to do the same (do strip off the  
cmdshell specific part). That should give you the same exception and  
might give you a hint how this could be fixed.


Verify if it is a knows issue in Jira[2], sometimes such issues give  
extra info.


Verify the SCM Subversion page[3], it also describes some additional  
configuration.


If this can't be solved by commandline, then there's a svnjava  
implementation which you could use[4].


thanks,
Robert

[1] http://maven.apache.org/scm/maven-scm-providers/index.html
[2] http://jira.codehaus.org/browse/SCM/component/11191
[3] http://maven.apache.org/scm/subversion.html
[4]
https://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/wiki/Usage

Op Thu, 26 Mar 2015 08:20:31 +0100 schreef Sebastian Oerding
:


Hello,

I have a problem with the maven-release-plugin using the SVN
credentials (details below). I always get an SVN authorization error.
It seems that the release plugin does not use the existing
credentials. Unfortunately I'm even not sure whether it is a problem
of the maven-release-plugin or SVN. How can I check / get a log which
credentials / whether credentials are actually used?

Please explain me how an installed SVN is used (SlikSvn and Tortoise
SVN installed, both with version 1.8 of the subversion protocol).

Details:
I'm in a company where we have Windows 7, 64 bit systems and an Active
Directory for Single Sign On (This Windows Kerberos / NTLM like stuff).

The maven-release-plugin worked fine until switching from subversion
1.6 to subversion 1.8. However I had exactly the same problem last
month after the monthly password change. Surprisingly I was able to
get this solved by making a single commit with Tortoise SVN providing
the credentials (and choosing Tortoise to save them). However after my
laptop has been renewed the same problem occurs again and I can not
solve it using the same trick as before.

Using Google I found a lot of posts on stackoverflow and similar stuff
where users report a problem with the maven-release-plugin and SVN
credentials. However all of the solutions presented are unacceptable
to

[ANN] Apache Maven Compiler Plugin Version 3.3 Released

[Karl Heinz Marbaise]

The Apache Maven team is pleased to announce the release of the 
Apache Maven Compiler Plugin, version 3.3

The Compiler Plugin is used to compile the sources of your project. 

http://maven.apache.org/plugins/maven-compiler-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-compiler-plugin
  3.3


Release Notes - Maven Compiler Plugin - Version 3.3

Bug:

 * [MCOMPILER-223] - Move to a non-ancient maven-toolchain dependency

Improvements:

 * [MCOMPILER-237] - Upgrade to Maven 2.2.1 compatiblity
 * [MCOMPILER-238] - Upgrade to maven-plugins parent version 27
 * [MCOMPILER-239] - Upgrade maven-shared-utils to 0.7
 * [MCOMPILER-241] - Upgrade plexus-compiler-api to 2.5

Enjoy,

-The Apache Maven team

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

Re: Integration Test: Dependency problem

[Christian Eugster]

After moving the dependencies to the parent pom and add them in the itest pom 
without version tag, I get in the itest pom following error for the following 
three depeondencies:


org.apache.camel.karaf
apache-camel



org.apache.karaf.features
standard
test


org.apache.karaf
apache-karaf
test


saying "Missing artifact org.apache.karaf.features:standard:jar:3.0.3"

But those are in the dependencyManagement section of the parent pom:


org.apache.camel.karaf
apache-camel
${camel.version}


org.apache.karaf.features
standard
${karaf.version}
test


org.apache.karaf
apache-karaf
${karaf.version}
test



Why does this message occure? Are these problems described anywhere so that I 
can resolve them myself?

Thanks and regards

Christian


Christian Eugster
Grissian 14
I-39010 Tisens
I:  +39 0473 420 873
CH: +41 79 107 92 27
christian.eugs...@gmx.net




> Am 27.03.2015 um 17:50 schrieb Stuart McCulloch :
> 
> I see you're declaring dependencies with bundle whereas you
> should just leave them with the default type (jar). While the packaging
> type is "bundle" (to activate the different packaging lifecycle) the
> artifacts produced are declared as type jar and can be referenced as
> dependencies with the default type.
> 
> If you do remove bundle then you likely won't need to add the
> bundle plugin to the top-level plugInManagement (though it is still good
> practice to pin plugin versions in your corporate pom)
> On 27 Mar 2015 16:36, "Christian Eugster"  wrote:
> 
>> Hi,
>> 
>> but as  I understand, the bundles have - as the normal jars - the
>> extension jar, the unique difference are some extra entries in the
>> MANIFEST.MF file. Is that wrong?
>> 
>> I added the frequently used dependencies to the parents pom as managed
>> dependencies and added those required for itest in the itest pom. I added
>> as you proposed the maven-bundle-plugin to the plugin management of the
>> parent pom. So the poms look like:
>> 
>> 
>> sip-detection POM:
>> 
>> 
>> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="
>> http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>>4.0.0
>> 
>>
>>ch.eugster.herakles
>>ingest
>>0.0.1-SNAPSHOT
>>
>> 
>>sip-detection
>>pom
>> 
>>
>>sip-detector-api
>>sip-detector-matterhorn
>>sip-detection-processor
>>sip-detection-features
>>sip-detector-itest
>>  
>> 
>> 
>> 
>> itest POM:
>> 
>> 
>> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="
>> http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>> 
>>
>> 
>>4.0.0
>> 
>>
>>sip-detection
>>ch.eugster.herakles
>>0.0.1-SNAPSHOT
>>
>> 
>>sip-detector-itest
>>pom
>> 
>>sip-detector-itest
>>sip-detector-itest
>> 
>>
>>4.4.0
>>3.0.3
>>
>> 
>>
>>
>>ch.eugster.herakles
>>sip-detector-api
>>0.0.1-SNAPSHOT
>>bundle
>>
>>
>>ch.eugster.herakles
>>sip-detector-matterhorn
>>${project.version}
>>bundle
>>
>>
>>ch.eugster.herakles
>>sip-matterhorn-profile
>>${project.version}
>>bundle
>>
>>
>>ch.eugster.herakles
>>sip-api
>>${project.version}
>>bundle
>>
>>
>>ch.eugster.herakles
>>sip-detection-processor
>>${project.version}
>>bundle
>>
>>
>>org.apache.camel
>>

Re: Integration Test: Dependency problem

[Stuart McCulloch]

type is not quite the same as packaging - packaging defines the lifecycle
used to build the project (what plugins get called for each phase) whereas
type is more about the final artifact and defines the extension amongst
other things.

The bundle lifecycle does define a type called 'bundle' with an extension
of 'jar'  - but as this is not a core type you need to add the bundle
plugin and set extensions to true - otherwise if you depend on artifacts
with type 'bundle' maven will assume the extension should also be
'.bundle'  (which is why the lookup was failing earlier)

But since bundles are also jars then you can simplify this when declaring
dependencies and just use the default dependency type (which has the same
extension: '.jar') which then means you don't need to pull in the bundle
plugin as an extension.
On 27 Mar 2015 17:00, "Christian Eugster"  wrote:

> So I can remove the type tag from dependencies. Is then tag type only used
> once, when introducing a new artifact in tag packaging?
>
> Regards Christian
>
> Christian Eugster
> Grissian 14
> I-39010 Tisens
> I:  +39 0473 420 873
> CH: +41 79 107 92 27
> christian.eugs...@gmx.net
>
>
>
>
> > Am 27.03.2015 um 17:50 schrieb Stuart McCulloch :
> >
> > I see you're declaring dependencies with bundle whereas you
> > should just leave them with the default type (jar). While the packaging
> > type is "bundle" (to activate the different packaging lifecycle) the
> > artifacts produced are declared as type jar and can be referenced as
> > dependencies with the default type.
> >
> > If you do remove bundle then you likely won't need to add
> the
> > bundle plugin to the top-level plugInManagement (though it is still good
> > practice to pin plugin versions in your corporate pom)
> > On 27 Mar 2015 16:36, "Christian Eugster" 
> wrote:
> >
> >> Hi,
> >>
> >> but as  I understand, the bundles have - as the normal jars - the
> >> extension jar, the unique difference are some extra entries in the
> >> MANIFEST.MF file. Is that wrong?
> >>
> >> I added the frequently used dependencies to the parents pom as managed
> >> dependencies and added those required for itest in the itest pom. I
> added
> >> as you proposed the maven-bundle-plugin to the plugin management of the
> >> parent pom. So the poms look like:
> >>
> >>
> >> sip-detection POM:
> >>
> >> 
> >> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
> >> http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="
> >> http://maven.apache.org/POM/4.0.0
> >> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> >>4.0.0
> >>
> >>
> >>ch.eugster.herakles
> >>ingest
> >>0.0.1-SNAPSHOT
> >>
> >>
> >>sip-detection
> >>pom
> >>
> >>
> >>sip-detector-api
> >>sip-detector-matterhorn
> >>sip-detection-processor
> >>sip-detection-features
> >>sip-detector-itest
> >>  
> >>
> >> 
> >>
> >> itest POM:
> >>
> >> 
> >> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
> >> http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="
> >> http://maven.apache.org/POM/4.0.0
> >> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> >>
> >>
> >>
> >>4.0.0
> >>
> >>
> >>sip-detection
> >>ch.eugster.herakles
> >>0.0.1-SNAPSHOT
> >>
> >>
> >>sip-detector-itest
> >>pom
> >>
> >>sip-detector-itest
> >>sip-detector-itest
> >>
> >>
> >>4.4.0
> >>3.0.3
> >>
> >>
> >>
> >>
> >>ch.eugster.herakles
> >>sip-detector-api
> >>0.0.1-SNAPSHOT
> >>bundle
> >>
> >>
> >>ch.eugster.herakles
> >>sip-detector-matterhorn
> >>${project.version}
> >>bundle
> >>
> >>
> >>ch.eugster.herakles
> >>sip-matterhorn-profile
> >>${project.version}
> >>bundle
> >>
> >>
> >>ch.eugster.herakles
> >>sip-api
> >>${project.version}
> >>bundle
> >>
> >>
> >>ch.eugster.herakles
> >>sip-detection-processor
> >>${project.version}
> >>bundle
> >>
> >>
> >>org.apache.camel
> >>camel-core
> >>
> >>
> >>org.apache.camel
> >>camel-blueprint
> >>
> >>
> >>org.apache.camel
> >>camel-test

Re: Integration Test: Dependency problem

[Christian Eugster]

So I can remove the type tag from dependencies. Is then tag type only used 
once, when introducing a new artifact in tag packaging?

Regards Christian

Christian Eugster
Grissian 14
I-39010 Tisens
I:  +39 0473 420 873
CH: +41 79 107 92 27
christian.eugs...@gmx.net




> Am 27.03.2015 um 17:50 schrieb Stuart McCulloch :
> 
> I see you're declaring dependencies with bundle whereas you
> should just leave them with the default type (jar). While the packaging
> type is "bundle" (to activate the different packaging lifecycle) the
> artifacts produced are declared as type jar and can be referenced as
> dependencies with the default type.
> 
> If you do remove bundle then you likely won't need to add the
> bundle plugin to the top-level plugInManagement (though it is still good
> practice to pin plugin versions in your corporate pom)
> On 27 Mar 2015 16:36, "Christian Eugster"  wrote:
> 
>> Hi,
>> 
>> but as  I understand, the bundles have - as the normal jars - the
>> extension jar, the unique difference are some extra entries in the
>> MANIFEST.MF file. Is that wrong?
>> 
>> I added the frequently used dependencies to the parents pom as managed
>> dependencies and added those required for itest in the itest pom. I added
>> as you proposed the maven-bundle-plugin to the plugin management of the
>> parent pom. So the poms look like:
>> 
>> 
>> sip-detection POM:
>> 
>> 
>> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="
>> http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>>4.0.0
>> 
>>
>>ch.eugster.herakles
>>ingest
>>0.0.1-SNAPSHOT
>>
>> 
>>sip-detection
>>pom
>> 
>>
>>sip-detector-api
>>sip-detector-matterhorn
>>sip-detection-processor
>>sip-detection-features
>>sip-detector-itest
>>  
>> 
>> 
>> 
>> itest POM:
>> 
>> 
>> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
>> http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="
>> http://maven.apache.org/POM/4.0.0
>> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>> 
>>
>> 
>>4.0.0
>> 
>>
>>sip-detection
>>ch.eugster.herakles
>>0.0.1-SNAPSHOT
>>
>> 
>>sip-detector-itest
>>pom
>> 
>>sip-detector-itest
>>sip-detector-itest
>> 
>>
>>4.4.0
>>3.0.3
>>
>> 
>>
>>
>>ch.eugster.herakles
>>sip-detector-api
>>0.0.1-SNAPSHOT
>>bundle
>>
>>
>>ch.eugster.herakles
>>sip-detector-matterhorn
>>${project.version}
>>bundle
>>
>>
>>ch.eugster.herakles
>>sip-matterhorn-profile
>>${project.version}
>>bundle
>>
>>
>>ch.eugster.herakles
>>sip-api
>>${project.version}
>>bundle
>>
>>
>>ch.eugster.herakles
>>sip-detection-processor
>>${project.version}
>>bundle
>>
>>
>>org.apache.camel
>>camel-core
>>
>>
>>org.apache.camel
>>camel-blueprint
>>
>>
>>org.apache.camel
>>camel-test
>>
>>
>>org.apache.camel.karaf
>>apache-camel
>>
>>
>>junit
>>junit
>>test
>>
>>
>>org.ops4j.pax.exam
>>pax-exam-junit4
>>test
>>
>>
>>org.ops4j.pax.exam
>>pax-exam-invoker-junit
>>test
>>
>>
>>org.ops4j.pax.exam
>>pax-exam-container-karaf
>>test
>>
>>
>>org.ops4j.pax.exam
>>pax-exam-inject
>>test
>>
>>
>>org.ops4j.pax.exam
>>pax-exam-extender-service
>>test
>>
>>
>>   

Re: Integration Test: Dependency problem

[Stuart McCulloch]

I see you're declaring dependencies with bundle whereas you
should just leave them with the default type (jar). While the packaging
type is "bundle" (to activate the different packaging lifecycle) the
artifacts produced are declared as type jar and can be referenced as
dependencies with the default type.

If you do remove bundle then you likely won't need to add the
bundle plugin to the top-level plugInManagement (though it is still good
practice to pin plugin versions in your corporate pom)
On 27 Mar 2015 16:36, "Christian Eugster"  wrote:

> Hi,
>
> but as  I understand, the bundles have - as the normal jars - the
> extension jar, the unique difference are some extra entries in the
> MANIFEST.MF file. Is that wrong?
>
> I added the frequently used dependencies to the parents pom as managed
> dependencies and added those required for itest in the itest pom. I added
> as you proposed the maven-bundle-plugin to the plugin management of the
> parent pom. So the poms look like:
>
>
> sip-detection POM:
>
> 
> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 4.0.0
>
> 
> ch.eugster.herakles
> ingest
> 0.0.1-SNAPSHOT
> 
>
> sip-detection
> pom
>
> 
> sip-detector-api
> sip-detector-matterhorn
> sip-detection-processor
> sip-detection-features
> sip-detector-itest
>   
>
> 
>
> itest POM:
>
> 
> http://maven.apache.org/POM/4.0.0"; xmlns:xsi="
> http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation="
> http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>
> 
>
> 4.0.0
>
> 
> sip-detection
> ch.eugster.herakles
> 0.0.1-SNAPSHOT
> 
>
> sip-detector-itest
> pom
>
> sip-detector-itest
> sip-detector-itest
>
> 
> 4.4.0
> 3.0.3
> 
>
> 
> 
> ch.eugster.herakles
> sip-detector-api
> 0.0.1-SNAPSHOT
> bundle
> 
> 
> ch.eugster.herakles
> sip-detector-matterhorn
> ${project.version}
> bundle
> 
> 
> ch.eugster.herakles
> sip-matterhorn-profile
> ${project.version}
> bundle
> 
> 
> ch.eugster.herakles
> sip-api
> ${project.version}
> bundle
> 
> 
> ch.eugster.herakles
> sip-detection-processor
> ${project.version}
> bundle
> 
> 
> org.apache.camel
> camel-core
> 
> 
> org.apache.camel
> camel-blueprint
> 
> 
> org.apache.camel
> camel-test
> 
> 
> org.apache.camel.karaf
> apache-camel
> 
> 
> junit
> junit
> test
> 
> 
> org.ops4j.pax.exam
> pax-exam-junit4
> test
> 
> 
> org.ops4j.pax.exam
> pax-exam-invoker-junit
> test
> 
> 
> org.ops4j.pax.exam
> pax-exam-container-karaf
> test
> 
> 
> org.ops4j.pax.exam
> pax-exam-inject
> test
> 
> 
> org.ops4j.pax.exam
> pax-exam-extender-service
> test
> 
> 
> org.ops4j.pax.exam
> pax-exam-link-mvn
> test
> 
> 
> org.ops4j.pax.exam
> pax-exam-testforge
> test
> 
> 
> org.ops4j.pax.exam
> pax-exam-link-assembly
>

Re: Integration Test: Dependency problem

[Christian Eugster]

I changed the type of the bundles to jar. It does not help.

Regards Christian

Christian Eugster
Grissian 14
I-39010 Tisens
I:  +39 0473 420 873
CH: +41 79 107 92 27
christian.eugs...@gmx.net




> Am 27.03.2015 um 17:35 schrieb Christian Eugster :
> 
> Hi,
> 
> but as  I understand, the bundles have - as the normal jars - the extension 
> jar, the unique difference are some extra entries in the MANIFEST.MF file. Is 
> that wrong?
> 
> I added the frequently used dependencies to the parents pom as managed 
> dependencies and added those required for itest in the itest pom. I added as 
> you proposed the maven-bundle-plugin to the plugin management of the parent 
> pom. So the poms look like:
> 
> 
> sip-detection POM:
> 
> 
> http://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>   4.0.0
> 
>   
>   ch.eugster.herakles
>   ingest
>   0.0.1-SNAPSHOT
>   
> 
>   sip-detection
>   pom
> 
>   
>   sip-detector-api
>   sip-detector-matterhorn
>   sip-detection-processor
>   sip-detection-features
>sip-detector-itest
>  
> 
> 
> 
> itest POM:
> 
> 
> http://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
> 
>
> 
>4.0.0
> 
>
>sip-detection
>ch.eugster.herakles
>0.0.1-SNAPSHOT
>
> 
>sip-detector-itest
>pom
> 
>sip-detector-itest
>sip-detector-itest
> 
>
>4.4.0
>3.0.3
>
> 
>   
>   
>   ch.eugster.herakles
>   sip-detector-api
>   0.0.1-SNAPSHOT
>   bundle
>   
>   
>   ch.eugster.herakles
>   sip-detector-matterhorn
>   ${project.version}
>   bundle
>   
>   
>   ch.eugster.herakles
>   sip-matterhorn-profile
>   ${project.version}
>   bundle
>   
>   
>   ch.eugster.herakles
>   sip-api
>   ${project.version}
>   bundle
>   
>   
>   ch.eugster.herakles
>   sip-detection-processor
>   ${project.version}
>   bundle
>   
>   
>   org.apache.camel
>   camel-core
>   
>   
>   org.apache.camel
>   camel-blueprint
>   
>   
>   org.apache.camel
>   camel-test
>   
>   
>   org.apache.camel.karaf
>   apache-camel
>   
>   
>   junit
>   junit
>   test
>   
>   
>   org.ops4j.pax.exam
>   pax-exam-junit4
>   test
>   
>   
>   org.ops4j.pax.exam
>   pax-exam-invoker-junit
>   test
>   
>   
>   org.ops4j.pax.exam
>   pax-exam-container-karaf
>   test
>   
>   
>   org.ops4j.pax.exam
>   pax-exam-inject
>   test
>   
>   
>   org.ops4j.pax.exam
>   pax-exam-extender-service
>   test
>   
>   
>   org.ops4j.pax.exam
>   pax-exam-link-mvn
>   test
>   
>   
>   org.ops4j.pax.exam
>   pax-exam-testforge
>   test
>   
>   
>   org.ops4j.pax.exam
>   pax-exam-link-assembly
>   test
>   
>   
>   org.apache.karaf.features
>   standard
>   test
>   
>   
>   org.apache.karaf.features
>   org.apache.karaf.features.core
>   test
>   
>   
>   org.apache.karaf.system
>   org.apache.karaf.system.core
>   test
>  

Re: Integration Test: Dependency problem

[Christian Eugster]

Hi,

but as  I understand, the bundles have - as the normal jars - the extension 
jar, the unique difference are some extra entries in the MANIFEST.MF file. Is 
that wrong?

I added the frequently used dependencies to the parents pom as managed 
dependencies and added those required for itest in the itest pom. I added as 
you proposed the maven-bundle-plugin to the plugin management of the parent 
pom. So the poms look like:


sip-detection POM:


http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0


ch.eugster.herakles
ingest
0.0.1-SNAPSHOT


sip-detection
pom


sip-detector-api
sip-detector-matterhorn
sip-detection-processor
sip-detection-features
sip-detector-itest
  



itest POM:


http://maven.apache.org/POM/4.0.0"; 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; 
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
http://maven.apache.org/xsd/maven-4.0.0.xsd";>



4.0.0


sip-detection
ch.eugster.herakles
0.0.1-SNAPSHOT


sip-detector-itest
pom

sip-detector-itest
sip-detector-itest


4.4.0
3.0.3




ch.eugster.herakles
sip-detector-api
0.0.1-SNAPSHOT
bundle


ch.eugster.herakles
sip-detector-matterhorn
${project.version}
bundle


ch.eugster.herakles
sip-matterhorn-profile
${project.version}
bundle


ch.eugster.herakles
sip-api
${project.version}
bundle


ch.eugster.herakles
sip-detection-processor
${project.version}
bundle


org.apache.camel
camel-core


org.apache.camel
camel-blueprint


org.apache.camel
camel-test


org.apache.camel.karaf
apache-camel


junit
junit
test


org.ops4j.pax.exam
pax-exam-junit4
test


org.ops4j.pax.exam
pax-exam-invoker-junit
test


org.ops4j.pax.exam
pax-exam-container-karaf
test


org.ops4j.pax.exam
pax-exam-inject
test


org.ops4j.pax.exam
pax-exam-extender-service
test


org.ops4j.pax.exam
pax-exam-link-mvn
test


org.ops4j.pax.exam
pax-exam-testforge
test


org.ops4j.pax.exam
pax-exam-link-assembly
test


org.apache.karaf.features
standard
test


org.apache.karaf.features
org.apache.karaf.features.core
test


org.apache.karaf.system
org.apache.karaf.system.core
test


org.apache.karaf
apache-karaf
test


javax.inject
javax.inject
test

Re: Integration Test: Dependency problem

[Stuart McCulloch]

The log shows that it’s looking for artifacts with an extension of ‘bundle’, 
whereas the bundle packaging type actually produces artifacts with an extension 
of ‘jar’ - this suggests that the bundle lifecycle extension has not been 
installed for the itest project.

What does the sip-detection pom.xml look like? Have you tried adding 
maven-bundle-plugin to the pluginManagement of that pom.xml with 
true ?

What do the dependency declarations in the itest pom.xml look like?  

On Friday, 27 March 2015 at 08:04, Christian Eugster wrote:

> Hi,
>  
> I am quite new to maven and I have the following problem:
>  
> I have a project with several modules (api and impl) and one of them is an 
> integration test module, that contains only a test class. The pom of this 
> module references (as I see) all dependencies. When I run the parents pom all 
> modules are successfully installed, even the itest module seems to run 
> successfully (as the log says). When I run only the itest module using mvn 
> test I get dependency errors, saying that the other modules could not be 
> found and the run ends with errors (while running the parents pom ends 
> successfully). I checked also the local repository for the compiled jars and 
> all are there. I do not understand what is going wrong. Can anyone give me a 
> hint?
>  
> I am running on yosemite, eclipse juno with m2e (but with mvn form 
> commandline it is the same). Following the log for the parent poms run, that 
> for the itest run
>  
> Thank you in advance for any hints!
>  
> Regards Christian
>  
> The log for parents pom run:
>  
> Christians-Docuteam-MacBook:sip-detection christian$ mvn install
> [INFO] Scanning for projects...
> [INFO] 
> 
> [INFO] Reactor Build Order:
> [INFO]  
> [INFO] sip-detection
> [INFO] sip-detector-api Bundle
> [INFO] sip-detector-matterhorn Blueprint Bundle
> [INFO] sip-detection-processor bundle
> [INFO] sip-detection-features
> [INFO] sip-detector-itest
> [INFO]  
> [INFO] 
> 
> [INFO] Building sip-detection 0.0.1-SNAPSHOT
> [INFO] 
> 
> [INFO]  
> [INFO] --- maven-install-plugin:2.4:install (default-install) @ sip-detection 
> ---
> [INFO] Installing 
> /Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/pom.xml
>  to 
> /Users/christian/.m2/repository/ch/eugster/herakles/sip-detection/0.0.1-SNAPSHOT/sip-detection-0.0.1-SNAPSHOT.pom
> [INFO]  
> [INFO] 
> 
> [INFO] Building sip-detector-api Bundle 0.0.1-SNAPSHOT
> [INFO] 
> 
> [INFO]  
> [INFO] --- maven-resources-plugin:2.7:resources (default-resources) @ 
> sip-detector-api ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory 
> /Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/sip-detector-api/src/main/resources
> [INFO]  
> [INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ 
> sip-detector-api ---
> [INFO] Nothing to compile - all classes are up to date
> [INFO]  
> [INFO] --- maven-resources-plugin:2.7:testResources (default-testResources) @ 
> sip-detector-api ---
> [INFO] Using 'UTF-8' encoding to copy filtered resources.
> [INFO] skip non existing resourceDirectory 
> /Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/sip-detector-api/src/test/resources
> [INFO]  
> [INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
> sip-detector-api ---
> [INFO] No sources to compile
> [INFO]  
> [INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ 
> sip-detector-api ---
> [INFO]  
> [INFO] --- maven-bundle-plugin:2.5.3:bundle (default-bundle) @ 
> sip-detector-api ---
> [INFO]  
> [INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
> sip-detector-api ---
> [INFO] Installing 
> /Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/sip-detector-api/target/sip-detector-api-0.0.1-SNAPSHOT.jar
>  to 
> /Users/christian/.m2/repository/ch/eugster/herakles/sip-detector-api/0.0.1-SNAPSHOT/sip-detector-api-0.0.1-SNAPSHOT.jar
> [INFO] Installing 
> /Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/sip-detector-api/pom.xml
>  to 
> /Users/christian/.m2/repository/ch/eugster/herakles/sip-detector-api/0.0.1-SNAPSHOT/sip-detector-api-0.0.1-SNAPSHOT.pom
> [INFO]  
> [INFO] --- maven-bundle-plugin:2.5.3:install (default-install) @ 
> sip-detector-api ---
> [INFO] Installing 
> ch/eugster/herakles/sip-detector-api/0.0.1-SNAPSHOT/sip-detector-api-0.0.1-SNAPSHOT.jar
> [INFO] Writing OBR metadata
> [INFO]  
> [INFO] 

AW: maven-release-plugin / SVN credentials

[Sebastian Oerding]

Hi Robert,

- I have looked at the Maven SCM project but do not get my problem solved or 
more hints on it
- The maven-release-plugin is locked (with version 2.5, not 2.5.1)
- If running maven with -X according to console no credentials are provided 
when accessing the SVN
- If running maven with -Dusername / -Dpassword the credentials are shown 
(password masked) and it works, however changing the password at least monthly 
for each run configuration / bat file / ... is no real solution
- My colleagues encounter the same problem having switched to SVN 1.8
- How can I get a JIRA account to report a bug?
- I know that SVN really changes from 1.6 to 1.8, maybe this problem stems from 
there?
- I read that  the order of authentication mechanism changes, however trying 
parameter -Dsvnkit.http.methods=Basic,Digest,Negotiate,NTLM did not help
- Does the maven-scm-plugin should be able to access SVN with Windows 7 + 
Active Directory by using the system's Kerberos / NTLM ticket or was there any 
desupport of this feature? 
- I also had the problem after the last password change but somehow managed it 
by doing a single commit with Tortoise, saving the credentials (deleting 
%USER%\AppData\Roaming\Subversion\auth before). Afterwards the maven-release 
worked as expected. Unfortunately this approach seems to work no more. Hence 
how can I check where are the credentials taken from? Is there some additional 
kind of extreme logging besides -e / -X switches?

Thanks in advance,
Sebastian

-Ursprüngliche Nachricht-
Von: Robert Scholte [mailto:rfscho...@apache.org] 
Gesendet: Freitag, 27. März 2015 08:51
An: Maven Users List
Betreff: Re: maven-release-plugin / SVN credentials

Hi Sebastian,

since your issue has to do with svn, one needs to look at the Maven SCM 
project.[1] That's what the maven-release-plugin is using to the commits, tags 
and checkouts.
First ensure you've locked the version of the maven-release-plugin, preferably 
the lastest (i.e. 2.5.1).
If you run the plugin with logging level set to debug (by adding the -X
argument) you'll see the commandline
which is executed. You should be able to do the same (do strip off the cmdshell 
specific part). That should give you the same exception and might give you a 
hint how this could be fixed.

Verify if it is a knows issue in Jira[2], sometimes such issues give extra info.

Verify the SCM Subversion page[3], it also describes some additional 
configuration.

If this can't be solved by commandline, then there's a svnjava implementation 
which you could use[4].

thanks,
Robert

[1] http://maven.apache.org/scm/maven-scm-providers/index.html
[2] http://jira.codehaus.org/browse/SCM/component/11191
[3] http://maven.apache.org/scm/subversion.html
[4]
https://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/wiki/Usage

Op Thu, 26 Mar 2015 08:20:31 +0100 schreef Sebastian Oerding
:

> Hello,
>
> I have a problem with the maven-release-plugin using the SVN 
> credentials (details below). I always get an SVN authorization error. 
> It seems that the release plugin does not use the existing 
> credentials. Unfortunately I'm even not sure whether it is a problem 
> of the maven-release-plugin or SVN. How can I check / get a log which 
> credentials / whether credentials are actually used?
>
> Please explain me how an installed SVN is used (SlikSvn and Tortoise 
> SVN installed, both with version 1.8 of the subversion protocol).
>
> Details:
> I'm in a company where we have Windows 7, 64 bit systems and an Active 
> Directory for Single Sign On (This Windows Kerberos / NTLM like stuff).
>
> The maven-release-plugin worked fine until switching from subversion 
> 1.6 to subversion 1.8. However I had exactly the same problem last 
> month after the monthly password change. Surprisingly I was able to 
> get this solved by making a single commit with Tortoise SVN providing 
> the credentials (and choosing Tortoise to save them). However after my 
> laptop has been renewed the same problem occurs again and I can not 
> solve it using the same trick as before.
>
> Using Google I found a lot of posts on stackoverflow and similar stuff 
> where users report a problem with the maven-release-plugin and SVN 
> credentials. However all of the solutions presented are unacceptable 
> to me or do not solve my problem. For example I can not store my 
> company wide password in some file which is checked into the SVN. 
> Providing the parameters for each invocation of the 
> maven-release-plugin adjusting them every month would also be somehow 
> risky. At least it would be error-prone - every time when I forget to 
> adjust the password after a monthly change I have to rollback the 
> release, clean up the project, adjust the settings and try again.
>
> In my previous setup where I was able to solve the problem by a 
> Tortoise commit I noticed that the SVN credentials persisted under 
> %USER%\AppData\Roaming\Subversion\auth changed. Before there were only 
> empt

Using site even if build fails

[Robert Mark Bram]

Hi all,

I am trying this command line:

mvn --fail-at-end -Plocal verify site

And I find that if an integration test fails, site is *not* being run
at all - even with --fail-at-end. This is my reporting element in
pom.xml:

  

  
org.apache.maven.plugins
maven-surefire-report-plugin
  
  
org.apache.maven.plugins
maven-javadoc-plugin
  

  

Have I misunderstood how site or  --fail-at-end works?

Rob
:)

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

Integration Test: Dependency problem

[Christian Eugster]

Hi,

I am quite new to maven and I have the following problem:

I have a project with several modules (api and impl) and one of them is an 
integration test module, that contains only a test class. The pom of this 
module references (as I see) all dependencies. When I run the parents pom all 
modules are successfully installed, even the itest module seems to run 
successfully (as the log says). When I run only the itest module using mvn test 
I get dependency errors, saying that the other modules could not be found and 
the run ends with errors (while running the parents pom ends successfully). I 
checked also the local repository for the compiled jars and all are there. I do 
not understand what is going wrong. Can anyone give me a hint?

I am running on yosemite, eclipse juno with m2e (but with mvn form commandline 
it is the same). Following the log for the parent poms run, that for the itest 
run

Thank you in advance for any hints!

Regards Christian

The log for parents pom run:

Christians-Docuteam-MacBook:sip-detection christian$ mvn install
[INFO] Scanning for projects...
[INFO] 
[INFO] Reactor Build Order:
[INFO] 
[INFO] sip-detection
[INFO] sip-detector-api Bundle
[INFO] sip-detector-matterhorn Blueprint Bundle
[INFO] sip-detection-processor bundle
[INFO] sip-detection-features
[INFO] sip-detector-itest
[INFO] 
[INFO] 
[INFO] Building sip-detection 0.0.1-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-install-plugin:2.4:install (default-install) @ sip-detection 
---
[INFO] Installing 
/Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/pom.xml
 to 
/Users/christian/.m2/repository/ch/eugster/herakles/sip-detection/0.0.1-SNAPSHOT/sip-detection-0.0.1-SNAPSHOT.pom
[INFO] 
[INFO] 
[INFO] Building sip-detector-api Bundle 0.0.1-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-resources-plugin:2.7:resources (default-resources) @ 
sip-detector-api ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/sip-detector-api/src/main/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ 
sip-detector-api ---
[INFO] Nothing to compile - all classes are up to date
[INFO] 
[INFO] --- maven-resources-plugin:2.7:testResources (default-testResources) @ 
sip-detector-api ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] skip non existing resourceDirectory 
/Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/sip-detector-api/src/test/resources
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:testCompile (default-testCompile) @ 
sip-detector-api ---
[INFO] No sources to compile
[INFO] 
[INFO] --- maven-surefire-plugin:2.18.1:test (default-test) @ sip-detector-api 
---
[INFO] 
[INFO] --- maven-bundle-plugin:2.5.3:bundle (default-bundle) @ sip-detector-api 
---
[INFO] 
[INFO] --- maven-install-plugin:2.5.2:install (default-install) @ 
sip-detector-api ---
[INFO] Installing 
/Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/sip-detector-api/target/sip-detector-api-0.0.1-SNAPSHOT.jar
 to 
/Users/christian/.m2/repository/ch/eugster/herakles/sip-detector-api/0.0.1-SNAPSHOT/sip-detector-api-0.0.1-SNAPSHOT.jar
[INFO] Installing 
/Users/christian/Projekte/ceugster/Entwicklung/Test/Workspace-4.4/herakles/ingest/sip-detection/sip-detector-api/pom.xml
 to 
/Users/christian/.m2/repository/ch/eugster/herakles/sip-detector-api/0.0.1-SNAPSHOT/sip-detector-api-0.0.1-SNAPSHOT.pom
[INFO] 
[INFO] --- maven-bundle-plugin:2.5.3:install (default-install) @ 
sip-detector-api ---
[INFO] Installing 
ch/eugster/herakles/sip-detector-api/0.0.1-SNAPSHOT/sip-detector-api-0.0.1-SNAPSHOT.jar
[INFO] Writing OBR metadata
[INFO] 
[INFO] 
[INFO] Building sip-detector-matterhorn Blueprint Bundle 0.0.1-SNAPSHOT
[INFO] 
[INFO] 
[INFO] --- maven-resources-plugin:2.7:resources (default-resources) @ 
sip-detector-matterhorn ---
[INFO] Using 'UTF-8' encoding to copy filtered resources.
[INFO] Copying 1 resource
[INFO] 
[INFO] --- maven-compiler-plugin:3.2:compile (default-compile) @ 
sip-detector-matterhorn ---
[INFO] Nothing to compile - all classes

Re: Proper way to have my Mojo instrument both main and test classes

[Anders Hammar]

You should have two separate goals (sharing most of hte same
code/functionality though). The end user could specify one single execution
block but specifying both goals in it.

You shouldn't need to know which phase you're in. The onyl thing you're
interested in (in the goal) is the classes to process. So each of the two
goals needs to have a method returning this. Having a look at similar
plugins would give you much of the structure. E.g. the aspectj maven
plugin. Or the jboss aop plugin.

/Anders

On Fri, Mar 27, 2015 at 2:10 AM, offbynull-maven <
offbynull-ma...@offbynull.com> wrote:

> I've written a Maven plugin. When it runs, I want it to process both main
> classes and test classes. I originally thought that setting my mojo's
> defaultPhase to PROCESS_CLASSES would handle this, but I've come to find
> out that PROCESS_CLASSES is only for main classes. There seems to be
> separate phase for test classes: PROCESS_TEST_CLASSES. So, when I do mvn
> clean install, my test classes don't get instrumented but my main classes
> do.
>
> What is the proper way to have a single goal process both test classes and
> main classes? Is there a way to have two default phases? or should I have
> separate goals, one for main classes and one for test classes? or should I
> tell the user to explicitly specify two execution blocks in their pom (one
> for bound to process-classes and the other to process-test-classes -- but
> then how would I find out which phase I'm in so that I can target the
> appropriate directory)?
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: maven-release-plugin / SVN credentials

[Robert Scholte]

Hi Sebastian,

since your issue has to do with svn, one needs to look at the Maven SCM  
project.[1]
That's what the maven-release-plugin is using to the commits, tags and  
checkouts.
First ensure you've locked the version of the maven-release-plugin,  
preferably the lastest (i.e. 2.5.1).
If you run the plugin with logging level set to debug (by adding the -X  
argument) you'll see the commandline
which is executed. You should be able to do the same (do strip off the  
cmdshell specific part). That should give you the same exception and might  
give you a hint how this could be fixed.


Verify if it is a knows issue in Jira[2], sometimes such issues give extra  
info.


Verify the SCM Subversion page[3], it also describes some additional  
configuration.


If this can't be solved by commandline, then there's a svnjava  
implementation which you could use[4].


thanks,
Robert

[1] http://maven.apache.org/scm/maven-scm-providers/index.html
[2] http://jira.codehaus.org/browse/SCM/component/11191
[3] http://maven.apache.org/scm/subversion.html
[4]  
https://code.google.com/a/apache-extras.org/p/maven-scm-provider-svnjava/wiki/Usage


Op Thu, 26 Mar 2015 08:20:31 +0100 schreef Sebastian Oerding  
:



Hello,

I have a problem with the maven-release-plugin using the SVN credentials  
(details below). I always get an SVN authorization error. It seems that  
the release plugin does not use the existing credentials. Unfortunately  
I'm even not sure whether it is a problem of the maven-release-plugin or  
SVN. How can I check / get a log which credentials / whether credentials  
are actually used?


Please explain me how an installed SVN is used (SlikSvn and Tortoise SVN  
installed, both with version 1.8 of the subversion protocol).


Details:
I'm in a company where we have Windows 7, 64 bit systems and an Active  
Directory for Single Sign On (This Windows Kerberos / NTLM like stuff).


The maven-release-plugin worked fine until switching from subversion 1.6  
to subversion 1.8. However I had exactly the same problem last month  
after the monthly password change. Surprisingly I was able to get this  
solved by making a single commit with Tortoise SVN providing the  
credentials (and choosing Tortoise to save them). However after my  
laptop has been renewed the same problem occurs again and I can not  
solve it using the same trick as before.


Using Google I found a lot of posts on stackoverflow and similar stuff  
where users report a problem with the maven-release-plugin and SVN  
credentials. However all of the solutions presented are unacceptable to  
me or do not solve my problem. For example I can not store my company  
wide password in some file which is checked into the SVN. Providing the  
parameters for each invocation of the maven-release-plugin adjusting  
them every month would also be somehow risky. At least it would be  
error-prone - every time when I forget to adjust the password after a  
monthly change I have to rollback the release, clean up the project,  
adjust the settings and try again.


In my previous setup where I was able to solve the problem by a Tortoise  
commit I noticed that the SVN credentials persisted under  
%USER%\AppData\Roaming\Subversion\auth changed. Before there were only  
empty directories, now there is a directory svn.simple which contains a  
text file with the SVN realm, username and so on as expected. The  
password also seems to be fine but I can not definitely say as it is  
encrypted.


Do you have any further hints on that, maybe a SVN mailing list where to  
go?


With kind regards,

Sebastian Oerding

Entwickler

Robotron Datenbank-Software GmbH
Stuttgarter Straße 29
01189 Dresden
sebastian.oerd...@robotron.de
www.robotron.de


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