[infinispan-dev] Building the Infinispan Server

[Sanne Grinovero]

On 6 November 2013 18:58, Tristan Tarrant <ttarrant at redhat.com> wrote:
> On 11/06/2013 03:55 PM, Sanne Grinovero wrote:
>> Right I misread the error, sorry, but still it's a broken flow.
>>
>> Would be nice to have a build tool which knows how to build the whole
>> project without me going to hunt down 3 different repositories.
>> It was absurd enough to need to apply two pull requests on two
>> different repositories to resolve one JIRA (or actually to handle a
>> single pull request).
>> #fail
> The real fail is that you didn't send a PR with such a build tool :)

No offence, but if it doesn't build out of the box, I'm not going to touch it.

The contributor barrier is high enough that it doesn't need more overhead,
people not working fulltime on Infinispan can't handle this.

I'm not asking you to make a new tool but pointing out it was a
mistake to split out the project in many repositories, if there is an
assumption that this high level of coupling is acceptable.
Rather than splitting CacheStores out I'd have merged the server project.

It's certainly doable to have projects managed in different
repositories and having different lifecycles (like our other projects
do integrate with Infinispan), but there usually is no expectation of
keeping them aligned: we develop SPIs or APIs and make plans across
projects to handle this complexity: I had warned about this kind of
trouble when the split was suggested and am not particularly happy to
see that my most pessimistic views became a reality.

We can have separate repositories, but it needs to be managed
differently.
We'll have to make sure different pull requests are sent in the
correct order to each project, that issues are scheduled accordingly
on the independent release cycle of each component, and that tags are
released to Nexus to allow for developers to focus on one module at a
time: having "misaligned snapshots" is another source of confusion
that I could have had in this scenario.

Sanne