Done.
On Fri, Jan 12, 2018 at 7:05 AM, Steve Ebersole wrote:
> Can you get those done by Wednesday? If so, I think that's a good plan.
> I can't think of anything else for you to work on atm for 5.3. Maybe once
> we start to hear back about the remaining outstanding challenges...
>
> On Thu, J
Great questions. There'd be clear separation of concerns in this:
* Docker
o Plain 'ole Karaf
o Install our features.xml
o Install a test bundle that enables the ability to remotely
execute some flows. I had been thinking along the lines of what
we do in the O
I believe most of this is already handled for various build tools (like the
gradle docker plugin) and simplified by docker image repos (bintray, e.g.).
But this is a good point. I'd be interested to see if you've done this
before Brett..
On Fri, Jan 12, 2018 at 2:56 PM Gunnar Morling wrote:
>
Brett,
What's still unclear to me is when going the Docker route, won't you still
need some code which deploys your tests to Karaf, runs them there and
fetches the test results, so e.g. your Gradle build will fail if there are
test failures? Would you envision to write these bits yourself? And
wou
Hey all,
> at least plan a 5.2.13 release soon to release all the fixes already in?
+1 for doing another 5.2 release if there are lots of issues already merged
and 5.3 isn't going through the door very soon. It'd be great to get those
nice fixes you all did out to users.
I realize I won't be th
I guess the way I'm looking at this is Docker will be primarily used by
Jenkins, and myself or anyone working directly on hibernate-osgi
itself. Otherwise, it'll be disabled by default and hidden behind a
profile. We'll make sure that most contributors running the entire
Hibernate test suite
On 12 January 2018 at 18:04, Steve Ebersole wrote:
> I do not. But from what I understand its trivial to install on Fedora,
> unlike some other tools y'all like to use ;)
Right, this one is easy to install :)
Although my questions was more about if you're all ok with that. I
know personally I'v
I already have Docker running on my machine, so it seems not a big issue
for me,but not sure about the impact for others.
Anyway It's worth giving a try.
On 12 January 2018 at 17:54, Sanne Grinovero wrote:
> On 12 January 2018 at 17:32, Brett Meyer wrote:
> > If I don't have time to contribute
I do not. But from what I understand its trivial to install on Fedora,
unlike some other tools y'all like to use ;)
On Fri, Jan 12, 2018 at 11:55 AM Sanne Grinovero
wrote:
> On 12 January 2018 at 17:32, Brett Meyer wrote:
> > If I don't have time to contribute to Pax Exam, I certainly don't h
On 12 January 2018 at 17:32, Brett Meyer wrote:
> If I don't have time to contribute to Pax Exam, I certainly don't have
> time to start a new project haha...
>
> And realistically, that "something new" would likely involve containers
> anyway.
>
> At this point, mostly a question of 1) status quo
If I don't have time to contribute to Pax Exam, I certainly don't have
time to start a new project haha...
And realistically, that "something new" would likely involve containers
anyway.
At this point, mostly a question of 1) status quo, 2) Docker (or any
other container-based solution), or 3)
Ok, looks like you really should start something new :)
Hopefully many of those other annoyed Karaf developers will follow.
On 12 January 2018 at 13:59, Brett Meyer wrote:
> Plus, for me, it's more a question of time. I only have a bit available
> for open source work these days, and I'd rather
On 12 January 2018 at 16:58, Vlad Mihalcea wrote:
> Sure, we need to profile it first.
I had started to create a micro-benchmark for it; unfortunately I had
to get back on more urgent things, but if someone is willing to let it
grow further, it's on github:
- https://github.com/Sanne/orm-boostra
Sure, we need to profile it first.
>From what our users have told us, getting the metadata from the database
takes some time and my
goal was to identify whether we can do something about that.
I'll come back once I have more info.
Vlad
On Thu, Jan 11, 2018 at 3:05 PM, Sanne Grinovero
wrote:
>
Can you get those done by Wednesday? If so, I think that's a good plan. I
can't think of anything else for you to work on atm for 5.3. Maybe once we
start to hear back about the remaining outstanding challenges...
On Thu, Jan 11, 2018 at 5:44 PM Gail Badner wrote:
> HHH-12150 is currently set
Personally I have had problems with Arquillian in the past. It was either
setting up CDI tests or setting up OSGi tests (or maybe both).
I am open to any suggestions that make this less brittle or easier to work
with
On Fri, Jan 12, 2018 at 5:34 AM Sanne Grinovero wrote:
> +1 to explore altern
Plus, for me, it's more a question of time. I only have a bit available
for open source work these days, and I'd rather spend that knocking out
some of the hibernate-osgi tasks we've had on our plate for a while. I
unfortunately don't have anything left to contribute to Pax Exam itself,
assum
Sorry Gunnar/Sanne, should have clarified this first:
We actually used Arquillian before Pax Exam, and the experience was far
worse (somewhat of a long story)...
> Pax Exam was just "helping" to deploy/run things in Karaf, so I can't
imagine using Karaf without the helpers being a walk in the
2018-01-12 12:59 GMT+01:00 Sanne Grinovero :
> Personally I'm neutral. I surely wouldn't want to manage our own
> Artifactory, but since JFrog will do that I'm not concerned about the
> platform management being horrible.
>
> Artifactory looks better, OSSRH has the benefit of possibly having
> bet
Firstly, if anyone looked at the Jira, you would see that Bintray simply
won't work. They have a 10G storage limit. That's something we would hit
pretty soon, depending on which projects moved there. Also, getting in
touch with them for any kind of support has be a pretty big pain; its
generally
Personally I'm neutral. I surely wouldn't want to manage our own
Artifactory, but since JFrog will do that I'm not concerned about the
platform management being horrible.
Artifactory looks better, OSSRH has the benefit of possibly having
better integration with Maven.
There are some benefits on s
Well done, thanks a lot.
On Fri, Jan 12, 2018 at 8:12 AM, Yoann Rodiere wrote:
> Quick update: the priority plugin seems to be working fine, and I disabled
> the Heavy Job plugin. It turns out the Heavy Job plugin was preventing the
> Amazon EC2 plugin to spin up new slaves, probably because the
+1 to explore alternatives to Pax Exam, but I'd be wary of maintining
our own test infrastructure.
Pax Exam was just "helping" to deploy/run things in Karaf, so I can't
imagine using Karaf without the helpers being a walk in the park; e.g.
having to deal with HTTP operations comes with its own bag
Hi Brett,
We also had our fair share of frustration with Pax Exam in HV, and I was
(more than once) at the point of dropping it.
Docker could work, but as you say it's a bit of a heavy dependency, if not
required anyways. Not sure whether I'd like to add this as a prerequisite
for the HV build to
Quick update: the priority plugin seems to be working fine, and I disabled
the Heavy Job plugin. It turns out the Heavy Job plugin was preventing the
Amazon EC2 plugin to spin up new slaves, probably because the Amazon EC2
plugin only saw two empty slots on an existing slave and couldn't
understand
25 matches
Mail list logo
