Re: [ANN] Apache Maven Assembly Plugin 2.5 Released
AS can be seen from http://jira.codehaus.org/browse/MASSEMBLY-722, this can be fixed for 2.5 by adding the following to your pom (these component updates are available in central): plugin artifactIdmaven-assembly-plugin/artifactId ... dependencies dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-archiver/artifactId version2.8.2/version /dependency dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-io/artifactId version2.3.3/version /dependency /dependencies /plugin Or alteranately you could give 2.6-SNAPSHOT (will be 2.5.1) a spin. I will await some feedback on this fix before I stage 2.5.1 for relase. Kristian 2014-10-28 22:03 GMT+01:00 Kristian Rosenvold krosenv...@apache.org: Unfortunately filtering into tar/zip is broken (http://jira.codehaus.org/browse/MASSEMBLY-722), and users of filtering/line endings must use a previous version or wait for 2.5.1, which will be released fairly soon. Kristian 2014-10-27 5:50 GMT+01:00 Kristian Rosenvold kristian.rosenv...@zenior.no: The Apache Maven team is pleased to announce the release of the long-awaited Apache Maven Assembly Plugin, version 2.5. The Assembly Plugin for Maven is primarily intended to allow users to aggregate the project output along with its dependencies, modules, site documentation, and other files into a single distributable archive. Notable in this release is improved file attribute support and full symlink support for java7+ users. Users of filtering/line ending selection should also notice a nice performance improvement. A large number of bugs have also been fixed. http://maven.apache.org/plugins/maven-assembly-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.5/version /plugin Release Notes - Maven Assembly Plugin - Version 2.5 ** Bug * [MASSEMBLY-75] - Unpacked TAR dependencies do not preserve file mode nor uid/gid * [MASSEMBLY-458] - Directory name resolution ignores $ and beyond * [MASSEMBLY-495] - Assembly changes timestamps when extracting dependency sets * [MASSEMBLY-523] - Filtering causes a loss of original unix file permissions * [MASSEMBLY-543] - japanese filenames cannot be correctly assembled by maven-assembly-plugin * [MASSEMBLY-557] - Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted * [MASSEMBLY-563] - JAR entry not found when including jar dependencies with # in classname * [MASSEMBLY-576] - addClasspath broken in new single goal * [MASSEMBLY-605] - Filtering does not work on files which are symlinks * [MASSEMBLY-615] - assembly:single fails with odd resource file name * [MASSEMBLY-622] - Unable to create TAR artifacts * [MASSEMBLY-641] - Assembly fails on resource name with a percent character * [MASSEMBLY-661] - Assembly plugin looses permissions when using fileSets * [MASSEMBLY-670] - Specifying lineEnding option of fileSet causes timestamps not to be preserved * [MASSEMBLY-684] - Parallel Execution w Custom Assembly Descriptor Fails * [MASSEMBLY-692] - Assembly ID is global * [MASSEMBLY-709] - When assembling a zip on windows duplicate files are added to the assembly * [MASSEMBLY-721] - Failing ITs for Maven 2.2.1 ** Improvement * [MASSEMBLY-479] - Add option to generate Posix tar files. * [MASSEMBLY-530] - Allow configuration of encoding * [MASSEMBLY-638] - [PATCH] Support tgz and tbz2 formats in assemblies * [MASSEMBLY-673] - Add support for delimiters and useDefaultDelimiters like the maven-resources-plugin 2.4 has * [MASSEMBLY-688] - Use maven-invoker-plugin 1.9 * [MASSEMBLY-705] - Removed compatibility with Maven 2.0.X * [MASSEMBLY-706] - MavenProject/MavenSession Injection as a paremeter instead as a component. * [MASSEMBLY-707] - Remove unnecessary excludes / Cleaning up console output * [MASSEMBLY-710] - Fix RAT Report * [MASSEMBLY-712] - Update version of plexus-archiver to 2.5 * [MASSEMBLY-714] - Update version of plexus-archiver to 2.7.1 * [MASSEMBLY-716] - Update plexus-io from 2.0.9 to 2.3.2 * [MASSEMBLY-719] - Ugrade to plexus-interpolation 1.21 ** New Feature * [MASSEMBLY-717] - Add an option to turn off project filters ** Wish * [MASSEMBLY-343] - add symbolic links managment (java7+ only supported) 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: [pre-verify over deploy]
Many thanks to Barrie. I think what you have clarified is the normal flow of maven practice. The deploy in the context of my previous post means: our developer invoke a mvn deploy command to share the output(bytecode) through the repository so as to shorten the build time of whole project(as its code base is too large). Our goal is modular compiling and packaging. Currently my pain is our developer would deploy broken bytecode to our dev repository and broken others work. Could i define a intermediate repository, everytime they deploy, jenkins will verify it. if pass, then depoy it into dev repository, otherwise, revert the intermediate repository to keep sync with dev repository. Is there a easier way to achieve this? 2014-10-29 13:07 GMT+08:00 Barrie Treloar baerr...@gmail.com: On 29 October 2014 14:00, Fay Wong philip584...@gmail.com wrote: Hi all, Is there any solution to pre-verify the deploy before it actually got into the repository? Take this usecase for example: In a team of 40 developer, every developer will deploy their module at any time, once there's a error, the final output software won't work and blocks other developer's flow. So is there any pre-verify solution(such as jenkins CI-server) to be enforced before the deploy overlapped the previous deploy? Not really, this is a process issue. You need to decide what is in a state of flux, and then when people should consume it. I'm assuming by deploy you mean a released artifact and not a snapshot one. Generally, you should not be deploying your snapshots for consumption by other developers, as snapshots could break at any time and you impact anyone who depends upon them. Instead, when a developer needs a snapshot version they check out the code and building it themselves, then when they need to import new changes they pull in the changes to the code and rebuild. That way the developer gets to choose when they will consume potentially breaking changes. If these are released artifacts then you have lots of choices on how to do this. *) By using your version control system and some form of isolation (e.g. branches). When the new version is released the developer still needs to pull those changes in, and if there are breaking changes can revert back to the previous version. *) Have someone in a QA role validate that the artifact works prior to promoting that version in you parent pom. The act of deploying into your Maven Repository is independent from the consumption of that artifact, it shouldn't be breaking peoples build until they start using it.
Re: [pre-verify over deploy]
On 29 October 2014 18:48, Fay Wong philip584...@gmail.com wrote: Many thanks to Barrie. I think what you have clarified is the normal flow of maven practice. The deploy in the context of my previous post means: our developer invoke a mvn deploy command to share the output(bytecode) through the repository so as to shorten the build time of whole project(as its code base is too large). Our goal is modular compiling and packaging. Currently my pain is our developer would deploy broken bytecode to our dev repository and broken others work. Could i define a intermediate repository, everytime they deploy, jenkins will verify it. if pass, then depoy it into dev repository, otherwise, revert the intermediate repository to keep sync with dev repository. Is there a easier way to achieve this? There is the stick, or the carrot. The paid version of Nexus (a Maven Repository Manager) has staging repositories, I dont use them, you may be able to get them to do what you want. Either way its a process issue. Teach your developers to stop breaking the build. Or use one of the options I've suggested.
Re: [pre-verify over deploy]
http://developer-blog.cloudbees.com/2012/12/should-you-deploy-snapshots.html On 29 October 2014 08:18, Fay Wong philip584...@gmail.com wrote: Many thanks to Barrie. I think what you have clarified is the normal flow of maven practice. The deploy in the context of my previous post means: our developer invoke a mvn deploy command to share the output(bytecode) through the repository so as to shorten the build time of whole project(as its code base is too large). Our goal is modular compiling and packaging. Currently my pain is our developer would deploy broken bytecode to our dev repository and broken others work. Could i define a intermediate repository, everytime they deploy, jenkins will verify it. if pass, then depoy it into dev repository, otherwise, revert the intermediate repository to keep sync with dev repository. Is there a easier way to achieve this? 2014-10-29 13:07 GMT+08:00 Barrie Treloar baerr...@gmail.com: On 29 October 2014 14:00, Fay Wong philip584...@gmail.com wrote: Hi all, Is there any solution to pre-verify the deploy before it actually got into the repository? Take this usecase for example: In a team of 40 developer, every developer will deploy their module at any time, once there's a error, the final output software won't work and blocks other developer's flow. So is there any pre-verify solution(such as jenkins CI-server) to be enforced before the deploy overlapped the previous deploy? Not really, this is a process issue. You need to decide what is in a state of flux, and then when people should consume it. I'm assuming by deploy you mean a released artifact and not a snapshot one. Generally, you should not be deploying your snapshots for consumption by other developers, as snapshots could break at any time and you impact anyone who depends upon them. Instead, when a developer needs a snapshot version they check out the code and building it themselves, then when they need to import new changes they pull in the changes to the code and rebuild. That way the developer gets to choose when they will consume potentially breaking changes. If these are released artifacts then you have lots of choices on how to do this. *) By using your version control system and some form of isolation (e.g. branches). When the new version is released the developer still needs to pull those changes in, and if there are breaking changes can revert back to the previous version. *) Have someone in a QA role validate that the artifact works prior to promoting that version in you parent pom. The act of deploying into your Maven Repository is independent from the consumption of that artifact, it shouldn't be breaking peoples build until they start using it.
JIRA project per Maven Project?
We have a few JIRA projects and many more Maven projects. Some are one-to-one related, in several cases many Maven projects make up a JIRA project. Just wondering how other organisations lay stuff out. Particularly of relevance given Jenkins can operate JIRA projects as it builds releases Maven projects. Thanks, James
Why does reporting exist?
According to: * http://maven.apache.org/plugins/maven-site-plugin/examples/configuring-reports.html * http://maven.apache.org/plugins/maven-checkstyle-plugin/usage.html * http://mojo.codehaus.org/findbugs-maven-plugin/usage.html * http://maven.apache.org/plugins/maven-pmd-plugin/usage.html and possibly others, I need to add reporting plugins to the reporting element of my POM. When I do this and run mvn clean site, I see a lovely web site but none of the reports. If I instead take the plugins from the reporting and put them as plugins of the maven-site-plugin, they all burst to life. Indeed, I can remove the reporting element and nothing is apparently lost. So, can anyone explain what's happening? Thanks, James
ApacheCon EU 2014, Budapest
Hi there, would like to know who will be attending ApacheCon EU 2014, Budapest. Some folks (like local JUGs and other) plan to kidnap Maven developers, make them have some beer or wine, chat and so, so the “kidnappers are curious about attendees :) Also, some personal way for contact (cellphone No, private email or such) would be good to have, if willing, you can send those to me privately. Thanks, ~t~
Re: [pre-verify over deploy]
On 29/10/2014 5:19 AM, Barrie Treloar wrote: On 29 October 2014 18:48, Fay Wong philip584...@gmail.com wrote: Many thanks to Barrie. I think what you have clarified is the normal flow of maven practice. The deploy in the context of my previous post means: our developer invoke a mvn deploy command to share the output(bytecode) through the repository so as to shorten the build time of whole project(as its code base is too large). Our goal is modular compiling and packaging. Currently my pain is our developer would deploy broken bytecode to our dev repository and broken others work. Could i define a intermediate repository, everytime they deploy, jenkins will verify it. if pass, then depoy it into dev repository, otherwise, revert the intermediate repository to keep sync with dev repository. Is there a easier way to achieve this? There is the stick, or the carrot. The paid version of Nexus (a Maven Repository Manager) has staging repositories, I dont use them, you may be able to get them to do what you want. Either way its a process issue. Teach your developers to stop breaking the build. Or use one of the options I've suggested. It is really a human engineering problem: 1) Whoever breaks the build buys the first round of beer or has to buy pizza for the team on Friday. Works for a small team that socializes together. 2) Build Breaker of the month club. Post the picture of the last person to break the build. If it is a widespread problem, offer reward each quarter to people who do not break the build - day-off, lunch with the boss at a good restaurant. Keep a scorecard of who is out and who is still in the running. 3)Track build breaking as a performance indicator when doing assessments. 4) If a person consistently (you can define this) breaks the build, take away their deploy rights so that they have to find someone to deploy their stuff and they will have to prove to that person that it has been tested. Hurts the pride. If no one will deploy their stuff, fire them. The team has lost confidence in their ability to do the work. Or just assign them work that does not affect the build - test data creation, testing UI, etc. Or move to Nexus-Pro. Ron -- Ron Wheeler President Artifact Software Inc email: rwhee...@artifact-software.com skype: ronaldmwheeler phone: 866-970-2435, ext 102 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Client-side SSL certifcates and Maven
Hello, I am trying to get Maven (3.2.2) to work with an instance of Archiva hosted behind a webserver secured with client-side SSL certificates. I have followed the guide at https://maven.apache.org/guides/mini/guide-repository-ssl.html, and imported the server-side SSL certificate into a Java .jks file. The client-side certificate is a PKCS12 file, which works correctly in Firefox and Chromium. I have a simple project that depends on an artifact hosted on my Archiva server. When client-side SSL verification is disabled on the server, `mvn clean install` works as expected, and the dependency is downloaded. But it doesn't work when I activate client-side SSL verification, and try the following command: mvn clean install -Djavax.net.debug=ssl -Djavax.net.ssl.trustStore=PATH_TO_TRUSTDB.jks -Djavax.net.ssl.trustStorePassword= -Djavax.net.ssl.keyStore=PATH_TO_MY_CERT.p12 -Djavax.net.ssl.keyStoreType=pkcs12 -Djavax.net.ssl.keyStorePassword= From what I can see in the output, my .p12 file is read by Maven at the start, as is the trust-store, but it fails to complete requests to the Archiva server, although TLS handshaking appears to work, so the server-side certificate is trusted and accepted. The server throws the 400: No required SSL certificate was sent error message you get when trying to talk to it without a client-side SSL certificate installed. In the server log I am indeed seeing HTTP GET requests from Maven without any client-side SSL certificate, whereas GETs by a browser do show access with the valid certificate there. Any idea why Maven isn't using the client-side SSL certificate passed via -Djavax.net.ssl.keyStoreType? Is there some configuration option I am overlooking? Kind regards, Jeroen Hoek Lable - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
RE: [ANN] Apache Maven Assembly Plugin 2.5 Released
This fixes the issue for me. Thanks Kristian! Cody Fyler Lending Grid Build Team G=Lending Grid Builds (515) – 441 - 0814 -Original Message- From: Kristian Rosenvold [mailto:krosenv...@apache.org] Sent: Wednesday, October 29, 2014 2:21 AM To: Maven Users List Cc: Maven Developers List Subject: Re: [ANN] Apache Maven Assembly Plugin 2.5 Released AS can be seen from http://jira.codehaus.org/browse/MASSEMBLY-722, this can be fixed for 2.5 by adding the following to your pom (these component updates are available in central): plugin artifactIdmaven-assembly-plugin/artifactId ... dependencies dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-archiver/artifactId version2.8.2/version /dependency dependency groupIdorg.codehaus.plexus/groupId artifactIdplexus-io/artifactId version2.3.3/version /dependency /dependencies /plugin Or alteranately you could give 2.6-SNAPSHOT (will be 2.5.1) a spin. I will await some feedback on this fix before I stage 2.5.1 for relase. Kristian 2014-10-28 22:03 GMT+01:00 Kristian Rosenvold krosenv...@apache.org: Unfortunately filtering into tar/zip is broken (http://jira.codehaus.org/browse/MASSEMBLY-722), and users of filtering/line endings must use a previous version or wait for 2.5.1, which will be released fairly soon. Kristian 2014-10-27 5:50 GMT+01:00 Kristian Rosenvold kristian.rosenv...@zenior.no: The Apache Maven team is pleased to announce the release of the long-awaited Apache Maven Assembly Plugin, version 2.5. The Assembly Plugin for Maven is primarily intended to allow users to aggregate the project output along with its dependencies, modules, site documentation, and other files into a single distributable archive. Notable in this release is improved file attribute support and full symlink support for java7+ users. Users of filtering/line ending selection should also notice a nice performance improvement. A large number of bugs have also been fixed. http://maven.apache.org/plugins/maven-assembly-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-assembly-plugin/artifactId version2.5/version /plugin Release Notes - Maven Assembly Plugin - Version 2.5 ** Bug * [MASSEMBLY-75] - Unpacked TAR dependencies do not preserve file mode nor uid/gid * [MASSEMBLY-458] - Directory name resolution ignores $ and beyond * [MASSEMBLY-495] - Assembly changes timestamps when extracting dependency sets * [MASSEMBLY-523] - Filtering causes a loss of original unix file permissions * [MASSEMBLY-543] - japanese filenames cannot be correctly assembled by maven-assembly-plugin * [MASSEMBLY-557] - Corrupted zip created by assembly: extracting the zip forgets certain folders (or throws permission denied errors) possibly because zip index is corrupted * [MASSEMBLY-563] - JAR entry not found when including jar dependencies with # in classname * [MASSEMBLY-576] - addClasspath broken in new single goal * [MASSEMBLY-605] - Filtering does not work on files which are symlinks * [MASSEMBLY-615] - assembly:single fails with odd resource file name * [MASSEMBLY-622] - Unable to create TAR artifacts * [MASSEMBLY-641] - Assembly fails on resource name with a percent character * [MASSEMBLY-661] - Assembly plugin looses permissions when using fileSets * [MASSEMBLY-670] - Specifying lineEnding option of fileSet causes timestamps not to be preserved * [MASSEMBLY-684] - Parallel Execution w Custom Assembly Descriptor Fails * [MASSEMBLY-692] - Assembly ID is global * [MASSEMBLY-709] - When assembling a zip on windows duplicate files are added to the assembly * [MASSEMBLY-721] - Failing ITs for Maven 2.2.1 ** Improvement * [MASSEMBLY-479] - Add option to generate Posix tar files. * [MASSEMBLY-530] - Allow configuration of encoding * [MASSEMBLY-638] - [PATCH] Support tgz and tbz2 formats in assemblies * [MASSEMBLY-673] - Add support for delimiters and useDefaultDelimiters like the maven-resources-plugin 2.4 has * [MASSEMBLY-688] - Use maven-invoker-plugin 1.9 * [MASSEMBLY-705] - Removed compatibility with Maven 2.0.X * [MASSEMBLY-706] - MavenProject/MavenSession Injection as a paremeter instead as a component. * [MASSEMBLY-707] - Remove unnecessary excludes / Cleaning up console output * [MASSEMBLY-710] - Fix RAT Report * [MASSEMBLY-712] - Update version of plexus-archiver to 2.5 * [MASSEMBLY-714] - Update version of plexus-archiver to 2.7.1 * [MASSEMBLY-716] - Update plexus-io from 2.0.9 to 2.3.2 * [MASSEMBLY-719] - Ugrade to plexus-interpolation 1.21 ** New Feature * [MASSEMBLY-717] - Add an option to turn off project filters ** Wish * [MASSEMBLY-343] - add symbolic links managment (java7+ only supported) Enjoy, -The Apache Maven team
Re: [pre-verify over deploy]
Hi Fay, Could i define a intermediate repository, everytime they deploy, jenkins will verify it. Why not have Jenkins do your deploys? I.e.: make it so that only Jenkins has deploy permission to your remote repository. So your devs can no longer run mvn deploy from the CLI and expect it to work, but instead just push to master (or whatever integration branch) and then Jenkins runs the build. Once Jenkins does your deploys, you can set up your jobs to test for more stringent conditions before actually doing the deploy. E.g.: $ git clean -fdx $ mvn clean install $ bin/verify-artifacts.sh $ mvn deploy And verify-artifacts.sh does whatever further programmatic testing you need. OTOH, in many cases, you don't need a shell script -- often times, you can get what you need using Maven plugins like Surefire, Failsafe, and Enforcer. If you go that route, it might be enough so that devs running mvn deploy won't deploy bad stuff to the repo by default (unless they are aggressive enough to run e.g. mvn -DskipTests deploy which would be pretty bold). Regards, Curtis On Wed, Oct 29, 2014 at 3:18 AM, Fay Wong philip584...@gmail.com wrote: Many thanks to Barrie. I think what you have clarified is the normal flow of maven practice. The deploy in the context of my previous post means: our developer invoke a mvn deploy command to share the output(bytecode) through the repository so as to shorten the build time of whole project(as its code base is too large). Our goal is modular compiling and packaging. Currently my pain is our developer would deploy broken bytecode to our dev repository and broken others work. Could i define a intermediate repository, everytime they deploy, jenkins will verify it. if pass, then depoy it into dev repository, otherwise, revert the intermediate repository to keep sync with dev repository. Is there a easier way to achieve this? 2014-10-29 13:07 GMT+08:00 Barrie Treloar baerr...@gmail.com: On 29 October 2014 14:00, Fay Wong philip584...@gmail.com wrote: Hi all, Is there any solution to pre-verify the deploy before it actually got into the repository? Take this usecase for example: In a team of 40 developer, every developer will deploy their module at any time, once there's a error, the final output software won't work and blocks other developer's flow. So is there any pre-verify solution(such as jenkins CI-server) to be enforced before the deploy overlapped the previous deploy? Not really, this is a process issue. You need to decide what is in a state of flux, and then when people should consume it. I'm assuming by deploy you mean a released artifact and not a snapshot one. Generally, you should not be deploying your snapshots for consumption by other developers, as snapshots could break at any time and you impact anyone who depends upon them. Instead, when a developer needs a snapshot version they check out the code and building it themselves, then when they need to import new changes they pull in the changes to the code and rebuild. That way the developer gets to choose when they will consume potentially breaking changes. If these are released artifacts then you have lots of choices on how to do this. *) By using your version control system and some form of isolation (e.g. branches). When the new version is released the developer still needs to pull those changes in, and if there are breaking changes can revert back to the previous version. *) Have someone in a QA role validate that the artifact works prior to promoting that version in you parent pom. The act of deploying into your Maven Repository is independent from the consumption of that artifact, it shouldn't be breaking peoples build until they start using it.
Re: [pre-verify over deploy]
On 30 October 2014 08:38, Curtis Rueden ctrue...@wisc.edu wrote: Hi Fay, Could i define a intermediate repository, everytime they deploy, jenkins will verify it. Why not have Jenkins do your deploys? I.e.: make it so that only Jenkins has deploy permission to your remote repository. So your devs can no longer run mvn deploy from the CLI and expect it to work, but instead just push to master (or whatever integration branch) and then Jenkins runs the build. Once Jenkins does your deploys, you can set up your jobs to test for more stringent conditions before actually doing the deploy. E.g.: $ git clean -fdx $ mvn clean install $ bin/verify-artifacts.sh $ mvn deploy And verify-artifacts.sh does whatever further programmatic testing you need. OTOH, in many cases, you don't need a shell script -- often times, you can get what you need using Maven plugins like Surefire, Failsafe, and Enforcer. If you go that route, it might be enough so that devs running mvn deploy won't deploy bad stuff to the repo by default (unless they are aggressive enough to run e.g. mvn -DskipTests deploy which would be pretty bold). Regards, Curtis Whether its Jenkins, or a developer, you've still pushed a release that could break the build. This is where you need some isolation available to your workflow. Stuff breaks - it happens, Fay needs to determine how they want to deal with it.
Not the usual authenticity can't be established post.
I'm trying to use the deploy goal to upload a built library to our local
repository. I get the message:
The authenticity of host 'FQDN' can't be established.
followed by a request for a password, despite the fact that I should be
using a private key to authenticate. I googled round and found about 1,000
people getting the same message, and in every case someone has explained
about ~/.ssh/known_hosts and it's solved their problem... but that doesn't
seem to be _my_ problem. I have that host in my known_hosts file, and I can
ssh in directly without receiving that message. Unless maven is looking in
the wrong place for my known_hosts file, which would be weird. So I
apologise if this is answered elsewhere in the archives - I couldn't find it
above the noise of people with the same symptoms, but apparently a different
problem.
Some background. I'm using Maven 3.05 on a kubuntu 14.04 machine. My
~/.m2/settings.xml file looks like:
settings xmlns=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/settings-1.0.0.xsd;
servers
server
idNAUMavenRepos/id
usernamemaven-p/username
privateKey/home/rob/.ssh/id_rsa/privateKey
filePermissions644/filePermissions
directoryPermissions755/directoryPermissions
/server
/servers
/settings
That is indeed the location of my private key. The corresponding public key
has been added to /home/maven-p/.ssh/authorized_keys2 on the host specified
('FQDN', in my obviously-doctored error message above. Yes, I have
double-checked that FQDN is exactly the same in all of the places I've
subbed that in.) I can ssh to the repository host as the user maven-p, and
I require no password, nor do I receive any message about being unable to
authenticate the host. I can confirm that the host is in my known_hosts
file with ssh-keygen -F FQDN -f ~/.ssh/known_hosts.
The project I'm trying to deploy has a long and convoluted pom.xml file, but
the relevant distributionManagement section looks like:
distributionManagement
repository
idNAUMavenRepos/id
urlscp://FQDN/home/maven-p/public_html/repository/url
/repository
/distributionManagement
When I run mvn with the deploy goal (and the debug flag on) I get a ton of
output, but the relevant bits seem to be:
Apache Maven 3.0.5
Maven home: /usr/share/maven
Java version: 1.7.0_25, vendor: Oracle Corporation
Java home: /usr/local/lib/jdk1.7.0_25/jre
Default locale: en_US, platform encoding: UTF-8
OS name: linux, version: 3.13.0-37-generic, arch: amd64, family:
unix
...
[DEBUG] Using connector WagonRepositoryConnector with priority 0 for
scp://FQDN/home/usr3/maven-p/public_html/repository as maven-p
Uploading:
scp://FQDN/home/maven-p/public_html/repository/edu/nau/scan/NatTrack/1.1.3/NatTrack-1.1.3.jar
The authenticity of host 'FQDN' can't be established.
RSA key fingerprint is a3:67:ef:52:ee:ad:11:c4:8e:7a:b1:8c:43:58:10:1a.
Are you sure you want to continue connecting? (yes/no):
Uploading:
scp://FQDN/home/maven-p/public_html/repository/edu/nau/scan/NatTrack/1.1.3/NatTrack-1.1.3.pom
[INFO]
[INFO] BUILD FAILURE
[INFO]
[INFO] Total time: 8:37.194s
[INFO] Finished at: Wed Oct 29 15:13:47 MST 2014
[INFO] Final Memory: 18M/239M
[INFO]
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy (default-deploy) on
project NatTrack: Failed to deploy artifacts: Could not transfer artifact
edu.nau.scan:NatTrack:jar:1.1.3 from/to NAUMavenRepos
(scp://FQDN/home/maven-p/public_html/repository): Cannot connect. Reason:
Session.connect: java.net.SocketException: Broken pipe - [Help 1]
org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute
goal org.apache.maven.plugins:maven-deploy-plugin:2.7:deploy
(default-deploy) on project NatTrack: Failed to deploy artifacts: Could not
transfer artifact edu.nau.scan:NatTrack:jar:1.1.3 from/to NAUMavenRepos
(scp://FQDN/home/maven-p/public_html/repository): Cannot connect. Reason:
Session.connect: java.net.SocketException: Broken pipe
If I've trimmed anything you particularly wanted to see, just let me know;
trying to avoid unnecessarily flooding everyone's inbox.
Its as if the WagonRepositoryConnector is using a different known_hosts file
than my usual one.
--
View this message in context:
http://maven.40175.n5.nabble.com/Not-the-usual-authenticity-can-t-be-established-post-tp5811605.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional
Re: [pre-verify over deploy]
Hi Barrie, Whether its Jenkins, or a developer, you've still pushed a release that could break the build. This is where you need some isolation available to your workflow. Agreed! However, for Fay's stated requirement, it may be sufficient to have a broken master branch as long as the latest deployed SNAPSHOT is not broken, since he stated: Currently my pain is our developer would deploy broken bytecode to our dev repository and broken others work. Regards, Curtis On Wed, Oct 29, 2014 at 5:15 PM, Barrie Treloar baerr...@gmail.com wrote: On 30 October 2014 08:38, Curtis Rueden ctrue...@wisc.edu wrote: Hi Fay, Could i define a intermediate repository, everytime they deploy, jenkins will verify it. Why not have Jenkins do your deploys? I.e.: make it so that only Jenkins has deploy permission to your remote repository. So your devs can no longer run mvn deploy from the CLI and expect it to work, but instead just push to master (or whatever integration branch) and then Jenkins runs the build. Once Jenkins does your deploys, you can set up your jobs to test for more stringent conditions before actually doing the deploy. E.g.: $ git clean -fdx $ mvn clean install $ bin/verify-artifacts.sh $ mvn deploy And verify-artifacts.sh does whatever further programmatic testing you need. OTOH, in many cases, you don't need a shell script -- often times, you can get what you need using Maven plugins like Surefire, Failsafe, and Enforcer. If you go that route, it might be enough so that devs running mvn deploy won't deploy bad stuff to the repo by default (unless they are aggressive enough to run e.g. mvn -DskipTests deploy which would be pretty bold). Regards, Curtis Whether its Jenkins, or a developer, you've still pushed a release that could break the build. This is where you need some isolation available to your workflow. Stuff breaks - it happens, Fay needs to determine how they want to deal with it.
mvn release:branch not updating POM
Good day, I hope someone can assist. Running mvn release:branch -Dbranchname=foo . The problem is that my POM file's SCM connection does not always update to point to my new branch. I ran this command a few times with different branch names. Sometimes the SCM connection updates, other times not. I'm suspecting there is a cache somewhere that is responsible for this behavior, as it only updates the POM at random. Hope this makes sense. :-) -- View this message in context: http://maven.40175.n5.nabble.com/mvn-release-branch-not-updating-POM-tp5811502.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: ApacheCon EU 2014, Budapest
Hi, I'll be there, ready for beer and wine :) Regards, Hervé Le mercredi 29 octobre 2014 13:41:11 Tamas Cservenak a écrit : Hi there, would like to know who will be attending ApacheCon EU 2014, Budapest. Some folks (like local JUGs and other) plan to kidnap Maven developers, make them have some beer or wine, chat and so, so the “kidnappers are curious about attendees :) Also, some personal way for contact (cellphone No, private email or such) would be good to have, if willing, you can send those to me privately. Thanks, ~t~ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [pre-verify over deploy]
2014-10-30 6:15 GMT+08:00 Barrie Treloar baerr...@gmail.com: On 30 October 2014 08:38, Curtis Rueden ctrue...@wisc.edu wrote: Hi Fay, Could i define a intermediate repository, everytime they deploy, jenkins will verify it. Why not have Jenkins do your deploys? I.e.: make it so that only Jenkins has deploy permission to your remote repository. So your devs can no longer run mvn deploy from the CLI and expect it to work, but instead just push to master (or whatever integration branch) and then Jenkins runs the build. Once Jenkins does your deploys, you can set up your jobs to test for more stringent conditions before actually doing the deploy. E.g.: $ git clean -fdx $ mvn clean install $ bin/verify-artifacts.sh $ mvn deploy And verify-artifacts.sh does whatever further programmatic testing you need. OTOH, in many cases, you don't need a shell script -- often times, you can get what you need using Maven plugins like Surefire, Failsafe, and Enforcer. If you go that route, it might be enough so that devs running mvn deploy won't deploy bad stuff to the repo by default (unless they are aggressive enough to run e.g. mvn -DskipTests deploy which would be pretty bold). Regards, Curtis Whether its Jenkins, or a developer, you've still pushed a release that could break the build. This is where you need some isolation available to your workflow. Stuff breaks - it happens, Fay needs to determine how they want to deal with it. This is where you need some isolation available to your workflow. Yes. Some other human engineering way(such as buys the first round of beer) maybe can't solve this issue. I do need some defensive isolation to prevent some guy from blocking others' develop process. Why not have Jenkins do your deploys? Maybe there's another process constraint i forget to mention: The integration of source code bytecode(the build output) follow different flow and can't keep sync with each other. If they keep sync with each other, Jenkins can do the right work.
