You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@activemq.apache.org by Justin Bertram <jb...@apache.org> on 2019/05/29 02:50:31 UTC
[DISCUSS] Component/Plugin repository
With the impending support for metrics plugins [1] as well as other
pluggable components which have been discussed in the past (e.g. Kafka
bridge [2] proposed by Mike Pearce) I think it would great to have an
official place where these things could be hosted and potentially included
as part of a broker release. Does anybody have any opinion on this?
Justin
[1] https://github.com/apache/activemq-artemis/pull/2681
[2] https://issues.apache.org/jira/browse/ARTEMIS-1478
Re: [DISCUSS] Component/Plugin repository
Posted by Clebert Suconic <cl...@gmail.com>.
I would start with a single repo for all the plugins we can add.
The way we are set now, a single git repo is a good way to start.
We can always revist and move a component out to its own repo later.
As for the day to day dev, discussions and adding components, this is
no different than what we have now.. Pull Requests will have
discussions associated with them.
On Mon, Jun 3, 2019 at 10:05 AM Robbie Gemmell <ro...@gmail.com> wrote:
>
> On Mon, 3 Jun 2019 at 14:24, Clebert Suconic <cl...@gmail.com> wrote:
> >
> > The question was in regard to spin new components? do we need a new vote to
> > start a new repository?
> >
>
> I dont believe we actually do need a vote, a lot of stuff doesn't,
> just establishing consensus on what is being done. Votes are one way
> of doing that so sometimes thats used all the time. Lazy concensus is
> another way. Making people clearly aware and giving chance to discuss
> things and agree a path is the important bit in most cases.
>
> I wouldnt expect a new component to pop up in a shared repo much
> differently than I'd expect a new specific repo to be established for
> it..i.e not without discussion and agreement on it occurring, ensuring
> its not a surprise to folks etc...likely stuff which cant happen any
> faster than the time to take a vote if folks feel that is actually
> needed.
>
> > Regarding the releases... we could release them altogether. Say...
> > ActiveMQ-Artemis-plugin 1.0
> >
> > Later on, when you add a new feature, you will have 1.1, 1.2... and
> > thereafter.
>
> Yep, and when one thing requires making a major/breaking change, then
> they all have to say that even though its not true (if the versions
> reflect that), and/or when most of the things havent changed at all
> folks get to wonder what changed in each bit. Made worse if a
> particular plugin ever wanted to support multiple streams, e.g support
> different major versions of <foo> being plugged in, or work with
> different major versions of Artemis. All of them have to be in a
> releasable state at exactly the same time. The build takes longer as
> more and more [unrelated] things are added. Etc.
>
> Less releases isnt necessarily an advantage.
>
> >
> > Say we changed something on the broker that will require update in all of
> > them/// we will need a lot of votes to go out.
> >
>
> Possibly, or that might be reason to do facilitate something more
> transitional so as to not to break them, which should maybe happen if
> its considered a supported plugin API. Presumably breaking them all
> 'deliberately' would be most likely to occur in a major broker
> release.
>
> Also worth considering that not everything need be part of the
> project. Not requiring that can even a good reason to have certain
> plugin points in the first place.
>
> >
> >
> >
> > On Mon, Jun 3, 2019 at 6:06 AM Robbie Gemmell <ro...@gmail.com>
> > wrote:
> >
> > > A vote would be required for each independently released thing, yes.
> > > That is true whether they are in specific repos or in an single repo
> > > but still released independently, so the only difference would come if
> > > releasing all plugins in that single repo as 'one thing'. That
> > > probably mean less releases, but likely also more complicated ones as
> > > grouping essentially indpendent bits into a single release tends to
> > > add its own challenges. That can tend to make them happen less often,
> > > and encourages them to be 'bigger' as folk stuff things in, which then
> > > makes them more complicated again, etc...
> > >
> > > Release votes dont need to be especially difficult. I've found the
> > > more targetted and/or regular they are, the easier doing them tends to
> > > become. I've run around 30 or so in the last year across a few
> > > components, but would have preferred to do more than I actually did.
> > >
> > > Robbie
> > >
> > > On Fri, 31 May 2019 at 20:12, Clebert Suconic <cl...@gmail.com>
> > > wrote:
> > > >
> > > > On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <ro...@gmail.com>
> > > wrote:
> > > > >
> > > > > I probably would do one each, yes. Its the easiest separation, keeps
> > > > > things independent and focused from the start and can avoid various
> > > > > hassles later.
> > > > >
> > > > > I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
> > > > > metrics), but really I dont personally see the benefits as outweighing
> > > > > the other things a lot of the time. I dont think anyone is charging us
> > > > > per repo.
> > > >
> > > > No, but does it require a vote each time we spin a new component?
> > > >
> > > >
> > > > >
> > > > > With a shared repo I guess you would just tag everything, or else
> > > > > start down the route of complications that also make individual repos
> > > > > seem nice. Could use Subversion, subdir tags were easy there :)
> > > > >
> > > > > (Aside, there is one project, ActiveMQ. These would be components).
> > > > >
> > > > > On Fri, 31 May 2019 at 17:24, Clebert Suconic <
> > > clebert.suconic@gmail.com> wrote:
> > > > > >
> > > > > > I agree with you, and that was my preference as well. I was trying to
> > > > > > understand if one git per component is what Robbie was suggesting.
> > > > > >
> > > > > > Although there's an issue though, when you have one super git for
> > > many
> > > > > > independent components, how would you tag releases?
> > > > > >
> > > > > > each fodler would be in fact an independent project, with no
> > > > > > correlation between the projects.
> > > > > >
> > > > > > On Fri, May 31, 2019 at 8:00 AM <mi...@me.com.invalid>
> > > wrote:
> > > > > > >
> > > > > > > I think one git repo per thing maybecome a bit too scattery. Id go
> > > for one repo with multiple modules.
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Get Outlook for Android
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <
> > > clebert.suconic@gmail.com> wrote:
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > I would put them outwith the broker repository. Not really
> > > because of
> > > > > > > > bloat, which was only a very small part of why I didnt think the
> > > > > > > > proposed Kafka Bridge should live inside the broker repo+package
> > > for
> > > > > > > > example, but thats certainly also something to keep in mind
> > > given the
> > > > > > > > build is pretty large/slow already.
> > > > > > > >
> > > > > > > > I wouldnt say a single plugin repository is necessarily a great
> > > idea,
> > > > > > > > it can tend to become a bit of a dumping ground for
> > > idea-of-the-week,
> > > > > > > > but the main thing for me would be that components should be
> > > > > > > > independently released if there were to be a bunch of optional
> > > > > > > > components with mostly unrelated functionality in the same place
> > > (e.g,
> > > > > > > > the ideas mentioned in this thread already seem mostly
> > > independent).
> > > > > > >
> > > > > > > So, what do you suggest? one gitRepo per plugin?
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Clebert Suconic
> > > >
> > > >
> > > >
> > > > --
> > > > Clebert Suconic
> > >
--
Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by Robbie Gemmell <ro...@gmail.com>.
On Mon, 3 Jun 2019 at 14:24, Clebert Suconic <cl...@gmail.com> wrote:
>
> The question was in regard to spin new components? do we need a new vote to
> start a new repository?
>
I dont believe we actually do need a vote, a lot of stuff doesn't,
just establishing consensus on what is being done. Votes are one way
of doing that so sometimes thats used all the time. Lazy concensus is
another way. Making people clearly aware and giving chance to discuss
things and agree a path is the important bit in most cases.
I wouldnt expect a new component to pop up in a shared repo much
differently than I'd expect a new specific repo to be established for
it..i.e not without discussion and agreement on it occurring, ensuring
its not a surprise to folks etc...likely stuff which cant happen any
faster than the time to take a vote if folks feel that is actually
needed.
> Regarding the releases... we could release them altogether. Say...
> ActiveMQ-Artemis-plugin 1.0
>
> Later on, when you add a new feature, you will have 1.1, 1.2... and
> thereafter.
Yep, and when one thing requires making a major/breaking change, then
they all have to say that even though its not true (if the versions
reflect that), and/or when most of the things havent changed at all
folks get to wonder what changed in each bit. Made worse if a
particular plugin ever wanted to support multiple streams, e.g support
different major versions of <foo> being plugged in, or work with
different major versions of Artemis. All of them have to be in a
releasable state at exactly the same time. The build takes longer as
more and more [unrelated] things are added. Etc.
Less releases isnt necessarily an advantage.
>
> Say we changed something on the broker that will require update in all of
> them/// we will need a lot of votes to go out.
>
Possibly, or that might be reason to do facilitate something more
transitional so as to not to break them, which should maybe happen if
its considered a supported plugin API. Presumably breaking them all
'deliberately' would be most likely to occur in a major broker
release.
Also worth considering that not everything need be part of the
project. Not requiring that can even a good reason to have certain
plugin points in the first place.
>
>
>
> On Mon, Jun 3, 2019 at 6:06 AM Robbie Gemmell <ro...@gmail.com>
> wrote:
>
> > A vote would be required for each independently released thing, yes.
> > That is true whether they are in specific repos or in an single repo
> > but still released independently, so the only difference would come if
> > releasing all plugins in that single repo as 'one thing'. That
> > probably mean less releases, but likely also more complicated ones as
> > grouping essentially indpendent bits into a single release tends to
> > add its own challenges. That can tend to make them happen less often,
> > and encourages them to be 'bigger' as folk stuff things in, which then
> > makes them more complicated again, etc...
> >
> > Release votes dont need to be especially difficult. I've found the
> > more targetted and/or regular they are, the easier doing them tends to
> > become. I've run around 30 or so in the last year across a few
> > components, but would have preferred to do more than I actually did.
> >
> > Robbie
> >
> > On Fri, 31 May 2019 at 20:12, Clebert Suconic <cl...@gmail.com>
> > wrote:
> > >
> > > On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <ro...@gmail.com>
> > wrote:
> > > >
> > > > I probably would do one each, yes. Its the easiest separation, keeps
> > > > things independent and focused from the start and can avoid various
> > > > hassles later.
> > > >
> > > > I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
> > > > metrics), but really I dont personally see the benefits as outweighing
> > > > the other things a lot of the time. I dont think anyone is charging us
> > > > per repo.
> > >
> > > No, but does it require a vote each time we spin a new component?
> > >
> > >
> > > >
> > > > With a shared repo I guess you would just tag everything, or else
> > > > start down the route of complications that also make individual repos
> > > > seem nice. Could use Subversion, subdir tags were easy there :)
> > > >
> > > > (Aside, there is one project, ActiveMQ. These would be components).
> > > >
> > > > On Fri, 31 May 2019 at 17:24, Clebert Suconic <
> > clebert.suconic@gmail.com> wrote:
> > > > >
> > > > > I agree with you, and that was my preference as well. I was trying to
> > > > > understand if one git per component is what Robbie was suggesting.
> > > > >
> > > > > Although there's an issue though, when you have one super git for
> > many
> > > > > independent components, how would you tag releases?
> > > > >
> > > > > each fodler would be in fact an independent project, with no
> > > > > correlation between the projects.
> > > > >
> > > > > On Fri, May 31, 2019 at 8:00 AM <mi...@me.com.invalid>
> > wrote:
> > > > > >
> > > > > > I think one git repo per thing maybecome a bit too scattery. Id go
> > for one repo with multiple modules.
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Get Outlook for Android
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <
> > clebert.suconic@gmail.com> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> > > > > > wrote:
> > > > > > >
> > > > > > > I would put them outwith the broker repository. Not really
> > because of
> > > > > > > bloat, which was only a very small part of why I didnt think the
> > > > > > > proposed Kafka Bridge should live inside the broker repo+package
> > for
> > > > > > > example, but thats certainly also something to keep in mind
> > given the
> > > > > > > build is pretty large/slow already.
> > > > > > >
> > > > > > > I wouldnt say a single plugin repository is necessarily a great
> > idea,
> > > > > > > it can tend to become a bit of a dumping ground for
> > idea-of-the-week,
> > > > > > > but the main thing for me would be that components should be
> > > > > > > independently released if there were to be a bunch of optional
> > > > > > > components with mostly unrelated functionality in the same place
> > (e.g,
> > > > > > > the ideas mentioned in this thread already seem mostly
> > independent).
> > > > > >
> > > > > > So, what do you suggest? one gitRepo per plugin?
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Clebert Suconic
> > >
> > >
> > >
> > > --
> > > Clebert Suconic
> >
Re: [DISCUSS] Component/Plugin repository
Posted by Robbie Gemmell <ro...@gmail.com>.
I think there is an element of difficulty in documenting precise
criteria for plugins, as to a certain extent what the plugin is (and
to smaller degree perhaps even what its implementation entails) could
influence how necessary or appropriate people think it is to be part
of this project, and might weigh against particular choices depending
on views on certain matters such as licensing (more below). I guess
thats precisely the type of uncertainty you are seeking to avoid, but
I'm not sure I see an easy path to do that in advance in an entirely
generic way.
The main things would seem to be general consensus from the PMC that
the plugin is something they think should be a component part of this
project as opposed to its own, and that there is clear support both
for maintaining and releasing it going forward. At least 3 binding
votes would be needed for it being released, so I'd expect that many
or preferably more to be in obvious support before it is established
as a plugin.
On plugins being shuffled off, I think with it now seeming individual
repositories is the preferred route this becomes even more similar to
any of the existing components such as the brokers or clients
themselves. If at some point it seems there is a lack of support
needed to continue maintaining and releasing a plugin, and releases
seem/are necessary but arent happening, then a discussion can be had
on their future. Maybe that prompts a revival of interest which is
good, or maybe its established that the plugin goes away at some
chosen point if things havent changed by then, or maybe that time has
been and gone an its shuffled off there and then.
On "Any third party dependency plugin including dependency to third
party client jar must be apache license approved. (E.g. we can have
plugin or extension for a closed source commerical tool)", am I right
to think the "we can have" was meant to be 'we cant have' or 'can we
have'? In general I'd say keeping things ASLv2 compatible is a good
idea, though per the recent "LICENSE ISSUE" thread optional
functionality can have Category X dependencies, and such plugins would
usually seem to fit that categorisation of optional. This would be a
choice for the PMC on what they want to permit, but is perhaps even a
bit of a 'is this particular plugin of benefit warranting that hassle'
balance, which per my opening can be hard to define up front - unless
for this specific case everything agrees now the answer is always that
its never warranted and those things must live elsewhere.
Robbie
On Mon, 3 Jun 2019 at 22:58, <mi...@me.com.invalid> wrote:
>
> I just want it clarified what will be the rules of adopting a new plugin or extension. Likewise the rule for archiving/killing off dead ones.
>
>
>
>
> And that is applied generically.
>
>
>
>
> E.g.
>
>
>
>
> At least one pmc member needs to sponsor (doesnt have to be the committer or contributor)
>
>
>
>
> Any third party dependency plugin including dependency to third party client jar must be apache license approved. (E.g. we can have plugin or extension for a closed source commerical tool)
>
>
>
>
>
>
> Just want the criteria decides agreed and documented up front to avoid less issues later on what can go in and what cant
>
>
>
>
> Get Outlook for Android
>
>
>
>
>
>
>
> On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <cl...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
>
> > All questions need to be same
>
> @Michael Pearce perhaps it's my english as second language here, but
> this to me sounded like "All your basis are belong to us" :)
>
> Can you explain what you meant here?
>
>
>
>
>
Re: [DISCUSS] Component/Plugin repository
Posted by Clebert Suconic <cl...@gmail.com>.
We can create a component on JIRA, and add JIRAs towards those
components. Same way that we do with native now.
On Thu, Jun 6, 2019 at 5:25 PM Michael André Pearce
<mi...@me.com.invalid> wrote:
>
> If we are going down the route of separate repos, are we going to have separate jira projects then for every plugin?
>
> Also just to be clear here we are talking about the
>
> promethius-plugin
> kafka-plugin
>
> currently? Or any others also?
>
> > On 4 Jun 2019, at 17:47, Clebert Suconic <cl...@gmail.com> wrote:
> >
> > Fair enough... one component per repo.
> >
> > On Tue, Jun 4, 2019 at 10:26 AM Timothy Bish <ta...@gmail.com> wrote:
> >>
> >> On 6/4/19 8:14 AM, Andy Taylor wrote:
> >>> Id personally pefer a single repo per plugin, some plugins will develop
> >>> quicker than others and with a single repo you would end up tagging and
> >>> releasing plugins that havent changed. I dont think there is an overhead
> >>> with using maven etc.
> >>
> >> Agreed, having each in its own repository running on its own release
> >> cycle would be my preferred option as well. A single large repository
> >> will tend to become harder to release as more things get dumped into it
> >> but not actively maintained. It is easier for the release validation if
> >> each is on its own as well, testing a release for a dozen different semi
> >> related components will likely drive down the quality of the review
> >> being done.
> >>
> >>
> >>>
> >>> I also think there should be no tight coupling between the plugin and the
> >>> broker apart from implementing a specific API that should be set in stone.
> >>> Even better would be the ability to just to drop a war or jar into the lib
> >>> dir and have it deployed automagically via annotations on the class or
> >>> method perhaps.
> >>>
> >>> On Mon, 3 Jun 2019 at 22:58, <mi...@me.com.invalid> wrote:
> >>>
> >>>> I just want it clarified what will be the rules of adopting a new plugin
> >>>> or extension. Likewise the rule for archiving/killing off dead ones.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> And that is applied generically.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> E.g.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> At least one pmc member needs to sponsor (doesnt have to be the committer
> >>>> or contributor)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Any third party dependency plugin including dependency to third party
> >>>> client jar must be apache license approved. (E.g. we can have plugin or
> >>>> extension for a closed source commerical tool)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Just want the criteria decides agreed and documented up front to avoid
> >>>> less issues later on what can go in and what cant
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Get Outlook for Android
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <
> >>>> clebert.suconic@gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> All questions need to be same
> >>>> @Michael Pearce perhaps it's my english as second language here, but
> >>>> this to me sounded like "All your basis are belong to us" :)
> >>>>
> >>>> Can you explain what you meant here?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >> --
> >> Tim Bish
> >>
> >
> >
> > --
> > Clebert Suconic
>
--
Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by Robbie Gemmell <ro...@gmail.com>.
There are groups that could be used to ease such things (though again,
its not difficult without) but infra seemed to explicitly move away
from using them in the past, I think as they needed to administer them
centrally with they didnt have bandwidth for. Perhaps some of that
might have changed.
On Mon, 10 Jun 2019 at 11:37, Christopher Shannon
<ch...@gmail.com> wrote:
>
> I went ahead and pinged Infra in the slack channel to see if there's
> anything we can do to control multiple project permissions together.
>
> On Mon, Jun 10, 2019 at 5:32 AM Robbie Gemmell <ro...@gmail.com>
> wrote:
>
> > I've not personally found it a big deal to manage rights across
> > multiple Jira projects, updates arent difficult. I do only manage 5
> > active Jira projects to be fair. Per the earlier link Maven look to
> > have around 70 though, so it certainly seems feasible to do a few
> > more. For me, not being able to get a rights update would just be
> > another metric to consider, going back to the earlier discussion
> > around removal for example.
> >
> > Dumping them all in to one JIRA project just to ease rights updates is
> > a tradeoff, one which I wouldnt make personally at the outset given
> > the choice, as having independently releasable stuff in the same JIRA
> > project can later be cumbersome in its own ways (some of the the ones
> > I manage have that, from previously being a single release that was
> > later split out to 2+). That why at the very least I would keep the
> > independent plugins seperate from the ARTEMIS JIRA project, but would
> > much prefer they just each had their own JIRA projects.
> >
> > Robbie
> >
> > On Sat, 8 Jun 2019 at 22:27, <mi...@me.com.invalid> wrote:
> > >
> > > So already it seems we have issues handling and maintaining rights for
> > users on the few jira projects we have.
> > >
> > >
> > >
> > >
> > > E.g. atm whilst Christopher S, sorted my activemq rights as pmc memebrt,
> > it seems no one has been able to sort the others artemis amqnet and amqcpp.
> > >
> > >
> > >
> > >
> > > As such it shows atm managing too many will just get worse. I think we
> > should avoid too much per project setup.
> > >
> > >
> > >
> > >
> > > Get Outlook for Android
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Fri, Jun 7, 2019 at 12:36 PM +0100, "Robbie Gemmell" <
> > robbie.gemmell@gmail.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On JIRA handling 3 main choices jump out for me, which I would do in
> > > this order (1 first) personally:
> > > 1) Create an individual JIRA project per plugin (e.g as Maven do:
> > >
> > https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=10510&selectedProjectType=all
> > )
> > > 2) Create a new 'artemis plugins' style agregate JIRA project, with
> > > 'component' per plugin and 'releases' for each separate plugin
> > > release.
> > > 3) Create a 'component' per plugin and add 'releases' for each
> > > separate plugin release, within the existing ARTEMIS JIRA project.
> > >
> > > Robbie
> > >
> > > On Thu, 6 Jun 2019 at 22:25, Michael André Pearce
> > > wrote:
> > > >
> > > > If we are going down the route of separate repos, are we going to have
> > separate jira projects then for every plugin?
> > > >
> > > > Also just to be clear here we are talking about the
> > > >
> > > > promethius-plugin
> > > > kafka-plugin
> > > >
> > > > currently? Or any others also?
> > > >
> > > > > On 4 Jun 2019, at 17:47, Clebert Suconic wrote:
> > > > >
> > > > > Fair enough... one component per repo.
> > > > >
> > > > > On Tue, Jun 4, 2019 at 10:26 AM Timothy Bish wrote:
> > > > >>
> > > > >> On 6/4/19 8:14 AM, Andy Taylor wrote:
> > > > >>> Id personally pefer a single repo per plugin, some plugins will
> > develop
> > > > >>> quicker than others and with a single repo you would end up
> > tagging and
> > > > >>> releasing plugins that havent changed. I dont think there is an
> > overhead
> > > > >>> with using maven etc.
> > > > >>
> > > > >> Agreed, having each in its own repository running on its own release
> > > > >> cycle would be my preferred option as well. A single large
> > repository
> > > > >> will tend to become harder to release as more things get dumped
> > into it
> > > > >> but not actively maintained. It is easier for the release
> > validation if
> > > > >> each is on its own as well, testing a release for a dozen different
> > semi
> > > > >> related components will likely drive down the quality of the review
> > > > >> being done.
> > > > >>
> > > > >>
> > > > >>>
> > > > >>> I also think there should be no tight coupling between the plugin
> > and the
> > > > >>> broker apart from implementing a specific API that should be set
> > in stone.
> > > > >>> Even better would be the ability to just to drop a war or jar
> > into the lib
> > > > >>> dir and have it deployed automagically via annotations on the
> > class or
> > > > >>> method perhaps.
> > > > >>>
> > > > >>> On Mon, 3 Jun 2019 at 22:58, wrote:
> > > > >>>
> > > > >>>> I just want it clarified what will be the rules of adopting a new
> > plugin
> > > > >>>> or extension. Likewise the rule for archiving/killing off dead
> > ones.
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> And that is applied generically.
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> E.g.
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> At least one pmc member needs to sponsor (doesnt have to be the
> > committer
> > > > >>>> or contributor)
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> Any third party dependency plugin including dependency to third
> > party
> > > > >>>> client jar must be apache license approved. (E.g. we can have
> > plugin or
> > > > >>>> extension for a closed source commerical tool)
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> Just want the criteria decides agreed and documented up front to
> > avoid
> > > > >>>> less issues later on what can go in and what cant
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> Get Outlook for Android
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <
> > > > >>>> clebert.suconic@gmail.com> wrote:
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>> All questions need to be same
> > > > >>>> @Michael Pearce perhaps it's my english as second language here,
> > but
> > > > >>>> this to me sounded like "All your basis are belong to us" :)
> > > > >>>>
> > > > >>>> Can you explain what you meant here?
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>
> > > > >> --
> > > > >> Tim Bish
> > > > >>
> > > > >
> > > > >
> > > > > --
> > > > > Clebert Suconic
> > > >
> > >
> > >
> > >
> > >
> > >
> >
Re: [DISCUSS] Component/Plugin repository
Posted by Christopher Shannon <ch...@gmail.com>.
I went ahead and pinged Infra in the slack channel to see if there's
anything we can do to control multiple project permissions together.
On Mon, Jun 10, 2019 at 5:32 AM Robbie Gemmell <ro...@gmail.com>
wrote:
> I've not personally found it a big deal to manage rights across
> multiple Jira projects, updates arent difficult. I do only manage 5
> active Jira projects to be fair. Per the earlier link Maven look to
> have around 70 though, so it certainly seems feasible to do a few
> more. For me, not being able to get a rights update would just be
> another metric to consider, going back to the earlier discussion
> around removal for example.
>
> Dumping them all in to one JIRA project just to ease rights updates is
> a tradeoff, one which I wouldnt make personally at the outset given
> the choice, as having independently releasable stuff in the same JIRA
> project can later be cumbersome in its own ways (some of the the ones
> I manage have that, from previously being a single release that was
> later split out to 2+). That why at the very least I would keep the
> independent plugins seperate from the ARTEMIS JIRA project, but would
> much prefer they just each had their own JIRA projects.
>
> Robbie
>
> On Sat, 8 Jun 2019 at 22:27, <mi...@me.com.invalid> wrote:
> >
> > So already it seems we have issues handling and maintaining rights for
> users on the few jira projects we have.
> >
> >
> >
> >
> > E.g. atm whilst Christopher S, sorted my activemq rights as pmc memebrt,
> it seems no one has been able to sort the others artemis amqnet and amqcpp.
> >
> >
> >
> >
> > As such it shows atm managing too many will just get worse. I think we
> should avoid too much per project setup.
> >
> >
> >
> >
> > Get Outlook for Android
> >
> >
> >
> >
> >
> >
> >
> > On Fri, Jun 7, 2019 at 12:36 PM +0100, "Robbie Gemmell" <
> robbie.gemmell@gmail.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On JIRA handling 3 main choices jump out for me, which I would do in
> > this order (1 first) personally:
> > 1) Create an individual JIRA project per plugin (e.g as Maven do:
> >
> https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=10510&selectedProjectType=all
> )
> > 2) Create a new 'artemis plugins' style agregate JIRA project, with
> > 'component' per plugin and 'releases' for each separate plugin
> > release.
> > 3) Create a 'component' per plugin and add 'releases' for each
> > separate plugin release, within the existing ARTEMIS JIRA project.
> >
> > Robbie
> >
> > On Thu, 6 Jun 2019 at 22:25, Michael André Pearce
> > wrote:
> > >
> > > If we are going down the route of separate repos, are we going to have
> separate jira projects then for every plugin?
> > >
> > > Also just to be clear here we are talking about the
> > >
> > > promethius-plugin
> > > kafka-plugin
> > >
> > > currently? Or any others also?
> > >
> > > > On 4 Jun 2019, at 17:47, Clebert Suconic wrote:
> > > >
> > > > Fair enough... one component per repo.
> > > >
> > > > On Tue, Jun 4, 2019 at 10:26 AM Timothy Bish wrote:
> > > >>
> > > >> On 6/4/19 8:14 AM, Andy Taylor wrote:
> > > >>> Id personally pefer a single repo per plugin, some plugins will
> develop
> > > >>> quicker than others and with a single repo you would end up
> tagging and
> > > >>> releasing plugins that havent changed. I dont think there is an
> overhead
> > > >>> with using maven etc.
> > > >>
> > > >> Agreed, having each in its own repository running on its own release
> > > >> cycle would be my preferred option as well. A single large
> repository
> > > >> will tend to become harder to release as more things get dumped
> into it
> > > >> but not actively maintained. It is easier for the release
> validation if
> > > >> each is on its own as well, testing a release for a dozen different
> semi
> > > >> related components will likely drive down the quality of the review
> > > >> being done.
> > > >>
> > > >>
> > > >>>
> > > >>> I also think there should be no tight coupling between the plugin
> and the
> > > >>> broker apart from implementing a specific API that should be set
> in stone.
> > > >>> Even better would be the ability to just to drop a war or jar
> into the lib
> > > >>> dir and have it deployed automagically via annotations on the
> class or
> > > >>> method perhaps.
> > > >>>
> > > >>> On Mon, 3 Jun 2019 at 22:58, wrote:
> > > >>>
> > > >>>> I just want it clarified what will be the rules of adopting a new
> plugin
> > > >>>> or extension. Likewise the rule for archiving/killing off dead
> ones.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> And that is applied generically.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> E.g.
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> At least one pmc member needs to sponsor (doesnt have to be the
> committer
> > > >>>> or contributor)
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> Any third party dependency plugin including dependency to third
> party
> > > >>>> client jar must be apache license approved. (E.g. we can have
> plugin or
> > > >>>> extension for a closed source commerical tool)
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> Just want the criteria decides agreed and documented up front to
> avoid
> > > >>>> less issues later on what can go in and what cant
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> Get Outlook for Android
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <
> > > >>>> clebert.suconic@gmail.com> wrote:
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>> All questions need to be same
> > > >>>> @Michael Pearce perhaps it's my english as second language here,
> but
> > > >>>> this to me sounded like "All your basis are belong to us" :)
> > > >>>>
> > > >>>> Can you explain what you meant here?
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>
> > > >> --
> > > >> Tim Bish
> > > >>
> > > >
> > > >
> > > > --
> > > > Clebert Suconic
> > >
> >
> >
> >
> >
> >
>
Re: [DISCUSS] Component/Plugin repository
Posted by Robbie Gemmell <ro...@gmail.com>.
I've not personally found it a big deal to manage rights across
multiple Jira projects, updates arent difficult. I do only manage 5
active Jira projects to be fair. Per the earlier link Maven look to
have around 70 though, so it certainly seems feasible to do a few
more. For me, not being able to get a rights update would just be
another metric to consider, going back to the earlier discussion
around removal for example.
Dumping them all in to one JIRA project just to ease rights updates is
a tradeoff, one which I wouldnt make personally at the outset given
the choice, as having independently releasable stuff in the same JIRA
project can later be cumbersome in its own ways (some of the the ones
I manage have that, from previously being a single release that was
later split out to 2+). That why at the very least I would keep the
independent plugins seperate from the ARTEMIS JIRA project, but would
much prefer they just each had their own JIRA projects.
Robbie
On Sat, 8 Jun 2019 at 22:27, <mi...@me.com.invalid> wrote:
>
> So already it seems we have issues handling and maintaining rights for users on the few jira projects we have.
>
>
>
>
> E.g. atm whilst Christopher S, sorted my activemq rights as pmc memebrt, it seems no one has been able to sort the others artemis amqnet and amqcpp.
>
>
>
>
> As such it shows atm managing too many will just get worse. I think we should avoid too much per project setup.
>
>
>
>
> Get Outlook for Android
>
>
>
>
>
>
>
> On Fri, Jun 7, 2019 at 12:36 PM +0100, "Robbie Gemmell" <ro...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
>
> On JIRA handling 3 main choices jump out for me, which I would do in
> this order (1 first) personally:
> 1) Create an individual JIRA project per plugin (e.g as Maven do:
> https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=10510&selectedProjectType=all)
> 2) Create a new 'artemis plugins' style agregate JIRA project, with
> 'component' per plugin and 'releases' for each separate plugin
> release.
> 3) Create a 'component' per plugin and add 'releases' for each
> separate plugin release, within the existing ARTEMIS JIRA project.
>
> Robbie
>
> On Thu, 6 Jun 2019 at 22:25, Michael André Pearce
> wrote:
> >
> > If we are going down the route of separate repos, are we going to have separate jira projects then for every plugin?
> >
> > Also just to be clear here we are talking about the
> >
> > promethius-plugin
> > kafka-plugin
> >
> > currently? Or any others also?
> >
> > > On 4 Jun 2019, at 17:47, Clebert Suconic wrote:
> > >
> > > Fair enough... one component per repo.
> > >
> > > On Tue, Jun 4, 2019 at 10:26 AM Timothy Bish wrote:
> > >>
> > >> On 6/4/19 8:14 AM, Andy Taylor wrote:
> > >>> Id personally pefer a single repo per plugin, some plugins will develop
> > >>> quicker than others and with a single repo you would end up tagging and
> > >>> releasing plugins that havent changed. I dont think there is an overhead
> > >>> with using maven etc.
> > >>
> > >> Agreed, having each in its own repository running on its own release
> > >> cycle would be my preferred option as well. A single large repository
> > >> will tend to become harder to release as more things get dumped into it
> > >> but not actively maintained. It is easier for the release validation if
> > >> each is on its own as well, testing a release for a dozen different semi
> > >> related components will likely drive down the quality of the review
> > >> being done.
> > >>
> > >>
> > >>>
> > >>> I also think there should be no tight coupling between the plugin and the
> > >>> broker apart from implementing a specific API that should be set in stone.
> > >>> Even better would be the ability to just to drop a war or jar into the lib
> > >>> dir and have it deployed automagically via annotations on the class or
> > >>> method perhaps.
> > >>>
> > >>> On Mon, 3 Jun 2019 at 22:58, wrote:
> > >>>
> > >>>> I just want it clarified what will be the rules of adopting a new plugin
> > >>>> or extension. Likewise the rule for archiving/killing off dead ones.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> And that is applied generically.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> E.g.
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> At least one pmc member needs to sponsor (doesnt have to be the committer
> > >>>> or contributor)
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> Any third party dependency plugin including dependency to third party
> > >>>> client jar must be apache license approved. (E.g. we can have plugin or
> > >>>> extension for a closed source commerical tool)
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> Just want the criteria decides agreed and documented up front to avoid
> > >>>> less issues later on what can go in and what cant
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> Get Outlook for Android
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <
> > >>>> clebert.suconic@gmail.com> wrote:
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>> All questions need to be same
> > >>>> @Michael Pearce perhaps it's my english as second language here, but
> > >>>> this to me sounded like "All your basis are belong to us" :)
> > >>>>
> > >>>> Can you explain what you meant here?
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>
> > >> --
> > >> Tim Bish
> > >>
> > >
> > >
> > > --
> > > Clebert Suconic
> >
>
>
>
>
>
Re: [DISCUSS] Component/Plugin repository
Posted by mi...@me.com.INVALID.
So already it seems we have issues handling and maintaining rights for users on the few jira projects we have.
E.g. atm whilst Christopher S, sorted my activemq rights as pmc memebrt, it seems no one has been able to sort the others artemis amqnet and amqcpp.
As such it shows atm managing too many will just get worse. I think we should avoid too much per project setup.
Get Outlook for Android
On Fri, Jun 7, 2019 at 12:36 PM +0100, "Robbie Gemmell" <ro...@gmail.com> wrote:
On JIRA handling 3 main choices jump out for me, which I would do in
this order (1 first) personally:
1) Create an individual JIRA project per plugin (e.g as Maven do:
https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=10510&selectedProjectType=all)
2) Create a new 'artemis plugins' style agregate JIRA project, with
'component' per plugin and 'releases' for each separate plugin
release.
3) Create a 'component' per plugin and add 'releases' for each
separate plugin release, within the existing ARTEMIS JIRA project.
Robbie
On Thu, 6 Jun 2019 at 22:25, Michael André Pearce
wrote:
>
> If we are going down the route of separate repos, are we going to have separate jira projects then for every plugin?
>
> Also just to be clear here we are talking about the
>
> promethius-plugin
> kafka-plugin
>
> currently? Or any others also?
>
> > On 4 Jun 2019, at 17:47, Clebert Suconic wrote:
> >
> > Fair enough... one component per repo.
> >
> > On Tue, Jun 4, 2019 at 10:26 AM Timothy Bish wrote:
> >>
> >> On 6/4/19 8:14 AM, Andy Taylor wrote:
> >>> Id personally pefer a single repo per plugin, some plugins will develop
> >>> quicker than others and with a single repo you would end up tagging and
> >>> releasing plugins that havent changed. I dont think there is an overhead
> >>> with using maven etc.
> >>
> >> Agreed, having each in its own repository running on its own release
> >> cycle would be my preferred option as well. A single large repository
> >> will tend to become harder to release as more things get dumped into it
> >> but not actively maintained. It is easier for the release validation if
> >> each is on its own as well, testing a release for a dozen different semi
> >> related components will likely drive down the quality of the review
> >> being done.
> >>
> >>
> >>>
> >>> I also think there should be no tight coupling between the plugin and the
> >>> broker apart from implementing a specific API that should be set in stone.
> >>> Even better would be the ability to just to drop a war or jar into the lib
> >>> dir and have it deployed automagically via annotations on the class or
> >>> method perhaps.
> >>>
> >>> On Mon, 3 Jun 2019 at 22:58, wrote:
> >>>
> >>>> I just want it clarified what will be the rules of adopting a new plugin
> >>>> or extension. Likewise the rule for archiving/killing off dead ones.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> And that is applied generically.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> E.g.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> At least one pmc member needs to sponsor (doesnt have to be the committer
> >>>> or contributor)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Any third party dependency plugin including dependency to third party
> >>>> client jar must be apache license approved. (E.g. we can have plugin or
> >>>> extension for a closed source commerical tool)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Just want the criteria decides agreed and documented up front to avoid
> >>>> less issues later on what can go in and what cant
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Get Outlook for Android
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <
> >>>> clebert.suconic@gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> All questions need to be same
> >>>> @Michael Pearce perhaps it's my english as second language here, but
> >>>> this to me sounded like "All your basis are belong to us" :)
> >>>>
> >>>> Can you explain what you meant here?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >> --
> >> Tim Bish
> >>
> >
> >
> > --
> > Clebert Suconic
>
Re: [DISCUSS] Component/Plugin repository
Posted by Robbie Gemmell <ro...@gmail.com>.
On JIRA handling 3 main choices jump out for me, which I would do in
this order (1 first) personally:
1) Create an individual JIRA project per plugin (e.g as Maven do:
https://issues.apache.org/jira/secure/BrowseProjects.jspa?selectedCategory=10510&selectedProjectType=all)
2) Create a new 'artemis plugins' style agregate JIRA project, with
'component' per plugin and 'releases' for each separate plugin
release.
3) Create a 'component' per plugin and add 'releases' for each
separate plugin release, within the existing ARTEMIS JIRA project.
Robbie
On Thu, 6 Jun 2019 at 22:25, Michael André Pearce
<mi...@me.com.invalid> wrote:
>
> If we are going down the route of separate repos, are we going to have separate jira projects then for every plugin?
>
> Also just to be clear here we are talking about the
>
> promethius-plugin
> kafka-plugin
>
> currently? Or any others also?
>
> > On 4 Jun 2019, at 17:47, Clebert Suconic <cl...@gmail.com> wrote:
> >
> > Fair enough... one component per repo.
> >
> > On Tue, Jun 4, 2019 at 10:26 AM Timothy Bish <ta...@gmail.com> wrote:
> >>
> >> On 6/4/19 8:14 AM, Andy Taylor wrote:
> >>> Id personally pefer a single repo per plugin, some plugins will develop
> >>> quicker than others and with a single repo you would end up tagging and
> >>> releasing plugins that havent changed. I dont think there is an overhead
> >>> with using maven etc.
> >>
> >> Agreed, having each in its own repository running on its own release
> >> cycle would be my preferred option as well. A single large repository
> >> will tend to become harder to release as more things get dumped into it
> >> but not actively maintained. It is easier for the release validation if
> >> each is on its own as well, testing a release for a dozen different semi
> >> related components will likely drive down the quality of the review
> >> being done.
> >>
> >>
> >>>
> >>> I also think there should be no tight coupling between the plugin and the
> >>> broker apart from implementing a specific API that should be set in stone.
> >>> Even better would be the ability to just to drop a war or jar into the lib
> >>> dir and have it deployed automagically via annotations on the class or
> >>> method perhaps.
> >>>
> >>> On Mon, 3 Jun 2019 at 22:58, <mi...@me.com.invalid> wrote:
> >>>
> >>>> I just want it clarified what will be the rules of adopting a new plugin
> >>>> or extension. Likewise the rule for archiving/killing off dead ones.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> And that is applied generically.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> E.g.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> At least one pmc member needs to sponsor (doesnt have to be the committer
> >>>> or contributor)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Any third party dependency plugin including dependency to third party
> >>>> client jar must be apache license approved. (E.g. we can have plugin or
> >>>> extension for a closed source commerical tool)
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Just want the criteria decides agreed and documented up front to avoid
> >>>> less issues later on what can go in and what cant
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> Get Outlook for Android
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <
> >>>> clebert.suconic@gmail.com> wrote:
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>> All questions need to be same
> >>>> @Michael Pearce perhaps it's my english as second language here, but
> >>>> this to me sounded like "All your basis are belong to us" :)
> >>>>
> >>>> Can you explain what you meant here?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>
> >> --
> >> Tim Bish
> >>
> >
> >
> > --
> > Clebert Suconic
>
Re: [DISCUSS] Component/Plugin repository
Posted by Michael André Pearce <mi...@me.com.INVALID>.
If we are going down the route of separate repos, are we going to have separate jira projects then for every plugin?
Also just to be clear here we are talking about the
promethius-plugin
kafka-plugin
currently? Or any others also?
> On 4 Jun 2019, at 17:47, Clebert Suconic <cl...@gmail.com> wrote:
>
> Fair enough... one component per repo.
>
> On Tue, Jun 4, 2019 at 10:26 AM Timothy Bish <ta...@gmail.com> wrote:
>>
>> On 6/4/19 8:14 AM, Andy Taylor wrote:
>>> Id personally pefer a single repo per plugin, some plugins will develop
>>> quicker than others and with a single repo you would end up tagging and
>>> releasing plugins that havent changed. I dont think there is an overhead
>>> with using maven etc.
>>
>> Agreed, having each in its own repository running on its own release
>> cycle would be my preferred option as well. A single large repository
>> will tend to become harder to release as more things get dumped into it
>> but not actively maintained. It is easier for the release validation if
>> each is on its own as well, testing a release for a dozen different semi
>> related components will likely drive down the quality of the review
>> being done.
>>
>>
>>>
>>> I also think there should be no tight coupling between the plugin and the
>>> broker apart from implementing a specific API that should be set in stone.
>>> Even better would be the ability to just to drop a war or jar into the lib
>>> dir and have it deployed automagically via annotations on the class or
>>> method perhaps.
>>>
>>> On Mon, 3 Jun 2019 at 22:58, <mi...@me.com.invalid> wrote:
>>>
>>>> I just want it clarified what will be the rules of adopting a new plugin
>>>> or extension. Likewise the rule for archiving/killing off dead ones.
>>>>
>>>>
>>>>
>>>>
>>>> And that is applied generically.
>>>>
>>>>
>>>>
>>>>
>>>> E.g.
>>>>
>>>>
>>>>
>>>>
>>>> At least one pmc member needs to sponsor (doesnt have to be the committer
>>>> or contributor)
>>>>
>>>>
>>>>
>>>>
>>>> Any third party dependency plugin including dependency to third party
>>>> client jar must be apache license approved. (E.g. we can have plugin or
>>>> extension for a closed source commerical tool)
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Just want the criteria decides agreed and documented up front to avoid
>>>> less issues later on what can go in and what cant
>>>>
>>>>
>>>>
>>>>
>>>> Get Outlook for Android
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <
>>>> clebert.suconic@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>> All questions need to be same
>>>> @Michael Pearce perhaps it's my english as second language here, but
>>>> this to me sounded like "All your basis are belong to us" :)
>>>>
>>>> Can you explain what you meant here?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>> --
>> Tim Bish
>>
>
>
> --
> Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by Clebert Suconic <cl...@gmail.com>.
Fair enough... one component per repo.
On Tue, Jun 4, 2019 at 10:26 AM Timothy Bish <ta...@gmail.com> wrote:
>
> On 6/4/19 8:14 AM, Andy Taylor wrote:
> > Id personally pefer a single repo per plugin, some plugins will develop
> > quicker than others and with a single repo you would end up tagging and
> > releasing plugins that havent changed. I dont think there is an overhead
> > with using maven etc.
>
> Agreed, having each in its own repository running on its own release
> cycle would be my preferred option as well. A single large repository
> will tend to become harder to release as more things get dumped into it
> but not actively maintained. It is easier for the release validation if
> each is on its own as well, testing a release for a dozen different semi
> related components will likely drive down the quality of the review
> being done.
>
>
> >
> > I also think there should be no tight coupling between the plugin and the
> > broker apart from implementing a specific API that should be set in stone.
> > Even better would be the ability to just to drop a war or jar into the lib
> > dir and have it deployed automagically via annotations on the class or
> > method perhaps.
> >
> > On Mon, 3 Jun 2019 at 22:58, <mi...@me.com.invalid> wrote:
> >
> >> I just want it clarified what will be the rules of adopting a new plugin
> >> or extension. Likewise the rule for archiving/killing off dead ones.
> >>
> >>
> >>
> >>
> >> And that is applied generically.
> >>
> >>
> >>
> >>
> >> E.g.
> >>
> >>
> >>
> >>
> >> At least one pmc member needs to sponsor (doesnt have to be the committer
> >> or contributor)
> >>
> >>
> >>
> >>
> >> Any third party dependency plugin including dependency to third party
> >> client jar must be apache license approved. (E.g. we can have plugin or
> >> extension for a closed source commerical tool)
> >>
> >>
> >>
> >>
> >>
> >>
> >> Just want the criteria decides agreed and documented up front to avoid
> >> less issues later on what can go in and what cant
> >>
> >>
> >>
> >>
> >> Get Outlook for Android
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <
> >> clebert.suconic@gmail.com> wrote:
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>> All questions need to be same
> >> @Michael Pearce perhaps it's my english as second language here, but
> >> this to me sounded like "All your basis are belong to us" :)
> >>
> >> Can you explain what you meant here?
> >>
> >>
> >>
> >>
> >>
> >>
>
> --
> Tim Bish
>
--
Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by Timothy Bish <ta...@gmail.com>.
On 6/4/19 8:14 AM, Andy Taylor wrote:
> Id personally pefer a single repo per plugin, some plugins will develop
> quicker than others and with a single repo you would end up tagging and
> releasing plugins that havent changed. I dont think there is an overhead
> with using maven etc.
Agreed, having each in its own repository running on its own release
cycle would be my preferred option as well. A single large repository
will tend to become harder to release as more things get dumped into it
but not actively maintained. It is easier for the release validation if
each is on its own as well, testing a release for a dozen different semi
related components will likely drive down the quality of the review
being done.
>
> I also think there should be no tight coupling between the plugin and the
> broker apart from implementing a specific API that should be set in stone.
> Even better would be the ability to just to drop a war or jar into the lib
> dir and have it deployed automagically via annotations on the class or
> method perhaps.
>
> On Mon, 3 Jun 2019 at 22:58, <mi...@me.com.invalid> wrote:
>
>> I just want it clarified what will be the rules of adopting a new plugin
>> or extension. Likewise the rule for archiving/killing off dead ones.
>>
>>
>>
>>
>> And that is applied generically.
>>
>>
>>
>>
>> E.g.
>>
>>
>>
>>
>> At least one pmc member needs to sponsor (doesnt have to be the committer
>> or contributor)
>>
>>
>>
>>
>> Any third party dependency plugin including dependency to third party
>> client jar must be apache license approved. (E.g. we can have plugin or
>> extension for a closed source commerical tool)
>>
>>
>>
>>
>>
>>
>> Just want the criteria decides agreed and documented up front to avoid
>> less issues later on what can go in and what cant
>>
>>
>>
>>
>> Get Outlook for Android
>>
>>
>>
>>
>>
>>
>>
>> On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <
>> clebert.suconic@gmail.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>> All questions need to be same
>> @Michael Pearce perhaps it's my english as second language here, but
>> this to me sounded like "All your basis are belong to us" :)
>>
>> Can you explain what you meant here?
>>
>>
>>
>>
>>
>>
--
Tim Bish
Re: [DISCUSS] Component/Plugin repository
Posted by Christopher Shannon <ch...@gmail.com>.
The more I think about it I think I am also in favor of a separate repo per
plugin for the reasons Andy stated. I think it will be quite common where
some plugins have low activity and not updated much and others are quite
active and it would be pretty confusing to be releasing several versions of
a plugin that hasn't changed.
Keep the scope small and have things be released independently.
On Tue, Jun 4, 2019 at 8:14 AM Andy Taylor <an...@gmail.com> wrote:
> Id personally pefer a single repo per plugin, some plugins will develop
> quicker than others and with a single repo you would end up tagging and
> releasing plugins that havent changed. I dont think there is an overhead
> with using maven etc.
>
> I also think there should be no tight coupling between the plugin and the
> broker apart from implementing a specific API that should be set in stone.
> Even better would be the ability to just to drop a war or jar into the lib
> dir and have it deployed automagically via annotations on the class or
> method perhaps.
>
> On Mon, 3 Jun 2019 at 22:58, <mi...@me.com.invalid> wrote:
>
> > I just want it clarified what will be the rules of adopting a new plugin
> > or extension. Likewise the rule for archiving/killing off dead ones.
> >
> >
> >
> >
> > And that is applied generically.
> >
> >
> >
> >
> > E.g.
> >
> >
> >
> >
> > At least one pmc member needs to sponsor (doesnt have to be the committer
> > or contributor)
> >
> >
> >
> >
> > Any third party dependency plugin including dependency to third party
> > client jar must be apache license approved. (E.g. we can have plugin or
> > extension for a closed source commerical tool)
> >
> >
> >
> >
> >
> >
> > Just want the criteria decides agreed and documented up front to avoid
> > less issues later on what can go in and what cant
> >
> >
> >
> >
> > Get Outlook for Android
> >
> >
> >
> >
> >
> >
> >
> > On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <
> > clebert.suconic@gmail.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > > All questions need to be same
> >
> > @Michael Pearce perhaps it's my english as second language here, but
> > this to me sounded like "All your basis are belong to us" :)
> >
> > Can you explain what you meant here?
> >
> >
> >
> >
> >
> >
>
Re: [DISCUSS] Component/Plugin repository
Posted by Andy Taylor <an...@gmail.com>.
Id personally pefer a single repo per plugin, some plugins will develop
quicker than others and with a single repo you would end up tagging and
releasing plugins that havent changed. I dont think there is an overhead
with using maven etc.
I also think there should be no tight coupling between the plugin and the
broker apart from implementing a specific API that should be set in stone.
Even better would be the ability to just to drop a war or jar into the lib
dir and have it deployed automagically via annotations on the class or
method perhaps.
On Mon, 3 Jun 2019 at 22:58, <mi...@me.com.invalid> wrote:
> I just want it clarified what will be the rules of adopting a new plugin
> or extension. Likewise the rule for archiving/killing off dead ones.
>
>
>
>
> And that is applied generically.
>
>
>
>
> E.g.
>
>
>
>
> At least one pmc member needs to sponsor (doesnt have to be the committer
> or contributor)
>
>
>
>
> Any third party dependency plugin including dependency to third party
> client jar must be apache license approved. (E.g. we can have plugin or
> extension for a closed source commerical tool)
>
>
>
>
>
>
> Just want the criteria decides agreed and documented up front to avoid
> less issues later on what can go in and what cant
>
>
>
>
> Get Outlook for Android
>
>
>
>
>
>
>
> On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <
> clebert.suconic@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
>
> > All questions need to be same
>
> @Michael Pearce perhaps it's my english as second language here, but
> this to me sounded like "All your basis are belong to us" :)
>
> Can you explain what you meant here?
>
>
>
>
>
>
Re: [DISCUSS] Component/Plugin repository
Posted by mi...@me.com.INVALID.
I just want it clarified what will be the rules of adopting a new plugin or extension. Likewise the rule for archiving/killing off dead ones.
And that is applied generically.
E.g.
At least one pmc member needs to sponsor (doesnt have to be the committer or contributor)
Any third party dependency plugin including dependency to third party client jar must be apache license approved. (E.g. we can have plugin or extension for a closed source commerical tool)
Just want the criteria decides agreed and documented up front to avoid less issues later on what can go in and what cant
Get Outlook for Android
On Mon, Jun 3, 2019 at 4:27 PM +0100, "Clebert Suconic" <cl...@gmail.com> wrote:
> All questions need to be same
@Michael Pearce perhaps it's my english as second language here, but
this to me sounded like "All your basis are belong to us" :)
Can you explain what you meant here?
Re: [DISCUSS] Component/Plugin repository
Posted by Clebert Suconic <cl...@gmail.com>.
> All questions need to be same
@Michael Pearce perhaps it's my english as second language here, but
this to me sounded like "All your basis are belong to us" :)
Can you explain what you meant here?
Re: [DISCUSS] Component/Plugin repository
Posted by mi...@me.com.INVALID.
What about the kafka plugin, or influx plugin...
All questions need to be same
Get Outlook for Android
On Mon, Jun 3, 2019 at 2:27 PM +0100, "Clebert Suconic" <cl...@gmail.com> wrote:
there's also another technical issue when we create / separate these components.
They will likely depend on the broker...
And how are we going to consume these components on the broker? Have
the users picking them and installing them manually?
idea:
We could have the CLI doing such thing for users, with an optional CLI
on the create:
./artemis create --plugin Prometheus
But then this would create a circular dependency between the
repositories, what makes it difficult.
How would it be consumed? Just having the user copying it ?
On Mon, Jun 3, 2019 at 9:24 AM Clebert Suconic
wrote:
>
> The question was in regard to spin new components? do we need a new vote to start a new repository?
>
> Regarding the releases... we could release them altogether. Say... ActiveMQ-Artemis-plugin 1.0
>
> Later on, when you add a new feature, you will have 1.1, 1.2... and thereafter.
>
> Say we changed something on the broker that will require update in all of them/// we will need a lot of votes to go out.
>
>
>
>
> On Mon, Jun 3, 2019 at 6:06 AM Robbie Gemmell wrote:
>>
>> A vote would be required for each independently released thing, yes.
>> That is true whether they are in specific repos or in an single repo
>> but still released independently, so the only difference would come if
>> releasing all plugins in that single repo as 'one thing'. That
>> probably mean less releases, but likely also more complicated ones as
>> grouping essentially indpendent bits into a single release tends to
>> add its own challenges. That can tend to make them happen less often,
>> and encourages them to be 'bigger' as folk stuff things in, which then
>> makes them more complicated again, etc...
>>
>> Release votes dont need to be especially difficult. I've found the
>> more targetted and/or regular they are, the easier doing them tends to
>> become. I've run around 30 or so in the last year across a few
>> components, but would have preferred to do more than I actually did.
>>
>> Robbie
>>
>> On Fri, 31 May 2019 at 20:12, Clebert Suconic wrote:
>> >
>> > On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell wrote:
>> > >
>> > > I probably would do one each, yes. Its the easiest separation, keeps
>> > > things independent and focused from the start and can avoid various
>> > > hassles later.
>> > >
>> > > I'd perhaps consider 'all stuff' aggregation (e.g foo =
>> > > metrics), but really I dont personally see the benefits as outweighing
>> > > the other things a lot of the time. I dont think anyone is charging us
>> > > per repo.
>> >
>> > No, but does it require a vote each time we spin a new component?
>> >
>> >
>> > >
>> > > With a shared repo I guess you would just tag everything, or else
>> > > start down the route of complications that also make individual repos
>> > > seem nice. Could use Subversion, subdir tags were easy there :)
>> > >
>> > > (Aside, there is one project, ActiveMQ. These would be components).
>> > >
>> > > On Fri, 31 May 2019 at 17:24, Clebert Suconic wrote:
>> > > >
>> > > > I agree with you, and that was my preference as well. I was trying to
>> > > > understand if one git per component is what Robbie was suggesting.
>> > > >
>> > > > Although there's an issue though, when you have one super git for many
>> > > > independent components, how would you tag releases?
>> > > >
>> > > > each fodler would be in fact an independent project, with no
>> > > > correlation between the projects.
>> > > >
>> > > > On Fri, May 31, 2019 at 8:00 AM wrote:
>> > > > >
>> > > > > I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > Get Outlook for Android
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" wrote:
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
>> > > > > wrote:
>> > > > > >
>> > > > > > I would put them outwith the broker repository. Not really because of
>> > > > > > bloat, which was only a very small part of why I didnt think the
>> > > > > > proposed Kafka Bridge should live inside the broker repo+package for
>> > > > > > example, but thats certainly also something to keep in mind given the
>> > > > > > build is pretty large/slow already.
>> > > > > >
>> > > > > > I wouldnt say a single plugin repository is necessarily a great idea,
>> > > > > > it can tend to become a bit of a dumping ground for idea-of-the-week,
>> > > > > > but the main thing for me would be that components should be
>> > > > > > independently released if there were to be a bunch of optional
>> > > > > > components with mostly unrelated functionality in the same place (e.g,
>> > > > > > the ideas mentioned in this thread already seem mostly independent).
>> > > > >
>> > > > > So, what do you suggest? one gitRepo per plugin?
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Clebert Suconic
>> >
>> >
>> >
>> > --
>> > Clebert Suconic
--
Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by Clebert Suconic <cl...@gmail.com>.
there's also another technical issue when we create / separate these components.
They will likely depend on the broker...
And how are we going to consume these components on the broker? Have
the users picking them and installing them manually?
idea:
We could have the CLI doing such thing for users, with an optional CLI
on the create:
./artemis create --plugin Prometheus
But then this would create a circular dependency between the
repositories, what makes it difficult.
How would it be consumed? Just having the user copying it ?
On Mon, Jun 3, 2019 at 9:24 AM Clebert Suconic
<cl...@gmail.com> wrote:
>
> The question was in regard to spin new components? do we need a new vote to start a new repository?
>
> Regarding the releases... we could release them altogether. Say... ActiveMQ-Artemis-plugin 1.0
>
> Later on, when you add a new feature, you will have 1.1, 1.2... and thereafter.
>
> Say we changed something on the broker that will require update in all of them/// we will need a lot of votes to go out.
>
>
>
>
> On Mon, Jun 3, 2019 at 6:06 AM Robbie Gemmell <ro...@gmail.com> wrote:
>>
>> A vote would be required for each independently released thing, yes.
>> That is true whether they are in specific repos or in an single repo
>> but still released independently, so the only difference would come if
>> releasing all plugins in that single repo as 'one thing'. That
>> probably mean less releases, but likely also more complicated ones as
>> grouping essentially indpendent bits into a single release tends to
>> add its own challenges. That can tend to make them happen less often,
>> and encourages them to be 'bigger' as folk stuff things in, which then
>> makes them more complicated again, etc...
>>
>> Release votes dont need to be especially difficult. I've found the
>> more targetted and/or regular they are, the easier doing them tends to
>> become. I've run around 30 or so in the last year across a few
>> components, but would have preferred to do more than I actually did.
>>
>> Robbie
>>
>> On Fri, 31 May 2019 at 20:12, Clebert Suconic <cl...@gmail.com> wrote:
>> >
>> > On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <ro...@gmail.com> wrote:
>> > >
>> > > I probably would do one each, yes. Its the easiest separation, keeps
>> > > things independent and focused from the start and can avoid various
>> > > hassles later.
>> > >
>> > > I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
>> > > metrics), but really I dont personally see the benefits as outweighing
>> > > the other things a lot of the time. I dont think anyone is charging us
>> > > per repo.
>> >
>> > No, but does it require a vote each time we spin a new component?
>> >
>> >
>> > >
>> > > With a shared repo I guess you would just tag everything, or else
>> > > start down the route of complications that also make individual repos
>> > > seem nice. Could use Subversion, subdir tags were easy there :)
>> > >
>> > > (Aside, there is one project, ActiveMQ. These would be components).
>> > >
>> > > On Fri, 31 May 2019 at 17:24, Clebert Suconic <cl...@gmail.com> wrote:
>> > > >
>> > > > I agree with you, and that was my preference as well. I was trying to
>> > > > understand if one git per component is what Robbie was suggesting.
>> > > >
>> > > > Although there's an issue though, when you have one super git for many
>> > > > independent components, how would you tag releases?
>> > > >
>> > > > each fodler would be in fact an independent project, with no
>> > > > correlation between the projects.
>> > > >
>> > > > On Fri, May 31, 2019 at 8:00 AM <mi...@me.com.invalid> wrote:
>> > > > >
>> > > > > I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > Get Outlook for Android
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <cl...@gmail.com> wrote:
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
>> > > > > wrote:
>> > > > > >
>> > > > > > I would put them outwith the broker repository. Not really because of
>> > > > > > bloat, which was only a very small part of why I didnt think the
>> > > > > > proposed Kafka Bridge should live inside the broker repo+package for
>> > > > > > example, but thats certainly also something to keep in mind given the
>> > > > > > build is pretty large/slow already.
>> > > > > >
>> > > > > > I wouldnt say a single plugin repository is necessarily a great idea,
>> > > > > > it can tend to become a bit of a dumping ground for idea-of-the-week,
>> > > > > > but the main thing for me would be that components should be
>> > > > > > independently released if there were to be a bunch of optional
>> > > > > > components with mostly unrelated functionality in the same place (e.g,
>> > > > > > the ideas mentioned in this thread already seem mostly independent).
>> > > > >
>> > > > > So, what do you suggest? one gitRepo per plugin?
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > > > --
>> > > > Clebert Suconic
>> >
>> >
>> >
>> > --
>> > Clebert Suconic
--
Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by Clebert Suconic <cl...@gmail.com>.
The question was in regard to spin new components? do we need a new vote to
start a new repository?
Regarding the releases... we could release them altogether. Say...
ActiveMQ-Artemis-plugin 1.0
Later on, when you add a new feature, you will have 1.1, 1.2... and
thereafter.
Say we changed something on the broker that will require update in all of
them/// we will need a lot of votes to go out.
On Mon, Jun 3, 2019 at 6:06 AM Robbie Gemmell <ro...@gmail.com>
wrote:
> A vote would be required for each independently released thing, yes.
> That is true whether they are in specific repos or in an single repo
> but still released independently, so the only difference would come if
> releasing all plugins in that single repo as 'one thing'. That
> probably mean less releases, but likely also more complicated ones as
> grouping essentially indpendent bits into a single release tends to
> add its own challenges. That can tend to make them happen less often,
> and encourages them to be 'bigger' as folk stuff things in, which then
> makes them more complicated again, etc...
>
> Release votes dont need to be especially difficult. I've found the
> more targetted and/or regular they are, the easier doing them tends to
> become. I've run around 30 or so in the last year across a few
> components, but would have preferred to do more than I actually did.
>
> Robbie
>
> On Fri, 31 May 2019 at 20:12, Clebert Suconic <cl...@gmail.com>
> wrote:
> >
> > On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <ro...@gmail.com>
> wrote:
> > >
> > > I probably would do one each, yes. Its the easiest separation, keeps
> > > things independent and focused from the start and can avoid various
> > > hassles later.
> > >
> > > I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
> > > metrics), but really I dont personally see the benefits as outweighing
> > > the other things a lot of the time. I dont think anyone is charging us
> > > per repo.
> >
> > No, but does it require a vote each time we spin a new component?
> >
> >
> > >
> > > With a shared repo I guess you would just tag everything, or else
> > > start down the route of complications that also make individual repos
> > > seem nice. Could use Subversion, subdir tags were easy there :)
> > >
> > > (Aside, there is one project, ActiveMQ. These would be components).
> > >
> > > On Fri, 31 May 2019 at 17:24, Clebert Suconic <
> clebert.suconic@gmail.com> wrote:
> > > >
> > > > I agree with you, and that was my preference as well. I was trying to
> > > > understand if one git per component is what Robbie was suggesting.
> > > >
> > > > Although there's an issue though, when you have one super git for
> many
> > > > independent components, how would you tag releases?
> > > >
> > > > each fodler would be in fact an independent project, with no
> > > > correlation between the projects.
> > > >
> > > > On Fri, May 31, 2019 at 8:00 AM <mi...@me.com.invalid>
> wrote:
> > > > >
> > > > > I think one git repo per thing maybecome a bit too scattery. Id go
> for one repo with multiple modules.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > Get Outlook for Android
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <
> clebert.suconic@gmail.com> wrote:
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> > > > > wrote:
> > > > > >
> > > > > > I would put them outwith the broker repository. Not really
> because of
> > > > > > bloat, which was only a very small part of why I didnt think the
> > > > > > proposed Kafka Bridge should live inside the broker repo+package
> for
> > > > > > example, but thats certainly also something to keep in mind
> given the
> > > > > > build is pretty large/slow already.
> > > > > >
> > > > > > I wouldnt say a single plugin repository is necessarily a great
> idea,
> > > > > > it can tend to become a bit of a dumping ground for
> idea-of-the-week,
> > > > > > but the main thing for me would be that components should be
> > > > > > independently released if there were to be a bunch of optional
> > > > > > components with mostly unrelated functionality in the same place
> (e.g,
> > > > > > the ideas mentioned in this thread already seem mostly
> independent).
> > > > >
> > > > > So, what do you suggest? one gitRepo per plugin?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Clebert Suconic
> >
> >
> >
> > --
> > Clebert Suconic
>
Re: [DISCUSS] Component/Plugin repository
Posted by Robbie Gemmell <ro...@gmail.com>.
A vote would be required for each independently released thing, yes.
That is true whether they are in specific repos or in an single repo
but still released independently, so the only difference would come if
releasing all plugins in that single repo as 'one thing'. That
probably mean less releases, but likely also more complicated ones as
grouping essentially indpendent bits into a single release tends to
add its own challenges. That can tend to make them happen less often,
and encourages them to be 'bigger' as folk stuff things in, which then
makes them more complicated again, etc...
Release votes dont need to be especially difficult. I've found the
more targetted and/or regular they are, the easier doing them tends to
become. I've run around 30 or so in the last year across a few
components, but would have preferred to do more than I actually did.
Robbie
On Fri, 31 May 2019 at 20:12, Clebert Suconic <cl...@gmail.com> wrote:
>
> On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <ro...@gmail.com> wrote:
> >
> > I probably would do one each, yes. Its the easiest separation, keeps
> > things independent and focused from the start and can avoid various
> > hassles later.
> >
> > I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
> > metrics), but really I dont personally see the benefits as outweighing
> > the other things a lot of the time. I dont think anyone is charging us
> > per repo.
>
> No, but does it require a vote each time we spin a new component?
>
>
> >
> > With a shared repo I guess you would just tag everything, or else
> > start down the route of complications that also make individual repos
> > seem nice. Could use Subversion, subdir tags were easy there :)
> >
> > (Aside, there is one project, ActiveMQ. These would be components).
> >
> > On Fri, 31 May 2019 at 17:24, Clebert Suconic <cl...@gmail.com> wrote:
> > >
> > > I agree with you, and that was my preference as well. I was trying to
> > > understand if one git per component is what Robbie was suggesting.
> > >
> > > Although there's an issue though, when you have one super git for many
> > > independent components, how would you tag releases?
> > >
> > > each fodler would be in fact an independent project, with no
> > > correlation between the projects.
> > >
> > > On Fri, May 31, 2019 at 8:00 AM <mi...@me.com.invalid> wrote:
> > > >
> > > > I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
> > > >
> > > >
> > > >
> > > >
> > > > Get Outlook for Android
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <cl...@gmail.com> wrote:
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> > > > wrote:
> > > > >
> > > > > I would put them outwith the broker repository. Not really because of
> > > > > bloat, which was only a very small part of why I didnt think the
> > > > > proposed Kafka Bridge should live inside the broker repo+package for
> > > > > example, but thats certainly also something to keep in mind given the
> > > > > build is pretty large/slow already.
> > > > >
> > > > > I wouldnt say a single plugin repository is necessarily a great idea,
> > > > > it can tend to become a bit of a dumping ground for idea-of-the-week,
> > > > > but the main thing for me would be that components should be
> > > > > independently released if there were to be a bunch of optional
> > > > > components with mostly unrelated functionality in the same place (e.g,
> > > > > the ideas mentioned in this thread already seem mostly independent).
> > > >
> > > > So, what do you suggest? one gitRepo per plugin?
> > > >
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> > > --
> > > Clebert Suconic
>
>
>
> --
> Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by "michael.andre.pearce" <mi...@me.com.INVALID>.
Thats a concern for me. Also the setup for every repo.I think personally having a single repo will be easier for starters. We can always split out groups of modules later, or even one per module. If it gets too much.But for a first go i think having a single repo for plugins and other extensions will be better.Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: Clebert Suconic <cl...@gmail.com> Date: 31/05/2019 20:12 (GMT+00:00) To: dev@activemq.apache.org Subject: Re: [DISCUSS] Component/Plugin repository On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <ro...@gmail.com> wrote:>> I probably would do one each, yes. Its the easiest separation, keeps> things independent and focused from the start and can avoid various> hassles later.>> I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo => metrics), but really I dont personally see the benefits as outweighing> the other things a lot of the time. I dont think anyone is charging us> per repo.No, but does it require a vote each time we spin a new component?>> With a shared repo I guess you would just tag everything, or else> start down the route of complications that also make individual repos> seem nice. Could use Subversion, subdir tags were easy there :)>> (Aside, there is one project, ActiveMQ. These would be components).>> On Fri, 31 May 2019 at 17:24, Clebert Suconic <cl...@gmail.com> wrote:> >> > I agree with you, and that was my preference as well. I was trying to> > understand if one git per component is what Robbie was suggesting.> >> > Although there's an issue though, when you have one super git for many> > independent components, how would you tag releases?> >> > each fodler would be in fact an independent project, with no> > correlation between the projects.> >> > On Fri, May 31, 2019 at 8:00 AM <mi...@me.com.invalid> wrote:> > >> > > I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.> > >> > >> > >> > >> > > Get Outlook for Android> > >> > >> > >> > >> > >> > >> > >> > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <cl...@gmail.com> wrote:> > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell> > > wrote:> > > >> > > > I would put them outwith the broker repository. Not really because of> > > > bloat, which was only a very small part of why I didnt think the> > > > proposed Kafka Bridge should live inside the broker repo+package for> > > > example, but thats certainly also something to keep in mind given the> > > > build is pretty large/slow already.> > > >> > > > I wouldnt say a single plugin repository is necessarily a great idea,> > > > it can tend to become a bit of a dumping ground for idea-of-the-week,> > > > but the main thing for me would be that components should be> > > > independently released if there were to be a bunch of optional> > > > components with mostly unrelated functionality in the same place (e.g,> > > > the ideas mentioned in this thread already seem mostly independent).> > >> > > So, what do you suggest? one gitRepo per plugin?> > >> > >> > >> > >> > >> >> >> > --> > Clebert Suconic-- Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by Clebert Suconic <cl...@gmail.com>.
On Fri, May 31, 2019 at 2:42 PM Robbie Gemmell <ro...@gmail.com> wrote:
>
> I probably would do one each, yes. Its the easiest separation, keeps
> things independent and focused from the start and can avoid various
> hassles later.
>
> I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
> metrics), but really I dont personally see the benefits as outweighing
> the other things a lot of the time. I dont think anyone is charging us
> per repo.
No, but does it require a vote each time we spin a new component?
>
> With a shared repo I guess you would just tag everything, or else
> start down the route of complications that also make individual repos
> seem nice. Could use Subversion, subdir tags were easy there :)
>
> (Aside, there is one project, ActiveMQ. These would be components).
>
> On Fri, 31 May 2019 at 17:24, Clebert Suconic <cl...@gmail.com> wrote:
> >
> > I agree with you, and that was my preference as well. I was trying to
> > understand if one git per component is what Robbie was suggesting.
> >
> > Although there's an issue though, when you have one super git for many
> > independent components, how would you tag releases?
> >
> > each fodler would be in fact an independent project, with no
> > correlation between the projects.
> >
> > On Fri, May 31, 2019 at 8:00 AM <mi...@me.com.invalid> wrote:
> > >
> > > I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
> > >
> > >
> > >
> > >
> > > Get Outlook for Android
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <cl...@gmail.com> wrote:
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> > > wrote:
> > > >
> > > > I would put them outwith the broker repository. Not really because of
> > > > bloat, which was only a very small part of why I didnt think the
> > > > proposed Kafka Bridge should live inside the broker repo+package for
> > > > example, but thats certainly also something to keep in mind given the
> > > > build is pretty large/slow already.
> > > >
> > > > I wouldnt say a single plugin repository is necessarily a great idea,
> > > > it can tend to become a bit of a dumping ground for idea-of-the-week,
> > > > but the main thing for me would be that components should be
> > > > independently released if there were to be a bunch of optional
> > > > components with mostly unrelated functionality in the same place (e.g,
> > > > the ideas mentioned in this thread already seem mostly independent).
> > >
> > > So, what do you suggest? one gitRepo per plugin?
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Clebert Suconic
--
Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by Robbie Gemmell <ro...@gmail.com>.
I probably would do one each, yes. Its the easiest separation, keeps
things independent and focused from the start and can avoid various
hassles later.
I'd perhaps consider 'all <foo> stuff' aggregation (e.g foo =
metrics), but really I dont personally see the benefits as outweighing
the other things a lot of the time. I dont think anyone is charging us
per repo.
With a shared repo I guess you would just tag everything, or else
start down the route of complications that also make individual repos
seem nice. Could use Subversion, subdir tags were easy there :)
(Aside, there is one project, ActiveMQ. These would be components).
On Fri, 31 May 2019 at 17:24, Clebert Suconic <cl...@gmail.com> wrote:
>
> I agree with you, and that was my preference as well. I was trying to
> understand if one git per component is what Robbie was suggesting.
>
> Although there's an issue though, when you have one super git for many
> independent components, how would you tag releases?
>
> each fodler would be in fact an independent project, with no
> correlation between the projects.
>
> On Fri, May 31, 2019 at 8:00 AM <mi...@me.com.invalid> wrote:
> >
> > I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
> >
> >
> >
> >
> > Get Outlook for Android
> >
> >
> >
> >
> >
> >
> >
> > On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <cl...@gmail.com> wrote:
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> > wrote:
> > >
> > > I would put them outwith the broker repository. Not really because of
> > > bloat, which was only a very small part of why I didnt think the
> > > proposed Kafka Bridge should live inside the broker repo+package for
> > > example, but thats certainly also something to keep in mind given the
> > > build is pretty large/slow already.
> > >
> > > I wouldnt say a single plugin repository is necessarily a great idea,
> > > it can tend to become a bit of a dumping ground for idea-of-the-week,
> > > but the main thing for me would be that components should be
> > > independently released if there were to be a bunch of optional
> > > components with mostly unrelated functionality in the same place (e.g,
> > > the ideas mentioned in this thread already seem mostly independent).
> >
> > So, what do you suggest? one gitRepo per plugin?
> >
> >
> >
> >
> >
>
>
> --
> Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by Clebert Suconic <cl...@gmail.com>.
I agree with you, and that was my preference as well. I was trying to
understand if one git per component is what Robbie was suggesting.
Although there's an issue though, when you have one super git for many
independent components, how would you tag releases?
each fodler would be in fact an independent project, with no
correlation between the projects.
On Fri, May 31, 2019 at 8:00 AM <mi...@me.com.invalid> wrote:
>
> I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
>
>
>
>
> Get Outlook for Android
>
>
>
>
>
>
>
> On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <cl...@gmail.com> wrote:
>
>
>
>
>
>
>
>
>
>
> On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
> wrote:
> >
> > I would put them outwith the broker repository. Not really because of
> > bloat, which was only a very small part of why I didnt think the
> > proposed Kafka Bridge should live inside the broker repo+package for
> > example, but thats certainly also something to keep in mind given the
> > build is pretty large/slow already.
> >
> > I wouldnt say a single plugin repository is necessarily a great idea,
> > it can tend to become a bit of a dumping ground for idea-of-the-week,
> > but the main thing for me would be that components should be
> > independently released if there were to be a bunch of optional
> > components with mostly unrelated functionality in the same place (e.g,
> > the ideas mentioned in this thread already seem mostly independent).
>
> So, what do you suggest? one gitRepo per plugin?
>
>
>
>
>
--
Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by mi...@me.com.INVALID.
I think one git repo per thing maybecome a bit too scattery. Id go for one repo with multiple modules.
Get Outlook for Android
On Thu, May 30, 2019 at 7:42 PM +0100, "Clebert Suconic" <cl...@gmail.com> wrote:
On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
wrote:
>
> I would put them outwith the broker repository. Not really because of
> bloat, which was only a very small part of why I didnt think the
> proposed Kafka Bridge should live inside the broker repo+package for
> example, but thats certainly also something to keep in mind given the
> build is pretty large/slow already.
>
> I wouldnt say a single plugin repository is necessarily a great idea,
> it can tend to become a bit of a dumping ground for idea-of-the-week,
> but the main thing for me would be that components should be
> independently released if there were to be a bunch of optional
> components with mostly unrelated functionality in the same place (e.g,
> the ideas mentioned in this thread already seem mostly independent).
So, what do you suggest? one gitRepo per plugin?
Re: [DISCUSS] Component/Plugin repository
Posted by Clebert Suconic <cl...@gmail.com>.
On Thu, May 30, 2019 at 12:25 PM Robbie Gemmell
<ro...@gmail.com> wrote:
>
> I would put them outwith the broker repository. Not really because of
> bloat, which was only a very small part of why I didnt think the
> proposed Kafka Bridge should live inside the broker repo+package for
> example, but thats certainly also something to keep in mind given the
> build is pretty large/slow already.
>
> I wouldnt say a single plugin repository is necessarily a great idea,
> it can tend to become a bit of a dumping ground for idea-of-the-week,
> but the main thing for me would be that components should be
> independently released if there were to be a bunch of optional
> components with mostly unrelated functionality in the same place (e.g,
> the ideas mentioned in this thread already seem mostly independent).
So, what do you suggest? one gitRepo per plugin?
Re: [DISCUSS] Component/Plugin repository
Posted by Robbie Gemmell <ro...@gmail.com>.
I would put them outwith the broker repository. Not really because of
bloat, which was only a very small part of why I didnt think the
proposed Kafka Bridge should live inside the broker repo+package for
example, but thats certainly also something to keep in mind given the
build is pretty large/slow already.
I wouldnt say a single plugin repository is necessarily a great idea,
it can tend to become a bit of a dumping ground for idea-of-the-week,
but the main thing for me would be that components should be
independently released if there were to be a bunch of optional
components with mostly unrelated functionality in the same place (e.g,
the ideas mentioned in this thread already seem mostly independent).
Robbie
On Wed, 29 May 2019 at 11:54, Christopher Shannon
<ch...@gmail.com> wrote:
>
> This sounds good to me, I think it would be good to have some way to keep a
> collection of plugins that is easy for people to find. I guess they could
> either go into a new directory under the current Artemis build and each
> have their own sub module/ jar or they could live by themselves in a new
> sub project.
>
> I'm not really sure which approach would be best. Having new sub modules
> makes it easy to keep the plugins in sync with the broker but can bloat the
> release with things that may not belong in the main release (which is why
> we didn't want the Kafka Bridge to be included as part of the main release)
>
> Having a new sub project could be nice so people can optionally grab
> plugins only if they want them and this would allow the plugins could be
> updated and released on their own schedule. The main downside I see with
> the sub project approach is trying to keep plugins in sync with the broker
> version. If we don't end up bundling the plugins with the broker itself
> then we need to figure out how to handle compatibility across releases.
>
> On Tue, May 28, 2019 at 10:50 PM Justin Bertram <jb...@apache.org> wrote:
>
> > With the impending support for metrics plugins [1] as well as other
> > pluggable components which have been discussed in the past (e.g. Kafka
> > bridge [2] proposed by Mike Pearce) I think it would great to have an
> > official place where these things could be hosted and potentially included
> > as part of a broker release. Does anybody have any opinion on this?
> >
> >
> > Justin
> >
> > [1] https://github.com/apache/activemq-artemis/pull/2681
> > [2] https://issues.apache.org/jira/browse/ARTEMIS-1478
> >
Re: [DISCUSS] Component/Plugin repository
Posted by Clebert Suconic <cl...@gmail.com>.
On Thu, May 30, 2019 at 12:50 AM <mi...@me.com.invalid> wrote:
>
> What ever the agreed place is i would want to see the same rules being applied across the board as noted this isnt the first time this has cropped up.
It's simple... if the integration is soft, make it a plugin.
We could have a framework defined on how plugins are consumed. That
would allow a whole set of features to be implemented.
>
> That said. If we go seperate repo route. We could move other bits like docker and operator sub modules to sub repos there so they can have possibly a different lifecycle.
We could.. however Docker is a bit dependent on the release. if we go
to the apache infra docker support, it would need to be part of the
repository. (not a good example on this case)
>
> In particular comment to Prometheus plugin. Would it be worth while also providing some base grafana dashboard people can just import to complement the metrics so end users have an even quicker onboarding journey.
It could be part of such external repository I think.
Re: [DISCUSS] Component/Plugin repository
Posted by mi...@me.com.INVALID.
What ever the agreed place is i would want to see the same rules being applied across the board as noted this isnt the first time this has cropped up.
That said. If we go seperate repo route. We could move other bits like docker and operator sub modules to sub repos there so they can have possibly a different lifecycle.
In particular comment to Prometheus plugin. Would it be worth while also providing some base grafana dashboard people can just import to complement the metrics so end users have an even quicker onboarding journey.
Get Outlook for Android
On Wed, May 29, 2019 at 2:09 PM +0100, "Clebert Suconic" <cl...@gmail.com> wrote:
We could have a separate repository for these plugins...
They could be part of our binary distribution (as being consumed), and
we could have special CLI options to activate them.
e.g.: ./artemis create /folder --plugin prometheus
The prometheus plugin would be only applied if such option was applied.
On Wed, May 29, 2019 at 6:54 AM Christopher Shannon
wrote:
>
> This sounds good to me, I think it would be good to have some way to keep a
> collection of plugins that is easy for people to find. I guess they could
> either go into a new directory under the current Artemis build and each
> have their own sub module/ jar or they could live by themselves in a new
> sub project.
>
> I'm not really sure which approach would be best. Having new sub modules
> makes it easy to keep the plugins in sync with the broker but can bloat the
> release with things that may not belong in the main release (which is why
> we didn't want the Kafka Bridge to be included as part of the main release)
>
> Having a new sub project could be nice so people can optionally grab
> plugins only if they want them and this would allow the plugins could be
> updated and released on their own schedule. The main downside I see with
> the sub project approach is trying to keep plugins in sync with the broker
> version. If we don't end up bundling the plugins with the broker itself
> then we need to figure out how to handle compatibility across releases.
>
> On Tue, May 28, 2019 at 10:50 PM Justin Bertram wrote:
>
> > With the impending support for metrics plugins [1] as well as other
> > pluggable components which have been discussed in the past (e.g. Kafka
> > bridge [2] proposed by Mike Pearce) I think it would great to have an
> > official place where these things could be hosted and potentially included
> > as part of a broker release. Does anybody have any opinion on this?
> >
> >
> > Justin
> >
> > [1] https://github.com/apache/activemq-artemis/pull/2681
> > [2] https://issues.apache.org/jira/browse/ARTEMIS-1478
> >
--
Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by Clebert Suconic <cl...@gmail.com>.
We could have a separate repository for these plugins...
They could be part of our binary distribution (as being consumed), and
we could have special CLI options to activate them.
e.g.: ./artemis create /folder --plugin prometheus
The prometheus plugin would be only applied if such option was applied.
On Wed, May 29, 2019 at 6:54 AM Christopher Shannon
<ch...@gmail.com> wrote:
>
> This sounds good to me, I think it would be good to have some way to keep a
> collection of plugins that is easy for people to find. I guess they could
> either go into a new directory under the current Artemis build and each
> have their own sub module/ jar or they could live by themselves in a new
> sub project.
>
> I'm not really sure which approach would be best. Having new sub modules
> makes it easy to keep the plugins in sync with the broker but can bloat the
> release with things that may not belong in the main release (which is why
> we didn't want the Kafka Bridge to be included as part of the main release)
>
> Having a new sub project could be nice so people can optionally grab
> plugins only if they want them and this would allow the plugins could be
> updated and released on their own schedule. The main downside I see with
> the sub project approach is trying to keep plugins in sync with the broker
> version. If we don't end up bundling the plugins with the broker itself
> then we need to figure out how to handle compatibility across releases.
>
> On Tue, May 28, 2019 at 10:50 PM Justin Bertram <jb...@apache.org> wrote:
>
> > With the impending support for metrics plugins [1] as well as other
> > pluggable components which have been discussed in the past (e.g. Kafka
> > bridge [2] proposed by Mike Pearce) I think it would great to have an
> > official place where these things could be hosted and potentially included
> > as part of a broker release. Does anybody have any opinion on this?
> >
> >
> > Justin
> >
> > [1] https://github.com/apache/activemq-artemis/pull/2681
> > [2] https://issues.apache.org/jira/browse/ARTEMIS-1478
> >
--
Clebert Suconic
Re: [DISCUSS] Component/Plugin repository
Posted by Christopher Shannon <ch...@gmail.com>.
This sounds good to me, I think it would be good to have some way to keep a
collection of plugins that is easy for people to find. I guess they could
either go into a new directory under the current Artemis build and each
have their own sub module/ jar or they could live by themselves in a new
sub project.
I'm not really sure which approach would be best. Having new sub modules
makes it easy to keep the plugins in sync with the broker but can bloat the
release with things that may not belong in the main release (which is why
we didn't want the Kafka Bridge to be included as part of the main release)
Having a new sub project could be nice so people can optionally grab
plugins only if they want them and this would allow the plugins could be
updated and released on their own schedule. The main downside I see with
the sub project approach is trying to keep plugins in sync with the broker
version. If we don't end up bundling the plugins with the broker itself
then we need to figure out how to handle compatibility across releases.
On Tue, May 28, 2019 at 10:50 PM Justin Bertram <jb...@apache.org> wrote:
> With the impending support for metrics plugins [1] as well as other
> pluggable components which have been discussed in the past (e.g. Kafka
> bridge [2] proposed by Mike Pearce) I think it would great to have an
> official place where these things could be hosted and potentially included
> as part of a broker release. Does anybody have any opinion on this?
>
>
> Justin
>
> [1] https://github.com/apache/activemq-artemis/pull/2681
> [2] https://issues.apache.org/jira/browse/ARTEMIS-1478
>