Re: Best way to retrieve multiple subsets from SVN?
Am 24.01.2013 05:39, schrieb Ron Wheeler: You manually put the jars in your Maven repo through its manual upload procedure with some version number (nice if it relates to the version that the authors gave them) and reference them as dependencies. That's 13 jars to be built from their sources, and 10 jars that they bundle as external dependencies. And since they're in pre-beta, I want to do that on a more-or-less daily basis. I don't think manual extraction is a good option for that. Maven does not really deal with SVN as a jar source. I have settled on this plan: a) Have one project per jar. (Place commonalities in a parent pom.) b) bind an svn export goal to the package phase c) configure it to extract the intended jar to target. Unless there's anything in that could come back and bite me, that looks like Maven can use SVN as a jar source right out of the box. Regards, Jo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Upload arbitrary directories to maven repositories
if your components are packaged as jar files hm, jars are java archives so I feel better if components containing sql-files and shell-scripts are compressed in rar files ..to a source control system.. SCS and ant are used to create the deliveries shown in the picture, and these deliveries are plugged together in a projectbuild. But this projectbuild may take place anywhere in the world in any intranet. So svn or git is no option for that. And we do not know what the end result will be, eg application.xml may contain 20 or 80 ejb-jars What is it about the file server that prompts you to want to change? the enduser can get a compressed fileserver structure or a compressed maven repository. Both will work, only the access is different: .m2\repository\com\org\BusinessComponent\xy0032_8a\BusinessComponent-xy0032_8a-assembly.rar .m2\repository\com\org\UIComponent\xy0024_9a\UIComponent-xy0024_9a-assembly.rar If someone says maven is not thought to be used in that way, he may be right. ant recommends not to use if-statements, but who cares, so why not Burkhard -- View this message in context: http://maven.40175.n5.nabble.com/Upload-arbitrary-directories-to-maven-repositories-tp5743526p5744376.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: Best way to retrieve multiple subsets from SVN?
On 24/01/2013 3:34 AM, Joachim Durchholz wrote: Am 24.01.2013 05:39, schrieb Ron Wheeler: You manually put the jars in your Maven repo through its manual upload procedure with some version number (nice if it relates to the version that the authors gave them) and reference them as dependencies. That's 13 jars to be built from their sources, and 10 jars that they bundle as external dependencies. And since they're in pre-beta, I want to do that on a more-or-less daily basis. Are the 10 external dependencies changing each day? Who is building the 13 jars? How are you going to use SNAPSHOTS in the pre-beta phase? I don't think manual extraction is a good option for that. Maven does not really deal with SVN as a jar source. I have settled on this plan: a) Have one project per jar. (Place commonalities in a parent pom.) b) bind an svn export goal to the package phase c) configure it to extract the intended jar to target. Unless there's anything in that could come back and bite me, that looks like Maven can use SVN as a jar source right out of the box. If you really believe that you are building something that no one else has ever done, you may be justified in breaking new ground. You are going to be pretty much on your own since no one here is going to have any experience in doing what you are planning. The manuals and books are going to be less help to you since much of their processes will not apply to you. Every time you ask a question, you are going to get a lot of incorrect advice and a lot of questions about the context of your questions, if anyone has the time to get involved in something that is not clear. Remember that everyone here is busy with their own projects and take a few seconds to scan the incoming stuff to decide whether they have a quick answer. You are not going to meet that criteria for most people. Ron Regards, Jo - 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: Best way to retrieve multiple subsets from SVN?
On Thursday, 24 January 2013, Joachim Durchholz wrote: Am 24.01.2013 05:39, schrieb Ron Wheeler: You manually put the jars in your Maven repo through its manual upload procedure with some version number (nice if it relates to the version that the authors gave them) and reference them as dependencies. That's 13 jars to be built from their sources, and 10 jars that they bundle as external dependencies. And since they're in pre-beta, I want to do that on a more-or-less daily basis. I don't think manual extraction is a good option for that. Maven does not really deal with SVN as a jar source. I have settled on this plan: a) Have one project per jar. (Place commonalities in a parent pom.) b) bind an svn export goal to the package phase c) configure it to extract the intended jar to target. http://stackoverflow.com/questions/14462694/maven-2-how-to-change-a-dependencys-location/14476240#14476240 My answer to the above is inverse of what you are trying to do What you want to do is create a series of shim projects for each of these external libs, and then just have your CI server roll a release nightly Don't try to make it all one project, that way madness lies I'd have the version number of each shim project be the svn revision it is faking a build of Unless there's anything in that could come back and bite me, that looks like Maven can use SVN as a jar source right out of the box. Regards, Jo --**--**- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: I need a complete antrun:run command for invoking ant-task by its id, other than default-cli.
plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-antrun-plugin/artifactId version1.7/version executions execution phase!-- needs a lifecycle phase here --/phase idstartupTomcat/id goals goalrun/goal /goals Generally I'd expect you to have a lifecycle phase defined in the execution and then you'd run mvn phase and Antrun would be automatically invoked during that phase to start your Tomcat instance. If this startpTomcat step is not going to be a regular part of your build in this project, you can use Maven Profiles instead, but at that point I think there is no good reason to use Maven at all and you might as well use Ant directly with its own build.xml etc. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best way to retrieve multiple subsets from SVN?
Am 24.01.2013 16:35, schrieb Stephen Connolly: What you want to do is create a series of shim projects for each of these external libs, If you mean a just-pass-it-through-unchanged-already project with shim project, then yes that's what I want to do. and then just have your CI server roll a release nightly No CI actually, I'm going to bump up the revision whenever the circumstances warrant it. Mostly, whenever I hit a bug, I'll upgrade to their HEAD before doing a bug report. Don't try to make it all one project, that way madness lies One Maven project per jar, I promise :-) I'd have the version number of each shim project be the svn revision it is faking a build of My current unterstanding is that since I'm still several months away from a release to anybody, -SNAPSHOT will work just as well and avoid flooding the repo with useless revision-numbered project versions. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best way to retrieve multiple subsets from SVN?
Am 24.01.2013 15:00, schrieb Ron Wheeler: On 24/01/2013 3:34 AM, Joachim Durchholz wrote: Am 24.01.2013 05:39, schrieb Ron Wheeler: You manually put the jars in your Maven repo through its manual upload procedure with some version number (nice if it relates to the version that the authors gave them) and reference them as dependencies. That's 13 jars to be built from their sources, and 10 jars that they bundle as external dependencies. And since they're in pre-beta, I want to do that on a more-or-less daily basis. Are the 10 external dependencies changing each day? Extremely rarely, but since changes there aren't announced anywhere, I have to act as if it might change any day. Who is building the 13 jars? I can choose, they're delivering the sources as well as precompiled jars. No source jars though, so I'll just svn checkout/update in the generate-sources phase and let the standard compile etc. mechanisms of maven do their thing. Sounds easier than explicitly configuring an attach-sources etc. goal. How are you going to use SNAPSHOTS in the pre-beta phase? I build my project based on that. Whenever I hit a bug, I submit a bug report, which usually gets fixed. Since my own project is months from a release, that's okay. If I find I'm nearing release before the external project doesn, I'll probably drop the SNAPSHOT qualifier and hardcode a known good pre-beta revision. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best way to retrieve multiple subsets from SVN?
On 24/01/2013 11:54 AM, Joachim Durchholz wrote: Am 24.01.2013 15:00, schrieb Ron Wheeler: On 24/01/2013 3:34 AM, Joachim Durchholz wrote: Am 24.01.2013 05:39, schrieb Ron Wheeler: You manually put the jars in your Maven repo through its manual upload procedure with some version number (nice if it relates to the version that the authors gave them) and reference them as dependencies. That's 13 jars to be built from their sources, and 10 jars that they bundle as external dependencies. And since they're in pre-beta, I want to do that on a more-or-less daily basis. Are the 10 external dependencies changing each day? Extremely rarely, but since changes there aren't announced anywhere, I have to act as if it might change any day. Do you really want to always get the changes without any notice about what has changed? I would be worried about seemingly random changes in my artifacts' behaviour that might take a long time to debug if they were caused by bug fixes in the external software that affected my stuff. We stick with a version of an external library as long as possible and when we do upgrade, we communicate this to everyone so that no one spends hours trying to find out why a change in their code caused a change in another part of the project. It was better to be a bit behind in a stable state than right up to date but in an unstable environment. Who is building the 13 jars? I can choose, they're delivering the sources as well as precompiled jars. No source jars though, so I'll just svn checkout/update in the generate-sources phase and let the standard compile etc. mechanisms of maven do their thing. Sounds easier than explicitly configuring an attach-sources etc. goal. This is almost the same as your own code except that you are not writing it. It is like being part of a team where they are letting you do the maven build. Same discussion as above. I would prefer to build a set of libraries, put them in my repo with a made up version and freeze the version dependency in my POMS until my code required an updated version. How are you going to use SNAPSHOTS in the pre-beta phase? I build my project based on that. Whenever I hit a bug, I submit a bug report, which usually gets fixed. Since my own project is months from a release, that's okay. If I find I'm nearing release before the external project doesn, I'll probably drop the SNAPSHOT qualifier and hardcode a known good pre-beta revision. I would do that during development and only upgrade to their latest version when: a) I really needed a new feature or bug fix to move forward or b) My code was stable and I had time to test their code for integration issues. If your code works with the last version of other people's stuff that you downloaded and placed in your repo, you can release with perfect confidence that you can come back at anytime and rebuild your application and get the same product out of your build. You can apply a patch to your code and know that your patch is responsible for all of the new behaviour. Trying to test and debug your own stuff is hard enough without having odd behaviours creep in while you are working. Ron - 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: maven-scm-publish-plugin freezed in Apache Oltu
We've seen this to. It's got to do with the huge number of files to be committed. One trick is to configure http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#notimestamp This way you can reduce the number of commits. Robert Op Thu, 24 Jan 2013 08:51:16 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi all guys, at Apache Oltu[1] (formerly Amber) we are adopting the maven-scm-publish-plugin to publish the site; everything looks be configured in the right way, but the plugin is stuck: +-+ [INFO] --- maven-scm-publish-plugin:1.0-beta-2:publish-scm (default-cli) @ amber-parent --- [INFO] Updating the pub tree from scm:svn:https://svn.apache.org/repos/asf/oltu/site ... [INFO] Executing: /bin/sh -c cd /Users/stripodi/oltu-site-content svn --username simonetripodi --password '*' --no-auth-cache --non-interactive update /Users/stripodi/oltu-site-content [INFO] Working directory: /Users/stripodi/oltu-site-content [INFO] changeSets [ null null Updating '.':, 0 null ] [INFO] Updating content... [INFO] Publish files: 0 addition(s), 1918 update(s), 0 delete(s) [INFO] Checking in SCM... [INFO] Checking in to the scm [INFO] Executing: /bin/sh -c cd /Users/stripodi/oltu-site-content svn --username simonetripodi --password '*' --no-auth-cache --non-interactive commit --file /var/folders/fm/yfzywr7s1d3c_36qc2l9whccgn/T/maven-scm-965165864.commit [INFO] Working directory: /Users/stripodi/oltu-site-content +-+ I let the laptop doing its work for all night long, but when I woke up the plugin was still in this status. Is there any way to monitor its activities? Many thanks in advance, all the best, -Simo [1] https://svn.apache.org/repos/asf/oltu/trunk http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best way to retrieve multiple subsets from SVN?
Am 24.01.2013 18:53, schrieb Ron Wheeler: On 24/01/2013 11:54 AM, Joachim Durchholz wrote: Am 24.01.2013 15:00, schrieb Ron Wheeler: On 24/01/2013 3:34 AM, Joachim Durchholz wrote: Am 24.01.2013 05:39, schrieb Ron Wheeler: You manually put the jars in your Maven repo through its manual upload procedure with some version number (nice if it relates to the version that the authors gave them) and reference them as dependencies. That's 13 jars to be built from their sources, and 10 jars that they bundle as external dependencies. And since they're in pre-beta, I want to do that on a more-or-less daily basis. Are the 10 external dependencies changing each day? Extremely rarely, but since changes there aren't announced anywhere, I have to act as if it might change any day. Do you really want to always get the changes without any notice about what has changed? I have little choice in that matter. I would be worried about seemingly random changes in my artifacts' behaviour that might take a long time to debug if they were caused by bug fixes in the external software that affected my stuff. I haven't had to work around a bug yet, so I'm not too worried about bug fixes breaking my code, and I fact I haven't had a problem of that kind yet. Once it becomes a problem, I'll stabilize the revision. Hopefully, that will happen after they release a stable version, but that's Not There Yet so I'm simply sticking with that works best at the time. Who is building the 13 jars? I can choose, they're delivering the sources as well as precompiled jars. No source jars though, so I'll just svn checkout/update in the generate-sources phase and let the standard compile etc. mechanisms of maven do their thing. Sounds easier than explicitly configuring an attach-sources etc. goal. This is almost the same as your own code except that you are not writing it. It is like being part of a team where they are letting you do the maven build. Exactly. Same discussion as above. I would prefer to build a set of libraries, put them in my repo with a made up version and freeze the version dependency in my POMS until my code required an updated version. Yes, but it's not necessary yet. And I wish to use the stable build when it comes out, so I'm sailing along with the updates to see any problems as soon as they arise. How are you going to use SNAPSHOTS in the pre-beta phase? I build my project based on that. Whenever I hit a bug, I submit a bug report, which usually gets fixed. Since my own project is months from a release, that's okay. If I find I'm nearing release before the external project doesn, I'll probably drop the SNAPSHOT qualifier and hardcode a known good pre-beta revision. I would do that during development and only upgrade to their latest version when: a) I really needed a new feature or bug fix to move forward or b) My code was stable and I had time to test their code for integration issues. I have little logic that I can test (yet). If your code works with the last version of other people's stuff that you downloaded and placed in your repo, you can release with perfect confidence that you can come back at anytime and rebuild your application and get the same product out of your build. You can apply a patch to your code and know that your patch is responsible for all of the new behaviour. Trying to test and debug your own stuff is hard enough without having odd behaviours creep in while you are working. I have the sources, so I'm not even noticing much when I cross the border to external code. What I've been using of the external code isn't that much; I can easily spot any problems that might have crept in. Things will get differently as I use more and more of their code, and I'll stabilize some day for sure. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: maven-scm-publish-plugin freezed in Apache Oltu
thanks a lot Robert, very appreciated! -Simo http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ On Thu, Jan 24, 2013 at 7:05 PM, Robert Scholte rfscho...@apache.org wrote: We've seen this to. It's got to do with the huge number of files to be committed. One trick is to configure http://maven.apache.org/plugins/maven-javadoc-plugin/javadoc-mojo.html#notimestamp This way you can reduce the number of commits. Robert Op Thu, 24 Jan 2013 08:51:16 +0100 schreef Simone Tripodi simonetrip...@apache.org: Hi all guys, at Apache Oltu[1] (formerly Amber) we are adopting the maven-scm-publish-plugin to publish the site; everything looks be configured in the right way, but the plugin is stuck: +-+ [INFO] --- maven-scm-publish-plugin:1.0-beta-2:publish-scm (default-cli) @ amber-parent --- [INFO] Updating the pub tree from scm:svn:https://svn.apache.org/repos/asf/oltu/site ... [INFO] Executing: /bin/sh -c cd /Users/stripodi/oltu-site-content svn --username simonetripodi --password '*' --no-auth-cache --non-interactive update /Users/stripodi/oltu-site-content [INFO] Working directory: /Users/stripodi/oltu-site-content [INFO] changeSets [ null null Updating '.':, 0 null ] [INFO] Updating content... [INFO] Publish files: 0 addition(s), 1918 update(s), 0 delete(s) [INFO] Checking in SCM... [INFO] Checking in to the scm [INFO] Executing: /bin/sh -c cd /Users/stripodi/oltu-site-content svn --username simonetripodi --password '*' --no-auth-cache --non-interactive commit --file /var/folders/fm/yfzywr7s1d3c_36qc2l9whccgn/T/maven-scm-965165864.commit [INFO] Working directory: /Users/stripodi/oltu-site-content +-+ I let the laptop doing its work for all night long, but when I woke up the plugin was still in this status. Is there any way to monitor its activities? Many thanks in advance, all the best, -Simo [1] https://svn.apache.org/repos/asf/oltu/trunk http://people.apache.org/~simonetripodi/ http://simonetripodi.livejournal.com/ http://twitter.com/simonetripodi http://www.99soft.org/ - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best way to retrieve multiple subsets from SVN?
Seems a pity not to just set it up right at the start and then your life with maven would be harmonious. What I suggested is a way to use maven in a way that everyone here could help you and your builds would be very simple. Stephen seems to be giving you a solution that fits with what you want and he knows maven inside out. Ron On 24/01/2013 1:21 PM, Joachim Durchholz wrote: Am 24.01.2013 18:53, schrieb Ron Wheeler: On 24/01/2013 11:54 AM, Joachim Durchholz wrote: Am 24.01.2013 15:00, schrieb Ron Wheeler: On 24/01/2013 3:34 AM, Joachim Durchholz wrote: Am 24.01.2013 05:39, schrieb Ron Wheeler: You manually put the jars in your Maven repo through its manual upload procedure with some version number (nice if it relates to the version that the authors gave them) and reference them as dependencies. That's 13 jars to be built from their sources, and 10 jars that they bundle as external dependencies. And since they're in pre-beta, I want to do that on a more-or-less daily basis. Are the 10 external dependencies changing each day? Extremely rarely, but since changes there aren't announced anywhere, I have to act as if it might change any day. Do you really want to always get the changes without any notice about what has changed? I have little choice in that matter. I would be worried about seemingly random changes in my artifacts' behaviour that might take a long time to debug if they were caused by bug fixes in the external software that affected my stuff. I haven't had to work around a bug yet, so I'm not too worried about bug fixes breaking my code, and I fact I haven't had a problem of that kind yet. Once it becomes a problem, I'll stabilize the revision. Hopefully, that will happen after they release a stable version, but that's Not There Yet so I'm simply sticking with that works best at the time. Who is building the 13 jars? I can choose, they're delivering the sources as well as precompiled jars. No source jars though, so I'll just svn checkout/update in the generate-sources phase and let the standard compile etc. mechanisms of maven do their thing. Sounds easier than explicitly configuring an attach-sources etc. goal. This is almost the same as your own code except that you are not writing it. It is like being part of a team where they are letting you do the maven build. Exactly. Same discussion as above. I would prefer to build a set of libraries, put them in my repo with a made up version and freeze the version dependency in my POMS until my code required an updated version. Yes, but it's not necessary yet. And I wish to use the stable build when it comes out, so I'm sailing along with the updates to see any problems as soon as they arise. How are you going to use SNAPSHOTS in the pre-beta phase? I build my project based on that. Whenever I hit a bug, I submit a bug report, which usually gets fixed. Since my own project is months from a release, that's okay. If I find I'm nearing release before the external project doesn, I'll probably drop the SNAPSHOT qualifier and hardcode a known good pre-beta revision. I would do that during development and only upgrade to their latest version when: a) I really needed a new feature or bug fix to move forward or b) My code was stable and I had time to test their code for integration issues. I have little logic that I can test (yet). If your code works with the last version of other people's stuff that you downloaded and placed in your repo, you can release with perfect confidence that you can come back at anytime and rebuild your application and get the same product out of your build. You can apply a patch to your code and know that your patch is responsible for all of the new behaviour. Trying to test and debug your own stuff is hard enough without having odd behaviours creep in while you are working. I have the sources, so I'm not even noticing much when I cross the border to external code. What I've been using of the external code isn't that much; I can easily spot any problems that might have crept in. Things will get differently as I use more and more of their code, and I'll stabilize some day for sure. - 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: Best way to retrieve multiple subsets from SVN?
Am 24.01.2013 19:53, schrieb Ron Wheeler: Seems a pity not to just set it up right at the start and then your life with maven would be harmonious. What I suggested is a way to use maven in a way that everyone here could help you and your builds would be very simple. Sorry, I must have been missing something then. I was considering you and me to be in a QA phase, with no final advice given yet. Stephen seems to be giving you a solution that fits with what you want and he knows maven inside out. I'm not sure I understand; I was thinking I was already following his advice. To wrap it all up: There's that external upstream project providing precompiled jars from a common SVN tree, which may change any time. My current approach is a set of minimal checkout-the-jar projects (one for each jar), plus a parent pom that provides the SCM coordinates and other commonalities. Revision number will be bumped manually, at intervals as the circumstances dictate. There's some variance as the SVN also contains sources, allowing me to compile 13 of the 23 jars myself. To get that, I'd vary the checkout to pull the sources instead of the jars and let Maven do its compile phases, giving me a functionally equivalent but more complete artifact set with source and javadoc jars. I'm using SNAPSHOT until either I publish the artifacts to a downstream project (highly unlikely), the upstream project declares a stable version, or I hit some blocker that's not going to be fixed upstream and I decide to stick with the last upstream version that works for me. Any obvious flaws with that? Regards, Jo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best way to retrieve multiple subsets from SVN?
If you are either replacing the (empty) jar with your real jar in the package phase of your 13 projects without source, And with the disclaimer that we don't like this way and prefer the MRM + simple shell script to do the mvn deploy:deploy-file, but understand your needs, you should be ok Note (if you are somebody else reading this later) that our recommended way is a MRM and shell script to run through mvn deploy:deploy-file for each of the jars. On Thursday, 24 January 2013, Joachim Durchholz wrote: Am 24.01.2013 19:53, schrieb Ron Wheeler: Seems a pity not to just set it up right at the start and then your life with maven would be harmonious. What I suggested is a way to use maven in a way that everyone here could help you and your builds would be very simple. Sorry, I must have been missing something then. I was considering you and me to be in a QA phase, with no final advice given yet. Stephen seems to be giving you a solution that fits with what you want and he knows maven inside out. I'm not sure I understand; I was thinking I was already following his advice. To wrap it all up: There's that external upstream project providing precompiled jars from a common SVN tree, which may change any time. My current approach is a set of minimal checkout-the-jar projects (one for each jar), plus a parent pom that provides the SCM coordinates and other commonalities. Revision number will be bumped manually, at intervals as the circumstances dictate. There's some variance as the SVN also contains sources, allowing me to compile 13 of the 23 jars myself. To get that, I'd vary the checkout to pull the sources instead of the jars and let Maven do its compile phases, giving me a functionally equivalent but more complete artifact set with source and javadoc jars. I'm using SNAPSHOT until either I publish the artifacts to a downstream project (highly unlikely), the upstream project declares a stable version, or I hit some blocker that's not going to be fixed upstream and I decide to stick with the last upstream version that works for me. Any obvious flaws with that? Regards, Jo --**--**- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: Best way to retrieve multiple subsets from SVN?
Am 24.01.2013 21:23, schrieb Stephen Connolly: If you are either replacing the (empty) jar with your real jar in the package phase of your 13 projects without source, Ah, good to know. I had intended to put that into an earlier phase, but of course the compiler will recreate the jar. Thanks. And with the disclaimer that we don't like this way and prefer the MRM + simple shell script to do the mvn deploy:deploy-file, but understand your needs, you should be ok Note (if you are somebody else reading this later) that our recommended way is a MRM and shell script to run through mvn deploy:deploy-file for each of the jars. I can see the issues with that. Personally, I'm feeling a bit uneasy about manipulating a repo via an MRM. With a pom, I have a versionable, auditable record of what's getting installed, how and (hopefully) why. Command-line actions tend to get forgotten. I'm probably seeing it that way because my primary means of creating a reviewable history is through an SCM, not through Maven. I'm seeing an overlap in functions between Maven and SCMs here; I'm not sure whether thats a good or a bad thing, but I'll let that issue rest for now :-) Regards, Jo - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
