maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: custom unique version
Date Mon, 23 Jan 2012 15:30:21 GMT
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 <rwheeler@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 <rwheeler@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.scheffler@uni-jena.de>:
>>>>>
>>>>>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>>>>>
>>>>>>  2012/1/20 Thomas Scheffler<thomas.scheffler@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<
>>>>>>>>>>> thomas.scheffler@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.org
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>>
>>>
>>
>>   --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> For additional commands, e-mail: users-help@maven.apache.org
>>
>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message