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