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 <[email protected]> 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
