I am not sure that having the development side run without any
constraints regarding releasing version for testing is a good idea, you
can deal with this.
Can you not upload their latest version into your Maven repo as
x.x-SNAPSHOTs and depend on their SNAPSHOTs?
You should always get the latest version and should be able to trace
back each day's configuration of SNAPSHOTS, if you want to know what you
actually tested.
Ron
On 20/09/2012 9:01 AM, mlandman99 wrote:
Ron Wheeler wrote
What is the underlying problem for which a solution is sought?
Why are the jars so volatile?
Why is it so important to use the "latest" version and then track the
history so carefully?
Describe the "release" cycle of the final product.
It sounds like this problem needs to be restated in higher level terms
in order to get a reasonable solution.
Great question and thanks for asking.
OK, let me describe in more detail:
There are two software projects in play here. One is mine (QA), we'll call
that project "TESTER". The other is built by our sw-dev team, we'll call
that "SERVER".
Sequence of events:
1) "SERVER" is built nightly by sw-dev, with no advanced build tools or
artifact mgmt, etc. The net result is that the build server has a new
directory with: The installer for "SERVER", and a few .jar files.
2) "TESTER" is intended to build on a CI server (teamcity), which
essentially ends up being a regression testing harness. It builds my java
project "TESTER", which is made up of testNG tests.
3) The first test "TESTER" runs, is to take the installer for "SERVER", and
run it on a remote machine.
4) All subsequent tests run on "TESTER" end up running tests across the
network (webservices, etc), against the now remotely-installed-and-running
"SERVER".
"SERVER" has a client UI, a java applet. I don't want to automate testing at
the client UI level for a number of reasons, I want to automate testing just
under the client UI. This way, the tests will exercise as much of the real
code path as possible (i.e. 1/2 the client code, and then that code will
communicate with the server across the network, etc.).
Here's the issue: some of the libraries that "TESTER" uses, are some of the
libraries built in the nightly build (i.e. they would be some of the
libraries used by the client app). If I run tests on deployed server build
123, but I'm still using some of the client libraries that were built in
build 122, I might miss a bug they've introduced in build 123, etc. Tests
might pass that should fail, or fail that should pass, etc.
So... when I build "TESTER", I want to ensure that it's using the 3-4 jars
that were specifically built for the same version of the server I've just
installed.
The problem is that the sw-dev build team doesn't manage these artifacts,
etc. I have access to them in a reliable network share, but that's about it.
Hopefully that describes the problem a little better.
Thanks in advance!
--
View this message in context:
http://maven.40175.n5.nabble.com/strategy-for-incorporating-private-jars-into-a-project-tp5722524p5722736.html
Sent from the Maven - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Ron Wheeler
President
Artifact Software Inc
email: [email protected]
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
