Re: [java]: compilation failure on M2 and trunk

[Rafael Schloming]

Rupert Smith wrote:
There are other SNAPSHOTs in Qpid. In particular we use SNAPSHOT versions of
Maven plugins. It has been unavoidable because maven seems to be very much a
work in progress.

I would favor removing these as well.

Even without snapshots you can get unrepeatable builds through maven. There
are version ranged dependencies. Also the repositories are outside your
control. If you want repeatable builds, it seems that you have to checkout
the repository to a local directory, and then commit that somewhere along
with the source for that version.

I'm familiar with the issues involved in getting maven to produce 
repeatable builds, and while these are great reasons not to touch maven 
with a 10 foot pole, they aren't great reasons to use SNAPSHOT 
dependencies. Doing so only makes the situation go from bad to worse.

Again, sorry about the build failures on the junit toolkit. 0.6 version will
remedy the issue.

My concern is not the immediate build failure but the fact that *any* 
use of SNAPSHOT dependencies is a *guarantee* that the code checked in 
at that revision will inevitably become unbuildable.

--Rafael


On 02/10/2007, Rupert Smith <[EMAIL PROTECTED]> wrote:
Although, I do agree with you that is a lot better not to use SNAPSHOTs.

On 02/10/2007, Rupert Smith <[EMAIL PROTECTED] > wrote:
I've already used it in other projects. It pre-dates qpid. Its a library
that extends junit to add performance testing capabilities, and command line
enhancements like running tests repeatedly, for a duration, many times in
parallel etc. The underlying tests that it runs are essentially junits,
although you can pull in some other extensions to enhance your test wrt
performance, such as setting the clock boundaries. I can imagine many ways
in which other projects could make use of it.

Snapshots are fine for code under development. You just have to resolve
them as part of stabilization towards a release.

On 02/10/2007, Rafael Schloming <[EMAIL PROTECTED]> wrote:
Rupert Smith wrote:
Its not in the Qpid repository because the code contains nothing
that is
specific to Qpid, only to testing in general.

Apologies for the broken builds. As I say, there is a 'qpid' user
setup on
the svn for it, with the intention that other qpid developers could
change
the code if needed. Trunk was previously pinned to the 0.5 release,
merges
down from M2 updated the poms to 0.6-SNAPSHOT by accident, without
also
merging down changes to the code. I needed to use a snapshot because
otherwise I would not be able to commit code dependant on small
changes in
the library for several days at a time; the length of time it takes
to get a
maven central repo upload.

A 0.6 build will be out in a few days, with source code and javadocs
available on the central repo too. Hope this resolves your concerns.
Given the added complications, I don't think there is sufficient
reason
to put this code in a separate repository. I can't imagine that other
projects could ever use this code while it is being developed in
lock-step with Qpid.

Furthermore I really don't think that this is a scalable practice.
Imagine the chaos if we all decided to contribute code into external
projects connected via SNAPSHOT dependencies.

If this code is sufficiently externally used to warrant a separate
release cycle from Qpid, then there really should be no need to use a
SNAPSHOT dependency, and if not then there is no reason not to simply
release it along with Qpid as an independently usable library.

It really is the case that SNAPSHOT dependencies *fundamentally*
destabilize a build. When you use SNAPSHOT dependencies like this you
lose a lot of the benefit of source control. It is no longer possible,
for example, to revert my checkout to a few weeks ago and rebuild the
broker since the build from a few weeks ago will pick up *today*'s
SNAPSHOT, not the SNAPSHOT from a few weeks ago.

I strongly believe as a matter of policy we shouldn't permit SNAPSHOT
dependencies in our build.

--Rafael

Rupert

On 02/10/2007, Rafael Schloming < [EMAIL PROTECTED]> wrote:
Rupert Smith wrote:
It is available through svn on sourceforge:
https://junit-toolkit.svn.sourceforge.net/svnroot/junit-toolkit.
Main
page:
http://sourceforge.net/projects/junit-toolkit/

It is Apache licensed.

I created a qpid account, on the sourceforge project, in case any
qpid
contributors need to edit the sources. If you have patches, please
ask
me
and I will apply them for you or give you the log in details.

It is a snapshot dependency because it has been undergoing a lot
of
improvements in order to provide support for qpid tests. It should
be
resolved to a concrete version for the M2 release (although not
strictly
necessary as it is a test dependency only). In fact I will put out
a
release
right now, so that it can make it onto the maven central repo in
the
next
few days.
So if I understand correctly, this code is being co-developed by
you
along with Qpid, but it isn't in the Qpid SVN repository and it is
being
pulled in via maven SNAPSHOT?

This seems like a particularly fragile arrangement. Beyond all the
*very* good reasons to *never* use maven snapshots, it's not quite
fair
to other Qpid developers as it makes it easy for you to break the
build,
but difficult for others to fix it.

--Rafael

Rupert

On 01/10/2007, Carl Trieloff < [EMAIL PROTECTED]> wrote:
If there is no public source we should remove it as a dependency.
None
of the links to source work.

Carl.

Rafael Schloming wrote:
Correction, the useless web site is here, not where I listed
below:
http://www.thebadgerset.co.uk/junit-toolkit/

--Rafael

Rafael Schloming wrote:
I can't seem to find anything useful on google about
uk.co.thebadgerset.junit.extensions.TKTestRunner. The source
isn't
available via google, and the instructions provided on
www.badgerset.co.uk for obtaining anonymous access to the
source
don't actually work.

So as far as I can tell Qpid has a SNAPSHOT dependency on a
junit
test runner that does not have publicly available source. This
is
quite frustrating as it is most difficult to fix the build
given
these circumstances.

How do we make this SNAPSHOT dependency go away? Could someone
please
explain why it is there in the first place?

--Rafael

Rafael Schloming wrote:
I'm still seeing this build failure on trunk.

--Rafael

Rupert Smith wrote:
Should be fixed very soon after it was able to occurr.
Committing
to
multiple svn's in a non-atomic way was the cause. Let me know
if it
is not
fixed.

On 28/09/2007, Gordon Sim <[EMAIL PROTECTED]> wrote:
M2:

[ERROR] BUILD FAILURE
[INFO]

------------------------------------------------------------------------
[INFO] Compilation failure
/usr/share/cruisecontrol-bin-2.6.1

/projects/qpid-M2/java/systests/src/main/java/org/apache/qpid/test/framework/distributedtesting/Coordinator.java:[142,8]

cannot find symbol
symbol : constructor
TKTestRunner(java.lang.Integer,java.lang.Long,int[],int,int[],
java.lang.String,java.lang.String,java.lang.String
,boolean,boolean,boolean)
location: class
uk.co.thebadgerset.junit.extensions.TKTestRunner
/usr/share/cruisecontrol-bin-2.6.1

/projects/qpid-M2/java/systests/src/main/java/org/apache/qpid/test/framework/distributedtesting/Coordinator.java:[395,16]

cannot find symbol
symbol : variable currentTestClassName
location: class

org.apache.qpid.test.framework.distributedtesting.Coordinator
Trunk:

[ERROR] BUILD FAILURE
[INFO]

------------------------------------------------------------------------
[INFO] Compilation failure



/home/gordon/qpid/trunk/qpid/java/systests/src/main/java/org/apache/qpid/test/framework/distributedtesting/Coordinator.java:[158,8]

cannot find symbol
symbol  : constructor
TKTestRunner(java.lang.Integer,java.lang.Long,int[],int,int[],
java.lang.String,java.lang.String,java.lang.String,boolean)
location: class
uk.co.thebadgerset.junit.extensions.TKTestRunner