[jira] Created: (SLING-967) Support davmount requests (RFC 4709)

2009-05-12 Thread Felix Meschberger (JIRA)
Support davmount requests (RFC 4709)


 Key: SLING-967
 URL: https://issues.apache.org/jira/browse/SLING-967
 Project: Sling
  Issue Type: New Feature
  Components: JCR
Affects Versions: JCR Webdav 2.0.4
Reporter: Felix Meschberger


RFC 4709 [1] defines a file format and MIME type to convey WebDAV mount 
information from servers to clients.

Generating such a response is easy for Sling in that the WebDAV support can 
register servlet responding to the "davmount" extension, which maps to the 
application/davmount+xml extension. This servlet would generate the correct 
response.

For example a request to 

http://host/some/content.davmount

might reply with

http://purl.org/NET/webdav/mount";>
 http://host:80/
 some/content/



[1] http://www.ietf.org/rfc/rfc4709.txt

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: creating new properties with HTTP request

2009-05-12 Thread Tobias Bocanegra
try  '&' as delimiter.

see: http://en.wikipedia.org/wiki/Query_string
and: 
https://developer.mozilla.org/en/Core_JavaScript_1.5_Reference/Global_Functions/encodeURIComponent

regards, toby


2009/5/12 vkrejcirik :
> I need to create more properties with HTTP request. When I send HTTP request
> with query string, which contents only one property, it's ok.
> I don't know, how can I separate more properties. (I tried coma and
> semicolon )
>
> example:
>
> var queryString = "newContent=" + newContent + ";mep=" + mep + ";endpoint="
> + endpoint;
>
> xmlHttp = createXMLHttpRequest();
> xmlHttp.onreadystatechange = processSave;
> xmlHttp.open("POST", url, true);
> xmlHttp.setRequestHeader("Content-Type",
> "application/x-www-form-urlencoded;");
> xmlHttp.send(queryString);
>
> Thanks.
>
> --
> /**/
> Best regards / S pozdravem
> Vladislav Krejčiřík
>
> http://www.vkrejcirik.info
>
>


Re: Releases in the future

2009-05-12 Thread Roy T. Fielding

On May 12, 2009, at 12:40 AM, Bertrand Delacretaz wrote:

On Mon, May 11, 2009 at 10:29 PM, Roy T. Fielding  
 wrote:

On May 11, 2009, at 12:03 PM, Felix Meschberger wrote:


Carsten and I have been reasoning about the releases in the future,
mainly the ones for end-users who just want to grab a binary and  
fire it

off


Apache only releases source code packages.  Those other things you  
build
are not releases -- they are binaries that individuals build and  
upload.


How about naming those things "binary packages" instead of "releases"?


A rose is still a rose ...


We can still use the same process for releasing them, and include a
disclaimer that they're not official releases and provided without
warranty etc..


I don't see how we can "use the same process for releasing them" when
part of that process requires comparison of the source code with what
is in subversion.  An ASF release is a group decision based on peer
review, and I don't think anyone giving +1s on the binaries are
actually doing JVM decompiles and source-level comparisons to verify
the contents don't include some extra trojan horse.  Running the tests
is not sufficient.

That's why the ASF does not vote on binaries.  I'd rather not make it
look like we are.

Roy



Revision of Sling documentation, determining old stuff

2009-05-12 Thread Mike Müller
Hi

I'm reviewing the documentation on the Sling Site and need your help
do determine old stuff, because I'm not sure if they are up-to-date or not.

So please give me some feedback on the following pages:

- Architecture (seems to be up-to-date) [1]
- Eventing and Jobs (can someone check) [2]
- Internationalization Support (can someone check, seems to be outdated,
  at least there's no getLocale() on SlingHttpServletRequest) [3]
- Installing and Upgrading Bundles (can someone check seems to be outdated
  in favour of Felix management console) [4]
- Assembly (can someone check, seems not to be part of Sling, maybe CRX) [5]
- Apache Sling Rewriter (maybe ok, but can't find org.apache.sling.rewriter.*) 
[6]
- Groovy Support (seems to be ok) [7]
- XSLT Processing Pipeline (seems to be ok) [8]
- Maven Sling Plugin (can someone check) [9]
- Maven JspC Plugin (can someone check) [10]

BTW I didn't get why the new Sling release is Sling 5 and not Sling 4...

best regards
mike


[1] http://incubator.apache.org/sling/site/architecture.html
[2] http://incubator.apache.org/sling/site/eventing-and-jobs.html
[3] http://incubator.apache.org/sling/site/internationalization-support.html
[4] http://incubator.apache.org/sling/site/installing-and-upgrading-bundles.html
[5] http://incubator.apache.org/sling/site/assembly.html
[6] 
http://incubator.apache.org/sling/site/rewriting-the-output-through-pipelines.html
[7] http://incubator.apache.org/sling/site/groovy-support.html
[8] http://incubator.apache.org/sling/site/xslt-processing-pipeline.html
[9] http://incubator.apache.org/sling/site/sling.html
[10] http://incubator.apache.org/sling/site/jspc.html



[jira] Commented: (SLING-964) MimeTypeService: set correct default xml mimetype

2009-05-12 Thread Roy T. Fielding (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708587#action_12708587
 ] 

Roy T. Fielding commented on SLING-964:
---

Should this be fixed in Sling or in Commons?

I maintain the mime.types for Apache httpd, which is a lot more accurate than 
any other source.
I suggest you merge the current version from

http://svn.apache.org/repos/asf/httpd/httpd/trunk/docs/conf/mime.types


> MimeTypeService: set correct default xml mimetype
> -
>
> Key: SLING-964
> URL: https://issues.apache.org/jira/browse/SLING-964
> Project: Sling
>  Issue Type: Bug
>  Components: Commons MimeType
>Affects Versions:  Commons Mime 2.0.4
>Reporter: Dominique Jäggi
>Assignee: Felix Meschberger
>Priority: Minor
> Fix For: Commons Mime 2.0.6
>
>
> currently the default mime type for .xml extensions is set to "text/html". 
> since this is deprecated i suggest updating the mime type to 
> "application/xml" as per spec.
> i also suggest adding the mime type for rss: "application/rss+xml"

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



creating new properties with HTTP request

2009-05-12 Thread vkrejcirik
I need to create more properties with HTTP request. When I send HTTP 
request with query string, which contents only one property, it's ok.
I don't know, how can I separate more properties. (I tried coma and 
semicolon )


example:

var queryString = "newContent=" + newContent + ";mep=" + mep + 
";endpoint=" + endpoint;


xmlHttp = createXMLHttpRequest();
xmlHttp.onreadystatechange = processSave;
xmlHttp.open("POST", url, true);
xmlHttp.setRequestHeader("Content-Type", 
"application/x-www-form-urlencoded;");

xmlHttp.send(queryString);

Thanks.

--
/**/
Best regards / S pozdravem
Vladislav Krejčiřík

http://www.vkrejcirik.info



[jira] Created: (SLING-966) Make internal sling authentication publicly available

2009-05-12 Thread Felix Meschberger (JIRA)
Make internal sling authentication publicly available
-

 Key: SLING-966
 URL: https://issues.apache.org/jira/browse/SLING-966
 Project: Sling
  Issue Type: Improvement
  Components: Engine
Reporter: Felix Meschberger


Currently the SlingAuthenticator is an internal class in the Engine bundle, 
which is used by the SlingMainServlet to handle the authentication as part of 
an OSGi HTTP Service specification HttpContext object.

To use the Sling authentication framework with the Authenticator and the 
AuthenticationHandlers outside of the SlingMainServlet, that is for other 
servlets directly registered with the OSGi HttpService the authentication 
functionality should be made publicly available.

One approach would be to provide a new authenticate() method in the 
Authenticator interface. Another option would be to provide an abstract 
HttpContext which already implements the HttpContext.handleSecurity method 
using the SlingAuthenticator instance.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (SLING-964) MimeTypeService: set correct default xml mimetype

2009-05-12 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger updated SLING-964:


Fix Version/s: (was: Extensions Thread Dumper 1.0.0)
   Commons Mime 2.0.6

> MimeTypeService: set correct default xml mimetype
> -
>
> Key: SLING-964
> URL: https://issues.apache.org/jira/browse/SLING-964
> Project: Sling
>  Issue Type: Bug
>  Components: Commons MimeType
>Affects Versions:  Commons Mime 2.0.4
>Reporter: Dominique Jäggi
>Assignee: Felix Meschberger
>Priority: Minor
> Fix For: Commons Mime 2.0.6
>
>
> currently the default mime type for .xml extensions is set to "text/html". 
> since this is deprecated i suggest updating the mime type to 
> "application/xml" as per spec.
> i also suggest adding the mime type for rss: "application/rss+xml"

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (SLING-964) MimeTypeService: set correct default xml mimetype

2009-05-12 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved SLING-964.
-

   Resolution: Fixed
Fix Version/s: Extensions Thread Dumper 1.0.0

Fixed in Rev. 773890.

Please close this issue, if this satisifies your request. Thanks.

> MimeTypeService: set correct default xml mimetype
> -
>
> Key: SLING-964
> URL: https://issues.apache.org/jira/browse/SLING-964
> Project: Sling
>  Issue Type: Bug
>  Components: Commons MimeType
>Affects Versions:  Commons Mime 2.0.4
>Reporter: Dominique Jäggi
>Assignee: Felix Meschberger
>Priority: Minor
> Fix For: Extensions Thread Dumper 1.0.0
>
>
> currently the default mime type for .xml extensions is set to "text/html". 
> since this is deprecated i suggest updating the mime type to 
> "application/xml" as per spec.
> i also suggest adding the mime type for rss: "application/rss+xml"

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Commented: (SLING-964) MimeTypeService: set correct default xml mimetype

2009-05-12 Thread Felix Meschberger (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708434#action_12708434
 ] 

Felix Meschberger commented on SLING-964:
-

It looks like the application/rss+xml mime type is not registered with IANA 
(yet?).

Here is the reference for the inclusion with Sling: 
http://www.rssboard.org/news/53/vote-board-supports-rss-mime-type

> MimeTypeService: set correct default xml mimetype
> -
>
> Key: SLING-964
> URL: https://issues.apache.org/jira/browse/SLING-964
> Project: Sling
>  Issue Type: Bug
>  Components: Commons MimeType
>Affects Versions:  Commons Mime 2.0.4
>Reporter: Dominique Jäggi
>Assignee: Felix Meschberger
>Priority: Minor
>
> currently the default mime type for .xml extensions is set to "text/html". 
> since this is deprecated i suggest updating the mime type to 
> "application/xml" as per spec.
> i also suggest adding the mime type for rss: "application/rss+xml"

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (SLING-965) MimeTypeService: expose default mime types config in osgi web console

2009-05-12 Thread JIRA
MimeTypeService: expose default mime types config in osgi web console
-

 Key: SLING-965
 URL: https://issues.apache.org/jira/browse/SLING-965
 Project: Sling
  Issue Type: Improvement
  Components: Commons MimeType
Affects Versions: Commons Mime 2.0.2
Reporter: Dominique Jäggi
Priority: Minor


please consider exposing the default mime types currently being defined in 
launchpad's web.xml as an OSGi configuration accessible through the web console 
or repository based content configuration.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Assigned: (SLING-964) MimeTypeService: set correct default xml mimetype

2009-05-12 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger reassigned SLING-964:
---

Assignee: Felix Meschberger

> MimeTypeService: set correct default xml mimetype
> -
>
> Key: SLING-964
> URL: https://issues.apache.org/jira/browse/SLING-964
> Project: Sling
>  Issue Type: Bug
>  Components: Commons MimeType
>Affects Versions:  Commons Mime 2.0.4
>Reporter: Dominique Jäggi
>Assignee: Felix Meschberger
>Priority: Minor
>
> currently the default mime type for .xml extensions is set to "text/html". 
> since this is deprecated i suggest updating the mime type to 
> "application/xml" as per spec.
> i also suggest adding the mime type for rss: "application/rss+xml"

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Created: (SLING-964) MimeTypeService: set correct default xml mimetype

2009-05-12 Thread JIRA
MimeTypeService: set correct default xml mimetype
-

 Key: SLING-964
 URL: https://issues.apache.org/jira/browse/SLING-964
 Project: Sling
  Issue Type: Bug
  Components: Commons MimeType
Affects Versions:  Commons Mime 2.0.4
Reporter: Dominique Jäggi
Priority: Minor


currently the default mime type for .xml extensions is set to "text/html". 
since this is deprecated i suggest updating the mime type to "application/xml" 
as per spec.
i also suggest adding the mime type for rss: "application/rss+xml"

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: Releases in the future

2009-05-12 Thread Vidar Ramdal
2009/5/12 Juan José Vázquez Delgado :

> As Ian describes, a custom launchpad, including Sling and some other
> bundles, is a typical enterprise-ready package for "Sling solutions".

Agreed.

> IMHO, there is not an easy way to package a Sling based software
> solution now. Along these, I see in Apache Felix Karaf [1] (a.k.a.
> Apache ServiceMix Kernel) a better approach in order to have
> enterprise-ready solutions over OSGi environments. WDYT?

Karaf looks very useful. For us, developing a bunch of our own jars
and scripts, it would greatly simplify deploying and packaging of our
own application.

> [1] http://felix.apache.org/site/apache-felix-karaf.html

-- 
Vidar S. Ramdal  - http://www.idium.no
Akersgata 16, N-0158 Oslo, Norway
+47 21 531941, ext 2070


LoginModulePlugin and AuthenticationHandler

2009-05-12 Thread Ian Boston

Hi,

Short question:
What is the best way to do form based login in the current Sling Trunk ?

Long Question:

I am trying to create a Form based login, that stores the fact the  
user has logged in in the http session, using the  
AuthenticationHandler mechanism in trunk, but I am having trouble  
doing this *without* storing the password.


What I want to achieve is:
UI goes to a URL and performs login,
The AuthenticationHandler produces SimpleCredentials that are used by  
the PluggableDefaultLoginModule to authenticate against the internal  
user manager.


All of that is Ok,

but I also want to store something in http session that records who  
the user is so that on subsequent request the request can be  
associated with the user. (without the browser providing additional  
authentication information, and without storing the password)


The problem I am encountering is that I have no hook into the  
PluggableDefaultLoginModule that allows me to see if the first  
authentication operation was sucessful, so I cant tell if I should  
perform the association or not. Short of storing the password plain  
text (which is against everything I believe in) the only way I can see  
is to directly use SimpleCredentialsAuthentication, which completely  
defeats the purpose of  the AuthenticationHandler and the  
LoginModulePlugin.


BTW, the structure of AuthenticationHandler and LoginModulePlugin are  
perfectly Ok if the handler takes complete responsibility for all  
aspects of authentication (as with the OpenIDAuthenticationHandler),  
but as soon as there is any dependency on the internal authentication,  
I cant see how to do it cleanly.


I hope that makes sense, any pointers, gratefully received.
Thanks
Ian


[jira] Closed: (SLING-963) maven-sling-plugin fix for targetPath without trailing slash

2009-05-12 Thread Stefan Seifert (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert closed SLING-963.



thanks

> maven-sling-plugin fix for targetPath without trailing slash
> 
>
> Key: SLING-963
> URL: https://issues.apache.org/jira/browse/SLING-963
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins
>Affects Versions: Maven Sling Plugin 2.0.2, Maven Sling Plugin 2.0.4
>Reporter: Stefan Seifert
>Assignee: Felix Meschberger
> Fix For: Maven Sling Plugin 2.0.6
>
> Attachments: slingplugin_patch_090512.patch
>
>
> this is a follow-up from SLING-876, which is fixed, but left one cosmetic 
> problem:
> if the path is defined in pom without a trailing slash, the path matching 
> does not work.
> the patch attached fixes this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: Releases in the future

2009-05-12 Thread Felix Meschberger
Hi,

Bertrand Delacretaz schrieb:
> Hi,
> 
> On Mon, May 11, 2009 at 9:03 PM, Felix Meschberger  wrote:
>> ...Basically, we will start releasing single bundles using the regular ASF
>> release process. This should enable us to release much quicker than with
>> big release we have done until now...
> 
> +1, and if we could graduate soon that would make the release process faster 
> ;-)

Yes, I plan to launch this discussion, once the release has been
approved by the IMPC.

Regards
Felix


[jira] Closed: (SLING-961) Parent pom should not include org.osgi.foundation artifact to allow compiling in eclipse

2009-05-12 Thread Stefan Seifert (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Seifert closed SLING-961.



thanks

> Parent pom should not include org.osgi.foundation artifact to allow compiling 
> in eclipse
> 
>
> Key: SLING-961
> URL: https://issues.apache.org/jira/browse/SLING-961
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 5
>Reporter: Stefan Seifert
>Assignee: Felix Meschberger
> Fix For: Parent 6
>
> Attachments: parent_patch_090512.patch
>
>
> the artifact org.osgi.compendium 1.2.0 includes another artifact 
> "org.osgi.foundation" as dependency, which contains several classes included 
> in current JDK release, but as non-generic versions.
> this prevents compiling most sling projects in trunk in eclipse.
> the "org.osgi.foundation" transitive dependency should be excluded in parent 
> pom to prevent this - sling is compiling happily without it.
> patch attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: Releases in the future

2009-05-12 Thread Ian Boston

On 12 May 2009, at 08:55, Felix Meschberger wrote:


What is important to me, is that we will be able to produce simple
applications (or web applications if required) which end-users can  
grab

and run without requiring them to launch a maven (or ant or whatever
tool you like) process.



If I gave my anti java UI guys this, they would stop giving me weird  
looks. IMHO it would remove a big barrier to the adoption of Sling by  
a far wider community.

So big +1 on this aim.
Ian



Regards
Felix




Re: Releases in the future

2009-05-12 Thread Juan José Vázquez Delgado
>  * create OSGi Deployment Packages for use with
>     the Deployment Admin service
>
>  * create Karaf features (requiring respective
>     Karaf support)
>
>  * create a list of dependencies to grab from
>     and OBR at first startup
>
> What is important to me, is that we will be able to produce simple
> applications (or web applications if required) which end-users can grab
> and run without requiring them to launch a maven (or ant or whatever
> tool you like) process.

Absolutely agree. +1.

Juanjo.


[jira] Closed: (SLING-962) Unused imports and missing serialVersionUID

2009-05-12 Thread Ian Boston (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ian Boston closed SLING-962.



closing,
thanks.

> Unused imports and missing serialVersionUID 
> 
>
> Key: SLING-962
> URL: https://issues.apache.org/jira/browse/SLING-962
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: Extensions httpauth 2.0.4
>Reporter: Ian Boston
>Assignee: Felix Meschberger
> Fix For: Extensions httpauth 2.0.6
>
> Attachments: SLING-962.patch
>
>
> There are some weird imports in http auth including java.awt, all unused 
> patch to follow.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



Re: Releases in the future

2009-05-12 Thread Felix Meschberger
Hi,

Juan José Vázquez Delgado schrieb:
>> Many of them are used to a pre configured lamp binary for getting up and
>> going on development fast, building from source doesnt appear to be in their
>> vocab.
> 
> IMHO, there is not an easy way to package a Sling based software
> solution now. Along these, I see in Apache Felix Karaf [1] (a.k.a.
> Apache ServiceMix Kernel) a better approach in order to have
> enterprise-ready solutions over OSGi environments. WDYT?

I have to admit, that I did not look into Karaf yet.

But lets resume what we currently have in Sling:

 * A very small launcher which is a web app or a
standalone java application. (attached artifacts
of the launchpad/base project)

 * A common jar file (we call it the launcher jar
file) containing the actual launch code to
kick of the framework (and to the initial
installations if any) (from the launchpad/base)

 * A packaging which just packs a list of bundles
into a single jar file (the launchpad/bundles
project)

 * A "final" build creating the distributable
Java application or web application from the
the small launcher (web) app, the launcher jar
and the bundles to be included.

 * We have a patch ready to also run the initial
installation from the filesystem.

Now, I understand that the biggest problem is creating the inital set of
bundles. Currently we just include them as explained above. We could also:

  * create OSGi Deployment Packages for use with
 the Deployment Admin service

  * create Karaf features (requiring respective
 Karaf support)

  * create a list of dependencies to grab from
 and OBR at first startup

What is important to me, is that we will be able to produce simple
applications (or web applications if required) which end-users can grab
and run without requiring them to launch a maven (or ant or whatever
tool you like) process.

Regards
Felix



Re: Releases in the future

2009-05-12 Thread Bertrand Delacretaz
On Mon, May 11, 2009 at 10:29 PM, Roy T. Fielding  wrote:
> On May 11, 2009, at 12:03 PM, Felix Meschberger wrote:
>
>> Carsten and I have been reasoning about the releases in the future,
>> mainly the ones for end-users who just want to grab a binary and fire it
>> off

> Apache only releases source code packages.  Those other things you build
> are not releases -- they are binaries that individuals build and upload.

How about naming those things "binary packages" instead of "releases"?

We can still use the same process for releasing them, and include a
disclaimer that they're not official releases and provided without
warranty etc..

That would help clarify things.

-Bertrand


Re: Releases in the future

2009-05-12 Thread Bertrand Delacretaz
Hi,

On Mon, May 11, 2009 at 9:03 PM, Felix Meschberger  wrote:
> ...Basically, we will start releasing single bundles using the regular ASF
> release process. This should enable us to release much quicker than with
> big release we have done until now...

+1, and if we could graduate soon that would make the release process faster ;-)

> ...For the consumer releases we are talking about 4 projects mainly:
>
>  * launchpad/base  - contains the launcher code, Felix framework
>           and the OSGi core and compendium libraries.
>
>  * launchpad/bundles - a very simple project to just pack together
>           existing bundles
>
>  * launchpad/app, launchpad/webapp - projects to create final app
>           and web app from the base and bundles projects
>
> So to release a "consumer product" we update the launchpad/bundles
> project with all the bundles we want to include and prepare the releases
> of the launchpad/bundles, launchpad/app and launchpad/webapp projects

Sounds good, and once we have a bundle repository in place, I could
imagine changing the launchpad to be a minimal launcher shell, using a
structured text file to define a list of bundles to load and maybe
some configuration parameters.  The empty shell would rarely or never
change, maybe it wouldn't even contain the OSGi framework, but load it
from URLs specified in the text file.

That text file is maybe simply a script for the Felix shell or for
Karaf (haven't looked at that closely yet).

Future music...for now, I agree with what you suggest above - except
maybe we shouldn't name those packages "releases", I'll reply to Roy's
comment about that.

-Bertrand


Re: Releases in the future

2009-05-12 Thread Juan José Vázquez Delgado
> As one of those "users" of sling the launchpad structures are working well
> for us. At the moment we take launchpad/bundles as is, and package with
> something close to lauchpad/app.

As Ian describes, a custom launchpad, including Sling and some other
bundles, is a typical enterprise-ready package for "Sling solutions".

> We are intending to give our UI developers an executable Jar to work with
> because when ever I say "you just have to download it and build it" they
> give me a really weird look like, like I have escaped from somewhere.
>
> Many of them are used to a pre configured lamp binary for getting up and
> going on development fast, building from source doesnt appear to be in their
> vocab.

IMHO, there is not an easy way to package a Sling based software
solution now. Along these, I see in Apache Felix Karaf [1] (a.k.a.
Apache ServiceMix Kernel) a better approach in order to have
enterprise-ready solutions over OSGi environments. WDYT?

BR,

Juanjo.

[1] http://felix.apache.org/site/apache-felix-karaf.html


[jira] Resolved: (SLING-963) maven-sling-plugin fix for targetPath without trailing slash

2009-05-12 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved SLING-963.
-

Resolution: Fixed

I have applied your patch in Rev. 773804.

Please close if you are satisfied. Thanks.

> maven-sling-plugin fix for targetPath without trailing slash
> 
>
> Key: SLING-963
> URL: https://issues.apache.org/jira/browse/SLING-963
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins
>Affects Versions: Maven Sling Plugin 2.0.2, Maven Sling Plugin 2.0.4
>Reporter: Stefan Seifert
>Assignee: Felix Meschberger
> Attachments: slingplugin_patch_090512.patch
>
>
> this is a follow-up from SLING-876, which is fixed, but left one cosmetic 
> problem:
> if the path is defined in pom without a trailing slash, the path matching 
> does not work.
> the patch attached fixes this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (SLING-963) maven-sling-plugin fix for targetPath without trailing slash

2009-05-12 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger updated SLING-963:


Fix Version/s: Maven Sling Plugin 2.0.6

> maven-sling-plugin fix for targetPath without trailing slash
> 
>
> Key: SLING-963
> URL: https://issues.apache.org/jira/browse/SLING-963
> Project: Sling
>  Issue Type: Bug
>  Components: Maven Plugins
>Affects Versions: Maven Sling Plugin 2.0.2, Maven Sling Plugin 2.0.4
>Reporter: Stefan Seifert
>Assignee: Felix Meschberger
> Fix For: Maven Sling Plugin 2.0.6
>
> Attachments: slingplugin_patch_090512.patch
>
>
> this is a follow-up from SLING-876, which is fixed, but left one cosmetic 
> problem:
> if the path is defined in pom without a trailing slash, the path matching 
> does not work.
> the patch attached fixes this.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Updated: (SLING-961) Parent pom should not include org.osgi.foundation artifact to allow compiling in eclipse

2009-05-12 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger updated SLING-961:


Fix Version/s: Parent 6

> Parent pom should not include org.osgi.foundation artifact to allow compiling 
> in eclipse
> 
>
> Key: SLING-961
> URL: https://issues.apache.org/jira/browse/SLING-961
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 5
>Reporter: Stefan Seifert
>Assignee: Felix Meschberger
> Fix For: Parent 6
>
> Attachments: parent_patch_090512.patch
>
>
> the artifact org.osgi.compendium 1.2.0 includes another artifact 
> "org.osgi.foundation" as dependency, which contains several classes included 
> in current JDK release, but as non-generic versions.
> this prevents compiling most sling projects in trunk in eclipse.
> the "org.osgi.foundation" transitive dependency should be excluded in parent 
> pom to prevent this - sling is compiling happily without it.
> patch attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (SLING-961) Parent pom should not include org.osgi.foundation artifact to allow compiling in eclipse

2009-05-12 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved SLING-961.
-

Resolution: Fixed

Applied your patch in Rev. 773803.

Please  close this issue, if you are satisfied. Thanks.

> Parent pom should not include org.osgi.foundation artifact to allow compiling 
> in eclipse
> 
>
> Key: SLING-961
> URL: https://issues.apache.org/jira/browse/SLING-961
> Project: Sling
>  Issue Type: Bug
>  Components: General
>Affects Versions: Parent 5
>Reporter: Stefan Seifert
>Assignee: Felix Meschberger
> Attachments: parent_patch_090512.patch
>
>
> the artifact org.osgi.compendium 1.2.0 includes another artifact 
> "org.osgi.foundation" as dependency, which contains several classes included 
> in current JDK release, but as non-generic versions.
> this prevents compiling most sling projects in trunk in eclipse.
> the "org.osgi.foundation" transitive dependency should be excluded in parent 
> pom to prevent this - sling is compiling happily without it.
> patch attached.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Issue Comment Edited: (SLING-962) Unused imports and missing serialVersionUID

2009-05-12 Thread Felix Meschberger (JIRA)

[ 
https://issues.apache.org/jira/browse/SLING-962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12708346#action_12708346
 ] 

Felix Meschberger edited comment on SLING-962 at 5/12/09 12:03 AM:
---

Added the serialVersionUID to the LoginServlet and cleaned up the import list 
of the AuthorizationHeaderAuthenticationHandler in Rev. 773802; the import list 
of the LoginSerlvet has already been cleaned up earlier.

Please close this issue, if you are satisfied. Thanks.

  was (Author: fmeschbe):
Added the serialVersionUID to the LoginServlet and cleaned up the import 
list of the AuthorizationHeaderAuthenticationHandler in Rev. 773802; the import 
list of the LoginSerlvet has already been cleaned up earlier.
  
> Unused imports and missing serialVersionUID 
> 
>
> Key: SLING-962
> URL: https://issues.apache.org/jira/browse/SLING-962
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: Extensions httpauth 2.0.4
>Reporter: Ian Boston
>Assignee: Felix Meschberger
> Fix For: Extensions httpauth 2.0.6
>
> Attachments: SLING-962.patch
>
>
> There are some weird imports in http auth including java.awt, all unused 
> patch to follow.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.



[jira] Resolved: (SLING-962) Unused imports and missing serialVersionUID

2009-05-12 Thread Felix Meschberger (JIRA)

 [ 
https://issues.apache.org/jira/browse/SLING-962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Felix Meschberger resolved SLING-962.
-

   Resolution: Fixed
Fix Version/s: Extensions httpauth 2.0.6

Added the serialVersionUID to the LoginServlet and cleaned up the import list 
of the AuthorizationHeaderAuthenticationHandler in Rev. 773802; the import list 
of the LoginSerlvet has already been cleaned up earlier.

> Unused imports and missing serialVersionUID 
> 
>
> Key: SLING-962
> URL: https://issues.apache.org/jira/browse/SLING-962
> Project: Sling
>  Issue Type: Improvement
>  Components: Engine
>Affects Versions: Extensions httpauth 2.0.4
>Reporter: Ian Boston
>Assignee: Felix Meschberger
> Fix For: Extensions httpauth 2.0.6
>
> Attachments: SLING-962.patch
>
>
> There are some weird imports in http auth including java.awt, all unused 
> patch to follow.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.