Re: Different behavior when building a project as a module or stand-alone
Are you using a Maven repo such as Nexus? Can you not give your corporate libraries GAV designations that are controlled so the version numbers are monotonically increasing? We do use a Maven repo, although we had to abandon Nexus in favor of Artifactory. Originally, we used versions when deploying those corporate libraries, but we didn't know how to automate the whole thing (namely, upgrading the version numbers). The easiest I could come up with was antrun + external properties files. This was considered going overboard for a basic use case, so we abandoned that idea, in favor of using a single version. There must be simpler ways to do this out there, but I did not manage to find them. Since there are no SCM interactions, release plugin didn't seem to fit. I looked at a couple of third party plugins (this one, for instance : http://mojo.codehaus.org/versions-maven-plugin/), but I couldn't find what I was looking for. The solution might be right in front of me, but I can't find it. I'd appreciate a lot some pointers on this issue. The problem I encountered would probably be void if I was doing things right. I want to be sure that I understand what you are saying here. The versions are DIFFERENT each time you run deploy-file, right? It is a basic premise of Maven and most sane build systems that that a given artifact with a particular version number must be immutable. Otherwise you have no idea if your file versioned 2.3.2 is the right one vs another file with version 2.3.2 that exists somewhere else. This is a problem we failed to take into consideration. We are effectively using a single, fixed version, which means there is only one jar/pom for each of the corporate libraries managed this way. We acknowledged that this was definitely not the intended way of managing libraries, but we didn't see that one problem you pointed out. It is somewhat lessened by the fact that only one person updates these libraries, and that my project is the only one to resolve these dependencies from our Maven repository, but clearly, this will become problematic at some point. As I mentionned above, these problem originate from the fact that I am not managing these corporate libraries the way I should. I will revert to manual, version enabled deployment for the time being, but I remain extremely interested in automating the process (basically, how to automatically increment the version using maven plugins, or something not too far-fetched). Any help on this matter will be greatly appreciated ! Philippe -- View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5614606.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: Different behavior when building a project as a module or stand-alone
looked at a couple of third party plugins (this one, for instance : http://mojo.codehaus.org/versions-maven-plugin/), but I couldn't find what I I don't see why you would look to versioning things yourself. The artifact should be delivered with a version associated with it from the group responsible for producing it. each of the corporate libraries managed this way. We acknowledged that this was definitely not the intended way of managing libraries, but we didn't see that one problem you pointed out. Ah yes this one, tiny, problem was unforseen. ;-) As I mentioned above, these problem originate from the fact that I am not managing these corporate libraries the way I should. I will revert to Somehow, you should force the party providing you these artifacts to VERSION them. And ideally they could also DEPLOY them into your Nexus/Artifactory instance so that you could merely depend on them in your own projects. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Different behavior when building a project as a module or stand-alone
Thanks for your answer, Wayne. I'll refrain from using Nabble's formatting options from now on. Here are the informations from my first message, in plain text this time. === === === My project has a basic multi-module structure, like this : project |_project-core |_project-web |_project-batch The thing is, I get two different results for executing mvn clean package, whether I run it from project-core or from project. From project-core [INFO] [INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ profilage-core --- [INFO] Building jar: D:\ozp6kz\Mes Documents\eclipse_workspace\ProjetProfilage\profilage-core\target\profilage-core-0.1.jar From project [INFO] [INFO] --- maven-jar-plugin:2.3.1:jar (default-jar) @ profilage-core --- [WARNING] JAR will be empty - no content was marked for inclusion! [INFO] Building jar: D:\ozp6kz\Mes Documents\eclipse_workspace\ProjetProfilage\profilage-core\target\profilage-core-0.1.jar [INFO] Basically, as a stand-alone, the project builds perfectly well, which allows in turn the other modules to build correctly. But when built as part of the global, multi-module project, there's this one [WARNING] line which throws off the rest of the build. === === === When preparing my code for paste-bins, I (finally) noticed the difference between the two builds. It happens during the execution of dependency:purge-local-repository. As you can see in the build pastebins below, there's only one library affected (profilage-lse). But, it's re-downloaded once during the standalone build, and twice during the multi-module build. Might seem benign, but when I comment out the execution for that goal, the warning disappears, and the multimodule build is successful. I'm definitely at a loss as to why this happens, so any explanation would be greatly appreciated ! Here are the pastebins from poms and builds, expurged of information unrelated : pom.xml - core module : http://commitcode.com/p/r/57wI2E5ovTY.html pom.xml - project parent : http://commitcode.com/p/r/57wI4xQmdLk.html pom.xml - corporate parent : http://commitcode.com/p/r/xX96TKUHndS.html pom.xml - help:effective-pom : http://commitcode.com/p/r/57wI8D7a2eV.html build - standalone : http://commitcode.com/p/r/xX97siekqj5.html build - as a module : http://commitcode.com/p/r/57wIbt2oV2v.html Philippe -- View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5611840.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: Different behavior when building a project as a module or stand-alone
between the two builds. It happens during the execution of dependency:purge-local-repository. As you can see in the build pastebins I have a lot of projects that are built with Maven, and not a single one uses purge-local-repo. Why are you using it? below, there's only one library affected (profilage-lse). But, it's re-downloaded once during the standalone build, and twice during the multi-module build. Might seem benign, but when I comment out the execution for that goal, the warning disappears, and the multimodule build is successful. I would eliminate your usage of purge-local-repo if at all possible since it sounds like that would solve your problem. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Different behavior when building a project as a module or stand-alone
Indeed, our use case for purge-local-repository is a bit dodgy and definitely sub-optimal. Our project depends on various corporate libraries which are not Mavenized. In order to use these libraries, we frequently use deploy:deploy-file to drop them on our repository, with a fixed version (given that new versions are duly tested and obsolete older versions). Clearly, this is not the best way of doing things, but it was by far the easiest solution for us, and we expected it to be somewhat sustainable. The purge-local-repo goal (with the right set of exclusions) was used in order to ensure the latest versions of there corporate libraries were used whenever we release a new version of the project. I configured an execution as it was the first idea I had in order to have the goal run once for a multi-module build. Now, since it doesn't seem to work all that well, it probably won't be too hard finding another way around, so I suppose we can say my problem is closed. But I'm still curious as to why this problem occurred, can anyone fill me in on that ? No biggie if it's not possible, but I do wonder what I did wrong there (aside from the management of non-maven libraries ;) ) ! Anyway, thanks for your insight, Wayne ! Philippe -- View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5612860.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: Different behavior when building a project as a module or stand-alone
Are you using a Maven repo such as Nexus? Can you not give your corporate libraries GAV designations that are controlled so the version numbers are monotonically increasing? Ron On 02/04/2012 11:53 AM, Philippe Lagardère wrote: Indeed, our use case for purge-local-repository is a bit dodgy and definitely sub-optimal. Our project depends on various corporate libraries which are not Mavenized. In order to use these libraries, we frequently use deploy:deploy-file to drop them on our repository, with a fixed version (given that new versions are duly tested and obsolete older versions). Clearly, this is not the best way of doing things, but it was by far the easiest solution for us, and we expected it to be somewhat sustainable. The purge-local-repo goal (with the right set of exclusions) was used in order to ensure the latest versions of there corporate libraries were used whenever we release a new version of the project. I configured an execution as it was the first idea I had in order to have the goal run once for a multi-module build. Now, since it doesn't seem to work all that well, it probably won't be too hard finding another way around, so I suppose we can say my problem is closed. But I'm still curious as to why this problem occurred, can anyone fill me in on that ? No biggie if it's not possible, but I do wonder what I did wrong there (aside from the management of non-maven libraries ;) ) ! Anyway, thanks for your insight, Wayne ! Philippe -- View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5612860.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
Re: Different behavior when building a project as a module or stand-alone
Our project depends on various corporate libraries which are not Mavenized. In order to use these libraries, we frequently use deploy:deploy-file to drop them on our repository, with a fixed version (given that new versions are duly tested and obsolete older versions). I want to be sure that I understand what you are saying here. The versions are DIFFERENT each time you run deploy-file, right? It is a basic premise of Maven and most sane build systems that that a given artifact with a particular version number must be immutable. Otherwise you have no idea if your file versioned 2.3.2 is the right one vs another file with version 2.3.2 that exists somewhere else. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Different behavior when building a project as a module or stand-alone
Hello, When trying to set up an assembly for a project, I ran into a problem I can't seem to find an explanation for. My project has a basic multi-module structure, like this : The thing is, I get two different results for executing /mvn clean package/, whether I run it from /project-core/ or from /project/. *From project-core* *From project* And indeed, the .jar is empty (safe a couple of metadata files), which cause the build to fail on /project-web/, which depends on /project-core/ The main oddities I have set up for the build are : 1) maven-dependency-plugin:purge-local-repository, executed at /prepare-package/ for /project-core/ only 2) maven-assembly-plugin:single, executed at /package/ for the web and batch projects, but the global build fails before they even kick in ;) I did not configure the /maven-jar-plugin/, so this is what I have in the effective pom : I'm using Maven 3.0.3, and a 1.6.0_24 JDK if it makes any difference. Sorry if this problem is common knowledge, I just didn't know what to search for in the mailing list ! Thank you ! Philippe -- View this message in context: http://maven.40175.n5.nabble.com/Different-behavior-when-building-a-project-as-a-module-or-stand-alone-tp5607081p5607081.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: Different behavior when building a project as a module or stand-alone
My project has a basic multi-module structure, like this : The thing is, I get two different results for executing /mvn clean package/, whether I run it from /project-core/ or from /project/. *From project-core* *From project* Just an FYI. No one on the mailing list saw parts of what you posted, probably because Nabble ate the XML or because this mailing list does not support attachments. Convert your email to 100% plain text and try again. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Different behavior when building a project as a module or stand-alone
And indeed, the .jar is empty (safe a couple of metadata files), which cause the build to fail on /project-web/, which depends on /project-core/ Generally this should just work no matter where you have started your build. If it isn't working, that usually suggests you have configured something improperly in a pom somewhere. Is your source code in src/main/java as it should be? Or are you doing something funky with sourceDirectory that might involve ..? In short, what does your pom file for the project-core look like? Post it to pastebin or gist and send a link here. Perhaps also post the help:effective-pom output. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org