Just publishing a new SNAPSHOT if you can test with it.
Regards
JB
On 10/13/2016 08:35 PM, Markus Rathgeb wrote:
-- Container 4.0.8: the ARM/Solaris issue should be fixed now (that was an
important regression in 4.0.6 & 4.0.7). Other fixes and upgrades are coming
too.
I tested the recent snap
> -- Container 4.0.8: the ARM/Solaris issue should be fixed now (that was an
> important regression in 4.0.6 & 4.0.7). Other fixes and upgrades are coming
> too.
I tested the recent snapshot, but this does not work for me.
See JIRA
fully agree on the scr ones and those posix commands.
We don't need to re-invent the wheel a fifth time ;)
regards, Achim
2016-10-13 11:47 GMT+02:00 Guillaume Nodet :
> 2016-10-13 11:28 GMT+02:00 Achim Nierbeck :
>
> > Just one question,
> > what's the effect on already existing Karaf commands
On Thu, 13 Oct 2016 12:18:04 +0200
Stephen Kitt wrote:
> I've been working on improving feature-generate-descriptor to support
> our use-cases, and I am still planning on improving it (e.g. to handle
> aggregate feature repositories). We still need hand-written
> feature.xml snippets in some cases
Hi Guillaume,
On Thu, 13 Oct 2016 11:07:50 +0200
Guillaume Nodet wrote:
[...]
> So I'd like to propose to get rid of the feature-generate-descriptor
> from inside the feature packaging and replace it with the verify goal
> to validate the hand-written features instead.
I've started migrating Ope
2016-10-13 11:28 GMT+02:00 Achim Nierbeck :
> Just one question,
> what's the effect on already existing Karaf commands and those completions
> etc.
> If that is not affected at all I've got no complaints ;)
>
Existing commands are not affected.
To achieve the above, I'm using a completer which
+1
It would remove or at least limit the generate feature execution. It's too
simple and never cleanly cover the use cases. Writing the features XML by hand
is always better IMHO.
Regards
JB
On Oct 13, 2016, 11:08, at 11:08, Guillaume Nodet wrote:
>The feature packaging is a nice thing, as
Just one question,
what's the effect on already existing Karaf commands and those completions
etc.
If that is not affected at all I've got no complaints ;)
regards, Achim
2016-10-12 18:41 GMT+02:00 Guillaume Nodet :
> The problem is to obtain the list of scripts that needs to be loaded
> someho
Hi,
as I'm the one with the most pain right now, I'm +1 on a pure validation
goal.
OTH I know a lot of people use the Feature generation as a starting point
to actually get going.
Especially since the "hand" writing for starters of using Karaf is
cumbersome in the beginning.
May I introduce anothe
I have 2 things to say to that
- I agree with all the pain points you've identified (experienced them
myself)
- I'd prefer to fix things instead of claim them useless due to
malfunctioning
Perhaps a middle ground would be a good starting point? Something like how
bndrun resolution works. I mean:
What do you expect ?
Hibernate has its own features:
http://repo1.maven.org/maven2/org/hibernate/hibernate-osgi/5.2.3.Final/hibernate-osgi-5.2.3.Final-karaf.xml
Try
> feature:install wrap
> repo-add hibernate 5.2.3.Final
> feature:install hibernate-orm/5.2.3.Final
2016-10-13 10:48 GMT+02:00
Good idea in my opinion.
Feature descriptors should be (are) first-class artifacts and should be
carefully maintained. Relying simply on underlying dependencies of another
category (like Maven) is not enough.
Manual creation + build time verification is much better idea.
regards
Grzegorz Grzybek
The feature packaging is a nice thing, as it allows automatic attachment of
the feature file.
However, it always use the feature-generate-descriptor, which produces a
lot of weird results.
Afaik, the feature packaging is not much used and all projects i've seen,
such as pax projects, camel, cxf, an
Hi ,
It is planned the integration Hibernate 5 in version 4.1.0?
Best Regards,
-
CTO , JeetConsulting.
Analyze now your Maven Java projects' dependencies , here
--
View this message in context:
http://karaf.922171.n3.nabble.com/Hibernate-5-tp4048343.html
Sent from the Karaf - Dev mailin
Agree, but it requires a Karaf change. So, in the mean time, I agree
with Achim's change.
Regards
JB
On 10/13/2016 09:14 AM, Christian Schneider wrote:
I see the need to deploy features with your own config.. or maybe even
no config at all to install but not activate the decanter module.
If th
I see the need to deploy features with your own config.. or maybe even
no config at all to install but not activate the decanter module.
If there is no other way I agree with this change.
It sounds a bit like a generic problem though. On one hand we have the
requirement for a very nice experien
16 matches
Mail list logo