Re: release of git folder
Mark, we are using maven 3.0.4 and encounter the same issue, it must have been introduced before Alejandro Endo | Software Designer/Concepteur de logiciels From: Mark Derricutt m...@talios.com To: Maven Users List users@maven.apache.org, Date: 2014-10-27 17:50 Subject:Re: release of git folder On 25 Oct 2014, at 23:05, Robert Scholte wrote: the only workaround I can think of is specifying the developerConnection in this project as well. I was meaning to post about this bug the other week - which we came across when working on the tiles-maven-plugin - this was introduced in the DefaultInheritanceAssemble somewhere in 3.1.x cycle. For some reason - for every parent in the chain it appends the artifactId to the parents SCM section fields ( connection, developerConnection etc. ). -- Mark Derricutt http://www.theoryinpractice.net http://plus.google.com/+MarkDerricutt http://twitter.com/talios http://facebook.com/mderricutt [attachment signature.asc deleted by Alejandro Endo/MontrealMIR/BeldenCDT] DISCLAIMER: Privileged and/or Confidential information may be contained in this message. If you are not the addressee of this message, you may not copy, use or deliver this message to anyone. In such event, you should destroy the message and kindly notify the sender by reply e-mail. It is understood that opinions or conclusions that do not relate to the official business of the company are neither given nor endorsed by the company. Thank You.
Re: release of git folder
AFAIK it has always been like this since the first Maven 2 releases. And it's not just both the connections, but also the siteURL. So maybe they have the same symptoms, but I think it is a different issue. Robert Op Tue, 28 Oct 2014 15:01:45 +0100 schreef alejandro.e...@grassvalley.com: Mark, we are using maven 3.0.4 and encounter the same issue, it must have been introduced before Alejandro Endo | Software Designer/Concepteur de logiciels From: Mark Derricutt m...@talios.com To: Maven Users List users@maven.apache.org, Date: 2014-10-27 17:50 Subject:Re: release of git folder On 25 Oct 2014, at 23:05, Robert Scholte wrote: the only workaround I can think of is specifying the developerConnection in this project as well. I was meaning to post about this bug the other week - which we came across when working on the tiles-maven-plugin - this was introduced in the DefaultInheritanceAssemble somewhere in 3.1.x cycle. For some reason - for every parent in the chain it appends the artifactId to the parents SCM section fields ( connection, developerConnection etc. ). - 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
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
[pre-verify over deploy]
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? Thanks, faywong
Re: [pre-verify over deploy]
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.
