| Re: [che-dev] Adding Arquillian Smart Testing to Che base distribution? |
Hi guys,thanks for your thoughts and ideas. Kind of functionality that would allow users to install any plugin on demand would be the best. But as Stevan mentioned it's not available now.So I had two options - to push it to the RH Che or to the community. I chose the community project as Smart Testing is an open source project that can be used by everyone and is not anyhow tied to OSIO or any other RH project. I also believe that it is an interesting and useful tool that would be helpful to everyone who is using Che.I'm open to any solution that would solve this maintainability/pluggability problem. The proposed solution that the plugin would live in an external repository and would be released separately would solve one problem - the code wouldn't be inside of the Che project - but it could cause a new one. When I was implementing the code, I've been trying to avoid using the code duplication. As a result, I'm using inner Che's abstract classes across the whole plugin. In other words, I heavily depend on the Che code and even a small refactoring change could break the plugin. If there happens such a change, then the plugin won't be compatible with the Che and (if you would add it into the assembly), then the whole assembly process would fail.Then, there would be again the question, who is responsible for this compatibility and how I could detect the incompatibility issues. Apart from that, I couldn't find any stable API that I could use (on the low level of test runner), so the entry points that I'm using can be completely changed or removed.Another potential issue is a small change that won't break the compatibility, but alter the behavior. Then, as it is using current test runner, it can break this functionality as well.What do you think about my concerns? Are they valid or am I missing something there...? Maybe I just don't understand the way you want to add the plugin to the assembly.ThanksHave a nice dayMatous Jobanek
--
Software Engineer
Devtools-test / Arquillian
Red Hat Czech s.r.o., Purkynova 111, 612 45 Brno, Czech Republic
Email: mjobanek@xxxxxxxxxx
irc: mjobanekOn Mon, Dec 11, 2017 at 3:46 PM, Gennady Azarenkov <gazarenk@xxxxxxxxxx> wrote:On Mon, Dec 11, 2017 at 4:16 PM, Gorkem Ercan <gorkem.ercan@xxxxxxxxx> wrote:
On 11 Dec 2017, at 5:46, Gennady Azarenkov wrote:
My (raw) proposal is to have well visible but other place to let community
contribute with minimum impact on maintaining the project,
some sort of "incubator", as well as a procedure to pick the plugin from
and (if needed) push the plugin back from/to incubation.
Something like che-incubator GH org (or sub-org) would work.
The root issue is plugins are required to be built into assemblies, that needs to change.
Until that happens I recommend we ask plugin developer to publish their component to maven central
and create a PR for including the plugin as a maven dependency into the assembly. Every time we
receive such a request or an update to existing one we will have to do a CQ but perhaps this forces
us to act quickly about extensions :)
Independently on how good extension framework is we have the question:
What we include in Che release by default?Another question to answer it:What we recommend to community in order to test and let other to test theirs Che things?I tried to address these questions.Actually, if maintainers are comfortable to include everything proposed as a PR into Che default assembly - it answers both.But, according to Sergii's message, it is not the case.
So contributor will ba able to request for repository inside, create and
own the code, keep updated (so it can be built and tested) assembly with
the plugin,
take care of documentation about its configuration etc and e2e/integration
tests.
And some moment offer it to the che...
Thanks,
Gennady
On Mon, Dec 11, 2017 at 11:30 AM, Sergii Kabashniuk <skabashn@xxxxxxxxxx>
wrote:
For me, one of the critical question with this topic is a support of code.
Who will support it, how? What if maintainer becomes unavailable for a
long period?
What are the criteria for removing the code from the repository, for the
case if the community (maintainer) lost them interest?
On Sat, Dec 2, 2017 at 12:30 AM, Brad Micklea <bmicklea@xxxxxxxxxx> wrote:
Thanks for the explanation. That doesn't sound too painful considering
where we are now. I'll +1 the addition because I think there's real
developer value here. What do others think?
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_______________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_____________________________________________________________________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev
_________________
che-dev mailing list
che-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/che-dev