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 <[email protected]> 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 <[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 > > > > > -- > 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
