Hey Lukas,
good points
Am 12.02.2013 um 08:24 schrieb Lukas Krejci:
While technically, I think we have most of the questions answered
thanks to
your work, Heiko, I think a couple of questions still have to be answered.
1) If we are going to split plugins and helpers from the core RHQ, how is it
going to affect versioning?
My proposal is that they work against a *stable* version of RHQ core.
E.g. the current 4.6-snapshot stream would work against 4.5.1 artifacts.
If the plugins need a newer version of modules/core, we would build
a new stable version of that and publish to central.
The important point here is that those modules/core artifacts (and perhaps
also dependencies for server plugins) are available from central so that a
plugin developer does not need to add some jBoss repos to his setup
in order to be able to compile them.
Another possible, but imo less desirable alternative is to publish timed
snapshots ("versioned snapshots"?) to central. We should do that only
when relevant changes are made and not on a per run or nightly basis,
as this would just pollute cental (and would probably be rejected anyway).
same release cycle or is each plugin going to be versioned
separately? If they
were versioned separately, wouldn't it make more sense to have a repo per
plugin?
I think this is too much, as GITs version of "pull many repos into an
über-repo"
is less powerful than what we had with svn the old days. But you mention
an important point below: we should indeed define a core set of plugins
(platform, jmx, ... ) that could stay in the rhq-core repository.
2) Our goal is to improve the situation of the plugin writers so that
they
don't have to check out the whole codebase before they can write their own
plugin (which they don't have to do even today). How is the split of the
plugins going to help them? They can depend on a released plugin-api artifact
and create their plugin in a complete separation from the rest of the
codebase.
Yes, that is the idea. To reiterate what I said above, it is important to create
dependencies that can be made available on maven central, so that users
don't have to first modify settings.xml or do other tricks to get this going.
Yes, one could add the JBoss-nexus to the plugin poms, but I doubt that
the JBoss nexus would be happy with snapshots after each little checkin
somewhere in our code base.
I personally was a proponent of a more granular split to even more
repositories than just plugins, helpers and the rest. But since then I've come
to the realization that what I really meant was more loose versioning scheme
of the individual components inside RHQ - and this does not necessarily
require standalone repositories - those would only make the "point" of
separate release cycles stronger.
In an ideal world we would split out modules/core into its own repo
and have the other repos depend on stable versions of modules/core
But again, as git does not handle pulling from many repos into one
über-repo that well, I don't think that is really desirable from the workflow.
The helpers depend on modules/core but other than that are pretty
loosely coupled with RHQ, so that the versioning is less of an issue there.
So in another words I think we need only a basic idea about our future
versioning strategy for at least the plugins that just call for individual
release cycles. Once we have this (rather philosphical) question answered, I
don't think there is much that holds us back from the move. It'll be just a
tedious excercise in flipping all our dev environments, CI jobs and various
other internal Red Hat tools to use the new URLs.
For the dev environments, I'd say that people push what they have to FH
and then after the migration clone the new GH repo into a different
directory. This allows to still fetch from the local clone of the FH repo (e.g.
for work in branches).
(Btw. what about the platform plugin? Shouldn't that be really part of the
core? I know that people can roll their own but how many do that? And given
the fact that none of the other plugins would be functional without platform,
wouldn't it be more logical to have the platform plugin as part of the core?)
Cheers,
Lukas
On Monday, February 11, 2013 17:22:17 Heiko W.Rupp wrote:
> John,
>
> very good question.
>
> Am 11.02.2013 um 17:01 schrieb John Sanda:
>> Where do we stand with respect to the github migration? What outstanding
>> tasks are left before we can pull the trigger? Given that we have various
>> RHQ and JON releases in flight, when is the best time to make the move?
> Actually I think we have an almost perfect timing now. Perhaps get RHQ 4.6
> out of the door and then after this, migrate over. This leaves us enough
> time for RHQ 4.7 and the next JON release.
>
> I think we should when doing that
>
> split off
>
> - plugins
> and
> - helpers except rtfilter*
>
> Heiko
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham, Charles Cachera