Uploaded image for project: 'Karaf'
  1. Karaf
  2. KARAF-222

Provide karaf:run, karaf:deploy, karaf:client Maven goals

    Details

    • Type: New Feature
    • Status: Resolved
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 4.0.4
    • Component/s: karaf-tooling
    • Labels:
      None

      Description

      Did a quick google & couldn't see one yet - please close if there is one already

      The really nice thing about jetty:run is it watches the source code & target/classes dir & auto redeploys on change, so there's no deploy step - you just hack & compile (which your IDE or incremental compile can do - e.g. "mvn scala:cc").

      For added bonus would be being able to add some extra bundles, so it can be a RAD way to hack bundles. Maybe folks could have some integration junit tests automatically rerun whenever the bundle is redeployed?

        Issue Links

          Activity

          Hide
          pieber Andreas Pieber added a comment -

          I've implemented some idea how this can look like here

          https://github.com/openengsb/openengsb/blob/master/tooling/maven-openengsb-plugin/src/main/java/org/openengsb/tooling/pluginsuite/openengsbplugin/Provision.java

          Nevertheless I think this code will fit better directly in Karaf. Basically you can do a openengsb:run which scans all pom files for a configuration looking like:

          <plugin>
                  <groupId>org.openengsb.tooling.pluginsuite</groupId>
                  <artifactId>maven-openengsb-plugin</artifactId>
                  <version>${project.version}</version>
                  <configuration>
                    <provisionArchivePathUnix>${project.basedir}/target/openengsb-${project.version}.tar.gz</provisionArchivePathUnix>
                    <provisionExecutionPathUnix>bin/openengsb</provisionExecutionPathUnix>
                    <provisionArchivePathWindows>${project.basedir}/target/openengsb-${project.version}.zip</provisionArchivePathWindows>
                    <provisionExecutionPathWindows>bin/openengsb.bat</provisionExecutionPathWindows>
                  </configuration>
                </plugin>
          

          In addition I think an variable to set environment vars such as KARAF_OPTS or KARAF_DEBUG would be nice. I mean this is far away from what is described in this issue, but at least it is an start. If you like the idea I can backport the code to Karaf...

          WDYT?

          Show
          pieber Andreas Pieber added a comment - I've implemented some idea how this can look like here https://github.com/openengsb/openengsb/blob/master/tooling/maven-openengsb-plugin/src/main/java/org/openengsb/tooling/pluginsuite/openengsbplugin/Provision.java Nevertheless I think this code will fit better directly in Karaf. Basically you can do a openengsb:run which scans all pom files for a configuration looking like: <plugin> <groupId>org.openengsb.tooling.pluginsuite</groupId> <artifactId>maven-openengsb-plugin</artifactId> <version>${project.version}</version> <configuration> <provisionArchivePathUnix>${project.basedir}/target/openengsb-${project.version}.tar.gz</provisionArchivePathUnix> <provisionExecutionPathUnix>bin/openengsb</provisionExecutionPathUnix> <provisionArchivePathWindows>${project.basedir}/target/openengsb-${project.version}.zip</provisionArchivePathWindows> <provisionExecutionPathWindows>bin/openengsb.bat</provisionExecutionPathWindows> </configuration> </plugin> In addition I think an variable to set environment vars such as KARAF_OPTS or KARAF_DEBUG would be nice. I mean this is far away from what is described in this issue, but at least it is an start. If you like the idea I can backport the code to Karaf... WDYT?
          Hide
          pieber Andreas Pieber added a comment -

          BTW, I think we should gather all those maven goals in an org.apache.maven.plugins:maven-karaf-plugin (is this possible?) to allow karaf:XXX directly...

          Show
          pieber Andreas Pieber added a comment - BTW, I think we should gather all those maven goals in an org.apache.maven.plugins:maven-karaf-plugin (is this possible?) to allow karaf:XXX directly...
          Hide
          cmoulliard Charles Moulliard added a comment -

          Hi,

          I like this idea to develop a karaf:run plugin like we have with jetty or camel. This could help project to setup and deploy their bundles with a pre-configured karaf instance/container. To speed up the process we could also during the build process generate the cache containing the bundles to allow to test quickly.

          This feature is not a must and should be part of Karaf 3.0

          Charles

          Show
          cmoulliard Charles Moulliard added a comment - Hi, I like this idea to develop a karaf:run plugin like we have with jetty or camel. This could help project to setup and deploy their bundles with a pre-configured karaf instance/container. To speed up the process we could also during the build process generate the cache containing the bundles to allow to test quickly. This feature is not a must and should be part of Karaf 3.0 Charles
          Hide
          jstrachan james strachan added a comment -

          I still love the idea of the 'mvn karaf:run' goal - particularly the continuous watching & rebuilding of the bundle like jetty:run does etc.

          Just an aside that if folks want to deploy a jar/war/bundle/xml file into karaf (or tomcat/jetty too) there's a mvn plugin I hacked up here...
          http://mvnplugins.fusesource.org/maven/1.14-SNAPSHOT/maven-provision-plugin/index.html

          which will provision the deployment unit (e.g. the bundle / war) into the deploy directory of the application server you configure.

          Though a karaf specific version of jetty:run would rock; we'd maybe be able to use the 'expanded bundle' approach in Karaf - so rather than repeatedly copying classes & files into a jar, we'd just make sure that everything is continuously compiled into target/classes and we add a symlink of sorts in Karaf so it auto-reloads whenever we rebuild the code (or copy new config files into the expanded bundle)

          Show
          jstrachan james strachan added a comment - I still love the idea of the 'mvn karaf:run' goal - particularly the continuous watching & rebuilding of the bundle like jetty:run does etc. Just an aside that if folks want to deploy a jar/war/bundle/xml file into karaf (or tomcat/jetty too) there's a mvn plugin I hacked up here... http://mvnplugins.fusesource.org/maven/1.14-SNAPSHOT/maven-provision-plugin/index.html which will provision the deployment unit (e.g. the bundle / war) into the deploy directory of the application server you configure. Though a karaf specific version of jetty:run would rock; we'd maybe be able to use the 'expanded bundle' approach in Karaf - so rather than repeatedly copying classes & files into a jar, we'd just make sure that everything is continuously compiled into target/classes and we add a symlink of sorts in Karaf so it auto-reloads whenever we rebuild the code (or copy new config files into the expanded bundle)
          Hide
          djencks David Jencks added a comment -

          I'd like a description of exactly what you want this goal to do, I don't know what jetty:run does.

          As part of geronimo migration I have a base mojo that starts "karaf" as described by a startup.properties file using aether to locate the listed bundles (in the local maven repo). It would be easy (and I'll probably have to do this for geronimo) to also deploy all the bundles listed as maven dependencies. I imagine that the target/classes directory could also be deployed as a bundle.

          At the moment with the geronimo plugin you basically get the karaf command line console showing after karaf startup. (in geronimo I shut it down again after the plugin's work is performed).

          Show
          djencks David Jencks added a comment - I'd like a description of exactly what you want this goal to do, I don't know what jetty:run does. As part of geronimo migration I have a base mojo that starts "karaf" as described by a startup.properties file using aether to locate the listed bundles (in the local maven repo). It would be easy (and I'll probably have to do this for geronimo) to also deploy all the bundles listed as maven dependencies. I imagine that the target/classes directory could also be deployed as a bundle. At the moment with the geronimo plugin you basically get the karaf command line console showing after karaf startup. (in geronimo I shut it down again after the plugin's work is performed).
          Hide
          jstrachan james strachan added a comment -

          Hey David, long time no speak!

          Sounds like we're almost there. Some background...

          So the really nice thing about "mvn jetty:run" is you don't have to wait for the build process to make a big WAR then copy it to your container which then unpacks it again; mvn jetty:run just watches your target/classes dir for changes then starts up the web app without needing the WAR. Then if you edit some code in, say, eclipse/IDEA and it recompiles it, the jetty:run plugin detects the classes changed in target/classes and restarts the WAR application inside the web container; without the JVM + Jetty restarting. So you get really RAD deployment of your application without really restarting the container.

          Something similar would be awesome; where rather than making the jar of the bundle (so just the compile goal is done), a karaf is started (maybe some dependent bundles are started too), the target/classes dir is used to start the bundle of the project you're doing "mvn karaf:run" inside. Then if you change any code and its compiled by your IDE incrementally, karaf:run detects it, stops the bundle & restarts it again with the new classes.

          Basically it gives you very fast re-run times as you don't have to stop + start maven or the JVM running Karaf; you just reload the bundle on the fly.

          Karaf already supports the expanded bundle format already; so I don't think it'd be hard to do; its kinda like treating the 'target' dir as the hotdeploy dir for a new karaf container thats started in the "karaf:run" goal, then the classes dir is the bundle for the application; then it just reuses the normal karaf file watcher stuff so the bundle is reloaded if changes are made inside target/classes.

          OK a slightly wacky idea now; I wonder if you're working on 3 different bundles in development which all work together inside Karaf; I wonder if it'd be possible to have a flavour of karaf:run where all you really mean is "deploy my target/classes as a bundle into the server X". i.e. so you could change code in any of your 3 projects and Karaf would auto-reload the bundles that changed. I guess you could do this today with a shell script, just creating sym links to your target/classes directories to directories inside your karaf servers deploy dir? Maybe there's a way to add a custom file type to Karaf's deployment which is a kinda pseudo file link to the developers IDE build of a bundle? So a maven goal copies myBundleName.link into your karaf servers hotdeploy dir; the contents of myBundleName.link is the full path of the $

          {basedir}

          /target/classes dir and Karaf interprets that actual physical dir as an exploded bundle to be watched?

          Show
          jstrachan james strachan added a comment - Hey David, long time no speak! Sounds like we're almost there. Some background... So the really nice thing about "mvn jetty:run" is you don't have to wait for the build process to make a big WAR then copy it to your container which then unpacks it again; mvn jetty:run just watches your target/classes dir for changes then starts up the web app without needing the WAR. Then if you edit some code in, say, eclipse/IDEA and it recompiles it, the jetty:run plugin detects the classes changed in target/classes and restarts the WAR application inside the web container; without the JVM + Jetty restarting. So you get really RAD deployment of your application without really restarting the container. Something similar would be awesome; where rather than making the jar of the bundle (so just the compile goal is done), a karaf is started (maybe some dependent bundles are started too), the target/classes dir is used to start the bundle of the project you're doing "mvn karaf:run" inside. Then if you change any code and its compiled by your IDE incrementally, karaf:run detects it, stops the bundle & restarts it again with the new classes. Basically it gives you very fast re-run times as you don't have to stop + start maven or the JVM running Karaf; you just reload the bundle on the fly. Karaf already supports the expanded bundle format already; so I don't think it'd be hard to do; its kinda like treating the 'target' dir as the hotdeploy dir for a new karaf container thats started in the "karaf:run" goal, then the classes dir is the bundle for the application; then it just reuses the normal karaf file watcher stuff so the bundle is reloaded if changes are made inside target/classes. OK a slightly wacky idea now; I wonder if you're working on 3 different bundles in development which all work together inside Karaf; I wonder if it'd be possible to have a flavour of karaf:run where all you really mean is "deploy my target/classes as a bundle into the server X". i.e. so you could change code in any of your 3 projects and Karaf would auto-reload the bundles that changed. I guess you could do this today with a shell script, just creating sym links to your target/classes directories to directories inside your karaf servers deploy dir? Maybe there's a way to add a custom file type to Karaf's deployment which is a kinda pseudo file link to the developers IDE build of a bundle? So a maven goal copies myBundleName.link into your karaf servers hotdeploy dir; the contents of myBundleName.link is the full path of the $ {basedir} /target/classes dir and Karaf interprets that actual physical dir as an exploded bundle to be watched?
          Hide
          djencks David Jencks added a comment -

          I ported the geronimo stuff I had to karaf. There are a few odd bits:

          – at the moment I copied the needed files out of a karaf assembly into the plugin. This is not OK for real usage, but there's a bit of chicken-egg problem here since the obvious way to get these resources is by using the karaf-maven-plugin which the run mojo is part of.

          • I'm not sure how to offer the choice of felix/equinox since the classpath the framework runs in is what is set up by maven. Maybe we should start the framework in our own classloader that doesn't use the maven realm as parent.

          Note that the "karaf" is started in the maven vm, not a separate vm. Is this a problem?

          Show
          djencks David Jencks added a comment - I ported the geronimo stuff I had to karaf. There are a few odd bits: – at the moment I copied the needed files out of a karaf assembly into the plugin. This is not OK for real usage, but there's a bit of chicken-egg problem here since the obvious way to get these resources is by using the karaf-maven-plugin which the run mojo is part of. I'm not sure how to offer the choice of felix/equinox since the classpath the framework runs in is what is set up by maven. Maybe we should start the framework in our own classloader that doesn't use the maven realm as parent. Note that the "karaf" is started in the maven vm, not a separate vm. Is this a problem?
          Hide
          djencks David Jencks added a comment -

          Also the diff is from git diff >my-file.diff. I'm happy to make other git output formats if someone tells me how.

          Show
          djencks David Jencks added a comment - Also the diff is from git diff >my-file.diff. I'm happy to make other git output formats if someone tells me how.
          Hide
          pieber Andreas Pieber added a comment -

          @karaf-stuff: couldn't we create this stuff at runtime by unpacking the karaf distribution (as we're doing for the kittests?)
          @git: git diff is absolutely OK since it can be easily applied using git apply my-file.diff. Other option would be to use git format-patch, but which is IMHO better for git-only-workflows --> +1 for using git diff > ...

          Show
          pieber Andreas Pieber added a comment - @karaf-stuff: couldn't we create this stuff at runtime by unpacking the karaf distribution (as we're doing for the kittests?) @git: git diff is absolutely OK since it can be easily applied using git apply my-file.diff. Other option would be to use git format-patch, but which is IMHO better for git-only-workflows --> +1 for using git diff > ...
          Hide
          jbonofre Jean-Baptiste Onofré added a comment -

          For git, git diff generate a patch file (which can be applied using git apply), so no problem at all

          For Karaf, I'm agree with Andreas: we can start with a clean karaf distro (eventually adding a profile, a profile can contain features, config files, etc).

          Show
          jbonofre Jean-Baptiste Onofré added a comment - For git, git diff generate a patch file (which can be applied using git apply), so no problem at all For Karaf, I'm agree with Andreas: we can start with a clean karaf distro (eventually adding a profile, a profile can contain features, config files, etc).
          Hide
          djencks David Jencks added a comment -

          There are a lot of possible ways to have something like karaf:run. One of them is certainly unpacking an actual karaf distro. What I did, unning a "karaf" instance that only involves a few configuration files and takes all the bundles from the local maven repo, ought to be a lot faster to start up since there's basically no file copying.

          I think this is a useful base for other kinds of mojos, and I need the base functionality for a while in geronimo, so I'm going to be maintaining it somewhere for a few months. If people are interested I can work more on fixing problems, otherwise we can drop it.

          I don't really understand what the difference between a profile and a kar file is. A kar file can contain arbitrary content that ends up in the server, features, bundles, configuration for the bundles.

          Show
          djencks David Jencks added a comment - There are a lot of possible ways to have something like karaf:run. One of them is certainly unpacking an actual karaf distro. What I did, unning a "karaf" instance that only involves a few configuration files and takes all the bundles from the local maven repo, ought to be a lot faster to start up since there's basically no file copying. I think this is a useful base for other kinds of mojos, and I need the base functionality for a while in geronimo, so I'm going to be maintaining it somewhere for a few months. If people are interested I can work more on fixing problems, otherwise we can drop it. I don't really understand what the difference between a profile and a kar file is. A kar file can contain arbitrary content that ends up in the server, features, bundles, configuration for the bundles.
          Hide
          pieber Andreas Pieber added a comment -

          The reason y I think that using a configurable Karaf instance is the better choice is because then you can easily use another distribution such as SMX (or your own Karaf product). WDYT?

          Show
          pieber Andreas Pieber added a comment - The reason y I think that using a configurable Karaf instance is the better choice is because then you can easily use another distribution such as SMX (or your own Karaf product). WDYT?
          Hide
          achim_nierbeck Achim Nierbeck added a comment -

          I'm also a fan of Andreas idea, this is a real benefit if the people are able to run their own "distributions" with mvn:run so a big +1

          Show
          achim_nierbeck Achim Nierbeck added a comment - I'm also a fan of Andreas idea, this is a real benefit if the people are able to run their own "distributions" with mvn:run so a big +1
          Hide
          djencks David Jencks added a comment -

          I'm assuming that everyone will be assembling their distributions using maven from kar files and features. You can set up one kar file to have all the configuration info needed for a distro. After doing this, including the kar file in your dependencies should give you the same "karaf" as unpacking the actual distribution, except without extracting all the bundles to the file system. As I noted there are some problems in the diff, but it does show that it's possible to run "karaf" out of the maven repo in the same vm as maven and deploy maven dependencies as bundles ( I didn't check that feature and kar dependencies work yet).

          I tried it by:

          • adding to my ~/.m2/settings.xml:
            <pluginGroups>
            <pluginGroup>org.apache.karaf.tooling</pluginGroup>
            </pluginGroups>
          • in a project that happens to build a bundle, do mvn karaf:run

          There's way too much logging on the console, but karaf starts and you can use the console.
          At the moment the project you run karaf in itself isn't deployed to karaf and I haven't thought about change listeners.

          Show
          djencks David Jencks added a comment - I'm assuming that everyone will be assembling their distributions using maven from kar files and features. You can set up one kar file to have all the configuration info needed for a distro. After doing this, including the kar file in your dependencies should give you the same "karaf" as unpacking the actual distribution, except without extracting all the bundles to the file system. As I noted there are some problems in the diff, but it does show that it's possible to run "karaf" out of the maven repo in the same vm as maven and deploy maven dependencies as bundles ( I didn't check that feature and kar dependencies work yet). I tried it by: adding to my ~/.m2/settings.xml: <pluginGroups> <pluginGroup>org.apache.karaf.tooling</pluginGroup> </pluginGroups> in a project that happens to build a bundle, do mvn karaf:run There's way too much logging on the console, but karaf starts and you can use the console. At the moment the project you run karaf in itself isn't deployed to karaf and I haven't thought about change listeners.
          Hide
          pieber Andreas Pieber added a comment -

          Mhm, but doesn't that mean that I have to duplicate some parts in my poms? The run and the assembly part would look almost identical then, wouldn't they?

          Show
          pieber Andreas Pieber added a comment - Mhm, but doesn't that mean that I have to duplicate some parts in my poms? The run and the assembly part would look almost identical then, wouldn't they?
          Hide
          pieber Andreas Pieber added a comment -

          This one is the representation issue for the development increasements; this will allow autodeployment if you compile code in eclipse

          Show
          pieber Andreas Pieber added a comment - This one is the representation issue for the development increasements; this will allow autodeployment if you compile code in eclipse
          Hide
          jbonofre Jean-Baptiste Onofré added a comment -

          I plan to provide the following goals very soon (let say next week):

          • karaf:run to bootstrap and run a local Karaf instance
          • karaf:deploy to upload (using scp) an artifact to a given Karaf deploy folder
          • karaf:client to execute commands on a given Karaf instance
          Show
          jbonofre Jean-Baptiste Onofré added a comment - I plan to provide the following goals very soon (let say next week): karaf:run to bootstrap and run a local Karaf instance karaf:deploy to upload (using scp) an artifact to a given Karaf deploy folder karaf:client to execute commands on a given Karaf instance
          Hide
          jbonofre Jean-Baptiste Onofré added a comment -

          It's likely done on one of my local branches but I need to do some cleanup before pushing.

          Show
          jbonofre Jean-Baptiste Onofré added a comment - It's likely done on one of my local branches but I need to do some cleanup before pushing.
          Hide
          kwesterfeld Kurt Westerfeld added a comment -

          It may seem like a silly idea, but James was really looking for improving the RAD experience for Karaf.

          I've gotten a LOT of mileage out of simply mounting my maven output directories directly using the felix (or is it pax-url) reference: URL mechanism. When I do this, I rarely need to do more than simply update my bundle. I don't deploy, and since the m2e plugin pushes java classes out to target/classes, along with resources, I many times don't even need to change my bundle if I run Karaf from within Eclipse. Does anyone use "reference:" ULRs with Karaf? I only use them for manual installation of bundles, although I created Karaf aliases to turn my distro into "dev" mode.

          To me, using reference: URLs for my local bundles that I am hacking shortens the edit/compile/debug cycle dramatically. I only wish I could build my whole distribution with a features file that would accept reference:file: as coordinates for the bundles, but alas the feature installer doesn't support that. If this doesn't make sense, I can elaborate more. What I'd like to do is build my whole distro with a -Pdev profile, which would create and expand a customized Karaf distribution, installing my features mounted to the local target/classes maven output directories of each of my bundles, and let it rip.

          I would definitely use a karaf:run maven goal, as long as I could still debug from within Eclipse, but many times there's issues with remote debugging, etc. that prevents exec-ing from really improving the RAD experience.

          Hope I'm making sense.

          Show
          kwesterfeld Kurt Westerfeld added a comment - It may seem like a silly idea, but James was really looking for improving the RAD experience for Karaf. I've gotten a LOT of mileage out of simply mounting my maven output directories directly using the felix (or is it pax-url) reference: URL mechanism. When I do this, I rarely need to do more than simply update my bundle. I don't deploy, and since the m2e plugin pushes java classes out to target/classes, along with resources, I many times don't even need to change my bundle if I run Karaf from within Eclipse. Does anyone use "reference:" ULRs with Karaf? I only use them for manual installation of bundles, although I created Karaf aliases to turn my distro into "dev" mode. To me, using reference: URLs for my local bundles that I am hacking shortens the edit/compile/debug cycle dramatically. I only wish I could build my whole distribution with a features file that would accept reference:file: as coordinates for the bundles, but alas the feature installer doesn't support that. If this doesn't make sense, I can elaborate more. What I'd like to do is build my whole distro with a -Pdev profile, which would create and expand a customized Karaf distribution, installing my features mounted to the local target/classes maven output directories of each of my bundles, and let it rip. I would definitely use a karaf:run maven goal, as long as I could still debug from within Eclipse, but many times there's issues with remote debugging, etc. that prevents exec-ing from really improving the RAD experience. Hope I'm making sense.
          Hide
          jbonofre Jean-Baptiste Onofré added a comment -

          Actually, as you may see in my previous comment, it's already done on my local branch. I will merge my local branch.

          Show
          jbonofre Jean-Baptiste Onofré added a comment - Actually, as you may see in my previous comment, it's already done on my local branch. I will merge my local branch.
          Hide
          jbonofre Jean-Baptiste Onofré added a comment -

          As I have some conflicts to fix to merge my branches, and avoid to block the planned release, I will complete the merge just after 2.3.5 and 3.0.1.

          Show
          jbonofre Jean-Baptiste Onofré added a comment - As I have some conflicts to fix to merge my branches, and avoid to block the planned release, I will complete the merge just after 2.3.5 and 3.0.1.
          Hide
          cmoulliard Charles Moulliard added a comment -

          What is the status to merge the code of your branch Jean-Baptiste to the trunk of Karaf 4, 3 or 2.x ?

          Show
          cmoulliard Charles Moulliard added a comment - What is the status to merge the code of your branch Jean-Baptiste to the trunk of Karaf 4, 3 or 2.x ?
          Hide
          jbonofre Jean-Baptiste Onofré added a comment -

          It's on the way: I'm updating my local branch where I have the new goals with the latest changes. I'm busy with 2.4.1 and 3.0.3 releases preparation. I should have time to do the merge during the week end.

          Show
          jbonofre Jean-Baptiste Onofré added a comment - It's on the way: I'm updating my local branch where I have the new goals with the latest changes. I'm busy with 2.4.1 and 3.0.3 releases preparation. I should have time to do the merge during the week end.
          Hide
          arnefranken Arne Franken added a comment -

          Jean-Baptiste Onofré: have you had the chance to integrate your changes? I would be very interested in running a Karaf application locally from Maven...

          Show
          arnefranken Arne Franken added a comment - Jean-Baptiste Onofré : have you had the chance to integrate your changes? I would be very interested in running a Karaf application locally from Maven...
          Hide
          jbonofre Jean-Baptiste Onofré added a comment -

          Hi Arne, yes I have something ready on a local branch. I will merge asap.

          Show
          jbonofre Jean-Baptiste Onofré added a comment - Hi Arne, yes I have something ready on a local branch. I will merge asap.
          Hide
          arnefranken Arne Franken added a comment -

          if you would push your branch, I could take a look/try out the new goals before merging to master. (and help with the implementation, if necessary)

          Show
          arnefranken Arne Franken added a comment - if you would push your branch, I could take a look/try out the new goals before merging to master. (and help with the implementation, if necessary)
          Hide
          jbonofre Jean-Baptiste Onofré added a comment -

          Sure ! I will do it asap.

          Show
          jbonofre Jean-Baptiste Onofré added a comment - Sure ! I will do it asap.
          Hide
          jira-bot ASF subversion and git services added a comment -

          Commit 335620adb7b1cc92380ec9cba7eb2dbbaa8bb96c in karaf's branch refs/heads/master from Jean-Baptiste Onofré
          [ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=335620a ]

          KARAF-222 - Provide karaf:run, karaf:deploy, karaf:client Maven goals

          Show
          jira-bot ASF subversion and git services added a comment - Commit 335620adb7b1cc92380ec9cba7eb2dbbaa8bb96c in karaf's branch refs/heads/master from Jean-Baptiste Onofré [ https://git-wip-us.apache.org/repos/asf?p=karaf.git;h=335620a ] KARAF-222 - Provide karaf:run, karaf:deploy, karaf:client Maven goals

            People

            • Assignee:
              jbonofre Jean-Baptiste Onofré
              Reporter:
              jstrachan james strachan
            • Votes:
              13 Vote for this issue
              Watchers:
              11 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development