The changes about feature loading are not yet in the trunk but I
attached them as a patch to:
https://issues.apache.org/jira/browse/KARAF-1296
So you can already try it. Guillaume is currently reviewing the changes
so I wait a bit more what his result is.
The patch also contains a test where
I haven't had a lot of time to look at karaf recently but I really thought I
left it so that the build worked in one step, and for this reason I did NOT use
the new packagings in the build but instead used pom packaging and explicitly
called out the mojos that the packaging uses. This is infuri
Christian:
I am curious
1) are your changes are in current karaf 3 snapshot?
2) do you have example/test project that shows how to build
karaf distro w/o startup.properties, with minimal feature=framework
only?
3) or is the idea discarded?
Thank you,
Andrei
right, but there is a need to supply an s3:// wagon:
http://team.ops4j.org/browse/PAXURL-188
Original Message
Subject: Re: org.ops4j.pax.url.mvn amazon s3 repo authentication?
From: Freeman Fang
To: u...@karaf.apache.org
Cc: dev@karaf.apache.org
Date: Tue 22 May 2012 09:18:47
Yes that is right. I will handle it in this jira. I think I also did the
other fixes there.
Christian
Am 23.05.2012 16:16, schrieb Guillaume Nodet:
Btw, I don't think there's a need to open new JIRA give KARAF-647 is
still in progress.
--
Christian Schneider
http://www.liquid-reality.de
O
On Wednesday, May 23, 2012 04:04:05 PM Christian Schneider wrote:
> I agree. We should redcommend the packaging feature for our end users
> but not use it in our own build.
With the caveat that it would good to have an it test or similar that uses
the plugin like that to make sure it works proper
Btw, I don't think there's a need to open new JIRA give KARAF-647 is
still in progress.
On Wed, May 23, 2012 at 3:18 PM, Guillaume Nodet wrote:
> Not sure, I haven't looked at how the subshells are implemented yet,
> but I suppose it modifies the session variable SCOPE to reduce the
> default com
I agree. We should redcommend the packaging feature for our end users
but not use it in our own build.
So we have a simple build and people have the convenience of the plugin.
Christian
Am 23.05.2012 15:54, schrieb Guillaume Nodet:
Right, I agree, we could just change the way the assembly is b
Right, I agree, we could just change the way the assembly is build and
not use our own plugin to simplify the build.
What I meant was I don't think we really want to rework the plugin to
get rid of the new packaging.
On Wed, May 23, 2012 at 3:50 PM, Daniel Kulp wrote:
> On Wednesday, May 23, 2012
On Wednesday, May 23, 2012 03:42:17 PM Andreas Pieber wrote:
> Well... one option might be to release the required components and the
> karaf-maven-plugin seperatly. Maybe we're able to split those
> components away far enough to release them separately... I think we
> might be able to reduce this
Also thought about that but the karaf-maven-plugin needs the feature
service which is a core part of karaf. So I am not sure this would work.
Christian
Am 23.05.2012 15:42, schrieb Andreas Pieber:
Well... one option might be to release the required components and the
karaf-maven-plugin sepera
Well... one option might be to release the required components and the
karaf-maven-plugin seperatly. Maybe we're able to split those
components away far enough to release them separately... I think we
might be able to reduce this to a hand of components... Just an idea
we would definitely need to d
No it doesn't. We've lived with that in ServiceMix for a few years,
so I'm well aware of the pain btw.
On Wed, May 23, 2012 at 3:26 PM, Daniel Kulp wrote:
> On Wednesday, May 23, 2012 10:47:46 AM Guillaume Nodet wrote:
>> I think we need at least a working two step build.
>> It can be done using
On Wednesday, May 23, 2012 10:47:46 AM Guillaume Nodet wrote:
> I think we need at least a working two step build.
> It can be done using profiles in the root pom and it has to work from
> a clean repo.
The problem is that that will likely make the release process much harder.
Not sure if the m
Not sure, I haven't looked at how the subshells are implemented yet,
but I suppose it modifies the session variable SCOPE to reduce the
default commands set.
I would think that the current subshell scope should be added to the
beginning of that list instead of at the end (if that's how it works).
I also encountered these bugs but was not sure how to fix that.
Can you open a jira issue? If you have any ideas how to solve it I can
do the implementation.
Christian
Am 23.05.2012 14:29, schrieb Guillaume Nodet:
I've seen a couple of problems in trunk with subshells:
karaf@root()> instan
I've seen a couple of problems in trunk with subshells:
karaf@root()> instance
karaf@root(instance)> list
that one executes bundle:list instead of instance:list. I suppose the
scope is not correctly updated.
karaf@root()> admin:connect foo
this one fails because ssh is not the command anymore,
I think we need at least a working two step build.
It can be done using profiles in the root pom and it has to work from
a clean repo.
So the first step is to build the maven plugin and the required
dependencies, the second one is to build everything (easier than just
building the rest).
The second
We already talked about the build on irc but to sum it up here also on
the list:
I tested a build of trunk with a clean maven repo. I did not work out of
the box as the karaf-maven-plugin is required when building the feature
files. As maven checks that very early the karaf maven plugin is not
19 matches
Mail list logo
