Re: custom unique version
For those who wants another use case for custom unique version is:
At our legacy application based on JPA has persistence.xml. Our domain jars
were divided into the two module and they are included at our
persistence.xml at like this:
persistence-unit name=SearchV2PU
jta-data-sourceSearchV2DS/jta-data-source
jar-filedomain-A-${A-version}.jar/jar-file
jar-filedomain-B-${B-version}.jar/jar-file
/persistence-unit
Our persistence.xml file is filtered at build time by maven. However because
of the unique version of each SNAPSHOT, it can not be filtered correctly.
Our persistence provider Eclipse can not locate domain-A-***.jar since the
name of it changing daily.
Please do not suggest me to use release version of domain A dependency. This
domain dependency is changing very rapidly and its daily usage is very
critical.
I strongly need custom unique version of the snapshot and filter my
persistense.xml.
Still looking for a solution.
Thanks
--
View this message in context:
http://maven.40175.n5.nabble.com/custom-unique-version-tp5159884p5281260.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: custom unique version
Am 24.01.2012 10:58, schrieb Cem Koc:
For those who wants another use case for custom unique version is:
At our legacy application based on JPA has persistence.xml. Our domain jars
were divided into the two module and they are included at our
persistence.xml at like this:
persistence-unit name=SearchV2PU
jta-data-sourceSearchV2DS/jta-data-source
jar-filedomain-A-${A-version}.jar/jar-file
jar-filedomain-B-${B-version}.jar/jar-file
/persistence-unit
Our persistence.xml file is filtered at build time by maven. However because
of the unique version of each SNAPSHOT, it can not be filtered correctly.
Our persistence provider Eclipse can not locate domain-A-***.jar since the
name of it changing daily.
Please do not suggest me to use release version of domain A dependency. This
domain dependency is changing very rapidly and its daily usage is very
critical.
I strongly need custom unique version of the snapshot and filter my
persistense.xml.
Still looking for a solution.
You could roughly follow these steps:
- make your persistence.xml a non-filtered resource, put in fixed JAR
file names.
- define the JAR files in your POM as SNAPSHOT dependency and configure
your settings.xml accordingly, so that they get updated in the interval
you want (or use -U on the mvn command line to force updates)
- use maven-dependency-plugin to download domain-A.jar and domain-B.jar.
Tell this plugin to strip version numbers (you'll then get the JAR file
names with versions stripped out).
- make sure the dependency plugin copies them into the directory where
your application would expect them
Snapshots are meant to change. Leave the details how snapshots are
managed to maven. Just tell it to use the snapshot. Don't mess with
internal unique versions.
Best regards
Ansgar
Thanks
--
View this message in context:
http://maven.40175.n5.nabble.com/custom-unique-version-tp5159884p5281260.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
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
Re: custom unique version
Am 23.01.2012 08:36 schrieb Thomas Scheffler thomas.scheff...@uni-jena.de : Am 20.01.2012 16:27, schrieb Ron Wheeler: Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Hi Ron, did you faced that problem already? What is your solution or what would be a general solution of keeping track unique version numbers? Through Hudson I run tests in a core library, the SNAPSHOT library, that got releases from time to time. Between those releases a SNAPSHOT is deployed to a snapshot repository from where another Hudson project gets this library and run integration test. Snapshots change over time. If you want to depend on your library and have reliable dependency tracking, why not just *release* the library? Regards, Ansgar Some more projects rely on this core library and it would be a good deal to get the unique version number right from the library. For now we embed the revision number from scm into the library. So you can look in hudson when this revision was tested and look in the console log the unique version number. These are a lot of manual task to to. I want this to be determined in a easier way. So if you could be please so kind to point me to what you say is the best practice here... regards Thomas On 20/01/2012 10:14 AM, Stephen Connolly wrote: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique version number into the JAR manifest? OK, let me put this in another form, so you might understand what I was asking you. I know how to put custom keys and values into a manifest. That's the yeah I know that above. The question should have been understand like this: How can I acquire the unique version number that makes of 1.0-SNAPSHOT locally 1.0-20120120.121003-6 remotely, so that I can put it into the JAR manifest of the JAR file that is deployed in a remote repository? That string is decided when deploy:deploy is invoked, so you cannot put that string in. Or in other words: The substring 20120120.121003-6 is changing at every deployment. I want that part in the manifest. Thomas http://bit.ly/zijlWA See the example on that screen... See how properties are substituted in? Then you need to go to http://to.justpitch.me/yiTp6D -Stephen Thomas Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.de thomas.scheff...@uni-jena.de : Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: custom unique version
Am 23.01.2012 09:34, schrieb Ansgar Konermann: Am 23.01.2012 08:36 schrieb Thomas Schefflerthomas.scheff...@uni-jena.de : Am 20.01.2012 16:27, schrieb Ron Wheeler: Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Hi Ron, did you faced that problem already? What is your solution or what would be a general solution of keeping track unique version numbers? Through Hudson I run tests in a core library, the SNAPSHOT library, that got releases from time to time. Between those releases a SNAPSHOT is deployed to a snapshot repository from where another Hudson project gets this library and run integration test. Snapshots change over time. If you want to depend on your library and have reliable dependency tracking, why not just *release* the library? Hi, I thought of that but that would mean several minor releases every day and changing application pom very often. I think that is the reason why maven as SNAPSHOT versions. But sadly there is no easy way to track them. So for some reason there are unique versioned SNAPSHOTS - that's the default case by the way - but when requesting a SNAPSHOT version you can not get it's unique version of it. The best way so far is to use the versions plugin prior testing: With versions:lock-snapshots you can modify the current pom and get the unique versions written inside the pom. After tests successfully finish you can grab the information from the pom.xml or you run versions:unlock-snapshots to put back SNAPSHOT to the versions. That is so far the best solution I got. It would be better to get this information after tests. So anymore ideas? Thomas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: custom unique version
You could reach out to the Hudson user community. I do not use Hudson although many people here do use Maven and Hudson together. We have a large project with over 90 maven projects of which 70 produce artifacts based on our code. We have a small team but have some rules about releases and SNAPSHOTS. We use Releases in a conventional way. SNAPSHOTs get deployed to Nexus with a spec and a warranty from the person doing the deploy. The spec may be verbal or in an e-mail I have deployed a new SNAPSHOT of Web Service x that has dummy database access and always returns 7 when you ask for a record count and returns testrecorda regardless of the search critera on a lookup. I have tested this and it works If you are a consumer of x, you have to decide if you want to keep using the older SNAPSHOT (only had the record count function, for example) or fix your code to take advantage of the increased/changed functionality(lookup stub partially working) included in the new version. This is a lot different from the workflow when using Hudson. I don't really understand the Hudson philosophy and how you avoid the human communication and management required to manage a multi-person project that uses stubs and partially functional modules in the process of developnment. Ron On 23/01/2012 2:36 AM, Thomas Scheffler wrote: Am 20.01.2012 16:27, schrieb Ron Wheeler: Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Hi Ron, did you faced that problem already? What is your solution or what would be a general solution of keeping track unique version numbers? Through Hudson I run tests in a core library, the SNAPSHOT library, that got releases from time to time. Between those releases a SNAPSHOT is deployed to a snapshot repository from where another Hudson project gets this library and run integration test. Some more projects rely on this core library and it would be a good deal to get the unique version number right from the library. For now we embed the revision number from scm into the library. So you can look in hudson when this revision was tested and look in the console log the unique version number. These are a lot of manual task to to. I want this to be determined in a easier way. So if you could be please so kind to point me to what you say is the best practice here... regards Thomas On 20/01/2012 10:14 AM, Stephen Connolly wrote: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique version number into the JAR manifest? OK, let me put this in another form, so you might understand what I was asking you. I know how to put custom keys and values into a manifest. That's the yeah I know that above. The question should have been understand like this: How can I acquire the unique version number that makes of 1.0-SNAPSHOT locally 1.0-20120120.121003-6 remotely, so that I can put it into the JAR manifest of the JAR file that is deployed in a remote repository? That string is decided when deploy:deploy is invoked, so you cannot put that string in. Or in other words: The substring 20120120.121003-6 is changing at every deployment. I want that part in the manifest. Thomas http://bit.ly/zijlWA See the example on that screen... See how properties are substituted in? Then you need to go to http://to.justpitch.me/yiTp6D -Stephen Thomas Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail:
Re: custom unique version
On 23 January 2012 13:25, Ron Wheeler rwhee...@artifact-software.comwrote: You could reach out to the Hudson user community. I do not use Hudson although many people here do use Maven and Hudson together. Most use Jenkins rather than that scurrilous fork Hudson ;-) We have a large project with over 90 maven projects of which 70 produce artifacts based on our code. We have a small team but have some rules about releases and SNAPSHOTS. We use Releases in a conventional way. SNAPSHOTs get deployed to Nexus with a spec and a warranty from the person doing the deploy. The spec may be verbal or in an e-mail I have deployed a new SNAPSHOT of Web Service x that has dummy database access and always returns 7 when you ask for a record count and returns testrecorda regardless of the search critera on a lookup. I have tested this and it works If you are a consumer of x, you have to decide if you want to keep using the older SNAPSHOT (only had the record count function, for example) or fix your code to take advantage of the increased/changed functionality(lookup stub partially working) included in the new version. This is a lot different from the workflow when using Hudson. I don't really understand the Hudson philosophy and how you avoid the human communication and management required to manage a multi-person project that uses stubs and partially functional modules in the process of developnment. I don't really understand why people are so afraid of making releases. Personally, I _never_ deploy -SNAPSHOTs to remote repos, and I try to never consume them also. Ron On 23/01/2012 2:36 AM, Thomas Scheffler wrote: Am 20.01.2012 16:27, schrieb Ron Wheeler: Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Hi Ron, did you faced that problem already? What is your solution or what would be a general solution of keeping track unique version numbers? Through Hudson I run tests in a core library, the SNAPSHOT library, that got releases from time to time. Between those releases a SNAPSHOT is deployed to a snapshot repository from where another Hudson project gets this library and run integration test. Some more projects rely on this core library and it would be a good deal to get the unique version number right from the library. For now we embed the revision number from scm into the library. So you can look in hudson when this revision was tested and look in the console log the unique version number. These are a lot of manual task to to. I want this to be determined in a easier way. So if you could be please so kind to point me to what you say is the best practice here... regards Thomas On 20/01/2012 10:14 AM, Stephen Connolly wrote: 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique version number into the JAR manifest? OK, let me put this in another form, so you might understand what I was asking you. I know how to put custom keys and values into a manifest. That's the yeah I know that above. The question should have been understand like this: How can I acquire the unique version number that makes of 1.0-SNAPSHOT locally 1.0-20120120.121003-6 remotely, so that I can put it into the JAR manifest of the JAR file that is deployed in a remote repository? That string is decided when deploy:deploy is invoked, so you cannot put that string in. Or in other words: The substring 20120120.121003-6 is changing at every deployment. I want that part in the manifest. Thomas http://bit.ly/zijlWA See the example on that screen... See how properties are substituted in? Then you need to go to http://to.justpitch.me/yiTp6D -Stephen Thomas Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**u**ni-jena.de http://uni-jena.de thomas.scheffler@**uni-jena.de
Re: custom unique version
We use SNAPSHOTs extensively and deploy them when they are ready to be used by a consuming project. For example, we often have one person working on the database and the DAOs, another person working on the Web services and a third person working on the GUI components. The GUI person often needs a stub of the web service very early in the process so that they can produce mockups and get started producing real code. The person doing the web service may want parts of the DAO stubbed in order to work on the web service logic. They might also request new queries or other functional changes to the DAO as the Web Service gets implemented which will cause a new SNAPSHOT of the DAO to be required. Over a week, the team might deploy several versions of the SNAPSHOTs with increasing functionality. The person doing the consuming has to be aware of new deployments so that their tests make sense. If the web service was stubbed and returned 7 for the record count, the person writing the GUI will be surprised when it starts to show 3 (from the actual database) unless they have been informed in advance by the person deploying the revised Web Service. They may in fact ask to have the Web Service deployment delayed until the GUI can be fixed to handle the revised specification or they get through a customer presentation. Ron On 23/01/2012 9:32 AM, Stephen Connolly wrote: On 23 January 2012 13:25, Ron Wheeler rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com wrote: You could reach out to the Hudson user community. I do not use Hudson although many people here do use Maven and Hudson together. Most use Jenkins rather than that scurrilous fork Hudson ;-) We have a large project with over 90 maven projects of which 70 produce artifacts based on our code. We have a small team but have some rules about releases and SNAPSHOTS. We use Releases in a conventional way. SNAPSHOTs get deployed to Nexus with a spec and a warranty from the person doing the deploy. The spec may be verbal or in an e-mail I have deployed a new SNAPSHOT of Web Service x that has dummy database access and always returns 7 when you ask for a record count and returns testrecorda regardless of the search critera on a lookup. I have tested this and it works If you are a consumer of x, you have to decide if you want to keep using the older SNAPSHOT (only had the record count function, for example) or fix your code to take advantage of the increased/changed functionality(lookup stub partially working) included in the new version. This is a lot different from the workflow when using Hudson. I don't really understand the Hudson philosophy and how you avoid the human communication and management required to manage a multi-person project that uses stubs and partially functional modules in the process of developnment. I don't really understand why people are so afraid of making releases. Personally, I _never_ deploy -SNAPSHOTs to remote repos, and I try to never consume them also. Ron On 23/01/2012 2:36 AM, Thomas Scheffler wrote: Am 20.01.2012 16:27, schrieb Ron Wheeler: Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Hi Ron, did you faced that problem already? What is your solution or what would be a general solution of keeping track unique version numbers? Through Hudson I run tests in a core library, the SNAPSHOT library, that got releases from time to time. Between those releases a SNAPSHOT is deployed to a snapshot repository from where another Hudson project gets this library and run integration test. Some more projects rely on this core library and it would be a good deal to get the unique version number right from the library. For now we embed the revision number from scm into the library. So you can look in hudson when this revision was tested and look in the console log the unique version number. These are a lot of manual task to to. I want this to be determined in a easier way. So if you could be please so kind to point me to what you say is the best practice here... regards Thomas On 20/01/2012 10:14 AM, Stephen Connolly wrote: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de mailto:thomas.scheff...@uni-jena.de: Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas
Re: custom unique version
See when Maven is the build tool, I usually find it easier to just checkout my -SNAPSHOT deps locally and build them. That way I have complete control over when they get updated. On 23 January 2012 15:17, Ron Wheeler rwhee...@artifact-software.comwrote: We use SNAPSHOTs extensively and deploy them when they are ready to be used by a consuming project. For example, we often have one person working on the database and the DAOs, another person working on the Web services and a third person working on the GUI components. The GUI person often needs a stub of the web service very early in the process so that they can produce mockups and get started producing real code. The person doing the web service may want parts of the DAO stubbed in order to work on the web service logic. They might also request new queries or other functional changes to the DAO as the Web Service gets implemented which will cause a new SNAPSHOT of the DAO to be required. Over a week, the team might deploy several versions of the SNAPSHOTs with increasing functionality. The person doing the consuming has to be aware of new deployments so that their tests make sense. If the web service was stubbed and returned 7 for the record count, the person writing the GUI will be surprised when it starts to show 3 (from the actual database) unless they have been informed in advance by the person deploying the revised Web Service. They may in fact ask to have the Web Service deployment delayed until the GUI can be fixed to handle the revised specification or they get through a customer presentation. Ron On 23/01/2012 9:32 AM, Stephen Connolly wrote: On 23 January 2012 13:25, Ron Wheeler rwhee...@artifact-software.comwrote: You could reach out to the Hudson user community. I do not use Hudson although many people here do use Maven and Hudson together. Most use Jenkins rather than that scurrilous fork Hudson ;-) We have a large project with over 90 maven projects of which 70 produce artifacts based on our code. We have a small team but have some rules about releases and SNAPSHOTS. We use Releases in a conventional way. SNAPSHOTs get deployed to Nexus with a spec and a warranty from the person doing the deploy. The spec may be verbal or in an e-mail I have deployed a new SNAPSHOT of Web Service x that has dummy database access and always returns 7 when you ask for a record count and returns testrecorda regardless of the search critera on a lookup. I have tested this and it works If you are a consumer of x, you have to decide if you want to keep using the older SNAPSHOT (only had the record count function, for example) or fix your code to take advantage of the increased/changed functionality(lookup stub partially working) included in the new version. This is a lot different from the workflow when using Hudson. I don't really understand the Hudson philosophy and how you avoid the human communication and management required to manage a multi-person project that uses stubs and partially functional modules in the process of developnment. I don't really understand why people are so afraid of making releases. Personally, I _never_ deploy -SNAPSHOTs to remote repos, and I try to never consume them also. Ron On 23/01/2012 2:36 AM, Thomas Scheffler wrote: Am 20.01.2012 16:27, schrieb Ron Wheeler: Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Hi Ron, did you faced that problem already? What is your solution or what would be a general solution of keeping track unique version numbers? Through Hudson I run tests in a core library, the SNAPSHOT library, that got releases from time to time. Between those releases a SNAPSHOT is deployed to a snapshot repository from where another Hudson project gets this library and run integration test. Some more projects rely on this core library and it would be a good deal to get the unique version number right from the library. For now we embed the revision number from scm into the library. So you can look in hudson when this revision was tested and look in the console log the unique version number. These are a lot of manual task to to. I want this to be determined in a easier way. So if you could be please so kind to point me to what you say is the best practice here... regards Thomas On 20/01/2012 10:14 AM, Stephen Connolly wrote: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique
Re: custom unique version
On 23/01/2012 10:30 AM, Stephen Connolly wrote: See when Maven is the build tool, I usually find it easier to just checkout my -SNAPSHOT deps locally and build them. That way I have complete control over when they get updated. Some times the guys do that as well. Ron On 23 January 2012 15:17, Ron Wheeler rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com wrote: We use SNAPSHOTs extensively and deploy them when they are ready to be used by a consuming project. For example, we often have one person working on the database and the DAOs, another person working on the Web services and a third person working on the GUI components. The GUI person often needs a stub of the web service very early in the process so that they can produce mockups and get started producing real code. The person doing the web service may want parts of the DAO stubbed in order to work on the web service logic. They might also request new queries or other functional changes to the DAO as the Web Service gets implemented which will cause a new SNAPSHOT of the DAO to be required. Over a week, the team might deploy several versions of the SNAPSHOTs with increasing functionality. The person doing the consuming has to be aware of new deployments so that their tests make sense. If the web service was stubbed and returned 7 for the record count, the person writing the GUI will be surprised when it starts to show 3 (from the actual database) unless they have been informed in advance by the person deploying the revised Web Service. They may in fact ask to have the Web Service deployment delayed until the GUI can be fixed to handle the revised specification or they get through a customer presentation. Ron On 23/01/2012 9:32 AM, Stephen Connolly wrote: On 23 January 2012 13:25, Ron Wheeler rwhee...@artifact-software.com mailto:rwhee...@artifact-software.com wrote: You could reach out to the Hudson user community. I do not use Hudson although many people here do use Maven and Hudson together. Most use Jenkins rather than that scurrilous fork Hudson ;-) We have a large project with over 90 maven projects of which 70 produce artifacts based on our code. We have a small team but have some rules about releases and SNAPSHOTS. We use Releases in a conventional way. SNAPSHOTs get deployed to Nexus with a spec and a warranty from the person doing the deploy. The spec may be verbal or in an e-mail I have deployed a new SNAPSHOT of Web Service x that has dummy database access and always returns 7 when you ask for a record count and returns testrecorda regardless of the search critera on a lookup. I have tested this and it works If you are a consumer of x, you have to decide if you want to keep using the older SNAPSHOT (only had the record count function, for example) or fix your code to take advantage of the increased/changed functionality(lookup stub partially working) included in the new version. This is a lot different from the workflow when using Hudson. I don't really understand the Hudson philosophy and how you avoid the human communication and management required to manage a multi-person project that uses stubs and partially functional modules in the process of developnment. I don't really understand why people are so afraid of making releases. Personally, I _never_ deploy -SNAPSHOTs to remote repos, and I try to never consume them also. Ron On 23/01/2012 2:36 AM, Thomas Scheffler wrote: Am 20.01.2012 16:27, schrieb Ron Wheeler: Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Hi Ron, did you faced that problem already? What is your solution or what would be a general solution of keeping track unique version numbers? Through Hudson I run tests in a core library, the SNAPSHOT library, that got releases from time to time. Between those releases a SNAPSHOT is deployed to a snapshot repository from where another Hudson project gets this library and run integration test. Some more projects rely on this core library and it would be a good deal to get the unique version number right from the library. For now we embed the revision number from scm into the library. So you can look in hudson
Re: custom unique version
Deploying SNAPSHOTS can work when there is a clear, one-directional, flow, from producers to consumers. It produces nothing but horror otherwise, when developers find Maven downloading a 'new' snapshot that is actually 'old' with respect to their pending changes. On Mon, Jan 23, 2012 at 1:06 PM, Ron Wheeler rwhee...@artifact-software.com wrote: On 23/01/2012 10:30 AM, Stephen Connolly wrote: See when Maven is the build tool, I usually find it easier to just checkout my -SNAPSHOT deps locally and build them. That way I have complete control over when they get updated. Some times the guys do that as well. Ron On 23 January 2012 15:17, Ron Wheeler rwhee...@artifact-software.com wrote: We use SNAPSHOTs extensively and deploy them when they are ready to be used by a consuming project. For example, we often have one person working on the database and the DAOs, another person working on the Web services and a third person working on the GUI components. The GUI person often needs a stub of the web service very early in the process so that they can produce mockups and get started producing real code. The person doing the web service may want parts of the DAO stubbed in order to work on the web service logic. They might also request new queries or other functional changes to the DAO as the Web Service gets implemented which will cause a new SNAPSHOT of the DAO to be required. Over a week, the team might deploy several versions of the SNAPSHOTs with increasing functionality. The person doing the consuming has to be aware of new deployments so that their tests make sense. If the web service was stubbed and returned 7 for the record count, the person writing the GUI will be surprised when it starts to show 3 (from the actual database) unless they have been informed in advance by the person deploying the revised Web Service. They may in fact ask to have the Web Service deployment delayed until the GUI can be fixed to handle the revised specification or they get through a customer presentation. Ron On 23/01/2012 9:32 AM, Stephen Connolly wrote: On 23 January 2012 13:25, Ron Wheeler rwhee...@artifact-software.com wrote: You could reach out to the Hudson user community. I do not use Hudson although many people here do use Maven and Hudson together. Most use Jenkins rather than that scurrilous fork Hudson ;-) We have a large project with over 90 maven projects of which 70 produce artifacts based on our code. We have a small team but have some rules about releases and SNAPSHOTS. We use Releases in a conventional way. SNAPSHOTs get deployed to Nexus with a spec and a warranty from the person doing the deploy. The spec may be verbal or in an e-mail I have deployed a new SNAPSHOT of Web Service x that has dummy database access and always returns 7 when you ask for a record count and returns testrecorda regardless of the search critera on a lookup. I have tested this and it works If you are a consumer of x, you have to decide if you want to keep using the older SNAPSHOT (only had the record count function, for example) or fix your code to take advantage of the increased/changed functionality(lookup stub partially working) included in the new version. This is a lot different from the workflow when using Hudson. I don't really understand the Hudson philosophy and how you avoid the human communication and management required to manage a multi-person project that uses stubs and partially functional modules in the process of developnment. I don't really understand why people are so afraid of making releases. Personally, I _never_ deploy -SNAPSHOTs to remote repos, and I try to never consume them also. Ron On 23/01/2012 2:36 AM, Thomas Scheffler wrote: Am 20.01.2012 16:27, schrieb Ron Wheeler: Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Hi Ron, did you faced that problem already? What is your solution or what would be a general solution of keeping track unique version numbers? Through Hudson I run tests in a core library, the SNAPSHOT library, that got releases from time to time. Between those releases a SNAPSHOT is deployed to a snapshot repository from where another Hudson project gets this library and run integration test. Some more projects rely on this core library and it would be a good deal to get the unique version number right from the library. For now we embed the revision number from scm into the library. So you can look in hudson when this revision was tested and look in the console log the unique version number. These are a lot of manual task to to. I want this to be determined in a easier way. So if you could be please so kind to point me to what you say is the best practice here... regards
Re: custom unique version
Am 21.01.2012 16:49, schrieb Vincent Latombe: http://mojo.codehaus.org/buildnumber-maven-plugin/ could be your solution Vincent Hi Vincent, thank you for your suggestion but sadly the buildnumber from buildnumber-maven-plugin is completely unrelated to the unique version number that is generated in the deploy step. Thomas 2012/1/20 Ron Wheelerrwhee...@artifact-software.com Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Ron On 20/01/2012 10:14 AM, Stephen Connolly wrote: 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique version number into the JAR manifest? OK, let me put this in another form, so you might understand what I was asking you. I know how to put custom keys and values into a manifest. That's the yeah I know that above. The question should have been understand like this: How can I acquire the unique version number that makes of 1.0-SNAPSHOT locally 1.0-20120120.121003-6 remotely, so that I can put it into the JAR manifest of the JAR file that is deployed in a remote repository? That string is decided when deploy:deploy is invoked, so you cannot put that string in. Or in other words: The substring 20120120.121003-6 is changing at every deployment. I want that part in the manifest. Thomas http://bit.ly/zijlWA See the example on that screen... See how properties are substituted in? Then you need to go to http://to.justpitch.me/yiTp6D -Stephen Thomas Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**u**ni-jena.dehttp://uni-jena.de thomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas --**--** - To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --**--** - To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-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: custom unique version
Am 20.01.2012 16:27, schrieb Ron Wheeler: Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Hi Ron, did you faced that problem already? What is your solution or what would be a general solution of keeping track unique version numbers? Through Hudson I run tests in a core library, the SNAPSHOT library, that got releases from time to time. Between those releases a SNAPSHOT is deployed to a snapshot repository from where another Hudson project gets this library and run integration test. Some more projects rely on this core library and it would be a good deal to get the unique version number right from the library. For now we embed the revision number from scm into the library. So you can look in hudson when this revision was tested and look in the console log the unique version number. These are a lot of manual task to to. I want this to be determined in a easier way. So if you could be please so kind to point me to what you say is the best practice here... regards Thomas On 20/01/2012 10:14 AM, Stephen Connolly wrote: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique version number into the JAR manifest? OK, let me put this in another form, so you might understand what I was asking you. I know how to put custom keys and values into a manifest. That's the yeah I know that above. The question should have been understand like this: How can I acquire the unique version number that makes of 1.0-SNAPSHOT locally 1.0-20120120.121003-6 remotely, so that I can put it into the JAR manifest of the JAR file that is deployed in a remote repository? That string is decided when deploy:deploy is invoked, so you cannot put that string in. Or in other words: The substring 20120120.121003-6 is changing at every deployment. I want that part in the manifest. Thomas http://bit.ly/zijlWA See the example on that screen... See how properties are substituted in? Then you need to go to http://to.justpitch.me/yiTp6D -Stephen Thomas Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: custom unique version
http://mojo.codehaus.org/buildnumber-maven-plugin/ could be your solution Vincent 2012/1/20 Ron Wheeler rwhee...@artifact-software.com Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Ron On 20/01/2012 10:14 AM, Stephen Connolly wrote: 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique version number into the JAR manifest? OK, let me put this in another form, so you might understand what I was asking you. I know how to put custom keys and values into a manifest. That's the yeah I know that above. The question should have been understand like this: How can I acquire the unique version number that makes of 1.0-SNAPSHOT locally 1.0-20120120.121003-6 remotely, so that I can put it into the JAR manifest of the JAR file that is deployed in a remote repository? That string is decided when deploy:deploy is invoked, so you cannot put that string in. Or in other words: The substring 20120120.121003-6 is changing at every deployment. I want that part in the manifest. Thomas http://bit.ly/zijlWA See the example on that screen... See how properties are substituted in? Then you need to go to http://to.justpitch.me/yiTp6D -Stephen Thomas Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**u**ni-jena.de http://uni-jena.de thomas.scheffler@**uni-jena.de thomas.scheff...@uni-jena.de : Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas --**--** - To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org --**--** - To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-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: custom unique version
It cannot. That is part of the spec for the layout of a Maven repository. -Stephen 2012/1/20 Thomas Scheffler thomas.scheff...@uni-jena.de: Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas - 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: custom unique version
Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: custom unique version
You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization - Stephen --- Sent from my Android phone, so random spelling mistakes, random nonsense words and other nonsense are a direct result of using swype to type on the screen On Jan 20, 2012 10:45 a.m., Thomas Scheffler thomas.scheff...@uni-jena.de wrote: Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas --**--**- To unsubscribe, e-mail: users-unsubscribe@maven.**apache.orgusers-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: custom unique version
Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique version number into the JAR manifest? Thomas Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: custom unique version
Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique version number into the JAR manifest? OK, let me put this in another form, so you might understand what I was asking you. I know how to put custom keys and values into a manifest. That's the yeah I know that above. The question should have been understand like this: How can I acquire the unique version number that makes of 1.0-SNAPSHOT locally 1.0-20120120.121003-6 remotely, so that I can put it into the JAR manifest of the JAR file that is deployed in a remote repository? Or in other words: The substring 20120120.121003-6 is changing at every deployment. I want that part in the manifest. Thomas http://bit.ly/zijlWA See the example on that screen... See how properties are substituted in? Then you need to go to http://to.justpitch.me/yiTp6D -Stephen Thomas Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: custom unique version
2012/1/20 Thomas Scheffler thomas.scheff...@uni-jena.de: Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique version number into the JAR manifest? OK, let me put this in another form, so you might understand what I was asking you. I know how to put custom keys and values into a manifest. That's the yeah I know that above. The question should have been understand like this: How can I acquire the unique version number that makes of 1.0-SNAPSHOT locally 1.0-20120120.121003-6 remotely, so that I can put it into the JAR manifest of the JAR file that is deployed in a remote repository? That string is decided when deploy:deploy is invoked, so you cannot put that string in. Or in other words: The substring 20120120.121003-6 is changing at every deployment. I want that part in the manifest. Thomas http://bit.ly/zijlWA See the example on that screen... See how properties are substituted in? Then you need to go to http://to.justpitch.me/yiTp6D -Stephen Thomas Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas - 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: custom unique version
Of all of the developers that have built thousands of applications using Maven, you are the only one who wants to do this. Does that not raise any red flags? There must be a best practice for what you are trying to achieve. This is clearly not it. Ron On 20/01/2012 10:14 AM, Stephen Connolly wrote: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Schefflerthomas.scheff...@uni-jena.de: Am 20.01.2012 12:40, schrieb Stephen Connolly: You can stuff what ever you want in tge manifest. Google is your friend: maven jar plugin manifest customization Hi, yeah I know that. But how can I put the unique version number into the JAR manifest? OK, let me put this in another form, so you might understand what I was asking you. I know how to put custom keys and values into a manifest. That's the yeah I know that above. The question should have been understand like this: How can I acquire the unique version number that makes of 1.0-SNAPSHOT locally 1.0-20120120.121003-6 remotely, so that I can put it into the JAR manifest of the JAR file that is deployed in a remote repository? That string is decided when deploy:deploy is invoked, so you cannot put that string in. Or in other words: The substring 20120120.121003-6 is changing at every deployment. I want that part in the manifest. Thomas http://bit.ly/zijlWA See the example on that screen... See how properties are substituted in? Then you need to go to http://to.justpitch.me/yiTp6D -Stephen Thomas Am 20.01.2012 10:32, schrieb Stephen Connolly: It cannot. That is part of the spec for the layout of a Maven repository. Is there a way to embed the unique version string into the JAR manifest then? If I test an application with a snapshot jar I want stick with that specific version when deploying the application later. This should be done automatically. 1. Do some automatic test, if they succeed gather the unique version number. 2. At deploy time use the last successful timestamp. Maybe someone could help me with that... :-) regards Thomas -Stephen 2012/1/20 Thomas Schefflerthomas.scheffler@**uni-jena.dethomas.scheff...@uni-jena.de : Hi, I want to create a unique SNAPSHOT version that does not consist of timestamp and buildnumber but is created by a defined property. I read the docs and googled for a solution but found no way to alter the unique version string. How can this be achieved? regards Thomas - 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 -- 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
