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 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 Scheffler<thomas.scheff...@uni-jena.de <mailto:thomas.scheff...@uni-jena.de>>: Am 20.01.2012 15:30, schrieb Stephen Connolly: 2012/1/20 Thomas Scheffler<thomas.scheff...@uni-jena.de <mailto:thomas.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 Scheffler<thomas.scheffler@**uni-jena.de <http://uni-jena.de><thomas.scheff...@uni-jena.de <mailto: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 <mailto:users-unsubscr...@maven.apache.org> For additional commands, e-mail: users-h...@maven.apache.org <mailto:users-h...@maven.apache.org>-- Ron WheelerPresident Artifact Software Inc email: rwhee...@artifact-software.com <mailto:rwhee...@artifact-software.com> skype: ronaldmwheeler phone: 866-970-2435, ext 102 --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@maven.apache.org <mailto:users-unsubscr...@maven.apache.org> For additional commands, e-mail: users-h...@maven.apache.org <mailto:users-h...@maven.apache.org>-- Ron WheelerPresident Artifact Software Inc email:rwhee...@artifact-software.com <mailto:rwhee...@artifact-software.com> skype: ronaldmwheeler phone: 866-970-2435, ext 102
-- 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
