Re: Karaf: Could not resolve mvn:org.apache.felix/org.apache.felix.framework/4.2.1

[PashaTurok]

No, I dont. And I've never had any network problems with my computer although
I work with very different protocols.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-Could-not-resolve-mvn-org-apache-felix-org-apache-felix-framework-4-2-1-tp4039578p4039601.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Karaf: Could not resolve mvn:org.apache.felix/org.apache.felix.framework/4.2.1

[Achim Nierbeck]

Is there something else showing besides that message?
Does the logfile in data/logs show anything?

On windows and linux, are you having write restrictions on the drive you
placed karaf on (for example been installed by an Administrative account)

regards, Achim


2015-04-13 6:44 GMT+02:00 Jean-Baptiste Onofré :

> Hi,
>
> do you use a proxy to access to the Internet ?
>
> Regards
> JB
>
>
> On 04/12/2015 10:09 PM, PashaTurok wrote:
>
>> @jbonofre Sorry, I dont understand you. I've tried apache karaf 3.0.3 on
>> windows xp + oracle jdk 8 - the result is the same. Coudn't resolve.
>>
>>
>>
>> --
>> View this message in context: http://karaf.922171.n3.nabble.
>> com/Karaf-Could-not-resolve-mvn-org-apache-felix-org-
>> apache-felix-framework-4-2-1-tp4039578p4039590.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>>
> --
> Jean-Baptiste Onofré
> jbono...@apache.org
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: Karaf and Docker

[Achim Nierbeck]

I can't agree more ... and some questions on stackoverflow or this
mailinglist just reflect that ...
"please solve my issue for me, cause I forgot to use my brain today" :D

regards, Achim

2015-04-13 0:44 GMT+02:00 Ryan Moquin :

> Serge,
>
> Package the world applications were able to be built easily before Docker
> was around.  Docker is simply a different way of deploying an application
> virtually.
>
> In my experience, developers who "package the world" with their code are
> usually either biased against modularity or just don't feel like putting
> forth the effort.  Many technologies in use today take effort to figure
> out.  A lot of developers seem to feel that any technology that requires
> effort above the maven shade plugin or using shell scripts to dump all
> their jars to a server isn't worth their time.
>
> Developers that care about the quality of the code or applications they
> produce won't be deterred from a technology they believe will help them
> make better applications just because it takes a little bit of effort.  How
> did less experienced developers manage to survive when the only real
> choices for writing software was assembly, c or c++?
>
> Ryan
> On Apr 11, 2015 9:53 PM, "Serge Huber"  wrote:
>
>> Very interesting thread guys :)
>>
>> Actually I recently started a project integrating Karaf with
>> ElasticSearch and for me it was a little like what you guys are describing
>> in this thread. ES, at least in the early versions is quite monolithic and
>> it would clearly benefit from a framework such as OSGi. For example, the
>> clustering technology is quite interesting but why can't it be reused
>> without all the other stuff ? Or maybe you want to wire things a little
>> differently ? Not have everything directly listen to ports without any
>> security but be able to plugin whatever filter or modules you need ?
>>
>> Personally I think that what is really needed in OSGi is better tooling,
>> especially for making it a lot simpler to build high quality and
>> minimalistic bundles. Using the maven-bundle-plugin or the shader-plugin is
>> quite tedious and possibly error prone. I've built my own Maven plugin on
>> top of the bundle plugin so that it can handle a lot more resources
>> (including JSPs that include taglibs for example) and that also tries to be
>> smarter at generating import-package statements. This makes it easier for
>> OSGi newbies to adopt the technology.
>>
>> I'm also worried that the initial learning curve of OSGi might be putting
>> less experienced developers off and more towards package-the-world
>> solutions such as Docker, which while acceptable for some cases such as
>> continuous integration, could also be dangerous if not maintained properly.
>>
>> Regards,
>>   Serge
>>
>> Le 11 avr. 2015 à 19:43, Niels  a écrit :
>>
>> Could not agree more Achim. Good fad indicators are high promises which
>> are designed to target the ultimate need of decision makers to deliver
>> software quicker and cheaper. Just rewind 10 years and we will find the
>> exact same promises were made at the start of the SOA hype which are now
>> touted by the microservices believers. At the end of the day nothing will
>> prevent people from doing something really badly.
>>
>> I can see the value of docker but unless one really has all the lifecycle
>> ducks in a row I would not go down the path and containerise the all and
>> sundry.
>>
>> Cheers,
>> Niels
>>
>> On 12 Apr 2015, at 08:28, Ryan Moquin  wrote:
>>
>> I used to work somewhere with other developers who always became very
>> spiritual about whatever the latest "cool" developer technology or
>> methodology is.  Microservices was one of them.  It always made me laugh
>> when I was told how super efficient and streamlined it was over any other
>> solution because every fat jar deployed (Maven shade plugin abuse in order
>> to be lazy) was between 500Mb and 1.7Gb.  So much for being a
>> "micro"-service.
>> On Apr 8, 2015 2:55 PM, "Achim Nierbeck"  wrote:
>>
>>> I'm very ambivalent regarding this topic.
>>>
>>> On one hand I see a lot of move to Docker as heading for the holy grail
>>> on fixing all the issues we had in the past. #FAIL
>>> On the other hand I see some benefits of it, but still haven't found the
>>> concrete use-case where it did top a bar-metal or bare virtualized machine.
>>>
>>> It's absolutely true that it does have some benefits for easier
>>> deployment of "Infrastructure" but I also see a lot of failures in usage of
>>> Docker. Just to mention one, where did the init daemon go, it's been there
>>> for a reason in linux OS's and now we run applications on top of the system
>>> without it ... I don't feel comfortable with that, especially if you don't
>>> have a JVM as process running which starts spawning other processes (one
>>> might remember the zombie processes).
>>> In the end there are mostly more slopy/lazy people around[1] trying to
>>> get something going, that's why Docker will be sufficient en

Re: Deploying applications on Karaf

[Achim Nierbeck]

Hi Ryan,

some comments inline

regards, Achim


2015-04-13 0:14 GMT+02:00 Ryan Moquin :

> Don't get me, features are a ton of help.  :)  I could maintain the
> features myself, I just hate to have to keep two lists of dependencies.
> The reason that the karaf maven plugin is a little tough sometimes is
> because it's hard to make sure that you don't end up with bundles in a
> generated feature that should come from a dependent feature without making
> everything provided.  Making most of the dependencies provided makes it
> hard to have transitive dependencies available in project dependencies
> because they are marked provided in the other poms.  There is probably a
> better way to handle it that I haven't figured out yet.  My project is
> growing rapidly so I am trying to leverage whatever tools I can to keep my
> features clean and not have to spend lots of time on them.
>
> Have you tried to add features as dependencies to your pom. AFAIK those
should show up as dependencies in the generated features.xml. If not we
just found a new use-case for the maven plugin and you could open an issue
for it ;)


> One thing I've been wrestling with (not sure if this has been improved in
> Karaf 4)
> is figuring out how to upgrade features and handle undeploying features..
> I've played around with it but I guess I'm not sure I understand the proper
> way to do it.  Such as if you had an application deployed in an environment
> and wanted to upgrade a feature, do you have to install the new features
> and uninstall the old one?  When I've tried to uninstall a feature
> previously, it didn't seem like everything got removed.
>
Till Karaf 4, you explicitly need to uninstall transitive features because
the features installer used to be quite dumb and therefore doesn't know of
possible other dependencies on this feature.
With Karaf 4 this will improve quite a bit.


> I want want to be able to do incremental upgrades of my app but not sure
> the best way to achieve that with features.  :)  I've done quite a lot of
> research on it but haven't quite narrowed down a concrete way to do it (I
> mean beyond manually upgrading individual bundles in the karaf console.)
>
> Upgrades is still an "open" field, with Karaf 4 I think it will be easier.


> Our Bamboo instance has access to the internet.  I think it hangs right at
> the beginning of Pax Exam starting up.  It's such a pain to deal with our
> Bamboo EC2 instance that I haven't been able to find out why it's hanging
> yet.
>
maybe post this as a question at the OPS4j list with some more details of
the logfiles.




> Ryan
> On Apr 12, 2015 2:34 AM, "Achim Nierbeck"  wrote:
>
>> Hi Ryan,
>>
>> see comments inline.
>>
>> regards, Achim
>>
>>
>> 2015-04-12 0:37 GMT+02:00 Ryan Moquin :
>>
>>> Thanks, Achim.  I am using a custom Karaf distribution, but maintaining
>>> deployment flexibility using features feels a little tougher than it feels
>>> like it should be (I don't have any better ideas).
>>>
>> That's strange, cause features are there to make life easier not harder.
>> Make sure you cut the features right, not to big but also not to small
>> (like one bundle, one feature). Usually it helps to create those feature
>> files yourself as the plugin can't estimate what your intension of this
>> combination of bundles is.
>>
>>
>>>   I also have issues with my Karaf integration tests in Bamboo.  Paxexam
>>> seems to not be able to initialize properly for who knows what reason.
>>> Another problem is that I seem to run into a lot of problems in the tests
>>> and can't seem to find anything in the output or Karaf love that
>>> indicate.the problem.  If I run it normally in Karaf, I usually get clued
>>> into what the issue is.
>>>
>> Now that could be addressed. First of all, does it work for you on your
>> machine? Is Bamboo capable of connecting to the internet.
>> Is maven capable of connecting to the required repositories. Do you have
>> all dependencies defined in your POM, so the configuration section of the
>> test does find those (combined with the depends-maven-plugin)
>>
>>
>>> One last thing is that since my development shop uses MacOSx, Docker
>>> containers have to be run in a VM which feels silly and is slow.  I don't
>>> have a choice in that manner.
>>>
>> Oh, I'm working with MacOSx too. I know it can be cumbersome but running
>> 4 images in parallel can be done :-)
>>
>>
>>
>>> It would be nice if there was a way to manage feature xml files in a way
>>> that felt more straight forward  Maybe there is and I'm just not aware
>>> of it.
>>>
>> You have the choices, use the karaf maven plugin for generation, or build
>> those yourself. In the end it's up to how you want your application build.
>> But maybe I miss something cause usually you have a certain set of
>> bundles running in your application that need to run anyway. With this
>> setup you can test your application.
>>
>>
>>
>>> On Apr 8, 2015 3:07 PM, "Achim Nierbeck" 
>>> wrote:
>>>
 Hi,
>>

Re: Karaf: Could not resolve mvn:org.apache.felix/org.apache.felix.framework/4.2.1

[Jean-Baptiste Onofré]

Hi,

do you use a proxy to access to the Internet ?

Regards
JB

On 04/12/2015 10:09 PM, PashaTurok wrote:

@jbonofre Sorry, I dont understand you. I've tried apache karaf 3.0.3 on
windows xp + oracle jdk 8 - the result is the same. Coudn't resolve.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-Could-not-resolve-mvn-org-apache-felix-org-apache-felix-framework-4-2-1-tp4039578p4039590.html
Sent from the Karaf - User mailing list archive at Nabble.com.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf and Docker

[Ryan Moquin]

Serge,

Package the world applications were able to be built easily before Docker
was around.  Docker is simply a different way of deploying an application
virtually.

In my experience, developers who "package the world" with their code are
usually either biased against modularity or just don't feel like putting
forth the effort.  Many technologies in use today take effort to figure
out.  A lot of developers seem to feel that any technology that requires
effort above the maven shade plugin or using shell scripts to dump all
their jars to a server isn't worth their time.

Developers that care about the quality of the code or applications they
produce won't be deterred from a technology they believe will help them
make better applications just because it takes a little bit of effort.  How
did less experienced developers manage to survive when the only real
choices for writing software was assembly, c or c++?

Ryan
On Apr 11, 2015 9:53 PM, "Serge Huber"  wrote:

> Very interesting thread guys :)
>
> Actually I recently started a project integrating Karaf with ElasticSearch
> and for me it was a little like what you guys are describing in this
> thread. ES, at least in the early versions is quite monolithic and it would
> clearly benefit from a framework such as OSGi. For example, the clustering
> technology is quite interesting but why can't it be reused without all the
> other stuff ? Or maybe you want to wire things a little differently ? Not
> have everything directly listen to ports without any security but be able
> to plugin whatever filter or modules you need ?
>
> Personally I think that what is really needed in OSGi is better tooling,
> especially for making it a lot simpler to build high quality and
> minimalistic bundles. Using the maven-bundle-plugin or the shader-plugin is
> quite tedious and possibly error prone. I've built my own Maven plugin on
> top of the bundle plugin so that it can handle a lot more resources
> (including JSPs that include taglibs for example) and that also tries to be
> smarter at generating import-package statements. This makes it easier for
> OSGi newbies to adopt the technology.
>
> I'm also worried that the initial learning curve of OSGi might be putting
> less experienced developers off and more towards package-the-world
> solutions such as Docker, which while acceptable for some cases such as
> continuous integration, could also be dangerous if not maintained properly.
>
> Regards,
>   Serge
>
> Le 11 avr. 2015 à 19:43, Niels  a écrit :
>
> Could not agree more Achim. Good fad indicators are high promises which
> are designed to target the ultimate need of decision makers to deliver
> software quicker and cheaper. Just rewind 10 years and we will find the
> exact same promises were made at the start of the SOA hype which are now
> touted by the microservices believers. At the end of the day nothing will
> prevent people from doing something really badly.
>
> I can see the value of docker but unless one really has all the lifecycle
> ducks in a row I would not go down the path and containerise the all and
> sundry.
>
> Cheers,
> Niels
>
> On 12 Apr 2015, at 08:28, Ryan Moquin  wrote:
>
> I used to work somewhere with other developers who always became very
> spiritual about whatever the latest "cool" developer technology or
> methodology is.  Microservices was one of them.  It always made me laugh
> when I was told how super efficient and streamlined it was over any other
> solution because every fat jar deployed (Maven shade plugin abuse in order
> to be lazy) was between 500Mb and 1.7Gb.  So much for being a
> "micro"-service.
> On Apr 8, 2015 2:55 PM, "Achim Nierbeck"  wrote:
>
>> I'm very ambivalent regarding this topic.
>>
>> On one hand I see a lot of move to Docker as heading for the holy grail
>> on fixing all the issues we had in the past. #FAIL
>> On the other hand I see some benefits of it, but still haven't found the
>> concrete use-case where it did top a bar-metal or bare virtualized machine.
>>
>> It's absolutely true that it does have some benefits for easier
>> deployment of "Infrastructure" but I also see a lot of failures in usage of
>> Docker. Just to mention one, where did the init daemon go, it's been there
>> for a reason in linux OS's and now we run applications on top of the system
>> without it ... I don't feel comfortable with that, especially if you don't
>> have a JVM as process running which starts spawning other processes (one
>> might remember the zombie processes).
>> In the end there are mostly more slopy/lazy people around[1] trying to
>> get something going, that's why Docker will be sufficient enough, while the
>> dynamic and re-configurable service oriented software architecture will be
>> on the decrease. One just needs to follow that Microservice hype.
>> Docker/SpringBoot are just part of this "mantra" :D
>> In the end people will just split their Monolithic rubbish up to
>> different small Monolithic piles of rubbish, but in 

Re: Deploying applications on Karaf

[Ryan Moquin]

Don't get me, features are a ton of help.  :)  I could maintain the
features myself, I just hate to have to keep two lists of dependencies.
The reason that the karaf maven plugin is a little tough sometimes is
because it's hard to make sure that you don't end up with bundles in a
generated feature that should come from a dependent feature without making
everything provided.  Making most of the dependencies provided makes it
hard to have transitive dependencies available in project dependencies
because they are marked provided in the other poms.  There is probably a
better way to handle it that I haven't figured out yet.  My project is
growing rapidly so I am trying to leverage whatever tools I can to keep my
features clean and not have to spend lots of time on them.

One thing I've been wrestling with (not sure if this has been improved in
Karaf 4)
is figuring out how to upgrade features and handle undeploying features..
I've played around with it but I guess I'm not sure I understand the proper
way to do it.  Such as if you had an application deployed in an environment
and wanted to upgrade a feature, do you have to install the new features
and uninstall the old one?  When I've tried to uninstall a feature
previously, it didn't seem like everything got removed.

I want want to be able to do incremental upgrades of my app but not sure
the best way to achieve that with features.  :)  I've done quite a lot of
research on it but haven't quite narrowed down a concrete way to do it (I
mean beyond manually upgrading individual bundles in the karaf console.)

Our Bamboo instance has access to the internet.  I think it hangs right at
the beginning of Pax Exam starting up.  It's such a pain to deal with our
Bamboo EC2 instance that I haven't been able to find out why it's hanging
yet.

Ryan
On Apr 12, 2015 2:34 AM, "Achim Nierbeck"  wrote:

> Hi Ryan,
>
> see comments inline.
>
> regards, Achim
>
>
> 2015-04-12 0:37 GMT+02:00 Ryan Moquin :
>
>> Thanks, Achim.  I am using a custom Karaf distribution, but maintaining
>> deployment flexibility using features feels a little tougher than it feels
>> like it should be (I don't have any better ideas).
>>
> That's strange, cause features are there to make life easier not harder.
> Make sure you cut the features right, not to big but also not to small
> (like one bundle, one feature). Usually it helps to create those feature
> files yourself as the plugin can't estimate what your intension of this
> combination of bundles is.
>
>
>>   I also have issues with my Karaf integration tests in Bamboo.  Paxexam
>> seems to not be able to initialize properly for who knows what reason.
>> Another problem is that I seem to run into a lot of problems in the tests
>> and can't seem to find anything in the output or Karaf love that
>> indicate.the problem.  If I run it normally in Karaf, I usually get clued
>> into what the issue is.
>>
> Now that could be addressed. First of all, does it work for you on your
> machine? Is Bamboo capable of connecting to the internet.
> Is maven capable of connecting to the required repositories. Do you have
> all dependencies defined in your POM, so the configuration section of the
> test does find those (combined with the depends-maven-plugin)
>
>
>> One last thing is that since my development shop uses MacOSx, Docker
>> containers have to be run in a VM which feels silly and is slow.  I don't
>> have a choice in that manner.
>>
> Oh, I'm working with MacOSx too. I know it can be cumbersome but running 4
> images in parallel can be done :-)
>
>
>
>> It would be nice if there was a way to manage feature xml files in a way
>> that felt more straight forward  Maybe there is and I'm just not aware
>> of it.
>>
> You have the choices, use the karaf maven plugin for generation, or build
> those yourself. In the end it's up to how you want your application build.
> But maybe I miss something cause usually you have a certain set of bundles
> running in your application that need to run anyway. With this setup you
> can test your application.
>
>
>
>> On Apr 8, 2015 3:07 PM, "Achim Nierbeck"  wrote:
>>
>>> Hi,
>>>
>>> just recently for a talk with showcase I was thinking about how to
>>> create a CI/CD build pipeline with Karaf. Maybe some of this does help
>>> you.[1]
>>> In the end I ended up with a setup where I have a pre-configured Karaf
>>> (custom build) which is startable as Docker Image or can be used as startup
>>> tar.gz of the Pax Exam integration tests.
>>> Usually camel routes are more about Integration therefore the most
>>> use-cases need to be handled by Integration tests. In those scenarios you
>>> just can't rely only on the camel-core bundles therefore you need more
>>> features just to have your unit tests/integration tests runnable. In those
>>> scenarios I usually suggest build your own distribution on top of Karaf and
>>> use it as your base-image in the pax-exam tests. If there is more external
>>> infrastructure needed I tend to u

Re: Karaf: Could not resolve mvn:org.apache.felix/org.apache.felix.framework/4.2.1

[PashaTurok]

@jbonofre Sorry, I dont understand you. I've tried apache karaf 3.0.3 on
windows xp + oracle jdk 8 - the result is the same. Coudn't resolve.



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-Could-not-resolve-mvn-org-apache-felix-org-apache-felix-framework-4-2-1-tp4039578p4039590.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Karaf on Amazon cloud

[Achim Nierbeck]

Hi Danijel,

that explains it. :-)
Usually you just start with a virtual box from amazon (you may decide on
the OS on it) and from there on, lot's of nice configurations via the web
interface ;)
Tim gave some good hints on what to think of.

regards, Achim


2015-04-12 19:36 GMT+02:00 Basic Danijel :

> Hi Achim and Tim,
>
> Thank you for giving me the hints, which are the good starting point.
>
> Honestly, I do not have experience in working with Amazon cloud. That's
> why I asked for some tutorial/hints, in order to start faster.
>
> Best regards,
> Danijel
> On Apr 12, 2015 4:59 PM, "tvogel"  wrote:
>
>> Danijel,  I have a karaf instance running in Amazon cloud.  There are
>> only three things that caused me a challenge:1) Getting the firewalls right.
>> I setup multiple security profiles by function (public access,
>> deployment, full remote admin) and then applied the appropriate ones.  Be
>> sure to consider file transfer, SSH and remote desktop ports.   You have at
>> two on Amazon, the one in EC2 console and the one in the OS (Windows /
>> Linux).  Depending on the ports used you may also have multiple firewalls
>> on the client side.2) The bundles that need to be loaded either have to
>> be located on the remote host or accessible / visible to maven from the
>> remote host.3) Security for the account that will be running the karaf
>> instance.  This needs to be a non-privileged account with the minimum
>> possible rights.
>> Tim
>>
>> Date: Sun, 12 Apr 2015 05:22:30 -0700
>> From: ml-node+s922171n4039581...@n3.nabble.com
>> To: tvo...@msn.com
>> Subject: Karaf on Amazon cloud
>>
>>
>>
>> Hi all,
>> I'm planning to put some webapp on Amazon cloud. The app is running on
>> Karaf.
>> Does anyone know for some good tutorial which explains how to do that?
>> Regards,
>>
>> Danijel
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> If you reply to this email, your message will be added to
>> the discussion below:
>>
>> http://karaf.922171.n3.nabble.com/Karaf-on-Amazon-cloud-tp4039581.html
>>
>>
>>
>> To unsubscribe from Karaf - User, click here.
>>
>> NAML
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://karaf.922171.n3.nabble.com/Karaf-on-Amazon-cloud-tp4039581p4039584.html
>> Sent from the Karaf - User mailing list archive at Nabble.com.
>>
>


-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Re: Karaf and Docker

[Charlie Mordant]

Hi Serge,

Docker learning curve is lower than the maven-Bnd-pg one? This is just
hype, not reality...

Regards,

2015-04-12 8:19 GMT+02:00 Achim Nierbeck :

> Hi Serge,
>
> since you wanted to integrate ES in Karaf, take a look at decanter. About
> the modularization of ES, I'm with you. A colleague of mine just recently
> talked to Shay Banon about this, but right now they aren't in for OSGi, I
> guess we have to push them there a little.
>
> About tooling, yes I think we could need some better tooling here and
> there, but as usual the devs here just scratch their own itches. So if we
> miss things, since we do it just a bit different or don't feel the pain
> we're not going to build those tools ;)
>
> Personally I think the learning curve used to be steeper, but with
> blueprint and DS it turns out to be much simpler. Until people stumble over
> service-trackers in Activators ;)
>
> The thing about Docker is, it's a nice tool and does help here and there,
> for showcases, POCs and such. In the end people will use
> it as the hammer for every issue they have.
>
> regards, Achim
>
>
> 2015-04-12 3:52 GMT+02:00 Serge Huber :
>
>> Very interesting thread guys :)
>>
>> Actually I recently started a project integrating Karaf with
>> ElasticSearch and for me it was a little like what you guys are describing
>> in this thread. ES, at least in the early versions is quite monolithic and
>> it would clearly benefit from a framework such as OSGi. For example, the
>> clustering technology is quite interesting but why can't it be reused
>> without all the other stuff ? Or maybe you want to wire things a little
>> differently ? Not have everything directly listen to ports without any
>> security but be able to plugin whatever filter or modules you need ?
>>
>> Personally I think that what is really needed in OSGi is better tooling,
>> especially for making it a lot simpler to build high quality and
>> minimalistic bundles. Using the maven-bundle-plugin or the shader-plugin is
>> quite tedious and possibly error prone. I've built my own Maven plugin on
>> top of the bundle plugin so that it can handle a lot more resources
>> (including JSPs that include taglibs for example) and that also tries to be
>> smarter at generating import-package statements. This makes it easier for
>> OSGi newbies to adopt the technology.
>>
>> I'm also worried that the initial learning curve of OSGi might be putting
>> less experienced developers off and more towards package-the-world
>> solutions such as Docker, which while acceptable for some cases such as
>> continuous integration, could also be dangerous if not maintained properly.
>>
>> Regards,
>>   Serge
>>
>> Le 11 avr. 2015 à 19:43, Niels  a écrit :
>>
>> Could not agree more Achim. Good fad indicators are high promises which
>> are designed to target the ultimate need of decision makers to deliver
>> software quicker and cheaper. Just rewind 10 years and we will find the
>> exact same promises were made at the start of the SOA hype which are now
>> touted by the microservices believers. At the end of the day nothing will
>> prevent people from doing something really badly.
>>
>> I can see the value of docker but unless one really has all the lifecycle
>> ducks in a row I would not go down the path and containerise the all and
>> sundry.
>>
>> Cheers,
>> Niels
>>
>> On 12 Apr 2015, at 08:28, Ryan Moquin  wrote:
>>
>> I used to work somewhere with other developers who always became very
>> spiritual about whatever the latest "cool" developer technology or
>> methodology is.  Microservices was one of them.  It always made me laugh
>> when I was told how super efficient and streamlined it was over any other
>> solution because every fat jar deployed (Maven shade plugin abuse in order
>> to be lazy) was between 500Mb and 1.7Gb.  So much for being a
>> "micro"-service.
>> On Apr 8, 2015 2:55 PM, "Achim Nierbeck"  wrote:
>>
>>> I'm very ambivalent regarding this topic.
>>>
>>> On one hand I see a lot of move to Docker as heading for the holy grail
>>> on fixing all the issues we had in the past. #FAIL
>>> On the other hand I see some benefits of it, but still haven't found the
>>> concrete use-case where it did top a bar-metal or bare virtualized machine.
>>>
>>> It's absolutely true that it does have some benefits for easier
>>> deployment of "Infrastructure" but I also see a lot of failures in usage of
>>> Docker. Just to mention one, where did the init daemon go, it's been there
>>> for a reason in linux OS's and now we run applications on top of the system
>>> without it ... I don't feel comfortable with that, especially if you don't
>>> have a JVM as process running which starts spawning other processes (one
>>> might remember the zombie processes).
>>> In the end there are mostly more slopy/lazy people around[1] trying to
>>> get something going, that's why Docker will be sufficient enough, while the
>>> dynamic and re-configurable service oriented software architecture will be
>>>

RE: Karaf on Amazon cloud

[Basic Danijel]

Hi Achim and Tim,

Thank you for giving me the hints, which are the good starting point.

Honestly, I do not have experience in working with Amazon cloud. That's why
I asked for some tutorial/hints, in order to start faster.

Best regards,
Danijel
On Apr 12, 2015 4:59 PM, "tvogel"  wrote:

> Danijel,  I have a karaf instance running in Amazon cloud.  There are only
> three things that caused me a challenge:1) Getting the firewalls right.
> I setup multiple security profiles by function (public access, deployment,
> full remote admin) and then applied the appropriate ones.  Be sure to
> consider file transfer, SSH and remote desktop ports.   You have at two on
> Amazon, the one in EC2 console and the one in the OS (Windows / Linux).
> Depending on the ports used you may also have multiple firewalls on the
> client side.2) The bundles that need to be loaded either have to be
> located on the remote host or accessible / visible to maven from the remote
> host.3) Security for the account that will be running the karaf instance.
> This needs to be a non-privileged account with the minimum possible rights.
> Tim
>
> Date: Sun, 12 Apr 2015 05:22:30 -0700
> From: ml-node+s922171n4039581...@n3.nabble.com
> To: tvo...@msn.com
> Subject: Karaf on Amazon cloud
>
>
>
> Hi all,
> I'm planning to put some webapp on Amazon cloud. The app is running on
> Karaf.
> Does anyone know for some good tutorial which explains how to do that?
> Regards,
>
> Danijel
>
>
>
>
>
>
>
>
>
>
>
> If you reply to this email, your message will be added to
> the discussion below:
>
> http://karaf.922171.n3.nabble.com/Karaf-on-Amazon-cloud-tp4039581.html
>
>
>
> To unsubscribe from Karaf - User, click here.
>
> NAML
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Karaf-on-Amazon-cloud-tp4039581p4039584.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>

Re: Karaf: Could not resolve mvn:org.apache.felix/org.apache.felix.framework/4.2.1

[Jean-Baptiste Onofré]

Hi Pasha,

can you check that the uncompress is OK especially of the system folder ?

Regards
JB

On 04/12/2015 11:33 AM, PashaTurok wrote:

I have openjdk 8 and centos 6.4 64. I've downloaded karaf 3.0.3 and run
/bin/karaf. And this is what I get:

 Could not resolve mvn:org.apache.felix/org.apache.felix.framework/4.2.1

How to fix it and run karaf?




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-Could-not-resolve-mvn-org-apache-felix-org-apache-felix-framework-4-2-1-tp4039578.html
Sent from the Karaf - User mailing list archive at Nabble.com.



--
Jean-Baptiste Onofré
jbono...@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Re: Karaf: Could not resolve mvn:org.apache.felix/org.apache.felix.framework/4.2.1

[Achim Nierbeck]

Strange, I just verified it with a vagrant centos-6.4 box.
Fresh install of JDK 8 from oracle, and downloaded Karaf 3.0.3 from within
this box.
Karaf 3.0.3 starts nicely.
Seems to be something on your box then.

Anything else you maybe did change beforehand?
What does the logfile show about it?


regards, Achim

2015-04-12 16:56 GMT+02:00 PashaTurok :

> I have tested with oracle jdk - result is the same. And yes, the box is
> connected to internet
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Karaf-Could-not-resolve-mvn-org-apache-felix-org-apache-felix-framework-4-2-1-tp4039578p4039583.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

RE: Karaf on Amazon cloud

[tvogel]

Danijel,  I have a karaf instance running in Amazon cloud.  There are only 
three things that caused me a challenge:1) Getting the firewalls right.  
I setup multiple security profiles by function (public access, deployment, full 
remote admin) and then applied the appropriate ones.  Be sure to consider file 
transfer, SSH and remote desktop ports.   You have at two on Amazon, the one in 
EC2 console and the one in the OS (Windows / Linux).  Depending on the ports 
used you may also have multiple firewalls on the client side.2) The bundles 
that need to be loaded either have to be located on the remote host or 
accessible / visible to maven from the remote host.3) Security for the account 
that will be running the karaf instance.  This needs to be a non-privileged 
account with the minimum possible rights.  
Tim

Date: Sun, 12 Apr 2015 05:22:30 -0700
From: ml-node+s922171n4039581...@n3.nabble.com
To: tvo...@msn.com
Subject: Karaf on Amazon cloud



Hi all,
I'm planning to put some webapp on Amazon cloud. The app is running on Karaf.
Does anyone know for some good tutorial which explains how to do that?
Regards,

Danijel











If you reply to this email, your message will be added to the 
discussion below:

http://karaf.922171.n3.nabble.com/Karaf-on-Amazon-cloud-tp4039581.html



To unsubscribe from Karaf - User, click here.

NAML
  



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-on-Amazon-cloud-tp4039581p4039584.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Karaf: Could not resolve mvn:org.apache.felix/org.apache.felix.framework/4.2.1

[PashaTurok]

I have tested with oracle jdk - result is the same. And yes, the box is
connected to internet



--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-Could-not-resolve-mvn-org-apache-felix-org-apache-felix-framework-4-2-1-tp4039578p4039583.html
Sent from the Karaf - User mailing list archive at Nabble.com.

Re: Karaf on Amazon cloud

[Achim Nierbeck]

Anything special you're looking for?

Cause usually it's just starting that instance, downloading Karaf, untar
the karaf distro and starting it.
So what did you have in mind?

regards, Achim


2015-04-12 14:21 GMT+02:00 Basic Danijel :

> Hi all,
>
> I'm planning to put some webapp on Amazon cloud. The app is running on
> Karaf.
>
> Does anyone know for some good tutorial which explains how to do that?
>
> Regards,
> Danijel
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Karaf on Amazon cloud

[Basic Danijel]

Hi all,

I'm planning to put some webapp on Amazon cloud. The app is running on
Karaf.

Does anyone know for some good tutorial which explains how to do that?

Regards,
Danijel

Re: Karaf: Could not resolve mvn:org.apache.felix/org.apache.felix.framework/4.2.1

[Achim Nierbeck]

First, try with oracle JDK 8,
second does your box have connection to internet?

regards, Achim


2015-04-12 11:33 GMT+02:00 PashaTurok :

> I have openjdk 8 and centos 6.4 64. I've downloaded karaf 3.0.3 and run
> /bin/karaf. And this is what I get:
>
> Could not resolve mvn:org.apache.felix/org.apache.felix.framework/4.2.1
>
> How to fix it and run karaf?
>
>
>
>
> --
> View this message in context:
> http://karaf.922171.n3.nabble.com/Karaf-Could-not-resolve-mvn-org-apache-felix-org-apache-felix-framework-4-2-1-tp4039578.html
> Sent from the Karaf - User mailing list archive at Nabble.com.
>



-- 

Apache Member
Apache Karaf  Committer & PMC
OPS4J Pax Web  Committer &
Project Lead
blog 
Co-Author of Apache Karaf Cookbook 

Software Architect / Project Manager / Scrum Master

Karaf: Could not resolve mvn:org.apache.felix/org.apache.felix.framework/4.2.1

[PashaTurok]

I have openjdk 8 and centos 6.4 64. I've downloaded karaf 3.0.3 and run
/bin/karaf. And this is what I get:

Could not resolve mvn:org.apache.felix/org.apache.felix.framework/4.2.1

How to fix it and run karaf?




--
View this message in context: 
http://karaf.922171.n3.nabble.com/Karaf-Could-not-resolve-mvn-org-apache-felix-org-apache-felix-framework-4-2-1-tp4039578.html
Sent from the Karaf - User mailing list archive at Nabble.com.