Re: Sub modules and goals
I suspect we could add that trick to mrm-maven-plugin with a little code... then you'd have mvn mrm:stage-start clean deploy mrm:stage-commit mrm:stage-start would set the altDeploymentRepository property to redirect the deploy to mrm, and then mrm:stage-commit would push them to the root pom's distribution management url... (more fancy would be to push to each projects dist mgmt) Probably take me a couple of hours if only I had the bandwidth! -Stephen On 5 April 2012 05:40, Anders Hammar and...@hammar.net wrote: First, you don't need to execute mvn clean install deploy. Just execute mvn clean deploy. The feature of deploying only if ALL artifacts build ok is something you need to look for in a repo manager. In Nexus you can use the staging feature in the Pro version for this (there is planned support for Snapshots which I believe will be part of the next version). I *think* Artifactory has a similar feature, or at least some plugin for Hudson that will do what you want. If you need more detailed info I suggest asking on their mailing lists. On Thu, Apr 5, 2012 at 05:11, Rajwinder Makkar rmakkaroff...@gmail.com wrote: Here is a scenario : I have one maven project which has sub modules defined in the root pom. So maven starts with root pom and then it hits module tag and start compiling the sub modules. goals i use are clean install deploy. What is happening here lets say root pom has 5 module and first one gets compiled and then deployed to remote maven repo then second one gett compiled and get deployed and lets assume it fails on 3rd module. So basically althoguh end of the day build fails but still it updates the remote maven repo that compiled fine. I deally if build fails then it should not deploy any thing. Is it configurable some how that maven compiles all modules and then only it deploy if successful ? -Raj - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Pom files organization / best practice
best practice is *never* to put repository in your pom. best practice is to run a Maven Repository Manager (there are 3 good ones: [in alphabetical order] archivia, artifactory, nexus) best practice is to have those present a virtual repository that is an aggregate of all the repositories you need. Then in your settings.xml you do mirror idmy-mrm/id urlyour virtual repository/url mirrorOf*/mirrorOf /mirror Then Maven will only use your mirror. Fast builds, reliable builds, reproducible builds, you have control over the infra. Anything else is a path to folly On 3 April 2012 11:55, Bata Degen bat...@arcor.de wrote: Hi list, I have set up a Java Enterprise project with Maven in Netbeans. The pom.xml files are organized hierarchically. I have poms for the entire project, for the ejb, the web and the assembly (ear) part of the project. I don't know in which of these many pom files to place my repository elements. Shall they be placed in the root pom or in the pom of the particular module where they are needed or does it make no difference? Is there a best practice for that? Thanks for your advice! Bata - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: There is a way to override distributionManagement in Maven
Take a step back and try and explain exactly what the problem is that you think you are trying to solve. I have a sneaky feeling you are trying to get functionality similar to staging/promotion available from the good repository managers (iirc nexus free does not, but nexus pro and artifactory certainly have the capability, I would need to check archivia, but I suspect it might) On Tuesday, 27 March 2012, jose.nunez-zul...@barclays.com wrote: Hello Maven users, I have a project master pom.xml with a distribution management section defined like this: distributionManagement repository idone/id nameBlah Managed Releases Repository/name urlhttp://:8080/archiva/repository/one//url layoutdefault/layout /repository snapshotRepository idsnapshots/id nameBlah Managed Snapshots Repository/name urlhttp://:8080/archiva/repository/snapshots//url uniqueVersiontrue/uniqueVersion layoutdefault/layout /snapshotRepository /distributionManagement I want to be able to override this values on a test and production setup, having the production setting enabled by default; After reading the Maven site it seems than the only way to do this is by using profiles but after some reading on this list it seems than the are not a good choice (many caveats). There is a cleaner way to achieve this? Can someone point me to some examples? I'm not sure what to put where Thanks in advance, --Jose Barclays is one of the world's leading banks, and we believe that by continuing to integrate the organisation we can better deliver the full power of Barclays to customers, clients and the communities in which we work. As a visible sign of that integration we are moving to a single Barclays brand for the majority of our divisions, including those formerly known as Barclays Capital, Barclays Wealth and Barclays Corporate. ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays offers premier investment banking products and services to its clients through Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___
Re: dependency plugin versus the reactor
Iirc the latest version does, but older versions didn't (except with m3 where the older versions might also pull from reactor) On Wednesday, 28 March 2012, Benson Margulies bimargul...@gmail.com wrote: Does dependency:copy (note, not copy-dependencies) interact with the reactor? In a multi-module project, can a project consume the output of one of its predecessors this way? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: There is a way to override distributionManagement in Maven
and what is exactly wrong with mvn -DaltDeploymentRepository=id::default::url deploy ? no change to pom required On 28 March 2012 14:35, Lyons, Roy roy.ly...@cmegroup.com wrote: Actually, this makes some sense to me. If you really want to test out your build scripts, but do not want to make actual changes to the corporate repo, you would want to instead publish to a temporary area. You don't actually want to disable the deploy but you don't want it overwriting your current binaries since Java was so awesome as to always create binaries with a new md5sum (AWESOME feature let me tell you...). I would be interested in the outcome of this as well, since at the moment our only way of setting up a test environment is to create entirely new code repos and update poms. Of course code and poms get out of date -- so unexpected goodness has the ability to creep up on us during production builds. -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Wednesday, March 28, 2012 2:45 AM To: Maven Users List Subject: Re: There is a way to override distributionManagement in Maven Take a step back and try and explain exactly what the problem is that you think you are trying to solve. I have a sneaky feeling you are trying to get functionality similar to staging/promotion available from the good repository managers (iirc nexus free does not, but nexus pro and artifactory certainly have the capability, I would need to check archivia, but I suspect it might) On Tuesday, 27 March 2012, jose.nunez-zul...@barclays.com wrote: Hello Maven users, I have a project master pom.xml with a distribution management section defined like this: distributionManagement repository idone/id nameBlah Managed Releases Repository/name urlhttp://:8080/archiva/repository/one//url layoutdefault/layout /repository snapshotRepository idsnapshots/id nameBlah Managed Snapshots Repository/name urlhttp://:8080/archiva/repository/snapshots//url uniqueVersiontrue/uniqueVersion layoutdefault/layout /snapshotRepository /distributionManagement I want to be able to override this values on a test and production setup, having the production setting enabled by default; After reading the Maven site it seems than the only way to do this is by using profiles but after some reading on this list it seems than the are not a good choice (many caveats). There is a cleaner way to achieve this? Can someone point me to some examples? I'm not sure what to put where Thanks in advance, --Jose Barclays is one of the world's leading banks, and we believe that by continuing to integrate the organisation we can better deliver the full power of Barclays to customers, clients and the communities in which we work. As a visible sign of that integration we are moving to a single Barclays brand for the majority of our divisions, including those formerly known as Barclays Capital, Barclays Wealth and Barclays Corporate. ___ This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing. Barclays offers premier investment banking products and services to its clients through Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP. This email may relate to or be sent from other members of the Barclays Group. ___ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: generate-sources target called twice
Nothing wrong with using build helper... But *if* you have written a plugin to do your code generation, then the mojo that generates the source code should also add the generated source to the compile class path (projecthelper.addsources iirc) For example I wrote a plugin to generate some code to help event logging, making a LogEvent class that had method signatures matching each event's requiered parameters... After the classes are generated in target/generated-sources/LogEvent/ I then add that path to the compile sources. HTH On Friday, 23 March 2012, Laird Nelson ljnel...@gmail.com wrote: On Tue, Mar 20, 2012 at 7:05 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: if you are writing a plugin yourself, you can add the generated code to the compile classpath from your plugin itself once out of the hacking stage Momentarily hijacking this--could you kindly point towards a doc somewhere that shows how to do this? I have been using the build helper plugin even when NOT hacking; I'd love to know the proper Maven Way here. Best, Laird -- http://about.me/lairdnelson
Re: generate-sources target called twice
On 20 March 2012 10:49, jackett_dad jackett_...@yahoo.com wrote: Anders, I'll look at that, then. This is in the early stages, and I'm following a tutorial on annotation processing, where annotations in code is used to generate code that the compiler will compile on a subsequent pass. If I put the source beneath the target folder, I think the compiler will skip it. build-helper mojo's add sources goal would help you while hacking... if you are writing a plugin yourself, you can add the generated code to the compile classpath from your plugin itself once out of the hacking stage As for my problem of a second invocation of generate-sources, I'm forced for now to keep a flag in a singleton object that is checked before I try to process my sources a second time. This at least gets me beyond my error, but I need to understand why this happened in the first place, and it looks like a complicated issue that requires a deep understanding of maven's cycles. -- View this message in context: http://maven.40175.n5.nabble.com/generate-sources-target-called-twice-tp5577988p5579659.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Which is the BEST Approach to define Global POM.XML
Always depend on a release version Keep in mind that the build must be reproducible, so old releases will build with the parent that was most recent at the time they were released mvn versions:update-parent Is your friend On Friday, 16 March 2012, Daivish Shah daivish.s...@gmail.com wrote: Hi, What if we want to change the version of the corporate POM ? At that time we have to change at all projects to use this ? parent groupIdcom.mosabuam.maven/groupId artifactIdsuper-pom/artifactId version0.1/version /parent We are at the starting stage of MAVEN implementation throughout the COMPANY so we expected to see lot of changes in this project. What is the best practice on that too ? We have to select this project version as SNAPSHOT for all the time ? OR we have to use the RANGE ? Dependency Version Ranges Need to be able to declare minimum, maximum allowed versions of a dependency (both min and max may be optional), and allow holes for known incompatible versions. Proposed syntax: Range Meaning (,1.0] x = 1.0 1.0 Soft requirement on 1.0 (just a recommendation - helps select the correct version if it matches all ranges) [1.0] Hard requirement on 1.0 [1.2,1.3] 1.2 = x = 1.3 [1.0,2.0) 1.0 = x 2.0 [1.5,) x = 1.5 (,1.0],[1.2,) x = 1.0 or x = 1.2. Multiple sets are comma-separated (,1.1),(1.1,) This excludes 1.1 if it is known not to work in combination with this library Mathematical syntax chosen to avoid the use of - as it would conflict with what is used in many version number, and because and = doesn't look nice in XML. (,1.0] is used because infinity is not really helpful here. Default strategy: Of the overlapping ranges, the highest soft requirement is the version to be used. If there are no soft requirements inside the prescribed ranges, the most recent version is used. If that does not fit the described ranges, then the most recent version number in the prescribed ranges is used. If the ranges exclude all versions, an error occurs. Addition of ranges leads to additional necessary specifications on the dependency element. Looking for correct Approach on this. thanks, daivish. On Thu, Mar 15, 2012 at 12:47 PM, Marcin Kuthan marcin.kut...@gmail.com wrote: I hope this example helps: http://code.google.com/p/m4enterprise/source/browse/trunk/corporate-pom/pom.xml Marcin On 14 March 2012 21:29, Daivish Shah daivish.s...@gmail.com wrote: Hi Maven Team, I am trying to find out what is the best way to define company specific GLOBAL POM.XML. Which each team can inherit it in EACH Projects. Can some one provide me guideline on that ? Is that going to be profile or just simple POM.XML ? And how to inherit that. Please provide me guideline to implement it. As this is very critical before we implement all projects with MAVEN. Thanks, Daivish.
Re: Which is the BEST Approach to define Global POM.XML
On 15 March 2012 12:11, Joao Silva joao.si...@vilt-group.com wrote: Hi Anders Thanks, but I already mentioned that blog post in my email. Do you have something to add to that post? Because in my opinion, that post does not offer clear cut conclusions regarding the inclusion of repositories in pom.xml files: /Should I put the urls to my repositories in my poms or in my settings?/ The short answer is: /settings/. The long answer is: /it depends/. For the enterprise scenarios, it may be reasonable to put them in pom.xml files... Nope For enterprise scenarios, you use mirrorOf*/mirrorOf so that *everything* is pulled from your enterprise repository manager. Otherwise you are putting your enterprise at risk of a failure of a 3rd party repository... e.g. what happened when JBoss shut down their old repositories, what happened when those crazy fools hosting their own maven repos on google-code svn repos deleted their projects... You want *everything* in your enterprise repository manager so that you have complete control over your destiny -Stephen Thanks and best regards Joao Silva On 3/15/2012 11:45 AM, Anders Hammar wrote: http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ /Anders On Thu, Mar 15, 2012 at 11:51, Joao Silvajoao.si...@vilt-group.com wrote: Hi Anders Can you provide some arguments to this statement? We currently recommend all our projects tech leads to add to their top level project pom.xml the repositories they use (each individual project tree usually has 3 repositories: releases, snapshots and 3rdparty). Since the projects are worked internally only, this eases new developers and developer rotation in projects. Our recommendation derives mainly from this blog post from the Sonatype blog: http://www.sonatype.com/people/2009/02/why-putting-repositories-in-your-poms-is-a-bad-idea/ If there are aspects of this approach that we are not aware of, it would be great to see them discussed. Thanks for your time! Best regards Joao Silva On 3/15/2012 9:09 AM, Anders Hammar wrote: You should NOT declare repositories (or plugin repositories) in a corporate pom. That should be handled in settings.xml. /Anders On Wed, Mar 14, 2012 at 22:22, Eric Kolotylukeric.koloty...@gmail.com wrote: What I do is have a top-level POM like (see below), and then I have my top level project POMs reference that (see further below). This may not be the best example, as I am still in the process of building the infrastructure, but 1. I put the Parent POM in its own place in source control and I manually deploy it with Maven when I make changes. 2. You need to do this before creating any Project POMs that reference it because they should reference it via Maven and not the file system - if you work in a large company you will soon discover why. 3. There is of course a bootstrapping issue because now the project POMs need to know how to find your Repository Manager, which is why I include that information in the top level (Corporate) POM so people can use it as a reference. 4. As you may gather I am using Sonatype's Nexus as a Repository Manager. 5. We are still developing our corporate repository infrastructure so the content of the Corporate POM will evolve over time as our corporate governance and policies are better codified. Does that help? ?xml version=1.0 encoding=UTF-8? project 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/maven-4.0.0.xsd; !-- Copyright Š My Company 2012 Proprietary Confidential This is the top level POM for My Company Maven projects. It contains rules and standards common to all projects. Changes: 2011-09-23 0.0.1-SNAPSHOT Eric Kolotyluk Created initial version for check-in into source control. 2012-02-27 0.0.1-SNAPSHOT Eric Kolotyluk Reconfigured for Nexus 2.0 on sonatype. -- modelVersion4.0.0/modelVersion groupIdcom/groupId artifactIdmy-company/artifactId version0.0.1-SNAPSHOT/version packagingpom/packaging nameMy Company Corporate POM/name descriptionCorporate Project Object Module for standard conventions and rules./description developers developer id10069959/id nameEric Kolotyluk/name emaileric.koloty...@gmail.com/email organizationMy Company Ltd./organization timezoneVancouver PDT/timezone roles roleSoftware Architect/role roleSoftware Developer/role /roles /developer /developers organization nameMy Company/name /organization distributionManagement downloadUrlhttp://sonatype:8081/nexus/content/groups/public/downloadUrl repository uniqueVersionfalse/uniqueVersion idnexus/id nameMy Company Release Repository/name urlhttp://sonatype:8081/nexus/content/repositories/releases/url layoutdefault/layout /repository
Re: Is it possible to tie current git branch to project version?
properties cannot be used where they will affect the build plan.
Therefore the following xpaths are not allowed (it may appear to work,
but it will blow up in your face when you are not looking)
/project/parent/*
/project/groupId
/project/artifactId
/project/version
almost anywhere else is fair game
On 7 March 2012 15:18, Seth Call sethc...@gmail.com wrote:
Hi Roy,
I don't understand what 'tagging our repo' means. Is this a feature of
your remote repository? Sorry... I googled but I don't know what you are
saying...
But aside from that, I really don't care about git hash in this question...
let me explain what I'm trying to acheive...
As a developer:
* If I'm on branch master, I want my project version to be master-SNAPSHOT
* If I'm on branch development, I want my project version to be
development-SNAPSHOT
I'd like that to happen automatically when I make the branch; I know this
is rather dynamic so I assume a plugin at a minimum is required. I'm also
not interested in using git local hooks if at all avoidable because they
have their own drawbacks.
This versioning scheme is very important; making a branch is making a new
version. So, downstream projects that depend on my project:master-SNAPSHOT
should *not* pickup my new branch's build artifact-not unless, of course, I
go to that downstream project and change it's dependency version to say
project:development-SNAPSHOT.
In summary, they are different versions, and so if you don't version your
project as you make a branch, then you will now have indeterminate build
resolution because 'the-last-branch-you-build-will-win' sort of problems.
Also, all of this should work locally (not require a build server), so I'm
limiting myself to maven-only techniques...
Any help is greatly appreciated. I hope there is some way to achieve this
that I'm just not thinking of...
But if anyone can say definitively that you can not put a variable in the
version tag of an artifact, then I at least know a plugin-based solution
is not an option.
Regards,
Seth
On Wed, Mar 7, 2012 at 6:00 AM, Lyons, Roy [via Maven]
ml-node+s40175n5543915...@n5.nabble.com wrote:
:-) we tag our repo with branchname!RP-BL-mavenlabel to help in
location. Rp is for release prepare and bl is for baseline (carryover from
clearcase terminology)
Just remember that in git a hash doesn't belong to a branch, it is simply
attached to a linked list of hashes. A branch is simply a tag pointing
to a hash being designated as a head. You can just as easily use the tag
created by the release plugin to checkout, and then make some bugfix branch
from that location.
Sent from my Blackberry.
- Original Message -
From: Seth Call [hidden
email]http://user/SendEmail.jtp?type=nodenode=5543915i=0
To: [hidden email]
http://user/SendEmail.jtp?type=nodenode=5543915i=1[hidden
email] http://user/SendEmail.jtp?type=nodenode=5543915i=2
Sent: Tue Mar 06 22:01:07 2012
Subject: Is it possible to tie current git branch to project version?
Hi there,
I've seen indication when searching the internet that it isn't possible to
put variables in version of a project (unless those variables are
hardcoded properties or provided at the command line), but I thought I'd
ask the list ...
Say there was a plugin that would invoke 'git branch' to determine the
current branch, and to then make that available to the project as a
variable; call it ${branch}. I'd like to use this variable then in the
version tag:
project
groupIdblah/groupId
artifactIdblah/artifactId
version${branch}-SNAPSHOT/version
/project
The reason I want to do this is that I'm realizing, for our internal-only
code projects, that a branch is always synonymous with a version of a
project, and ideally the act of being of switching branches would be all
it
takes to switch your maven project's version.
Is this possible if I were to make a maven plugin?
Thanks!
Seth
--
View this message in context:
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543110.html
Sent from the Maven - Users mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [hidden
email]http://user/SendEmail.jtp?type=nodenode=5543915i=3
For additional commands, e-mail: [hidden
email]http://user/SendEmail.jtp?type=nodenode=5543915i=4
-
To unsubscribe, e-mail: [hidden
email]http://user/SendEmail.jtp?type=nodenode=5543915i=5
For additional commands, e-mail: [hidden
email]http://user/SendEmail.jtp?type=nodenode=5543915i=6
--
If you reply to this email, your message will be added to the discussion
below:
http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5543915.html
To unsubscribe from Is it
Re: Is it possible to tie current git branch to project version?
My view is that there are places where stuff can be inferred, such as groupId and version of children can be inferred *if and only if* the child is always checked out with the parent (at the specified relative path)... There are plans to tackle those cases. There is, though a bit of a dual purpose to the Pom... One which may have to be split... On the one hand the deployed Pom should be fully resolved, and properties at those xpaths won't work... On the other hand, for inheritance to work we need the deployed Pom to be fully unresolved... From my point of view, those xpaths should never allow property expansion, but more smarts in inferring based on other Pom files would be good... Version numbers coming from a SCM branch name is a bad smell to me... So I would not favour without a very good case being made On Wednesday, 7 March 2012, Seth Call sethc...@gmail.com wrote: Hi Stephen, Thank you for clarifying. That tells me what constraints I have to work with, which is a big help. Is there any intent to change these restrictions? I don't think anyone wants to change version mid-run (I've seen in other threads where you mention something about the reactor getting confused if the version were to change mid-run?), but I think there is a desire to change it 'at the start' of maven process execution in a more dynamic-yet-friendly way than just 'pass it in via command line'. The desire here, to be clear, is to give developers a correct default behavior when they type 'mvn clean install', and to never force them to type -Dproject.version = something-wrong Matt (posted after you) wanted to do something similiar point with the buildnumber plugin, too. Seth -- View this message in context: http://maven.40175.n5.nabble.com/Is-it-possible-to-tie-current-git-branch-to-project-version-tp5543110p5545298.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: Is it possible to tie current git branch to project version?
On 7 March 2012 20:59, Seth Call sethc...@gmail.com wrote: Bad smell eh? Ok, here's my bad smell. Version numbers. Stinkier? Version *numbers* in source code. More stinky than that? Version numbers in source code for projects that are never released to the public. You are confusing two concepts: * version names - these are the marketing numbers associated with a product * version numbers - these are the internal development defined version numbers there may be many builds each with a different version number but tagged with the same version name... at the end of the day, only one of those version numbers will be released, so that the public sees a 1:1 but actually behind the scenes there is a N:1 I care most about the development process, and much less about the release process. If the release process is hard, that's an OK trade-off if the day-to-day development process is easy (1 release guy, 15 developers). Also, I'd argue that version numbers are usually entirely artificial, and are actually a marketing/end-user construct, and having nothing to do with source code. That is version names you are thinking of. (ideally, they can be applied at a packaging phase, but having nothing to do with compiling/building day-to-day). Firefox went from 'normal versioning' to a major-release-every-month because they *can*. It has no tie in to anything in reality other than user expectations. I'm a git user, and because git allows branching so easily, it allows expression of version in a very developer-friendly; through their branch. If you are using git, every time you branch, you have just said, 'I made a version'. And if your poms don't reflect that, then you have interesting new problems arise (like a build server that tracks two branchs with the same version in the pom, meaning 'last-build-of-either-branch-wins' for SNAPSHOT. That's no good, right?). Well here is the rub... say you checkout 1a2b3c4d build that... according to you that would be version 1a2b3c4d-SNAPSHOT? or would it be 1a2b3c4d modify some one file and don't check in... build it again... what is it now? it's not 1a2b3c4d because you cannot reproduce it... so it would have to be 1a2b3c4d-SNAPSHOT except it's not that either, because -SNAPSHOT implies it will eventually become 1a2b3c4d which it cannot as you are working on the next revision which is likely 9f8e7d6c only we cannot know that... and in git both branches and tags are completely mutable and just pointers... can't use them... I think you need to think about this a little more. To be clear, when I talk about 'version numbers', I'm not talking about build numbers. Never thought you were. So in my ultimate desired versioning scheme, I'd like to version every last one of our projects this way, expressed as artifact names: Remote Repository (Artifactory, etc) would only have artifacts named: $company:$git-repository:$branch-$buildnumber $company:$git-repository:$branch-SNAPSHOT I suspect that you don't fully understand how git branches work... but I am willing to be proved wrong ;-) branch names are not canonical... I can call it anything I like on my side... git push -u origin trunk:master oh look locally my branch is called trunk because I don't like calling it master... oh look fred's local name for the master branch is called fubar totally mutable example: acme:project-A:master-234 acme:project-A:master-SNAPSHOT acme:project-B:master-100 acme:project-B:master-SNAPSHOT Local Repository would only have artifacts named: $company:$git-repository:$branch-local example: acme:project-A:master-local acme:project-B:master-local Now how would I use this scheme? Usage 1) I'm a project-B developer, and I *haven't checked* out project-A. I don't want to force developers to check out code that I don't need to complete a task. Project-B depends on project-A. Most of the time, I want my dependency to look like this: dependency groupIdacme/groupId artifactIdproject-A/artifactId versionmaster-SNAPSHOT/version /dependency translation: whatever the latest build on master is, I want it from the remote repository. I want to have project-B float forward with project-A, and I don't want to actively maintain that relationship. Usage 2) If I want to use a particular build: versionmaster-234/version git tags do not increase as they are hashes, so you cannot use the hash to determine sequencing. translation: someone broke project-A:master-235 and above. I need to pin my version to avoid this bug. Or maybe I'm working on a release variant of project-B, and I need to pin my project-A dependency. In either case, I'm still using the remote repository to resolve project-A artifacts. Usage 3) If I want to checkout project-B, make a local-only code change, 'mvn install' it, then I can use MY version by updating my dependency to: versionmaster-local/version translation: project-A has a bug or feature I
Re: EAR project produces application.xml, but EJB module is missing
Because ejb type maps to jar extension On Sunday, 4 March 2012, Markus KARG mar...@headcrashing.eu wrote: You are right, when adding typeejb/type it is working! I missed the fact that maven coordinates include the packaging, while the default packaging is typejar/type. The odd thing is that dependency resolution is working without that. So it actually seems, module resolution is working correctly while dependency resolution ignores type. Thanks a lot! Markus -Original Message- From: Stephen Coy [mailto:st...@resolvesw.com] Sent: Sonntag, 4. März 2012 09:44 To: Maven Users List Subject: Re: EAR project produces application.xml, but EJB module is missing The number one reason I've had this problem in the past is forgetting to specify: typeejb/type in the dependency declarations for EJB jars. On 04/03/2012, at 2:33 AM, Markus KARG wrote: Maven 3.0.4 is producing application.xml containing module entries for some dependencies (RAR modules), but which is missing module entries for other dependencies (EJB modules). This is weird as the pom more or less is empty. It just contains the dependencies (RAR modules and EJB modules) and Java EE version (6). So I assume one cannot do wrong. Is that a bug in Maven or what the heck is the trick to get module entries for EJB modules? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to deploy with 'classifier'
Argh
You're doing it wrong.
The JAR/WAR/EAR/etc should be independent of the environment in which
it works. If you want to bundle default properties for when no
properties file is to be found, that is fine. But it is a great
ANTI-PATTERN to put environment specific resources into your
artifacts.
Maven is going to fight you all the way.
Here is how you would do things with a .war/.ear file, where there are
a number of options (a subset of the options works for .jar files):
* Use context parameters in the servlet/application container
* Use JNDI to expose the parameters
* Use System properties to expose the configuration
* Put the environment specific parameters in resource files on the classpath
* Use a repackaging script immediately prior to deployment to the
container that unpacks the archive, adds the configuration files, and
repacks it
All of these are considered outside the scope of Maven.
Maven's responsibility for building your artifact ends when it has
delivered an environment independent artifact into the Maven
Repository.
Your responsibility does not end there. To then (I am going to use the
word 'ship' in place of 'deploy' because people confuse maven's use of
'deploy' with application container, and operations teams use of the
word) ship your application, you take the artifact from the Maven
Repository, configure it (if necessary) for the environment in which
it will be shipped and put it into that environment.
If you want Maven to help with that, I would take a look at the
ship-maven-plugin@mojo or the cargo set of plugins... both of which
operate, in this context, outside of the standard Maven lifecycle,
i.e. after Maven has completed its responsibilities.
HTH
-Stephen
On 29 February 2012 00:51, Billy Newman newman...@gmail.com wrote:
So for reasons I don't want to get into I have a jar that is backed by a
properties file. That properties file is different for different
environments. What I want to end up with is something like:
myapi-1.0-dev.jar
myapi-1.0-test.jar
myapi-1.0-ops.jar
Where dev, test, and ops are different flavors of the jar specified by the
classifier.
My real question was is how do I set the classifier such that it would create
one of these. The answer is in the maven-jar-plugin you can set a
configuration with a classifier.
classifier${env}/classifier
Then I setup a Jenkins build that will execute a deploy for each of my
flavors by setting the env property differently for each execution.
env=dev
env=test
env=ops
Then when I or anyone makes changes to the jar they can update the version in
the Pom file and run he Jenkins task to deploy all three flavors. Making them
all available for all groups to grab out of my repository.
Sent from my iPhone
On Feb 28, 2012, at 3:26 PM, Manfred Moser manf...@mosabuam.com wrote:
On Tue, February 28, 2012 2:13 pm, Benson Margulies wrote:
Let me try to arrange the explanation here in good order.
Classifiers were not designed to allow for 'different flavors of one
artifact'. They were designed to allow an artifact to have an
entourage, such as its sources or javadoc.
So, to begin with, there's no way to ask Maven to set a non-
classifier for the main artifact with packaging jar.
Further, there are corner cases of dependency management that will get
you in this case.
The maven model is really that you would use different artifactIds for
the different 'flavors'. You might accomplish this with an aggregating
pom and a bunch of modules, one per flavor, for example.
No it's not entirely satisfactory. This is just not a case that Maven
is designed to support well, and you should seriously consider
alternatives.
While I agree with Benson if you still want to make it happen you could
use the build helper plugin with the attachArtifact goal.
manfred
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to deploy with 'classifier'
On 29 February 2012 14:36, Billy Newman newman...@gmail.com wrote: I have a solution that already works, is what I am really trying to say. Rather than keep it to myself I thought I would reply so that if someone else ran into this solution they might find some help. I understand one build one artifact. I am using Jenkins to initiate multiple builds (one for each env). In each build I specify the classifier that I want to use. This is how I would except a jdk5 vs jdk6 flavor of the jar to work as well. Two builds in Jenkins, one for jdk5 and one for jdk6. Nope... you want two different artifactIds as the jdk5 version has different dependencies than the jdk6 one and different dependencies requires different GAV Sure I could build the jar with the properties then unpack the jar and repack it with the properties but that is an extra step I don't need. And if a properties file in a jar is an anti pattern then it is an anti pattern whether I build the properties file into the jar, or unpack shove it in and repack. Why not just load the properties file from beside wherever the jar is no need to pack it in at all Again my solution works I was just tying to post the fact that I came up with something in case someone else is interested. I did not fight maven, I got it to work with one line in the Pom file to specify a classifier for the jar as a variable. Sent from my iPhone On Feb 29, 2012, at 6:56 AM, Benson Margulies bimargul...@gmail.com wrote: Billy, The functionality in Maven is a fact. Whether you or anyone else thinks that the design *should* have, or *should*, include your use case, it does not. It is the nature of Maven, for better or worse, that attempting to use it 'against the grain' generally leads to a ramifying collection of painful problems. It is not a simple, passive, extensible structure. Using profiles and multiple executions of Maven (see the maven-invoker-plugin) is the only way I can see to get what you want -- roughly. You can then have an additional project that uses the build helper to attach them all with classifiers. Just don't expect much help if this leads you to additional pain if/when you try to use these things as dependencies. On Wed, Feb 29, 2012 at 8:44 AM, Billy Newman newman...@gmail.com wrote: That still does not help. I do not have a war/ear. I have a jar. I is standalone and will not run in a container. Jar will not work without the properties file in which it is backed. There is proprietary info in the different properties files and my company will not let me include certain properties files to certain places. It really is coding by properties as the jar cannot function without the properties, even the unit tests will not run with he properties file. I still see no reason why I cannot tell maven which properties file to build into the jar. When that happens why not label the jar for which env it was intended for? Previously I would build the jar when the system was built, so it would need to be built every time even when there were no code changes. The unit test also ran (which take a while ) again for no reason since there were no code changes. I read: The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number. As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14such that clients can choose which one to use. So if I can kick off two builds one for a jdk5 jar and another for a jdk6 jar both the same version so that the are stored in the same place in the repository but differ by classifier. Then why not kick off a couple builds that are meant for different envs whenever the code changes, bump the version, test the changes and make them all available in the repo? Sent from my iPhone On Feb 29, 2012, at 4:02 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Argh You're doing it wrong. The JAR/WAR/EAR/etc should be independent of the environment in which it works. If you want to bundle default properties for when no properties file is to be found, that is fine. But it is a great ANTI-PATTERN to put environment specific resources into your artifacts. Maven is going to fight you all the way. Here is how you would do things with a .war/.ear file, where there are a number of options (a subset of the options works for .jar files): * Use context parameters in the servlet/application container * Use JNDI to expose the parameters * Use System properties to expose the configuration * Put the environment specific parameters in resource files
Re: How to deploy with 'classifier'
No problem:
Stephen Connolly
Hat #1: Apache Maven Project Management Committee
Hat #2: CloudBees Elite Developer Architect
On 29 February 2012 14:03, Ron Wheeler rwhee...@artifact-software.com wrote:
Great explanation.
Could I put this up on my technical blog where it can be referenced?
This comes up at least once a month and really needs a clear explanation
such as you have given.
If you agree, can you give me an attribution line that I can add to indicate
that you are the author.
If you want to add links or a short description, I would be pleased to
include them.
You can check out the blog at http://blog.artifact-software.com/tech
I would appreciate any comments on the JNDI article or any other article.
I do not get a lot of traffic but at least it is a place to refer people
rather than writing a long note each time.
Ron
On 29/02/2012 6:02 AM, Stephen Connolly wrote:
Argh
You're doing it wrong.
The JAR/WAR/EAR/etc should be independent of the environment in which
it works. If you want to bundle default properties for when no
properties file is to be found, that is fine. But it is a great
ANTI-PATTERN to put environment specific resources into your
artifacts.
Maven is going to fight you all the way.
Here is how you would do things with a .war/.ear file, where there are
a number of options (a subset of the options works for .jar files):
* Use context parameters in the servlet/application container
* Use JNDI to expose the parameters
* Use System properties to expose the configuration
* Put the environment specific parameters in resource files on the
classpath
* Use a repackaging script immediately prior to deployment to the
container that unpacks the archive, adds the configuration files, and
repacks it
All of these are considered outside the scope of Maven.
Maven's responsibility for building your artifact ends when it has
delivered an environment independent artifact into the Maven
Repository.
Your responsibility does not end there. To then (I am going to use the
word 'ship' in place of 'deploy' because people confuse maven's use of
'deploy' with application container, and operations teams use of the
word) ship your application, you take the artifact from the Maven
Repository, configure it (if necessary) for the environment in which
it will be shipped and put it into that environment.
If you want Maven to help with that, I would take a look at the
ship-maven-plugin@mojo or the cargo set of plugins... both of which
operate, in this context, outside of the standard Maven lifecycle,
i.e. after Maven has completed its responsibilities.
HTH
-Stephen
On 29 February 2012 00:51, Billy Newmannewman...@gmail.com wrote:
So for reasons I don't want to get into I have a jar that is backed by a
properties file. That properties file is different for different
environments. What I want to end up with is something like:
myapi-1.0-dev.jar
myapi-1.0-test.jar
myapi-1.0-ops.jar
Where dev, test, and ops are different flavors of the jar specified by
the classifier.
My real question was is how do I set the classifier such that it would
create one of these. The answer is in the maven-jar-plugin you can set a
configuration with a classifier.
classifier${env}/classifier
Then I setup a Jenkins build that will execute a deploy for each of my
flavors by setting the env property differently for each execution.
env=dev
env=test
env=ops
Then when I or anyone makes changes to the jar they can update the
version in the Pom file and run he Jenkins task to deploy all three flavors.
Making them all available for all groups to grab out of my repository.
Sent from my iPhone
On Feb 28, 2012, at 3:26 PM, Manfred Mosermanf...@mosabuam.com
wrote:
On Tue, February 28, 2012 2:13 pm, Benson Margulies wrote:
Let me try to arrange the explanation here in good order.
Classifiers were not designed to allow for 'different flavors of one
artifact'. They were designed to allow an artifact to have an
entourage, such as its sources or javadoc.
So, to begin with, there's no way to ask Maven to set a non-
classifier for the main artifact with packaging jar.
Further, there are corner cases of dependency management that will get
you in this case.
The maven model is really that you would use different artifactIds for
the different 'flavors'. You might accomplish this with an aggregating
pom and a bunch of modules, one per flavor, for example.
No it's not entirely satisfactory. This is just not a case that Maven
is designed to support well, and you should seriously consider
alternatives.
While I agree with Benson if you still want to make it happen you could
use the build helper plugin with the attachArtifact goal.
manfred
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to deploy with 'classifier'
Just because you *can* do something doesn't mean you *should* On Wednesday, 29 February 2012, Billy Newman wrote: So this is not true: http://maven.apache.org/plugins/maven-deploy-plugin/examples/deploying-with-classifiers.html bin is used to describe that the artifact is a binary. dev is used to describe that the artifact is for development. prod is used to describe that the artifact is for production. Seems like this is exactly what I would like to use the classifier for. Sent from my iPhone On Feb 29, 2012, at 9:20 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 29 February 2012 14:36, Billy Newman newman...@gmail.com wrote: I have a solution that already works, is what I am really trying to say. Rather than keep it to myself I thought I would reply so that if someone else ran into this solution they might find some help. I understand one build one artifact. I am using Jenkins to initiate multiple builds (one for each env). In each build I specify the classifier that I want to use. This is how I would except a jdk5 vs jdk6 flavor of the jar to work as well. Two builds in Jenkins, one for jdk5 and one for jdk6. Nope... you want two different artifactIds as the jdk5 version has different dependencies than the jdk6 one and different dependencies requires different GAV Sure I could build the jar with the properties then unpack the jar and repack it with the properties but that is an extra step I don't need. And if a properties file in a jar is an anti pattern then it is an anti pattern whether I build the properties file into the jar, or unpack shove it in and repack. Why not just load the properties file from beside wherever the jar is no need to pack it in at all Again my solution works I was just tying to post the fact that I came up with something in case someone else is interested. I did not fight maven, I got it to work with one line in the Pom file to specify a classifier for the jar as a variable. Sent from my iPhone On Feb 29, 2012, at 6:56 AM, Benson Margulies bimargul...@gmail.com wrote: Billy, The functionality in Maven is a fact. Whether you or anyone else thinks that the design *should* have, or *should*, include your use case, it does not. It is the nature of Maven, for better or worse, that attempting to use it 'against the grain' generally leads to a ramifying collection of painful problems. It is not a simple, passive, extensible structure. Using profiles and multiple executions of Maven (see the maven-invoker-plugin) is the only way I can see to get what you want -- roughly. You can then have an additional project that uses the build helper to attach them all with classifiers. Just don't expect much help if this leads you to additional pain if/when you try to use these things as dependencies. On Wed, Feb 29, 2012 at 8:44 AM, Billy Newman newman...@gmail.com wrote: That still does not help. I do not have a war/ear. I have a jar. I is standalone and will not run in a container. Jar will not work without the properties file in which it is backed. There is proprietary info in the different properties files and my company will not let me include certain properties files to certain places. It really is coding by properties as the jar cannot function without the properties, even the unit tests will not run with he properties file. I still see no reason why I cannot tell maven which properties file to build into the jar. When that happens why not label the jar for which env it was intended for? Previously I would build the jar when the system was built, so it would need to be built every time even when there were no code changes. The unit test also ran (which take a while ) again for no reason since there were no code changes. I read: The classifier allows to distinguish artifacts that were built from the same POM but differ in their content. It is some optional and arbitrary string that - if present - is appended to the artifact name just after the version number. As a motivation for this element, consider for example a project that offers an artifact targeting JRE 1.5 but at the same time also an artifact that still supports JRE 1.4. The first artifact could be equipped with the classifier jdk15 and the second one with jdk14such that clients
Re: using build profiles for WAR plugin
Read the thread I posted... JNDI is not the only solution. Profiles is *NOT* the solution On 29 February 2012 21:32, offbyone r...@iridiumsuite.com wrote: I have no interest in using JNDI. Could someone please address my question regarding profiles? -- View this message in context: http://maven.40175.n5.nabble.com/using-build-profiles-for-WAR-plugin-tp5525954p5526140.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to deploy with 'classifier'
You are fighting maven. One artifact one module Sent from my iPhone On 28 Feb 2012, at 19:40, Billy Newman newman...@gmail.com wrote: I have a pretty simple pom file setup to build a jar. I can deploy to my internal repository just fine. However I want to build different flavors of my jar and use the 'classifier' tag and deploy. However I can specify a 'classifier' in my pom file (with the group/artifact id and version), and I cannot seem to find how to specifiy the 'classifier' in the maven-deploy-plugin either. Since I am building with maven I do not want to use the deploy-file plugin. What am I missing? Thanks in advance. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: repository id question
if they all use the same credentials, I would say no issues On 27 February 2012 16:08, chad.da...@emc.com wrote: Are there issues with the re-use of the same repository id across the various repository declarations? As identifiers, it seems like they should each be unique. Is there anything wrong with the following . . . repositories repository idmyRepo/id nameInternal Repo /name urlhttp://myRepo/nexus/content/groups/public/url /repository /repositories pluginRepositories pluginRepository idmyRepo/id nameInternal Repo /name urlhttp://myRepo /nexus/content/groups/public/url /pluginRepository /pluginRepositories distributionManagement repository idmyRepo/id nameInternal Releases/name urlhttp://myRepo /nexus/content/repositories/releases/url /repository snapshotRepository idmyRepo /id nameSnapshots/name urlhttp://myRepo /nexus/content/repositories/snapshots/url /snapshotRepository /distributionManagement
Re: How to set the dependencies of plugin?
Add a dependencies section to the plugin On 22 February 2012 05:48, zhaoyi youhaod...@gmail.com wrote: I am using a maven plugin which has some dependencies. How can I modify the plugin's dependencies in my pom.xml? -- View this message in context: http://maven.40175.n5.nabble.com/How-to-set-the-dependencies-of-plugin-tp5504204p5504204.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven 3.0.3 Not Allowing Different Versions for Compile/Test
put the tests in a separate module and that way the module can have the alternative dependency On 21 February 2012 09:44, Daniel Jones dan...@mendeley.com wrote: Hi all, Apologies in advance if this isn't the right list to post to. Using Maven 3.0.3 and Dependency plug-in 2.4, I've encountered a strange issue whereby if I specify different versions of a dependency, one in compile scope and one in test, only one of them gets 'noticed'. I've detailed the problem on Stack Overflow (http://stackoverflow.com/questions/9364511/maven-different-dependency-version-in-test), but I'll repeat the explanation here. In my project I need to depend on a Cloudera distribution of Hadoop and a 'vanilla' version for JUnit testing, as the former only works on *nix. When I try and execute my application, I get Exception in thread main java.lang.NoClassDefFoundError: org/apache/hadoop/conf/Configuration. When I run JUnit tests from Maven or Eclipse, everything works fine. If I comment out the test dependencies, the application runs successfully, but then the tests fail because they're using the wrong version. Why is the compile dependency getting ignored when the test dependency is uncommented? dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-core/artifactId version0.20.2-cdh3u2/version scopecompile/scope /dependency dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-core/artifactId version1.0.0/version scopetest/scope /dependency dependency groupIdorg.apache.hadoop/groupId artifactIdhadoop-test/artifactId version1.0.0/version scopetest/scope /dependency mvn dependency:list shows the following, which does not show the compile scoped version at all: [INFO] The following files have been resolved: [INFO] ant:ant:jar:1.6.5:test [INFO] aopalliance:aopalliance:jar:1.0:compile [INFO] asm:asm:jar:3.3.1:compile [INFO] cglib:cglib:jar:2.2.2:compile [INFO] ch.qos.logback:logback-classic:jar:1.0.0:compile [INFO] ch.qos.logback:logback-core:jar:1.0.0:compile [INFO] com.google.guava:guava:jar:r08:compile [INFO] com.h2database:h2:jar:1.3.164:test [INFO] com.jolbox:bonecp:jar:0.7.1.RELEASE:compile [INFO] com.sun.jersey:jersey-core:jar:1.11:test [INFO] commons-beanutils:commons-beanutils:jar:1.7.0:test [INFO] commons-beanutils:commons-beanutils-core:jar:1.8.0:test [INFO] commons-cli:commons-cli:jar:1.2:test [INFO] commons-codec:commons-codec:jar:1.4:test [INFO] commons-collections:commons-collections:jar:3.2.1:test [INFO] commons-configuration:commons-configuration:jar:1.6:test [INFO] commons-digester:commons-digester:jar:1.8:test [INFO] commons-el:commons-el:jar:1.0:test [INFO] commons-httpclient:commons-httpclient:jar:3.0.1:test [INFO] commons-lang:commons-lang:jar:2.4:test [INFO] commons-logging:commons-logging:jar:1.1.1:compile [INFO] commons-net:commons-net:jar:1.4.1:test [INFO] hsqldb:hsqldb:jar:1.8.0.10:test [INFO] junit:junit:jar:4.10:test [INFO] mysql:mysql-connector-java:jar:5.1.18:compile [INFO] net.java.dev.jets3t:jets3t:jar:0.7.1:test [INFO] net.sf.kosmosfs:kfs:jar:0.3:test [INFO] org.apache.commons:commons-math:jar:2.1:test [INFO] org.apache.ftpserver:ftplet-api:jar:1.0.0:test [INFO] org.apache.ftpserver:ftpserver-core:jar:1.0.0:test [INFO] org.apache.ftpserver:ftpserver-deprecated:jar:1.0.0-M2:test [INFO] org.apache.hadoop:hadoop-core:jar:1.0.0:test [INFO] org.apache.hadoop:hadoop-test:jar:1.0.0:test [INFO] org.apache.mina:mina-core:jar:2.0.0-M5:test [INFO] org.codehaus.jackson:jackson-core-asl:jar:1.0.1:test [INFO] org.codehaus.jackson:jackson-mapper-asl:jar:1.0.1:test [INFO] org.eclipse.jdt:core:jar:3.1.1:test [INFO] org.hamcrest:hamcrest-core:jar:1.1:test [INFO] org.liquibase:liquibase-core:jar:2.0.3:test [INFO] org.liquibase.ext:liquibase-slf4j:jar:0.0.1:test [INFO] org.mortbay.jetty:jetty:jar:6.1.26:test [INFO] org.mortbay.jetty:jetty-util:jar:6.1.26:test [INFO] org.mortbay.jetty:jsp-2.1:jar:6.1.14:test [INFO] org.mortbay.jetty:jsp-api-2.1:jar:6.1.14:test [INFO] org.mortbay.jetty:servlet-api:jar:2.5-20081211:test [INFO] org.mortbay.jetty:servlet-api-2.5:jar:6.1.14:test [INFO] org.slf4j:jcl-over-slf4j:jar:1.6.4:compile [INFO] org.slf4j:log4j-over-slf4j:jar:1.6.4:compile [INFO] org.slf4j:slf4j-api:jar:1.6.4:compile [INFO] org.springframework:spring-aop:jar:3.1.1.RELEASE:compile [INFO] org.springframework:spring-asm:jar:3.1.1.RELEASE:compile [INFO] org.springframework:spring-beans:jar:3.1.1.RELEASE:compile [INFO] org.springframework:spring-context:jar:3.1.1.RELEASE:compile [INFO] org.springframework:spring-context-support:jar:3.1.1.RELEASE:compile [INFO] org.springframework:spring-core:jar:3.1.1.RELEASE:compile [INFO]
Re: problem scm in superPOM
They are special elements. if inherited, the artifactId is appended...
you will just have to write each one in each module
2012/2/20 José Manuel Prieto joseman...@prietopalacios.net:
Hi,
I try configure to scm (for mvn release:prepare release:perform ) in my
enterprise superPOM. But I have a problem.
mySuperPom.xml (pom.xml)
properties
git.urlscm:git:ssh://git@192.168.1.18:/home/git/proyectos//git.url
dot.git.git/dot.git
/properties
scm
url${git.url}${project.name}${dot.git}/url
connection${git.url}${project.name}${dot.git}/connection
developerConnection${git.url}${project.name
}${dot.git}/developerConnection
/scm
myPom.xml (pom.xml)
properties
project.namenasa_cierrestaquillasexportacion/project.name
/properties
myEffectivePOM.xml (pom.xml)
scm
connectionscm:git:ssh://git@192.168.1.18:
/home/git/proyectos/nasa_cierrestaquillasexportacion.git/nasa_cierrestaquillasexportacion/connection
developerConnectionscm:git:ssh://git@192.168.1.18:
/home/git/proyectos/nasa_cierrestaquillasexportacion.git/nasa_cierrestaquillasexportacion/developerConnection
urlscm:git:ssh://git@192.168.1.18:
/home/git/proyectos/nasa_cierrestaquillasexportacion.git/nasa_cierrestaquillasexportacion/url
/scm
The question is, why put at the end?:
scm:git:ssh://git@192.168.1.18:
/home/git/proyectos/nasa_cierrestaquillasexportacion.git/nasa_cierrestaquillasexportacion
instead of:
scm:git:ssh://git@192.168.1.18:
/home/git/proyectos/nasa_cierrestaquillasexportacion.git
why add /nasa_cierrestaquillasexportacion?
If I put scm in myPom.xml all is correct.
Thanks
Jose Manuel Prieto
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven for XML project
Write your own plugins it's not too hard... In the absolute worst case you may end up implementing your own packaging type, that is not too hard either, but slightly more work than implementing your own plugins, and you need to understand the use case that drives needing your own packaging type. SO START WITH YOUR OWN PLUGIN first The Maven book has at least one chapter on the subject, and covers it quite well -Stephen On 20 February 2012 11:39, ecniv vince.leguill...@gmail.com wrote: Hi there, I'm new to maven, and currently using it for JAVA projects. I'm now wondering if I can use maven efficiently for other projects. As an example, some of my projects contains XML files and other configuration files, which have a specific folder hierarchy quite different from the usual src/main/* hierarchy user by maven. These files, once modified, must be reloaded in a specific software using the command line, and some test must also be run before any production release, still using the command line. They are versionned in a SVN repository. Can maven be used with such projects ? Is there any possibility to customise the build process so it fits the requirements of non-java projects ? (i.e. no JAVA compiler) Any comment will be apreciated :) -- View this message in context: http://maven.40175.n5.nabble.com/Maven-for-XML-project-tp5498778p5498778.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Maven for XML project
Archetypes are initial templates of a project, they just provide an initial layout and pom, but no build time functionality, and cannot be reapplied. Plugins provide buildtime actions From your initial description, you want the latter... You might, after you have created your plugin, create an archetype to show how to create/use your plugin in a project. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On Feb 20, 2012 12:46 p.m., ecniv vince.leguill...@gmail.com wrote: Hum, plugin is one possibility indeed. Why not using a custom archetype ? What are the advantages / drawbacks of each solution (plugin VS archetypes / pom)? -- View this message in context: http://maven.40175.n5.nabble.com/Maven-for-XML-project-tp5498778p5498911.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: Maven for XML project
the OP was making sounds of the I have a lot of projects like this and there is XML/other processing to be done which sounds like a plugin would be needed, or a lot of exec:exec and antrun:run hackery... but yeah, might work too... we just don't know enough of the OP's problem to give the simplest solution ;-) On 20 February 2012 14:45, Ron Wheeler rwhee...@artifact-software.com wrote: What about the assembly plug-in or shade? Could they not be used to package up the structure in the right way? Ron On 20/02/2012 8:02 AM, Stephen Connolly wrote: Archetypes are initial templates of a project, they just provide an initial layout and pom, but no build time functionality, and cannot be reapplied. Plugins provide buildtime actions From your initial description, you want the latter... You might, after you have created your plugin, create an archetype to show how to create/use your plugin in a project. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On Feb 20, 2012 12:46 p.m., ecnivvince.leguill...@gmail.com wrote: Hum, plugin is one possibility indeed. Why not using a custom archetype ? What are the advantages / drawbacks of each solution (plugin VS archetypes / pom)? -- View this message in context: http://maven.40175.n5.nabble.com/Maven-for-XML-project-tp5498778p5498911.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 -- 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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: systemPath creating problem for hot deploy
Do not drop off list.
The list acts as a searchable archive for the next person that has your problem.
Please read the sonatype maven book.
Please get yourself a repository manager... There are three prominent options,
all equally capable, I will not recommend one over the other, in alphabetical
order: archivia, artifactory, nexus. The latter two also have commercial
versions with additional features.
Re option 1, google maven install:install-file
Re option 2, google maven deploy:deploy-file
Sent from my iPhone
On 19 Feb 2012, at 02:31, deoraashut...@gmail.com wrote:
I m totally new to Maven .
Can you please give me an example on this , taking this one as sample so that
I can figure out how to write others for both point 1 and 2.
Can you explain the What do you mean with repository manager
quote author='stephenconnolly'
don't use scope=system
either:
1. install the artifact in your local repo
or
2. (Better) deploy the artifact to your maven repository manager
Friends don't let friends use Maven without a Repository Manager
Friends don't let friedns use Scope = system
-Stephen
On 17 February 2012 15:03, ashutoshd deoraashut...@gmail.com wrote:
dependency
groupIdcom.XX/groupId
artifactId/artifactId
version3.2/version
scopesystem/scope
systemPath${basedir}/lib/XX-3.1.4.jar/systemPath
/dependency
this is creating problem for auto build of projects in maven
can anyone tell me what is the correct way to write so that maven can be
auto build again
--
View this message in context:
http://maven.40175.n5.nabble.com/systemPath-creating-problem-for-hot-deploy-tp5492802p5492802.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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
/quote
Quoted from:
http://maven.40175.n5.nabble.com/systemPath-creating-problem-for-hot-deploy-tp5492802p5496071.html
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Help! What I'm doing wrong with release:branch?
Looks like you are fighting maven (a loosing battle) Only tags should have a fixed version Sent from my iPhone On 19 Feb 2012, at 00:29, Dipl.-Ing. Torsten Liermann l...@liermann-it.de wrote: Hi, (sorry, I can't speak english :( ) I would like to create a branch with a release version in all pom's The Snapshot version of the trunk is 3.0.2-SNAPSHOT and the release version should be 3.0-b01. Calling maven with mvn org.apache.maven.plugins:maven-release-plugn:2.2.2:branch -DbranchName=3.0-b01 -DreleaseVersion=3.0-b01 -DupdateBranchVersions=true -DupdateVersionsToSnapshot=false -DautoVersionSubmodules=true -DupdateWorkingCopyVersions=false results in pom's with version of 3.0-b01-SNAPSHOT in branch 3.0-b01. But I need the fix verssion 3.0-b01. Also the updated of the scm info is wrong: scm connectionscm:svn:svn://lierdata/lehel/branches/3.0-b01/trunk/connection developerConnectionscm:svn:svn://lierdata/lehel/branches/3.0-b01/trunk/developerConnection urlscm:svn:svn://lierdata/lehel/branches/3.0-b01/trunk/url /scm Thanks for a hint Torsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: what does --define do in maven
No. Toolchains that is the way. Profiles are not best suited to that, esp when you are hardcoding paths in the profile. If you are doing Maven right, on another new PC running any of MacOS/Linux/Windows you should just need to install maven, setup your toolchains.xml and settings.xml and checkout the project and build should work first time. If you are doing Maven wrong then it won't work -Stephen On 18 February 2012 10:25, sarmahdi sarma...@hotmail.com wrote: thanks for the comment stephen: I agree, it does seem like a bootstrap or adhoc way of passing which JDK we need to compile with: How ever, i made profiles. So you think making profiles is a good way or not. i made two profiles and gave the compiler plugin settings differently. So when i call with -PDEVJDK5 it compiles with jdk 5 or else -PDEVJDK6 in which case it compiles using the jdk 5 (I had hardcoded the jdk directory path like this ) / profile idSITJDK5/id build plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.3.2/version configuration source1.5/source target1.5/target verbosetrue/verbose forktrue/fork executableD:/IBM/SDP70/jdk/bin/javac/executable /configuration /plugin /plugins /build /profile/ This seemed like a decent way to me. What do you guys think, can we choose JDK like that and run it like this : /mvn.bat --also-make --projects com.riyadbank:eCorp-ear clean -PSITJDK5 install/ I just started reading on toolchains so dont know how it will help me. Thanks Syed... -- View this message in context: http://maven.40175.n5.nabble.com/what-does-define-do-in-maven-tp5485392p5495040.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: what does --define do in maven
It is a question of itch scratching... If it is your itch, scratch it, submit a patch, and it will be done ;-) On Saturday, 18 February 2012, sarmahdi sarma...@hotmail.com wrote: Stephen, i just saw toolchain. for jdk yes its a good way, pretty much the same way I am doing in profiles. It will only add one more step (or xml tree) to add a tool chain instead of reading from properties in the compiler plugin the profile will be bound by its own specific tool chain for the jdk. which is good too. it says that only four plugins are toolchain aware: maven-compiler-plugin-2.1 maven-javadoc-plugin-2.5 maven-surefire-plugin-2.5 exec-maven-plugin-1.1.1 (Codehaus MOJO) I think it would be a better thing to add the SCM plugin to be tool chain aware as well. so that we can configure a tool chain for the scm and add them to profiles so that when we run a profile it updates from the tool chained stream/branch and all other props in those tool chain. -- View this message in context: http://maven.40175.n5.nabble.com/what-does-define-do-in-maven-tp5485392p5495206.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: Maven fails to run any tests was:TestNG dependency not found
Sure fire expects test class names to begin or end with Test unless you configure it otherwise... Rename your test and it will run ;-) On Saturday, 18 February 2012, Gogirl claudia.fr...@gmail.com wrote: Wayne wrote I am guessing that you made changes but did not re-import yet. I am only using the IDE Editor to edit. Sorry for the mixup. I am only using the console and a simple bat file with maven goals and phases. I have made the following changes to the original Maven in 5 min example: Changes to the .pom I added the TestNG dependency and vertified that the jars were loaded in the . m folder. Added the surefire plugin as explained to be able to run tests: http://maven.apache.org/plugins/maven-surefire-plugin/usage.html I had added a test src file AppTestNG.java and some others as is http://www.mkyong.com/maven/how-to-run-unit-test-with-maven/ and placed the new src files under the same test folder as AppTest. However I removed them as soon as i discovered that Maven won't run any tests for me neither junit nor testng. Result Tests run:0 Read: http://maven.apache.org/general.html#run-one-test http://maven.apache.org/plugins/maven-surefire-plugin/usage.html http://maven.apache.org/plugins/maven-surefire-plugin/examples/single-test.html I even tried java -cp target/mavenHelloWorld-1.0-SNAPSHOT.jar com.mycompany.app.AppTest *ERROR MESSAGE: Cannot find or load AppTest Here is the bat file with the commands I use: @echo off echo * echo Run a single test case echo Expected Output: 6 test case run echo *ERROR MESSAGE: Failed to execute goal on echo surefire plugin No tests were executed echo * mvn -Dtest=AppTestNG test GOTO EndComment @echo off echo * echo See maven-in-five-minutes echo Using mc.bat echo SWITCH TO MAVEN PROJECTS DIR: echo C:\Users\GoGirl\_MavenProjects\mavenHelloWorld echo * echo. CD C:\Users\GoGirl\_MavenProjects\mavenHelloWorld echo * echo CLEAN: Expected Output: Target Folder removed echo * echo. mvn clean echo. @echo off echo * echo COMPILE: echo Expected Output: Hello World echo * echo. mvn compile echo. echo * echo Test: echo Expected Output: Compile tests (does not run them) echo * echo. mvn test echo. echo * echo BUILD COMPILE ALL: echo Rather than a goal, package is a phase echo in the build lifecycle creating an executable jar echo Expected output: Target folder created echo * echo. mvn package echo. @echo off echo * echo Test the newly compiled and packaged JAR echo using java -cp: Expected Output: Hello World echo * echo. java -cp target/mavenHelloWorld-1.0-SNAPSHOT.jar com.mycompany.app.App echo. echo * echo Test the newly compiled and packaged JAR echo *ERROR MESSAGE: Cannot find or load AppTest echo * echo. java -cp target/mavenHelloWorld-1.0-SNAPSHOT.jar com.mycompany.app.AppTest echo. echo * echo Compile all tests echo Without running them echo BUILD SUCCESS echo * echo. mvn test-compile echo: check package name matches directory structure C:\Users\GoGirl\_MavenProjects\mavenHelloWorld\src\test\java\com\mycompany\app :EndComment -- View this message in context: http://maven.40175.n5.nabble.com/Maven-fails-to-run-any-tests-was-TestNG-dependency-not-found-tp5495324p5495324.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: what does --define do in maven
Copy your toolchains and Pom into *pastebin* or *gist* and post *the link*
I will take a look
Do not try posting you Pom in the reply, do not pass go, do not collect
$200, do not pick up any community chest cards
On Saturday, 18 February 2012, sarmahdi sarma...@hotmail.com wrote:
Hello Stephen,
I need some help i guess:
I tried to use toolchains to actually compile the code with JDK 5 while my
default java_home is jdk6 and it said :
[DEBUG] Configuring mojo
org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile from plugin
realm
ClassRealm[pluginorg.apache.maven.plugins:maven-compiler-plugin:2.3.2,
parent: sun.misc.Launcher$AppClassLoader@f4a24a]
[DEBUG] Configuring mojo
'org.apache.maven.plugins:maven-compiler-plugin:2.3.2:compile' with basic
configurator --
[DEBUG] (f) basedir = C:\Alpha\eCorp\eCorp-web
[DEBUG] (f) buildDirectory = C:\Alpha\eCorp\eCorp-web\target
[DEBUG] (f) compileSourceRoots =
[C:\Alpha\eCorp\eCorp-web\src\main\java]
[DEBUG] (f) compilerArguments =
{endorseddirs=C:\Alpha\eCorp\eCorp-web\target/endorsed}
[DEBUG] (f) compilerId = javac
[DEBUG] (f) debug = true
[DEBUG] (f) encoding = UTF-8
[DEBUG] (f) *executable *= C:\glassfish3withjdk\jdk/bin/javac */(this
is
the JDK6)/*
[DEBUG] (f) failOnError = true
[DEBUG] (f) fork = true
[DEBUG] (f) generatedSourcesDirectory =
C:\Alpha\eCorp\eCorp-web\target\generated-sources\annotations
[DEBUG] (f) optimize = false
[DEBUG] (f) outputDirectory = C:\Alpha\eCorp\eCorp-web\target\classes
[DEBUG] (f) outputFileName = eCorp-web-1.0-SNAPSHOT
[DEBUG] (f) projectArtifact = com.riyadbank:eCorp-web:war:1.0-SNAPSHOT
[DEBUG] (f) session = org.apache.maven.execution.MavenSession@46a55e
[DEBUG] (f) showDeprecation = false
[DEBUG] (f) showWarnings = false
[DEBUG] (f) source = 1.5
[DEBUG] (f) staleMillis = 0
[DEBUG] (f) target = 1.5
[DEBUG] (f) verbose = true
[DEBUG] -- end configuration --
[DEBUG] Using compiler 'javac'.
[INFO] Toolchain in compiler-plugin: JDK[D:/IBM/SDP70/jdk] */(This is the
JDK5)/*
*[WARNING] Toolchains are ignored, 'executable' parameter is set to
C:\glassfish3withjdk\jdk/bin/javac*
It goes for JDK 6 after getting the toolchain why is it not going for the
JDK that i hard coded for the 1.5 JDk in toolchains.xml
Do you have any idea: I searched on google and some one said that cos
there
is already a JVM installed so it went for that. When i remove the
JAVA_HOME
from system environment as a variable then mvn.bat doesnt run cos
JAVA_HOME
is not set for it.
So what do i do now: if i set a JAVA_HOME it falls back on it and ignores
the toolchain, if i dont set the JAVA_HOME then mvn fails
So what do we do: whats wrong here?
Thanks in advance.
Syed...
--
View this message in context:
http://maven.40175.n5.nabble.com/what-does-define-do-in-maven-tp5485392p5495490.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: systemPath creating problem for hot deploy
don't use scope=system
either:
1. install the artifact in your local repo
or
2. (Better) deploy the artifact to your maven repository manager
Friends don't let friends use Maven without a Repository Manager
Friends don't let friedns use Scope = system
-Stephen
On 17 February 2012 15:03, ashutoshd deoraashut...@gmail.com wrote:
dependency
groupIdcom.XX/groupId
artifactId/artifactId
version3.2/version
scopesystem/scope
systemPath${basedir}/lib/XX-3.1.4.jar/systemPath
/dependency
this is creating problem for auto build of projects in maven
can anyone tell me what is the correct way to write so that maven can be
auto build again
--
View this message in context:
http://maven.40175.n5.nabble.com/systemPath-creating-problem-for-hot-deploy-tp5492802p5492802.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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: compile and run a class before the comiple phase
put it in a separate module On 18 February 2012 15:14, jgruber john.t.gru...@gmail.com wrote: Hello all.. still learning maven. I have a project where I need to compile a class and then run its main method to acquire some of the needed files for the compile phase. The files I need to acquire require a bit of massaging of a HTTP conversation to work, so that part is proprietary to my class for now. Originally I had a shell script which would run both the compile step and the mvn commands, but exec:exec will not work inside of eclipse (the target for this project) when importing my maven project. What the best way to have maven compile a java class from the src tree, have it in its path, and exec:java before the compile phase? Thanks for the advice. -- View this message in context: http://maven.40175.n5.nabble.com/compile-and-run-a-class-before-the-comiple-phase-tp5495402p5495402.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: compile and run a class before the comiple phase
or better yet, make it a plugin On 19 February 2012 01:38, Stephen Connolly stephen.alan.conno...@gmail.com wrote: put it in a separate module On 18 February 2012 15:14, jgruber john.t.gru...@gmail.com wrote: Hello all.. still learning maven. I have a project where I need to compile a class and then run its main method to acquire some of the needed files for the compile phase. The files I need to acquire require a bit of massaging of a HTTP conversation to work, so that part is proprietary to my class for now. Originally I had a shell script which would run both the compile step and the mvn commands, but exec:exec will not work inside of eclipse (the target for this project) when importing my maven project. What the best way to have maven compile a java class from the src tree, have it in its path, and exec:java before the compile phase? Thanks for the advice. -- View this message in context: http://maven.40175.n5.nabble.com/compile-and-run-a-class-before-the-comiple-phase-tp5495402p5495402.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Copy two versions of same jar
Alternatively, if you just need a copy of the jar, and not the jar on the classpath, ie you are writing some app that builds its own classpath, some parts of the app use one version and other parts use the other version, and you have fancy code that sets up the class loaders correctly, this would be an ideal illustration of why dependency:copy can be needed sometimes (ie dependency:copy-dependencies does not fit this use-case) Though IMHO I would rather wrap the code that needs the older version in a separate jar that uses maven-shade-plugin to remove the need for class loader trickery, if you have your own plugin framework, that might not be tractable... Having said all that, 99% chance is that none of the above apply to your case, and you are just fighting maven because you think you can win... Well you won't win. On Friday, 17 February 2012, Wayne Fay wayne...@gmail.com wrote: dependencies dependency groupIdtest/groupId artifactIdcastor/artifactId version0.9.5/version /dependency dependency groupIdtest/groupId artifactIdcastor/artifactId version1.0.4/version /dependency /dependencies ... But this copies only one version and it ignores the other one.. Please provide a solution for copying both the versions. Why do you want to do this? As you've already discovered, Maven will generally collapse two such dependencies into a single element and pick one version over the other. If you have any ability to control the GA coordinates or to add a C (classifier) to one of the artifacts, you should do so as that would be the easiest possible solution. Then Maven would consider them as different and you could bring in both versions very easily. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: what does --define do in maven
ASIDE: Please note that using properties is not the recommended way to pick different JDKs for building with. The recommended way is to use ~/.m2/toolchains.xml to define where your different JDKs (and other toolchains) are located, and then use the maven-toolchains-plugin to call out the specific toolchain you want maven to use for compiling your project with, running your unit tests with, etc. However, if you are just playing around to grok maven, that's OK... as long as realise that the correct way for specifying toolchains is ~/.m2/toolchains.xml ;-) On 15 February 2012 15:37, sarmahdi sarma...@hotmail.com wrote: Oliver: Did you mean that if i do *mvn compile -dexecutable=C:/glassfish3withjdk/jdk/bin/javac -dfork=true -dsource=1.6 -dtarget=1.6 -dverbose=true * it will be like running the compile plugin with this configuration : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId version2.3.2/version configuration /* source1.6/source target1.6/target verbosetrue/verbose forktrue/fork*/ /*executableC:/glassfish3withjdk/jdk/bin/javac/executable*/ /configuration /plugin Thanks for answering tho. Syed... -- View this message in context: http://maven.40175.n5.nabble.com/what-does-define-do-in-maven-tp5485392p5486406.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: compiler errors hidden when building Maven project on Jenkins
On 15 February 2012 09:06, Nord, James jn...@nds.com wrote:
Moving to Jenkins-dev (if anyone wants to follow there)
I say no - except if you use any plugin that behind the scenes changes the
configuration of the mojos you run.
I'm open for someone to convince me I'm wrong though.
I haven't taken an in depth look but IIRC a Jenkins plugin can't subvert
the
maven build by changing mojo parameters on the fly anymore if you use
Maven 3.x (in a Maven2 job).
does your build fail if the tests fail?
Depends on what type of build I'm running (code review, commit or full).
if the answer is no, and you haven't put -Dmaven.test.failure.ignore=true on
the
CLI then you are recalling incorrectly :-P
But - is this any different to someone hiding away MAVEN_OPTS somewhere in
the global or slave configuration that a non admin user can't see?
All be it this info should really be echoed in the build log (regardless of
freestyle or maven2 job type) but that is a different discussion.
The bit I was referring to was from MojoInfo.java:
/**
* Mojo object that carries out the actual execution.
*
* @deprecated as of 1.427
* Maven3 can no longer provide this information, so plugins cannot
rely on this value being present.
* For the time being we are setting a dummy value to avoid NPE. Use
{@link #configuration} to access
* configuration values, but otherwise the ability to inject values
is lost and there's no viable
* alternative.
*/
public final Mojo mojo;
Are you saying that all the manipulation of the configuration can still be
done on the fly per mojo per module - and it is not done up-front by a system
property or some other mechanism)?
AFAIR
/**
* Configuration of the mojo for the current execution.
* This reflects the default values, as well as values configured from POM,
* including inherited values.
*/
public final PlexusConfiguration configuration;
allows you to modify the configuration, the scope of changes is
reduced but not removed...
I'm sure Olivier will correct me if I am wrong though ;-)
/James
**
This message is confidential and intended only for the addressee. If you have
received this message in error, please immediately notify the
postmas...@nds.com and delete it from your system as well as any copies. The
content of e-mails as well as traffic data may be monitored by NDS for
employment and security purposes. To protect the environment please do not
print this e-mail unless necessary.
NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18
4EX, United Kingdom. A company registered in England and Wales. Registered
no. 3080780. VAT no. GB 603 8808 40-00
**
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Non Recursive Maven as a Pom Configuration
Add the modules in a profile that is activated by default... that way when you activate the check profile explicitly (as long as you don't do -P+check) the modules will be missing from the effective pom ;-) But beware fun side-effects On 15 February 2012 08:49, Cem Koc cemalettin@gmail.com wrote: Hi, Is there a way to restrict reactor plugin to forbid running sub modules in a pom configuration. What I want to do is exact equivalent of non recursive parameter ( -N ) of Maven. My parent pom is inherited by all sub modules and my goal is running my pom profile without command line parameter. mvn -Pcheck instead of mvn -Pcheck -N Thanks -- View this message in context: http://maven.40175.n5.nabble.com/Non-Recursive-Maven-as-a-Pom-Configuration-tp5485284p5485284.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Make plugin failsafe compatible
On 14 February 2012 11:20, Gaurav Arora g.ar...@iontrading.com wrote: Hi, I'm running robot framework tests from maven using the rf maven plugin - http://code.google.com/p/robotframework-maven-plugin/. The plugin works fine except that it fails my build and prevents post-integration-test from running and post-integration-test is where I tear down my environment. This is how the failsafe plugin is configured. plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.12/version executions execution idintegration-test/id goals goalintegration-test/goal /goals /execution execution idverify/id goals goalverify/goal /goals /execution /executions /plugin And this is how I run the rf plugin. plugin groupIdcom.googlecode.robotframework-maven-plugin/groupId artifactIdrobotframework-maven-plugin/artifactId version1.1.2-SNAPSHOT/version executions execution phaseintegration-test/phase goals goalrun/goal /goals /execution /executions /plugin I can clearly see in the logs that the failsafe plugin is run but for some reason the rf plugin bypasses the failsafe plugin. This makes me think that I need to change the rf plugin to be failsafe compatible. Am I right or completely off the mark? actually you need to change it to be integration-test compatible... Thanks, Gaurav P.S. The rf plugin throws a MojoExecutionException when there are test failures. Well what you really should do, if you are executing a goal that is bound to the integration-test phase is *never fail the build* but offer a second goal (bound to the verify phase) that checks the results of your integration-test phase goal and fails the build if necessary. That is how integration tests are supposed to work... see both the failsafe and invoker plugins for examples of this. In short, if your goal is bound to the integration-test phase then you should not fail the build *ever* otherwise the post-integration-test phase never gets executed to do whatever tidy-up is needed in the user's build... Oh and while I am at it, *never* invoke the integration-test phase directly mvn integration-test BAD BAD BAD mvn verify GOOD Again this is for the same reason - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: compiler errors hidden when building Maven project on Jenkins
On 14 February 2012 14:54, Olivier Lamy ol...@apache.org wrote: 2012/2/14 Drury, Tim t.dr...@sap.com: I've asked this question on the Jenkins email list a week ago (where I think it belongs) and on StackOverflow, but I've gotten no results. I know this isn't a Maven issue per se' because a local build does show compiler syntax errors, but I'm at wits end and hoping someone on this list may have seen this issue before and offer some insight. I've posted this question to StackOverflow here: http://stackoverflow.com/questions/9229020/jenkins-not-showing-maven-compiler-errors I'll summarize here, but to see full output I hope you wouldn't mind clicking that link - the output is long and better encapsulated there then in this email. When Jenkins 1.450 builds my maven 3 project, if there are compiler errors all I get is an exception from the maven-compiler-plugin (2.0.2) and not the actual syntax errors you usually see. When building locally, you _do_ get the syntax errors. Jenkins used to show the compiler syntax errors but stopped doing so about two weeks ago. What changed? We switched from maven 2.2.1 to maven 3.0.4, but I'm fairly certain we got compiler errors in the output just after the switch (but can't verify this). I found a similar (possibly the same) issue on Jenkins' Jira: https://issues.jenkins-ci.org/browse/JENKINS-10333 but no action had been taken. Has anyone else seen this? Is this a Jenkins issue or a Maven issue (or both)? IMHO It's a Jenkins issue. And the OP is probably using the evil Maven project type and not a freestyle project with a maven build step -Stephen -tim Tim Drury Architect SAP Manufacturing Execution (SAP ME) Supply Chain Management SAP Labs, LLC T +1 404 943 2088 F +1 610 492 2257 mailto:t.dr...@sap.com www.sap.com Please consider the impact on the environment before printing this e-mail. -- Olivier Lamy Talend: http://coders.talend.com http://twitter.com/olamy | http://linkedin.com/in/olamy - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: compiler errors hidden when building Maven project on Jenkins
On 14 February 2012 17:00, Nord, James jn...@nds.com wrote: Some people (like Stephen) will say yes. And what would I know about maven and jenkins ;-) 99 times out of 100, when I see a problem with Maven and Jenkins it is trivially fixed by switching to a FreeStyle project type with a Maven build step. Now that is not to say that it is completely evil or without merrit... just that it is the root of most of the issues. I say no - except if you use any plugin that behind the scenes changes the configuration of the mojos you run. I'm open for someone to convince me I'm wrong though. I haven't taken an in depth look but IIRC a Jenkins plugin can't subvert the maven build by changing mojo parameters on the fly anymore if you use Maven 3.x (in a Maven2 job). does your build fail if the tests fail? if the answer is no, and you haven't put -Dmaven.test.failure.ignore=true on the CLI then you are recalling incorrectly :-P /James -Original Message- From: Drury, Tim [mailto:t.dr...@sap.com] Sent: 14 February 2012 16:14 To: Maven Users List Subject: RE: compiler errors hidden when building Maven project on Jenkins And the OP is probably using the evil Maven project type and not a freestyle project with a maven build step I am. Is this bad? -tim - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org ** This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. NDS Limited. Registered Office: One London Road, Staines, Middlesex, TW18 4EX, United Kingdom. A company registered in England and Wales. Registered no. 3080780. VAT no. GB 603 8808 40-00 ** - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Whatever happened to mixins?
On Tuesday, 14 February 2012, Andrew Todd andrew.todd...@gmail.com wrote: Apologies if this has already been rehashed to death, but I have been trying to trace the arc of Maven mixin development over the past few years, and was wondering what happened. They kind of need a Pom version change to work... Every time we hit the Pom version change problem the 3.0.0 to 4.0.0 transition flashbacks put a blocker on migration, and the thought of deploying two poms, with the resulting slow-down for people depending on legacy artifacts, or people with maven 3.0 or 2.x trying to use new artifacts stymies progress. There really is only one viable solution so far, and that is less than perfect... Add on top that with the (deploy two poms) solution, it only gets us one version transition, so it does not scale... That is to have a version 6.0.0 Pom we'd need to deploy three poms for each artifact. The end result is we need a version 5.0.0 format that we are sure can be extended (future proof) and then the two poms deployment is perhaps acceptable - stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to deal with maintenance branches?
On 10 February 2012 18:58, Markus Karg markus.k...@gmx.net wrote: What is Maven 3's best practice to deal with Maintenance Branches (non-feature, bug-fix-only line of development)? Our company needs to maintain a second development line besides trunk, which we call The Maintenance Branch, for those customers having signed a maintenance contract for one particular version (e. g. when signed for 1.1.0 he will receive bug fixes 1.1.* but not features 1.2.*). This means, besides trunk (which always contains the latest features), we have branches/1.1-maintenance (with 1.1 being the version number that this branch was forked from to further get bug fixed but not feature-extended). Due to the rules of the contracts, in that branches, all bug fixes must go in, but no new features. Before using maven this was simple, as it was completely manual work. But now we start using Maven, and get into some CI and dependency trouble. In trunk we always have SNAPSHOT versions, obviously, as we add features daily til we reach the release day. Just when we do a release (1.0, 2.0, etc.) we use the maven release plugin to get tagged branches (non-SNAPSHOT). From those tagged branches, we copy our maintenance branches (using svn cp directly as we do not know how to tell maven to do so, BTW). So, the maintenance branch is NOT a SNAPSHOT version, as the release obviously is never a SNAPSHOT version. $ svn co release-tag-uri somedir $ cd somedir $ mvn release:branch -DbranchName=my-branch -DupdateBranchVersions=true -DupdateWorkingCopyVersions=false $ cd .. $ rm -rvf somedir done. Now we like to use CruiseControl to do CI. We expect no problems in trunk as all are SNAPSHOT versions, so a change to a dependency will trigger maven2snapshotdependency to effectively compile and test the dependent project each time the dependency changes (as the name says: it detects snapshot changes of dependencies). Great! But what to do with the Maintenance Branch? As soon as we merge a fix for a dependency into that svn branch, we want CruiseControl to do CI. But we do not expect that maven2snapshotdependency will recognize the modified dependency -- as the maintenance branch is not SNAPSHOT (as it was created by copying the release tag in svn). We need a solution for THAT and have NO CLUE! We had the idea that we could just manually increase the version's z (from x.y.z) of the product with each merged fix to express that this is a bug fix, and add -SNAPSHOT to all projects in the Maintenance Branch to activate the maven2snapshotdependency again. I assume that would work. But, besides a LOT of manual work (we have nearly one hundred projects), we would break the possibility to replace a JAR inside a customer's installation (i. e. to actually provide the fix to the requesting customer): That is a problem you will have anyway. If the customer reports a bug and you ask them what version are they running and the tell you that it's the one with foo-1.1.0.jar so it must be version 1.1.0 how are you going to explain to them that it could be any one of 50 different patch versions of that jar that you gave them. Your sanity *requires* that you do one of the following: 1. strip the version from the .jar files and thereby sidestep the problem. 2. bump all the jar files to keep the version number references correctly, and thereby remove the problem. 3. use a patch utility to modify the existing unmodified jar files to point to the new jar files... can be problematic... but if you have already give the customer 1.1.0 and you need to support that customer, well it's kind-of your only solution... the wise prince will pick option 3 initially and have the patch utility strip the version numbers from all the jar files so that option 1 can be applied going forwards, OR just go with option 2. As Maven's best practice is to add the version to the name, increasing the minor version to express the bug fix level would result in dependencies getting not found by the JVM's classloader anymore, as Java's META-INF dependency resolution technology cannot deal with partially changed names but insists on the exact same JAR name (and such the version number) of the last major release (i. e. abc-x.y.0-JAR instead of abc-x.y.1-JAR). We could provide a custom artifact name to the pom enforcing abc-x.y.0.jar always, but as it seems, this is not Maven's best practice (otherwise maven would do it automatically), so we assume there is a totally different solution we just do no see. So please, Maven Experts in this forum, enlight us! What is The Maven Way of dealing with Maintenance Branches? What is the big trick that we just do not see to get CI and dependency JAR loading running on bug-fix-only branches? I never rely on a classpath in a .jar file anyway, I write my scripts for setting up the classpath such that either the classpath is pulled from a text file (now patching is easy, just add in the
Re: dependency plugin usage
On 13 February 2012 18:20, chad.da...@emc.com wrote: I'm wondering what the difference would be between the following two ways of handling copying of a certain type of maven dependency. The dependency I'm talking about is something like, for instance, a self-extracting installer that I want to bundle with my custom assembly. I've deployed this installer as a maven artifact. Initially, I didn't think of it as a normal maven dependency, since it's not a compile dependency, so I set the build up to use the maven-dependency-plugin:copy mojo. The rule of thumb is use dependency:copy if the dependency comes from outside your reactor, as dependency:copy will not affect the build order, and you might need to influence the build order. [can always add a pom typed dependency to force the build order if needed This works great. However, I then started wondering whether I should just declare the dependency in my dependencies and then use the maven-dependency-plugin:copy-dependencies mojo. this one is equally good, but will (by definition) ensure that the reactor is built in the correct sequence for dependencies from the reactor... but in some cases, you may not want this as, by necessity, listing dependencies can influence the classpath if the dependencies are of type jar Can anyone provide some insight as to whether either way is better or worse? - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Antwort: Deploy javadoc/sources for snapshots
can we not cheat and specify -DupdateReleaseInfo=false Or is the flag set in the parent directly in the configuration and not by setting the property On 10 February 2012 13:32, Thiessen, Todd (Todd) tthies...@avaya.com wrote: You certainly can do the work yourself. But most of what you have defined is already defined in the super pom via the release profile. And of course the benefit of using the release profile is that is isn't active by default. You can configure you CI to activate the profile, no extra work needed. Very neat and tidy. But the question still remains is if this can have any negative side effects since the release profile also configures the deploy plugin with updateReleaseInfo=true. -Original Message- From: Thorsten Heit [mailto:thorsten.h...@vkb.de] Sent: Friday, February 10, 2012 8:15 AM To: Maven Users List Subject: Antwort: Deploy javadoc/sources for snapshots Hi, Anyone run into the desire to deploy javadoc and sources artifacts for snapshots, in a similar fashion as done by the release-profile? If so, how are you handling that? Add the following configuration to buildplugins in your pom.xml: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-javadoc-plugin/artifactId version2.8.1/version executions execution idattach-javadocs/id goals goaljar/goal /goals /execution /executions /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-source-plugin/artifactId version2.1.2/version executions execution idattach-sources/id phaseverify/phase goals goaljar-no-fork/goal /goals /execution /executions /plugin This is what I'm doing in a pluginManagement section in my parent pom. See: http://maven.apache.org/plugins/maven-javadoc- plugin/faq.html#How_to_deploy_Javadoc_jar_file http://maven.apache.org/plugins/maven-source-plugin/usage.html HTH Thorsten - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How do I make a dependency both system and test scope?
In the light of idiocy you resort to complete and utter foolishness...
Where is your repository manager? Just deploy it there.
Friends don't let friends use maven without a repository manager
On Friday, 10 February 2012, laredotornado-3 laredotorn...@gmail.com
wrote:
Hi,
I'm using Maven 3.0.3. For bizarre reasons, our company has blocked
access
to a certain Maven repo, so I have chosen to load the dependency through
the
inclusion
dependency
groupIdorg.openqa.selenium.server/groupId
artifactIdselenium-server/artifactId
version2.0b3/version
scopesystem/scope
systemPath${project.basedir}/lib/selenium-server-standalone-2.0b3.jar/systemPath
/dependency
However, I only want this dependency referenced during the test phase.
How
do I make a dependency both available through a system scope and a test
scope?
Thanks, - Dave
--
View this message in context:
http://maven.40175.n5.nabble.com/How-do-I-make-a-dependency-both-system-and-test-scope-tp5473053p5473053.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: Are profiles in published POMs a supported feature?
They are the bastard son of satan. which is why adding dependencies via profiles is an anti-pattern people who do it give maven a bad name Take them out and shoot them. I may just have to thump psandoz on the shoulder really hard next time I see him if old jersey poms did that kind of thing... I know he's not at sun any more, which is why he won't get a shooting! On 9 February 2012 14:38, Peter Niederwieser pnied...@gmail.com wrote: The published POM for com.sun.jersey.jersey-test-framework:jersey-test-framework-core:1.11 (1) specifies additional dependencies in the cobertura and default profiles. Are profiles in published POMs an officially supported feature, and are they supposed to be resolved at consumption time? I wonder if that makes any sense, and whether tools like Ivy and Gradle could even support this (currently they don't). Cheers, Peter -- Peter Niederwieser Principal Engineer, Gradleware http://gradleware.com Creator, Spock Framework http://spockframework.org Twitter: @pniederw (1) http://search.maven.org/#artifactdetails%7Ccom.sun.jersey.jersey-test-framework%7Cjersey-test-framework-core%7C1.11%7Cjar -- View this message in context: http://maven.40175.n5.nabble.com/Are-profiles-in-published-POMs-a-supported-feature-tp5469611p5469611.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Are profiles in published POMs a supported feature?
I should clarify, Profiles in published poms are ok Provided they do not affect in any way the dependency tree. If they affect the dependency tree (either directly by adding dependencies, or indirectly by modifying properties which affect the dependency tree) then they are evil. There may be some rare cases where indirect dependency tree modification is ok but I have yet to see one. -Stephen On 9 February 2012 14:50, Stephen Connolly stephen.alan.conno...@gmail.com wrote: They are the bastard son of satan. which is why adding dependencies via profiles is an anti-pattern people who do it give maven a bad name Take them out and shoot them. I may just have to thump psandoz on the shoulder really hard next time I see him if old jersey poms did that kind of thing... I know he's not at sun any more, which is why he won't get a shooting! On 9 February 2012 14:38, Peter Niederwieser pnied...@gmail.com wrote: The published POM for com.sun.jersey.jersey-test-framework:jersey-test-framework-core:1.11 (1) specifies additional dependencies in the cobertura and default profiles. Are profiles in published POMs an officially supported feature, and are they supposed to be resolved at consumption time? I wonder if that makes any sense, and whether tools like Ivy and Gradle could even support this (currently they don't). Cheers, Peter -- Peter Niederwieser Principal Engineer, Gradleware http://gradleware.com Creator, Spock Framework http://spockframework.org Twitter: @pniederw (1) http://search.maven.org/#artifactdetails%7Ccom.sun.jersey.jersey-test-framework%7Cjersey-test-framework-core%7C1.11%7Cjar -- View this message in context: http://maven.40175.n5.nabble.com/Are-profiles-in-published-POMs-a-supported-feature-tp5469611p5469611.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Versions Maven Plugin 1.3.1 released
The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.3.1 NOTE: This is the *last* planned release that will support running on Maven 2.0.x and JRE 1.4 The Versions Plugin has the following goals. * versions:compare-dependencies compares the dependency versions of the current project to the dependency management section of a remote project. * versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match). * versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4 * versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT. * versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used. * versions:set can be used to set the project version from the command line. * versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version. * versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version. * versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version. * versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version. * versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version. * versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version. * versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version. * versions:commit removes the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. * versions:revert restores the pom.xml files from the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. The artifacts have been deployed to the mojo repository and will be mirrored to central. The Mojo Team. Release Notes - Maven 2.x Versions Plugin - Version 1.3.1 ** Bug * [MVERSIONS-174] - Loss of JRE 1.4 compatibility * [MVERSIONS-175] - NPE when running versions:display-plugin-updates Share and Enjoy[1] The Mojo Team [1] The Hitchhiker's Guide to the Galaxy: Share and Enjoy
[ANN] Versions Maven Plugin 1.3 released
The Mojo team is pleased to announce the release of the Versions Maven Plugin, version 1.3. NOTE: This is the last release line that will support running on Maven 2.0.x. NOTE: This version contains one method that requires JDK 1.5, version 1.3.1 of this plugin will be released tomorrow and that will run on JDK 1.4. Version 2.0 of the plugin will require Maven 2.2.1 and JDK 1.5. NOTE: One major change in this version is that the versions:display-plugin-updates goal has been modified to take into account the project and plugin's prerequisites, so that if you invoke it on a project that specifies a minimum of Maven 2.0.9, it will only suggest plugin updates that are compatible with that version of Maven... oh and it will also suggest what plugin updates are available if you increase the minimum version of Maven in your project's pom. The Versions Plugin has the following goals. * versions:compare-dependencies compares the dependency versions of the current project to the dependency management section of a remote project. * versions:display-dependency-updates scans a project's dependencies and produces a report of those dependencies which have newer versions available. * versions:display-plugin-updates scans a project's plugins and produces a report of those plugins which have newer versions available. * versions:display-property-updates scans a projectand produces a report of those properties which are used to control artifact versions and which properies have newer versions available. * versions:update-parent updates the parent section of a project so that it references the newest available version. For example, if you use a corporate root POM, this goal can be helpful if you need to ensure you are using the latest version of the corporate root POM. * versions:update-properties updates properties defined in a project so that they correspond to the latest available version of specific dependencies. This can be useful if a suite of dependencies must all be locked to one version. * versions:update-child-modules updates the parent section of the child modules of a project so the version matches the version of the current project. For example, if you have an aggregator pom that is also the parent for the projects that it aggregates and the children and parent versions get out of sync, this mojo can help fix the versions of the child modules. (Note you may need to invoke Maven with the -N option in order to run this goal if your project is broken so badly that it cannot build because of the version mis-match). * versions:lock-snapshots searches the pom for all -SNAPSHOT versions and replaces them with the current timestamp version of that -SNAPSHOT, e.g. -20090327.172306-4 * versions:unlock-snapshots searches the pom for all timestamp locked snapshot versions and replaces them with -SNAPSHOT. * versions:resolve-ranges finds dependencies using version ranges and resolves the range to the specific version being used. * versions:set can be used to set the project version from the command line. * versions:use-releases searches the pom for all -SNAPSHOT versions which have been released and replaces them with the corresponding release version. * versions:use-next-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the next release version. * versions:use-latest-releases searches the pom for all non-SNAPSHOT versions which have been a newer release and replaces them with the latest release version. * versions:use-next-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the next -SNAPSHOT version. * versions:use-latest-snapshots searches the pom for all non-SNAPSHOT versions which have been a newer -SNAPSHOT version and replaces them with the latest -SNAPSHOT version. * versions:use-next-versions searches the pom for all versions which have been a newer version and replaces them with the next version. * versions:use-latest-versions searches the pom for all versions which have been a newer version and replaces them with the latest version. * versions:commit removes the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. * versions:revert restores the pom.xml files from the pom.xml.versionsBackup files. Forms one half of the built-in Poor Man's SCM. The artifacts have been deployed to the mojo repository and will be mirrored to central. The Mojo Team. Release Notes - Maven 2.x Versions Plugin - Version 1.3 ** Bug * [MVERSIONS-99] - display-dependency-updates reports dependencies with ranges under wrong heading (when the range contains the latest version) * [MVERSIONS-114] - Explict versions inside child poms are updated if they are the same than the version in the parent pom * [MVERSIONS-117] - NPE in UseLatestSnapshotsMojo when allowMajorUpdates=true * [MVERSIONS-120] - NPE from DefaultArtifactVersion.parseVersion in
Re: How to ensure proper transitive dependencies
On 2 February 2012 16:17, Leon Rosenberg rosenberg.l...@gmail.com wrote: Hello, I have following question, I don't quite understand how to solve properly. I have 3 projects, A,B and C. A depends on B and C, and B depends on C. A requires at least C version 1.06. However, after a while C got a new feature which is now used in B. So in my situation A contains: B version 2.0 C version 1.0.6 pom of B (2.0) contains C version 1.0.14 When I build A, I'd expect 1.0.14 of C to be included through the dependency to B. However, the resulting war contains 1.0.6, which cause B 2.0 to malfunction, because it expects 1.0.14 of C. How can I resolve this issue, without manually version of C in the pom of A? two solutions immediately present themselves: 1. Remove C as a dependency from A (transitive will pull it in) or 2. Make B depend on C [1.0.14,) Note for option #2, most people consider version ranges evil, as they can cause non-reproducible builds and only really work when people use the major.minor.patch 3 segment version numbers without qualifiers. I'd go with option 1. If B ever decides to remove its dep on C, then your build of A will immediately break to tell you ;-) regards Leon - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: In-profile parent property loading inheritance works in Maven 2, not in Maven 2
On 30 January 2012 20:09, Shane StClair sh...@axiomalaska.com wrote:
Hello all,
I have a project with a parent pom and child modules. Configuration
properties are kept in a build.properties file and an overriding
custom.build.properties. The properties-maven-plugin is defined in the
You are off the reservation there already.
That plugin is against the Maven design, at least as far as property
inheritance is concerned, only bugs in Maven 2 may have let you away
with that for now.
parent pom to load these properties, and the plugin is inherited by the
child poms. Property substitution based on these files is used directly in
the parent and child poms and also for resource filtering.
One child pom has a deploy profile using the cargo-maven2-plugin. In Maven
2, property substitution works everywhere using this methodology. In Maven
3, it works everywhere except inside of the child pom's deploy profile. In
this case the substitution tokens are never replaced.
Parent:
project
...
modules
modulechild-module/module
/modules
properties
main.basedir${project.basedir}/main.basedir
/properties
...
build
plugins
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdproperties-maven-plugin/artifactId
version1.0-alpha-2/version
inheritedtrue/inherited
executions
execution
phaseinitialize/phase
goals
goalread-project-properties/goal
/goals
configuration
files
file${main.basedir}/build.properties/file
file${main.basedir}/custom.build.properties/file
/files
/configuration
/execution
/executions
/plugin
...
/plugins
/build
...
/project
Child:
project
parent
groupIdthe.group/groupId
artifactIdthe-parent/artifactId
version0.1-SNAPSHOT/version
/parent
modelVersion4.0.0/modelVersion
artifactIdchild-module/artifactId
packagingwar/packaging
properties
main.basedir${project.parent.basedir}/main.basedir
/properties
build
finalName${final.name}/finalName
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-war-plugin/artifactId
version2.1.1/version
configuration
filteringDeploymentDescriptorstrue/filteringDeploymentDescriptors
webResources
resource
directorysrc/main/webapp/directory
filteringtrue/filtering
/resource
resource
directorysrc/main/webapp/WEB-INF/directory
filteringtrue/filtering
targetPathWEB-INF/targetPath
/resource
/webResources
/configuration
/plugin
/plugins
/build
profiles
profile
iddeploy/id
build
finalName${final.name}/finalName
plugins
plugin
groupIdorg.codehaus.cargo/groupId
artifactIdcargo-maven2-plugin/artifactId
executions
execution
iddeploy-exec/id
phaseinstall/phase
goals
goaldeployer-undeploy/goal
goaldeployer-deploy/goal
/goals
/execution
/executions
configuration
container
containerId${deploy.tomcat.version}/containerId
typeremote/type
/container
configuration
typeruntime/type
properties
cargo.tomcat.manager.url
${deploy.tomcat.manager.url}
/cargo.tomcat.manager.url
cargo.remote.username
${deploy.tomcat.manager.username}
/cargo.remote.username
cargo.remote.password
${deploy.tomcat.manager.password}
/cargo.remote.password
/properties
Re: surefire report missing css, images
On 30 January 2012 19:01, Michael Norman michael.nor...@oracle.com wrote:
Running maven 3.0.4 via m2e (Maven Integration for Eclipse version
1.0.100.20110804-1717).
Here is my pom.xml file:
properties
maven-surefire-plugin.version2.11/maven-surefire-plugin.version
maven-surefire-report-plugin.version2.11/maven-surefire-report-plugin.version
jxr-maven-plugin.version2.3/jxr-maven-plugin.version
/properties
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version4.8.2/version
scopetest/scope
/dependency
/dependencies
build
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-plugin/artifactId
version${maven-surefire-plugin.version}/version
executions
execution
idtest/id
phasetest/phase
configuration
forkModeonce/forkMode
redirectTestOutputToFiletrue/redirectTestOutputToFile
includes
include**/AllTests.java/include
/includes
/configuration
goals
goaltest/goal
/goals
/execution
/executions
/plugin
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-report-plugin/artifactId
version${maven-surefire-report-plugin.version}/version
executions
execution
idgenerate-test-report/id
phasetest/phase
goals
goalreport/goal
/goals
/execution
/executions
/plugin
/plugins
/build
reporting
plugins
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-surefire-report-plugin/artifactId
version${maven-surefire-report-plugin.version}/version
/plugin
plugin
groupIdorg.codehaus.mojo/groupId
artifactIdjxr-maven-plugin/artifactId
version${jxr-maven-plugin.version}/version
/plugin
/plugins
/reporting
When I run 'mvn compile compiler:testCompile test', everything works (see
attach'd log)
OT,
You do understand how the Maven lifecycle works?
You do understand that you should just be doing mvn test
as
1. test is farther along the lifecycle than compile, so you are just
running up to compile twice in a row
2. compiler:testCompile is bound to the test-compile phase of the
lifecycle, which is helpfully before the test phase of the lifecycle
but in the 'target/site' directory, the surefire-report.html does not
render very nicely because
of the missing files under 'target/site/css' and 'target/site/images'
I've seen some discussion about this as part of issue
SUREFIRE-616http://jira.codehaus.org/browse/SUREFIRE-616,
but I'm not sure if
there is a fix other than adding the 'site' goal to the mvn invocation.
This generates about
a ~dozen or so files/directories, so its a bit overkill.
--
[image: Oracle] http://www.oracle.com
Mike Norman | Principal Software Designer
Phone: +6132884638 | Fax: +6132382818
Server Technologies | EclipseLink Product
Oracle Canada | 45 O'Connor Street, Suite 400, Ottawa, Ontario | K1P 1A4
[image: Hardware and Software, Engineered to Work
Together]http://www.oracle.com
[image: Oracle is committed to developing practices and products that help
protect the environment] http://www.oracle.com/commitment
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: How to parse JUnit report xml that causes build to pass/fail
Please take a look at the maven-failsafe-plugin, it is a version of surefire to cover your exact use case On 26 January 2012 19:36, swapsa...@gmail.com swapsa...@gmail.com wrote: Hi, I have been using Maven 2.2.1 for a while now and have used it successfully for multiple projects so far. I must say it is one the most sophisticated build system that is well thought and comprehensive in nature. I have 'maven'ized a project to a certain extent but we have an outstanding issue that is troubling developers. Take a deep breath as I explain this problem below... I'm trying to follow beautiful principal of maven lifecycle thoroughly and performing unit tests in 'test' phase and integration tests in 'integration-test' phase. Since its a webapp (war), I start/stop server during pre/post integration-phases. During this 'integration-test', I run a series of Java JUnit tests that asserts different features of server. If one of the test fails, the main maven build comes out saying.. [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. And this is very useful for me and treasure this logic very much. Life is good so far and here comes the problem. Along with these Java based JUnit integration tests, I also have some other non-Java, non-JUnit based tests (actually phantomjs/Jasmine) which validates some other aspects of server. And this external test executable exports its test results in a xml file that is compatible with JUnit, described here http://www.junit.org/node/399. Note that this is NOT a junit test and maven runtime does not know abt how the test are ran, rather external test exec just exports a xml file that is fully JUnit result compatible. And if there is a failure reported in this exported xml file, I need to cause the build to fail like above. That means I want maven to parse this report xml, treat it similar to any other tests and cause build to fail. Currently my build says 'Successful' even if there are test failures in the exported xml file. Note: Similar feature exists in the CI tools like Jenkins/TeamCity but its not something that developer can use locally. I wish simple 'mvn clean install' to work with my exported xml file. Note: Surefire report-only goal does generates the reports with all the test xml files I have and shows the test failure in the HTML report. But this does not cause final build to fail upon test failures. Q. Is there a way to tell maven (via plugin or something) that look for test failures in the test xml file and declare the build pass/fail? Appreciate any help/clues/suggestions. Thanks you. Deep 'Maven'er :) -- View this message in context: http://maven.40175.n5.nabble.com/How-to-parse-JUnit-report-xml-that-causes-build-to-pass-fail-tp5433750p5433750.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: How to parse JUnit report xml that causes build to pass/fail
Sorry, my bad. I mis-understood. You can just write your own plugin, very easy to do On 26 January 2012 22:58, Stephen Connolly stephen.alan.conno...@gmail.comwrote: Please take a look at the maven-failsafe-plugin, it is a version of surefire to cover your exact use case On 26 January 2012 19:36, swapsa...@gmail.com swapsa...@gmail.com wrote: Hi, I have been using Maven 2.2.1 for a while now and have used it successfully for multiple projects so far. I must say it is one the most sophisticated build system that is well thought and comprehensive in nature. I have 'maven'ized a project to a certain extent but we have an outstanding issue that is troubling developers. Take a deep breath as I explain this problem below... I'm trying to follow beautiful principal of maven lifecycle thoroughly and performing unit tests in 'test' phase and integration tests in 'integration-test' phase. Since its a webapp (war), I start/stop server during pre/post integration-phases. During this 'integration-test', I run a series of Java JUnit tests that asserts different features of server. If one of the test fails, the main maven build comes out saying.. [ERROR] BUILD FAILURE [INFO] [INFO] There are test failures. And this is very useful for me and treasure this logic very much. Life is good so far and here comes the problem. Along with these Java based JUnit integration tests, I also have some other non-Java, non-JUnit based tests (actually phantomjs/Jasmine) which validates some other aspects of server. And this external test executable exports its test results in a xml file that is compatible with JUnit, described here http://www.junit.org/node/399. Note that this is NOT a junit test and maven runtime does not know abt how the test are ran, rather external test exec just exports a xml file that is fully JUnit result compatible. And if there is a failure reported in this exported xml file, I need to cause the build to fail like above. That means I want maven to parse this report xml, treat it similar to any other tests and cause build to fail. Currently my build says 'Successful' even if there are test failures in the exported xml file. Note: Similar feature exists in the CI tools like Jenkins/TeamCity but its not something that developer can use locally. I wish simple 'mvn clean install' to work with my exported xml file. Note: Surefire report-only goal does generates the reports with all the test xml files I have and shows the test failure in the HTML report. But this does not cause final build to fail upon test failures. Q. Is there a way to tell maven (via plugin or something) that look for test failures in the test xml file and declare the build pass/fail? Appreciate any help/clues/suggestions. Thanks you. Deep 'Maven'er :) -- View this message in context: http://maven.40175.n5.nabble.com/How-to-parse-JUnit-report-xml-that-causes-build-to-pass-fail-tp5433750p5433750.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: M2-Job: mvn clean install site chicken egg problem for multi-module project
Try pipe. I think a long time ago i added support for pipe - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On Jan 24, 2012 8:40 p.m., Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello everybody, for a fresh multi-module maven project, invoking clean install site will not suceed, as site in the parent will fail due to missing javadoc parts from the modules, see: http://huschteguzzel.de/hudson/job/testlink-junit/14/console (the project may be found at https://github.com/1and1/testlink-junit/) --- snip --- mavenExecutionResult exceptions not empty message : Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project tljunit-parent: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin cause : failed to get report for org.apache.maven.plugins:maven-javadoc-plugin Stack trace : org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-site-plugin:3.0:site (default-site) on project tljunit-parent: failed to get report for org.apache.maven.plugins:maven-javadoc-plugin at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) --- snap --- I have to: - execute clean install once and change it back to clean install site or - execute clean install in the M2 configuration and add a Maven Post Step site (this however will of course not show up in the Executed Mojo section. With a freestyle project this is not a biggy as I could just configure two Maven steps. This is of course consistent with the execution on command line, when the project was never installed before: mvn clean install site will fail and I have to fall back to something like: mvn clean install ; mvn site I think with CruiseControl invoking multiple, serial executions of Maven were available by separating the phases by a pipe (|) symbol. Does anyone know a solution for this chicken egg problem in Jenkins (or on the command line)? Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: custom unique version
On 23 January 2012 13:25, Ron Wheeler rwhee...@artifact-software.comwrote: You could reach out to the Hudson user community. I do not use Hudson although many people here do use Maven and Hudson together. Most use Jenkins rather than that scurrilous fork Hudson ;-) We have a large project with over 90 maven projects of which 70 produce artifacts based on our code. We have a small team but have some rules about releases and SNAPSHOTS. We use Releases in a conventional way. SNAPSHOTs get deployed to Nexus with a spec and a warranty from the person doing the deploy. The spec may be verbal or in an e-mail I have deployed a new SNAPSHOT of Web Service x that has dummy database access and always returns 7 when you ask for a record count and returns testrecorda regardless of the search critera on a lookup. I have tested this and it works If you are a consumer of x, you have to decide if you want to keep using the older SNAPSHOT (only had the record count function, for example) or fix your code to take advantage of the increased/changed functionality(lookup stub partially working) included in the new version. This is a lot different from the workflow when using Hudson. I don't really understand the Hudson philosophy and how you avoid the human communication and management required to manage a multi-person project that uses stubs and partially functional modules in the process of developnment. I don't really understand why people are so afraid of making releases. Personally, I _never_ deploy -SNAPSHOTs to remote repos, and I try to never consume them also. Ron On 23/01/2012 2:36 AM, Thomas Scheffler wrote: Am 20.01.2012 16:27, schrieb Ron Wheeler: Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Hi Ron, did you faced that problem already? What is your solution or what would be a general solution of keeping track unique version numbers? Through Hudson I run tests in a core library, the SNAPSHOT library, that got releases from time to time. Between those releases a SNAPSHOT is deployed to a snapshot repository from where another Hudson project gets this library and run integration test. Some more projects rely on this core library and it would be a good deal to get the unique version number right from the library. For now we embed the revision number from scm into the library. So you can look in hudson when this revision was tested and look in the console log the unique version number. These are a lot of manual task to to. I want this to be determined in a easier way. So if you could be please so kind to point me to what you say is the best practice here... regards Thomas On 20/01/2012 10:14 AM, Stephen Connolly wrote: 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique version number into the JAR manifest? OK, let me put this in another form, so you might understand what I was asking you. I know how to put custom keys and values into a manifest. That's the yeah I know that above. The question should have been understand like this: How can I acquire the unique version number that makes of 1.0-SNAPSHOT locally 1.0-20120120.121003-6 remotely, so that I can put it into the JAR manifest of the JAR file that is deployed in a remote repository? That string is decided when deploy:deploy is invoked, so you cannot put that string in. Or in other words: The substring 20120120.121003-6 is changing at every deployment. I want that part in the manifest. Thomas http://bit.ly/zijlWA See the example on that screen... See how properties are substituted in? Then you need to go to http://to.justpitch.me/yiTp6D -Stephen Thomas Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**u**ni-jena.de http://uni-jena.de thomas.scheffler@**uni-jena.de
Re: custom unique version
See when Maven is the build tool, I usually find it easier to just checkout my -SNAPSHOT deps locally and build them. That way I have complete control over when they get updated. On 23 January 2012 15:17, Ron Wheeler rwhee...@artifact-software.comwrote: We use SNAPSHOTs extensively and deploy them when they are ready to be used by a consuming project. For example, we often have one person working on the database and the DAOs, another person working on the Web services and a third person working on the GUI components. The GUI person often needs a stub of the web service very early in the process so that they can produce mockups and get started producing real code. The person doing the web service may want parts of the DAO stubbed in order to work on the web service logic. They might also request new queries or other functional changes to the DAO as the Web Service gets implemented which will cause a new SNAPSHOT of the DAO to be required. Over a week, the team might deploy several versions of the SNAPSHOTs with increasing functionality. The person doing the consuming has to be aware of new deployments so that their tests make sense. If the web service was stubbed and returned 7 for the record count, the person writing the GUI will be surprised when it starts to show 3 (from the actual database) unless they have been informed in advance by the person deploying the revised Web Service. They may in fact ask to have the Web Service deployment delayed until the GUI can be fixed to handle the revised specification or they get through a customer presentation. Ron On 23/01/2012 9:32 AM, Stephen Connolly wrote: On 23 January 2012 13:25, Ron Wheeler rwhee...@artifact-software.comwrote: You could reach out to the Hudson user community. I do not use Hudson although many people here do use Maven and Hudson together. Most use Jenkins rather than that scurrilous fork Hudson ;-) We have a large project with over 90 maven projects of which 70 produce artifacts based on our code. We have a small team but have some rules about releases and SNAPSHOTS. We use Releases in a conventional way. SNAPSHOTs get deployed to Nexus with a spec and a warranty from the person doing the deploy. The spec may be verbal or in an e-mail I have deployed a new SNAPSHOT of Web Service x that has dummy database access and always returns 7 when you ask for a record count and returns testrecorda regardless of the search critera on a lookup. I have tested this and it works If you are a consumer of x, you have to decide if you want to keep using the older SNAPSHOT (only had the record count function, for example) or fix your code to take advantage of the increased/changed functionality(lookup stub partially working) included in the new version. This is a lot different from the workflow when using Hudson. I don't really understand the Hudson philosophy and how you avoid the human communication and management required to manage a multi-person project that uses stubs and partially functional modules in the process of developnment. I don't really understand why people are so afraid of making releases. Personally, I _never_ deploy -SNAPSHOTs to remote repos, and I try to never consume them also. Ron On 23/01/2012 2:36 AM, Thomas Scheffler wrote: Am 20.01.2012 16:27, schrieb Ron Wheeler: Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Hi Ron, did you faced that problem already? What is your solution or what would be a general solution of keeping track unique version numbers? Through Hudson I run tests in a core library, the SNAPSHOT library, that got releases from time to time. Between those releases a SNAPSHOT is deployed to a snapshot repository from where another Hudson project gets this library and run integration test. Some more projects rely on this core library and it would be a good deal to get the unique version number right from the library. For now we embed the revision number from scm into the library. So you can look in hudson when this revision was tested and look in the console log the unique version number. These are a lot of manual task to to. I want this to be determined in a easier way. So if you could be please so kind to point me to what you say is the best practice here... regards Thomas On 20/01/2012 10:14 AM, Stephen Connolly wrote: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique
Re: Managing module dependency in Maven parallel build
add a dependency of type zip and scope test On 20 January 2012 08:38, Ashish Srivastava ashis...@yahoo.com wrote: Hi, (I just subscribed to the mailing list so would appreciate if you could reply directly to my email address too) I am trying out the parallel build feature of Maven 3. My project is divided into multiple modules and one of the module generates a deployable zip file. Another module takes this zip file and runs some deployment and performance tests. This worked with sequential build but with the parallel build the build fails because most of the time the module could not find the zip file because it is picked up before the zip could be created. As the module that generates the zip file does not produce a jar file having a dependency to this module would not work (or so as per my understanding). Is there a way in Maven 3 parallel build that such module dependency can be instructed? Appreciate your help, -Ashish - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: custom unique version
It cannot. That is part of the spec for the layout of a Maven repository. -Stephen 2012/1/20 Thomas Scheffler thomas.scheff...@uni-jena.de: Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: custom unique version
You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On Jan 20, 2012 10:45 a.m., Thomas Scheffler thomas.scheff...@uni-jena.de wrote: Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: custom unique version
2012/1/20 Thomas Scheffler thomas.scheff...@uni-jena.de: Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique version number into the JAR manifest? OK, let me put this in another form, so you might understand what I was asking you. I know how to put custom keys and values into a manifest. That's the yeah I know that above. The question should have been understand like this: How can I acquire the unique version number that makes of 1.0-SNAPSHOT locally 1.0-20120120.121003-6 remotely, so that I can put it into the JAR manifest of the JAR file that is deployed in a remote repository? That string is decided when deploy:deploy is invoked, so you cannot put that string in. Or in other words: The substring 20120120.121003-6 is changing at every deployment. I want that part in the manifest. Thomas http://bit.ly/zijlWA See the example on that screen... See how properties are substituted in? Then you need to go to http://to.justpitch.me/yiTp6D -Stephen Thomas Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: fail-safe plugin does not see test
where is that test?
is it in src/test/java? it should be somewhere in src/test/java or it
will not be picked up
On 19 January 2012 10:04, kooper sergeysach...@list.ru wrote:
Hi,
I'm using fail-safe plugin for integration tests but it seems that plugin
does not see the tests. I have DeviceResourceIT.java that uses junit in it
it has test method IsRegisteredTest() but fail-safe says 0 test run:
@Test
public void IsRegisteredTest(){
logger.debug(isRegisteredTest started);
ClientResponse clientResponse =
webClient.performGet(http://localhost:8080/app/Device/; +
WebClientImpl.TEST_DEVICE);
...
logger.debug(isRegisteredTest completed);
}
Here is the plugin configuration:
plugin
groupIdorg.apache.maven.plugins/groupId
artifactIdmaven-failsafe-plugin/artifactId
version2.11/version
configuration
skipTestsfalse/skipTests
encodingutf-8/encoding
/configuration
executions
Simplify your life, use the default phases and have one execution
execution
idintegration-test/id
goals
goalintegration-test/goal
goalverify/goal
/goals
/execution
/executions
Why are you adding the dependency here? it should be a (test scoped)
dependency of your project, not the plugin
dependencies
dependencygroupIdjunit/groupId
artifactIdjunit/artifactId
version4.8.2/version
/dependency
/dependencies
/plugin
I've tried different configs added include tags, surfire dependency etc, but
it stills says:
[INFO] --- maven-failsafe-plugin:2.11:integration-test (integration-test) @
app---
[INFO] Failsafe report directory: D:\Projects\app\target\failsafe-reports
---
T E S T S
---
Results :
Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
[INFO]
[INFO] --- cargo-maven2-plugin:1.1.4:stop (stop-container)
What could be the issue here? Can anyone help with it?
Thanks in advance.
--
View this message in context:
http://maven.40175.n5.nabble.com/fail-safe-plugin-does-not-see-test-tp5157259p5157259.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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: fail-safe plugin does not see test
On 19 January 2012 11:31, kooper sergeysach...@list.ru wrote: hm, I've tried moving class to src/test/java folder once more and it works now. Not sure why it wasn't previously, so thank you very much for advice. BTW can I configure fail-safe to check my directory also? failsafe looks for .class files in target/test-classes you can configure failsafe to look elsewhere, but then you need to configure compiler-m-p to compile your classes from your custom location into your custom location. failsafe uses the different naming scheme as a way around having to have different layers. hence, it's tests are *IT, etc while surefire's are *Test, etc -- View this message in context: http://maven.40175.n5.nabble.com/fail-safe-plugin-does-not-see-test-tp5157259p5157424.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: plugin dependency
On 19 January 2012 11:53, Julien Ruaux jru...@gmail.com wrote: Hi, I'm trying to get my plugin to automatically call another one (the JAXB XJC Maven plugin). Here is what users of my plugin currently have to write: project build plugins plugin groupIdcom.sun.tools.xjc.maven2/groupId artifactIdmaven-jaxb-plugin/artifactId version1.1.1/version executions execution goals goalgenerate/goal /goals /execution /executions configuration schemaDirectoryResources/Schemas/schemaDirectory /configuration /plugin plugin groupIdsample.plugin/groupId artifactIdmy-maven-plugin/artifactId version1.0-SNAPSHOT/version executions execution phaseprocess-classes/phase goals goalgenerate/goal /goals /execution /executions configuration generate.../generate /configuration /plugin /plugins /build /project This is what I would like my user's pom to look like : project build plugins plugin groupIdsample.plugin/groupId artifactIdmy-maven-plugin/artifactId version1.0-SNAPSHOT/version configuration schemaDirectoryResources/Schemas/schemaDirectory generate.../generate /configuration /plugin /plugins /build /project Is that feasible? No. 1. Unless you define a custom packaging, the default lifecycle is what it is, and cannot be overridden, so you could do project ... packagingmy-packaging/packaging ... build plugins plugin groupIdsample.plugin/groupId artifactIdmy-maven-plugin/artifactId version1.0-SNAPSHOT/version configuration schemaDirectoryResources/Schemas/schemaDirectory generate.../generate /configuration extensionstrue/extensions !-- need this -- /plugin /plugins /build /project and that would bind both your plugin's execution and the other plugin's execution to your packaging's lifecycle An alternative would be to define your own lifecycle and execute it as a pre-req'd forked lifecycle... you'd still need people to add an executions to get your goal to execute, but that would be the only execution... the down side is that this is in a forked lifecycle Thanks for your help, Julien - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven plugin configuration and binding execution to a phase/goal
On 18 January 2012 13:32, C Potter cabin.pot...@gmail.com wrote:
Hi Manfred,
I've already posted my Android related questions on the Android Dev forum
yesterday that motivated the need for this.
These question here remain outstanding and all pertain solely to Maven...
can someone please answer these...
(1) Configuration parameters - just using aVal did not work! There is some
other problem below that I cannot spot. Do I need a maven plugin xml to
make this happen?
(2) How do I bind to the right phase/goal without needing executions?
You don't... unless you implement a custom packaging type
Thanks!
On Wed, Jan 18, 2012 at 12:03 AM, Manfred Moser manf...@mosabuam.comwrote:
On 12-01-17 07:24 PM, Jeff Trent wrote:
I am stuck on two things while writing a plugin: (1) configuration,
and (2) binding to the right goal/phase automatically. I am using
Maven 3.0.3, and trying to use the plugin for APK (android) packaged
modules.
(1) configuration.
/**
* @phase compile
* @goal myGoal
* @requiresDependencyResolution runtime
*/
public class MyMojo extends AbstractMojo {
/**
* @parameter expression=${myGoal.aVal} default-value=defaultVal
*/
String aVal;
…
}
And in my pom using the plugin:
build
plugins
plugin
groupIdmy.package/groupId
artifactIdmy-plugin-test/**artifactId
version1.0-SNAPSHOT/**version
configuration
aValmyConfiguredValue/aVal
/configuration
executions
execution
phasegenerate-resources/
**phase
goals
goalmyGoal/goal
/goals
/execution
/executions
/plugin
...
The problem is that I always get the default value instead of the
configured value. What am I missing?
Am I required to provide the plugin.xml file, even for this simple case?
(2) Binding to the right goal/phase.
Ideally in the above example I don't want to specifyexecutions for
my plugin. But I can't figure out how to vary my annotations to get
it to work.
Can someone point out the problem, or a simple concrete example that
demonstrates this case please?
Thanks,
CP
The expression should just be aVal... btw. what are you trying to do that
the Android Maven Plugin does not do? You could implement the feature as a
mojo there become part of that strong community..
manfred
--**--**-
To unsubscribe, e-mail:
users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Committing non-POM files during release:prepare?
in http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#completionGoals invoke scm:add Though I am pretty sure all unmodified files which are already in SCM get committed by default On 17 January 2012 14:47, Andrew Todd andrew.todd...@gmail.com wrote: I'm fairly certain the answer to the question below is no, but I'm wondering if anyone can definitively say either way. Thanks. On Mon, Jan 9, 2012 at 3:02 PM, Andrew Todd andrew.todd...@gmail.com wrote: Maven 2.2, release plugin. During the preparationGoals, I'm modifying a .properties file that references the Maven project version. When the POM files get committed to Subversion after the preparationGoals have completed, I need this .properties file to get committed as well. Otherwise the release:perform step will fail. Is this possible? Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Committing non-POM files during release:prepare?
sorry yeah, completion goals is for after starting the next version. you can do the same trick in preparation goals though - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 17 Jan 2012 18:36, Andrew Todd andrew.todd...@gmail.com wrote: Thanks, I somehow missed completionGoals before. However, it doesn't really seem to do what's necessary. Looking at my build log, I can see that the source code is being tagged and committed before completionGoals runs. Not to mention that I'm not sure scm:add is the right command, since my .properties file already exists in the repository. Looking at scm:checkin. On Tue, Jan 17, 2012 at 9:55 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: in http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#completionGoals invoke scm:add Though I am pretty sure all unmodified files which are already in SCM get committed by default On 17 January 2012 14:47, Andrew Todd andrew.todd...@gmail.com wrote: I'm fairly certain the answer to the question below is no, but I'm wondering if anyone can definitively say either way. Thanks. On Mon, Jan 9, 2012 at 3:02 PM, Andrew Todd andrew.todd...@gmail.com wrote: Maven 2.2, release plugin. During the preparationGoals, I'm modifying a .properties file that references the Maven project version. When the POM files get committed to Subversion after the preparationGoals have completed, I need this .properties file to get committed as well. Otherwise the release:perform step will fail. Is this possible? Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-metadata.xml : release vs. latest
1. Both of these tags are deprecated because they are a load of crap and useless. 2. Here is what they mean: LATEST = The most recently deployed version RELEASE = The most recently deployed non -SNAPSHOT version Crappy aren't they! 3. Versions-maven-plugin does not pay any heed to those two tags 4. Maven 3.x does not pay any heed to those tags 5. They were meant for plugins only not regular dependencies. -Stephen On 17 January 2012 22:31, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello, what is the difference between these two tags? Say I deploy two versions 1.1 and 1.2 in this order. What should I expect for release and latest? My expectation would be to see 1.2 for both. Say I deploy 1.2 and later on 1.1. Now my expectation would be 1.2 for latest and 1.1 for release. Do plugins like the versions-maven-plugin or requests for LATEST in e.g. Nexus read this information or do they use the natural order (1.2 1.1) for getting latest? Could someone please shed a light :-D . Regards Mirko -- Sent from my phone http://illegalstateexception.blogspot.com http://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Settings-file and invoker-plugin
Most people use invoker to run integration tests of their maven plugins. As such, when running integration tests, you typically will have a test settings.xml so that the test environment will be constant. There is the issue of when you are behind a proxy, to solve this issue (as sometimes you need absolute control over the test env settings) there is mrm-maven-plugin @ mojo, that fires up a local Mock Repository Manager which will use your settings.xml to retrieve artifacts not available in your local repository so that the invoker based tests can still have the required environment, but work behind a proxy. What is your use-case? On 16 January 2012 08:43, Asmann, Roland roland.asm...@adesso.at wrote: Hi all, When running my projects on Jenkins, I need to set the settings-file (-s /path/to/settings.xml). I've hit my toes a couple of times now on the fact that I than also have to set the settings-file for the invoker-plugin (-Dinvoker.settingsFile=/path/to/settings.xml). Why doesn't the invoker use the file that was given with -s? I can understand that it takes the default settings when no configuration is give, but having the plugin actually use a different settings-file when running Maven with an explicit settings-file is kind of weird. Anyway, is there a way to get the invoker-plugin to use the settings-file that I set at the command-line? Thanks, -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Settings-file and invoker-plugin
Please try mrm-maven-plugin... you'll be pleasantly surprised... best example is the current trunk of versions-maven-plugin @ mojo On 16 January 2012 15:08, Asmann, Roland roland.asm...@adesso.at wrote: My use-case is also running integration tests. However, I don't want to have several different settings.xml files (unless it becomes necessary). So, I created one that works for me (user/pw on servers, proxy, repositories -- especially using the 'normal' local repo as a remote for the invoker) and had this copied onto our Jenkins. Now, I use these settings in both my normal builds and my invoker integration-tests. So, what I would like, is when running Maven with the -s command, the invoker should pick this up as the default settings. Or if there is a way to get the location of the settings.xml file using a variable, I can configure my invoker-plugin to use it automatically. Is there some way to solve this or will I just have to live with adding 2 parameters when running Maven? On 16.01.2012 10:12, Stephen Connolly wrote: Most people use invoker to run integration tests of their maven plugins. As such, when running integration tests, you typically will have a test settings.xml so that the test environment will be constant. There is the issue of when you are behind a proxy, to solve this issue (as sometimes you need absolute control over the test env settings) there is mrm-maven-plugin @ mojo, that fires up a local Mock Repository Manager which will use your settings.xml to retrieve artifacts not available in your local repository so that the invoker based tests can still have the required environment, but work behind a proxy. What is your use-case? On 16 January 2012 08:43, Asmann, Roland roland.asm...@adesso.at wrote: Hi all, When running my projects on Jenkins, I need to set the settings-file (-s /path/to/settings.xml). I've hit my toes a couple of times now on the fact that I than also have to set the settings-file for the invoker-plugin (-Dinvoker.settingsFile=/path/to/settings.xml). Why doesn't the invoker use the file that was given with -s? I can understand that it takes the default settings when no configuration is give, but having the plugin actually use a different settings-file when running Maven with an explicit settings-file is kind of weird. Anyway, is there a way to get the invoker-plugin to use the settings-file that I set at the command-line? Thanks, -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org -- Roland Asmann Senior Software Engineer adesso Austria GmbH Floridotower 26. Stock T +43 1 2198790-27 Floridsdorfer Hauptstr. 1 F +43 1 2198790-927 A-1210 Wien M +43 664 88657566 E roland.asm...@adesso.at W www.adesso.at - business. people. technology. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: mavem-war-plugin packagingExcludes regex not working
find() just means that there is a partial match, but you need a complete match (i.e. the match() column needs to say yes) On 16 January 2012 15:49, mschipperheyn m.schipperh...@gmail.com wrote: Your suggestion doesn't work. BTW, I do see a Yes in the column find() in the example you are referring to, or am I reading this wrong? -- View this message in context: http://maven.40175.n5.nabble.com/mavem-war-plugin-packagingExcludes-regex-not-working-tp5139981p5149055.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: 'version' contains an expression but should be a constant. Better way to add a new version?
here is why this is a bad plan.
the pom that gets deployed will not have the property value resolved, so
anyone depending on that pom will pick up the dependency as being the
string uninterpolated with the ${ } and much hilarity will ensue in your
build process.
in maven 2.1.0 and/or 2.2.0 an attempt was made to deploy poms with
resolved properties... this broke more than expected, which is why those
two versions are not recommended, 2.2.1 being the recommended 2.x version.
best bet would be
mvn versions:set mvn deploy versions:rollback
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On 15 Jan 2012 15:31, Jose Vicente Nunez Zuleta und...@stupidzombie.com
wrote:
Hi,
I want to compile and deploy release artifacts on daily basis to my Maven
repository, each version different from the other; Ideally I want to setup
a property to do this but Maven complains very strongly about it:
Macintosh:walker josevnz$ mvn package -Dwalker.version=20120115
[INFO] Scanning for projects...
[WARNING]
[WARNING] Some problems were encountered while building the effective
model for com.stupidzombie:walker:jar:20120115
[WARNING] 'version' contains an expression but should be a constant. @
com.stupidzombie:walker:${walker.version},
/Users/josevnz/Documents/stupidzombie/kenai/stupidzombie~source-code-repository/branches/walker/pom.xml,
line 6, column 12
[WARNING]
[WARNING] It is highly recommended to fix these problems because they
threaten the stability of your build.
[WARNING]
[WARNING] For this reason, future Maven versions might no longer support
building such malformed projects.
[WARNING]
[INFO]
[INFO]
[INFO] Building walker 20120115
[INFO]
[INFO]
So it seems that I cannot use a variable on the version tag in my pom.
What is the right way to do this?:
?xml version=1.0?
project 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/maven-4.0.0.xsd;
modelVersion4.0.0/modelVersion
groupIdcom.stupidzombie/groupId
artifactIdwalker/artifactId
version${walker.version}/version
packagingjar/packaging
namewalker/name
urlhttp://stupidzombie.com/url
Thanks in advance,
--Jose
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: Help with installing a non-maven jar in local repo .
Step 1. Download Nexus OSS (i.e. free) Step 2. Run Nexus Step 3. Configure your settings.xml to point to Nexus Done. Done. Done. NOTE 1: Does not have to be Nexus, there are others: Artifactory, Archivia, etc. I only mention Nexus OSS because: 1. it's free, 2. it's very low footprint in terms of memory. NOTE 2: Artifactory provide a 30 day free trial of cloud based repo hosting if you don't want to manage your own repo manager yourself. I only mention Artifactory because I know they have cloud based repo hosting. NOTE 3: I work for CloudBees, not Sonatype nor JFrog. My opinions are my own and not those of my employers On 13 January 2012 13:03, vvkbtnkr vvkbt...@yahoo.com wrote: I am aware of the repo manager concept, but setting it up is more work than what I want for the quick-fire poc that I am working on, would be reaally helpful if some one can point out the mistake in the pom snippet posted earlier and help me fix that ... -- View this message in context: http://maven-users.828.n2.nabble.com/Help-with-installing-a-non-maven-jar-in-local-repo-tp7182923p7183920.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 - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Required goal not found
different versions of the plugin you need to specify the version of the plugin you are asking help about as the same version you are using otherwise it answers for thew latest version On 12 January 2012 15:51, Adam Dyga ad...@tlen.pl wrote: Hello, I have some problems with goals not found. When I execute: mvn help:describe -DgroupId=org.apache.maven.plugins -DartifactId=maven-dependency-plugin among many goals I get: ... dependency:get Description: Downloads a single artifact transitively from the specified remote repositories. Caveat: will always check the central repository defined in the super pom. You could use a mirror entry in your settings.xml ... dependency:help Description: Display help information on maven-dependency-plugin. Call mvn dependency:help -Ddetail=true -Dgoal=goal-name to display parameter details. ... But if I execute mvn dependency:help or mvn dependency:get I get: [INFO] Searching repository for plugin with prefix: 'dependency'. [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] Required goal not found: dependency:help in org.apache.maven.plugins:maven-dependency-plugin:2.0 Is this normal? This happens not only with dependency plugin but others too. On the other hand dependency:list (for instance) works fine. My Maven version is: Apache Maven 2.2.1 (r801777; 2009-08-06 21:16:01+0200) Java version: 1.6.0_30 Java home: c:\\jdk1.6.0_30\jre Default locale: de_DE, platform encoding: Cp1252 OS name: windows xp version: 5.1 arch: x86 Family: windows Regards, AD - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Upgrade from Maven 2.0.7 to 2.1.0
do NOT use maven 2.1.0 or 2.2.0 2.2.1 is safe, i would seriously consider going as far as 3.0.3 as it is mostly a drop in replacement, with very few regressions and some serious bugs fixed. but do NOT use maven 2.1.0 or 2.2.0 - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 12 Jan 2012 22:30, LennyB le...@releaseonellc.com wrote: In testing an upgrade from Maven 2.0.7 to Maven 2.1.0 we are getting build errors. Apparently Maven 2.1.0 has stricter checking. The problem is the version (Internal version) in the META-INF/maven/plugin.xml and META-INF/maven/group/artifactId/pom.xml does not match the version (MAR version) of the artifact as it is stored in the Maven Repository. (hope that makes sense) == Error message: [INFO] Internal error in the plugin manager getting plugin 'groupId:artifactId': Plugin 'groupId:artifactId:MAR version' has an invalid descriptor: 1) Plugin's descriptor contains the wrong version: Internal version = Is there a way to execute Maven 2.1.0 to not perform this check? Basically, don't want to fix all the inconsistent internal (to the artifact) pom.xml and plugin.xml files. TIA! -- View this message in context: http://maven.40175.n5.nabble.com/Upgrade-from-Maven-2-0-7-to-2-1-0-tp5140655p5140655.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: releasing a multi-modult project
assuming that the project that succeeds is the aggregator root, everything is fine. prepare runs on the aggregator root and tags from that root. just run perform and it will check out all the modules and release them. if it is not the aggregator root, you may have to release each scm root separately. - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 11 Jan 2012 00:02, Greg Babcock greg.babc...@testadvantagesoftware.com wrote: I inherited a multi-module project from someone that is no-longer with the company. I have Maven experience, but not with multi-module projects. Release prepare is succeeding for the first module, and is skipping the remainder of the modules. How do I get release prepare to prepare all modules? NFO] [INFO] Reactor Summary: [INFO] [INFO] Production . SUCCESS [13.131s] [INFO] Hibernate Service .. SKIPPED [INFO] Production Commons . SKIPPED [INFO] Host Adapter ... SKIPPED [INFO] Web Service Host .. SKIPPED [INFO] Web Service Client SKIPPED [INFO] File Host Adapter Service .. SKIPPED [INFO] HostAdapterService SKIPPED [INFO] Socket Host Adapter Service SKIPPED [INFO] Engineering Client Service SKIPPED [INFO] Standard Service ... SKIPPED [INFO] High Availability Service .. SKIPPED [INFO] Production Web Application . SKIPPED [INFO] Step One ... SKIPPED [INFO] Production Utilities ... SKIPPED [INFO] Production License Creator . SKIPPED [INFO] Configuration Service .. SKIPPED [INFO] [INFO] BUILD SUCCESS [INFO] [INFO] Total time: 13.917s [INFO] Finished at: Tue Jan 10 17:51:03 EST 2012 [INFO] Final Memory: 5M/15M Thanks, GB
Re: How to run a maven goal when there is tests failures?
you may have to override the default phases, disable surefire (as you cannot unbind from lifecycle), and change the includes pattern for failsafe to the surefire one. if you do the above, should have no side effects other than your intended as they both use the same back end - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 11 Jan 2012 07:32, Xavier S. xavier.seign...@gmail.com wrote: :) Sorry, I missed your answer in the noise! I'll give it a try and let you know. (I hope it won't have side effects using failsafe rather than surefire). Regards, Xavier 2012/1/10 Stephen Connolly stephen.alan.conno...@gmail.com given that nobody else bothered to read the original question, it does not surprise me that nobody bothered to read my original answer of using failsafe ;-) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 10 Jan 2012 18:16, Stephen Connolly stephen.alan.conno...@gmail.com wrote: use failsafe. parse the failsafe results yourself... if they show a test failure, do your special thing then let failsafe verify stop the build - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 10 Jan 2012 16:58, Xavier S. xavier.seign...@gmail.com wrote: Thanks Guillaume! That's exactly what I want to do. So people, any idea? Regards, Xavier 2012/1/10 Guillaume Polet guillaume.po...@gmail.com Tell me if I am wrong Xavier, but I think that what he would like to do is perform something special when the tests fail, not just skip them or not fail the build. My guess would be that he is expecting some kind of on failure/on tests failure phase where he could attach other maven plugins to perform alternate behaviour. Unfortunately I have no idea on how this could be done. Probably using Ant or by writing your own plugin, but I find both solutions quite poor. Maybe Maven is not the tool to be used to perform this. Although you can do a lot of things with Maven, sometimes bending its original objectives too far away is just cumbersome and counter-productive /(not sure this english, btw). /Cheers, Guillaume Le 10/01/2012 17:22, Jeff MAURY a écrit : what about http://maven.apache.org/**plugins/maven-surefire-plugin/**test-mojo.html# **testFailureIgnore http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#testFailureIgnore Jeff MAURY On Tue, Jan 10, 2012 at 4:55 PM, Xavier S. xavier.seign...@gmail.com ** wrote: Thanks for all your answers, but I think I should re explain my need. I don't want to skip the tests. The default fail fast mode of maven suits me (section 6.1.8 http://www.sonatype.com/books/**mvnref-book/reference/running-** sect-options.html http://www.sonatype.com/books/mvnref-book/reference/running-sect-options.html ). I just want to run my custom mojo just after my tests failures and just before the end of the maven execution (if there is build failures, maven do not even finishes the current test phase). Regards, Xavier
Re: Minimize an Uber Jar correctly, Using Shade-Plugin
Moving to Users list as this is a question for people developing WITH maven not a question for people developing maven. At present there is no solution, other than having those classes referenced from a referenced class. Shade has no way of knowing that you use properties files to pull in classes via dynamic class loading, as there are sooo sooo many ways you could set that up. While we are on dev@m.a.o A fix would be to allow you to specify classes that should be retained in the minimized jar as a plugin parameter. Would you like to try and write a patch to shade for such a feature? If you are willing to take a shot, please open a JIRA, attach the patch (with tests if you want to stand a chance of getting the patch applied) and give me or the dev@m.a.o list a ping and somebody will apply the patch (assuming you have written tests and used the Maven formatting, but once you have a patch written we can help you get that stuff sorted) It would be relatively easy to do, just not an itch that any of the current committers has needed to scratch. -Stephen On 11 January 2012 09:46, Blitz, Shmuel sbl...@nds.com wrote: Dear fellows, I am using the Maven-Shade-Plugin to create a runnable Uber-jar. According to the last frame on maven.apache.org/plugins/maven-shade-plugin/examples/includes-excludes.html, the size of the jar can be minimized by using: configuration minimizeJartrue/minimizeJar /configuration But this feature does not take into consideration the classes that are declared in the log4j.properties file. Hence, e.g. org.apache.log4j.appender.TimeAndSizeRollingAppender is not included in the Uber-jar, even though it's declared in the log4j.properties file. I believe I will face the same problem with Spring. If my code only refers to interface A and my Spring file contains an instantiation of class B that implements A, then B might not be added to the jar, since it's not in the code. How can I solve this problem? You input will be highly appreciated. Thanks in advance, Shmuel Blitz This message is confidential and intended only for the addressee. If you have received this message in error, please immediately notify the postmas...@nds.com and delete it from your system as well as any copies. The content of e-mails as well as traffic data may be monitored by NDS for employment and security purposes. To protect the environment please do not print this e-mail unless necessary. An NDS Group Limited company. www.nds.com - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Could we delete old version jar in local repository by mvn ?
actually, no, in that case I would recommend downloading a repository manager and running it locally. Running Maven without a repository manager is like driving a car with a 24inch spike pointing out of the middle of the steering wheel On 11 January 2012 12:31, Rueegg Alexander a...@bdal.de wrote: Hi! I think you should even in this case use a different directory on your local filesystem to deploy your proprietary artifacts to. Isn't that best practise? Think of making backups of your deployed artifacts and not of the whole cached artifacts from the internet. Mixing things in the same type of repositories leads to more confusion and is not reproducable. Best Alex It's not a cache for another reason... mvn install:install-file where you install proprietary artifacts into your local repo when working on proprietary code and you don't have a proper repository manager to host them on. So you really have to know why each artifact is there and where it came from before you can just delete it at random. - Bruker Daltonik GmbH Fahrenheitstrasse 4 Gesch?ftsf?hrer Sitz der Gesellschaft 28359 Bremen Frank Laukien, Ph. D. Bremen Germany Gerd H?lso Sebastian Meyer-Plath Bruker Daltonik GmbH Stefan Ruge Handelsregister Zweigniederlassung Leipzig Dr.Ian Sanders, Ph. D. Amtsgericht Bremen Dr. Michael Schubert HRB 8150 Permoserstrasse 15 Dr. Michael Schubert www.bdal.de 04318 Leipzig Germany Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich f?r die ordnungsgem??e, vollst?ndige und verz?gerungsfreie ?bertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend best?tigt wird. Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Could we delete old version jar in local repository by mvn ?
I was only pointing out that silly users can do silly things, like installing manually, so saying it is just a cache is incorrect On 11 January 2012 14:34, Rueegg Alexander a...@bdal.de wrote: Sorry, but I was confused that you suggested to run mvn install:install-file to deploy proprietary artifacts when you don't have a proper repository manager installed. For sure best is to use a repo manager! -Original Message- From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] Sent: Mittwoch, 11. Januar 2012 14:33 To: Maven Users List Subject: Re: Could we delete old version jar in local repository by mvn ? actually, no, in that case I would recommend downloading a repository manager and running it locally. Running Maven without a repository manager is like driving a car with a 24inch spike pointing out of the middle of the steering wheel On 11 January 2012 12:31, Rueegg Alexander a...@bdal.de wrote: Hi! I think you should even in this case use a different directory on your local filesystem to deploy your proprietary artifacts to. Isn't that best practise? Think of making backups of your deployed artifacts and not of the whole cached artifacts from the internet. Mixing things in the same type of repositories leads to more confusion and is not reproducable. Best Alex It's not a cache for another reason... mvn install:install-file where you install proprietary artifacts into your local repo when working on proprietary code and you don't have a proper repository manager to host them on. So you really have to know why each artifact is there and where it came from before you can just delete it at random. - Bruker Daltonik GmbH Fahrenheitstrasse 4 Gesch?ftsf?hrer Sitz der Gesellschaft 28359 Bremen Frank Laukien, Ph. D. Bremen Germany Gerd H?lso Sebastian Meyer-Plath Bruker Daltonik GmbH Stefan Ruge Handelsregister Zweigniederlassung Leipzig Dr.Ian Sanders, Ph. D. Amtsgericht Bremen Dr. Michael Schubert HRB 8150 Permoserstrasse 15 Dr. Michael Schubert www.bdal.de 04318 Leipzig Germany Haftungsausschluss: Die Bruker Daltonik GmbH ist nicht verantwortlich f?r die ordnungsgem??e, vollst?ndige und verz?gerungsfreie ?bertragung der Nachricht. Der Inhalt der E-Mail ist nur rechtsverbindlich, wenn er unsererseits durch einen Brief oder ein Fax entsprechend best?tigt wird. Exclusion from liability: Any liability of Bruker Daltonik GmbH referring to the correct, complete and immediate transmission of the message shall be excluded. The content of the e-mail including its attachments is only legally binding if confirmed by Bruker Daltonik GmbH by letter or fax. - - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Re: Howto access project version programmatically within application
getClass().getClassLoader().getPackage().getImplementationVersion() On 11 January 2012 16:44, Steve Cohen sco...@javactivity.org wrote: Hm, is this really heading into the direction you intended with your question originally? No, it isn't! Thanks. The original link I posted talked about reading the manifest with a dead link explaining this in more detail. Another poster set me off on this blind alley. I think I need to roll my own manifest reader, since I AM encoding the version there, or perhaps read the maven.properties. Original Message Subject: Re: Howto access project version programmatically within application Date: Wed, 11 Jan 2012 16:41:49 +0100 From: Rainer Pruy rainer.p...@acrys.com Reply-To: Maven Users List users@maven.apache.org Organization: Acrys Consult GmbH Co. KG To: users@maven.apache.org Hm, is this really heading into the direction you intended with your question originally? The api your are looking at is more for maven internal use (or for dealing with maven world (poms, etc.). If your application is into this direction you might find interesting hints with maven plugin development. If you have in mind some kind of application that just happens to use maven as a build platform, then the solution is not in the first place maven specific. (The version of the maven project needs not necessarily be the version of the application, but providing such info to your application is application specif in the first place.) You need to consider in what form said information is to be bundled with your application. (e.g. readable from jar manifest or other resource, read from pom included with jar, provided by a dedicated class to name a few) Second step would be how you access it from there. So, probably you can drop a word or more on the use case involved. Rainer On 11.01.2012 16:07, Steve Cohen wrote: It appears that this entire class and the interface it is based on are deprecated, in favor of org.apache.maven.rtinfo.RuntimeInformation and org.apache.maven.rtinfo.internal.DefaultRuntimeInformation. But this non-deprecated version of the interface/impl REMOVE the getApplicationVersion() method. What's going on here and what is the approved method for getting the application version now? On 01/11/2012 08:59 AM, Steve Cohen wrote: Thanks. But according to this: http://maven.apache.org/ref/3.0.4-SNAPSHOT/apidocs/org/apache/maven/execution/DefaultRuntimeInformation.html the getApplicationVersion() method has been deprecated, with no indication as to what I should use instead. Also, it seems that this introduces a dependency on Maven itself within the application. What jar would this be? Thanks again. On 01/11/2012 08:12 AM, Guillaume Polet wrote: Just google org/apache/maven/execution/DefaultRuntimeInformation.java . http://grepcode.com/file/repo1.maven.org/maven2/org.apache.maven/maven-core/2.0.5/org/apache/maven/execution/DefaultRuntimeInformation.java?av=h Cheers, Guillaume Le 11/01/2012 15:03, Steve Cohen a écrit : A solution to this question appears to have been offered here, in 2007. http://maven.40175.n5.nabble.com/HowTo-access-project-version-programmatically-in-application-td82542.html It references a page explaining how to do it. That page is now gone: http://svn.apache.org/repos/asf/maven/components/trunk/maven-core/src/main/java/org/apache/maven/execution/DefaultRuntimeInformation.java Does this page or another more advanced way to do this now exist? Thanks. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to run a maven goal when there is tests failures?
you'd need to do something like failsafe, where the execution is separated from the checking and failing the build might even get what you want using just failsafe On 10 January 2012 13:05, Xavier S. xavier.seign...@gmail.com wrote: Hello, I would like to know if there is a way to execute a goal when there is test failures? Since maven stops its execution (fail fast mode) after encountering a test failure, is there any options to launch a goal between that test failure and he stop of maven? Regards, Xavier. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: How to run a maven goal when there is tests failures?
use failsafe. parse the failsafe results yourself... if they show a test failure, do your special thing then let failsafe verify stop the build - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 10 Jan 2012 16:58, Xavier S. xavier.seign...@gmail.com wrote: Thanks Guillaume! That's exactly what I want to do. So people, any idea? Regards, Xavier 2012/1/10 Guillaume Polet guillaume.po...@gmail.com Tell me if I am wrong Xavier, but I think that what he would like to do is perform something special when the tests fail, not just skip them or not fail the build. My guess would be that he is expecting some kind of on failure/on tests failure phase where he could attach other maven plugins to perform alternate behaviour. Unfortunately I have no idea on how this could be done. Probably using Ant or by writing your own plugin, but I find both solutions quite poor. Maybe Maven is not the tool to be used to perform this. Although you can do a lot of things with Maven, sometimes bending its original objectives too far away is just cumbersome and counter-productive /(not sure this english, btw). /Cheers, Guillaume Le 10/01/2012 17:22, Jeff MAURY a écrit : what about http://maven.apache.org/**plugins/maven-surefire-plugin/**test-mojo.html# **testFailureIgnore http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#testFailureIgnore Jeff MAURY On Tue, Jan 10, 2012 at 4:55 PM, Xavier S.xavier.seign...@gmail.com** wrote: Thanks for all your answers, but I think I should re explain my need. I don't want to skip the tests. The default fail fast mode of maven suits me (section 6.1.8 http://www.sonatype.com/books/**mvnref-book/reference/running-** sect-options.html http://www.sonatype.com/books/mvnref-book/reference/running-sect-options.html ). I just want to run my custom mojo just after my tests failures and just before the end of the maven execution (if there is build failures, maven do not even finishes the current test phase). Regards, Xavier
Re: How to run a maven goal when there is tests failures?
given that nobody else bothered to read the original question, it does not surprise me that nobody bothered to read my original answer of using failsafe ;-) - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 10 Jan 2012 18:16, Stephen Connolly stephen.alan.conno...@gmail.com wrote: use failsafe. parse the failsafe results yourself... if they show a test failure, do your special thing then let failsafe verify stop the build - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 10 Jan 2012 16:58, Xavier S. xavier.seign...@gmail.com wrote: Thanks Guillaume! That's exactly what I want to do. So people, any idea? Regards, Xavier 2012/1/10 Guillaume Polet guillaume.po...@gmail.com Tell me if I am wrong Xavier, but I think that what he would like to do is perform something special when the tests fail, not just skip them or not fail the build. My guess would be that he is expecting some kind of on failure/on tests failure phase where he could attach other maven plugins to perform alternate behaviour. Unfortunately I have no idea on how this could be done. Probably using Ant or by writing your own plugin, but I find both solutions quite poor. Maybe Maven is not the tool to be used to perform this. Although you can do a lot of things with Maven, sometimes bending its original objectives too far away is just cumbersome and counter-productive /(not sure this english, btw). /Cheers, Guillaume Le 10/01/2012 17:22, Jeff MAURY a écrit : what about http://maven.apache.org/**plugins/maven-surefire-plugin/**test-mojo.html# **testFailureIgnore http://maven.apache.org/plugins/maven-surefire-plugin/test-mojo.html#testFailureIgnore Jeff MAURY On Tue, Jan 10, 2012 at 4:55 PM, Xavier S.xavier.seign...@gmail.com ** wrote: Thanks for all your answers, but I think I should re explain my need. I don't want to skip the tests. The default fail fast mode of maven suits me (section 6.1.8 http://www.sonatype.com/books/**mvnref-book/reference/running-** sect-options.html http://www.sonatype.com/books/mvnref-book/reference/running-sect-options.html ). I just want to run my custom mojo just after my tests failures and just before the end of the maven execution (if there is build failures, maven do not even finishes the current test phase). Regards, Xavier
Re: Interfaces, implementations and circular dependencies
the standard java way to solve this is the service loader pattern. java 6 has explicit support in the serviceloader class, but it is easy to use classloader.getResources(...) note that's a plural, to roll your own if you need to support java 5 or earlier. basically the factory looks for files called /META-INF/services/fullyqualifiedinterfaceclassname those files contain the name(s) of implementations of the interface. no circular dependency required. a more modern solution is to use dependency injection so that the implementations have eg @Producers. this is effectively the same as serviceloader but can be more flexible - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 7 Jan 2012 04:24, oweijr oweirj stupid...@yahoo.com wrote: I have a set of interfaces and then multiple implementations of the interfaces. Only one implementation is used in a given instance of the application. I'm trying to create separate projects for the common interface and each of the implementations. However, the problem I have is that in order to implement the common interface, each of the implementation projects needs to depend on the common interface project. I also need to create a factory method somewhere which will return the appropriate version of the implementation based on some parameters. It seems logical to put this factory into the common project. However, I cannot do this because the implementation projects depend on the common one and this creates a circular dependency in maven. How does one typically solve this sort of problem. I could create yet another project which contains the factory and depends on all the other projects. Is there a more sensible way? parent +--- common-interface +--- implementation-1 - depends on common-interface +--- implementation-2 - depends on common-interface Where does the factory go? It depends on all 3 of the above. TIA
Re: Could we delete old version jar in local repository by mvn ?
On 5 January 2012 13:41, Mark H. Wood mw...@iupui.edu wrote: On Wed, Jan 04, 2012 at 10:19:15PM +0100, Ansgar Konermann wrote: Am 04.01.2012 05:02, schrieb zuxiong lin: I want to remove 3.0.5 and 3.0.6. The local maven repository is an artifact cache. Why do you want to remove anything from this cache? This does not reliably control what versions maven will use to build your project. Because it is not a cache; it is a dumping ground for every artifact Maven has ever fetched, whether or not that artifact will ever again It's not a cache for another reason... mvn install:install-file where you install proprietary artifacts into your local repo when working on proprietary code and you don't have a proper repository manager to host them on. So you really have to know why each artifact is there and where it came from before you can just delete it at random. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
Hi, I just found a regression: http://jira.codehaus.org/browse/MNG-5224 I think it is serious enough to recommend users avoid using the above combination if you rely on properties in a settings.xml profile to GPG sign your releases. (i.e. anyone pushing to Central) -Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
I have checked in a fix towards 3.0.5... Pester olamy to backport... though he may want to wait for me to write the tests of the fix (manual testing confirms the fix... just have to figure out how to get automated testing!) On 3 January 2012 16:03, Mark Derricutt m...@talios.com wrote: Is this still broken under the 3.0.4-RC4 builds, or just 3.0.3? -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Wed, Jan 4, 2012 at 4:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Hi, I just found a regression: http://jira.codehaus.org/browse/MNG-5224 I think it is serious enough to recommend users avoid using the above combination if you rely on properties in a settings.xml profile to GPG sign your releases. (i.e. anyone pushing to Central) -Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
it all depends on whether olamy decides as RM to backport or not. he is RM for the 3.0.4 release by virtue of action. On Tuesday, 3 January 2012, Mark Derricutt m...@talios.com wrote: Surely something as egregious as allowing releases to break should block 3.0.4 from being released tho. As someone who uses GPG in that manner for some of his releases I'd certainly want 3.0.4 to be able to release... -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Wed, Jan 4, 2012 at 5:23 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have checked in a fix towards 3.0.5... Pester olamy to backport... though he may want to wait for me to write the tests of the fix (manual testing confirms the fix... just have to figure out how to get automated testing!) On 3 January 2012 16:03, Mark Derricutt m...@talios.com wrote: Is this still broken under the 3.0.4-RC4 builds, or just 3.0.3? -- Great artists are extremely selfish and arrogant things — Steven Wilson, Porcupine Tree On Wed, Jan 4, 2012 at 4:18 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Hi, I just found a regression: http://jira.codehaus.org/browse/MNG-5224 I think it is serious enough to recommend users avoid using the above combination if you rely on properties in a settings.xml profile to GPG sign your releases. (i.e. anyone pushing to Central) -Stephen - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: WARNING: Cannot use Maven 3.0.3 with Maven Release Plugin 2.2.2 (MNG-5224)
that is because you are using maven-release-plugin 2.2.1 switch to 2.2.2 and see how you feel - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 3 Jan 2012 20:58, Jesse Farinacci jie...@gmail.com wrote: Greetings, On Tue, Jan 3, 2012 at 3:45 PM, Mark Derricutt m...@talios.com wrote: Surely something as egregious as allowing releases to break should block 3.0.4 from being released tho. As someone who uses GPG in that manner for some of his releases I'd certainly want 3.0.4 to be able to release... It didn't stop the 3.0.3 release, what's the difference with 3.0.4? It's getting rather frustrating at seeing all these relatively solitary or edge-case problems derail the entire release process. I have performed many releases with 3.0.3 and 3.0.4-rcX both, so this is not a problem for me, and I dare say it's a very large majority of users that it is also not a problem for. Stop stopping the presses, please!! It's just a stupid point release! It doesn't have to solve every existing MNG-* out there! This kind of localized Chicken Little behavior is making it harder and harder to get small releases out the door. You're making it worse for all users. *sigh* (the same goes for all the bike shedding whiners about the dependency fetch timeout - you know who you are) -Jesse -- There are 10 types of people in this world, those that can read binary and those that can not.
RE: maven-release-plugin: using git where do I see the tag used to build the release in the pom?
yes - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 18 Dec 2011 17:41, Mirko Friedenhagen mfriedenha...@gmail.com wrote: I had a look :-D . The class code boils down to executing 'git tag -F messageFile' AFAICS. So there is no sign in a released POM how the tagname was. Would it be an useful enhancement to put either the hash or the tagname into the POM? Regards Mirko -- Sent from my phone http://illegalstateexception.blogspot.com http://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ On Dec 17, 2011 9:16 PM, Robert Scholte rfscho...@codehaus.org wrote: Hi Mirko, Did you have a look at the related code? http://maven.apache.org/scm/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/xref/org/apache/maven/scm/provider/git/gitexe/command/tag/GitTagCommand.html -Robert From: mfriedenha...@gmail.com Date: Sat, 17 Dec 2011 20:51:02 +0100 Subject: Re: maven-release-plugin: using git where do I see the tag used to build the release in the pom? To: users@maven.apache.org No comments on this? How would a scm:bootstrap know which tag to build with git? Regards Mirko On Fri, Dec 16, 2011 at 22:58, Mirko Friedenhagen mfriedenha...@gmail.com wrote: Hello, I know that with SVN the developerConnection and connection are updated to the real URL, that is when I invoke release:prepare with a URL like: https://SVNSERVER/svn/REPO/myproject/branches/release it will be replaced by https://SVNSERVER/svn/REPO/myproject/tags/myproject-1.0 which is fine because now I know which revision to checkout for building the release. With git there is no such possibility to realize this with rewriting the URL AFAIK. So I would have expected however, that maybe the tag element would be updated to reflect the fact, that the pom is the one of release, either to the symbolic name myproject-1.0 or to the hash of the tag. Regards Mirko -- http://illegalstateexception.blogspot.com/ https://github.com/mfriedenhagen/ https://bitbucket.org/mfriedenhagen/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Multi Module Project Failing - Help Me
The automated solution is probably a patch to the xmlbeans plugin you are using... Given that the plugin is hosted at mojo, it should be easy for a well structured patch with tests to get accepted. If you have issues getting a well structured patch accepted, ping myself or Barry and I'm sure we can help. -Stephen On 16 December 2011 20:51, Daivish Shah daivish.s...@gmail.com wrote: Yes I am looking for automated solution because we have 100 projects and almost all projects has XSD sub projects and we have to use this manual technic for all projects. So we can find something automated then it will make life easy. And we are right now converting all projects from ANT to MAVEN so if we can find some standard automated solution then it helps everybody in our team.. Thanks, daivish. On Fri, Dec 16, 2011 at 11:51 AM, Barrie Treloar baerr...@gmail.com wrote: On Sat, Dec 17, 2011 at 4:10 AM, Daivish Shah daivish.s...@gmail.com wrote: Hi Barrie, That's correct It's not MAVEN issue but i was thinking that whatever we define in POM.XML file as dependency eclipse must find it automatically for it's compilation yes this is working well for projects which doesn't have SUB MODULEs for XSD projects. But this is not working automatically only in the case, When there is XSD Project as sub module project and that module depends internally with other modules. Then i have to do manual job. Yes you are right the only quickest and easiest solution is to add that JAR as dependency manually. But i was looking for something automated solution. But i really appreciate your help on this to understand it properly. I always LOVE this MAVEN USER Group to resolve all my maven questions. Well, I'd appreciate an automated solution, but I've never cared enough to hunt it down. If this bugs you more than me and you would like to find the answer, then that would help me and any others who want it in the future... - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
[ANN] Maven Release Plugin 2.2.2 Released
The Maven team is pleased to announce the release of the Maven XXX Plugin, version Y.Z This plugin is used to release a project with Maven, saving a lot of repetitive, manual work. Releasing a project is made in two steps: prepare and perform. http://maven.apache.org/plugins/maven-release-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.2.2/version /plugin Release Notes - Maven 2.x Release Plugin - Version 2.2.2 ** Bug * [MRELEASE-354] - Versions defined in profiles are not updated * [MRELEASE-454] - The Release-Plugin does not rewrite dependencies in the DependencyManagement with scope import * [MRELEASE-577] - release:prepare does not pass argument --settings with current settings.xml to inner maven ** Improvement * [MRELEASE-708] - upgrade to last scm 1.6 to integrate new scm provider mks integrity ** New Feature * [MRELEASE-467] - Release preparation should update version of plugin dependencies Enjoy, -The Maven team - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best way to handle an ssh copy?
ship-maven-plugin - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 15 Dec 2011 17:09, Tom Masterson kd7...@gmail.com wrote: So if I don't use the wagon plugin do you have a sugestion as to what I should use? I am not finding anything else out there when I do a google search. Tom On Thu, 15 Dec 2011, Benson Margulies wrote: On Wed, Dec 14, 2011 at 6:26 PM, Tom Masterson kd7...@gmail.com wrote: We have several artifacts that we want to copy to remote servers via scp/ssh. I have looked at the wagon plugin but the documentation seems to have issues. DO NOT try to use the Wagon plugin. It is *not* a tool for arbitrary SCPs. It is only defined to work with Maven repos. You can sometimes accidently get it to do what you want for something else, but that's it. When I try to use it as documented I get an error telling me it can't find a plugin descriptor for wagon-ssh. Is there a good way to get maven to scp files to a remote server and where can I find documentation on how to do this. Thank TOm --**--** - To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Odd failure with maven-checkstyle-plugin in pluginManagement
Are you sure you know how to spell checkstyle? On 14 December 2011 09:54, Andreas Sewe s...@st.informatik.tu-darmstadt.de wrote: Hi, I have encountered a very odd failure when adding the maven-checkstyle-plugin to my pluginManagement section. Below is the simplest POM that triggers this error (both under Maven 3.0.3 and 3.0.4-RC3): project ... modelVersion4.0.0/modelVersion groupIdorg.example/groupId artifactIdexample/artifactId version0.0.1-SNAPSHOT/version build pluginManagement plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-ckeckstyle-plugin/artifactId version2.8/version /plugin /pluginManagement /build /project A mvn clean install runs just fine, but as soon as someone actually tries to do something with the pluginManagement entry (a mvn help:effective-pom already triggers this), I get the following warning. [WARNING] The POM for org.apache.maven.plugins:maven-ckeckstyle-plugin:jar:2.8 is missing, no dependency information available [WARNING] Failed to retrieve plugin descriptor for org.apache.maven.plugins:maven-ckeckstyle-plugin:2.8: Plugin org.apache.maven.plugins:maven-ckeckstyle-plugin:2.8 or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.maven.plugins:maven-ckeckstyle-plugin:jar:2.8 Note the packaging of jar in the above. AFAIK, it should be maven-plugin instead. At any rate, the above is really an error rather than a mere warning. Any attempt to actually use the maven-checkstyle-plugin in build/plugins uses the plugin's default configuration rather than any configuration configured build/pluginManagement/plugins. I strongly suspect this is a bug. Can someone please point me to the right issue tracker for this? (I don't think it's the plugin's fault.) Best wishes, Andreas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Failed to determine Java version for profile jdk* @
On 14 December 2011 16:06, Daniel Kulp dk...@apache.org wrote: On Tuesday, December 13, 2011 7:45:29 PM Benson Margulies wrote: On Tue, Dec 13, 2011 at 7:39 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: describe the problem better and point me to some sample code and i will have a think. but profiles containing (compile or runtime scope) deps activated based on the jre that maven is running is wrong wrong wrong, and will only lead to pain. (test and provided scope deps are still wrong in a profile but can be excused as they are non-transitive) The problem is this: different JDKs have different garbage in 'endorsed' in the departments of XML and web services. There are dependencies that have to be ADDED when running in some JDKs, and others that need to be SUBTRACTED. Provided isn't going to work, since (in the first case) we are adding things to the classpath that need to be there to compensate for what isn't there in the particular kit. If you want examples I can go dig them out. Here's a simple example: JAXB On Java5, we have to add both a JAXB-API jar and a JAXB-IMPL jar (and other deps like stax-api) as there is no JAXB stuff built into the JDK. We generally would prefer the latest JAXB stuff (2.2) here as there are no conflicts. On Java6, there is JAXB 2.1 stuff built in. Thus, we DON'T want to add an API jar (extra deps pulled in unnecessarily), but we DO want to pull in a newer JAXB-IMPL that fixes a bunch of bugs. However, it needs to be the latest 2.1.x version, not the newer 2.2 versions as they won't work with the 2.1 API's built into the JDK. (and pulling in a newer API jar would require and endorsing mechanism to override the JDK version) On Java7, JAXB 2.2 is built in. Again, we don't want to bring in an API jar, but we do want the latest 2.2 implementation. Suggestions? It will be a bit easier once we drop support for Java5 and it's just between impls, but at this point, we do need java5 support. Dan Well the key question is who needs these deps? If it is the end users that need the deps... well here's the rub, you will need to produce three artifacts, one for java 5, one for java 6 and one for java 7, in each case pulling in the required deps... [but but but you stammer] This is because if I build on Java 6 an app that targets support for Java 5, then the (helpful) profile activation will bundle the Java 6 deps and not the Java 5 deps I need... making it almost impossible for all but the hero of JDK version dancers to build on their Mac a CXF app that targets a Java 5 environment. On the other hand, it it is unit tests that need the deps... then profiles may be the solution, but I would have a series of aggregator projects with transitive deps to solve your issues, so that you pull in compat-java5 or compat-java6 or compat-java7 with scope test in each module. And while you are at it, order a hit on whoever decided to add JAXB to the endorsed list - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 14 Dec 2011 00:30, Benson Margulies bimargul...@gmail.com wrote: On Tue, Dec 13, 2011 at 7:24 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: sounds like cxf have been really bold and are adding deps in a profile Yes indeed. *purely for testing* we have profiles that change the dependencies. Got another suggestion? - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 14 Dec 2011 00:02, jaybytez jayby...@yahoo.com wrote: Sorry if this question has already been posted. I have tried running Maven 3.0.3 and Maven 2.2.12 (which is the current version we use for building via Hudson). I have a simple project that has poms it inherits from that were defining a maven-compiler-plugin with the target/source set to jdk1.6. Whether or not this configuration existed, I still get the following error on a project that has dependencies to cxf. I am running Eclipse Helios/m2eclipse. Any thoughts as to why this error exists and how to get rid of it. 12/13/11 3:56:15 PM PST: [WARN] The POM for org.apache.cxf:cxf-rt-frontend-jaxws:jar:2.4.4 is invalid, transitive dependencies (if any) will not be available: 5 problems were encountered while building the effective model for org.apache.cxf:cxf-rt-frontend-jaxws:2.4.4 [ERROR] Failed to determine Java version for profile jdk17 @ [ERROR] Failed to determine Java version for profile jdk15 @ [ERROR] Failed to determine Java version for profile jdk15 @ org.apache.cxf:cxf-parent:2.4.4 [ERROR] Failed to determine Java version for profile jdk17 @ org.apache.cxf:cxf-parent:2.4.4
Re: Best way to handle an ssh copy?
maybe the ship-maven-plugin could help... though if you want to use a wagon that is non-default for the maven version you are using (eg ssh is non default in maven 3.0.3) you will need to either add that wagon as a dependency of *the plugin* or add that wagon as an extension to *the project's build* - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On 15 Dec 2011 00:28, Tom Masterson kd7...@gmail.com wrote: We have several artifacts that we want to copy to remote servers via scp/ssh. I have looked at the wagon plugin but the documentation seems to have issues. When I try to use it as documented I get an error telling me it can't find a plugin descriptor for wagon-ssh. Is there a good way to get maven to scp files to a remote server and where can I find documentation on how to do this. Thank TOm --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-shade-plugin, minifyJar removes classes used in Class.forName(...)
try {
Class.forName(oracle.jdbc.driver.OracleDriver.class.getName())
} catch (LinkerError e) {
// ignore
}
:-P
On 13 December 2011 12:04, Oliver Schrenk oliver.schr...@gmx.net wrote:
Hej,
I'm using the maven-shade-plugin to create an executable jar. The number of
included jars blows the final jar over 10+ MB. Using the `minifyJar`
instruction, reduces it to 2.8 MB.
Unfortunately it will remove the classes for the database driver. I assume
its because they are included via
Class.forName(oracle.jdbc.driver.OracleDriver)
and aren't found during the minifying process.
I tried including it via
configuration
artifactSet
includes
includecom.oracle:ojdbc6/include
/includes
/artifactSet
/configuration
but this removes all other classes.
How can I minify the shaded jar and still include the database driver?
Best regards
Oliver Schrenk
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
