You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Thomas Scheffler <th...@uni-jena.de> on 2012/01/20 10:29:35 UTC
custom unique version
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
Re: custom unique version
Posted by Ansgar Konermann <an...@googlemail.com>.
Am 24.01.2012 10:58, schrieb Cem Koc:
> For those who wants another use case for custom unique version is:
>
> At our legacy application based on JPA has persistence.xml. Our domain jars
> were divided into the two module and they are included at our
> persistence.xml at like this:
>
> <persistence-unit name="SearchV2PU">
> <jta-data-source>SearchV2DS</jta-data-source>
> <jar-file>domain-A-${A-version}.jar</jar-file>
> <jar-file>domain-B-${B-version}.jar</jar-file>
> </persistence-unit>
>
> Our persistence.xml file is filtered at build time by maven. However because
> of the unique version of each SNAPSHOT, it can not be filtered correctly.
>
> Our persistence provider Eclipse can not locate domain-A-***.jar since the
> name of it changing daily.
>
> Please do not suggest me to use release version of domain A dependency. This
> domain dependency is changing very rapidly and its daily usage is very
> critical.
>
> I strongly need "custom unique version" of the snapshot and filter my
> persistense.xml.
>
> Still looking for a solution.
You could roughly follow these steps:
- make your persistence.xml a non-filtered resource, put in fixed JAR
file names.
- define the JAR files in your POM as SNAPSHOT dependency and configure
your settings.xml accordingly, so that they get updated in the interval
you want (or use -U on the mvn command line to force updates)
- use maven-dependency-plugin to download domain-A.jar and domain-B.jar.
Tell this plugin to strip version numbers (you'll then get the JAR file
names with versions stripped out).
- make sure the dependency plugin copies them into the directory where
your application would expect them
Snapshots are meant to change. Leave the details how snapshots are
managed to maven. Just tell it to use the snapshot. Don't mess with
internal "unique versions".
Best regards
Ansgar
>
>
> Thanks
>
>
> --
> View this message in context: http://maven.40175.n5.nabble.com/custom-unique-version-tp5159884p5281260.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: custom unique version
Posted by Cem Koc <ce...@gmail.com>.
For those who wants another use case for custom unique version is:
At our legacy application based on JPA has persistence.xml. Our domain jars
were divided into the two module and they are included at our
persistence.xml at like this:
<persistence-unit name="SearchV2PU">
<jta-data-source>SearchV2DS</jta-data-source>
<jar-file>domain-A-${A-version}.jar</jar-file>
<jar-file>domain-B-${B-version}.jar</jar-file>
</persistence-unit>
Our persistence.xml file is filtered at build time by maven. However because
of the unique version of each SNAPSHOT, it can not be filtered correctly.
Our persistence provider Eclipse can not locate domain-A-***.jar since the
name of it changing daily.
Please do not suggest me to use release version of domain A dependency. This
domain dependency is changing very rapidly and its daily usage is very
critical.
I strongly need "custom unique version" of the snapshot and filter my
persistense.xml.
Still looking for a solution.
Thanks
--
View this message in context: http://maven.40175.n5.nabble.com/custom-unique-version-tp5159884p5281260.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: custom unique version
Posted by Benson Margulies <bi...@gmail.com>.
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
<rw...@artifact-software.com> 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 <rw...@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 <rw...@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<th...@uni-jena.de>:
>>>>>>>
>>>>>>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>>>>>>
>>>>>>>> 2012/1/20 Thomas Scheffler<th...@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<th...@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
>
>
>
>
> --
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: custom unique version
Posted by Ron Wheeler <rw...@artifact-software.com>.
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 <rwheeler@artifact-software.com
> <ma...@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
>> <ma...@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
>> <ma...@uni-jena.de>>:
>>
>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>
>> 2012/1/20 Thomas
>> Scheffler<thomas.scheffler@uni-jena.de
>> <ma...@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.scheffler@uni-jena.de
>> <ma...@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
>> <ma...@maven.apache.org>
>> For additional commands, e-mail:
>> users-help@maven.apache.org
>> <ma...@maven.apache.org>
>>
>>
>>
>>
>> --
>> Ron Wheeler
>> President
>> Artifact Software Inc
>> email: rwheeler@artifact-software.com
>> <ma...@artifact-software.com>
>> skype: ronaldmwheeler
>> phone: 866-970-2435, ext 102
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
>> <ma...@maven.apache.org>
>> For additional commands, e-mail: users-help@maven.apache.org
>> <ma...@maven.apache.org>
>>
>>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email:rwheeler@artifact-software.com <ma...@artifact-software.com>
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: custom unique version
Posted by Stephen Connolly <st...@gmail.com>.
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 <rw...@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 <rw...@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<th...@uni-jena.de>:
>>>>>
>>>>>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>>>>>
>>>>>> 2012/1/20 Thomas Scheffler<th...@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
>
>
Re: custom unique version
Posted by Ron Wheeler <rw...@artifact-software.com>.
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
> <ma...@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
> <ma...@uni-jena.de>>:
>
> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>
> 2012/1/20 Thomas
> Scheffler<thomas.scheffler@uni-jena.de
> <ma...@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.scheffler@uni-jena.de
> <ma...@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
> <ma...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
>
>
> --
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwheeler@artifact-software.com
> <ma...@artifact-software.com>
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> <ma...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
> <ma...@maven.apache.org>
>
>
--
Ron Wheeler
President
Artifact Software Inc
email: rwheeler@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
Re: custom unique version
Posted by Stephen Connolly <st...@gmail.com>.
On 23 January 2012 13:25, Ron Wheeler <rw...@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<th...@uni-jena.de>
>>>> >:
>>>>
>>>>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>>>>
>>>>> 2012/1/20 Thomas Scheffler<th...@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@**u**ni-jena.de <http://uni-jena.de><
>>>>>>>>>> thomas.scheffler@**uni-jena.de <th...@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<us...@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
>
Re: custom unique version
Posted by Ron Wheeler <rw...@artifact-software.com>.
You could reach out to the Hudson user community.
I do not use Hudson although many people here do use Maven and Hudson
together.
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.
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<th...@uni-jena.de>:
>>>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>>>
>>>>> 2012/1/20 Thomas Scheffler<th...@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<th...@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
Re: custom unique version
Posted by Thomas Scheffler <th...@uni-jena.de>.
Am 23.01.2012 09:34, schrieb Ansgar Konermann:
> Am 23.01.2012 08:36 schrieb "Thomas Scheffler"<thomas.scheffler@uni-jena.de
>> :
>>
>> 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.
>
> Snapshots change over time. If you want to depend on your library and have
> reliable dependency tracking, why not just *release* the library?
Hi, I thought of that but that would mean several minor releases every
day and changing application pom very often. I think that is the reason
why maven as SNAPSHOT versions. But sadly there is no easy way to track
them. So for some reason there are unique versioned SNAPSHOTS - that's
the default case by the way - but when requesting a SNAPSHOT version you
can not get it's unique version of it.
The best way so far is to use the versions plugin prior testing:
With "versions:lock-snapshots" you can modify the current pom and get
the unique versions written inside the pom.
After tests successfully finish you can grab the information from the
pom.xml or you run "versions:unlock-snapshots" to put back "SNAPSHOT" to
the versions.
That is so far the best solution I got. It would be better to get this
information after tests.
So anymore ideas?
Thomas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: custom unique version
Posted by Ansgar Konermann <an...@googlemail.com>.
Am 23.01.2012 08:36 schrieb "Thomas Scheffler" <thomas.scheffler@uni-jena.de
>:
>
> 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.
Snapshots change over time. If you want to depend on your library and have
reliable dependency tracking, why not just *release* the library?
Regards,
Ansgar
>
> 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<th...@uni-jena.de>:
>>>>
>>>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>>>
>>>>> 2012/1/20 Thomas Scheffler<th...@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
>
Re: custom unique version
Posted by Thomas Scheffler <th...@uni-jena.de>.
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<th...@uni-jena.de>:
>>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>>
>>>> 2012/1/20 Thomas Scheffler<th...@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<th...@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
Re: custom unique version
Posted by Thomas Scheffler <th...@uni-jena.de>.
Am 21.01.2012 16:49, schrieb Vincent Latombe:
> http://mojo.codehaus.org/buildnumber-maven-plugin/ could be your solution
>
> Vincent
Hi Vincent,
thank you for your suggestion but sadly the buildnumber from
buildnumber-maven-plugin is completely unrelated to the unique version
number that is generated in the deploy step.
Thomas
> 2012/1/20 Ron Wheeler<rw...@artifact-software.com>
>
>> 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.
>>
>> Ron
>>
>>
>> On 20/01/2012 10:14 AM, Stephen Connolly wrote:
>>
>>> 2012/1/20 Thomas Scheffler<th...@uni-jena.de>
>>>> :
>>>
>>>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>>>
>>>> 2012/1/20 Thomas Scheffler<th...@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@**u**ni-jena.de<http://uni-jena.de><
>>>>>>>>> thomas.scheffler@**uni-jena.de<th...@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<us...@maven.apache.org>
>>>> For additional commands, e-mail: users-help@maven.apache.org
>>>>
>>>> ------------------------------**------------------------------**
>>> ---------
>>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: custom unique version
Posted by Vincent Latombe <vi...@gmail.com>.
http://mojo.codehaus.org/buildnumber-maven-plugin/ could be your solution
Vincent
2012/1/20 Ron Wheeler <rw...@artifact-software.com>
> 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.
>
> Ron
>
>
> On 20/01/2012 10:14 AM, Stephen Connolly wrote:
>
>> 2012/1/20 Thomas Scheffler<th...@uni-jena.de>
>> >:
>>
>>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>>
>>> 2012/1/20 Thomas Scheffler<th...@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@**u**ni-jena.de <http://uni-jena.de><
>>>>>>>> thomas.scheffler@**uni-jena.de <th...@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<us...@maven.apache.org>
>>> For additional commands, e-mail: users-help@maven.apache.org
>>>
>>> ------------------------------**------------------------------**
>> ---------
>> To unsubscribe, e-mail: users-unsubscribe@maven.**apache.org<us...@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
>
Re: custom unique version
Posted by Ron Wheeler <rw...@artifact-software.com>.
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.
Ron
On 20/01/2012 10:14 AM, Stephen Connolly wrote:
> 2012/1/20 Thomas Scheffler<th...@uni-jena.de>:
>> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>>
>>> 2012/1/20 Thomas Scheffler<th...@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<th...@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
>>
> ---------------------------------------------------------------------
> 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
Re: custom unique version
Posted by Stephen Connolly <st...@gmail.com>.
2012/1/20 Thomas Scheffler <th...@uni-jena.de>:
> Am 20.01.2012 15:30, schrieb Stephen Connolly:
>
>> 2012/1/20 Thomas Scheffler<th...@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<th...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: custom unique version
Posted by Thomas Scheffler <th...@uni-jena.de>.
Am 20.01.2012 15:30, schrieb Stephen Connolly:
> 2012/1/20 Thomas Scheffler<th...@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?
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<th...@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
Re: custom unique version
Posted by Stephen Connolly <st...@gmail.com>.
2012/1/20 Thomas Scheffler <th...@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?
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<th...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: custom unique version
Posted by Thomas Scheffler <th...@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?
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<th...@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
Re: custom unique version
Posted by Stephen Connolly <st...@gmail.com>.
You can stuff what ever you want in tge manifest.
Google is your friend: maven jar plugin manifest customization
- Stephen
---
Sent from my Android phone, so random spelling mistakes, random nonsense
words and other nonsense are a direct result of using swype to type on the
screen
On Jan 20, 2012 10:45 a.m., "Thomas Scheffler" <th...@uni-jena.de>
wrote:
> 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<th...@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<us...@maven.apache.org>
> For additional commands, e-mail: users-help@maven.apache.org
>
>
Re: custom unique version
Posted by Thomas Scheffler <th...@uni-jena.de>.
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<th...@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
Re: custom unique version
Posted by Stephen Connolly <st...@gmail.com>.
It cannot.
That is part of the spec for the layout of a Maven repository.
-Stephen
2012/1/20 Thomas Scheffler <th...@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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org