You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shindig.apache.org by Ben Smith <be...@gmail.com> on 2009/02/10 13:40:26 UTC
Samples project keeps breaking
Hi all,
I seem to be spending every Tuesday morning providing patches to fix
the Shindig Java 'samples' project. This is because it is not included
by the parent pom.xml and is therefore rarely built by committers. The
patch in question today is SHINDIG-908.
In the short term, I'd really appreciate it if committers could make
sure they run 'mvn clean install -Pall,samples' before they check-in.
A long-term strategy needs to be decided by the community for the
samples project. Ian's done a really good job providing a JPA
implementation of a persistence layer, and Chico and I have found it
to be very useful in the development of the BBC-specific persistence
layer (and have supplied a fair amount of additional code). However,
it is only useful if it is kept up-to-speed with the rest of the code-
base and would really benefit from being part of the default build,
even if it isn't then depended on.
Let me know what you think,
Ben Smith
BBC
Re: Samples project keeps breaking
Posted by Chris Chabot <ch...@google.com>.
I'm working on some 0.9 items that once they land on the trunk, will pretty
much break everything and not be consumption ready at all .... so if
anything from that perspective I would *love* to see a 1.0 release (and I
think on the java end of things, the same thing is going on by the sound of
it).
On Tue, Feb 10, 2009 at 2:14 PM, Ian Boston <ie...@tfd.co.uk> wrote:
> The samples project was originally put there for 2 reasons.
> 1. To let us know when SPI API's had changed so that we would be aware of
> breakages downstream to a user of shindig...
> 2. To provide a sample implementation beyond the Json DB sample that is
> used for building.
>
> Although it would be great for the samples project to become part of the
> normal build there is tension.
>
> The are so many tests, and the tests consume a significant amount of time
> for a build that probably make inclusion unattractive to anyone doing a lot
> of work on shindig,
>
> Fixing the implementation my not be trivial for changes to the SPI.
>
> One approach could be to segment the unit tests into SPI validation and
> integration tests. The integration tests only run under a profile.
>
> How do others feel about this ?
>
> There is a second issue that this brings up... the 1.0 release.. which we
> never did.
> It might be that users of shindig are only binding to trunk because there
> is no release for them to take ?
> As we get closer to a real 0.9 drive, I think that trunk is going to become
> wild west for a while, not a place where those close to production will want
> to bind to.
>
> WDYT?
>
> Ian
>
>
>
>
> On 10 Feb 2009, at 12:40, Ben Smith wrote:
>
> Hi all,
>>
>> I seem to be spending every Tuesday morning providing patches to fix the
>> Shindig Java 'samples' project. This is because it is not included by the
>> parent pom.xml and is therefore rarely built by committers. The patch in
>> question today is SHINDIG-908.
>>
>> In the short term, I'd really appreciate it if committers could make sure
>> they run 'mvn clean install -Pall,samples' before they check-in. A long-term
>> strategy needs to be decided by the community for the samples project. Ian's
>> done a really good job providing a JPA implementation of a persistence
>> layer, and Chico and I have found it to be very useful in the development of
>> the BBC-specific persistence layer (and have supplied a fair amount of
>> additional code). However, it is only useful if it is kept up-to-speed with
>> the rest of the code-base and would really benefit from being part of the
>> default build, even if it isn't then depended on.
>>
>> Let me know what you think,
>>
>> Ben Smith
>> BBC
>>
>
>
Re: Samples project keeps breaking
Posted by Louis Ryan <lr...@google.com>.
Committed last night
On Wed, Feb 11, 2009 at 1:34 AM, Ben Smith <be...@gmail.com> wrote:
> No worries. Would be good if someone committed it though: SHINDIG-908
> (nudge).
>
> Like I said, for the time being, it would be great if people just
> remembered to build using the 'samples' profile: -Pall,samples before
> committing.
>
> We've really found the samples project helpful and would like to find a
> good long-term strategy for how to maintain this and other useful examples.
>
>
>
> On 10 Feb 2009, at 17:32, Louis Ryan wrote:
>
> Ben,
>>
>> Thanks for the patch, I hope it wasnt to painful. Given that I'm the
>> guilty
>> party in this case I should have run the samples build given the nature of
>> my change. TBH its not something I've done before and I'm willing to bet
>> I've broken that build before so I'm guessing Ian and co. have just been
>> backfilling.
>>
>> Personally I dont mind if the samples build take a little extra time but
>> Ians point about tension is a valid one and there will very likely be
>> times
>> where we break the samples on trunk intentionally for limited periods.
>> Adding a 'mvn everything' shortcut also seems like a good idea.
>>
>> @Ian - Agreed that the 1.0 release needs a push. Im personally loaded with
>> 0.9 related commitments for the next week or so but I should have some
>> time
>> after that.
>>
>> -Louis
>>
>>
>>
>> On Tue, Feb 10, 2009 at 5:14 AM, Ian Boston <ie...@tfd.co.uk> wrote:
>>
>> The samples project was originally put there for 2 reasons.
>>> 1. To let us know when SPI API's had changed so that we would be aware of
>>> breakages downstream to a user of shindig...
>>> 2. To provide a sample implementation beyond the Json DB sample that is
>>> used for building.
>>>
>>> Although it would be great for the samples project to become part of the
>>> normal build there is tension.
>>>
>>> The are so many tests, and the tests consume a significant amount of time
>>> for a build that probably make inclusion unattractive to anyone doing a
>>> lot
>>> of work on shindig,
>>>
>>> Fixing the implementation my not be trivial for changes to the SPI.
>>>
>>> One approach could be to segment the unit tests into SPI validation and
>>> integration tests. The integration tests only run under a profile.
>>>
>>> How do others feel about this ?
>>>
>>> There is a second issue that this brings up... the 1.0 release.. which we
>>> never did.
>>> It might be that users of shindig are only binding to trunk because there
>>> is no release for them to take ?
>>> As we get closer to a real 0.9 drive, I think that trunk is going to
>>> become
>>> wild west for a while, not a place where those close to production will
>>> want
>>> to bind to.
>>>
>>> WDYT?
>>>
>>> Ian
>>>
>>>
>>>
>>>
>>> On 10 Feb 2009, at 12:40, Ben Smith wrote:
>>>
>>> Hi all,
>>>
>>>>
>>>> I seem to be spending every Tuesday morning providing patches to fix the
>>>> Shindig Java 'samples' project. This is because it is not included by
>>>> the
>>>> parent pom.xml and is therefore rarely built by committers. The patch in
>>>> question today is SHINDIG-908.
>>>>
>>>> In the short term, I'd really appreciate it if committers could make
>>>> sure
>>>> they run 'mvn clean install -Pall,samples' before they check-in. A
>>>> long-term
>>>> strategy needs to be decided by the community for the samples project.
>>>> Ian's
>>>> done a really good job providing a JPA implementation of a persistence
>>>> layer, and Chico and I have found it to be very useful in the
>>>> development of
>>>> the BBC-specific persistence layer (and have supplied a fair amount of
>>>> additional code). However, it is only useful if it is kept up-to-speed
>>>> with
>>>> the rest of the code-base and would really benefit from being part of
>>>> the
>>>> default build, even if it isn't then depended on.
>>>>
>>>> Let me know what you think,
>>>>
>>>> Ben Smith
>>>> BBC
>>>>
>>>>
>>>
>>>
>
Re: Samples project keeps breaking
Posted by Ben Smith <be...@gmail.com>.
No worries. Would be good if someone committed it though: SHINDIG-908
(nudge).
Like I said, for the time being, it would be great if people just
remembered to build using the 'samples' profile: -Pall,samples before
committing.
We've really found the samples project helpful and would like to find
a good long-term strategy for how to maintain this and other useful
examples.
On 10 Feb 2009, at 17:32, Louis Ryan wrote:
> Ben,
>
> Thanks for the patch, I hope it wasnt to painful. Given that I'm the
> guilty
> party in this case I should have run the samples build given the
> nature of
> my change. TBH its not something I've done before and I'm willing to
> bet
> I've broken that build before so I'm guessing Ian and co. have just
> been
> backfilling.
>
> Personally I dont mind if the samples build take a little extra time
> but
> Ians point about tension is a valid one and there will very likely
> be times
> where we break the samples on trunk intentionally for limited periods.
> Adding a 'mvn everything' shortcut also seems like a good idea.
>
> @Ian - Agreed that the 1.0 release needs a push. Im personally
> loaded with
> 0.9 related commitments for the next week or so but I should have
> some time
> after that.
>
> -Louis
>
>
>
> On Tue, Feb 10, 2009 at 5:14 AM, Ian Boston <ie...@tfd.co.uk> wrote:
>
>> The samples project was originally put there for 2 reasons.
>> 1. To let us know when SPI API's had changed so that we would be
>> aware of
>> breakages downstream to a user of shindig...
>> 2. To provide a sample implementation beyond the Json DB sample
>> that is
>> used for building.
>>
>> Although it would be great for the samples project to become part
>> of the
>> normal build there is tension.
>>
>> The are so many tests, and the tests consume a significant amount
>> of time
>> for a build that probably make inclusion unattractive to anyone
>> doing a lot
>> of work on shindig,
>>
>> Fixing the implementation my not be trivial for changes to the SPI.
>>
>> One approach could be to segment the unit tests into SPI validation
>> and
>> integration tests. The integration tests only run under a profile.
>>
>> How do others feel about this ?
>>
>> There is a second issue that this brings up... the 1.0 release..
>> which we
>> never did.
>> It might be that users of shindig are only binding to trunk because
>> there
>> is no release for them to take ?
>> As we get closer to a real 0.9 drive, I think that trunk is going
>> to become
>> wild west for a while, not a place where those close to production
>> will want
>> to bind to.
>>
>> WDYT?
>>
>> Ian
>>
>>
>>
>>
>> On 10 Feb 2009, at 12:40, Ben Smith wrote:
>>
>> Hi all,
>>>
>>> I seem to be spending every Tuesday morning providing patches to
>>> fix the
>>> Shindig Java 'samples' project. This is because it is not included
>>> by the
>>> parent pom.xml and is therefore rarely built by committers. The
>>> patch in
>>> question today is SHINDIG-908.
>>>
>>> In the short term, I'd really appreciate it if committers could
>>> make sure
>>> they run 'mvn clean install -Pall,samples' before they check-in. A
>>> long-term
>>> strategy needs to be decided by the community for the samples
>>> project. Ian's
>>> done a really good job providing a JPA implementation of a
>>> persistence
>>> layer, and Chico and I have found it to be very useful in the
>>> development of
>>> the BBC-specific persistence layer (and have supplied a fair
>>> amount of
>>> additional code). However, it is only useful if it is kept up-to-
>>> speed with
>>> the rest of the code-base and would really benefit from being part
>>> of the
>>> default build, even if it isn't then depended on.
>>>
>>> Let me know what you think,
>>>
>>> Ben Smith
>>> BBC
>>>
>>
>>
Re: Samples project keeps breaking
Posted by Louis Ryan <lr...@google.com>.
Ben,
Thanks for the patch, I hope it wasnt to painful. Given that I'm the guilty
party in this case I should have run the samples build given the nature of
my change. TBH its not something I've done before and I'm willing to bet
I've broken that build before so I'm guessing Ian and co. have just been
backfilling.
Personally I dont mind if the samples build take a little extra time but
Ians point about tension is a valid one and there will very likely be times
where we break the samples on trunk intentionally for limited periods.
Adding a 'mvn everything' shortcut also seems like a good idea.
@Ian - Agreed that the 1.0 release needs a push. Im personally loaded with
0.9 related commitments for the next week or so but I should have some time
after that.
-Louis
On Tue, Feb 10, 2009 at 5:14 AM, Ian Boston <ie...@tfd.co.uk> wrote:
> The samples project was originally put there for 2 reasons.
> 1. To let us know when SPI API's had changed so that we would be aware of
> breakages downstream to a user of shindig...
> 2. To provide a sample implementation beyond the Json DB sample that is
> used for building.
>
> Although it would be great for the samples project to become part of the
> normal build there is tension.
>
> The are so many tests, and the tests consume a significant amount of time
> for a build that probably make inclusion unattractive to anyone doing a lot
> of work on shindig,
>
> Fixing the implementation my not be trivial for changes to the SPI.
>
> One approach could be to segment the unit tests into SPI validation and
> integration tests. The integration tests only run under a profile.
>
> How do others feel about this ?
>
> There is a second issue that this brings up... the 1.0 release.. which we
> never did.
> It might be that users of shindig are only binding to trunk because there
> is no release for them to take ?
> As we get closer to a real 0.9 drive, I think that trunk is going to become
> wild west for a while, not a place where those close to production will want
> to bind to.
>
> WDYT?
>
> Ian
>
>
>
>
> On 10 Feb 2009, at 12:40, Ben Smith wrote:
>
> Hi all,
>>
>> I seem to be spending every Tuesday morning providing patches to fix the
>> Shindig Java 'samples' project. This is because it is not included by the
>> parent pom.xml and is therefore rarely built by committers. The patch in
>> question today is SHINDIG-908.
>>
>> In the short term, I'd really appreciate it if committers could make sure
>> they run 'mvn clean install -Pall,samples' before they check-in. A long-term
>> strategy needs to be decided by the community for the samples project. Ian's
>> done a really good job providing a JPA implementation of a persistence
>> layer, and Chico and I have found it to be very useful in the development of
>> the BBC-specific persistence layer (and have supplied a fair amount of
>> additional code). However, it is only useful if it is kept up-to-speed with
>> the rest of the code-base and would really benefit from being part of the
>> default build, even if it isn't then depended on.
>>
>> Let me know what you think,
>>
>> Ben Smith
>> BBC
>>
>
>
Re: Samples project keeps breaking
Posted by Ian Boston <ie...@tfd.co.uk>.
The samples project was originally put there for 2 reasons.
1. To let us know when SPI API's had changed so that we would be aware
of breakages downstream to a user of shindig...
2. To provide a sample implementation beyond the Json DB sample that
is used for building.
Although it would be great for the samples project to become part of
the normal build there is tension.
The are so many tests, and the tests consume a significant amount of
time for a build that probably make inclusion unattractive to anyone
doing a lot of work on shindig,
Fixing the implementation my not be trivial for changes to the SPI.
One approach could be to segment the unit tests into SPI validation
and integration tests. The integration tests only run under a profile.
How do others feel about this ?
There is a second issue that this brings up... the 1.0 release.. which
we never did.
It might be that users of shindig are only binding to trunk because
there is no release for them to take ?
As we get closer to a real 0.9 drive, I think that trunk is going to
become wild west for a while, not a place where those close to
production will want to bind to.
WDYT?
Ian
On 10 Feb 2009, at 12:40, Ben Smith wrote:
> Hi all,
>
> I seem to be spending every Tuesday morning providing patches to fix
> the Shindig Java 'samples' project. This is because it is not
> included by the parent pom.xml and is therefore rarely built by
> committers. The patch in question today is SHINDIG-908.
>
> In the short term, I'd really appreciate it if committers could make
> sure they run 'mvn clean install -Pall,samples' before they check-
> in. A long-term strategy needs to be decided by the community for
> the samples project. Ian's done a really good job providing a JPA
> implementation of a persistence layer, and Chico and I have found it
> to be very useful in the development of the BBC-specific persistence
> layer (and have supplied a fair amount of additional code). However,
> it is only useful if it is kept up-to-speed with the rest of the
> code-base and would really benefit from being part of the default
> build, even if it isn't then depended on.
>
> Let me know what you think,
>
> Ben Smith
> BBC