Re: ActiveMQ POM
I'm actually ok with that. overwriting old artifacts. That part the kinda sucks is that maven won't download updates to those artifacts. On 11/14/06, Fritz Oconer [EMAIL PROTECTED] wrote: Hi, I think the downside here is that it will loose reference to previous builds. Since development will not change to timestamp, then deploy will just overwrite the existing artifacts. Regards, Fritz - Original Message - From: Hiram Chirino [EMAIL PROTECTED] To: activemq-dev@geronimo.apache.org Sent: Wednesday, November 15, 2006 12:52 AM Subject: Re: ActiveMQ POM Thanks Fritz! I knew there had to be a reason that I was just not aware of. What do you think would be the downsides of not using the special SNAPSHOT handling that maven provides? What if we tagged our SNAPSHOT builds with something like like DEVELOPMENT instead of SNAPSHOT. I'm guessing that problem would go away, but what other ones would we get? On 11/14/06, Guillaume Nodet [EMAIL PROTECTED] wrote: This is also my experience. If we just use the real version 4.2-SNAPSHOT for example, it should also work and maven should be able to change (*nearly*) all these occurrences when using the release plugin. I say nearly, because in ServiceMix, there are some edge cases where this fail (when including the version in files other than pom.xml like artifacts resources for example). On 11/14/06, Fritz Oconer [EMAIL PROTECTED] wrote: Hi, I added ${activemq-version} instead of ${project.version} basically as a workaround for build failures due to differences in timestamp. If we use ${project.version} then it will require all activemq type artifacts (specified as dependency in the parent pom.xml) to have the same timestamp as the parent. This becomes an issue when nightly-build deploy fails after some of the modules have been deployed causing some activemq modules to have different timestamp as the parent. We can change this back to using project.version but we need to make sure that nightly-build always deploys successfully or I wonder if there is another workaround for this? https://issues.apache.org/activemq/browse/AMQ-956 Regards, Fritz - Original Message - From: Hiram Chirino [EMAIL PROTECTED] To: activemq-dev@geronimo.apache.org Sent: Tuesday, November 14, 2006 8:48 PM Subject: ActiveMQ POM Howdy, I was wondering if anybody knows why we are using ${activemq-version} instead of ${project.version} in our ActiveMQ poms?? When doing a release build, it's easy to forget that you need to updated the version in to places. Can't we just use the ${project.version} variable?? -- Regards, Hiram Blog: http://hiramchirino.com -- Cheers, Guillaume Nodet -- Regards, Hiram Blog: http://hiramchirino.com -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ POM
On 11/14/06, Guillaume Nodet [EMAIL PROTECTED] wrote: I think the main problem is that users will never download newest versions. IMHO, this would be a bad idea. yeah. On 11/14/06, Hiram Chirino [EMAIL PROTECTED] wrote: Thanks Fritz! I knew there had to be a reason that I was just not aware of. What do you think would be the downsides of not using the special SNAPSHOT handling that maven provides? What if we tagged our SNAPSHOT builds with something like like DEVELOPMENT instead of SNAPSHOT. I'm guessing that problem would go away, but what other ones would we get? On 11/14/06, Guillaume Nodet [EMAIL PROTECTED] wrote: This is also my experience. If we just use the real version 4.2-SNAPSHOT for example, it should also work and maven should be able to change (*nearly*) all these occurrences when using the release plugin. I say nearly, because in ServiceMix, there are some edge cases where this fail (when including the version in files other than pom.xml like artifacts resources for example). On 11/14/06, Fritz Oconer [EMAIL PROTECTED] wrote: Hi, I added ${activemq-version} instead of ${project.version} basically as a workaround for build failures due to differences in timestamp. If we use ${project.version} then it will require all activemq type artifacts (specified as dependency in the parent pom.xml) to have the same timestamp as the parent. This becomes an issue when nightly-build deploy fails after some of the modules have been deployed causing some activemq modules to have different timestamp as the parent. We can change this back to using project.version but we need to make sure that nightly-build always deploys successfully or I wonder if there is another workaround for this? https://issues.apache.org/activemq/browse/AMQ-956 Regards, Fritz - Original Message - From: Hiram Chirino [EMAIL PROTECTED] To: activemq-dev@geronimo.apache.org Sent: Tuesday, November 14, 2006 8:48 PM Subject: ActiveMQ POM Howdy, I was wondering if anybody knows why we are using ${activemq-version} instead of ${project.version} in our ActiveMQ poms?? When doing a release build, it's easy to forget that you need to updated the version in to places. Can't we just use the ${project.version} variable?? -- Regards, Hiram Blog: http://hiramchirino.com -- Cheers, Guillaume Nodet -- Regards, Hiram Blog: http://hiramchirino.com -- Cheers, Guillaume Nodet -- Regards, Hiram Blog: http://hiramchirino.com
Re: ActiveMQ POM
Hi, I think the downside here is that it will loose reference to previous builds. Since development will not change to timestamp, then deploy will just overwrite the existing artifacts. Regards, Fritz - Original Message - From: Hiram Chirino [EMAIL PROTECTED] To: activemq-dev@geronimo.apache.org Sent: Wednesday, November 15, 2006 12:52 AM Subject: Re: ActiveMQ POM Thanks Fritz! I knew there had to be a reason that I was just not aware of. What do you think would be the downsides of not using the special SNAPSHOT handling that maven provides? What if we tagged our SNAPSHOT builds with something like like DEVELOPMENT instead of SNAPSHOT. I'm guessing that problem would go away, but what other ones would we get? On 11/14/06, Guillaume Nodet [EMAIL PROTECTED] wrote: This is also my experience. If we just use the real version 4.2-SNAPSHOT for example, it should also work and maven should be able to change (*nearly*) all these occurrences when using the release plugin. I say nearly, because in ServiceMix, there are some edge cases where this fail (when including the version in files other than pom.xml like artifacts resources for example). On 11/14/06, Fritz Oconer [EMAIL PROTECTED] wrote: Hi, I added ${activemq-version} instead of ${project.version} basically as a workaround for build failures due to differences in timestamp. If we use ${project.version} then it will require all activemq type artifacts (specified as dependency in the parent pom.xml) to have the same timestamp as the parent. This becomes an issue when nightly-build deploy fails after some of the modules have been deployed causing some activemq modules to have different timestamp as the parent. We can change this back to using project.version but we need to make sure that nightly-build always deploys successfully or I wonder if there is another workaround for this? https://issues.apache.org/activemq/browse/AMQ-956 Regards, Fritz - Original Message - From: Hiram Chirino [EMAIL PROTECTED] To: activemq-dev@geronimo.apache.org Sent: Tuesday, November 14, 2006 8:48 PM Subject: ActiveMQ POM Howdy, I was wondering if anybody knows why we are using ${activemq-version} instead of ${project.version} in our ActiveMQ poms?? When doing a release build, it's easy to forget that you need to updated the version in to places. Can't we just use the ${project.version} variable?? -- Regards, Hiram Blog: http://hiramchirino.com -- Cheers, Guillaume Nodet -- Regards, Hiram Blog: http://hiramchirino.com