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 <[email protected]>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 <[email protected]>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<[email protected]>: >>>>> >>>>>> Am 20.01.2012 15:30, schrieb Stephen Connolly: >>>>>> >>>>>> 2012/1/20 Thomas Scheffler<[email protected]>: >>>>>>> >>>>>>>> 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< >>>>>>>>>>> [email protected]> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> : >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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: [email protected] >>> For additional commands, e-mail: [email protected] >>> >>> >>> >> >> -- >> Ron Wheeler >> President >> Artifact Software Inc >> email: [email protected] >> skype: ronaldmwheeler >> phone: 866-970-2435, ext 102 >> >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > > > -- > Ron Wheeler > President > Artifact Software Inc > email: [email protected] > skype: ronaldmwheeler > phone: 866-970-2435, ext 102 > >
