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<thomas.scheff...@uni-jena.de>:
Am 20.01.2012 15:30, schrieb Stephen Connolly:
2012/1/20 Thomas Scheffler<thomas.scheff...@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.scheff...@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-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
