RE: dependency plugin
The unpack goal doesn't look in the reactor for the dependencies. You should use the unpack-dependencies dependencies instead since this lets maven resolve it for the plugin. There are enough filters available that you can get just the one you're after. -Original Message- From: Build Guy [mailto:[EMAIL PROTECTED] Sent: Friday, September 12, 2008 10:11 PM To: Maven Users List Subject: Re: dependency plugin well, the whole point is that... If module A's jar is a dependency thats needed for compilation of Module B. I don't need to use the install goal. Module B finds the Module A jar when building from the parent. How ever. If I further want to do something with Module A's jar in Module B. Like extract it using dependency unpack. I can't, unless I 1st run install goal from Module A. But this means the release plugin won't properly work from the parent pom unless I release Module A and B individually. Here's what my project looks like: -parent pom | - Module A (produces Jar) | - Module B (includes jar) I'm wondering if this is just a limitation of the dependency plugin.. :-/ I've been struggling with this for quite some time. Thought? thanks! Taras Dan Tran wrote: did you use install goal ? -D On Fri, Sep 12, 2008 at 6:54 PM, Build Guy [EMAIL PROTECTED] wrote: Can some one please shine some light on the following scenario.. I have parent pom and 2 modules. Module A produces a jar file Module B has Module A's jar as dependency, but it uses the dependency plugin to unpack it. If I run mvn package from the parent. Module B's dependency plugin is always trying to take the jar from the repository, not from Module A's target So my build fails with [INFO] Unable to find artifact. I always have to run mvn install on Module A before using Module B. Quite tedious.. And I do have the jar listed in Module B as a dependency and then again in he plugin like so: dependency groupIdfoo.bar/groupId artifactIdmyjar/artifactId version1.0.0-SNAPSHOT/version typejar/type scopecompile/scope /dependency plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.0/version executions execution idgetjar/id phasegenerate-sources/phase goals goalunpack/goal /goals configuration artifactItems artifactItem groupIdfoo.bar/groupId artifactIdmyjar/artifactId typejar/type overWritetrue/overWrite outputDirectory target/tmp /outputDirectory /artifactItem /artifactItems overWriteReleasestrue/overWriteReleases overWriteSnapshotstrue/overWriteSnapshots /configuration /execution /executions /plugin Any thoughts? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
Rick wrote: Is it common for the development environment to rely on company snapshot versions and only in test or later, to define specific version numbers? I seem weary though to have for example project B rely on the snapshot version of project A. Maybe project A is working on a release that won't break project B, but it's still a release that project B wouldn't necessarily want (especially if they haven't been communicating with each other. For example maybe project A is changing the way a calculation is done, but project B still wants the calc to stay the old way for now. If they are relying on snapshots, they might not be aware that the change was even made.) You are describing a recipe for disaster - use proper release management, and you will be fine. In other words, use the maven-release-plugin to publish formal releases of code, and make sure that project A never depends on a snapshot of project B if you can possibly avoid it. Use proper version numbers. snapshot is another way of saying all bets are off, and I cannot stress this enough: if project B depends on snapshots from project A, project B is saying we accept that our code will break with no warning and for no clear reason because of project A, and it will be our own fault. Get your projects to release often, and you will minimise the need for people to depend on snapshots. Regards, Graham -- smime.p7s Description: S/MIME Cryptographic Signature
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
--- On Sat, 9/13/08, Graham Leggett wrote: In other words, use the maven-release-plugin to publish formal releases of code, and make sure that project A never depends on a snapshot of project B if you can possibly avoid it. Use proper version numbers. Would it be reasonable to say that *released* versions of A shouldn't depend on B-snapshots? In other words, an A-snapshot may use a B-snapshot, but an A-release should not. Every A-release should depend only on a B-release, even if it means releasing an B-n.n.n+1 tag to fix minor B-release issues. (We're revamping some of our build and release policies, and may be using Maven moving forward, so I'm definitely interested in hearing opinions, best practices, and how others deal with this.) Dave - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Doxia: Can I use it outside of Maven?
I want to integrate Doxia into a web application of mine. I like the APT support it has. Is this possible? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dependency plugin
It is this goal in the dependency plugin, but in general when working with multimodule builds, you should just do install. Other plugins can have the same problems. Sent from my iPhone On Sep 12, 2008, at 10:10 PM, Build Guy [EMAIL PROTECTED] wrote: well, the whole point is that... If module A's jar is a dependency thats needed for compilation of Module B. I don't need to use the install goal. Module B finds the Module A jar when building from the parent. How ever. If I further want to do something with Module A's jar in Module B. Like extract it using dependency unpack. I can't, unless I 1st run install goal from Module A. But this means the release plugin won't properly work from the parent pom unless I release Module A and B individually. Here's what my project looks like: -parent pom | - Module A (produces Jar) | - Module B (includes jar) I'm wondering if this is just a limitation of the dependency plugin.. :-/ I've been struggling with this for quite some time. Thought? thanks! Taras Dan Tran wrote: did you use install goal ? -D On Fri, Sep 12, 2008 at 6:54 PM, Build Guy [EMAIL PROTECTED] wrote: Can some one please shine some light on the following scenario.. I have parent pom and 2 modules. Module A produces a jar file Module B has Module A's jar as dependency, but it uses the dependency plugin to unpack it. If I run mvn package from the parent. Module B's dependency plugin is always trying to take the jar from the repository, not from Module A's target So my build fails with [INFO] Unable to find artifact. I always have to run mvn install on Module A before using Module B. Quite tedious.. And I do have the jar listed in Module B as a dependency and then again in he plugin like so: dependency groupIdfoo.bar/groupId artifactIdmyjar/artifactId version1.0.0-SNAPSHOT/version typejar/type scopecompile/scope /dependency plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-dependency-plugin/artifactId version2.0/version executions execution idgetjar/id phasegenerate-sources/phase goals goalunpack/goal /goals configuration artifactItems artifactItem groupIdfoo.bar/groupId artifactIdmyjar/artifactId typejar/type overWritetrue/overWrite outputDirectory target/tmp /outputDirectory /artifactItem /artifactItems overWriteReleasestrue/overWriteReleases overWriteSnapshotstrue/overWriteSnapshots /configuration /execution /executions /plugin Any thoughts? Thanks! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Doxia: Can I use it outside of Maven?
Paul Benedict wrote: I want to integrate Doxia into a web application of mine. I like the APT support it has. Is this possible? Sure, why not? I have used doxia to generate a simple html report like this: Writer writer = ... Sink sink = new XhtmlSink(writer); sink.head(); sink.title(); sink.text(this is the document's title); sink.title_(); sink.close(); -dirk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
On Sat, Sep 13, 2008 at 4:39 PM, Graham Leggett [EMAIL PROTECTED] wrote: In other words, use the maven-release-plugin to publish formal releases of code, and make sure that project A never depends on a snapshot of project B if you can possibly avoid it. Use proper version numbers. Here's what I'm confused at though. Project A builds a jar. It needs to be used in Project B. Ideally of course Project A should be tested in Project B locally, but in reality (unfortunately) the dev environment often becomes a more 'real' test. Typically the developers of Project A will have access to Project B, so can't they just set up the dev profile of Project B, to use the latest stable version? This way they won't have to constantly be changing the profile for Project B.. or is that a bad practice? Assuming some time goes by while they do more 'real life' stuff in dev and they like how things are. They could then change the version of the dependency of Project A to a set number and then check that updated pom/profile into version control. Are they any documents out there that explain some of these common best practices in company environments? The two books I mentioned 'touch' upon it but don't see give a lot of detail. Understanding this 'process' of how things should be done to me seems critical to have nailed down (even if there are different ways to do it, I'd like to be aware of the typical scenarios corporations use.) Thanks to all for the replies so far. -- Rick - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: newbie: understanding how teams deal with version numbers on dependencies (Best practices)?
On Sat, Sep 13, 2008 at 9:03 PM, Rick [EMAIL PROTECTED] wrote: On Sat, Sep 13, 2008 at 4:39 PM, Graham Leggett [EMAIL PROTECTED] wrote: Here's what I'm confused at though. Project A builds a jar. It needs to be used in Project B. Ideally of course Project A should be tested in Project B locally, but in reality (unfortunately) the dev environment often becomes a more 'real' test. Typically the developers of Project A will have access to Project B, so can't they just set up the dev profile of Project B, to use the latest stable version? This way they won't have to constantly be changing the profile for Project B.. or is that a bad practice? Assuming some time goes by while they Sure, you can do this by setting a version number to 'RELEASE' to get the latest non-snapshot, but IMHO it's a bad practice in general. In any dev environment, there are lot of variables you are trying to control and the last thing you want to do is to slow down the devs by causing unexpected issues with some non-obvious change. About the only environment I could think of doing something like this is a specific continous integration profile where the system runs a test suite against the latest available dependencies *before* the devs move to it, to have a better idea whether it's safe to move to it or not. I think the old truth, if it ain't broken, don't fix it holds true in this case; or if the old version works, don't upgrade. Kalle
