Re: Sling Release
Hi Carsten, There is currently a single issue (SLING-933 [1]) open. We have a request by Aaron Zeckoski to also include SLING-933 [2] in the release. For SLING-933 I will have to wait a few hours for the Apache Felix SCR bundle 1.0.8 to hit the central maven repository, at which time I will then fix this issue. For SLING-933: Aaron provided a pretty good patch, to which I had some comments. I am not sure, whether we should stop the release to wait for this (valuable) addition. I would rather like to go with the release and take our time to cleanly implement this new feature and release the launchpad/base module as soon as we are done. Apart from these issues, there are none left [3]. The others mentioned in an earlier posts have either been closed (SLING-793, SLING-938) or I descheduled (SLING-926, SLING-604, SLING-841) them for a later release. Regards Felix [1] https://issues.apache.org/jira/browse/SLING-933 [2] https://issues.apache.org/jira/browse/SLING-922 [3] https://issues.apache.org/jira/secure/IssueNavigator.jspa?requestId=12312970 Carsten Ziegeler schrieb: Hello everyone, I'm planning to do the release next monday or tuesday. We have two missing pieces atm, one is the Felix framework 1.6.1 release (which should be available now) and the Felix SCR 1.0.8 implementation (which should be available by monday). So if you think that we need to anything in svn before the release, this is the time to step up :) I'll release the modules in bundles, launchpad and maven plugins and will create a single release download like we did for our first release for convenience. After this big release we can think about releasing samples etc. separately. Regards Carsten
Re: Sling Release
Hi, Ping. Anyone interested in pushing out a new release? BR, Jukka Zitting
Re: Sling Release
Hi, Jukka Zitting schrieb: Ping. Anyone interested in pushing out a new release? I am not sure how interested he really is ;-) But IIRC Carsten agreed to stand in as the RM for it. Regards Felix
Re: Sling Release
Hi, On Wed, Apr 29, 2009 at 2:53 PM, Felix Meschberger fmesc...@gmail.com wrote: Jukka Zitting schrieb: Ping. Anyone interested in pushing out a new release? I am not sure how interested he really is ;-) But IIRC Carsten agreed to stand in as the RM for it. Yeah, I saw that. Just pinging on whether we're still doing the release. BR, Jukka Zitting
Re: Sling Release
Jukka Zitting wrote: Hi, On Wed, Apr 29, 2009 at 2:53 PM, Felix Meschberger fmesc...@gmail.com wrote: Jukka Zitting schrieb: Ping. Anyone interested in pushing out a new release? I am not sure how interested he really is ;-) But IIRC Carsten agreed to stand in as the RM for it. Yeah, I saw that. Just pinging on whether we're still doing the release. Yes, we're doing the release - the question is what still needs to be done before the release! Afaik, one thing is the SCR plugin from the Felix project. Do we have some other bugs that need to be really fixed? Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Sling Release
Hi, Carsten Ziegeler schrieb: Jukka Zitting wrote: Hi, On Wed, Apr 29, 2009 at 2:53 PM, Felix Meschberger fmesc...@gmail.com wrote: Jukka Zitting schrieb: Ping. Anyone interested in pushing out a new release? I am not sure how interested he really is ;-) But IIRC Carsten agreed to stand in as the RM for it. Yeah, I saw that. Just pinging on whether we're still doing the release. Yes, we're doing the release - the question is what still needs to be done before the release! Afaik, one thing is the SCR plugin from the Felix project. Do we have some other bugs that need to be really fixed? I have created a JIRA query at [1], which lists the following open issues: SLING-926 Do not render directory on included request - would be very nice to have SLING-793 Improve property file includes - is this really required ? SLING-604 Multi value properties not properly supported by ScriptableNode.get(String) method - might want to postpone SLING-841 Set thread context class loader on behalf of script engines - might want to postpone SLING-933 Upgrade to latest SCR release - blocker IMHO SLING-938 Refine initiaition of the authentication process - almost finished So, given that SLING-938 is almost finished, SLING-926 is small and probably a good thing, we are just waiting for the SCR release (currently under vote in Apache Felix) for SLING-933. There quite a number of open issues currently, but none is attributed to a version. Also I left out the version tags for JCR Install and other projects in the contrib subtree. WDYT ? Regards Felix [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?requestId=12312970 Regards Felix
Re: Cocoon pipelines in Sling, using XPL - thanks Juanjo! (was: Sling Release)
Exciting stuff for an old xslt head like myself. Just wondering, if the xpl file is at /apps/xproc/xproc.xpl, what tells sling that it should resolve the .html extension in this example to the script? I would have guessed /apps/xproc/sling/servlet/default/html.xpl .. Regards, Erik Buene 2009/4/1 Bertrand Delacretaz bdelacre...@apache.org Hi, 2009/4/1 Juan José Vázquez Delgado juanjo.vazq...@gmail.com: Bertrand said: SLING-893 Pipeline support - still in the whiteboard, right? I'm going to test it today. As discussed in [1], pipeline support stuff has been already saved in contrib [2]. I´m going to close SLING-893 and open new issues for enhancements Great, thanks! I made minor improvements to error reporting (SLING-908), below are some notes about how to use this - we'll need to turn this (or better examples) into some docs later on. For now, just saving this here. Cool stuff! -Bertrand Example using the xproc script engine - rough notes: 1) Install the org.apache.sling.scripting.xproc bundle (found in contrib/scripting/xproc) 2) Create some content: $ curl -F sling:resourceType=xproc -F title=some title -F text=And some text http://admin:ad...@localhost:/foo 3) Create a pipeline script at /apps/xproc/xproc.xpl: ?xml version=1.0 encoding=UTF-8? p:pipeline xmlns:p=http://www.w3.org/ns/xproc; p:xslt p:input port=stylesheet p:document href=/apps/xproc/one.xsl/ /p:input /p:xslt p:xslt p:input port=stylesheet p:document href=/apps/xproc/two.xsl/ /p:input /p:xslt /p:pipeline 4) Store the XSLT transforms in the repository: /apps/xproc/one.xsl: xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:template match=/ one xsl:copy-of select=./ /one /xsl:template /xsl:stylesheet /apps/xproc/two.xsl: xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:template match=/ two xsl:copy-of select=./ /two /xsl:template /xsl:stylesheet 5) Request foo.html to execute the pipeline: $ curl http://admin:ad...@localhost:/foo.html ?xml version=1.0 encoding=UTF-8? two one foo ...sling:resourceType=xproc text=And some text title=some title/ /one /two
Re: Use the next Sling Release to enhance to community
Hi Mike, Mike Müller schrieb: Hi all, First of all, I would like to thank all of you for the big efforts to enhance and refine sling step by step. I'm watching the project since a few months for now and tested sling in a few simple projects - and it really is very easy to use it right from scratch. Thanks to you ;-) But to be honest, it's rather hard to really get into the code of sling if you try to build a complex app, not only based on scripting. The big problem by now for a non-sling-insider is the documentation. The website mostly is outdated. Dont' get me wrong, I know sling is open source and all free, so nobody has to bother about missing things. And yes, if you try hard enough, you also get into the details of sling. But that's the problem of the project: I think sling is such a good project it should get out of the incubator. The project is mature, it is tested in real projects (as Day's CQ5) and it evolves further. It seems that the only thing which holds sling off to get out the incubator is the list of active committers outside Day. My company would like to move our products on a sling based core and we also are interested to develop sling and help to enhance it. To make it easier for others to use and also contribute to sling, I think the following things would be as impo rtant as the source code itself: First of all: We are perfectly aware of this situation, but fail to be able to really cope with it in the sense of updating all docs, due to overfilled time tables (you know the problem ;-) ). One thing you could do, except of contributing code of course, is to contribute documentation ;-) 1) an up-to-date website with documentation about the core part of sling (like architecture, request processing, which services/interfaces are exposed by the core of sling and which are additional services/interfaces?, how and where can you enhance sling - servlets, scripting, components) 2) a short getting started guide for developers e.g. how do I develop for sling with eclipse without getting long roundtrips (or other IDEs, what's about the eclipse plugin for jcr/sling?) 3) a short how-to guide for a real productive installation (like apache as front server with mod_proxy or similar) +1 for 1-3 Sounds good and this is also what is spinning around in our heads .. but it never finds time to spin down into the fingers and over the wires. 4) a separation of the core code and the additional bundles (as it is already planed for the new release) - maybe almost done? Carsten has already done that. We now have the main folders (parent, api, bundles and launchpad) which constitute what's going into the next big release. And we have the contrib folder (with the same structure as the bundles folder), which are additional bundles, we will be releasing separately later, based on community requirements. It's great to hear that there will be soon a new release of sling. IMHO the new release should be really used to get more people using sling and also to get more people be involved in sling development. Maybe in favour of a consistent documentation the release should be delayed. We have discussed delaying the release for documentation before the first release (which dates back almost a year now!). And we decided to cut the release and then update the docs. My position is to do the same this time... The release is overdue as is the docs. But I think first things first and the docs will surely follow. Promised. Finally: As I said, contribution is also possible in the form of documentation and we very much welcome documentation contribution. Hope this helps to understand the situation as it is. Regards Felix WDYT? regards Mike
Re: Cocoon pipelines in Sling, using XPL - thanks Juanjo! (was: Sling Release)
Hi, Exciting stuff for an old xslt head like myself. Yeap, XST is still the best option in a lot of situations. Just wondering, if the xpl file is at /apps/xproc/xproc.xpl, what tells sling that it should resolve the .html extension in this example to the script? I would have guessed /apps/xproc/sling/servlet/default/html.xpl .. Because of resource type is xproc, you have: /apps +-- xproc [resource type in our case] -- xproc.xpl [xpl - script manager is XProc xproc - is not an extesion, so relies on default, i.e. html] Hope this helps, Juanjo.
Re: Cocoon pipelines in Sling, using XPL - thanks Juanjo! (was: Sling Release)
Just wondering, if the xpl file is at /apps/xproc/xproc.xpl, what tells sling that it should resolve the .html extension in this example to the script? I would have guessed /apps/xproc/sling/servlet/default/html.xpl .. Because of resource type is xproc, you have: /apps +-- xproc [resource type in our case] -- xproc.xpl [xpl - script manager is XProc xproc - is not an extesion, so relies on default, i.e. html] Of course, should have seen that, but it supports extentions and methods as well, right? Sure, html.xpl is fine too. Juanjo.
Re: Cocoon pipelines in Sling, using XPL - thanks Juanjo! (was: Sling Release)
Hi 2009/4/3 Juan José Vázquez Delgado juanjo.vazq...@gmail.com Just wondering, if the xpl file is at /apps/xproc/xproc.xpl, what tells sling that it should resolve the .html extension in this example to the script? I would have guessed /apps/xproc/sling/servlet/default/html.xpl .. Because of resource type is xproc, you have: /apps +-- xproc [resource type in our case] -- xproc.xpl [xpl - script manager is XProc xproc - is not an extesion, so relies on default, i.e. html] Of course, should have seen that, but it supports extentions and methods as well, right? Cheers, Erik Buene
Re: Cocoon pipelines in Sling, using XPL - thanks Juanjo! (was: Sling Release)
Hi, Bertrand Delacretaz schrieb: Hi, 2009/4/1 Juan José Vázquez Delgado juanjo.vazq...@gmail.com: Bertrand said: SLING-893 Pipeline support - still in the whiteboard, right? I'm going to test it today. As discussed in [1], pipeline support stuff has been already saved in contrib [2]. I´m going to close SLING-893 and open new issues for enhancements Great, thanks! +1 I made minor improvements to error reporting (SLING-908), below are some notes about how to use this - we'll need to turn this (or better examples) into some docs later on. For now, just saving this here. Cool stuff! -Bertrand Example using the xproc script engine - rough notes: I have created a documentation page at [1] which should shortly appear on our site (follow Development - Integrating Scripting Languages - XSLT ...) This page may be edited directly in the SLINGxSITE wiki to update the site. Regards Felix
Re: Cocoon pipelines in Sling, using XPL - thanks Juanjo! (was: Sling Release)
On Fri, Apr 3, 2009 at 1:53 PM, Felix Meschberger fmesc...@gmail.com wrote: I have created a documentation page at [1] which should shortly appear on our site (follow Development - Integrating Scripting Languages - XSLT ...) Thanks! Just added a note that the xproc module uses the Cocoon 3 pipeline engine. -Bertrand [1] http://cwiki.apache.org/confluence/display/SLINGxSITE/XSLT+Processing+Pipeline
Re: Cocoon pipelines in Sling, using XPL - thanks Juanjo! (was: Sling Release)
I have created a documentation page at [1] which should shortly appear on our site (follow Development - Integrating Scripting Languages - XSLT ...) This page may be edited directly in the SLINGxSITE wiki to update the site. Thanks Felix. I´ll work at it soon. Juanjo.
AW: Use the next Sling Release to enhance to community
Hi Felix First of all: We are perfectly aware of this situation, but fail to be able to really cope with it in the sense of updating all docs, due to overfilled time tables (you know the problem ;-) ). yes, you're totally right, I know exactly the problem :-) One thing you could do, except of contributing code of course, is to contribute documentation ;-) that's correct. but to be clear, to provide a good documentation, you have to have deep knowledge of the project, which is - unfortunately - hard (or better say time consuming) to get without a documentation... To have more people getting involved, to have more committers - even only committers for more documentation, there should be at least some basic up to date documentation about the core. I really know the difficult situation, but if it's the ambition to get out of the incubator (hope it is?) someone of the core team has to bite the bullet. 1) an up-to-date website with documentation about the core part of sling (like architecture, request processing, which services/interfaces are exposed by the core of sling and which are additional services/interfaces?, how and where can you enhance sling - servlets, scripting, components) 2) a short getting started guide for developers e.g. how do I develop for sling with eclipse without getting long roundtrips (or other IDEs, what's about the eclipse plugin for jcr/sling?) 3) a short how-to guide for a real productive installation (like apache as front server with mod_proxy or similar) +1 for 1-3 Sounds good and this is also what is spinning around in our heads .. but it never finds time to spin down into the fingers and over the wires. Maybe your expectations are to high: In my mind 1) should be a short but precise docu about the core and how to extend/enhance it. (an indiscreet question: is there no docu stuff from CRX which Day would provide to reshape for sling?) 2) the release of the plugin would be a big push for sling. documentation here is not the big issue, here I agree, if the plugin is published, the documentation could be done by new committers like our company could be. 3) has lower priority for me than 1 and 2. We have discussed delaying the release for documentation before the first release (which dates back almost a year now!). And we decided to cut the release and then update the docs. My position is to do the same this time... The release is overdue as is the docs. But I think first things first and the docs will surely follow. Promised. if you promise it :-)) Hope this helps to understand the situation as it is. To be clear: I really understand your situation but would like to see the sling community growing... regards mike
Re: Cocoon pipelines in Sling, using XPL - thanks Juanjo! (was: Sling Release)
2009/4/1 Juan José Vázquez Delgado juanjo.vazq...@gmail.com: ...I hope to have samples and more improvements soon... It would be cool to explain to the Cocoon community what you've done, and maybe some parts could be of general interest and could move there? Ideally, describing what you've done on the wiki in terms of how the Cocoon stuff is used would help. I could do that, but you probably know better - or feel free to point me to existing info. I've been more or less out of touch with Sling in the last few weeks, might have missed something. -Bertrand
Use the next Sling Release to enhance to community
Hi all, First of all, I would like to thank all of you for the big efforts to enhance and refine sling step by step. I'm watching the project since a few months for now and tested sling in a few simple projects - and it really is very easy to use it right from scratch. But to be honest, it's rather hard to really get into the code of sling if you try to build a complex app, not only based on scripting. The big problem by now for a non-sling-insider is the documentation. The website mostly is outdated. Dont' get me wrong, I know sling is open source and all free, so nobody has to bother about missing things. And yes, if you try hard enough, you also get into the details of sling. But that's the problem of the project: I think sling is such a good project it should get out of the incubator. The project is mature, it is tested in real projects (as Day's CQ5) and it evolves further. It seems that the only thing which holds sling off to get out the incubator is the list of active committers outside Day. My company would like to move our products on a sling based core and we also are interested to develop sling and help to enhance it. To make it easier for others to use and also contribute to sling, I think the following things would be as important as the source code itself: 1) an up-to-date website with documentation about the core part of sling (like architecture, request processing, which services/interfaces are exposed by the core of sling and which are additional services/interfaces?, how and where can you enhance sling - servlets, scripting, components) 2) a short getting started guide for developers e.g. how do I develop for sling with eclipse without getting long roundtrips (or other IDEs, what's about the eclipse plugin for jcr/sling?) 3) a short how-to guide for a real productive installation (like apache as front server with mod_proxy or similar) 4) a separation of the core code and the additional bundles (as it is already planed for the new release) - maybe almost done? It's great to hear that there will be soon a new release of sling. IMHO the new release should be really used to get more people using sling and also to get more people be involved in sling development. Maybe in favour of a consistent documentation the release should be delayed. WDYT? regards Mike
Re: Use the next Sling Release to enhance to community
Hi there, I heard a rumor that day is planning a sling training in the near future? Is that so and if yes, could that lead to a better documentation for sling? Ruben Dominik Süß wrote: Hi Mike, you're not the only one who did address this issue. This pops up in the mailing list from time-to-time and on conventions like ApacheCon last week. The main problem about that seams that the commiters are involved in a lot of projects (as well the apache projects as the day products). Since Sling does not have that many other commiters there is just a lack of time for documentation. And since there is almost nothing in the existing documentation which isn't at least in details outdated no one except the core team feels capable enough to write a basic documentation. I really hope someone will do the move and try to write a basic documentation. The getting started guide would propably be something even someone of us users could write and contribute. I would like to do this but I'm always out of time and the rare time I have left is reserved by my girlfriend. (planning to write something since the first official release). I even did plan some kind of multipart tutorial which allows to start with a simple app which grows from step to step and uses all those funky features we have (like versioning and observations). If there is anyone out there who wants to support me in doing this little project please mail me directly (since I wouldn't like to spam the mailing list without having at least a skeleton of this). Any other ideas out there how to get better documentation? Best regards, Dominik On Thu, Apr 2, 2009 at 4:11 PM, Mike Müller mike...@mysign.ch wrote: Hi all, First of all, I would like to thank all of you for the big efforts to enhance and refine sling step by step. I'm watching the project since a few months for now and tested sling in a few simple projects - and it really is very easy to use it right from scratch. But to be honest, it's rather hard to really get into the code of sling if you try to build a complex app, not only based on scripting. The big problem by now for a non-sling-insider is the documentation. The website mostly is outdated. Dont' get me wrong, I know sling is open source and all free, so nobody has to bother about missing things. And yes, if you try hard enough, you also get into the details of sling. But that's the problem of the project: I think sling is such a good project it should get out of the incubator. The project is mature, it is tested in real projects (as Day's CQ5) and it evolves further. It seems that the only thing which holds sling off to get out the incubator is the list of active committers outside Day. My company would like to move our products on a sling based core and we also are interested to develop sling and help to enhance it. To make it easier for others to use and also contribute to sling, I think the following things would be as important as the source code itself: 1) an up-to-date website with documentation about the core part of sling (like architecture, request processing, which services/interfaces are exposed by the core of sling and which are additional services/interfaces?, how and where can you enhance sling - servlets, scripting, components) 2) a short getting started guide for developers e.g. how do I develop for sling with eclipse without getting long roundtrips (or other IDEs, what's about the eclipse plugin for jcr/sling?) 3) a short how-to guide for a real productive installation (like apache as front server with mod_proxy or similar) 4) a separation of the core code and the additional bundles (as it is already planed for the new release) - maybe almost done? It's great to hear that there will be soon a new release of sling. IMHO the new release should be really used to get more people using sling and also to get more people be involved in sling development. Maybe in favour of a consistent documentation the release should be delayed. WDYT? regards Mike
Sling Release
Hi all, Just wanted to inform you all (at least the ones not sitting on felix-dev@), that the Felix project is currently voting on the 1.6.0 release of the Felix framework. I tested Sling with the release candidate and apart from a small issue in Sling [1], it works flawlessly. I assume that, given the vote passes, we should release Sling next week. WDYT ? Regards Felix
Re: Sling Release
On Wed, Apr 1, 2009 at 9:37 AM, Felix Meschberger fmesc...@gmail.com wrote: Hi all, Just wanted to inform you all (at least the ones not sitting on felix-dev@), that the Felix project is currently voting on the 1.6.0 release of the Felix framework. I tested Sling with the release candidate and apart from a small issue in Sling [1], it works flawlessly. I assume that, given the vote passes, we should release Sling next week. WDYT ? Great. Is there a list of issues that should be resolved before the release? And, more specifically, will SLING-880 [1] be on that list? :) [1] https://issues.apache.org/jira/browse/SLING-880 -- Vidar S. Ramdal vi...@idium.no - http://www.idium.no Akersgata 16, N-0158 Oslo, Norway +47 21 531941, ext 2070
Re: Sling Release
Hi, Vidar Ramdal schrieb: On Wed, Apr 1, 2009 at 9:37 AM, Felix Meschberger fmesc...@gmail.com wrote: Hi all, Just wanted to inform you all (at least the ones not sitting on felix-dev@), that the Felix project is currently voting on the 1.6.0 release of the Felix framework. I tested Sling with the release candidate and apart from a small issue in Sling [1], it works flawlessly. I assume that, given the vote passes, we should release Sling next week. WDYT ? Great. Is there a list of issues that should be resolved before the release? And, more specifically, will SLING-880 [1] be on that list? :) [1] https://issues.apache.org/jira/browse/SLING-880 I assume it goes along the line of [1] and since you tagged SLING-880 for the next jackrabbit-server release, we should really apply this patch before releasing. BTW, my initial mail missed a link which is to SLING-905 [2] Regards Felix [1] https://issues.apache.org/jira/secure/IssueNavigator.jspa?mode=showrequestId=12312970 [2] https://issues.apache.org/jira/browse/SLING-905
Re: Sling Release
On Wed, Apr 1, 2009 at 9:37 AM, Felix Meschberger fmesc...@gmail.com wrote: ...I assume that, given the vote passes, we should release Sling next week Shouldn't we rather ask which issues need to (or can easily be) solved before releasing? (and I also have a POLL coming up w.r.t scripting in general, but that might be for after the release) I went through our oustanding issues, here's the ones that I feel might go into our next release: SLING-893 Pipeline support - still in the whiteboard, right? I'm going to test it today. SLING-887 Include Dojo 1.2.3 SLING-884 [PATCH] Sling Commons Java Compiler SLING-849 Enhance SlingAuthenticator's handler selection mechanism - can probably be closed SLING-868 NPE in SlingAuthenticator.findApplicableAuthenticationHandler (ugly) SLING-845 Full build with integration test leaves sling folder in root SLING-829 Cosmetic: Clean up bundle and configuration names SLING-880 Pluggable AccessManager (suggested by Vidar) I'm not saying all of those must go into the release, but I think we should evaluate them. -Bertrand
Re: Sling Release
I think we should just update to the latest Felix framework and then release. Everything else can be fixed later on. With bundles we can just release separate bundles frequently. The only real issue I see atm are the failing tests. Carsten -- Carsten Ziegeler cziege...@apache.org
Re: Sling Release
SLING-893 Pipeline support - still in the whiteboard, right? I'm going to test it today. As discussed in [1], pipeline support stuff has been already saved in contrib [2]. I´m going to close SLING-893 and open new issues for enhancements. BTW, we have some contrib tests failing too (SLING-869 [3]). Juanjo. [1] http://markmail.org/thread/33h5nhk5e3mswrue [2] http://svn.apache.org/repos/asf/incubator/sling/trunk/contrib/scripting/xproc [3] https://issues.apache.org/jira/browse/SLING-869
Cocoon pipelines in Sling, using XPL - thanks Juanjo! (was: Sling Release)
Hi, 2009/4/1 Juan José Vázquez Delgado juanjo.vazq...@gmail.com: Bertrand said: SLING-893 Pipeline support - still in the whiteboard, right? I'm going to test it today. As discussed in [1], pipeline support stuff has been already saved in contrib [2]. I´m going to close SLING-893 and open new issues for enhancements Great, thanks! I made minor improvements to error reporting (SLING-908), below are some notes about how to use this - we'll need to turn this (or better examples) into some docs later on. For now, just saving this here. Cool stuff! -Bertrand Example using the xproc script engine - rough notes: 1) Install the org.apache.sling.scripting.xproc bundle (found in contrib/scripting/xproc) 2) Create some content: $ curl -F sling:resourceType=xproc -F title=some title -F text=And some text http://admin:ad...@localhost:/foo 3) Create a pipeline script at /apps/xproc/xproc.xpl: ?xml version=1.0 encoding=UTF-8? p:pipeline xmlns:p=http://www.w3.org/ns/xproc; p:xslt p:input port=stylesheet p:document href=/apps/xproc/one.xsl/ /p:input /p:xslt p:xslt p:input port=stylesheet p:document href=/apps/xproc/two.xsl/ /p:input /p:xslt /p:pipeline 4) Store the XSLT transforms in the repository: /apps/xproc/one.xsl: xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:template match=/ one xsl:copy-of select=./ /one /xsl:template /xsl:stylesheet /apps/xproc/two.xsl: xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xsl:template match=/ two xsl:copy-of select=./ /two /xsl:template /xsl:stylesheet 5) Request foo.html to execute the pipeline: $ curl http://admin:ad...@localhost:/foo.html ?xml version=1.0 encoding=UTF-8? two one foo ...sling:resourceType=xproc text=And some text title=some title/ /one /two
Re: Cocoon pipelines in Sling, using XPL - thanks Juanjo! (was: Sling Release)
SLING-893 Pipeline support - still in the whiteboard, right? I'm going to test it today. As discussed in [1], pipeline support stuff has been already saved in contrib [2]. I´m going to close SLING-893 and open new issues for enhancements Great, thanks! I made minor improvements to error reporting (SLING-908), below are some notes about how to use this - we'll need to turn this (or better examples) into some docs later on. For now, just saving this here. Cool stuff! wow, thnks!. Example using the xproc script engine - rough notes: . Cool sample. I hope to have samples and more improvements soon. Regards, Juanjo.
Re: Sling Release
Hi all, Am 06.01.2009 um 12:38 schrieb Felix Meschberger: After all the enhancements and bugfixes to Sling in the last months since the first release, I think it is about time to consider a new release. good to hear that ;) I think we should push forward the release in a few steps: (1) Remove Dependency Management from the parent pom (see [1]). (2) Release Sling Parent POM, Version 5 (2a) Upgrade all Sling projects to use Sling Parent POM 5 (3) Decide on bugs to be fixed for the release +1 for the proposed steps could you please consider to include SLING-784 for the release, because we depend on it in our next CQ5 version. regards, alex
ETA for Sling release?
Hi Carsten I hate to do what makes me (as a product mgr) frown a lot... but what's the current ETA for Sling release? I'm aware of the license and notice files discussion [1] - somewhat painful, but better done before the release in any case. [1] http://markmail.org/message/2enw6ktxhc4ixmrk Some people really want it, now^H^H^H a.s.a.p. :) Cheers Greg -- -- Greg Klebus | http://day.com | http://dev.day.com -- Best open-source JCR repository: http://jacrkabbit.apache.org -- ** Day JCR Cup 08** | Win a MacBook Pro: http://dev.day.com
Re: ETA for Sling release?
On Thu, Jun 12, 2008 at 10:44 AM, Greg Klebus [EMAIL PROTECTED] wrote: Some people really want it, now^H^H^H a.s.a.p. :) I can only second that. I understand legal discussions, but nevertheless the attraction of sling far outweighs that. our project would benefit extremely. so yeah, what's the ETA? :) dom.
Re: ETA for Sling release?
Hi, ok, the honest answer is that we don't have a fixed date - it happens when it happens :) For sure, that answer does not satisfy, so I can outline the best case scenario. I'll adjust the notice files and the other stuff as discussed tomorrow. Hopefully others can help with the readme files. So we should have a version on monday or tuesday. Then we have to vote on this version in the Sling project - the vote has to be open for 72 hours. This means we should finish the vote by the end of next week. As Sling is in incubation, the incubator PMC has to vote after that as well - again for 72 hours; as it is not the best idea to hold a vote over the week, we might start the vote on friday/saturday but leave it open for 96 hours until tuesday/wednesday. Keeping the story short - the optimum would be to have the final version around the 25th of June. But if any problems are detected throughout the whole process, we have to restart it from the beginning! Which adds approx. 10 to 14 days each time! So the best thing is that people help with getting it right the first time (well, it's the third time actually...) and help getting the readme's done, add docs, check the notice files after I change them and report potential problems before I will build the release candidate. Carsten Dominique Jäggi wrote: On Thu, Jun 12, 2008 at 10:44 AM, Greg Klebus [EMAIL PROTECTED] wrote: Some people really want it, now^H^H^H a.s.a.p. :) I can only second that. I understand legal discussions, but nevertheless the attraction of sling far outweighs that. our project would benefit extremely. so yeah, what's the ETA? :) dom. -- Carsten Ziegeler [EMAIL PROTECTED]
Re: ETA for Sling release?
Carsten On Thu, Jun 12, 2008 at 11:14 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ok, the honest answer is that we don't have a fixed date - it happens when it happens :) For sure, that answer does not satisfy, so I can outline the best case scenario. Good answer :) I'll adjust the notice files and the other stuff as discussed tomorrow. Hopefully others can help with the readme files. So we should have a version on monday or tuesday. Then we have to vote on this version in the Sling project - the vote has to be open for 72 hours. This means we should finish the vote by the end of next week. As Sling is in incubation, the incubator PMC has to vote after that as well - again for 72 hours; as it is not the best idea to hold a vote over the week, we might start the vote on friday/saturday but leave it open for 96 hours until tuesday/wednesday. Keeping the story short - the optimum would be to have the final version around the 25th of June. But if any problems are detected throughout the whole process, we have to restart it from the beginning! Which adds approx. 10 to 14 days each time! Thanks, that helps me a lot. Does that mean that the compiled release (*) will be available in maven repositories also around 25th June in the best case? So the best thing is that people help with getting it right the first time (well, it's the third time actually...) and help getting the readme's done, add docs, check the notice files after I change them and report potential problems before I will build the release candidate. Fair enough. Thanks for your hard work on this. Regards, Greg (*) I know Apache projects release source code, and the built binaries are just to help the users. This are indeed very helpful for us consumer of this technology.
Re: ETA for Sling release?
Greg Klebus wrote: Thanks, that helps me a lot. Does that mean that the compiled release (*) will be available in maven repositories also around 25th June in the best case? Yes, after the vote is successfully finished, I deploy the artifacts directly into a maven repository. From there they're synced to the central maven repo - usually this happens after some ours. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Hi, Am Mittwoch, den 04.06.2008, 19:31 +0200 schrieb Carsten Ziegeler: The depenencies are now all set to 2.0.1-incubator-SNAPSHOT. Once the release is out to the maven repos, we will revert this to 2.0.0-incubator where appropriate. Very good. I would suggest we revert _all_ cross-dependencies to the release versions and just upgrade to snapshot references where required. Regards Felix Carsten Carsten Ziegeler wrote: I'm finished with building the release artifacts. Please note that our current trunk is not buildable due to this. The artifacts reference the release versions which are not available in a public maven repository and the versions in our svn are set to the next snapshot. I'll correct this asap and start the vote. Carsten
Re: Sling Release
On Wed, Jun 4, 2008 at 12:35 AM, Roy T. Fielding [EMAIL PROTECTED] wrote: ...I'd rather have a set of hand-edited NOTICE files that accurately reflect each of the release packages I see your point, and thanks for your changes in etc/notice/notices, that will help a lot. The nice thing (IMHO) about generating the notices from the Maven dependencies, is that this will expose any new dependencies that might have been added next time we do a release, without having to manually check our 55 notice files by hand. But I agree about refining the process with exceptions, I'll modify the mknotice script now, to ignore #comment lines. -Bertrand
Re: Sling Release
Bertrand Delacretaz wrote: On Wed, Jun 4, 2008 at 12:35 AM, Roy T. Fielding [EMAIL PROTECTED] wrote: ...I'd rather have a set of hand-edited NOTICE files that accurately reflect each of the release packages I see your point, and thanks for your changes in etc/notice/notices, that will help a lot. The nice thing (IMHO) about generating the notices from the Maven dependencies, is that this will expose any new dependencies that might have been added next time we do a release, without having to manually check our 55 notice files by hand. But I agree about refining the process with exceptions, I'll modify the mknotice script now, to ignore #comment lines. Ok, where are we now? :) I think we should make the final changes (as discussed recently here), recheck the notice files and then I can go ahead and make the release candidates. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
On Wed, Jun 4, 2008 at 9:35 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...I think we should make the final changes (as discussed recently here), recheck the notice files and then I can go ahead and make the release candidates... Yes, I'm cleaning up the NOTICE files based on Roy's latest changes, give me a few minutes...I'll close SLING-495 again when done. -Bertrand
Re: Sling Release
Ok, can I have a short ok from other committers that they think the notice files are ok now? I'll check them myself now and would like to start the build process afterwards. Thanks Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Hi, I was distracted with other work and could not yet post my NOTICE inspection results. Unfortunately, I have to say, that the NOTICE files are partly inaccurate and incomplete. I will post my findings (should they diverge from what Carsten has found) to the reponend SLING-495 issue. Regards Felix Am Mittwoch, den 04.06.2008, 14:36 +0200 schrieb Carsten Ziegeler: Ok, can I have a short ok from other committers that they think the notice files are ok now? I'll check them myself now and would like to start the build process afterwards. Thanks Carsten
Re: Sling Release
On Wed, Jun 4, 2008 at 3:00 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...Unfortunately, I have to say, that the NOTICE files are partly inaccurate and incomplete Make sure to look at the notice fragments under http://svn.apache.org/repos/asf/incubator/sling/trunk/etc/notice/notices/ if you think dependencies are missing from the NOTICEs. In revision 662927, Roy intently commented a lot of those files to prevent the corresponding notices from appearing, and in most cases indicate why he thinks that must be so. I think we all trust him to know what he's doing. -Bertrand
Re: Sling Release
If noone stops me I'll start to build the release candidates now Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
On Wed, Jun 4, 2008 at 4:12 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: If noone stops me I'll start to build the release candidates now RAT reports some missing licenses, see below. I'll fix the java files now (except commons/json which is ok, right?), please have a look at the rest, I think it's ok. -Bertrand !? ./commons/json/src/main/java/org/apache/sling/commons/json/JSONArray.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/JSONException.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/JSONObject.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/JSONString.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/JSONTokener.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/http/Cookie.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/http/CookieList.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/http/HTTP.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/http/HTTPTokener.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/io/JSONStringer.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/io/JSONWriter.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/util/CDL.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/xml/XML.java !? ./commons/json/src/main/java/org/apache/sling/commons/json/xml/XMLTokener.java !? ./commons/log/LICENSE.slf4j !? ./engine/src/main/resources/OSGI-INF/manual_serviceComponents.xml !? ./engine/src/main/resources/OSGI-INF/metatype/metatype.xml !? ./engine/src/main/resources/OSGI-INF/scr-plugin/scrinfo.xml !? ./etc/notice/mknotice !? ./etc/notice/noticemap.txt !? ./etc/notice/notices/asm.txt !? ./etc/notice/notices/bnd.txt !? ./etc/notice/notices/cglib.txt !? ./etc/notice/notices/codehaus.txt !? ./etc/notice/notices/concurrent.txt !? ./etc/notice/notices/equinox.txt !? ./etc/notice/notices/freemarker.txt !? ./etc/notice/notices/hamcrest.txt !? ./etc/notice/notices/jcr.txt !? ./etc/notice/notices/jetty.txt !? ./etc/notice/notices/jmock.txt !? ./etc/notice/notices/jruby-codehaus.txt !? ./etc/notice/notices/json.txt !? ./etc/notice/notices/junit.txt !? ./etc/notice/notices/kxml2.txt !? ./etc/notice/notices/mx4j.txt !? ./etc/notice/notices/nekohtml.txt !? ./etc/notice/notices/opensymphony.txt !? ./etc/notice/notices/osgi.txt !? ./etc/notice/notices/pax.txt !? ./etc/notice/notices/pdfbox.txt !? ./etc/notice/notices/prefix.txt !? ./etc/notice/notices/qdox.txt !? ./etc/notice/notices/rhino.txt !? ./etc/notice/notices/slf4j.txt !? ./etc/notice/notices/textmining.txt !? ./extensions/apt/servlet/src/main/java/org/apache/sling/apt/servlet/SlingAptServlet.java !? ./extensions/dojo/LICENSE_dojo !? ./extensions/dojo/src/main/dojo-override/dojo/_base/_loader/hostenv_rhino.js !? ./extensions/dojo-sling/src/main/resources/SLING-INF/content/dojox/data/demo/README-JCR.txt !? ./extensions/dojo-sling/src/main/resources/SLING-INF/content/dojox/data/demo/demo1.html !? ./extensions/dojo-sling/src/main/resources/SLING-INF/content/dojox/data/demo/demo2.html !? ./extensions/dojo-sling/src/main/resources/SLING-INF/content/dojox/data/demo/demo3.html !? ./jcr/api/LICENSE.jcr !? ./jcr/contentloader/LICENSE.kxml2 !? ./jcr/jackrabbit-client/src/main/resources/OSGI-INF/manual_serviceComponents.xml !? ./jcr/jackrabbit-client/src/main/resources/OSGI-INF/metatype/metatype.xml !? ./jcr/jackrabbit-server/src/main/resources/OSGI-INF/manual_serviceComponents.xml !? ./jcr/jackrabbit-server/src/main/resources/OSGI-INF/metatype/metatype.xml !? ./jcr/ocm/LICENSE.kxml2 !? ./launchpad/content/src/main/resources/content/ROOT.json !? ./launchpad/content/src/main/resources/content/index.html !? ./launchpad/content/src/main/resources/content/sling.css !? ./launchpad/webapp/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/ScriptBuiltinObjectsTest.java !? ./launchpad/webapp/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/package.html !? ./launchpad/webapp/src/test/resources/integration-test/builtin-objects.esp !? ./launchpad/webapp/src/test/resources/integration-test/dump-resource.ecma !? ./launchpad/webapp/src/test/resources/integration-test/include-forced.esp !? ./launchpad/webapp/src/test/resources/integration-test/include-test.esp !? ./launchpad/webapp/src/test/resources/integration-test/no-code.esp !? ./launchpad/webapp/src/test/resources/integration-test/post-test.esp !? ./launchpad/webapp/src/test/resources/integration-test/rendering-test-2.esp !?
Re: Sling Release
I'm finished with building the release artifacts. Please note that our current trunk is not buildable due to this. The artifacts reference the release versions which are not available in a public maven repository and the versions in our svn are set to the next snapshot. I'll correct this asap and start the vote. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
The depenencies are now all set to 2.0.1-incubator-SNAPSHOT. Once the release is out to the maven repos, we will revert this to 2.0.0-incubator where appropriate. Carsten Carsten Ziegeler wrote: I'm finished with building the release artifacts. Please note that our current trunk is not buildable due to this. The artifacts reference the release versions which are not available in a public maven repository and the versions in our svn are set to the next snapshot. I'll correct this asap and start the vote. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
On Jun 3, 2008, at 11:45 PM, Bertrand Delacretaz wrote: On Wed, Jun 4, 2008 at 12:35 AM, Roy T. Fielding [EMAIL PROTECTED] wrote: ...I'd rather have a set of hand-edited NOTICE files that accurately reflect each of the release packages I see your point, and thanks for your changes in etc/notice/notices, that will help a lot. The nice thing (IMHO) about generating the notices from the Maven dependencies, is that this will expose any new dependencies that might have been added next time we do a release, without having to manually check our 55 notice files by hand. But I agree about refining the process with exceptions, I'll modify the mknotice script now, to ignore #comment lines. But the NOTICE files are not for describing build dependencies. They exist to satisfy the copyright license of packaged distributions. If the notices aren't required by the bits in the package, then they don't belong in NOTICE. That means there will be a different NOTICE file required for each differently packaged set of bits. We must do this by hand. I think that tracking detailed dependencies and all of their licenses is very useful and necessary for helping us construct the subsets that need to be noted in LICENSE (the union of all licenses) and NOTICE (the union of a required notices) and README (everything else). Roy
Re: Sling Release
Roy T. Fielding wrote: But the NOTICE files are not for describing build dependencies. They exist to satisfy the copyright license of packaged distributions. If the notices aren't required by the bits in the package, then they don't belong in NOTICE. That means there will be a different NOTICE file required for each differently packaged set of bits. We must do this by hand. So this basically means that we only have to add something to the NOTICE file if the license of an included project requires this, right? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Bertrand Delacretaz wrote: I'm finishing up the NOTICE stuff, I suggest regenerating *all* NOTICE files with the mknotice script. Great! I'll modify the script to concatenate an optional local.notice.txt file, found in the same directory as the module's pom.xml, to the end of the NOTICE, for stuff like dojo which does not appear in the pom dependencies. Ok. I just ran into a blocker :( https://issues.apache.org/jira/browse/SLING-501 Sling does not work with the latest SCR implementations from Felix (1.0.1-SNAPSHOT). Unfortunately my own stuff requires the latest SCR and of course latest Sling...so I'm wondering if we could fix this issue in a way that Sling runs with the old SCR and the new one? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Hi, Am Dienstag, den 03.06.2008, 11:42 +0200 schrieb Carsten Ziegeler: Bertrand Delacretaz wrote: I'm finishing up the NOTICE stuff, I suggest regenerating *all* NOTICE files with the mknotice script. Great! I'll modify the script to concatenate an optional local.notice.txt file, found in the same directory as the module's pom.xml, to the end of the NOTICE, for stuff like dojo which does not appear in the pom dependencies. Ok. I just ran into a blocker :( https://issues.apache.org/jira/browse/SLING-501 Sling does not work with the latest SCR implementations from Felix (1.0.1-SNAPSHOT). Unfortunately my own stuff requires the latest SCR and of course latest Sling...so I'm wondering if we could fix this issue in a way that Sling runs with the old SCR and the new one? Actually, it would run ;-) The problem is the maven-scr-plugin which always sets the immediate attribute to true (if not explicitly) set. This is incorrect in connection with using the factory attribute (the same happens for the jcr/jackrabbit-server and jcr/jackrabbit-client bundles). The real fix is to use the latest maven-scr-plugin which does NOT set the attribute and then it should run. Regards Felix
Re: Sling Release
Felix Meschberger wrote: Actually, it would run ;-) The problem is the maven-scr-plugin which always sets the immediate attribute to true (if not explicitly) set. This is incorrect in connection with using the factory attribute (the same happens for the jcr/jackrabbit-server and jcr/jackrabbit-client bundles). The real fix is to use the latest maven-scr-plugin which does NOT set the attribute and then it should run. Yes, it might run with scr snapshot, but it doesn't run with scr 1.0.0 then :( As we definitly don't want to wait until scr and the scr plugin is released, what about not using the scr plugin for the logger but hand writing the xml file? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Hi, Am Dienstag, den 03.06.2008, 11:58 +0200 schrieb Carsten Ziegeler: Felix Meschberger wrote: Actually, it would run ;-) The problem is the maven-scr-plugin which always sets the immediate attribute to true (if not explicitly) set. This is incorrect in connection with using the factory attribute (the same happens for the jcr/jackrabbit-server and jcr/jackrabbit-client bundles). The real fix is to use the latest maven-scr-plugin which does NOT set the attribute and then it should run. Yes, it might run with scr snapshot, but it doesn't run with scr 1.0.0 then :( As we definitly don't want to wait until scr and the scr plugin is released, what about not using the scr plugin for the logger but hand writing the xml file? It _will_ run with the scr 1.0.0 snapshot, unless the immediate flag is set, which is the real bug behind this. If the immediate flag is not explicitly set to any value, both versions of SCR -- 1.0.0 and 1.0.1-SNAPSHOT -- assume their own default value valid in their context. And hence the bundle works. The real culprit, if you wish, is the maven-scr-plugin, which always sets this flag to an explict true value, thus prevent the bundle to work. We might need a maven-scr-plugin release ?? Regards Felix
Re: Sling Release
Felix Meschberger wrote: It _will_ run with the scr 1.0.0 snapshot, unless the immediate flag is set, which is the real bug behind this. If the immediate flag is not explicitly set to any value, both versions of SCR -- 1.0.0 and 1.0.1-SNAPSHOT -- assume their own default value valid in their context. And hence the bundle works. Yes, that's my understanding as well :) The real culprit, if you wish, is the maven-scr-plugin, which always sets this flag to an explict true value, thus prevent the bundle to work. We might need a maven-scr-plugin release ?? Yes, but we don't want to wait for that I guess/hope :) therefore why not hand writing the scr config without the explicit flag just for the release? The alternative would be to release the scr plugin (and we could then also release the scr to get the latest version), but this would require us to delay the release until next week. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Hi, scanning our project reveals the following component factories: jcr/jackrabbit-server : SlingServerRepository jcr/jackrabbit-client : SlingClientRepository jcr/classloader : RepositoryClassLoaderProviderImpl engine: RequestLoggerService I created SLING-502 to change them to manual descriptors and SLING-503 to revert to automatic descriptors after any maven-scr-plugin release. Regards Felix Am Dienstag, den 03.06.2008, 12:17 +0200 schrieb Felix Meschberger: Hi, Am Dienstag, den 03.06.2008, 12:07 +0200 schrieb Carsten Ziegeler: Felix Meschberger wrote: It _will_ run with the scr 1.0.0 snapshot, unless the immediate flag is set, which is the real bug behind this. If the immediate flag is not explicitly set to any value, both versions of SCR -- 1.0.0 and 1.0.1-SNAPSHOT -- assume their own default value valid in their context. And hence the bundle works. Yes, that's my understanding as well :) The real culprit, if you wish, is the maven-scr-plugin, which always sets this flag to an explict true value, thus prevent the bundle to work. We might need a maven-scr-plugin release ?? Yes, but we don't want to wait for that I guess/hope :) therefore why not hand writing the scr config without the explicit flag just for the release? The alternative would be to release the scr plugin (and we could then also release the scr to get the latest version), but this would require us to delay the release until next week. After considering this, I agree, that handwriting is probably the best for the moment being. Regards Felix Carsten
Re: Sling Release
Hi, Am Dienstag, den 03.06.2008, 12:07 +0200 schrieb Carsten Ziegeler: Felix Meschberger wrote: It _will_ run with the scr 1.0.0 snapshot, unless the immediate flag is set, which is the real bug behind this. If the immediate flag is not explicitly set to any value, both versions of SCR -- 1.0.0 and 1.0.1-SNAPSHOT -- assume their own default value valid in their context. And hence the bundle works. Yes, that's my understanding as well :) The real culprit, if you wish, is the maven-scr-plugin, which always sets this flag to an explict true value, thus prevent the bundle to work. We might need a maven-scr-plugin release ?? Yes, but we don't want to wait for that I guess/hope :) therefore why not hand writing the scr config without the explicit flag just for the release? The alternative would be to release the scr plugin (and we could then also release the scr to get the latest version), but this would require us to delay the release until next week. After considering this, I agree, that handwriting is probably the best for the moment being. Regards Felix Carsten
Re: Sling Release
Hi, I fixed SLING-502 so, this blocker is removed, I hope. I also closed SLING-501 as duplicate of SLING-502. In addition I descheduled SLING-421 (Update Servlet Resolution Description) from the 2.0 release. Remains the notices case ... Are we on track ? ;-) Regards Felix Am Dienstag, den 03.06.2008, 12:40 +0200 schrieb Felix Meschberger: Hi, scanning our project reveals the following component factories: jcr/jackrabbit-server : SlingServerRepository jcr/jackrabbit-client : SlingClientRepository jcr/classloader : RepositoryClassLoaderProviderImpl engine: RequestLoggerService I created SLING-502 to change them to manual descriptors and SLING-503 to revert to automatic descriptors after any maven-scr-plugin release. Regards Felix Am Dienstag, den 03.06.2008, 12:17 +0200 schrieb Felix Meschberger: Hi, Am Dienstag, den 03.06.2008, 12:07 +0200 schrieb Carsten Ziegeler: Felix Meschberger wrote: It _will_ run with the scr 1.0.0 snapshot, unless the immediate flag is set, which is the real bug behind this. If the immediate flag is not explicitly set to any value, both versions of SCR -- 1.0.0 and 1.0.1-SNAPSHOT -- assume their own default value valid in their context. And hence the bundle works. Yes, that's my understanding as well :) The real culprit, if you wish, is the maven-scr-plugin, which always sets this flag to an explict true value, thus prevent the bundle to work. We might need a maven-scr-plugin release ?? Yes, but we don't want to wait for that I guess/hope :) therefore why not hand writing the scr config without the explicit flag just for the release? The alternative would be to release the scr plugin (and we could then also release the scr to get the latest version), but this would require us to delay the release until next week. After considering this, I agree, that handwriting is probably the best for the moment being. Regards Felix Carsten
Re: Sling Release
Felix Meschberger wrote: Hi, Am Dienstag, den 03.06.2008, 11:13 +0200 schrieb Carsten Ziegeler: I created a profile in our reactor pom with the modules we don't want to include in our first release. I'm not sure if this list is complete/correct, so please cross check. I think we should try to build the release today, so what else needs to be done? Apart from the NOTICE stuff, I would say we are ready for rock'n'roll, right ? Yes, I think so - I just tested your changes regarding the factory stuff (SLING-502) and they work like expected. Great. Thanks! Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
On Tue, Jun 3, 2008 at 1:52 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: ...I'm generating the NOTICEs as we speak, ETA 30 minutes... Done (took 34 minutes, sorry ;-) Generating those NOTICEs and digging out the info for all the notice fragments in etc/notice/notices/ was *much* more painful than I expected, but at least we have now a traceable and (mostly) automated way of updating them for future releases. I have added a few module.txt.files where needed to complete what the script generates, see notes in SLING-493. Feel review to review and update as needed, but the idea is not to edit NOTICE directly. -Bertrand
Re: Sling Release
On Tue, Jun 3, 2008 at 2:41 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...I just looked at the NOTICE file in the engine and see that it includes references to SLF4J and jcp.org. Interestingly neither is included in the engine Both of these have scope=provided, and right now the mknotice script takes as input the output of mvn dependency:resolve, grepped to remove scope=test. In theory we could exclude the provided stuff from the NOTICE, as we do not redistribute it in this module. But the dependencies having scope=provided are also sometimes included in the generated bundles, by way of the private-package maven-bundle-plugin statement, right? If we can change that (and enforce it, for example by the maven-bundle-plugin refusing to include dependencies with scope=provided, and/or inventing a new scope for that) we could ignore provided dependencies in the mknotice script. For now, I'd suggest leaving things as is (unless I'm wrong about our use of provided). As you indicate that means including too much stuff in the NOTICE files sometimes, which is probably better than too little, at least for this first release. -Bertrand
Re: Sling Release
Hi, Am Dienstag, den 03.06.2008, 15:01 +0200 schrieb Bertrand Delacretaz: On Tue, Jun 3, 2008 at 2:41 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...I just looked at the NOTICE file in the engine and see that it includes references to SLF4J and jcp.org. Interestingly neither is included in the engine Both of these have scope=provided, and right now the mknotice script takes as input the output of mvn dependency:resolve, grepped to remove scope=test. In theory we could exclude the provided stuff from the NOTICE, as we do not redistribute it in this module. But the dependencies having scope=provided are also sometimes included in the generated bundles, by way of the private-package maven-bundle-plugin statement, right? Yes, this is in fact a problem. One solution I could see is, that we mark all dependencies, which are included in a bundle as optional. This is done for the launchpad/app module to not include all dependencies and transitives into a project's dependency list when adding app as a dependency. Like that we could depend on the optionality setting for adding the notice line. Not sure, whether this actually already works. If we can change that (and enforce it, for example by the maven-bundle-plugin refusing to include dependencies with scope=provided, and/or inventing a new scope for that) we could ignore provided dependencies in the mknotice script. For now, I'd suggest leaving things as is (unless I'm wrong about our use of provided). As you indicate that means including too much stuff in the NOTICE files sometimes, which is probably better than too little, at least for this first release. Agreed. Let's go with what we have. Regards Felix
Re: Sling Release
Hi, Am Dienstag, den 03.06.2008, 14:32 +0200 schrieb Bertrand Delacretaz: On Tue, Jun 3, 2008 at 1:52 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: ...I'm generating the NOTICEs as we speak, ETA 30 minutes... Done (took 34 minutes, sorry ;-) Generating those NOTICEs and digging out the info for all the notice fragments in etc/notice/notices/ was *much* more painful than I expected, but at least we have now a traceable and (mostly) automated way of updating them for future releases. I have added a few module.txt.files where needed to complete what the script generates, see notes in SLING-493. Great thing ! Feel review to review and update as needed, but the idea is not to edit NOTICE directly. I just looked at the NOTICE file in the engine and see that it includes references to SLF4J and jcp.org. Interestingly neither is included in the engine. Is this an artifact of the generation by dependencies ? Furthermore, I assume it is not problematic to have more stuff in the NOTICE file(s) than is really required. Regards Felix
Re: Sling Release
Hi, Am Dienstag, den 03.06.2008, 15:29 +0200 schrieb Carsten Ziegeler: Bertrand Delacretaz wrote: On Tue, Jun 3, 2008 at 3:07 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...One solution I could see is, that we mark all dependencies, which are included in a bundle as optional. This is done for the launchpad/app module to not include all dependencies and transitives into a project's dependency list when adding app as a dependency Created SLING-504 for that. Sorry, but I think we are abusing the maven dependency mechanism here a little bit. If this deps are included in the bundle they are not optional. So marking them optional just to get a correct notice file seems to be wrong. Kind of agreeing here. OTOH we mark them optional to not taint the transitive dependency system with unneeded dependencies. We might make use of this fact when building the notice files. Regards Felix
Re: Sling Release
Felix Meschberger wrote: Hi, Am Dienstag, den 03.06.2008, 15:29 +0200 schrieb Carsten Ziegeler: Bertrand Delacretaz wrote: On Tue, Jun 3, 2008 at 3:07 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...One solution I could see is, that we mark all dependencies, which are included in a bundle as optional. This is done for the launchpad/app module to not include all dependencies and transitives into a project's dependency list when adding app as a dependency Created SLING-504 for that. Sorry, but I think we are abusing the maven dependency mechanism here a little bit. If this deps are included in the bundle they are not optional. So marking them optional just to get a correct notice file seems to be wrong. Kind of agreeing here. OTOH we mark them optional to not taint the transitive dependency system with unneeded dependencies. We might make use of this fact when building the notice files. :) tricky... Btw, anyone against changing the repository pinger (see SLING-505) and remove the debug logs for the release? I'm currently trying to debug something with log level set to debug and the log is growing like mad. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
On Tue, Jun 3, 2008 at 3:29 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 3:07 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...One solution I could see is, that we mark all dependencies, which are included in a bundle as optional Sorry, but I think we are abusing the maven dependency mechanism here a little bit. If this deps are included in the bundle they are not optional. So marking them optional just to get a correct notice file seems to be wrong... I agree, but aren't we abusing it already? We are marking dependencies as provided, but including them in the generated artifact using the maven-bundle-plugin. The correct scope (although it does not exist, and IIRC you said custom scopes pose problems) might be bundled in this case, and the maven-bundle-plugin would then complain if trying to include the code of any package in the bundle code, unless that package comes from a bundled dependency, or comes from the project itself. -Bertrand
Re: Sling Release
On Tue, Jun 3, 2008 at 3:07 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...One solution I could see is, that we mark all dependencies, which are included in a bundle as optional. This is done for the launchpad/app module to not include all dependencies and transitives into a project's dependency list when adding app as a dependency Created SLING-504 for that. -Bertrand
Re: Sling Release
Bertrand Delacretaz wrote: On Tue, Jun 3, 2008 at 3:07 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...One solution I could see is, that we mark all dependencies, which are included in a bundle as optional. This is done for the launchpad/app module to not include all dependencies and transitives into a project's dependency list when adding app as a dependency Created SLING-504 for that. Sorry, but I think we are abusing the maven dependency mechanism here a little bit. If this deps are included in the bundle they are not optional. So marking them optional just to get a correct notice file seems to be wrong. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: RepositoryPinger (was: Sling Release)
On Tue, Jun 3, 2008 at 3:47 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Am Dienstag, den 03.06.2008, 15:41 +0200 schrieb Bertrand Delacretaz: ...that the pinger pings way too often currently, I'll create an issue for that unless there's one already. Couldn't this be handled in the same issue 505 ? Hijacking issues ;-) Sure, feel free to merge 506 and 505. -Bertrand
Re: Sling Release
Hi, Am Dienstag, den 03.06.2008, 15:57 +0200 schrieb Carsten Ziegeler: Bertrand Delacretaz wrote: I agree, but aren't we abusing it already? We are marking dependencies as provided, but including them in the generated artifact using the maven-bundle-plugin. The correct scope (although it does not exist, and IIRC you said custom scopes pose problems) might be bundled in this case, and the maven-bundle-plugin would then complain if trying to include the code of any package in the bundle code, unless that package comes from a bundled dependency, or comes from the project itself. Usually I use the scope compile when including bundles :) which is closer as optional and provided to what we do...not optimal though. The problem with compile is that it creates hard transitive dependencies, which is not what you want when including library code into the bundle. Regards Felix
RepositoryPinger (was: Sling Release)
Am Dienstag, den 03.06.2008, 15:41 +0200 schrieb Bertrand Delacretaz: On Tue, Jun 3, 2008 at 3:39 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...Btw, anyone against changing the repository pinger (see SLING-505) and remove the debug logs for the release? I'm currently trying to debug something with log level set to debug and the log is growing like mad... Hijacking threads hey? ;-) No problem with that, and that reminds me that the pinger pings way too often currently, I'll create an issue for that unless there's one already. Couldn't this be handled in the same issue 505 ? Hijacking issues ;-) Regards Felix
Re: Sling Release
Bertrand Delacretaz wrote: I agree, but aren't we abusing it already? We are marking dependencies as provided, but including them in the generated artifact using the maven-bundle-plugin. The correct scope (although it does not exist, and IIRC you said custom scopes pose problems) might be bundled in this case, and the maven-bundle-plugin would then complain if trying to include the code of any package in the bundle code, unless that package comes from a bundled dependency, or comes from the project itself. Usually I use the scope compile when including bundles :) which is closer as optional and provided to what we do...not optimal though. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
On Tue, Jun 3, 2008 at 3:39 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: ...Btw, anyone against changing the repository pinger (see SLING-505) and remove the debug logs for the release? I'm currently trying to debug something with log level set to debug and the log is growing like mad... Hijacking threads hey? ;-) No problem with that, and that reminds me that the pinger pings way too often currently, I'll create an issue for that unless there's one already. -Bertrand
Re: Sling Release
Hi, On Tue, Jun 3, 2008 at 5:20 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Am Dienstag, den 03.06.2008, 17:14 +0300 schrieb Jukka Zitting: I'm trying to understand the issue, do you have an example of a case where this would be troublesome? It is not directly troublesome, more like annoying - and sometimes really confusing. I cannot rememeber exactly what problems compile type dependencies pose, but at one time I had log4j dependencies which just blew out because the defined compile type dependencies too generously. Yeah, there are quite a few cases where libraries are too eager to bring in optional libraries as hard dependencies. A good example is the recent log4j 1.2.15, see http://yoavs.blogspot.com/2008/05/caution-log4j-1215-brings-in-bunch-of.html. Anyway, if your component depends for example on log4j 1.2.15, it's much better to explicitly exclude such transitive dependencies than to mark the entire log4j dependency as optional and then work around that in the bundle packaging. BR, Jukka Zitting
Re: Sling Release
2008/6/3 Carsten Ziegeler [EMAIL PROTECTED]: Ok, can we release? +1 on creating the release artifacts. Releasing requires a vote IIRC ;-) -Bertrand
Re: Sling Release
Hi, Am Dienstag, den 03.06.2008, 17:14 +0300 schrieb Jukka Zitting: Hi, On Tue, Jun 3, 2008 at 5:00 PM, Felix Meschberger [EMAIL PROTECTED] wrote: The problem with compile is that it creates hard transitive dependencies, which is not what you want when including library code into the bundle. I'm trying to understand the issue, do you have an example of a case where this would be troublesome? It is not directly troublesome, more like annoying - and sometimes really confusing. I cannot rememeber exactly what problems compile type dependencies pose, but at one time I had log4j dependencies which just blew out because the defined compile type dependencies too generously. Regards Felix
Re: Sling Release
Ok, can we release? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Yes, please ;-) Regards Felix Am Dienstag, den 03.06.2008, 16:47 +0200 schrieb Carsten Ziegeler: Ok, can we release? Carsten
Re: Sling Release
Hi, Am Dienstag, den 03.06.2008, 17:31 +0300 schrieb Jukka Zitting: Hi, On Tue, Jun 3, 2008 at 5:20 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Am Dienstag, den 03.06.2008, 17:14 +0300 schrieb Jukka Zitting: I'm trying to understand the issue, do you have an example of a case where this would be troublesome? It is not directly troublesome, more like annoying - and sometimes really confusing. I cannot rememeber exactly what problems compile type dependencies pose, but at one time I had log4j dependencies which just blew out because the defined compile type dependencies too generously. Yeah, there are quite a few cases where libraries are too eager to bring in optional libraries as hard dependencies. A good example is the recent log4j 1.2.15, see http://yoavs.blogspot.com/2008/05/caution-log4j-1215-brings-in-bunch-of.html. Anyway, if your component depends for example on log4j 1.2.15, it's much better to explicitly exclude such transitive dependencies than to mark the entire log4j dependency as optional and then work around that in the bundle packaging. Right. But if I include the code into the bundle as and internal implementation detail (which would be the case for log4j would I include it in the osgi/log bundle for example), I would mark the dependency as optional, because it is noone's business what the bundle internally uses and hence the dependency is neither anybobdy's business. Regards Felix
Dependency scopes (Was: Sling Release)
Hi, On Tue, Jun 3, 2008 at 5:37 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Am Dienstag, den 03.06.2008, 17:31 +0300 schrieb Jukka Zitting: Anyway, if your component depends for example on log4j 1.2.15, it's much better to explicitly exclude such transitive dependencies than to mark the entire log4j dependency as optional and then work around that in the bundle packaging. Right. But if I include the code into the bundle as and internal implementation detail (which would be the case for log4j would I include it in the osgi/log bundle for example), I would mark the dependency as optional, because it is noone's business what the bundle internally uses and hence the dependency is neither anybobdy's business. The dependency is certainly Maven's business and, as discussed, also the business of any plugins or other tools that traverse the dependency tree. By marking the dependency as optional you're making things more complicated for those tools. What's the downside of not marking the dependency as optional? I.e. who's the someone who shouldn't know about the dependency? BR, Jukka Zitting
Re: Sling Release
On Jun 3, 2008, at 5:41 AM, Felix Meschberger wrote: Am Dienstag, den 03.06.2008, 14:32 +0200 schrieb Bertrand Delacretaz: On Tue, Jun 3, 2008 at 1:52 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: ...I'm generating the NOTICEs as we speak, ETA 30 minutes... Done (took 34 minutes, sorry ;-) Generating those NOTICEs and digging out the info for all the notice fragments in etc/notice/notices/ was *much* more painful than I expected, but at least we have now a traceable and (mostly) automated way of updating them for future releases. I have added a few module.txt.files where needed to complete what the script generates, see notes in SLING-493. Great thing ! I'd rather have a set of hand-edited NOTICE files that accurately reflect each of the release packages. What is going to be in the release? NOTICE is not for describing the license of each artifact. It is only for required attributions. Feel review to review and update as needed, but the idea is not to edit NOTICE directly. I just looked at the NOTICE file in the engine and see that it includes references to SLF4J and jcp.org. Interestingly neither is included in the engine. Is this an artifact of the generation by dependencies ? Furthermore, I assume it is not problematic to have more stuff in the NOTICE file(s) than is really required. Yes, it is problematic. Consider it a tax on all downstream recipients. Roy
Re: Sling Release
Hi, Am Montag, den 02.06.2008, 10:36 +0200 schrieb Bertrand Delacretaz: On Fri, May 30, 2008 at 2:40 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...The final question is, what = which parts we want to release? ... I would say: api, engine, jcr (api, base, classloader, contentloader, jackrabbit-*, ocm, resource, webdav), launchpad/*, event, i18n, httpauth, servlets/*, commons/*, adapter, bundleresource, scripting (api, core, javascript, jsp, jsp.taglib). The launchpad/app jar file and the launchpad/webapp war file include binary copies of their dependencies, which means we are redistributing said dependencies once we release those modules. I think we must update the NOTICE files of the launchpad/app and webapp modules to mention all non-Apache dependencies, as listed by mvn dependency:resolve. WDYT? I agree Can we automate this ? Regards Felix
Re: Sling Release
Am Montag, den 02.06.2008, 10:41 +0200 schrieb Bertrand Delacretaz: On Fri, May 30, 2008 at 2:40 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...The final question is, what = which parts we want to release? ... ...I would say: api, engine, jcr (api, base, classloader, contentloader, jackrabbit-*, ocm, resource, webdav), launchpad/*, event, i18n, httpauth, servlets/*, commons/*, adapter, bundleresource, scripting (api, core, javascript, jsp, jsp.taglib) Why not the Maven plugins? I think at least maven-sling-plugin should be released. Because I forgot to list them ;-) Of course they should be released The parent POM must also be released, right (obvious I guess)? Correct. And could we include the samples/webloader module? It's a good example, even if limited, of how to combine java code with scripting. I'd test it before the release. ok. Regards Felix
Re: Sling Release
Bertrand Delacretaz wrote: On Mon, Jun 2, 2008 at 10:38 AM, Felix Meschberger [EMAIL PROTECTED] wrote: ...Am Montag, den 02.06.2008, 10:36 +0200 schrieb Bertrand Delacretaz: ... I think we must update the NOTICE files of the launchpad/app and webapp modules to mention all non-Apache dependencies, as listed by mvn dependency:resolve. I agree Can we automate this ? IIRC, Wicket has a way of combining multiple NOTICE files using Maven, I'll have a look at that... Afaik this is done by the maven remote resources plugin. I looked at it some months ago and I though that it's a mess :) It is able to collect the information from the dependencies, but this is of course based on the information from the various poms - and these are never really correct or complete. So it's possible to override this stuff and you end up maintaining the info just to use the plugin anyway. As dependencies do not change that often, I would prefer doing it by hand. Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
On Mon, Jun 2, 2008 at 10:38 AM, Felix Meschberger [EMAIL PROTECTED] wrote: ...Am Montag, den 02.06.2008, 10:36 +0200 schrieb Bertrand Delacretaz: ... I think we must update the NOTICE files of the launchpad/app and webapp modules to mention all non-Apache dependencies, as listed by mvn dependency:resolve. I agree Can we automate this ? IIRC, Wicket has a way of combining multiple NOTICE files using Maven, I'll have a look at that... -Bertrand
Re: Sling Release
Hi, Am Montag, den 02.06.2008, 10:43 +0200 schrieb Bertrand Delacretaz: On Mon, Jun 2, 2008 at 10:38 AM, Felix Meschberger [EMAIL PROTECTED] wrote: ...Am Montag, den 02.06.2008, 10:36 +0200 schrieb Bertrand Delacretaz: ... I think we must update the NOTICE files of the launchpad/app and webapp modules to mention all non-Apache dependencies, as listed by mvn dependency:resolve. I agree Can we automate this ? IIRC, Wicket has a way of combining multiple NOTICE files using Maven, I'll have a look at that... Cool. Thanks. Regards Felix
Re: Sling Release
On Fri, May 30, 2008 at 2:40 PM, Felix Meschberger [EMAIL PROTECTED] wrote: ...The final question is, what = which parts we want to release? ... ...I would say: api, engine, jcr (api, base, classloader, contentloader, jackrabbit-*, ocm, resource, webdav), launchpad/*, event, i18n, httpauth, servlets/*, commons/*, adapter, bundleresource, scripting (api, core, javascript, jsp, jsp.taglib) Why not the Maven plugins? I think at least maven-sling-plugin should be released. The parent POM must also be released, right (obvious I guess)? And could we include the samples/webloader module? It's a good example, even if limited, of how to combine java code with scripting. I'd test it before the release. -Bertrand
Re: Sling Release
Bertrand Delacretaz wrote: On Mon, Jun 2, 2008 at 11:15 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Bertrand Delacretaz wrote: ...IIRC, Wicket has a way of combining multiple NOTICE files using Maven, I'll have a look at that... Afaik this is done by the maven remote resources plugin. I looked at it some months ago and I though that it's a mess :)... Ok, and what it does IIUC is concatenating NOTICE files from subprojects in the top-level NOTICE, that's not really what we need. I'm working on a shell script to generate those files semi-automatically from mvn dependency:resolve output, stay tuned... Great, please note that we only need this for the launchpad stuff; the other modules should be ok as I checked them some time ago manually :) Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Sling Release
Ten..nine... ...five... ...two...one There's one single issue for a 2.0.0 release in Jira (and it's about docs), so it really seems that we can release next week. :) So I think it's time to ask if there are any outstanding issues? Something we are currently not aware of? The final question is, what = which parts we want to release? I think there are some bundles/modules which we don't need to include in a first cut. WDYT? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
About docs. I would prefer to have a nice documentation before releasing. Including: - Quickstart Tutorials - a few Sample Apps (with well documented code and functional description) - documentation of architecture (basic concepts) - documentation of maven usage - documentation of sling taglib (for jsp - as well as equal technical aspects for other resources) Even if I yet just did some simple tests and studied the sling code to figure out required changes and possiblities when changing from CQ4.2 to CQ5 I could try to create some simple tutorials. I'd propably need someone else to help me set up usefull sampleapps. So, all in all IMHO it would be time for a code freeze to get everyones attention to documentation issues (I really had some frustrating moments because of the lack of documentation) Best regards, Dominik On Fri, May 30, 2008 at 11:44 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Ten..nine... ...five... ...two...one There's one single issue for a 2.0.0 release in Jira (and it's about docs), so it really seems that we can release next week. :) So I think it's time to ask if there are any outstanding issues? Something we are currently not aware of? The final question is, what = which parts we want to release? I think there are some bundles/modules which we don't need to include in a first cut. WDYT? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
On 5/30/08, Carsten Ziegeler [EMAIL PROTECTED] wrote: Ten..nine... ...five... ...two...one There's one single issue for a 2.0.0 release in Jira (and it's about docs), so it really seems that we can release next week. :) and this one: https://issues.apache.org/jira/browse/SLING-491 ? So I think it's time to ask if there are any outstanding issues? Something we are currently not aware of? The final question is, what = which parts we want to release? I think there are some bundles/modules which we don't need to include in a first cut. WDYT? Carsten -- Carsten Ziegeler [EMAIL PROTECTED]
Re: Sling Release
Hi Congrats to the whole Sling team on such a great job! On Fri, May 30, 2008 at 12:52 PM, Dominik Süß [EMAIL PROTECTED] wrote: About docs. I would prefer to have a nice documentation before releasing. Including: - Quickstart Tutorials - a few Sample Apps (with well documented code and functional description) - documentation of architecture (basic concepts) - documentation of maven usage - documentation of sling taglib (for jsp - as well as equal technical aspects for other resources) I think that's right on, that's what Sling needs right now a.s.a.p. I wouldn't, however, block the release of Sling because of lack of docu. Having a released (fixed, maintained) API is of highest priority for projects using sling. So release then follow up with docu is my proposal here. Cheers Greg -- -- Greg Klebus | http://day.com | http://dev.day.com -- Best open-source JCR repository: http://jacrkabbit.apache.org -- ** Day JCR Cup 08** | Win a MacBook Pro: http://dev.day.com
Re: Sling Release
The point is not to inform newsplattforms, but the users. While news plattforms only need information about the basic ideas of Sling, the consumers, which will hopefully will be some new developers, need instructions on how to use Sling. I recently checked out apache wicket and they've done a pretty nice work on documentation and examples. You get an idea of how to setup a new project within minutes (sorry but I do not like the discover-sling-in-15-minutes Tutorial). Michael Marth did a good job at his screencasts, but screencasts most times are problembased, not giving the author the possibility to reference other documents or describing complex technical things like resourceresolution. The other problem is - his texts and screencasts are not content of the sling pape where I would anticipate this information. While I do not have the time right now I would really like to define (or at least help to define) a basic but obligatory set of documents for the final 2.0.0 release. Regards, Dominik On Fri, May 30, 2008 at 2:12 PM, Joseph Ottinger [EMAIL PROTECTED] wrote: Of course, now the news platforms - at least one of them - are aware of the release, but hey. :) On Fri, May 30, 2008 at 8:10 AM, Dominik Süß [EMAIL PROTECTED] wrote: I think it wouldn't be good for the image of the product to release and have news all around in the IT-World without having at least a basic documentation which is up to date. I'd prefer to do a code freeze, build a release candidate and build the documentation within some days. Then it would be the right time to release and inform all the news plattforms out there about this milestone in CMS-development ;). I think it would be good to think of a release like a product. I'd never release a product without a manual. It should not be the goal to fullfill a roadmap concentrating on releasedates, it should be the goal to fullfill all requirements of a release (which IMHO includes documentation). Best regards, Dominik On Fri, May 30, 2008 at 1:58 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Hi, Am Freitag, den 30.05.2008, 13:34 +0200 schrieb Tobias Bocanegra: On 5/30/08, Carsten Ziegeler [EMAIL PROTECTED] wrote: Ten..nine... ...five... ...two...one There's one single issue for a 2.0.0 release in Jira (and it's about docs), so it really seems that we can release next week. :) and this one: https://issues.apache.org/jira/browse/SLING-491 ? I just posted a workaround (you certainly know) to the issue. I think this issue is certainly not a release blocker as it may easily - if so decided - be added in a maintenance version of the JSP tag lib bundle. Regards Felix So I think it's time to ask if there are any outstanding issues? Something we are currently not aware of? The final question is, what = which parts we want to release? I think there are some bundles/modules which we don't need to include in a first cut. WDYT? Carsten -- Carsten Ziegeler [EMAIL PROTECTED] -- Joseph B. Ottinger http://enigmastation.com Editor, http://www.TheServerSide.com
Re: Sling Release
I know. My point was that at least one of the news platforms pays a lot of attention to Sling as it is, and as such, an announcement on sling-dev is the same as telling the news platform that Sling's on it's way. On Fri, May 30, 2008 at 8:37 AM, Dominik Süß [EMAIL PROTECTED] wrote: The point is not to inform newsplattforms, but the users. While news plattforms only need information about the basic ideas of Sling, the consumers, which will hopefully will be some new developers, need instructions on how to use Sling. I recently checked out apache wicket and they've done a pretty nice work on documentation and examples. You get an idea of how to setup a new project within minutes (sorry but I do not like the discover-sling-in-15-minutes Tutorial). Michael Marth did a good job at his screencasts, but screencasts most times are problembased, not giving the author the possibility to reference other documents or describing complex technical things like resourceresolution. The other problem is - his texts and screencasts are not content of the sling pape where I would anticipate this information. While I do not have the time right now I would really like to define (or at least help to define) a basic but obligatory set of documents for the final 2.0.0 release. Regards, Dominik On Fri, May 30, 2008 at 2:12 PM, Joseph Ottinger [EMAIL PROTECTED] wrote: Of course, now the news platforms - at least one of them - are aware of the release, but hey. :) On Fri, May 30, 2008 at 8:10 AM, Dominik Süß [EMAIL PROTECTED] wrote: I think it wouldn't be good for the image of the product to release and have news all around in the IT-World without having at least a basic documentation which is up to date. I'd prefer to do a code freeze, build a release candidate and build the documentation within some days. Then it would be the right time to release and inform all the news plattforms out there about this milestone in CMS-development ;). I think it would be good to think of a release like a product. I'd never release a product without a manual. It should not be the goal to fullfill a roadmap concentrating on releasedates, it should be the goal to fullfill all requirements of a release (which IMHO includes documentation). Best regards, Dominik On Fri, May 30, 2008 at 1:58 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Hi, Am Freitag, den 30.05.2008, 13:34 +0200 schrieb Tobias Bocanegra: On 5/30/08, Carsten Ziegeler [EMAIL PROTECTED] wrote: Ten..nine... ...five... ...two...one There's one single issue for a 2.0.0 release in Jira (and it's about docs), so it really seems that we can release next week. :) and this one: https://issues.apache.org/jira/browse/SLING-491 ? I just posted a workaround (you certainly know) to the issue. I think this issue is certainly not a release blocker as it may easily - if so decided - be added in a maintenance version of the JSP tag lib bundle. Regards Felix So I think it's time to ask if there are any outstanding issues? Something we are currently not aware of? The final question is, what = which parts we want to release? I think there are some bundles/modules which we don't need to include in a first cut. WDYT? Carsten -- Carsten Ziegeler [EMAIL PROTECTED] -- Joseph B. Ottinger http://enigmastation.com Editor, http://www.TheServerSide.com -- Joseph B. Ottinger http://enigmastation.com Engineer, http://gigaspaces.co
Re: Sling Release
Hi, Am Freitag, den 30.05.2008, 11:44 +0200 schrieb Carsten Ziegeler: Ten..nine... ...five... ...two...one There's one single issue for a 2.0.0 release in Jira (and it's about docs), so it really seems that we can release next week. :) We can IMHO deschedule this documentation issue from the 2.0 release and start cutting the release on monday. If I find time over the weekend to fix this issue, all the better. But I don't think it is a blocker. So I think it's time to ask if there are any outstanding issues? https://issues.apache.org/jira/browse/SLING-485 (Replace our JSON derivate with the original). But I think this has been resolved to not implement due to the property order issue in the JSONObject. I will therefore close SLING-485 as won't fix. Something we are currently not aware of? I don't have nothing The final question is, what = which parts we want to release? I think there are some bundles/modules which we don't need to include in a first cut. I would say: api, engine, jcr (api, base, classloader, contentloader, jackrabbit-*, ocm, resource, webdav), launchpad/*, event, i18n, httpauth, servlets/*, commons/*, adapter, bundleresource, scripting (api, core, javascript, jsp, jsp.taglib). I think, that's about it. We should split the currently module list in the root pom.xml into two groups: modules we intent to release and a profile with optional modules we do not release (yet). Regards Felis WDYT? Carsten
Re: Sling Release
On Fri, May 30, 2008 at 2:37 PM, Dominik Süß [EMAIL PROTECTED] wrote: ...While I do not have the time right now I would really like to define (or at least help to define) a basic but obligatory set of documents for the final 2.0.0 release Although the version number is 2.0.0 (or whatever that is), what we're talking about for next week is in no way a final release, I think that's where our viewpoints differ: we're definitely shooting for a release early, release often way of working here. So while I agree that docs are required for a final release, we're more talking about an initial release ;-) -Bertrand
Re: Sling Release
So why is it defined as major release(just looking at the version number) without being a final release? Wouldn't it be the better way to define Milestone releases like RC1 - RCx? Dominik On Fri, May 30, 2008 at 2:48 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On Fri, May 30, 2008 at 2:37 PM, Dominik Süß [EMAIL PROTECTED] wrote: ...While I do not have the time right now I would really like to define (or at least help to define) a basic but obligatory set of documents for the final 2.0.0 release Although the version number is 2.0.0 (or whatever that is), what we're talking about for next week is in no way a final release, I think that's where our viewpoints differ: we're definitely shooting for a release early, release often way of working here. So while I agree that docs are required for a final release, we're more talking about an initial release ;-) -Bertrand
Re: Sling Release
On Fri, May 30, 2008 at 2:55 PM, Dominik Süß [EMAIL PROTECTED] wrote: So why is it defined as major release(just looking at the version number) without being a final release?... Good point, I agree that 2.0.0 might sound a bit too final for the current state of the project - the code is fairly solid and feature-complete, but I agree with you that docs and examples are lacking. I would feel better if the version number was 0.9.0, but considering that we've been using 2.0.0-SNAPSHOT for ages, I doubt it is possible to change that at this point, without causing major Maven confusion (aaarghhh - we don't want Maven confusion do we?). What do others think? -Bertrand
Re: Sling Release
Proposal for this and future releases: Versionname: 2.0.0-RC1 And trying to define a roadmap leading to the final release. Dominik On Fri, May 30, 2008 at 3:02 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On Fri, May 30, 2008 at 2:55 PM, Dominik Süß [EMAIL PROTECTED] wrote: So why is it defined as major release(just looking at the version number) without being a final release?... Good point, I agree that 2.0.0 might sound a bit too final for the current state of the project - the code is fairly solid and feature-complete, but I agree with you that docs and examples are lacking. I would feel better if the version number was 0.9.0, but considering that we've been using 2.0.0-SNAPSHOT for ages, I doubt it is possible to change that at this point, without causing major Maven confusion (aaarghhh - we don't want Maven confusion do we?). What do others think? -Bertrand
Re: Sling Release
Hi, My guts feeling is, yes we need that documentation. But we need that release even more. We have been in the incubator for almost 9 month now constantly extending and at least twice rewriting the complete code. It is about time to get a release. Whether we do a 2.0.0 or a 0.9.0 or an RCx release is minor, actually. We decided a long time ago upon entering the incubator, that Apache Sling's first release will get a major release number and as we already had a private Sling release 1.0 before contributing the project to the ASF, the consequence is to have it like that. In addition, I think, the code itself is pretty stable and warrants a major release number. But this is probably nowhere near a final release, just given the sheer number of open issues we still have and the enhancements requests we expect. So as a starter, I would really go for the release and fix the documentation along the run. Regards Felix Am Freitag, den 30.05.2008, 15:02 +0200 schrieb Bertrand Delacretaz: On Fri, May 30, 2008 at 2:55 PM, Dominik Süß [EMAIL PROTECTED] wrote: So why is it defined as major release(just looking at the version number) without being a final release?... Good point, I agree that 2.0.0 might sound a bit too final for the current state of the project - the code is fairly solid and feature-complete, but I agree with you that docs and examples are lacking. I would feel better if the version number was 0.9.0, but considering that we've been using 2.0.0-SNAPSHOT for ages, I doubt it is possible to change that at this point, without causing major Maven confusion (aaarghhh - we don't want Maven confusion do we?). What do others think? -Bertrand
Re: Sling Release
Hi, Am Freitag, den 30.05.2008, 15:08 +0200 schrieb Dominik Süß: Proposal for this and future releases: Versionname: 2.0.0-RC1 I disagree. Our initial release is not a release candidate. The code is good and works and is proven. It is just documentation which still lacking and which we are constantly enhancing. And trying to define a roadmap leading to the final release. There is no final release and there never will be ;-) We expect to have a constant stream of releases once the first full-blown release has been cut. Remember we will release all-at-once just once. After that, each module will have its own release cycle and versioning. This is not to say, that we neglect your concerns regarding documentation, we have the same. But we also have other concerns. And so we weight the concerns against each other and come to the conclusion to release-early-release-often, even though documentation is not 100% up to date. Regards Felix Dominik On Fri, May 30, 2008 at 3:02 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On Fri, May 30, 2008 at 2:55 PM, Dominik Süß [EMAIL PROTECTED] wrote: So why is it defined as major release(just looking at the version number) without being a final release?... Good point, I agree that 2.0.0 might sound a bit too final for the current state of the project - the code is fairly solid and feature-complete, but I agree with you that docs and examples are lacking. I would feel better if the version number was 0.9.0, but considering that we've been using 2.0.0-SNAPSHOT for ages, I doubt it is possible to change that at this point, without causing major Maven confusion (aaarghhh - we don't want Maven confusion do we?). What do others think? -Bertrand
Re: Sling Release
Ok thats a good point. But then could at least all those out of date pages be reviewed this weekend. Nothing is worse then an outdated documentation. (better remove outdated information which no longer suits the release to prevent confusion) I think the release paradigm would be a nice information to be publicated ;) (wasn't that obvious to me). Regards, Dominik On Fri, May 30, 2008 at 3:15 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Hi, Am Freitag, den 30.05.2008, 15:08 +0200 schrieb Dominik Süß: Proposal for this and future releases: Versionname: 2.0.0-RC1 I disagree. Our initial release is not a release candidate. The code is good and works and is proven. It is just documentation which still lacking and which we are constantly enhancing. And trying to define a roadmap leading to the final release. There is no final release and there never will be ;-) We expect to have a constant stream of releases once the first full-blown release has been cut. Remember we will release all-at-once just once. After that, each module will have its own release cycle and versioning. This is not to say, that we neglect your concerns regarding documentation, we have the same. But we also have other concerns. And so we weight the concerns against each other and come to the conclusion to release-early-release-often, even though documentation is not 100% up to date. Regards Felix Dominik On Fri, May 30, 2008 at 3:02 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On Fri, May 30, 2008 at 2:55 PM, Dominik Süß [EMAIL PROTECTED] wrote: So why is it defined as major release(just looking at the version number) without being a final release?... Good point, I agree that 2.0.0 might sound a bit too final for the current state of the project - the code is fairly solid and feature-complete, but I agree with you that docs and examples are lacking. I would feel better if the version number was 0.9.0, but considering that we've been using 2.0.0-SNAPSHOT for ages, I doubt it is possible to change that at this point, without causing major Maven confusion (aaarghhh - we don't want Maven confusion do we?). What do others think? -Bertrand
