Re: [jira] Created: (SLING-1804) instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository

2010-09-24 Thread Felix Meschberger
Hi,

Could we leverage stuff from PAX/OPS4J here ? Namely the stuff they did
around URL Handlers ? An option besides Maven could also be OBR, of course.

Regards
Felix

Am 24.09.2010 20:48, schrieb Justin Edelson (JIRA):
 instead of packaging bundles in the standalone JAR or WAR, provision them at 
 runtime from a Maven repository
 
 
  Key: SLING-1804
  URL: https://issues.apache.org/jira/browse/SLING-1804
  Project: Sling
   Issue Type: New Feature
   Components: Launchpad
 Reporter: Justin Edelson
 
 
 something I've been thinking about for a few months, but never wrote down...
 
 It would be nice to have the option to create a Launchpad JAR or WAR which 
 was only composed of Launchpad and the bundle list. At runtime, Launchpad 
 could download the artifacts referenced in the bundle list from a Maven 
 repository.
 
 With the work being done to extract the repository integration code from the 
 rest of Maven (i.e. to create Aether), this should be relatively simple.
 


Re: [jira] Created: (SLING-1804) instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository

2010-09-24 Thread Justin Edelson
Worth looking at, but AFAIK, the Pax URL handlers doesn't fully interop
with Maven's settings. Reading
http://wiki.ops4j.org/display/paxurl/Mvn+Protocol, it looks like mirrors
and proxies aren't supported.

Justin

On 9/24/10 3:25 PM, Felix Meschberger wrote:
 Hi,
 
 Could we leverage stuff from PAX/OPS4J here ? Namely the stuff they did
 around URL Handlers ? An option besides Maven could also be OBR, of course.
 
 Regards
 Felix
 
 Am 24.09.2010 20:48, schrieb Justin Edelson (JIRA):
 instead of packaging bundles in the standalone JAR or WAR, provision them at 
 runtime from a Maven repository
 

  Key: SLING-1804
  URL: https://issues.apache.org/jira/browse/SLING-1804
  Project: Sling
   Issue Type: New Feature
   Components: Launchpad
 Reporter: Justin Edelson


 something I've been thinking about for a few months, but never wrote down...

 It would be nice to have the option to create a Launchpad JAR or WAR which 
 was only composed of Launchpad and the bundle list. At runtime, Launchpad 
 could download the artifacts referenced in the bundle list from a Maven 
 repository.

 With the work being done to extract the repository integration code from the 
 rest of Maven (i.e. to create Aether), this should be relatively simple.




Re: [jira] Created: (SLING-1804) instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository

2010-09-24 Thread Mike Moulton
If your going to go this far, would it be worth looking at using Karaf as the 
basis of the launchpad? Given this functionality is already provided out of the 
box, with many other benefits.

This is how we deploy all our sling instances, in a Karaf instance, either 
standalone or in a WAR. It is worth noting though, due to the nature of URL 
protocol registration, you can only register the mvn protocol provided by PAX 
in a JVM once. This has the side effect of only being able to deploy 1 instance 
of an embedded Karaf WAR into another container once.

-- Mike


On Sep 24, 2010, at 2:02 PM, Justin Edelson wrote:

 Worth looking at, but AFAIK, the Pax URL handlers doesn't fully interop
 with Maven's settings. Reading
 http://wiki.ops4j.org/display/paxurl/Mvn+Protocol, it looks like mirrors
 and proxies aren't supported.
 
 Justin
 
 On 9/24/10 3:25 PM, Felix Meschberger wrote:
 Hi,
 
 Could we leverage stuff from PAX/OPS4J here ? Namely the stuff they did
 around URL Handlers ? An option besides Maven could also be OBR, of course.
 
 Regards
 Felix
 
 Am 24.09.2010 20:48, schrieb Justin Edelson (JIRA):
 instead of packaging bundles in the standalone JAR or WAR, provision them 
 at runtime from a Maven repository
 
 
 Key: SLING-1804
 URL: https://issues.apache.org/jira/browse/SLING-1804
 Project: Sling
  Issue Type: New Feature
  Components: Launchpad
Reporter: Justin Edelson
 
 
 something I've been thinking about for a few months, but never wrote down...
 
 It would be nice to have the option to create a Launchpad JAR or WAR which 
 was only composed of Launchpad and the bundle list. At runtime, Launchpad 
 could download the artifacts referenced in the bundle list from a Maven 
 repository.
 
 With the work being done to extract the repository integration code from 
 the rest of Maven (i.e. to create Aether), this should be relatively simple.
 
 



Re: [jira] Created: (SLING-1804) instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository

2010-09-24 Thread Justin Edelson
It has been almost a year since I seriously evaluated Karaf, so I
can't really speak to it. I will say that I am very happy with how
Launchpad handles bundle upgrades and that this is an important piece
of functionality for me.

The change I have in mind is purely a matter of how the bundles are
retrieved (i.e. from the local Maven repository instead of extracted
from the JAR/WAR). How those bundles are processed will be exactly
what we already have in Launchpad.

Justin

On Fri, Sep 24, 2010 at 5:31 PM, Mike Moulton m...@meltmedia.com wrote:
 If your going to go this far, would it be worth looking at using Karaf as the 
 basis of the launchpad? Given this functionality is already provided out of 
 the box, with many other benefits.

 This is how we deploy all our sling instances, in a Karaf instance, either 
 standalone or in a WAR. It is worth noting though, due to the nature of URL 
 protocol registration, you can only register the mvn protocol provided by PAX 
 in a JVM once. This has the side effect of only being able to deploy 1 
 instance of an embedded Karaf WAR into another container once.

 -- Mike


 On Sep 24, 2010, at 2:02 PM, Justin Edelson wrote:

 Worth looking at, but AFAIK, the Pax URL handlers doesn't fully interop
 with Maven's settings. Reading
 http://wiki.ops4j.org/display/paxurl/Mvn+Protocol, it looks like mirrors
 and proxies aren't supported.

 Justin

 On 9/24/10 3:25 PM, Felix Meschberger wrote:
 Hi,

 Could we leverage stuff from PAX/OPS4J here ? Namely the stuff they did
 around URL Handlers ? An option besides Maven could also be OBR, of course.

 Regards
 Felix

 Am 24.09.2010 20:48, schrieb Justin Edelson (JIRA):
 instead of packaging bundles in the standalone JAR or WAR, provision them 
 at runtime from a Maven repository
 

                 Key: SLING-1804
                 URL: https://issues.apache.org/jira/browse/SLING-1804
             Project: Sling
          Issue Type: New Feature
          Components: Launchpad
            Reporter: Justin Edelson


 something I've been thinking about for a few months, but never wrote 
 down...

 It would be nice to have the option to create a Launchpad JAR or WAR which 
 was only composed of Launchpad and the bundle list. At runtime, Launchpad 
 could download the artifacts referenced in the bundle list from a Maven 
 repository.

 With the work being done to extract the repository integration code from 
 the rest of Maven (i.e. to create Aether), this should be relatively 
 simple.






Re: [jira] Created: (SLING-1804) instead of packaging bundles in the standalone JAR or WAR, provision them at runtime from a Maven repository

2010-09-24 Thread Mike Moulton
We often use sling with Servicemix 4, so we had to integrate it with Karaf. 
Since then, we exclusively use Karaf, even if we are not in need of Servicemix. 
The features Karaf gives us, such as the SSH console, features, etc. makes it 
very attractive for us. 

Karaf is now a top-level apache project that has matured immensely in the last 
year.

-- Mike



On Sep 24, 2010, at 4:20 PM, Justin Edelson wrote:

 It has been almost a year since I seriously evaluated Karaf, so I
 can't really speak to it. I will say that I am very happy with how
 Launchpad handles bundle upgrades and that this is an important piece
 of functionality for me.
 
 The change I have in mind is purely a matter of how the bundles are
 retrieved (i.e. from the local Maven repository instead of extracted
 from the JAR/WAR). How those bundles are processed will be exactly
 what we already have in Launchpad.
 
 Justin
 
 On Fri, Sep 24, 2010 at 5:31 PM, Mike Moulton m...@meltmedia.com wrote:
 If your going to go this far, would it be worth looking at using Karaf as 
 the basis of the launchpad? Given this functionality is already provided out 
 of the box, with many other benefits.
 
 This is how we deploy all our sling instances, in a Karaf instance, either 
 standalone or in a WAR. It is worth noting though, due to the nature of URL 
 protocol registration, you can only register the mvn protocol provided by 
 PAX in a JVM once. This has the side effect of only being able to deploy 1 
 instance of an embedded Karaf WAR into another container once.
 
 -- Mike
 
 
 On Sep 24, 2010, at 2:02 PM, Justin Edelson wrote:
 
 Worth looking at, but AFAIK, the Pax URL handlers doesn't fully interop
 with Maven's settings. Reading
 http://wiki.ops4j.org/display/paxurl/Mvn+Protocol, it looks like mirrors
 and proxies aren't supported.
 
 Justin
 
 On 9/24/10 3:25 PM, Felix Meschberger wrote:
 Hi,
 
 Could we leverage stuff from PAX/OPS4J here ? Namely the stuff they did
 around URL Handlers ? An option besides Maven could also be OBR, of course.
 
 Regards
 Felix
 
 Am 24.09.2010 20:48, schrieb Justin Edelson (JIRA):
 instead of packaging bundles in the standalone JAR or WAR, provision them 
 at runtime from a Maven repository
 
 
 Key: SLING-1804
 URL: https://issues.apache.org/jira/browse/SLING-1804
 Project: Sling
  Issue Type: New Feature
  Components: Launchpad
Reporter: Justin Edelson
 
 
 something I've been thinking about for a few months, but never wrote 
 down...
 
 It would be nice to have the option to create a Launchpad JAR or WAR 
 which was only composed of Launchpad and the bundle list. At runtime, 
 Launchpad could download the artifacts referenced in the bundle list from 
 a Maven repository.
 
 With the work being done to extract the repository integration code from 
 the rest of Maven (i.e. to create Aether), this should be relatively 
 simple.