Hi, "Ian, if you agree would you take care of 1) or should I prepare a suggested patch, slightly rearranged from SLING-5646?"
Yes, I can do this. https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs/mom-api -> contrib/commons/mom/api https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs/activemq -> contrib/commons/mom/jms https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs/core -> contrib/??? https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs/it -> contrib/??? https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs/it-services -> contrib/??? While I understand it makes sense to split the mom-api from something using it, (in this case jobs) scattering the something that uses it and the integration tests doesn't make sense. Without the it and it-services projects there is no proof any of it works, other than trivial Unit test coverage, and the only known consumer of the API at present is message oriented jobs implementation. https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs/core -> contrib/commons/mom/examples/jobs/core/??? https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs/it -> contrib/commons/mom/examples/jobs/it/??? https://github.com/ieb/sling/tree/jobs_28/contrib/extensions/jobs/it-services -> contrib/commons/mom/examples/jobs/it-services/??? wdyt? The code doesn't need/use Sling, JCR or Oak as can be seen from the crankstart model [1] used in the Integration tests, as such it could live in it's own repo. I would not want to increase the build time of Sling any further unecessarilly. Best Regards Ian 1 https://github.com/ieb/sling/blob/jobs_28/contrib/extensions/jobs/it/src/test/resources/provisioning-model/jobs-runtime.txt On 21 July 2016 at 08:58, Carsten Ziegeler <cziege...@apache.org> wrote: > > On Thu, Jul 21, 2016 at 9:16 AM, Carsten Ziegeler <cziege...@apache.org> > wrote: > >> ...I assume you mean committing it to contrib, right?... > > > > I thought bundles/commons as the MoM stuff is not sling-specific, but > > if you prefer contrib/commons as a first step I'm fine with that. > > > > Yes, contrib/commons - new stuff should usually go into contrib first. > We can further experiment there, see whether there is larger interest etc. > > > Carsten > > -- > Carsten Ziegeler > Adobe Research Switzerland > cziege...@apache.org > >
