qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rafael Schloming <rafa...@redhat.com>
Subject Re: [java]: compilation failure on M2 and trunk
Date Tue, 02 Oct 2007 16:33:01 GMT
Rupert Smith 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.

Because we're using SNAPSHOTs, I can no longer build old versions of the 
code. This means it's impossible for me to rollback and figure out if a 
specific change introduced/fixed a problem. What exactly is the point of 
using source control with this constraint?

If you want to maintain your own separate project, that's fine, but 
forcing Qpid to use SNAPSHOT dependencies is a significant burden.


> On 02/10/2007, Rafael Schloming <rafaels@redhat.com> 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 <rafaels@redhat.com> 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 <cctrieloff@redhat.com> 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
>>>>>>> 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
>>>>>>>> available via google, and the instructions provided on
>>>>>>>> www.badgerset.co.uk for obtaining anonymous access to the
>>>>>>>> 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
>>>>>>>> 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.
>>>> 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 <gsim@redhat.com>
>>>>>>>>>>> M2:
>>>>>>>>>>> [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:
>>>>>>>>>>> [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

View raw message