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<thomas.scheffler@**uni-jena.de<[email protected]>
>>>> >:
>>>>
>>>>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>>>>
>>>>>  2012/1/20 Thomas 
>>>>> Scheffler<thomas.scheffler@**uni-jena.de<[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@**u**ni-jena.de <http://uni-jena.de><
>>>>>>>>>> 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: 
>> users-unsubscribe@maven.**apache.org<[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]
>

Reply via email to