Re: JSTL
No worries, I got it all put together. Lots of dependencies... On Tue, Apr 7, 2009 at 9:26 AM, John Crawford wrote: > Hi, > > I pulled down the source for felix and did a quick hack to the commons/jstl > OSGi wrapper pom.xml to gather all dependencies for the jstl into one jar. > After installing it as a bundle (which it does resolve and startup), I still > get the standard error message: The absolute uri: > http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or > the jar files deployed with this applicationI'm a little baffled at this > point. Any suggestions? Obviously, the jstl 1.1.2 dependency is in my > classpath for the ide and my code resolves just fine in development. > > Respectfully, > John >
JSTL
Hi, I pulled down the source for felix and did a quick hack to the commons/jstl OSGi wrapper pom.xml to gather all dependencies for the jstl into one jar. After installing it as a bundle (which it does resolve and startup), I still get the standard error message:The absolute uri: http://java.sun.com/jsp/jstl/core cannot be resolved in either web.xml or the jar files deployed with this applicationI'm a little baffled at this point. Any suggestions? Obviously, the jstl 1.1.2 dependency is in my classpath for the ide and my code resolves just fine in development. Respectfully, John
Re: Felix Framework update
Hi,
Bertrand Delacretaz schrieb:
> On Tue, Apr 7, 2009 at 2:48 PM, Felix Meschberger wrote:
>> ...This has been one of our main hold-backs for a release. If you see
>> anything else really blocking, please tell us so. Otherwise I would say,
>> that we take the next step and start cutting the release
>
> The jcrinstall integration tests fail ("mvn -P jcrinstall-tests clean
> install" in contrib/launchpad/testing). I have to run now, will have a
> look tomorrow morning.
Since JCR Install will not be part of the release, this is IMHO not a
show-stopper.
Regards
Felix
>
>> To this avail, I hereby nominate Carsten Ziegeler as our release manager
>> for this second Sling release.
>
> Sure thing ;-)
>
> -Bertrand
>
Re: Felix Framework update
On Tue, Apr 7, 2009 at 2:48 PM, Felix Meschberger wrote:
> ...This has been one of our main hold-backs for a release. If you see
> anything else really blocking, please tell us so. Otherwise I would say,
> that we take the next step and start cutting the release
The jcrinstall integration tests fail ("mvn -P jcrinstall-tests clean
install" in contrib/launchpad/testing). I have to run now, will have a
look tomorrow morning.
> To this avail, I hereby nominate Carsten Ziegeler as our release manager
> for this second Sling release.
Sure thing ;-)
-Bertrand
Re: Felix Framework update
+1 Good luck Carsten. BR, Juanjo. On Tue, Apr 7, 2009 at 2:48 PM, Felix Meschberger wrote: > Hi all, > > > The Felix framework 1.6.0 release has hit the streets (aka maven repo). > Thus I upgraded the reference to the Felix framework. I have also > upgraded the bundle repository bundle reference to the latest release > 1.4.0 and downgraded the SCR bundle reference to the latest release > 1.0.6. Thus we don't have any snapshot dependencies anymore except our own. > > This has been one of our main hold-backs for a release. If you see > anything else really blocking, please tell us so. Otherwise I would say, > that we take the next step and start cutting the release. > > To this avail, I hereby nominate Carsten Ziegeler as our release manager > for this second Sling release. > > WDYT ? > > Regards > Felix >
Re: Felix Framework update
On Tue, Apr 7, 2009 at 2:48 PM, Felix Meschberger wrote: > [...] > Otherwise I would say, that we take the next step and start cutting the > release. Cool! > To this avail, I hereby nominate Carsten Ziegeler as our release manager > for this second Sling release. My congratulations, or condolences, depending on your view :) -- Vidar S. Ramdal - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
Re: Felix Framework update
Felix Meschberger wrote: > The Felix framework 1.6.0 release has hit the streets (aka maven repo). > Thus I upgraded the reference to the Felix framework. I have also > upgraded the bundle repository bundle reference to the latest release > 1.4.0 and downgraded the SCR bundle reference to the latest release > 1.0.6. Thus we don't have any snapshot dependencies anymore except our own. Hurray! > > This has been one of our main hold-backs for a release. If you see > anything else really blocking, please tell us so. Otherwise I would say, > that we take the next step and start cutting the release. I don't see any blockers. > To this avail, I hereby nominate Carsten Ziegeler as our release manager > for this second Sling release. Urgs, thanks :) Carsten -- Carsten Ziegeler cziege...@apache.org
Sample JEE webapp runs in Sling, using Pax Web Extender
Hi, A while ago, Carsten pointed me to the Pax Web Extender - War [2] service, an extender bundle that makes possible to deploy WAR files into OSGi. As this might be interesting in some integration scenarios, or to keep JEE developers happy, I have created a prototype webapp that can be loaded in Sling as an OSGi bundle. See the README file at [1] for details - feedback is welcome. -Bertrand [1] http://svn.apache.org/repos/asf/incubator/sling/whiteboard/bdelacretaz/pax-webapp/ [2] http://wiki.ops4j.org/display/ops4j/Pax+Web+Extender+-+War
Re: Sling javadocs?
Hi, I have generated JavaDocs from the bundles, which are intended to be included in the upcoming release and uploaded them to [1]. I have just run the javadoc:aggregate goal with some exclusions. I think we can use such javadoc as a first start but would probably need to elaborate a bit more, since such aggregate java doc generally does not make sense and per-module javadoc might be more sensible. Regards Felix [1] http://people.apache.org/~fmeschbe/slingdocs.762729/ Jukka Zitting schrieb: > Hi, > > Something I look for every now and then. Do we have the javadocs of a) > the latest trunk and b) the release up somewhere? > > BR, > > Jukka Zitting >
Felix Framework update
Hi all, The Felix framework 1.6.0 release has hit the streets (aka maven repo). Thus I upgraded the reference to the Felix framework. I have also upgraded the bundle repository bundle reference to the latest release 1.4.0 and downgraded the SCR bundle reference to the latest release 1.0.6. Thus we don't have any snapshot dependencies anymore except our own. This has been one of our main hold-backs for a release. If you see anything else really blocking, please tell us so. Otherwise I would say, that we take the next step and start cutting the release. To this avail, I hereby nominate Carsten Ziegeler as our release manager for this second Sling release. WDYT ? Regards Felix
[jira] Commented: (SLING-712) Adapt Sling Launcher code to new Felix framework launcher mechanism
[ https://issues.apache.org/jira/browse/SLING-712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696493#action_12696493 ] Felix Meschberger commented on SLING-712: - Felix Framework 1.6.0 has hit the streets, so I updated our launchpad/base module to refer to it officially in Rev. 762719 > Adapt Sling Launcher code to new Felix framework launcher mechanism > --- > > Key: SLING-712 > URL: https://issues.apache.org/jira/browse/SLING-712 > Project: Sling > Issue Type: Improvement > Components: Launchpad Launcher >Affects Versions: Launchpad Base 2.0.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Launchpad Base 2.0.4 > > Attachments: SLING-712.patch > > > The Felix framework has modified the launcher mechanism since the 1.0.4 > release. As soon as we updated to a more recent Felix framework version, most > probably 1.4.0, we also have to update the launcher code to integrate with > Felix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-712) Adapt Sling Launcher code to new Felix framework launcher mechanism
[ https://issues.apache.org/jira/browse/SLING-712?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Felix Meschberger closed SLING-712. --- Resolution: Fixed Closing this after upgrading to Felix Framework 1.6.0 > Adapt Sling Launcher code to new Felix framework launcher mechanism > --- > > Key: SLING-712 > URL: https://issues.apache.org/jira/browse/SLING-712 > Project: Sling > Issue Type: Improvement > Components: Launchpad Launcher >Affects Versions: Launchpad Base 2.0.2 >Reporter: Felix Meschberger >Assignee: Felix Meschberger > Fix For: Launchpad Base 2.0.4 > > Attachments: SLING-712.patch > > > The Felix framework has modified the launcher mechanism since the 1.0.4 > release. As soon as we updated to a more recent Felix framework version, most > probably 1.4.0, we also have to update the launcher code to integrate with > Felix. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Created: (SLING-916) Consistently place non-exported classes into packages containing impl or internal
Hi all, I have been starting to experiment whether and how we could deploy Sling JavaDoc and/or sites. This turned out into an experiment of fooling around with the maven site plugin I did not really succeed in generating a basic site, which provides links from the root pom to the modules, since the site plugin does not do this correctly. If we could at least deploy each module separately and still keep some links to a "root page", it would still be ok, I thnk. I am still working on that. What I have had some kind of success is in the generation of an aggregate JavaDoc. But this contains a lot of classes, which are not exported by the bundles and thus may no tbe used. For this reasona I created SLING-916 with the goal to have (almost) all non-exported classes in packages whose name contains impl or internal. I have done this for the main bundles with the exception of the scripting/jsp (repackaing might break compiled JSPs) and the jcr/jackrabbit-usermanager (needs some more investigation). I also set up the root pom to by default not include impl and internal packages in the JavaDoc. In addition a project may set the site.javadoc.exclude property to a list of packages to add to the excludePackageNames configuration property of the javadoc plugin (in addition to impl and internal). More to be documented on the site ... If you encounter any issues with my repackaging, please shout. Thanks. Regards Felix Felix Meschberger (JIRA) schrieb: > Consistently place non-exported classes into packages containing impl or > internal > - > > Key: SLING-916 > URL: https://issues.apache.org/jira/browse/SLING-916 > Project: Sling > Issue Type: Improvement > Components: General > Reporter: Felix Meschberger > Assignee: Felix Meschberger > > > To simplify generation of JavaDocs as well as for consistency, internal > classes should always be located in packages whose name contains > either impl or internal. All Sling bundles, which contain a mix of exported > and private packages are currently already implemented like this. > > Sling bundles, which do not export anything, for example the commons/log or > the extensions/fsresource bundle, are not implemented in this way. > > This issue is about aligning these bundles with the consistent setup. >
[jira] Commented: (SLING-916) Consistently place non-exported classes into packages containing impl or internal
[ https://issues.apache.org/jira/browse/SLING-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696489#action_12696489 ] Felix Meschberger commented on SLING-916: - The scripting/jsp bundle has not been modified at this moment since it contains a modified Jasper which is referred to by the compiled JSP scripts. > Consistently place non-exported classes into packages containing impl or > internal > - > > Key: SLING-916 > URL: https://issues.apache.org/jira/browse/SLING-916 > Project: Sling > Issue Type: Improvement > Components: General >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > To simplify generation of JavaDocs as well as for consistency, internal > classes should always be located in packages whose name contains > either impl or internal. All Sling bundles, which contain a mix of exported > and private packages are currently already implemented like this. > Sling bundles, which do not export anything, for example the commons/log or > the extensions/fsresource bundle, are not implemented in this way. > This issue is about aligning these bundles with the consistent setup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-916) Consistently place non-exported classes into packages containing impl or internal
[ https://issues.apache.org/jira/browse/SLING-916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12696487#action_12696487 ] Felix Meschberger commented on SLING-916: - Rev. 762681: commons/log Rev. 762683: extensions/threaddump Rev. 762685: extensions/fsresource Rev. 762686: extensions/i18n (just remove javadoc plugin config which will be inherited from parent) Rev. 762699: servlets/resolver Rev. 762703: servlets/get Rev. 762707: parent: defaults for JavaDoc generation and preparation for site generation > Consistently place non-exported classes into packages containing impl or > internal > - > > Key: SLING-916 > URL: https://issues.apache.org/jira/browse/SLING-916 > Project: Sling > Issue Type: Improvement > Components: General >Reporter: Felix Meschberger >Assignee: Felix Meschberger > > To simplify generation of JavaDocs as well as for consistency, internal > classes should always be located in packages whose name contains > either impl or internal. All Sling bundles, which contain a mix of exported > and private packages are currently already implemented like this. > Sling bundles, which do not export anything, for example the commons/log or > the extensions/fsresource bundle, are not implemented in this way. > This issue is about aligning these bundles with the consistent setup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-916) Consistently place non-exported classes into packages containing impl or internal
Consistently place non-exported classes into packages containing impl or internal - Key: SLING-916 URL: https://issues.apache.org/jira/browse/SLING-916 Project: Sling Issue Type: Improvement Components: General Reporter: Felix Meschberger Assignee: Felix Meschberger To simplify generation of JavaDocs as well as for consistency, internal classes should always be located in packages whose name contains either impl or internal. All Sling bundles, which contain a mix of exported and private packages are currently already implemented like this. Sling bundles, which do not export anything, for example the commons/log or the extensions/fsresource bundle, are not implemented in this way. This issue is about aligning these bundles with the consistent setup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling @ JavaZone 2009
On Tue, Apr 7, 2009 at 10:34 AM, Vidar Ramdal wrote: > I'm thinking of submitting a presentation on Sling at this year's > JavaZone in Oslo (http://www.java.no/javazone/2009/) in September... Great! > ...I'll probably go with a presentation similar to Bertrand's at > ApacheCon EU - an introduction to Sling and the technologies it is > built on, and a demo of some cool stuff you can do with sling (like > the blogging app). > > Does anyone have any particular subject wishes for what should be > included in the presentation?... Giving more exposure to Sling's JSON storage/retrieval features might be good - next time I give a Sling presentation I'll probably refocus my message a bit: -Sling uses JCR for storage (filesystem on steroids, hierarchy, rich properties, WebDAV, observation, ...) -Sling uses OSGi for modularity (even bundles in repository using jcrinstall) -Sling can use scripts (many languages) or servlets to process HTTP requests (show the nice URL decomposition) -The Sling HTTP/JSON interface (including powerful search) enables modern ajaxish applications Feel free to reuse stuff for my presentation, of course. -Bertrand [1] http://www.slideshare.net/bdelacretaz/rapid-jcr-applications-development-with-sling-1196003
Sling @ JavaZone 2009
I'm thinking of submitting a presentation on Sling at this year's JavaZone in Oslo (http://www.java.no/javazone/2009/) in September. This could give some publicity for the project, and potentially attract new Sling users in Norway (not to mention a free ticket to the conference and free beer in the speaker's lounge :). For this, I have to submit an abstract before April 15. I'll probably go with a presentation similar to Bertrand's at ApacheCon EU - an introduction to Sling and the technologies it is built on, and a demo of some cool stuff you can do with sling (like the blogging app). Does anyone have any particular subject wishes for what should be included in the presentation? -- Vidar S. Ramdal - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
Re: Welcome Vidar Ramdal as our new Sling committer!
On Mon, Apr 6, 2009 at 9:53 PM, Bertrand Delacretaz wrote: > ...Vidar's account has been created, used vramdal should have commit > access on Sling now I have also added Vidar's name on the list at http://incubator.apache.org/sling/site/project-team.html and a news item at http://incubator.apache.org/projects/sling.html, both should be updated in a few hours. -Bertrand
