Re: Advice on dealing with hostility to Maven 2
Hi cvr, I think hostility can exist with any change in general. Sometimes it is really just an attitude thing so you can't use logic to reason with him. What you need is a mandate (whether it is concencus from team members or from someone else). If you don't have a mandate to use Maven then you might as well give up. If you need his vote to get a mandate then I'd say bribery or blackmail. Seriously, nothing is wrong with anything he objects, everyone is open to an opinion but is he professional and humble enough to try something new and give it an objective assessment. Maven is not perfect, I have a lot of gripes with it but it is better than anything out there I know at the moment. Cheers, rOnn c. Russ Tremain [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 22/10/2008 04:43 PM Please respond to Maven Users List users@maven.apache.org To cvr [EMAIL PROTECTED] cc users@maven.apache.org Subject Re: Advice on dealing with hostility to Maven 2 have you tried the Maven Kool-Aid on him? It's sort-of purplish and you can buy it at Trader Joe's, but they are often out of stock. :) bottom line, in maven you can see the dependencies of a project, in a clearly specified form. there are even visual tools to help. not so with ant, make, sh, perl, etc. make and ant moved in that direction, but were overcome by our need to be procedural. Clearly written maven specifications, with configuration rules centralized in a few parent poms, can offer great simplicity for developers creating new sub-projects within a build system. You can provide archetypes to make it even simpler. In contrast, go back and read some of the ant files you wrote 4 or 10 years ago and see if you can figure them out. Better yet, look at some of the *generated* ant files coming from IDE's, and try to figure those out. Not to say you can't write spaghetti code in maven; I've seen it. You can replicate cannonical configurations to your hearts content, and generally succumb to the dark forces of entropy, as you can with any language. This can happen on any development team, especially once it grows beyond a certain size (N 1, I think). But even then, maven is easier to figure out, and it gives rise to an urge, in certain talented developers, to tidy things up. :) And if you can't figure out how to do it in maven, then there is always the antrun plugin, or even the exec plugin. I find that I use 'em less and less, however. BUT, if your friend is really in love with his shell script, then exec it from maven and move on. my 2 cents. /r At 7:16 PM -0700 10/20/08, cvr wrote: I have a colleague has recently become a very vocal opponent of Maven. The problem is that we're behind a corporate firewall, and he has had a lot of difficulty getting Maven to work (I googled firewall and created a ~/m2./settings.xml file appropriately). His arguments have been: - The build system should be more complicated (harder to run, harder to configure) than the software - Why all this configuration for a glorified WGET? - Why do you need a shared repository (~/.m2/repository)? Disk space is really cheap - What's wrong with just checking the jars in to source control under lib - I just have a build script that I run to compile my project, what's so hard about that? (ed. note: it's a bash script) Having struggled with projects that had *no* build script (from the README: step 1: open up Eclipse and click compile), projects with undocumented dependencies (yay, ClassNotFoundException at runtime), and having fought multi-module ant builds for two years - Maven has worked out wonderfully. However, I can't seem to get this across. His mind is (angrily) closed. I'm just wondering if others on this forum have encountered similar hostility and you coped with it. -- View this message in context: http://www.nabble.com/Advice-on-dealing-with-hostility-to-Maven-2-tp20082277p20082277.html Sent from the Maven - Users mailing list archive at Nabble.com. - 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] ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Re: Ant to Maven
Hi Luis, As you'd already know, Maven is good with the following, a) maven is structured and more declarative (less procedural) than Ant. b) maven manage your dependencies properly (or at least in its ideal) c) maven can generate IDE project files easily d) life cycle management ensure that test cases and other important things always run e) central repository of artifacts with maven corrdinates. All of those should add up to simply, less pain and more elegant way in managing build. But gotcha that I found are a) single artifact per module (generally ok but occasionally you need to do some trick with dependency plugin to import source/resources from another module). b) It's not as robust as Ant - expect to find critical bugs and things that you need to work around. c) version range is still buggy. d) can be very verbose if you want to ensure that your build is repeatable - you need to explicitly declare every plugins in the root pom. e) different settings.xml can lead to different build results. different local repository can also lead to different build results. Obvious, but it means that your maven project depends on these external factors and you'd often find youself flushing local repo when things doesn't work right. f) You need to understand how to develop convention for groupId and artifactId and their impact. Ideally, artifactId needs to be a unique id irregardless of groupId that it belongs to. I find that groupId is not really like a qualifying package name, it's more of a unique project id that should be the same across muti module projects. g) Plain old maven repo can get corrupted if there are concurrent deployment. Is it worth it? I think so but won't be a painless experience! Cheers, rOnn c. Luis Roberto P. Paula [EMAIL PROTECTED] 12/11/2007 12:14 AM Please respond to Maven Users List users@maven.apache.org To users@maven.apache.org cc Subject Ant to Maven Hi, I'm work in a huge java project that has a ant script with almost 800 lines. The last two weeks I'm trying to convert this script into a maven2 multiproject, in order to simplify the build process, and its being such a pain in the ass. My questions are: - Is it worth to do this? - I know it is a great software, but in what causes maven is not recommended? Thanks, Luis ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Backwards incompatibility with 2.0.8?
We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Re: Backwards incompatibility with 2.0.8?
Right, thanks for the explanation. Explicitly specifying the plugin version would help in this particular case but would we then need explictly declare every single plugin in the project to guard against future problem? i.e., clean, compiler, deployer, install, jar, war etc... would you then recommending this as the best practice? Surely this will lead to a very large pom.xml. I supposed, the release plugin can do this work, but does it currently do this ? rOnn c. Michael McCallum [EMAIL PROTECTED] 12/10/2007 10:41 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ## -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Re: Backwards incompatibility with 2.0.8?
Ok, but our problem is not a simple backward compatibility. I was working on project A on my machine. I upgraded to 2.0.8. Nothing breaks here but it it break then fair enough. A colleauge was working on project B and still using 2.0.6. Some how my action of upgrading to 2.0.8 in my machine has cause his build environment to break in his machine. Both build machine uses surefire 2.3.1-SNAPSHOT. So perhaps surefure 2.3.1 doesn't work with Maven 2.0.6 ? rOnn c. Brett Porter [EMAIL PROTECTED] 12/10/2007 10:42 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? No, it's because 2.0.8 is not backwards compatible with 2.0.6, as documented in the release notes. On 10/12/2007, Michael McCallum [EMAIL PROTECTED] wrote: its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ## -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Brett Porter Blog: http://www.devzuz.org/blogs/bporter/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Re: Backwards incompatibility with 2.0.8?
I've worked out what happened. Surefire 2.3.1 is not in the central repository yet but apparantly it has been tagged (http://jira.codehaus.org/browse/MNG-3118). Last Friday, I've downloaded maven source and build it on my local machine (and added apache snapshot into Artifactory). As a result, surefire 2.3.1-SNAPSHOT got into our Artifactory. This is what I've found. Maven 2.0.6 + surefire 2.3 works. Maven 2.0.6 + surefire 2.3.1-SNAPSHOT doesn't work. Maven 2.0.8 + surefire 2.3 doesn't work Maven 2.0.8 + surefire 2.3.1-SNAPSHOT works. I'm not sure what differences there are in surefire 2.3.1-SNAPSHOT and 2.3.1. I can't find surefire 2.3.1 anywhere so I'll wait and see. Thanks for your help. Cheers, rOnn c. Brett Porter [EMAIL PROTECTED] 12/10/2007 11:24 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? Your act of upgrading certainly can't have broken his environment :) There are two possibilities: a) something changed in a surefire snapshot. This is possible as its under active development, though I'm not sure if new snapshots are being deployed regularly. b) a test was added to your environment that relied on the classpath ordering. b) still sounds like the most likely based on your original message - note that 2.0.6 always had main-first ordering, while 2.0.8 has test-first ordering. If you have a sample case where 2.0.6 + surefire 2.3 succeeds and 2.0.6 + 2.3.1 fails, please file it in the surefire JIRA. Otherwise, I would look at the test cases as above. Note you can also use the enforcer to force a Maven version to require people to upgrade to 2.0.8 - consistency is likely to give you less headaches, though I can understand that this is not something you would want to jump to quite so soon perhaps given it is a recent release. I'm still using 2.0.7 myself :) Cheers, Brett On 10/12/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Ok, but our problem is not a simple backward compatibility. I was working on project A on my machine. I upgraded to 2.0.8. Nothing breaks here but it it break then fair enough. A colleauge was working on project B and still using 2.0.6. Some how my action of upgrading to 2.0.8 in my machine has cause his build environment to break in his machine. Both build machine uses surefire 2.3.1-SNAPSHOT. So perhaps surefure 2.3.1 doesn't work with Maven 2.0.6 ? rOnn c. Brett Porter [EMAIL PROTECTED] 12/10/2007 10:42 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? No, it's because 2.0.8 is not backwards compatible with 2.0.6, as documented in the release notes. On 10/12/2007, Michael McCallum [EMAIL PROTECTED] wrote: its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for
Re: Backwards incompatibility with 2.0.8?
Is there a philosophical reason why release plugin shouldn't do that on behalf of the users? Maven makes alot of things simpler and pleasant for you (i.e., transitive dependencies, lifecycles management etc..) and then there are occasional things like this that makes you wonder why would I have to care? Most of the time users don't really care if he/she run sure fire 2.3, complier plugin 2.0.2, jar plugin 2.1 and countless other plugins that are magically invoked to make the build works. Explicitly specifying all the plugins (let alone its version) is definitely not a fun thing to do. The trouble with shared parent pom is that, there will be one per logical set of deliverable projects. So in our environment, there is one poping up all the time. Even if we can create our own super pom and store it some where in SVN, maven won't know how to tag the custom super pom that is outside it's project. Personally, I think release plugin should have some of the enforcer features built in. If enforcer is the way to go, then I think there needs to be a big disclaimer in the release plugin or Maven FAQ saying that you must use enforcer to ensure repeatable build across releases. Cheers, rOnn c. Brett Porter [EMAIL PROTECTED] 12/10/2007 11:13 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? It is a best practice - in a shared parent POM so that you don't need to do it frequently. The release plugin doesn't do it, but the enforcer plugin can be used to ensure that you have. Cheers, Brett On 10/12/2007, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Right, thanks for the explanation. Explicitly specifying the plugin version would help in this particular case but would we then need explictly declare every single plugin in the project to guard against future problem? i.e., clean, compiler, deployer, install, jar, war etc... would you then recommending this as the best practice? Surely this will lead to a very large pom.xml. I supposed, the release plugin can do this work, but does it currently do this ? rOnn c. Michael McCallum [EMAIL PROTECTED] 12/10/2007 10:41 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Backwards incompatibility with 2.0.8? its just coincidental that surefire 2.3.1 was released at the same time as 2.0.8... if you specify surefire 2.3 or less in you pluginManagement then the tests will start working again... of course its best practice to specify plugin versions anyway so magic upgrades don't break things On Mon, 10 Dec 2007 12:30:25 [EMAIL PROTECTED] wrote: We were using maven 2.0.6 in a team with Artifactory as a proxy. I then upgrade my environment to 2.0.8. A whole bunch of new plugins get fetched. Other people were using 2.0.6 but it appears that they also get a whole heap of new plugins. As a result, test cases in another project which had worked before now failed for people running 2.0.6. It appears that the problem is with classpath ordering - for some reason with 2.0.6 and the new bunch of plugins, src/main/resources gets picked up before src/test/resources and so it doesn't load the resources for test cases. So what happens now is that everyone has to abandon 2.0.6 to 2.0.8. Can someone offer any explanation how this could happen? It concerns me that someone running 2.0.6 would now be forced to move to 2.0.8 simply because I decided to upgrade to 2.0.8 in my own environment and project? Is the automatic plugin update a problem here? I don't understand how automatic plugin update works but how would one guarantee repeatable builds ? esp with the releases that have been tagged and potentailly checked out for build later. rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ## -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ## DISCLAIMER: This email and any attachment may contain
Re: auto-deploy 3rd party files
Hi, If you don't use any maven proxy, you could simply copy all of the libraries across to your repository and write a script to generate basic pom.xmls and the checksums. You just need to understand how he repoitory is structured. Alternatively, you could also write a script to run deploy-file for all your jars.Shouldn't be too hard at all if you dont care too much about dependencies in side each of the pom file. Cheers, rOnn c. javijava [EMAIL PROTECTED] 12/06/2007 12:30 AM Please respond to Maven Users List users@maven.apache.org To users@maven.apache.org cc Subject auto-deploy 3rd party files Hi, I see that people use mvn deploy:deploy-file to put ONE jar into a remote repository. Or with an ant task, can say the path of some file to deploy too. But what happend if a proyect have 100 3rd party jars? we must do 100 deploy-file ?? There is some way..to tell maven that must find the necessary jars to run a project and deploy all the same time? thanks a lot -- View this message in context: http://www.nabble.com/auto-deploy-3rd-party-files-tf4949608s177.html#a14171500 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Re: Buggy version range ?
That's interesting. Would this version range work [1.2,-!) i.e., to match 1.2 or anything later ? don't put [X.X] ranges in things that will resolve transitively.. that gives NPE have not figure out why yet... i suspect broken metadata Not sure what you mean, but when we use version range we use it all the way (from the most common denominator libraries that are reused every where at several levels right to the bespoke end product applications). Here's a scenario that we have. Three reusable artifacts that depends on each other. * projecta - project b (version range) -project c (version range) Bespoke application that may imports the above reusable artifacts * project d may explictly declare depenencies on project a (version range), project b (version rage) and project c (version range)! Version range is certainly very useful but I think one can always work around it, especially if it is buggy. Can you elaborate on what you mean by make complex project possible and makes parallel development possible ? Regards, rOnn c. Michael McCallum [EMAIL PROTECTED] 12/05/2007 04:14 PM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: Buggy version range ? I use version ranges... make complex projects possible... makes parallel development possible too there are a few gotchas... * [3,4) will match 4.0-SNAPSHOT should use [3,4-!) * [3,4) will not match 3.0-SNAPSHOT * don't use - any in ranges just causes trouble make regular use of releases and where you have a breaking change increment the major version don't put [X.X] ranges in things that will resolve transitively.. that gives NPE have not figure out why yet... i suspect broken metadata broken metadata for external projects can be very anoyying... i wrap them in local projects I call composites that give the power of ranges with decent metadata and let me use ranges for projects with funny versions that don't work with ranges we use eclipse with the m2eclipse plugin which works very well with ranges using 2.0.7 and 2.0.8 we don't use modules have over 113 artifacts have both java4 and java6 repositories On Wed, 05 Dec 2007 17:26:32 [EMAIL PROTECTED] wrote: Hi All, I'd like to get an idea if there are many people using the version range feature in the community. For those users using/relying version range, do you find any problems with it? In our organisation, some people advocate the usage of version range but personally, I don't think it is robust enough for real world usage. Following problems are my main gripes that often stop me from runing maven on a day to day basis. * idea plugin errors (can't resolve artifacts with obscure errors). * dependencies resolution errors (various obscure NPE errors). * release plugin errors (can't release because we do clean install first and it will resolve to snapshot). * release plugin does not crystalise the actual version that has been resolved in the release pom that has been tagged. * version range depends on maven-metadata.xml the content of the file which can be errorneous. This is mainly based on Maven 2.0.6, because 2.0.7 gave us more NPE on resolving transitive dependencies. The problem also seems to happen with some projects and not others. Generally, we have about three or more layers of inhouse artifacts that are imported as dependencies across several maven modules. Like to hear any success/failure stories about this. Cheers, rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ## -- Michael McCallum Enterprise Engineer mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems
Buggy version range ?
Hi All, I'd like to get an idea if there are many people using the version range feature in the community. For those users using/relying version range, do you find any problems with it? In our organisation, some people advocate the usage of version range but personally, I don't think it is robust enough for real world usage. Following problems are my main gripes that often stop me from runing maven on a day to day basis. * idea plugin errors (can't resolve artifacts with obscure errors). * dependencies resolution errors (various obscure NPE errors). * release plugin errors (can't release because we do clean install first and it will resolve to snapshot). * release plugin does not crystalise the actual version that has been resolved in the release pom that has been tagged. * version range depends on maven-metadata.xml the content of the file which can be errorneous. This is mainly based on Maven 2.0.6, because 2.0.7 gave us more NPE on resolving transitive dependencies. The problem also seems to happen with some projects and not others. Generally, we have about three or more layers of inhouse artifacts that are imported as dependencies across several maven modules. Like to hear any success/failure stories about this. Cheers, rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Re: Version moving up fast
It sounds odd to have that many release version per day. Version range notation would be perfect for what you need.. i.e., [2.1, ) Having said that I found a number of problems with using version range and I am stuck with 2.0.6 because 2.0.7 gives me NPE when it tries to resolve conflict between version ranges. Cheers, rOnn c. Borut Bolčina [EMAIL PROTECTED] 11/26/2007 06:31 PM Please respond to Maven Users List users@maven.apache.org To Maven users@maven.apache.org cc Subject Version moving up fast Hello maven users, if one of our in-house jars (lets call it A.jar) is progressing fast in terms of artifact version numbers (several times per week: 2.1 - 2.2 - 2.3- ... - 2.678 - 2.679 - ...), what is the best way for other artifacts which depend on this fast one to always use the last one? All the artifacts which depend on the A, would have to have their poms modified to 2.1-SNAPSHOT, 2.2-SNAPSHOT etc. because the SNAPSHOT version is in the trunk. This is error prone. I haven't looked into the release plugin yet, but I don't think it addresses this issue. One solution might be to name the A's version to something like 999-SNAPSHOT and then all the other jars would have their dependencies to this version. This smells like a dead fish in the sewer to me. What do you say? ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Re: How to control versioning across multiple POMs?
Sorry Arron, I have missed that section of your mail. Yes you do need
commit access across all project. I think it is reasonable that if you
don't have commit access to all the projects then you need to manually
coordinate the change with everyone. It is a pain so commit access can
solve the problem very easily. If it is a politically sensitive thing to
gain this access you could try to configure your source control to only
give you access to pom.xml.
Also, looking at your poms, I think you have a very non conventional
setup. You have alot of dependencies setup in the parent pom with provided
scope - those dependencies also seems to be artifacts of your child
projects. To be honest, I'm really confused about the structure of your
poms. Have you converted this Maven project structure from Ant? How have
you managed to perform a release of your software without a the use of
release plugin? I can't imagine how your build will work as it is like
chicken and egg problem - i.e., you need all the artifacts of the 50+
modules before you even get to build all of them.
The release tag helps you to increment -SNAPSHOT version to non snapshot.
It then tag the code and pull the code out for a clean build which it's
artifacts then gets deployed to the repository. The pom version and parent
pom version is then incremented back to the next -SNAPSHOT ready for
development again. Basically it automates the manual work of tagging,
incrementing version numbers, commiting to source control and releasing
your software version.
${project.version} just refers to the version of the pom - this is a
built-in facility of Maven to reference various element value with the
pom.
Cheers,
rOnn c.
Aaron Zeckoski [EMAIL PROTECTED]
11/15/2007 08:27 PM
Please respond to
Maven Users List users@maven.apache.org
To
[EMAIL PROTECTED]
cc
Maven Users List users@maven.apache.org
Subject
Re: How to control versioning across multiple POMs?
Do you use release plugin?
The release plugin should increment the version of the parent pom and
the
pom itself for you.
If you mean this one:
http://maven.apache.org/plugins/maven-release-plugin/index.html
No. I had a hard time understanding what it actually does from the
docs and it seems like I would need commit access to all the
sub-projects (which I do not have).
If you have dependencies to sibling pom in your dependencies
declaration,
I'd use version${project.version}/version to get around the problem
that
the release tag won't increment the version back to snapshot.
What do you mean? Where would I specify this property? In the master
POM? Is this a special property in maven2?
I have a series of 3 POMs and I need to be able to control versioning
across them. They are arranged like so:
master POM (parent of) base POM (parent of) project POM
There is one master and one base POM but there are many many project
POMs, roughly 50+ currently with new ones being added
The master POM has a version (as it seems all children must specify
the version of the parent correctly in the parent tag). The base POM
has no version as it inherits from the master. The problem here is
that we want to upgrade the overall version... except that every
project POM specifies the version of either the master or base POM (in
the parent tag). It means we have to somehow coordinate among 50+
projects (which are controlled by various people/groups) and tell them
to all change the version of the parent.
This is not ideal at all and I suspect we are just doing something
dumb or completely wrong. So, how can we control the overall version
for all the projects without having to change all of the POMs?
You can view the source here if you like:
master: https://source.sakaiproject.org/svn/master/trunk/pom.xml
base: https://source.sakaiproject.org/contrib/caret/kernel/pom.xml
sample project:
https://source.sakaiproject.org/contrib/caret/kernel/alias/pom.xml
-AZ
--
Aaron Zeckoski ([EMAIL PROTECTED])
Senior Research Engineer - CARET - Cambridge University
[http://bugs.sakaiproject.org/confluence/display/~aaronz/]
Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
##
DISCLAIMER:
This email and any attachment may contain confidential information.
If you are not the intended recipient you are not authorized to copy
or disclose all or any part of it without the prior written consent
of Toyota.
Opinions expressed in this email and any attachments are those of the
sender and not necessarily the opinions of Toyota.
Please scan this email and any attachment(s) for viruses.
Toyota does not accept any responsibility for problems caused by
viruses, whether it is Toyota's fault or not.
Re: How to control versioning across multiple POMs?
Hi Aaron,
Do you use release plugin?
The release plugin should increment the version of the parent pom and the
pom itself for you.
If you have dependencies to sibling pom in your dependencies declaration,
I'd use version${project.version}/version to get around the problem
that the release tag won't increment the version back to snapshot.
Cheers,
rOnn c.
Aaron Zeckoski [EMAIL PROTECTED]
Sent by: [EMAIL PROTECTED]
11/15/2007 09:44 AM
Please respond to
Maven Users List users@maven.apache.org
To
Maven Users List users@maven.apache.org
cc
Subject
How to control versioning across multiple POMs?
I have a series of 3 POMs and I need to be able to control versioning
across them. They are arranged like so:
master POM (parent of) base POM (parent of) project POM
There is one master and one base POM but there are many many project
POMs, roughly 50+ currently with new ones being added
The master POM has a version (as it seems all children must specify
the version of the parent correctly in the parent tag). The base POM
has no version as it inherits from the master. The problem here is
that we want to upgrade the overall version... except that every
project POM specifies the version of either the master or base POM (in
the parent tag). It means we have to somehow coordinate among 50+
projects (which are controlled by various people/groups) and tell them
to all change the version of the parent.
This is not ideal at all and I suspect we are just doing something
dumb or completely wrong. So, how can we control the overall version
for all the projects without having to change all of the POMs?
You can view the source here if you like:
master: https://source.sakaiproject.org/svn/master/trunk/pom.xml
base: https://source.sakaiproject.org/contrib/caret/kernel/pom.xml
sample project:
https://source.sakaiproject.org/contrib/caret/kernel/alias/pom.xml
-AZ
--
Aaron Zeckoski ([EMAIL PROTECTED])
Senior Research Engineer - CARET - Cambridge University
[http://bugs.sakaiproject.org/confluence/display/~aaronz/]
Sakai Fellow - [http://aaronz-sakai.blogspot.com/]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
##
DISCLAIMER:
This email and any attachment may contain confidential information.
If you are not the intended recipient you are not authorized to copy
or disclose all or any part of it without the prior written consent
of Toyota.
Opinions expressed in this email and any attachments are those of the
sender and not necessarily the opinions of Toyota.
Please scan this email and any attachment(s) for viruses.
Toyota does not accept any responsibility for problems caused by
viruses, whether it is Toyota's fault or not.
##
Re: JUnit and Maven - compiling helper classes
You need to create a test-jar artifact out of your helper classes Put this in the pom of your helper classes plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId executions execution goals goaltest-jar/goal /goals /execution /executions /plugin This will create a test-jar. Then in the project that you depend on these helper classes in test packages, declare a dependency to it with a type tag. i.e., dependency groupIdyour group id/groupId artifactIdhelper project/artifactId versionversion/version typetest-jar/type scopetest/scope /dependency Cheers, rOnn c. jsweeney67 [EMAIL PROTECTED] 11/15/2007 11:16 AM Please respond to Maven Users List users@maven.apache.org To users@maven.apache.org cc Subject JUnit and Maven - compiling helper classes I'm a Maven newbie trying to incorporate JUnit tests into the build. Some of our JUnit test classes make use of shared code in helper classes that live in the test packages. When I run these tests from Eclipse, the helper classes are found and compiled. However, when a cmd-line Maven build tries to run these tests, it does not find these classes and the tests get compile errors. What is the prefered way to tell the .pom(s) to compile these helper classes as part of JUnit testing? -- View this message in context: http://www.nabble.com/JUnit-and-Maven---compiling-helper-classes-tf4808900s177.html#a13759355 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Re: JUnit and Maven - compiling helper classes
Yes the helper classes (in src/test/java) needs to be packaged and installed to the repository so that another maven project can reference. By default, maven-jar-plugin doesn't jar up class in src/test/java. By default, all of the classes in src/test/java as well as src/test/resources will be included in the jar. I don't see why it would matter if your unit tests are jarred up as well. The scope element tells that the dependencies are only for testing phase. The type element tells it to look for test jar of the helper artifact (rather than the helper jar itself). When you are ready to run the project, go to your root pom and do a clean install (this will make sure that your test jar is deployed to your local repository) Cheers, rOnn c. jsweeney67 [EMAIL PROTECTED] 11/15/2007 12:55 PM Please respond to Maven Users List users@maven.apache.org To users@maven.apache.org cc Subject Re: JUnit and Maven - compiling helper classes So, if I understand correctly, the helper classes need to be in a jar. These classes now live in the same packages as the JUnit tests so should the jar exclude the actual test classes? I then presume that the scope tag tells Maven to only look for the new jar if tests are being run, correct? Thanks! I appreciate the response. Ronn.Chinowutthichai wrote: You need to create a test-jar artifact out of your helper classes Put this in the pom of your helper classes plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId executions execution goals goaltest-jar/goal /goals /execution /executions /plugin This will create a test-jar. Then in the project that you depend on these helper classes in test packages, declare a dependency to it with a type tag. i.e., dependency groupIdyour group id/groupId artifactIdhelper project/artifactId versionversion/version typetest-jar/type scopetest/scope /dependency Cheers, rOnn c. -- View this message in context: http://www.nabble.com/JUnit-and-Maven---compiling-helper-classes-tf4808900s177.html#a13760218 Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Re: WebLogic Deployment ok from child, fails from parent ?
Thanks Scott, I just wanted to confirm that the behaviour that Anton asked for is not supported. Your response to him didn't really answer that question. I think the *default* behaviour that would be nice to have is when you perform mvn weblogic:deploy at root pom and any child poms that has artifact of type war/ear should get deployed to weblogic (I assume that we use plugin management here to define global behaviour of where the admin server is). I also think that this behaviour is consistent with other plugins in maven. The scenario you mentioned about an ear consisting of war in the same project tree, I think that is an exception case. Could you handle that by having a configuration in the parent pom plugin that allows user to ignores the deployment of certain project ? I have about 4 wars sub modules in my projects and yes in production I would deploy each of them individually but when I want to refresh DEV and TEST, it is a tedious work. Cheers, rOnn c. Scott Ryan [EMAIL PROTECTED] Sent by: Scott Ryan [EMAIL PROTECTED] 08/07/2007 10:25 PM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: WebLogic Deployment ok from child, fails from parent ? You have to run the deploy command from the war directory if you want to deploy the war. This is because the project type and object location are dynamically determined from the pom.xml of the directory you are running in. You cannot run the command from the parent directory because it will then try to deploy all artifacts in all projects which is not what you want. What is it you are trying to do exactly? The plugin will work with the deployment information defined anywhere in any parent pom but you must run the command from the proper project. I suppose I could include code to ignore deployments made from directories that are not supported but that breaks complex projects. For example if you have a parent and a war child and jar child and ear child. You only want the ear to deploy but how does the plugin know not to deploy the war as well. You will have to describe the scenario that you want to occur so that I can understand what you are expecting to happen. Use a complex project containing a parent pom of project type pom and 3 child projects one jar, one ear, and one war. What would you like to happen in this case? Scott Ryan On Aug 6, 2007, at 6:25 PM, [EMAIL PROTECTED] wrote: Scott, I have the same problem here, I have the plugin defined in parent pom (under pluginManagement). When I run mvn weblogic:deploy from the parent, it assumes that the parent pom is a war project and then tries to deploy the war artifact of the parent at the parent level. This immediately fails because the parent pom is simply an aggregate of sub modules and the war artifacts of the parent does not exists. Is this supported? If so I'd love to get it going too. Cheers, rOnn c. Scott Ryan [EMAIL PROTECTED] Sent by: Scott Ryan [EMAIL PROTECTED] 08/03/2007 11:53 PM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Re: WebLogic Deployment ok from child, fails from parent ? Why is the plugin definition not in your parent? If you run the command in the parent directory then the plugin definition needs to be there as well. Scott Ryan On Aug 3, 2007, at 1:04 AM, Anton Schoultz wrote: Hi, I have an prototype setup with three modules, 2 Jars and a WEB app. I have set up the WebLogic plugins in the web project. When I CD to the web project and mvn weblogic:deploy the web app is deployed as expected. However, if I go to the root/parent dir and try mvn weblogic:deploy I get this error [INFO] Reactor build order: [INFO] Unnamed - com.mergere.mvnbook:build-all-aggregator:pom:1 [INFO] console [INFO] helloworld [INFO] helloWeb [INFO] Searching repository for plugin with prefix: 'weblogic'. [INFO] - - -- [ERROR] BUILD ERROR [INFO] - - -- [INFO] The plugin 'org.apache.maven.plugins:maven-weblogic-plugin' does not exist or no valid version could be found in this setup I'm ONLY looking at deployment issues. Here's the parent pom project modelVersion4.0.0/modelVersion groupIdcom.mergere.mvnbook/groupId artifactIdbuild-all-aggregator/artifactId version1/version packagingpom/packaging modules moduleconsole/module modulehelloworld/module modulehelloWeb/module /modules /project And here's the web-app (child) pom project parent
Re: How to increase the memory usage for mvn?
You could set MAVEN_OPTS environment variable in your shell. e.g., set MAVEN_OPTS=-Xmx512M Cheers, rOnn c. Baz [EMAIL PROTECTED] 08/07/2007 09:19 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject How to increase the memory usage for mvn? Hi, How can i increase the memory usage for mvn? Like using ANT, there is an option for that right? Thanks. A. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
RE: Maven-Weblogic: NoClassDefFoundError for JAR in an EAR
Vaidya, I can't work out the directory structure of your EAR from your emails but the lib directory you mention should be in creditelseEAR.ear/APP-INF/lib/ and not creditelseEAR.ear/lib/ Weblogic should be able to find libraries within APP-INF/lib/ rOnn c. Vaidya, Supriya A (US - Chicago) [EMAIL PROTECTED] 08/07/2007 02:27 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject RE: Maven-Weblogic: NoClassDefFoundError for JAR in an EAR Ok... I just tried deploying the same EAR in the weblogic console - and it failed there too withteh same NoClassDefFoundError... WHY!?!??!?!? :o( The required class is packaged in a .jar. The jar is in the EAR's lib folder. The application.xml does not have mention to it tho (I don't see why it should) Where else am I missing its mention?? -Original Message- From: Vaidya, Supriya A (US - Chicago) Sent: Monday, August 06, 2007 11:00 AM To: 'Maven Users List' Subject: RE: Maven-Weblogic: NoClassDefFoundError for JAR in an EAR HI Scott - sorry I took so long to respond, got pulled into a few other things. Here is the stack trace on the maven console - below it is that on the weblogic server console: C:\CreditelseContinuance\creditelseEARmvn weblogic:deploy -X + Error stacktraces are turned on. Maven version: 2.0.7 Java version: 1.5.0_04 OS name: windows xp version: 5.1 arch: x86 [DEBUG] Building Maven user-level plugin registry from: 'C:\Documents and Settin gs\ch1svai1\.m2\plugin-registry.xml' [DEBUG] Building Maven global-level plugin registry from: 'C:\Maven\maven-2.0.7\ conf\plugin-registry.xml' [INFO] Scanning for projects... [DEBUG] Searching for parent-POM: com.something.credit:creditelse::2.0 of p roject: com.something.credit.else:creditelseEAR:ear:2.0 in relative pat h: ../pom.xml [DEBUG] Using parent-POM from the project hierarchy at: '../pom.xml' for project : com.something.credit.else:creditelseEAR:ear:2.0 [INFO] Searching repository for plugin with prefix: 'weblogic'. [DEBUG] Loading plugin prefixes from group: org.apache.maven.plugins [DEBUG] Skipping disabled repository Codehaus Snapshots [DEBUG] Skipping disabled repository Maven Snapshots [DEBUG] Loading plugin prefixes from group: org.codehaus.mojo [DEBUG] Skipping disabled repository Codehaus Snapshots [DEBUG] Skipping disabled repository Maven Snapshots [DEBUG] Skipping disabled repository Codehaus Snapshots [DEBUG] Skipping disabled repository Maven Snapshots [DEBUG] maven-compiler-plugin: resolved to version 2.0.2 from repository central [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::8 for pro ject: null:maven-compiler-plugin:maven-plugin:2.0.2 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-parent::5 for project: org .apache.maven.plugins:maven-plugins:pom:8 from the repository. [DEBUG] Retrieving parent-POM: org.apache:apache::3 for project: org.apache.mave n:maven-parent:pom:5 from the repository. [DEBUG] Skipping disabled repository central [DEBUG] Skipping disabled repository central [DEBUG] weblogic-maven-plugin: resolved to version 2.9.0-20070211.224419-10 from repository Maven Snapshots [DEBUG] Retrieving parent-POM: org.codehaus.mojo:mojo::13 for project: null:webl ogic-maven-plugin:maven-plugin:2.9.0-20070211.224419-10 from the repository. [DEBUG] weblogic-maven-plugin: resolved to version 2.9.0-20070211.224419-10 from repository Maven Snapshots [DEBUG] Skipping disabled repository Codehaus Snapshots [DEBUG] Skipping disabled repository Maven Snapshots [DEBUG] maven-ear-plugin: resolved to version 2.3 from repository central [DEBUG] Retrieving parent-POM: org.apache.maven.plugins:maven-plugins::7 for pro ject: null:maven-ear-plugin:maven-plugin:2.3 from the repository. [DEBUG] Retrieving parent-POM: org.apache.maven:maven-plugin-surrogate-parent::5 for project: org.apache.maven.plugins:maven-plugins:pom:7 from the repository. [DEBUG] weblogic-maven-plugin: resolved to version 2.9.0-20070211.224419-10 from repository Maven Snapshots [DEBUG] weblogic-maven-plugin: resolved to version 2.9.0-20070211.224419-10 from repository Maven Snapshots [INFO] - --- [INFO] Building creditelse [INFO]task-segment: [weblogic:deploy] [INFO] - --- [DEBUG] org.codehaus.mojo:weblogic-maven-plugin:maven-plugin:2.9.0-20070211.2244 19-10:runtime (selected for runtime) [DEBUG] Skipping disabled repository Codehaus Snapshots [DEBUG] Skipping disabled repository Maven Snapshots [DEBUG] Skipping disabled repository snapshots [DEBUG] Trying repository codehaus.org Downloading: http://repository.codehaus.org/web-maven/web-maven/1.0/web-maven-1. 0.pom [DEBUG] Unable to get resource 'web-maven:web-maven:pom:1.0' from repository cod ehaus.org (http://repository.codehaus.org) [DEBUG] Trying repository central Downloading:
Re: WebLogic Deployment ok from child, fails from parent ?
Scott,
I have the same problem here, I have the plugin defined in parent pom
(under pluginManagement).
When I run mvn weblogic:deploy from the parent, it assumes that the
parent pom is a war project and then tries to deploy the war artifact of
the parent at the parent level. This immediately fails because the parent
pom is simply an aggregate of sub modules and the war artifacts of the
parent does not exists.
Is this supported? If so I'd love to get it going too.
Cheers,
rOnn c.
Scott Ryan [EMAIL PROTECTED]
Sent by: Scott Ryan [EMAIL PROTECTED]
08/03/2007 11:53 PM
Please respond to
Maven Users List users@maven.apache.org
To
Maven Users List users@maven.apache.org
cc
Subject
Re: WebLogic Deployment ok from child, fails from parent ?
Why is the plugin definition not in your parent? If you run the
command in the parent directory then the plugin definition needs to
be there as well.
Scott Ryan
On Aug 3, 2007, at 1:04 AM, Anton Schoultz wrote:
Hi,
I have an prototype setup with three modules, 2 Jars and a WEB app.
I have set up the WebLogic plugins in the web project.
When I CD to the web project and mvn weblogic:deploy the web app is
deployed as expected.
However, if I go to the root/parent dir and try mvn
weblogic:deploy I
get this error
[INFO] Reactor build order:
[INFO] Unnamed - com.mergere.mvnbook:build-all-aggregator:pom:1
[INFO] console
[INFO] helloworld
[INFO] helloWeb
[INFO] Searching repository for plugin with prefix: 'weblogic'.
[INFO]
--
--
[ERROR] BUILD ERROR
[INFO]
--
--
[INFO] The plugin 'org.apache.maven.plugins:maven-weblogic-plugin'
does
not exist or no valid version could be found
in this setup I'm ONLY looking at deployment issues.
Here's the parent pom
project
modelVersion4.0.0/modelVersion
groupIdcom.mergere.mvnbook/groupId
artifactIdbuild-all-aggregator/artifactId
version1/version
packagingpom/packaging
modules
moduleconsole/module
modulehelloworld/module
modulehelloWeb/module
/modules
/project
And here's the web-app (child) pom
project
parent
artifactIdbuild-all-aggregator/artifactId
groupIdcom.mergere.mvnbook/groupId
version1/version
/parent
modelVersion4.0.0/modelVersion
groupIdanton/groupId
artifactIdhelloWeb/artifactId
namehelloWeb/name
descriptiontestWeb/description
packagingwar/packaging
version1.0-SNAPSHOT/version
urlhttp://maven.apache.org/url
dependencies
dependency
groupIdjunit/groupId
artifactIdjunit/artifactId
version3.8.1/version
scopetest/scope
/dependency
/dependencies
build
plugins
plugin!-- WebLogic Plugin for deploy
== WebLogic --
groupIdorg.codehaus.mojo/groupId
artifactIdweblogic-maven-plugin/artifactId
version2.9.0-SNAPSHOT/version
configuration
adminServerHostName${weblogicServerHostName}/
adminServerHostName!--
localhost --
adminServerPort${weblogicServerPort}/adminServerPort
adminServerProtocolhttp/adminServerProtocol
userId${weblogicUserId}/userId
password${weblogicPassword}/password
uploadtrue/upload
remotetrue/remote
verbosetrue/verbose
debugfalse/debug
targetNames${weblogicTargetNames}/targetNames
artifactPathD:\build\helloWeb\target\helloWeb-1.0-SNAPSHOT.war/
artifa
ctPath
namehelloWeb/name!-- app name on the
server --
projectPackagingwar/projectPackaging
/configuration
/plugin
/plugins
/build
/project
Any ideas? How should I be approaching this?
In our situataion we have 50 odd projects, most of which are
deployable
(ear / war),
with only a handfull being jar projects. We'd like to be able to
deploy
all of them in one cmd.
I figure each deployable project will have it's own weblogic plugin
and
config - with more
generic handling of the artifactPath obviously.
TestBox: WinXp; WebLogic:9.2x; Maven:2.0.6; Jdk:1.5.0_06
Anton Schoultz
Senior Java developer
Life Systems - Servicing
Discovery Life
Direct: +27 11 529 1636
Mobile: +27 83 651 7191
Email: [EMAIL PROTECTED]
Discovery Holdings Limited
Registration number: 1999/007789/06
This message and any attachments are confidential and intended
solely for the addressee. If you have received this message in
error, please notify
Overriding artifact name in the repository
Hi there, Pom.xml allows you to override final name of the artifact that gets generated. However, this final name doesn't get carried through when you deploy to the repository. I.e., if you have /myproject/common/library/pom.xml and say you override final name as myproject-common-library, myproject-common-library-1.1.jar gets generated. That is fine and good, however, when I deploy this library to the repository, the actual file name that resides in the repository is library-1.1.jar Is there anything I have missed? Is there a way to override the artifact name that gets deployed into the repository? Cheers, rOnn c. ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
Re: Production build question
Hi Chris, What about a cron job that rsync content from repo in dev regularly? Surely by the time your code gets to production, it would have had at least half an hour to sync the repository ;-) Also, I think putting repo artifacts in SCM will makes things very slow and painful - esp if you are dependent on lots of libraries. Regards, rOnn c. Chris Helck [EMAIL PROTECTED] 05/17/2007 05:04 AM Please respond to Maven Users List users@maven.apache.org To Maven Users List users@maven.apache.org cc Subject Production build question Hello, I need advice. Our production builds are handled by a separate group. They do the builds in a locked room with limited access to the company infrastructure, and no access to the outside world. They have access to our SCM. In the room they have a web server that has ssh access to a development web server. To do a maven based build they first rsync their web server's repo with the development one. Then the build machine accesses their web server. This is a pain for both developers and the build group. So, I'm thinking I should just put an image of the repo in SCM. This gives them a good audit trail and control. To do a build they first update the repo to the head of the SCM, then fetch the source code by a label, and finally kick off maven. I know SCM people don't like to put artifacts into SCM, but this seems like a reasonable use. Are there any maven specific issues/problems that this may cause? Thanks, Christopher Helck ** This communication and all information (including, but not limited to, market prices/levels and data) contained therein (the Information) is for informational purposes only, is confidential, may be legally privileged and is the intellectual property of ICAP plc and its affiliates (ICAP) or third parties. No confidentiality or privilege is waived or lost by any mistransmission. The Information is not, and should not be construed as, an offer, bid or solicitation in relation to any financial instrument or as an official confirmation of any transaction. The Information is not warranted, including, but not limited, as to completeness, timeliness or accuracy and is subject to change without notice. ICAP assumes no liability for use or misuse of the Information. All representations and warranties are expressly disclaimed. The Information does not necessarily reflect the views of ICAP. Access to the Information by anyone else other than the recipient is unauthorized and any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited. If you receive this message in error, please immediately delete it and all copies of it from your system, destroy any hard copies of it and notify the sender. ** ## DISCLAIMER: This email and any attachment may contain confidential information. If you are not the intended recipient you are not authorized to copy or disclose all or any part of it without the prior written consent of Toyota. Opinions expressed in this email and any attachments are those of the sender and not necessarily the opinions of Toyota. Please scan this email and any attachment(s) for viruses. Toyota does not accept any responsibility for problems caused by viruses, whether it is Toyota's fault or not. ##
