Stefan,
The part of the plan that concerns me is the version mismatch between
core and the other two repositories when it comes to master branch. I am thinking here for
the perspectives of the developer and a Jenkins build.
From a developer perspective, take the scenario where a BZ requires a concurrent fixes in
in the plugin repository and the core repositories. I just to not see how one can test
such fix easily. Having the HEAD of master branch of both repository on the local disk
would not be sufficient. So what would be workflow here?
I know that this is not too easy and totally see your point.
My motivation here is (and otherwise we would not need to discuss about splitting at
all):
a user / developer wishing to develop plugins must be able to
$ git clone
github.com/rhq-project/rhq-plugins
$ mvn install
without any issues in dependency resolving
We and contributors had issues for years because a potential contributor has to check out
a huge pile of sources,
run a build for a loooong time just to get at a point where the local env is suited to do
some plugin development.
Now from the perspective of a Jenkins build. Lets say the developers manages to write the
fix. How can we create a Jenkins build with the fix for QA?
How often in reality do we really make changes in modules/core/* for plugin changes?
I had a conversation with Thomas on Irc yesterday who was pointing out the same issue -
let me paste that in:
[21:33:59] <tsegismont> pilhuhn, you said we would not publish core/* and plugin/*
snapshots right?
[21:34:10] <tsegismont> after the split
[21:34:15] <@pilhuhn> yes
[21:34:55] <@pilhuhn> we may at the extreme publish a timed/dated snapshot as in
rhq-core-201302282134.jar
[21:35:07] <tsegismont> so what should i do then if, for example, i add some
methods to core API and want a plugin to use it?
[21:35:25] <@pilhuhn> But we need to make sure that users can at any time come in,
checkout rhq-plugins and build it
[21:35:35] <@pilhuhn> I've described that in the wiki
[21:35:48] <@pilhuhn> we may publish a datd snapshot
[21:36:03] <@pilhuhn> or just a new stable release for modules/core/* as in 4.6.1
[21:36:10] <tsegismont> ok
[21:36:43] <@pilhuhn> publishing -SNAPSHOT or per build -timed snapshots is not
going to work with the nexus repos at jboss and even less with central
[21:37:56] <tsegismont> what i fear is that we might be tempted in the future not
to change core api just to avoid to build a 4.6.1
[21:38:11] <@pilhuhn> Is that bad?
[21:38:14] <tsegismont> i mean, we will not be willing to do this for minor
changes
[21:39:06] <tsegismont> not sure how bad it is, let me give an example
[21:39:31] <@pilhuhn> We need to absolutely make sure that someone who has no
~/.m2/repository can clone rhq-plugins and then run mvn install and succeed
[21:43:44] <tsegismont> yes right
[21:45:48] <tsegismont> back to my example, last time i worked on a plugin, i had
to test a whether a String was blank or not. To avoid importing another commons i searched
core classes for a StringUtil but there was no method like i wanted. So added it (at the
benefit of all plugins) and used it in the plugin. Would you release a 4.6.1 for that?
[21:46:09] <tsegismont> had to test whether (-a)
[21:49:12] <@pilhuhn> It is the question in the sense that we may think a little
harder what we will change in the root of the dependency tree.
[21:49:35] <@pilhuhn> And yes, this may sound like a very small change and not
warrant a 4.6.1 version of modules/core
[21:49:57] <@pilhuhn> and then we may e.g batch up some of those changes
[21:50:07] <@pilhuhn> or indeed create a timed snapshot
[21:51:03] <@pilhuhn> But : we can not create a timed snapshot every night or on
every jenkins run of master, as this will not be accepted by repositories
Hope this makes it more clear
Heiko