You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@qpid.apache.org by Rafael Schloming <ra...@redhat.com> on 2007/10/01 20:13:04 UTC
Re: [java]: compilation failure on M2 and trunk
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 <gs...@redhat.com> 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
>>
>>
>
Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
Should be fixed on trunk, all dependencies now refer to 0.6-SNAPSHOT, this
will be updated to 0.6 in a few days, when it comes out on the central repo.
On 02/10/2007, Rupert Smith <ru...@googlemail.com> wrote:
>
> Sorry, didn't realize you were complaining about failure on trunk. I will
> update all refs to junit-toolkit* on the trunk poms so that the build passes
> there. I think the issue is that trunk got pinned to a non-SNAPSHOT version
> ( 0.5), but test code must have been merged down, that depends upon the
> newest SNAPSHOT.
>
> Yet another reason for not forking the tests...
>
> On 01/10/2007, Rafael Schloming <ra...@redhat.com> 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 <gsim@redhat.com > 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
> > >>>
> > >>>
> > >>
> >
>
>
Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
Sorry, didn't realize you were complaining about failure on trunk. I will
update all refs to junit-toolkit* on the trunk poms so that the build passes
there. I think the issue is that trunk got pinned to a non-SNAPSHOT version
(0.5), but test code must have been merged down, that depends upon the
newest SNAPSHOT.
Yet another reason for not forking the tests...
On 01/10/2007, Rafael Schloming <ra...@redhat.com> 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 <gs...@redhat.com> 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
> >>>
> >>>
> >>
>
Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
You may need to refresh your local repository if you still have build
failures. Delete everything under repository/uk/co/thebadgerset and try
again. The build should pick up snapshots from sourceforge.
On 02/10/2007, Rupert Smith <ru...@googlemail.com> 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.
>
> Rupert
>
> On 01/10/2007, Carl Trieloff <cc...@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 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 <gs...@redhat.com> 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
> > >>>>>
> > >>>>>
> > >>>>
> >
> >
>
Re: [java]: compilation failure on M2 and trunk
Posted by Robert Greig <ro...@gmail.com>.
On 02/10/2007, Rafael Schloming <ra...@redhat.com> wrote:
> 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.
Does anyone know the impact of doing so? Is our build going to die?
> 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.
There is also the issue of how we support custom builds of
dependencies. For example one solution for the hanging problem we
identified is to rebuild Mina with a change that removes the use of
IdentityHashMap. However it would appear (from what I have been told
at least) that doing this with maven isn't as simple as any sane
person might expect.
It really does beg the question exactly what benefits maven brings to
this project.
> 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.
I would have major concerns about the lack of repeatability of a build
of a release, in particular M2. We need to make sure that an M2 build
is repeatable.
RG
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
On 04/10/2007, Robert Greig <ro...@gmail.com> wrote:
>
> On 04/10/2007, Rupert Smith <ru...@googlemail.com> wrote:
>
> > By all means, write an alternative build in Ant, that does everything
> that
> > the Maven 2 one does. Once you are done, tell us how long it took, and
> how
> > nicely modular and maintainable your script is, and what process you
> will
> > put in place to ensure that it stays that way.
>
> Did you look at the ant build system we had for M1? Rafi wrote that
> and IMO it was excellent. In fact I have used it in several projects
> since then (with various small modifications obviously). It was
> modular and in general each "module" had only a very small number of
> lines of xml to configure it.
>
> I am not sure if our current maven build system actually even has the
> same functionality as the previous ant system. I certainly find trying
> to do builds for debugging with the current maven system extremely
> painful and slow - I want to run one command that builds classes into
> a particular "exploded" directory tree not build then call mvn
> assembly:directory to create various archives then extract them.
>
> > I never saw and Ant script
> > that was well documented and easy to maintain, except the ones I wrote
> > myself and took great care over.
>
> We can only aspire to your standards.
>
> > Just leave the existing Maven 2 build
> > alone, until you can convince everyone that an alternative is really
> better.
>
> I don't believe I indicated anywhere that I was planning on removing
> our current build system.
>
> RG
>
Sorry Robert, I was more replying in general to the thread than your post
specifically.
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Robert Greig <ro...@gmail.com>.
On 04/10/2007, Rupert Smith <ru...@googlemail.com> wrote:
> By all means, write an alternative build in Ant, that does everything that
> the Maven 2 one does. Once you are done, tell us how long it took, and how
> nicely modular and maintainable your script is, and what process you will
> put in place to ensure that it stays that way.
Did you look at the ant build system we had for M1? Rafi wrote that
and IMO it was excellent. In fact I have used it in several projects
since then (with various small modifications obviously). It was
modular and in general each "module" had only a very small number of
lines of xml to configure it.
I am not sure if our current maven build system actually even has the
same functionality as the previous ant system. I certainly find trying
to do builds for debugging with the current maven system extremely
painful and slow - I want to run one command that builds classes into
a particular "exploded" directory tree not build then call mvn
assembly:directory to create various archives then extract them.
> I never saw and Ant script
> that was well documented and easy to maintain, except the ones I wrote
> myself and took great care over.
We can only aspire to your standards.
> Just leave the existing Maven 2 build
> alone, until you can convince everyone that an alternative is really better.
I don't believe I indicated anywhere that I was planning on removing
our current build system.
RG
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
On 03/10/2007, Robert Greig <ro...@gmail.com> wrote:
>
> On 03/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
> >
> > I think the following has come out of this thread.. (my view)
>
> > 1. we should make it a practice not to use snapshots
> > 2. if we decide to use one - it should be the only option and with list
> > agreement.
>
> I agree with these points.
>
> I would also seriously question whether maven is actually the right
> choice for this project.
-1
Maven is flawed, but it gradually getting better. Seriously, we've got
better things to do than rewrite the entire build system in Ant. What we
have works, and there are ways to get repeatable builds out of it.
I have used Ant, Maven 1 and Maven 2, and I actually have scripts from all 3
in working order against my personal library of stuff. One interesting this
I have observed about these 3, is that Ant is by far the most verbose. The
ant build weighs in at +1000 lines of XML, Maven 1 the lightest at around a
hundred, Maven 2 bloating out again to a few hundred.
By all means, write an alternative build in Ant, that does everything that
the Maven 2 one does. Once you are done, tell us how long it took, and how
nicely modular and maintainable your script is, and what process you will
put in place to ensure that it stays that way. I never saw and Ant script
that was well documented and easy to maintain, except the ones I wrote
myself and took great care over. Just leave the existing Maven 2 build
alone, until you can convince everyone that an alternative is really better.
Rupert
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Marnie McCormack <ma...@googlemail.com>.
I think that they key question, right now, for Qpid is .. does Maven add
more to our project as it currently stands than it costs to
maintain/manage/fit in with ? All opinions my own ...
The future is important, in terms of project uptake of Qpid, but we need to
focus on the now for a bit longer imho.
To figure that out we'd need to consider:
- the cost of re-introducing ant or, more likely, something more
sophisticated to do building/packaging
- more fundamentally, does something mature enough exists so that removing
maven wouldn't mean we spend an age writing ant plugins ?
- the cost of maintaining maven config in Qpid and dealing with
bugs/constraints that it introduces
- the impact of not using maven, in terms of other projects and how we might
make life simple for other projects without it
Our milestone releases tend to be a while in the making, and I don't think
maven has helped much with gettting our first two out. Firstly because we
didn't have a lot of maven experience and also because some of maven's
features are not as inituitive as they could be. However, I speak from the
standpoint of only working on Qpid (rather than integration with other dev
projects using maven) so I don't have any vested interest in maven from that
pov.
My gut is that it's not a great solution, but we've come so far down this
road that I think we should stick with it, at least until M2 is done. Given
recent discussions now seems a good time to get a Qpid community consensus
though. Can we do that ?
I guess the time to apply any change would be before the main 0.10 changes
get too advanced.
Regards,
Marnie
ps I'm +1 for no snapshots now
On 10/4/07, Robert Greig <ro...@gmail.com> wrote:
>
> On 04/10/2007, Rafael Schloming <ra...@redhat.com> wrote:
>
> > I wouldn't say dependency management is useless. Look at RPM if you want
> > an example of how incredibly useful it can be. It's just that what maven
> > does doesn't really qualify as dependency management in any real sense.
>
> I agree with most of your points but I would say that RPM is useful
> because of the need to update /usr/lib etc and track system library
> dependencies. While I agree that if you are going to claim to do
> dependency management you need to be able to do this for essentially
> arbitrary dependencies, for most java "products" I think it is fine to
> bundle all the dependencies and put them under the installation
> directory.
>
> > The only thing people might want to create a maven dependency on is our
> > client library, and I seriously doubt that anyone would stop using it
> > because we didn't build it with maven.
>
> Exactly. I don't believe IBM produces a maven repo for the MQ client.
>
> RG
>
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Robert Greig <ro...@gmail.com>.
On 04/10/2007, Rafael Schloming <ra...@redhat.com> wrote:
> I wouldn't say dependency management is useless. Look at RPM if you want
> an example of how incredibly useful it can be. It's just that what maven
> does doesn't really qualify as dependency management in any real sense.
I agree with most of your points but I would say that RPM is useful
because of the need to update /usr/lib etc and track system library
dependencies. While I agree that if you are going to claim to do
dependency management you need to be able to do this for essentially
arbitrary dependencies, for most java "products" I think it is fine to
bundle all the dependencies and put them under the installation
directory.
> The only thing people might want to create a maven dependency on is our
> client library, and I seriously doubt that anyone would stop using it
> because we didn't build it with maven.
Exactly. I don't believe IBM produces a maven repo for the MQ client.
RG
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Rafael Schloming <ra...@redhat.com>.
Rajith Attapattu wrote:
> I totally agree that maven sucks in a lot of ways.
> I am more upset about the attitude of some of the folks in the maven
> community and their reluctance to listen to users.
> (I saw most of the discussions my friend deepak had with some of the so
> called maven stalwarts in the maven community)
>
> However I think maven is a nessacery evil if want Qpid to be used by other
> projects.
Personally I think maven's lack of ability to describe dependencies on
non mavenized software is really a problem for the maven community to solve.
>> I think this dependency feature is oversold and outweighed by the
>> repeatability disadvantages already discussed.
>
> Yes, this has blinded so many folks and they think maven is great bcos it
> does this magical dependency management.
I wouldn't say dependency management is useless. Look at RPM if you want
an example of how incredibly useful it can be. It's just that what maven
does doesn't really qualify as dependency management in any real sense.
Real software is messy and has messy dependencies, and maven just can't
describe those kinds of dependencies, and as a result it's usefulness is
limited to a fairly small subset of all software, i.e. pretty much java
software with java-only dependencies that all happen to be built by maven.
> So until these folks move on the next big thing (the latest fad) we might
> have to keep using maven IF we want our project to be used by these people.
>
> It is sad, but thats reality.
The only thing people might want to create a maven dependency on is our
client library, and I seriously doubt that anyone would stop using it
because we didn't build it with maven.
--Rafael
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Rajith Attapattu <ra...@gmail.com>.
I totally agree that maven sucks in a lot of ways.
I am more upset about the attitude of some of the folks in the maven
community and their reluctance to listen to users.
(I saw most of the discussions my friend deepak had with some of the so
called maven stalwarts in the maven community)
However I think maven is a nessacery evil if want Qpid to be used by other
projects.
> I think this dependency feature is oversold and outweighed by the
> repeatability disadvantages already discussed.
Yes, this has blinded so many folks and they think maven is great bcos it
does this magical dependency management.
So until these folks move on the next big thing (the latest fad) we might
have to keep using maven IF we want our project to be used by these people.
It is sad, but thats reality.
Regards,
Rajith
On 10/3/07, Robert Greig <ro...@gmail.com> wrote:
>
> On 03/10/2007, Daniel Kulp <da...@iona.com> wrote:
>
> > For example: you are currently using mina version 1.0.0. I see 1.0.6
> > was released yesterday. To see if qpid works, just update your top
> > level pom to 1.0.6 and run. There's also a 1.1.3 released yesterday.
> > Again, update and try it. (I assume 1.1.x might have more API changes
> > that may require more work). If I want to try the 1.0.7-SNAPSHOT
> > builds, that's easy too.
>
> I presume you mean developers of Qpid, not developers who use Qpid in
> their project, since anyone using a project who tries a dependency
> like that to see if it works is just mad.
>
> For Qpid developers, downloading dependencies is not a big deal. The
> number of dependencies used by the Qpid client is deliberately small.
>
> > 2) Ease for your users - related to (1). If you do a "mvn deploy", all
> > your artifacts should then be in the repo. I could depend on
> > qpid-client only and I'd get everything that qpid-client needs
> > automatically. If you have a pom pointing at a local file not in a
> > repo, I would then also have to go off to figure out where the hell that
> > file is and also do all the "magic" to get mvn to use it.
>
> Or you could download a client bundle and get all our dependencies in
> the same way that if I want Oracle drivers, or WebLogic or Gigaspaces
> I just download it and install it.
>
> I think this dependency feature is oversold and outweighed by the
> repeatability disadvantages already discussed.
>
> > It cycles down from there. Lets say I then deploy new artifacts. My
> > users would then also have to find the jar, etc... They may not know
> > that I even use qpid. They would just complain and bitch at me for
> > something you started.
>
> It's up to you to provide tested distributions and clear instructions.
>
> RG
>
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Robert Greig <ro...@gmail.com>.
On 03/10/2007, Daniel Kulp <da...@iona.com> wrote:
> For example: you are currently using mina version 1.0.0. I see 1.0.6
> was released yesterday. To see if qpid works, just update your top
> level pom to 1.0.6 and run. There's also a 1.1.3 released yesterday.
> Again, update and try it. (I assume 1.1.x might have more API changes
> that may require more work). If I want to try the 1.0.7-SNAPSHOT
> builds, that's easy too.
I presume you mean developers of Qpid, not developers who use Qpid in
their project, since anyone using a project who tries a dependency
like that to see if it works is just mad.
For Qpid developers, downloading dependencies is not a big deal. The
number of dependencies used by the Qpid client is deliberately small.
> 2) Ease for your users - related to (1). If you do a "mvn deploy", all
> your artifacts should then be in the repo. I could depend on
> qpid-client only and I'd get everything that qpid-client needs
> automatically. If you have a pom pointing at a local file not in a
> repo, I would then also have to go off to figure out where the hell that
> file is and also do all the "magic" to get mvn to use it.
Or you could download a client bundle and get all our dependencies in
the same way that if I want Oracle drivers, or WebLogic or Gigaspaces
I just download it and install it.
I think this dependency feature is oversold and outweighed by the
repeatability disadvantages already discussed.
> It cycles down from there. Lets say I then deploy new artifacts. My
> users would then also have to find the jar, etc... They may not know
> that I even use qpid. They would just complain and bitch at me for
> something you started.
It's up to you to provide tested distributions and clear instructions.
RG
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Rafael Schloming <ra...@redhat.com>.
Daniel Kulp wrote:
> On Wednesday 03 October 2007, Robert Greig wrote:
>>> Since you haven't done a release, the artifacts aren't there.
>>> Once you do the release (providing it's done properly) and actually
>>> start getting users that want to integrate Qpid into their builds,
>>> this starts becoming increasingly important.
>> Are you saying there is no way to use a jar in a maven build that
>> isn't available on a maven repo? If so that sounds like a pretty
>> damning indictment of maven.
>
> Well, there ARE ways to do it, but it's very hard to do and it's very
> fragile so for all intents and purposes, the answer is no.
>
> But that's not a bad thing. It's a good thing and was specifically
> designed to be that way.
You're suggesting that maven was specifically designed to make it
difficult and fragile to depend on software that wasn't built with maven?
I don't see how the reasons you list below at all suggest that this is a
good thing.
> Couple of reasons:
> 1) Ease for developers - when I need to update a dependency version, I
> just change the version number in my pom and run "mvn install" and mvn
> does the rest to test to see if it will work. The old way of going off
> to download their distribution, unpacking it, replacing the jars in my
> lib dir, checking the other jars in the distribution (maybe the new
> version includes/depends on newer versions of other things), possibly
> updating the build scripts, etc... really sucks.
It is admittedly a pain to do that by hand whenever it needs to be done,
however it seems like a leap to suppose that the only solution to that
pain is to force everyone to change their projects so that maven can
understand them.
As a point of contrast, RPM automates that whole process without any
imposition on the projects being depended on. This would seem to be a
more useful approach since it solves the problem without requiring the
whole world to switch to maven, and also happens to work across other
languages where maven is not an option.
It would be quite trivial for maven to similarly provide the means to
specify a dependency on any jar or jar(s) stored in a standard archive
rather than forcing everyone to use the packaging conventions adopted by
maven.
> For example: you are currently using mina version 1.0.0. I see 1.0.6
> was released yesterday. To see if qpid works, just update your top
> level pom to 1.0.6 and run. There's also a 1.1.3 released yesterday.
> Again, update and try it. (I assume 1.1.x might have more API changes
> that may require more work). If I want to try the 1.0.7-SNAPSHOT
> builds, that's easy too.
>
>
> 2) Ease for your users - related to (1). If you do a "mvn deploy", all
> your artifacts should then be in the repo. I could depend on
> qpid-client only and I'd get everything that qpid-client needs
> automatically. If you have a pom pointing at a local file not in a
> repo, I would then also have to go off to figure out where the hell that
> file is and also do all the "magic" to get mvn to use it.
>
> It cycles down from there. Lets say I then deploy new artifacts. My
> users would then also have to find the jar, etc... They may not know
> that I even use qpid. They would just complain and bitch at me for
> something you started.
>
> If the poms accurately describe all the dependencies and the dependencies
> are all available, mvn make it easier for you as well as projects that
> depend on you. (if they also use mvn or the mvn extensions to ant or
> Ivy, which all would use the repositories)
You seem to be suggesting that the only way to make software available
remotely in a machine readable format is through a maven repository.
This isn't true. The vast majority of open source projects provide
stable download URLs for their releases, and as I said above it would be
quite trivial for maven to access these if maven developers really
wanted to make their users lives easier.
<rant>
Your argument basically boils down to stating that the reason we should
use maven is that it would make our lives easier if everyone else in the
world happened to already be using it, but I have yet to see a
satisfactory explanation of why maven couldn't provide all the same
benefits from the get-go without requiring everyone else to switch over.
Beyond that I also have yet to see a good technical reason to entangle
package distribution and dependency management with a specific build
system. There is as yet no such thing as a one-size-fits-all build
system, and maven's efforts in that area certainly fall spectacularly
short of the ideal.
IMHO any package distribution and dependency format that can't describe
dependencies on external distribution formats, and also forces the use
of a single build system will only ever meet with limited success. I
certainly think it's a stretch to call what maven does "helpful". It's
certainly as much of a problem as it is a solution.
</rant>
--Rafael
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Daniel Kulp <da...@iona.com>.
On Wednesday 03 October 2007, Robert Greig wrote:
> > Since you haven't done a release, the artifacts aren't there.
> > Once you do the release (providing it's done properly) and actually
> > start getting users that want to integrate Qpid into their builds,
> > this starts becoming increasingly important.
>
> Are you saying there is no way to use a jar in a maven build that
> isn't available on a maven repo? If so that sounds like a pretty
> damning indictment of maven.
Well, there ARE ways to do it, but it's very hard to do and it's very
fragile so for all intents and purposes, the answer is no.
But that's not a bad thing. It's a good thing and was specifically
designed to be that way.
Couple of reasons:
1) Ease for developers - when I need to update a dependency version, I
just change the version number in my pom and run "mvn install" and mvn
does the rest to test to see if it will work. The old way of going off
to download their distribution, unpacking it, replacing the jars in my
lib dir, checking the other jars in the distribution (maybe the new
version includes/depends on newer versions of other things), possibly
updating the build scripts, etc... really sucks.
For example: you are currently using mina version 1.0.0. I see 1.0.6
was released yesterday. To see if qpid works, just update your top
level pom to 1.0.6 and run. There's also a 1.1.3 released yesterday.
Again, update and try it. (I assume 1.1.x might have more API changes
that may require more work). If I want to try the 1.0.7-SNAPSHOT
builds, that's easy too.
2) Ease for your users - related to (1). If you do a "mvn deploy", all
your artifacts should then be in the repo. I could depend on
qpid-client only and I'd get everything that qpid-client needs
automatically. If you have a pom pointing at a local file not in a
repo, I would then also have to go off to figure out where the hell that
file is and also do all the "magic" to get mvn to use it.
It cycles down from there. Lets say I then deploy new artifacts. My
users would then also have to find the jar, etc... They may not know
that I even use qpid. They would just complain and bitch at me for
something you started.
If the poms accurately describe all the dependencies and the dependencies
are all available, mvn make it easier for you as well as projects that
depend on you. (if they also use mvn or the mvn extensions to ant or
Ivy, which all would use the repositories)
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Daniel Kulp <da...@iona.com>.
This is where the "fragile" comes in..
In a multi-module build, ${basedir} is the dir of the current build.
Thus, if you have a jar that is needed by all the submodules, you'd have
to move it into all the subdirs. OR define a propery in each module
that gives it's relative location:
<topdir>../..</topdir>
....
<url>file://${basedir}/${topdir}/mvn-repo</url>
The next issue is if you do a deploy to maven repo to make your stuff
available to other maven projects, they'll start trying to find things
in file://${basedir}/${topdir}/mvn-repo, which, in their project,
doesn't exist. Thus, it won't find your dependent jars.
Dan
On Thursday 04 October 2007, Rupert Smith wrote:
> Or to use the jar without uploading...
>
> Put it in a local directory that you check in under svn. In your
> pom.xmlcreate a repository that references it. For example:
>
> <repositories>
> <repository>
> <id>local.repo</id>
> <name>Local Repository</name>
> <url>file://${basedir}/mvn-repo</url>
> </repository>
> </repositories>
>
> The trick is to use file: in the URL.
>
> Rupert
>
> On 04/10/2007, Rupert Smith <ru...@googlemail.com> wrote:
> > On 03/10/2007, Robert Greig <ro...@gmail.com> wrote:
> > > On 03/10/2007, Daniel Kulp <da...@iona.com> wrote:
> > > > One of the main points of using maven was to get artifacts into
> > > > the repositories in a way that other USERS can use them with
> > > > their maven builds.
> > >
> > > Other MAVEN USERS presumably.
> > >
> > > > Since you haven't done a release, the artifacts aren't there.
> > > > Once you do the release (providing it's done properly) and
> > > > actually start getting users that want to integrate Qpid into
> > > > their builds,
> > >
> > > this
> > >
> > > > starts becoming increasingly important.
> > >
> > > Are you saying there is no way to use a jar in a maven build that
> > > isn't available on a maven repo? If so that sounds like a pretty
> > > damning indictment of maven.
> > >
> > > RG
> >
> > Its pretty easy really. Create a pom.xml listing the dependencies of
> > the jar, then package it up with you upload request:
> >
> > http://maven.apache.org/guides/mini/guide-central-repository-upload.
> >html
> >
> > Rupert
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
This is the thing I find amusing about Maven2. Maven means 'expert' and the
fundamental idea of maven is that is is an expert on how to build, and
provides that expertise in the form of plugins, to free us from having to
write the same code over and over in Ant for common build tasks. Someone
invents a new common build task (e.g. retro translation) and uploads a
plugin for it, then everyone can use it with very little thought. Often it
works very well, and it is possible to do a lot of advanced stuff with maven
with just a couple of lines of XML.
But when it comes to the simple stuff, like this .jar example... It is the
maven user who must be an expert; a Maven maven. I have had to invest a lot
of effort in learning Mavens quirks and workarounds, in order to be able to
do the simplest of things.
Maven1 was actually a lot better in that respect, because you had a
maven.xml which was a jellyfied (ugh!) Ant script, so you could easily drop
down to Ant when you needed to.
If you get stuck with it, then I would recommend taking a look at the list
of reference resources I have compiled on del.icio.us for Maven2:
http://del.icio.us/rupertlssmith/maven
Rupert
On 04/10/2007, Rupert Smith <ru...@googlemail.com> wrote:
>
> Or to use the jar without uploading...
>
> Put it in a local directory that you check in under svn. In your pom.xmlcreate a repository that references it. For example:
>
> <repositories>
> <repository>
> <id>local.repo</id>
> <name>Local Repository</name>
> <url>file://${basedir}/mvn-repo</url>
> </repository>
> </repositories>
>
> The trick is to use file: in the URL.
>
> Rupert
>
> On 04/10/2007, Rupert Smith <rupertlssmith@googlemail.com > wrote:
> >
> > On 03/10/2007, Robert Greig <ro...@gmail.com> wrote:
> > >
> > > On 03/10/2007, Daniel Kulp <da...@iona.com> wrote:
> > >
> > > > One of the main points of using maven was to get artifacts into the
> > > > repositories in a way that other USERS can use them with their maven
> > >
> > > > builds.
> > >
> > > Other MAVEN USERS presumably.
> > >
> > > > Since you haven't done a release, the artifacts aren't there.
> > > > Once you do the release (providing it's done properly) and actually
> > > > start getting users that want to integrate Qpid into their builds,
> > > this
> > > > starts becoming increasingly important.
> > >
> > > Are you saying there is no way to use a jar in a maven build that
> > > isn't available on a maven repo? If so that sounds like a pretty
> > > damning indictment of maven.
> > >
> > > RG
> > >
> >
> >
> > Its pretty easy really. Create a pom.xml listing the dependencies of the
> > jar, then package it up with you upload request:
> >
> > http://maven.apache.org/guides/mini/guide-central-repository-upload.html
> >
> > Rupert
> >
>
>
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
Or to use the jar without uploading...
Put it in a local directory that you check in under svn. In your
pom.xmlcreate a repository that references it. For example:
<repositories>
<repository>
<id>local.repo</id>
<name>Local Repository</name>
<url>file://${basedir}/mvn-repo</url>
</repository>
</repositories>
The trick is to use file: in the URL.
Rupert
On 04/10/2007, Rupert Smith <ru...@googlemail.com> wrote:
>
> On 03/10/2007, Robert Greig <ro...@gmail.com> wrote:
> >
> > On 03/10/2007, Daniel Kulp <da...@iona.com> wrote:
> >
> > > One of the main points of using maven was to get artifacts into the
> > > repositories in a way that other USERS can use them with their maven
> > > builds.
> >
> > Other MAVEN USERS presumably.
> >
> > > Since you haven't done a release, the artifacts aren't there.
> > > Once you do the release (providing it's done properly) and actually
> > > start getting users that want to integrate Qpid into their builds,
> > this
> > > starts becoming increasingly important.
> >
> > Are you saying there is no way to use a jar in a maven build that
> > isn't available on a maven repo? If so that sounds like a pretty
> > damning indictment of maven.
> >
> > RG
> >
>
>
> Its pretty easy really. Create a pom.xml listing the dependencies of the
> jar, then package it up with you upload request:
>
> http://maven.apache.org/guides/mini/guide-central-repository-upload.html
>
> Rupert
>
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
On 03/10/2007, Robert Greig <ro...@gmail.com> wrote:
>
> On 03/10/2007, Daniel Kulp <da...@iona.com> wrote:
>
> > One of the main points of using maven was to get artifacts into the
> > repositories in a way that other USERS can use them with their maven
> > builds.
>
> Other MAVEN USERS presumably.
>
> > Since you haven't done a release, the artifacts aren't there.
> > Once you do the release (providing it's done properly) and actually
> > start getting users that want to integrate Qpid into their builds, this
> > starts becoming increasingly important.
>
> Are you saying there is no way to use a jar in a maven build that
> isn't available on a maven repo? If so that sounds like a pretty
> damning indictment of maven.
>
> RG
>
Its pretty easy really. Create a pom.xml listing the dependencies of the
jar, then package it up with you upload request:
http://maven.apache.org/guides/mini/guide-central-repository-upload.html
Rupert
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Robert Greig <ro...@gmail.com>.
On 03/10/2007, Daniel Kulp <da...@iona.com> wrote:
> One of the main points of using maven was to get artifacts into the
> repositories in a way that other USERS can use them with their maven
> builds.
Other MAVEN USERS presumably.
> Since you haven't done a release, the artifacts aren't there.
> Once you do the release (providing it's done properly) and actually
> start getting users that want to integrate Qpid into their builds, this
> starts becoming increasingly important.
Are you saying there is no way to use a jar in a maven build that
isn't available on a maven repo? If so that sounds like a pretty
damning indictment of maven.
RG
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Daniel Kulp <da...@iona.com>.
I'll jump in now... :-)
On Wednesday 03 October 2007, Rafael Schloming wrote:
> Robert Greig wrote:
> > On 03/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
> >> I think the following has come out of this thread.. (my view)
> >>
> >> 1. we should make it a practice not to use snapshots
> >> 2. if we decide to use one - it should be the only option and with
> >> list agreement.
> >
> > I agree with these points.
>
> +1
+1 - though I'll add that if you decide to take a snapshot, you should
ALSO start immediately working with the team responsible to get a
release out ASAP. Part of the discussion to agree to take a snapshot
should include the timeframe that is expected to be on the snapshot.
> > I would also seriously question whether maven is actually the right
> > choice for this project.
>
> +1
>
One of the main points of using maven was to get artifacts into the
repositories in a way that other USERS can use them with their maven
builds. Since you haven't done a release, the artifacts aren't there.
Once you do the release (providing it's done properly) and actually
start getting users that want to integrate Qpid into their builds, this
starts becoming increasingly important.
For example, one of my JIRA tasks is to get CXF up and running using Qpid
as a transport:
https://issues.apache.org/jira/browse/CXF-318
Until there are release artifacts in the repo, I cannot accomplish that.
CXF is completely maven based and all the dependencies NEED to be in the
repo. That would include things like the mina jars that would have
whatever fixes you need in them. Those jars cannot live in SVN. They
would have to be in the repo as well. With you using maven, that is
currently enforced, and that's a good thing.
--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727 C: 508-380-7194
daniel.kulp@iona.com
http://www.dankulp.com/blog
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Rafael Schloming <ra...@redhat.com>.
Robert Greig wrote:
> On 03/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
>> I think the following has come out of this thread.. (my view)
>
>> 1. we should make it a practice not to use snapshots
>> 2. if we decide to use one - it should be the only option and with list
>> agreement.
>
> I agree with these points.
+1
> I would also seriously question whether maven is actually the right
> choice for this project.
+1
--Rafael
Re: Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Robert Greig <ro...@gmail.com>.
On 03/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
>
> I think the following has come out of this thread.. (my view)
> 1. we should make it a practice not to use snapshots
> 2. if we decide to use one - it should be the only option and with list
> agreement.
I agree with these points.
I would also seriously question whether maven is actually the right
choice for this project.
RG
Snapshots - was Re: [java]: compilation failure on M2 and trunk
Posted by Carl Trieloff <cc...@redhat.com>.
I think the following has come out of this thread.. (my view)
1. we should make it a practice not to use snapshots
2. if we decide to use one - it should be the only option and with list
agreement.
Carl.
Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
Rafael,
Good post about how Fedora uses Maven. I think you have made your point, and
I concede that we should remove all snapshots and not introduce any more, at
least not without very good reason and obtaining consent after discussing on
the list.
We too want repeatable builds. We don't want out customers to come to us
with a serious production problem and not be able to re-create their build
for a patch. Not that we ever do things like that ;)
Rupert
On 03/10/2007, Rafael Schloming <ra...@redhat.com> wrote:
>
> Rupert Smith wrote:
> > I think that the issue of snapshots can be graded into different
> degrees.
> > There are snapshots in the main build artefacts, in the test artefacts,
> and
> > in the build scripts themselves. Snapshots in the main artefacts being
> the
> > worst.
> >
> > However, I think that there are situations where even that could be
> > acceptable. A hypothetical example. Lets us suppose that we find a
> horrible
> > bug in say MINA. Its two weeks till the next MINA release, but the next
> Qpid
> > release is certainly going to be months away, the code base is heavily
> under
> > development. The MINA bug is holding development up, so we temporarily
> pick
> > up a snapshot of it, create a JIRA on the forthcoming Qpid release to
> ensure
> > that the snapshot is resolved before the release. Do remember, that you
> can
> > also pin to a specific snapshot version by including the full snapshot
> > timestamp if needed, but that this still does not guarantee
> repeatability,
> > as snapshots are held outside the central repo, and their maintainers
> could
> > remove them at any time.
>
> I don't think this as a particularly realistic situation. I'm finding it
> hard to imagine what kind of MINA bug would occur that is low enough
> priority for MINA developers to wait months to release a fix for, and
> yet severe enough to block all other forms of development on Qpid.
>
> The only similar scenario I can think of is the way security updates are
> handled by OS vendors since that is the one case where we truly can't
> wait for an upstream bug fix, however this wouldn't be a concern in your
> scenario.
>
> > One solution to the above, might be, that whenever a snapshot is used a
> copy
> > of the offending jar should be checked in the Apache svn, under a
> directory
> > that is set up as a local mvn repository on the build.
>
> The way OS vendors handle this when it truly can't be avoided is to use
> a patch against a well defined version of the source.
>
> --Rafael
>
Re: [java]: compilation failure on M2 and trunk
Posted by Rafael Schloming <ra...@redhat.com>.
Rupert Smith wrote:
> I think that the issue of snapshots can be graded into different degrees.
> There are snapshots in the main build artefacts, in the test artefacts, and
> in the build scripts themselves. Snapshots in the main artefacts being the
> worst.
>
> However, I think that there are situations where even that could be
> acceptable. A hypothetical example. Lets us suppose that we find a horrible
> bug in say MINA. Its two weeks till the next MINA release, but the next Qpid
> release is certainly going to be months away, the code base is heavily under
> development. The MINA bug is holding development up, so we temporarily pick
> up a snapshot of it, create a JIRA on the forthcoming Qpid release to ensure
> that the snapshot is resolved before the release. Do remember, that you can
> also pin to a specific snapshot version by including the full snapshot
> timestamp if needed, but that this still does not guarantee repeatability,
> as snapshots are held outside the central repo, and their maintainers could
> remove them at any time.
I don't think this as a particularly realistic situation. I'm finding it
hard to imagine what kind of MINA bug would occur that is low enough
priority for MINA developers to wait months to release a fix for, and
yet severe enough to block all other forms of development on Qpid.
The only similar scenario I can think of is the way security updates are
handled by OS vendors since that is the one case where we truly can't
wait for an upstream bug fix, however this wouldn't be a concern in your
scenario.
> One solution to the above, might be, that whenever a snapshot is used a copy
> of the offending jar should be checked in the Apache svn, under a directory
> that is set up as a local mvn repository on the build.
The way OS vendors handle this when it truly can't be avoided is to use
a patch against a well defined version of the source.
--Rafael
Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
I think that the issue of snapshots can be graded into different degrees.
There are snapshots in the main build artefacts, in the test artefacts, and
in the build scripts themselves. Snapshots in the main artefacts being the
worst.
However, I think that there are situations where even that could be
acceptable. A hypothetical example. Lets us suppose that we find a horrible
bug in say MINA. Its two weeks till the next MINA release, but the next Qpid
release is certainly going to be months away, the code base is heavily under
development. The MINA bug is holding development up, so we temporarily pick
up a snapshot of it, create a JIRA on the forthcoming Qpid release to ensure
that the snapshot is resolved before the release. Do remember, that you can
also pin to a specific snapshot version by including the full snapshot
timestamp if needed, but that this still does not guarantee repeatability,
as snapshots are held outside the central repo, and their maintainers could
remove them at any time.
One solution to the above, might be, that whenever a snapshot is used a copy
of the offending jar should be checked in the Apache svn, under a directory
that is set up as a local mvn repository on the build.
I think there has to be flexibility, as sometimes it is a question of
weighing up the situation.
On 02/10/2007, Rafael Schloming <ra...@redhat.com> wrote:
>
> 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.
>
Many of the build plugins that we currently use as snapshots, may now have
put out releases with the needed bug fixes in them. In which case we can now
resolve those snapshots. Being the least offending type of snapshot, no-one
has made this a priority to date.
Rupert
Re: [java]: compilation failure on M2 and trunk
Posted by Rafael Schloming <ra...@redhat.com>.
Martin Ritchie wrote:
> On 02/10/2007, Rafael Schloming <ra...@redhat.com> wrote:
>> 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.
>
> Can you please share what you know on "getting maven to produce
> repeatable builds".
> As far as I can tell the only truly reliable way is to, as Rupert
> said, do a clean install in to an empty repository and check that in
> to svn. You can then build in offline mode but I have seen occasions
> when this has failed to rebuild.
Fedora uses a patched version of maven in order to produce repeatable
builds. It is modified to never go online to get things (OS builds are
isolated from the network for security reasons), and sometimes maven
does even when -o is specified. It is also modified to bypass the maven
dependency resolution process entirely and build against the locally
installed system versions of all the dependencies. It looks in a
registry kept under /etc that maps maven groupId/artifactId/etc to
locally installed jar files.
All of this makes creating RPMs for mavenized software substantially
more difficult than other software since every mavenized package
installed needs to update the registry with all the various artifacts.
We've attempted to work with the maven community to make maven more
friendly for OS builds, however they were quite horrified that we were
bypassing their dependency resolution. Ironically they were concerned
that doing so damages the repeatability of their builds. In the end they
didn't have much interest in helping OS vendors package maven software.
Some of them even expressed the view that OSes are obselete now that the
JVM exists.
The upshot is that maven isn't very friendly to anything outside of
Java, and this is unfortunate because Java as a platform is really too
immature to have experienced the unscalable nature of some of the
practices that maven employs.
--Rafael
Re: [java]: compilation failure on M2 and trunk
Posted by Martin Ritchie <ri...@apache.org>.
On 02/10/2007, Rafael Schloming <ra...@redhat.com> wrote:
> 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.
Can you please share what you know on "getting maven to produce
repeatable builds".
As far as I can tell the only truly reliable way is to, as Rupert
said, do a clean install in to an empty repository and check that in
to svn. You can then build in offline mode but I have seen occasions
when this has failed to rebuild.
> > 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 <ru...@googlemail.com> wrote:
> >> Although, I do agree with you that is a lot better not to use SNAPSHOTs.
> >>
> >> On 02/10/2007, Rupert Smith <rupertlssmith@googlemail.com > 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 <ra...@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
> >>>> 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 <gs...@redhat.com> 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
> >>>>>>>>>>>>>
> >>>
> >
>
--
Martin Ritchie
Re: [java]: compilation failure on M2 and trunk
Posted by Rafael Schloming <ra...@redhat.com>.
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 <ru...@googlemail.com> wrote:
>> Although, I do agree with you that is a lot better not to use SNAPSHOTs.
>>
>> On 02/10/2007, Rupert Smith <rupertlssmith@googlemail.com > 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 <ra...@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
>>>> 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 <gs...@redhat.com> 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
>>>>>>>>>>>>>
>>>
>
Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
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.
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.
Again, sorry about the build failures on the junit toolkit. 0.6 version will
remedy the issue.
On 02/10/2007, Rupert Smith <ru...@googlemail.com> wrote:
>
> Although, I do agree with you that is a lot better not to use SNAPSHOTs.
>
> On 02/10/2007, Rupert Smith <rupertlssmith@googlemail.com > 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 <ra...@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
> > > 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 <gs...@redhat.com> 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
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >
> > >
> >
> >
>
Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
Although, I do agree with you that is a lot better not to use SNAPSHOTs.
On 02/10/2007, Rupert Smith <ru...@googlemail.com> 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 <ra...@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
> > 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 <gs...@redhat.com> 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
> > >>>>>>>>>
> > >>>>>>>>>
> > >
> >
>
>
Re: [java]: compilation failure on M2 and trunk
Posted by Rafael Schloming <ra...@redhat.com>.
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.
--Rafael
> On 02/10/2007, Rafael Schloming <ra...@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 <ra...@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 <cc...@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 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 <gs...@redhat.com> 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
>>>>>>>>>>>
>>>>>>>>>>>
>
Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
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 <ra...@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 <ra...@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 <cc...@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 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 <gs...@redhat.com> 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
> >>>>>>>>>
> >>>>>>>>>
> >
>
Re: [java]: compilation failure on M2 and trunk
Posted by Rafael Schloming <ra...@redhat.com>.
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 <ra...@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 <cc...@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 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 <gs...@redhat.com> 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
>>>>>>>>>
>>>>>>>>>
>
Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
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.
Rupert
On 02/10/2007, Rafael Schloming <ra...@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 <cc...@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 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 <gs...@redhat.com> 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
> >>>>>>>
> >>>>>>>
> >>
> >
>
Re: [java]: compilation failure on M2 and trunk
Posted by Rafael Schloming <ra...@redhat.com>.
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 <cc...@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 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 <gs...@redhat.com> 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
>>>>>>>
>>>>>>>
>>
>
Re: [java]: compilation failure on M2 and trunk
Posted by Rupert Smith <ru...@googlemail.com>.
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.
Rupert
On 01/10/2007, Carl Trieloff <cc...@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 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 <gs...@redhat.com> 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
> >>>>>
> >>>>>
> >>>>
>
>
Re: [java]: compilation failure on M2 and trunk
Posted by Carl Trieloff <cc...@redhat.com>.
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 <gs...@redhat.com> 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
>>>>>
>>>>>
>>>>
Re: [java]: compilation failure on M2 and trunk
Posted by Rafael Schloming <ra...@redhat.com>.
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 <gs...@redhat.com> 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
>>>>
>>>>
>>>
Re: [java]: compilation failure on M2 and trunk
Posted by Rafael Schloming <ra...@redhat.com>.
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 <gs...@redhat.com> 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
>>>
>>>
>>
Re: House keeping...
Posted by Carl Trieloff <cc...@redhat.com>.
ack,
If we are still clean - let's cut RC's Friday and restart the vote
Monday if all goes well
Carl.
Robert Godfrey wrote:
> I don't think there's a high chance... I'll be running the unit tests
> in a loop from now on... We'll set up some other tests as well... I
> think cutting the RC's now is ok, but we won't be in a position to
> vote until we're satisfied there's no more failures... probably the
> start of next week...
>
> -- Rob
>
> On 03/10/2007, *Carl Trieloff* <cctrieloff@redhat.com
> <ma...@redhat.com>> wrote:
>
>
> given that, should we go ahead and create the RC's + check them.
> That will take a few days so we are ready to vote
> if all goes well.
>
> Unless you think there is a high chance of issues coming out of
> the build.
>
> Carl.
>
>
>
> Robert Godfrey wrote:
>> We think we are good now, but we are now wanting to run tests
>> solidly for a few days to make sure there are no more issues.
>>
>> If we can go through that without any failures then we'll be able
>> to vote for a release.
>>
>> Rob
>>
>> On 03/10/2007, *Carl Trieloff* <cctrieloff@redhat.com
>> <ma...@redhat.com>> wrote:
>>
>>
>> Are we then ready to create a new set of M2 RC?
>>
>> Carl.
>>
>>
>> Rupert Smith wrote:
>> > I may have thought that to begin with, but then realized I
>> had searched for
>> > usages of Iterator.remove(), and not specifically
>> > IdentityHashMap.Iterator.remove().
>> >
>> > On 02/10/2007, Robert Greig <robert.j.greig@gmail.com
>> <ma...@gmail.com>> wrote:
>> >
>> >> On 02/10/2007, Rupert Smith < rupertlssmith@googlemail.com
>> <ma...@googlemail.com>> wrote:
>> >>
>> >>> BTW The Qpid code does not call
>> IdentityHashMap.Iterator.remove(), which
>> >>>
>> >> is
>> >>
>> >>> the source of the problem. So it is probably ok, even so,
>> a HashMap
>> >>>
>> >> might be
>> >>
>> >>> safer.
>> >>>
>> >> Ah, I thought someone had told me that it was removing
>> items in an
>> >> iterator. Must have picked up the wrong end of the stick.
>> >>
>> >> RG
>> >>
>> >>
>> >
>> >
>>
>>
>
>
Re: House keeping...
Posted by Robert Godfrey <ro...@gmail.com>.
I don't think there's a high chance... I'll be running the unit tests in a
loop from now on... We'll set up some other tests as well... I think cutting
the RC's now is ok, but we won't be in a position to vote until we're
satisfied there's no more failures... probably the start of next week...
-- Rob
On 03/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
>
>
> given that, should we go ahead and create the RC's + check them. That will
> take a few days so we are ready to vote
> if all goes well.
>
> Unless you think there is a high chance of issues coming out of the build.
>
> Carl.
>
>
> Robert Godfrey wrote:
>
> We think we are good now, but we are now wanting to run tests solidly for
> a few days to make sure there are no more issues.
>
> If we can go through that without any failures then we'll be able to vote
> for a release.
>
> Rob
>
> On 03/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
> >
> >
> > Are we then ready to create a new set of M2 RC?
> >
> > Carl.
> >
> >
> > Rupert Smith wrote:
> > > I may have thought that to begin with, but then realized I had
> > searched for
> > > usages of Iterator.remove(), and not specifically
> > > IdentityHashMap.Iterator.remove().
> > >
> > > On 02/10/2007, Robert Greig <ro...@gmail.com> wrote:
> > >
> > >> On 02/10/2007, Rupert Smith < rupertlssmith@googlemail.com> wrote:
> > >>
> > >>> BTW The Qpid code does not call IdentityHashMap.Iterator.remove(),
> > which
> > >>>
> > >> is
> > >>
> > >>> the source of the problem. So it is probably ok, even so, a HashMap
> > >>>
> > >> might be
> > >>
> > >>> safer.
> > >>>
> > >> Ah, I thought someone had told me that it was removing items in an
> > >> iterator. Must have picked up the wrong end of the stick.
> > >>
> > >> RG
> > >>
> > >>
> > >
> > >
> >
> >
>
>
Re: House keeping...
Posted by Carl Trieloff <cc...@redhat.com>.
given that, should we go ahead and create the RC's + check them. That
will take a few days so we are ready to vote
if all goes well.
Unless you think there is a high chance of issues coming out of the build.
Carl.
Robert Godfrey wrote:
> We think we are good now, but we are now wanting to run tests solidly
> for a few days to make sure there are no more issues.
>
> If we can go through that without any failures then we'll be able to
> vote for a release.
>
> Rob
>
> On 03/10/2007, *Carl Trieloff* <cctrieloff@redhat.com
> <ma...@redhat.com>> wrote:
>
>
> Are we then ready to create a new set of M2 RC?
>
> Carl.
>
>
> Rupert Smith wrote:
> > I may have thought that to begin with, but then realized I had
> searched for
> > usages of Iterator.remove(), and not specifically
> > IdentityHashMap.Iterator.remove().
> >
> > On 02/10/2007, Robert Greig <robert.j.greig@gmail.com
> <ma...@gmail.com>> wrote:
> >
> >> On 02/10/2007, Rupert Smith < rupertlssmith@googlemail.com
> <ma...@googlemail.com>> wrote:
> >>
> >>> BTW The Qpid code does not call
> IdentityHashMap.Iterator.remove(), which
> >>>
> >> is
> >>
> >>> the source of the problem. So it is probably ok, even so, a
> HashMap
> >>>
> >> might be
> >>
> >>> safer.
> >>>
> >> Ah, I thought someone had told me that it was removing items in an
> >> iterator. Must have picked up the wrong end of the stick.
> >>
> >> RG
> >>
> >>
> >
> >
>
>
Re: House keeping...
Posted by Robert Godfrey <ro...@gmail.com>.
We think we are good now, but we are now wanting to run tests solidly for a
few days to make sure there are no more issues.
If we can go through that without any failures then we'll be able to vote
for a release.
Rob
On 03/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
>
>
> Are we then ready to create a new set of M2 RC?
>
> Carl.
>
>
> Rupert Smith wrote:
> > I may have thought that to begin with, but then realized I had searched
> for
> > usages of Iterator.remove(), and not specifically
> > IdentityHashMap.Iterator.remove().
> >
> > On 02/10/2007, Robert Greig <ro...@gmail.com> wrote:
> >
> >> On 02/10/2007, Rupert Smith <ru...@googlemail.com> wrote:
> >>
> >>> BTW The Qpid code does not call IdentityHashMap.Iterator.remove(),
> which
> >>>
> >> is
> >>
> >>> the source of the problem. So it is probably ok, even so, a HashMap
> >>>
> >> might be
> >>
> >>> safer.
> >>>
> >> Ah, I thought someone had told me that it was removing items in an
> >> iterator. Must have picked up the wrong end of the stick.
> >>
> >> RG
> >>
> >>
> >
> >
>
>
Re: House keeping...
Posted by Carl Trieloff <cc...@redhat.com>.
Are we then ready to create a new set of M2 RC?
Carl.
Rupert Smith wrote:
> I may have thought that to begin with, but then realized I had searched for
> usages of Iterator.remove(), and not specifically
> IdentityHashMap.Iterator.remove().
>
> On 02/10/2007, Robert Greig <ro...@gmail.com> wrote:
>
>> On 02/10/2007, Rupert Smith <ru...@googlemail.com> wrote:
>>
>>> BTW The Qpid code does not call IdentityHashMap.Iterator.remove(), which
>>>
>> is
>>
>>> the source of the problem. So it is probably ok, even so, a HashMap
>>>
>> might be
>>
>>> safer.
>>>
>> Ah, I thought someone had told me that it was removing items in an
>> iterator. Must have picked up the wrong end of the stick.
>>
>> RG
>>
>>
>
>
Re: House keeping...
Posted by Rupert Smith <ru...@googlemail.com>.
I may have thought that to begin with, but then realized I had searched for
usages of Iterator.remove(), and not specifically
IdentityHashMap.Iterator.remove().
On 02/10/2007, Robert Greig <ro...@gmail.com> wrote:
>
> On 02/10/2007, Rupert Smith <ru...@googlemail.com> wrote:
> > BTW The Qpid code does not call IdentityHashMap.Iterator.remove(), which
> is
> > the source of the problem. So it is probably ok, even so, a HashMap
> might be
> > safer.
>
> Ah, I thought someone had told me that it was removing items in an
> iterator. Must have picked up the wrong end of the stick.
>
> RG
>
Re: House keeping...
Posted by Robert Greig <ro...@gmail.com>.
On 02/10/2007, Rupert Smith <ru...@googlemail.com> wrote:
> BTW The Qpid code does not call IdentityHashMap.Iterator.remove(), which is
> the source of the problem. So it is probably ok, even so, a HashMap might be
> safer.
Ah, I thought someone had told me that it was removing items in an
iterator. Must have picked up the wrong end of the stick.
RG
Re: House keeping...
Posted by Rupert Smith <ru...@googlemail.com>.
BTW The Qpid code does not call IdentityHashMap.Iterator.remove(), which is
the source of the problem. So it is probably ok, even so, a HashMap might be
safer.
On 02/10/2007, Robert Godfrey <ro...@gmail.com> wrote:
>
> From our side what we want to do with the Java is have all the remaining
> M2
> JIRAs closed (which we believe will be done by the end of today) and then
> just have the tests run in a continuous loop for a couple of days to
> satisfy
> ourselves that there are no remaining race conditions.
>
> -- Rob
>
> On 01/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
> >
> >
> > Thanks for the update.
> > Carl.
> >
> > Robert Greig wrote:
> > > On 01/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
> > >
> > >> Where are we in relation to cutting a new M2 release?
> > >>
> > >
> > > We are, we believe, very close.
> > >
> > > You will not believe this but we have found a bug in
> > > java.util.IdentityHashMap which was the cause of one of the hangs that
> > > we see periodically. Unfortunately the IdentityHashMap is used in a
> > > MINA class.
> > >
> > > We have a reproducible isolated test case and I am going to raise it
> > > with Sun but obviously in this case we are going to look for a
> > > workaround. There is no semantic need to use an IdentityHashMap and
> > > regular HashMap does not exhibit this bug so we should be able to
> > > apply a workaround in our code. We also found usage of IdentityHashMap
> > > in a similar situation in the Qpid code which we are going to
> > > remediate too.
> > >
> > > I'll send another update tomorrow morning UK time, also detailing any
> > > other jiras that are remaining (I know a good number got updated
> > > today).
> > >
> > > RG
> > >
> >
> >
>
Re: House keeping...
Posted by Robert Godfrey <ro...@gmail.com>.
>From our side what we want to do with the Java is have all the remaining M2
JIRAs closed (which we believe will be done by the end of today) and then
just have the tests run in a continuous loop for a couple of days to satisfy
ourselves that there are no remaining race conditions.
-- Rob
On 01/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
>
>
> Thanks for the update.
> Carl.
>
> Robert Greig wrote:
> > On 01/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
> >
> >> Where are we in relation to cutting a new M2 release?
> >>
> >
> > We are, we believe, very close.
> >
> > You will not believe this but we have found a bug in
> > java.util.IdentityHashMap which was the cause of one of the hangs that
> > we see periodically. Unfortunately the IdentityHashMap is used in a
> > MINA class.
> >
> > We have a reproducible isolated test case and I am going to raise it
> > with Sun but obviously in this case we are going to look for a
> > workaround. There is no semantic need to use an IdentityHashMap and
> > regular HashMap does not exhibit this bug so we should be able to
> > apply a workaround in our code. We also found usage of IdentityHashMap
> > in a similar situation in the Qpid code which we are going to
> > remediate too.
> >
> > I'll send another update tomorrow morning UK time, also detailing any
> > other jiras that are remaining (I know a good number got updated
> > today).
> >
> > RG
> >
>
>
Re: House keeping...
Posted by Carl Trieloff <cc...@redhat.com>.
Thanks for the update.
Carl.
Robert Greig wrote:
> On 01/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
>
>> Where are we in relation to cutting a new M2 release?
>>
>
> We are, we believe, very close.
>
> You will not believe this but we have found a bug in
> java.util.IdentityHashMap which was the cause of one of the hangs that
> we see periodically. Unfortunately the IdentityHashMap is used in a
> MINA class.
>
> We have a reproducible isolated test case and I am going to raise it
> with Sun but obviously in this case we are going to look for a
> workaround. There is no semantic need to use an IdentityHashMap and
> regular HashMap does not exhibit this bug so we should be able to
> apply a workaround in our code. We also found usage of IdentityHashMap
> in a similar situation in the Qpid code which we are going to
> remediate too.
>
> I'll send another update tomorrow morning UK time, also detailing any
> other jiras that are remaining (I know a good number got updated
> today).
>
> RG
>
Re: House keeping...
Posted by Robert Greig <ro...@gmail.com>.
On 01/10/2007, Carl Trieloff <cc...@redhat.com> wrote:
>
> Where are we in relation to cutting a new M2 release?
We are, we believe, very close.
You will not believe this but we have found a bug in
java.util.IdentityHashMap which was the cause of one of the hangs that
we see periodically. Unfortunately the IdentityHashMap is used in a
MINA class.
We have a reproducible isolated test case and I am going to raise it
with Sun but obviously in this case we are going to look for a
workaround. There is no semantic need to use an IdentityHashMap and
regular HashMap does not exhibit this bug so we should be able to
apply a workaround in our code. We also found usage of IdentityHashMap
in a similar situation in the Qpid code which we are going to
remediate too.
I'll send another update tomorrow morning UK time, also detailing any
other jiras that are remaining (I know a good number got updated
today).
RG
House keeping...
Posted by Carl Trieloff <cc...@redhat.com>.
Where are we in relation to cutting a new M2 release?
Carl.