[jira] Resolved: (SLING-1001) Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers
[ https://issues.apache.org/jira/browse/SLING-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz resolved SLING-1001. Resolution: Fixed Fix Version/s: JCR Install 2.0.4 Implemented in revision 788311, but not configurable yet Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers -- Key: SLING-1001 URL: https://issues.apache.org/jira/browse/SLING-1001 Project: Sling Issue Type: Improvement Components: JCR Install Affects Versions: JCR Install 2.0.4 Reporter: Bertrand Delacretaz Fix For: JCR Install 2.0.4 When doing Maven-based development, it is common to create a new version of a bundle with the same xyz-SNAPSHOT version number as the previous one. Currently, jcrinstall does not update the bundle if a new one with the same xyz-SNAPSHOT version number is copied into the repository. It should update in this case, i.e. consider the bundle as a new version if the version string is the same as the installed one but contains -SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [RT] Script Resolution
Hi, On Mon, Jun 22, 2009 at 9:16 PM, Carsten Ziegelercziege...@apache.org wrote: ...I suggest to change the script resolution to use the admin session Sounds good for now, though we might later want to use specific credentials for that. When working with JCR, I miss the unixish execute permission bit, user owner and group owner attributes, and (maybe) setuid bit, we might want to introduce such concepts later. But not right now, no time for that ;-) ... Btw, this would also make caching the script resolution easier as the current approach requires the caching of the script resolution to be a per user cache. With the changes from above the cache can be global... Cool. ...2) Resource events We need to implement https://issues.apache.org/jira/browse/SLING-944 and some extension of this to properly update the cache if scripts are changed, added removed. As scripts can be coming from any data source (jcr, file system, bundle, database etc.) we need a generic mechanism here. For now I think we could start with OSGi events for - Resource added, removed, changed - Resource Provider added, removed... Ok, as long as this doesn't lead to duplicating JCR functionality. -Bertrand
Re: Code Coverage and Metrics
On Tue, Jun 23, 2009 at 10:09 AM, Carsten Ziegelercziege...@apache.org wrote: Sling has been added to the public Sonar instance: http://nemo.sonarsource.org/project/index/org.apache.sling:sling-builder So we get some nice graphics about code coverage, some metrics etc. Cool! Atm we have 9% coverage :) Anyone interested in making us look better? That probably doesn't include our integration tests, or does it? I'd assume the only way to include those tests in the test coverage computation is to run the tests with an instrumented Sling server instance, can Sonar do that? -Bertrand
Re: [RT] Script Resolution
Hi, On Tue, Jun 23, 2009 at 12:03 PM, Ian Bostoni...@tfd.co.uk wrote: On 23 Jun 2009, at 09:42, Felix Meschberger wrote: ... What exact problem do you want to solve with the restriction on script access ? Do you have some kind of x-bit in mind ? The repository itself has no support for (and cannot support) this kind of permission itself Doesn't JCR 2.0 support arbitrary permissions? The spec says A privilege represents the ability to perform a particular set of operations on a node. Each privilege is identified by a JCR name. JCR defines a set of standard privileges within the Privilege interface. An implementation may add additional privileges, using an appropriate implementation
Re: [RT] Script Resolution
(hit send too early - ignore previous message) Hi, On Tue, Jun 23, 2009 at 12:03 PM, Ian Bostoni...@tfd.co.uk wrote: On 23 Jun 2009, at 09:42, Felix Meschberger wrote: ... What exact problem do you want to solve with the restriction on script access ? Do you have some kind of x-bit in mind ? The repository itself has no support for (and cannot support) this kind of permission itself Doesn't JCR 2.0 support arbitrary permissions? The spec says A privilege represents the ability to perform a particular set of operations on a node. Each privilege is identified by a JCR name. JCR defines a set of standard privileges within the Privilege interface. An implementation may add additional privileges, using an appropriate implementation-
Re: [RT] Script Resolution
Hi, On Tue, Jun 23, 2009 at 12:03 PM, Ian Bostoni...@tfd.co.uk wrote: On 23 Jun 2009, at 09:42, Felix Meschberger wrote: ... What exact problem do you want to solve with the restriction on script access ? Do you have some kind of x-bit in mind ? The repository itself has no support for (and cannot support) this kind of permission itself Doesn't JCR 2.0 support arbitrary permissions? The spec says A privilege represents the ability to perform a particular set of operations on a node. Each privilege is identified by a JCR name. JCR defines a set of standard privileges within the Privilege interface. An implementation may add additional privileges, using an appropriate implementation specific namespace for their names So IIUC we (or rather Jackrabbit) might be able to define a jackrabbit:execute privilege? Although Sling might choose to ignore this, I/we (sakai) are going to need to do something since all our users have write access to the repo, and at least 10% of them are Computer Science first year students just itching to prove their prowess by hacking/defacing an institutional system :) Brings back memories ;-) If we're using a distinct session for script resolution, we might want to make its credentials configurable, and setup that user to see scripts only under /libs and /apps. Would that suit your needs? -Bertrand
Re: Selectors and URL paths
Hi Aaron, On Fri, Jun 19, 2009 at 4:00 PM, Aaron Zeckoskiaar...@vt.edu wrote: I am trying to handle requests for certain resourceTypes (e.g. sakai/contactstore) a special way. What I really want to do is handle something like: /_user/contacts/key1.key2.json Where key1 has an unlimited set of values (it would not be a real node) and key2 has a set of about 8 values. If you can, the simplest might be to add another selector that's constant: /_user/contacts/key1.key2.userinfo.json Then, declare your servlet to handle the userinfo selector, and use SlingHttpServletRequest.getRequestPathInfo() .getSelectors() to list all selectors. -Bertrand
Sling graduates from the Apache Incubator!
(ccing jackrabbit PMC as our incubation sponsor) (and friends!) Hi Sling community, I'm pleased to announce that our Board of Directors, at yesterday's meeting, approved the graduation of Sling as a top-level project. I abstained from that vote (as working on Sling is part of my job), so it's not my fault ;-) Felix Meschberger is the chair of the new PMC, composed of * Alexandru Popescu apopescu * Bertrand Delacretaz bdelacretaz * Christophe Lombart clombart * Carsten Ziegeler cziegeler * Felix Meschberger fmeschbe * Gianugo Rabellino gianugo * Padraic Hannon hannonpi * Juan José Vázquez Delgado juanjo * Karl Pauls pauls * Vidar Ramdal vramdal Mike Müller is not listed above but of course remains a documentor as mentioned at http://incubator.apache.org/sling/site/project-team.html. This is just not part of the board's vote, which is about establishing the new project and PMC. Felix is preparing the infrastructure move and will keep us informed. Thanks very much to all involved and let's take Apache Sling to the next level! -- Bertrand
[FYI] OSGi DevCon Europe is next Monday in Zürich, Switzerland
Hi, See http://www.osgi.org/DevConEurope2009/Schedule. From the Sling crowd, Felix, Karl and myself will be giving talks, along with a number of other Apache people and OSGi gurus (including some from the intersection of several of those sets ;-) See you there, hopefully! -Bertrand
Re: SVN moved
On Thu, Jun 18, 2009 at 11:26 AM, Felix Meschberger fmesc...@gmail.com wrote: Thanks to Jukka I could already move the Sling source in SVN to the new location. To adapt your local check-out just use the svn switch, like in: $ svn switch http://svn.apache.org/repos/asf/incubator/sling/trunk I think you mean svn switch http://svn.apache.org/repos/asf/sling/trunk Thanks! -Bertrand
Re: getting error in sling
Hi, On Wed, Jun 17, 2009 at 3:26 PM, Tanmay Barman tanmay.cy...@gmail.com wrote: ...Caused by: java.net.SocketException: Software caused connection abort: socket write error at java.net.SocketOutputStream.socketWrite0(Native Method)... Seems to indicate a client-side problem, looks like Jetty is unable to write output to the client. But it's hard to be specific without more details about what you're doing and how to reproduce the problem. -Bertrand
Re: SLING-490, SystemStatus service discussion
On Tue, Jun 16, 2009 at 1:07 PM, Alexander Klimetschekaklim...@day.com wrote: On Tue, Jun 16, 2009 at 7:55 AM, Felix Meschbergerfmesc...@gmail.com wrote: ...Just to have a status mechanism for startup makes no sense. Well, the whole point of the system ready detection is to find out at what point in time everything is up and running to serve requests... ...But I don't think that bundles going away or crashing during the lifetime should lead to a 503 immediately. They might indicate a problem and one wants to see this problem rather than a 503 Agreed - and anyway I think this can be decided later, here's how I see it: The SystemStatus service will have to cache the system is ready info anyway, to avoid recomputing it for each request. If we want events (bundle installs etc) to cause the system to go back to the not ready mode, it's just a matter of clearing that cached state when such events happen. As long as the SystemStatus service provides a method to clear its cache, we can start with the 503 at startup use case, and look at more sophisticated strategies later - if needed. -Bertrand
Re: SLING-490, SystemStatus service discussion
On Tue, Jun 16, 2009 at 8:02 AM, Felix Meschbergerfmesc...@gmail.com wrote: ...Replying to this message, but my response applies to the complete thread. Let's step back a second and look at what we really need to know to be able to decide the system is ready or not. And who is responsible to provide this knowledge. (1) The most basic criterion for the system to be ready is the available of certain services. ok (2) There must be away to specify which services are required. ok Now, this is very simple and easy: As Alex Klimetschek proposes we are using ConfigurationAdmin for this. Each service can be described by a few properties: (a) Service Name (b) Service Filter (c) Number of services... And in some case (like script engines), additional properties. Use case is I want the JSP script engine to be ready - can we express that with a filter? ...The system status service itself : * requires the ConfigAdmin service to be present * registers as a ManagedService to receive the configuration Thats basically all. Very simple, very lean But how do you bootstrap that ConfigAdmin information for the first startup of a Sling instance, where no OSGi state is stored? Use case: 1) I create a variant of the launchpad app with my own set of bundles 2) I define a custom list of services (according to the above syntax) that must be active for my system to be ready 3) I want my SystemStatus configuration to be available from the first startup of the system How can I put 2) in my custom executable jar? Again, I think using sling.properties to define where this info comes from is the most flexible way, going back to yesterday's example from sling.properties: # Values like myServiceA uses the syntax proposed by Felix sling.readyness.check.1 = services:myServiceA, myServiceB # jcr: means look in the repository for additional definitions sling.readyness.check.2 = jcr:/system/sling/status # osgi:ConfigAdmin means use that service to get additional required # services definition. If not present, the ConfigAdmin service is not # required (for super-lean Sling instances) sling.readyness.check.3 = osgi:ConfigAdmin:nameOfTheConfigThatHoldsThisInfo This is easy to implement, flexible, and implementing it is probably faster than spending ages discussing exactly which options we allow ;-) -Bertrand
Re: SLING-490, SystemStatus service discussion
On Tue, Jun 16, 2009 at 2:55 PM, Carsten Ziegelercziege...@apache.org wrote: Carsten Ziegeler wrote: ...Rethinking the whole stuff, maybe it's better to not use the sling.properties :) and use a configuration provided by the config admin. With jcr install, file install, and the sling launchpad we have a provisioning system that installs bundles and configurations at the same time Not really at the same time, IMHO the sequence is, in a typical Sling launchpad setup: 1. OSGi framework starts 2. Sling engine bundle starts (few dependencies, so starts early) - HTTP requests are accepted now, or soon 3. SlingRepository becomes available (usally later- more dependencies and heavier) 4. jcrinstall observer requires SlingRepository, so starts even later 5. jcrinstall configs might take 1-2 seconds to be activated, due to some internal polling cycles So, if a request comes in afer step 2, and at step 5. some additional SystemStatus configs would have come in, we have a problem. There has to be a way, at step 2. to know that either all the config is already here, and/or that we need to find more of it in the ConfigAdmin, and/or that we have to find more of it in the Resource tree. My proposal provides for these three different options. So, once again- with even more convincing comments ;-) # Values like myServiceA uses the syntax proposed by Felix # This is the minimal sling, no repository, no ConfigAdmin case sling.readyness.check.1 = services:myServiceA, myServiceB # resource: means look in the resource tree for additional definitions # This is the We love Resources case sling.readyness.check.2 = resource:/system/sling/status # osgi:ConfigAdmin means use that service to get additional required # services definition. # This is the We love OSGi case sling.readyness.check.3 = osgi:ConfigAdmin:nameOfTheConfigThatHoldsThisInfo What's wrong with that? You say no, we must use ConfigAdmin but what's the justification for this? The above is more flexible and copes with different use cases for the Sling engine, including not having a repository and not having a ConfigAdmin service. ...So I withdraw my +1 for properties :) and give +1 for config admin!.. I'm starting to think this thread is a plot to make me lose the few hair that I have left ;-) But still, checking for services should be sufficient. I think we all agree on that, especially with Felix's nice filter examples. -Bertrand
Re: SLING-490, SystemStatus service discussion
On Tue, Jun 16, 2009 at 2:44 PM, Felix Meschbergerfmesc...@gmail.com wrote: ...Well, *if* we want to check the system state, that check should be done continuously during the whole lifetime otherwise it makes no sense, honestly:... As I said, SLING-490 is a first step that focuses to startup, and it's easy to add event-driven reset/recompute the readyness state features later on. The latter is not hard to implement (though certainly harder to test), but I'd like to do things in two phases to first get the basics right. ...The goal is to not stop the system, so a system startup is a seldom case and bruning cycles for a case, which almost never (in theory and as a goal) happens, sounds not very productive My main use case is: -Start a Sling application embedded in a runnable jar. -Wait for Sling to be ready. -Open a browser on the applications's homepage. And not get a weird error on that page. It might be a demo use case, but failed demos are not a good way to convince people of Sling's coolness ;-) I agree that *in production webapps* the goal is to never restart but as the above shows that's not the only use case. And in practice we all know that restarts do happen, sometimes for reasons that have nothing to do with Sling, and getting weird errors because requests are accepted before the system is ready is ugly. -Bertrnad
Re: SLING-490, SystemStatus service discussion
On Tue, Jun 16, 2009 at 4:05 PM, Carsten Ziegelercziege...@apache.org wrote: ...We should really make the engine work without any extra bundle as soon as possible I will do that as soon as you accept my proposal ;-) (just kidding, doing it now) -Bertrand
Re: SLING-490, SystemStatus service discussion
On Tue, Jun 16, 2009 at 4:05 PM, Carsten Ziegelercziege...@apache.org wrote: ...We should really make the engine work without any extra bundle as soon as possible... Done, revision 785224. -Bertrand
Re: SLING-490, SystemStatus service discussion
On Tue, Jun 16, 2009 at 4:24 PM, Jukka Zittingjukka.zitt...@gmail.com wrote: Hi, On Tue, Jun 16, 2009 at 3:55 PM, Bertrand Delacretazbdelacre...@apache.org wrote: Not really at the same time, IMHO the sequence is, in a typical Sling launchpad setup: 1. OSGi framework starts 2. Sling engine bundle starts (few dependencies, so starts early) - HTTP requests are accepted now, or soon 3. SlingRepository becomes available (usally later- more dependencies and heavier) 4. jcrinstall observer requires SlingRepository, so starts even later 5. jcrinstall configs might take 1-2 seconds to be activated, due to some internal polling cycles So, if a request comes in afer step 2, and at step 5. some additional SystemStatus configs would have come in, we have a problem. What prevents us from making the Sling engine bundle depend on the repository and jcrinstall bundles? It's certainly good for the engine bundle to have minimal dependencies, to allow for various use cases. Carsten says he's got a no-repository use case for portals, for example. Additionally it could query jcrinstall for config status before starting to respond to HTTP requests That would create a dependency to jcrinstall, which is definitely an optional module and should remain as such. ...If it's a dependency problem, we could perhaps split the engine bundle so that only a small part depends on the availability of the repository and jcrinstall. In non-JCR environments that part could be replaced by something that depends on the alternative backend... That would be an option, if we want to go this route. I'm not too keen on expanding the possible options at the moment, considering the length of this thread ;-) ... PS. I've skipped most of the background for this, so I'm probably missing something essential here... Be gentle. :-)... That was not too bad ;-) -Bertrand
[jira] Commented: (SLING-490) SlingStatusServlet - find out whether a Sling application is ready after startup
[ https://issues.apache.org/jira/browse/SLING-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12719477#action_12719477 ] Bertrand Delacretaz commented on SLING-490: --- Will change version number, and agree about making the SystemStatusService a standard servlet instead of the current special case. I'll discuss the others bits on the sling-dev list. SlingStatusServlet - find out whether a Sling application is ready after startup Key: SLING-490 URL: https://issues.apache.org/jira/browse/SLING-490 Project: Sling Issue Type: Improvement Components: Engine Reporter: Bertrand Delacretaz Priority: Minor Being discussed in http://markmail.org/message/jtdnqneoudxbmb6k -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
SLING-490, SystemStatus service discussion
Hi, Felix and Carsten made some comments in SLING-490 that are probably worth discussing here. Here's how I view this service, comments are welcome. 1. The goal is to return a 503 status until the system is ready to process requests. 2. Defining readyness is hard due to the dynamic nature of OSGi and especially Declarative Services. My idea is to use scripts found under /system/sling/status in the JCR repository to let programmers define what they require for their system to be ready. 3. If it finds an *.foo script there, the default SystemStatus service will complain if no script engine is found to execute *.foo scripts. This avoids problems with requests coming in while the required script engines are not started yet. 4. Currently, a SystemStatus service is required for the SlingMainServlet to operate. I'm not sure how to avoid this coupling - if the SystemStatus service is made optional and a request comes in before it is started, the SlingMainServlet might erroneously think the system is ready. 5. As the default SystemStatus implementation uses scripts, it is not practical to make it a part of the engine bundle, which has no dependency to script engines at the moment. Hence the separate bundle. I'm happy to rediscuss this if needed, but I think giving a customizable server-side way for people to compute the readyness of their Sling system is a must. -Bertrand
Re: SLING-490, SystemStatus service discussion
On Mon, Jun 15, 2009 at 1:00 PM, Alexander Klimetschekaklim...@day.com wrote: On Mon, Jun 15, 2009 at 11:31 AM, Bertrand Delacretazbdelacre...@apache.org wrote: 1. The goal is to return a 503 status until the system is ready to process requests. 2. Defining readyness is hard due to the dynamic nature of OSGi and especially Declarative Services. My idea is to use scripts found under /system/sling/status in the JCR repository to let programmers define what they require for their system to be ready. Why not put a list under /system/sling/status/requiredBundles and requiredServices with the names of the bundles and services that should be running in order to consider the system to be ready? Good idea, and it would allow extensions for use cases that go beyond just testing the presence of a given bundle or service: one could create a service S that checks the required preconditions before coming up (using code, scripts, whatever), and configure S as a requiredService. ...That way it a) only depends on the OSGi Framework API b) could be implemented right inside the engine, introducing none of the chicken and egg problems. c) it also allows you to define more than just scripting engines as dependencies for your system ready state Correct, though my original proposal also allowed for more than scripting engines. The idea was that readyness scripts would check for bundles and services, and maybe run some test code. But your proposal seems to cover all of that. What do others think? -Bertrand
Re: SLING-490, SystemStatus service discussion
On Mon, Jun 15, 2009 at 3:18 PM, Carsten Ziegelercziege...@apache.org wrote: Bertrand Delacretaz wrote: sling.readyness.check = jcr:/system/sling/status to indicate that the readyness check must use JCR nodes under that path to configure itself, like Alex suggests. Absence of that property means no readyness check, and we can later define prefixes other than jcr for alternate mechanisms, if needed. What about merging this with Alex idea? We define properties for required bundles to be available and another one for the services. The sling main servlet (or some helper service) reads the props, and acts accordingly. This keeps everything in one single bundle and does not require any additional stuff. There's one additional requirement ;-) It should be easy for developers to augment this configuration when installing additional services, without having to restart Sling. When adding a bundle that provides a Foo service, for example, I can easily add a node under /system/sling/status, but modifying sling.properties is harder, and less visible. We can still probably combine those ideas, maybe something like: sling.readyness.check = jcr:/system/sling/status sling.readyness.check.1 = bundles:mybundleA, mybundleB sling.readyness.check.2 = services:myServiceA, myServiceB in sling.properties. The SystemStatus service should then indicate, in log messages, where it gets the actual list of things to check. -Bertrand
Re: SLING-490, SystemStatus service discussion
On Mon, Jun 15, 2009 at 3:37 PM, Carsten Ziegelercziege...@apache.org wrote: ... There's one additional requirement ;-) It should be easy for developers to augment this configuration when installing additional services, without having to restart Sling. When adding a bundle that provides a Foo service, for example, I can easily add a node under /system/sling/status, but modifying sling.properties is harder, and less visible. We can still probably combine those ideas, maybe something like: sling.readyness.check = jcr:/system/sling/status sling.readyness.check.1 = bundles:mybundleA, mybundleB sling.readyness.check.2 = services:myServiceA, myServiceB in sling.properties. The SystemStatus service should then indicate, in log messages, where it gets the actual list of things to check. Hmm, not sure if I really understand this requirement :) You have a running system which is ready. Then you install *additional* bundles and the system might be in the state not ready after adding additional stuff? Sounds a little bit strange to me It's for the next startup - as I have added the Foo service, I want the system to wait for it to be ready on the next startup. -Bertrand
Re: SLING-490, SystemStatus service discussion
On Mon, Jun 15, 2009 at 4:05 PM, Carsten Ziegelercziege...@apache.org wrote: Bertrand Delacretaz wrote: On Mon, Jun 15, 2009 at 3:37 PM, Carsten Ziegelercziege...@apache.org wrote: ... There's one additional requirement ;-) It should be easy for developers to augment this configuration when installing additional services, without having to restart Sling. When adding a bundle that provides a Foo service, for example, I can easily add a node under /system/sling/status, but modifying sling.properties is harder, and less visible. We can still probably combine those ideas, maybe something like: sling.readyness.check = jcr:/system/sling/status sling.readyness.check.1 = bundles:mybundleA, mybundleB sling.readyness.check.2 = services:myServiceA, myServiceB in sling.properties. The SystemStatus service should then indicate, in log messages, where it gets the actual list of things to check. Hmm, not sure if I really understand this requirement :) You have a running system which is ready. Then you install *additional* bundles and the system might be in the state not ready after adding additional stuff? Sounds a little bit strange to me It's for the next startup - as I have added the Foo service, I want the system to wait for it to be ready on the next startup. Hmm, but that's still strange - without a restart the check is not enforced but with a restart it is? I think if this is the desired behaviour changing the properties is appropriate. The ideal case would be for the system to go from ready to not ready when you install an additional bundle, but that's harder to implement so I'd like to keep that for later, if needed. About properties vs. nodes...the initial content loading mechanism seems perfectly suited to add the require nodes when a bundle is installed, and remove them when it goes away (IIRC it does that), so that sounds like the simplest thing to do for user bundles. ...On a different thing, OSGi is all about packages and services (bundles are just the way of bundling them - more or less). As services are based on interfaces and therefore packages, it should be enough to just check for the availability of services Right, services should be enough. -Bertrand
[jira] Commented: (SLING-490) SlingStatusServlet - find out whether a Sling application is ready after startup
[ https://issues.apache.org/jira/browse/SLING-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12719114#action_12719114 ] Bertrand Delacretaz commented on SLING-490: --- I would suggest we set the initial version to 0.9.0-incubator-SNAPSHOT Ok, makes sense For compatibility reason, I would suggest to just ignore system status if no SystemStatus service is registered I think that won't work, because if a request comes in and the SystemStatus service is not started yet, the SlingMainServlet might say ready if it ignores the SystemStatus service. It's no big deal to have to add the systemstatus bundle to existing setups, and the error message (No SystemStatus service available) is clear enough to indicate the problem. * I don't like interface methods with throws Exception signature, I suggest to define the method such as to return a status info why the service considers the system not ready, this might be something like a string or more elaborate. At least the signature should define an explicit, publicly available exception to be thrown. Ok, I'll think about that * I would register the extension/systemstatus as a web console plugin to provide end user status info. The current approach is too static. Alternatively the status information could be registered as a normal Sling servlet, though this will of course not be available if Sling is not ready The idea is that /system/sling/status returns a plain text page with details about the current status, as reported by the status scripts found under /system/sling/status in the repository. This info could also be made available in a console plugin, is that what you mean? SlingStatusServlet - find out whether a Sling application is ready after startup Key: SLING-490 URL: https://issues.apache.org/jira/browse/SLING-490 Project: Sling Issue Type: Improvement Components: Engine Reporter: Bertrand Delacretaz Priority: Minor Being discussed in http://markmail.org/message/jtdnqneoudxbmb6k -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-993) Sling Explorer with jquery
[ https://issues.apache.org/jira/browse/SLING-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-993: -- Attachment: explorer-20090613.zip (this time with the correct file ;-) Here's a slightly modified patch, added names to the entry fields for adding properties and nodes, and tweaked layout a bit. I think this is ready to commit, maybe not perfect but usable. Next step - plugins to define specific editors based on node types/property names/etc? Sling Explorer with jquery -- Key: SLING-993 URL: https://issues.apache.org/jira/browse/SLING-993 Project: Sling Issue Type: New Feature Components: Launchpad Environment: osx Reporter: Renaud Richardet Priority: Minor Attachments: explorer-20090613.zip, explorer.zip, Picture 2.png, sling.zip a jcr explorer based on jquery. goals: minimum install and dependencies -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-993) Sling Explorer with jquery
[ https://issues.apache.org/jira/browse/SLING-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-993: -- Attachment: explorer.zip Here's a slightly modified patch, added names to the entry fields for adding properties and nodes, and tweaked layout a bit. I think this is ready to commit, maybe not perfect but usable. Next step - plugins to define specific editors based on node types/property names/etc? Sling Explorer with jquery -- Key: SLING-993 URL: https://issues.apache.org/jira/browse/SLING-993 Project: Sling Issue Type: New Feature Components: Launchpad Environment: osx Reporter: Renaud Richardet Priority: Minor Attachments: explorer-20090613.zip, explorer.zip, Picture 2.png, sling.zip a jcr explorer based on jquery. goals: minimum install and dependencies -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-993) Sling Explorer with jquery
[ https://issues.apache.org/jira/browse/SLING-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-993: -- Attachment: (was: explorer.zip) Sling Explorer with jquery -- Key: SLING-993 URL: https://issues.apache.org/jira/browse/SLING-993 Project: Sling Issue Type: New Feature Components: Launchpad Environment: osx Reporter: Renaud Richardet Priority: Minor Attachments: explorer-20090613.zip, explorer.zip, Picture 2.png, sling.zip a jcr explorer based on jquery. goals: minimum install and dependencies -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-993) Sling Explorer with jquery
[ https://issues.apache.org/jira/browse/SLING-993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz updated SLING-993: -- Comment: was deleted (was: Here's a slightly modified patch, added names to the entry fields for adding properties and nodes, and tweaked layout a bit. I think this is ready to commit, maybe not perfect but usable. Next step - plugins to define specific editors based on node types/property names/etc?) Sling Explorer with jquery -- Key: SLING-993 URL: https://issues.apache.org/jira/browse/SLING-993 Project: Sling Issue Type: New Feature Components: Launchpad Environment: osx Reporter: Renaud Richardet Priority: Minor Attachments: explorer-20090613.zip, explorer.zip, Picture 2.png, sling.zip a jcr explorer based on jquery. goals: minimum install and dependencies -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Make our first release available on central Maven repo? (was: Problems with dependency paths)
Hi Ian, On Thu, Jun 11, 2009 at 11:59 PM, Ian Bostoni...@tfd.co.uk wrote: ...I have a jar that depends on org.apache.sling:org.apache.sling.engine:jar:2.0.4-incubator, which since its released I think is a reasonable thing to do... Of course. . But if you clean out your maven repo (rm -rf ~/.m2/repository/org/apache/sling ) and build you find the build fails with a dependency path of: ... 5) org.apache.sling:org.apache.sling.commons.osgi:jar:2.0.2-incubator and no 5 doesnt exist in the repo. see [1] There is a simple solution to this, force the versions of those releases that are missing to versions that are not, but that a) feels dangerous and b) creates a maintenance headache A quick scan of the repo1 looks like *all* the 202 versions have gone missing from the repo, perhaps they were never there ? That's correct, the artifacts of the first Sling release are in http://people.apache.org/repo/m2-incubating-repository/org/apache/sling/org.apache.sling.commons.osgi/ for example, so currently you need to add that repository to your setup, as described in http://incubator.apache.org/sling/site/getting-and-building-sling.html Now, considering that since our first release the incubator voted [2] to allow podlings to deploy to the main Maven repository, I think we should make the whole http://people.apache.org/repo/m2-incubating-repository/org/apache/sling/ available on repo1.maven.org. What do people think? And how do we do that, is there a way to copy the whole thing at once? -Bertrand [1] http://repo1.maven.org/maven2/org/apache/sling/org.apache.sling.commons.osgi/ [2] https://issues.apache.org/jira/browse/INCUBATOR-82
Re: load root node from a bundle
Hi Andreas, On Fri, Jun 12, 2009 at 6:08 AM, Andreas Kolleggerandr...@kollegger.name wrote: The content loading web page [1] is pretty helpful for getting initial content for directories below root. But, is it possible to use a content definition file for the root node? ... Yes, see http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/content/src/main/resources/content/ROOT.json for an example. -Bertrand
[jira] Commented: (SLING-490) SlingStatusServlet - find out whether a Sling application is ready after startup
[ https://issues.apache.org/jira/browse/SLING-490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718894#action_12718894 ] Bertrand Delacretaz commented on SLING-490: --- Added a new extensions/systemstatus bundle in revision 784180 - dummy implementation for now, says system not ready if a file named /tmp/SystemStatusService.foo exists, to test the mechanism. The SlingMainServlet now requires a SystemStatus service to process requests - this means that all Sling instances need to have the systemstatus bundle (or a custom variant) installed. SlingStatusServlet - find out whether a Sling application is ready after startup Key: SLING-490 URL: https://issues.apache.org/jira/browse/SLING-490 Project: Sling Issue Type: Improvement Components: Engine Reporter: Bertrand Delacretaz Priority: Minor Being discussed in http://markmail.org/message/jtdnqneoudxbmb6k -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1001) Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers
Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers -- Key: SLING-1001 URL: https://issues.apache.org/jira/browse/SLING-1001 Project: Sling Issue Type: Improvement Components: JCR Install Affects Versions: JCR Install 2.0.4 Reporter: Bertrand Delacretaz When doing Maven-based development, it is common to create a new version of a bundle with the same xyz-SNAPSHOT version number as the previous one. Currently, jcrinstall does not update the bundle if a new one with the same xyz-SNAPSHOT version number is copied into the repository. It should update in this case, i.e. consider the bundle as a new version if the version string is the same as the installed one but contains -SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-1001) Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers
[ https://issues.apache.org/jira/browse/SLING-1001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718321#action_12718321 ] Bertrand Delacretaz commented on SLING-1001: This behavior should be configurable (configure the -SNAPSHOT string, empty means no special behavior), as there could be unwanted side effects. Take the Maven -SNAPSHOT convention into account when comparing bundle version numbers -- Key: SLING-1001 URL: https://issues.apache.org/jira/browse/SLING-1001 Project: Sling Issue Type: Improvement Components: JCR Install Affects Versions: JCR Install 2.0.4 Reporter: Bertrand Delacretaz When doing Maven-based development, it is common to create a new version of a bundle with the same xyz-SNAPSHOT version number as the previous one. Currently, jcrinstall does not update the bundle if a new one with the same xyz-SNAPSHOT version number is copied into the repository. It should update in this case, i.e. consider the bundle as a new version if the version string is the same as the installed one but contains -SNAPSHOT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling configuration
Salut Claude, On Thu, Jun 11, 2009 at 2:07 PM, Claude Vedoviniclaude.vedov...@gmail.com wrote: ...Should I (can I) open a JIRA issue for this?.. yes please - the sling.home.prefix way seems to be the best, as Felix suggests in his last message here. -Bertrand
[jira] Commented: (SLING-904) jcrinstall - take three
[ https://issues.apache.org/jira/browse/SLING-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12718022#action_12718022 ] Bertrand Delacretaz commented on SLING-904: --- Start level changes removed in revision 783282 jcrinstall - take three --- Key: SLING-904 URL: https://issues.apache.org/jira/browse/SLING-904 Project: Sling Issue Type: Improvement Components: JCR Install Reporter: Bertrand Delacretaz Refactor and reengineer jcrinstall based on the accumulated experiences of the take two, SLING-646. See discussion in http://markmail.org/message/ld6tkz6fdseknntx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling configuration
Hi, On Tue, Jun 9, 2009 at 8:03 AM, Felix Meschbergerfmesc...@gmail.com wrote: Claude Vedovini schrieb: ...I guess that now that each deployed sling servlet has it's own subfolder under sling.home to store configuration to, then may be overriding the sling.home from the system properties could be a good idea. Since system properties apply to the whole VM, multiple sling web applications deployed to the same servlet container would then use the same sling.home system property, which will not work But if each deployed Sling servlet adds its own suffix (its context path) to the base sling.home path, that would work, not? The best might be to allow overriding sling.home from system properties (to allow people to control where that goes), yet have each sling servlet add its own context path to that value to define its own storage path. -Bertrand
Continuum or Hudson?
Hi, We currently have two continuous integration setups for Sling: Continuum: http://vmbuild.apache.org/continuum/projectGroupSummary.action?projectGroupId=53 Hudson: http://hudson.zones.apache.org/hudson/view/Sling/ I don't have much experience with Continuum, but every time I try to do something on vmbuild it's very slow and painful. Seems like that box is overburdened, and the UI is not very easy to use, IMHO. The Hudson setup, OTOH, took me only about an hour of work from scratch, with no previous knowledge of Hudson, and has been running smoothly ever since. Including automatically picking up changes in parent POMs when new modules are created or whem modules are moved, which is very convenient. The overall experience has been much better for me. I don't think we need two CI servers - what do people think of dropping Continuum, and keeping only Hudson? -Bertrand
Re: Unable to run latest SNAPSHOT 6 espblog sample
On Tue, May 26, 2009 at 7:33 PM, Glenn Silvermangl...@glenn3.securesites.net wrote: ...Navigating to http://localhost:8080/content/espblog/*.html generated the following error: HTTP ERROR 200 Problem accessing /content/espblog/*.html. Reason: OK with Allow Anonymous Access set to false in the Request Authenticator Bundle configuration Created https://issues.apache.org/jira/browse/SLING-998 to handle this, got a patch already, should be fixed soon. -Bertrand
[jira] Closed: (SLING-998) Request fails with HTTP ERROR 200 - Reason: OK if anonymous access is disabled
[ https://issues.apache.org/jira/browse/SLING-998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz closed SLING-998. - Resolution: Fixed Fix Version/s: Engine 2.0.6 In revision 782948, an unauthenticated request is redirected to /system/sling/login if anonymous access is not allowed. The LoginServlet handles that path by displaying a simple login form. I have also moved the LoginServlet from the extensions/httpauth bundle to the engine bundle, as it is not http-specific. Request fails with HTTP ERROR 200 - Reason: OK if anonymous access is disabled -- Key: SLING-998 URL: https://issues.apache.org/jira/browse/SLING-998 Project: Sling Issue Type: Bug Components: Engine Affects Versions: Engine 2.0.4 Reporter: Bertrand Delacretaz Fix For: Engine 2.0.6 See discussion in http://markmail.org/message/smbbphesab42fwnz - a request to / with no credentials returns a page saying: HTTP ERROR 200 Problem accessing / Reason: OK If allow anonymous access is disabled on /system/console/configMgr/org.apache.sling.engine.impl.auth.SlingAuthenticator -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-999) Integration test for /system/sling/login redirect and login
Integration test for /system/sling/login redirect and login --- Key: SLING-999 URL: https://issues.apache.org/jira/browse/SLING-999 Project: Sling Issue Type: Test Components: Testing Reporter: Bertrand Delacretaz Implement an integration test according to this scenario: 1. Set allow anonymous access to false 2. Request / and expect a redirect to /system/sling/login 3. Login via /system/sling/login 4. Verify access to /index.html 5. Logout and verify The SLING-998 changes implement that behavior. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-990) Prototype for a Sling Explorer implementation based on GWT
[ https://issues.apache.org/jira/browse/SLING-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12717680#action_12717680 ] Bertrand Delacretaz commented on SLING-990: --- Would it be a big problem to not be able to use SmartGWT ? Or would you be able to convince the SmartGWT folks to change their license or to use a dual license? Prototype for a Sling Explorer implementation based on GWT -- Key: SLING-990 URL: https://issues.apache.org/jira/browse/SLING-990 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Christophe Lombart Attachments: Sling Explorer.zip Following the Sling Explorer proposal [1], I have started an implementation with the SwartGwt UI framework [2] (based on GWT and under LGPL licence). Not sure but I think that LGPL is compatible with the Apache project. Until now, it is just a prototype. Can you review the code and see if this Gwt application is well integrated with Sling ? [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html [2] http://code.google.com/p/smartgwt/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-990) Prototype for a Sling Explorer implementation based on GWT
[ https://issues.apache.org/jira/browse/SLING-990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12717698#action_12717698 ] Bertrand Delacretaz commented on SLING-990: --- I had a quick look and this looks good. To build it, I had to set the maven-sling-plugin version to 2.0.4-incubator in pom.xml Also, I think the URL used to access the explorer ( /explorer/index.html ) is not mentioned in the README. Is it correct that this version is read-only? That's not a problem, I'm just not sure if I haven't found how to edit stuff ;-) Prototype for a Sling Explorer implementation based on GWT -- Key: SLING-990 URL: https://issues.apache.org/jira/browse/SLING-990 Project: Sling Issue Type: New Feature Components: Extensions Reporter: Christophe Lombart Attachments: Sling Explorer.zip Following the Sling Explorer proposal [1], I have started an implementation with the SwartGwt UI framework [2] (based on GWT and under LGPL licence). Not sure but I think that LGPL is compatible with the Apache project. Until now, it is just a prototype. Can you review the code and see if this Gwt application is well integrated with Sling ? [1] http://cwiki.apache.org/SLING/sling-based-jcr-explorer.html [2] http://code.google.com/p/smartgwt/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Moving rewriter to contrib
Hi Carsten, On Tue, Jun 9, 2009 at 2:17 PM, Carsten Ziegelercziege...@apache.org wrote: ...I'm planning to move this from the whiteboard to the contrib section. If noone objects, I'll do this in the next days In principle I'm all for it, but http://svn.apache.org/repos/asf/incubator/sling/whiteboard/rewriter/src/test returns a 404 ;-) Can I haz tests? Or maybe a simple smoke-test-the-whole-thing test in launchpad/testing is easier? -Bertrand
Re: Sling configuration
Hi,
On Tue, Jun 9, 2009 at 1:58 PM, Claude
Vedoviniclaude.vedov...@gmail.com wrote:
Thus given the system poroperty sling.home.prefix is set to
/var/sling. In this case the default sling.home for the /sling/i1 web
app would be /var/sling/_sling_i1.
Would such a prefix suit your needs ?
That would certainly do, but why introduce a new concept?
Let's say that the sling.home property in the sling.property file, the
sling.home init-param in the web.xml and the sling.home system
property override each others (in this order) and they all specify the
root where each deployed sling servlet is going to create its
workspace.
I agree that having a single sling.home property would be simpler, so why not
sling.home = ./sling/{1}
by default, where {1} is replaced by the (suitably escaped)
SlingServlet's context path?
This would make things fully configurable, while allowing multiple
instances of the SlingServlet to each have their own storage folder.
-Bertrand
[jira] Created: (SLING-1000) Web console plugin to display recent requests
Web console plugin to display recent requests - Key: SLING-1000 URL: https://issues.apache.org/jira/browse/SLING-1000 Project: Sling Issue Type: Improvement Components: Engine Affects Versions: Engine 2.0.4 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Fix For: Engine 2.0.6 I have created a console plugin that displays the RequestProgressTracker info of the last N requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (SLING-1000) Web console plugin to display recent requests
[ https://issues.apache.org/jira/browse/SLING-1000?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz closed SLING-1000. -- Resolution: Fixed Committed in revision 783056, the web console includes a new plugin at /system/console/requests, see screenshot. The information that's displayed comes from the RequestProgressTracker, if we need more details we just have to add them there. Web console plugin to display recent requests - Key: SLING-1000 URL: https://issues.apache.org/jira/browse/SLING-1000 Project: Sling Issue Type: Improvement Components: Engine Affects Versions: Engine 2.0.4 Reporter: Bertrand Delacretaz Assignee: Bertrand Delacretaz Priority: Minor Fix For: Engine 2.0.6 Attachments: recent-requests.jpg I have created a console plugin that displays the RequestProgressTracker info of the last N requests. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: GEtting and starting Sling in Eclipse 3.4
Hi Glenn, On Tue, Jun 9, 2009 at 10:16 PM, Glenn Silvermangl...@glenn3.securesites.net wrote: http://admin:ad...@localhost:/testing/this should display a default HTMLrepresentation, including the value of the title property. That URL is not valid anymore due to changes in how URLs without extensions are handled. The correct one is http://admin:ad...@localhost:/testing/this.html I just updated the launchpad/webapp/README.txt - thanks for reporting! -Bertrand
Re: GEtting and starting Sling in Eclipse 3.4
Hi Glenn,
On Tue, Jun 9, 2009 at 10:57 PM, Glenn
Silvermangl...@glenn3.securesites.net wrote:
...I tried the new URL, but got the following error
message:
Resource dumped by HtmlRendererServlet
Resource path: */testing/this*
Resource metadata: *{sling.resolutionPathInfo=.html
sling.resolutionPath=/testing/this}*
Resource properties
title: *something*
jcr:primaryType: *nt:unstructured
*I thought that this message would go away if I installed the path-based-rpt
bundle, which I did
The above rendering is correct in this case, it's the default HTML
rendering, used when no specific script is present to render a node.
So if you did
curl -D - -Ftitle=something http://admin:ad...@localhost:/testing/this
to create the node, it doesn't have a sling:resource property, which
causes it to be rendered by the default GET servlet's HTML renderer
(Resource dumped by HtmlRendererServlet).
With its default config, the path-based-rtp bundle only applies to
nodes under /content, so it does not make any difference in this case.
To set a specific resource type for your node, the best would be to
add a sling:resourceType property to it, as shown in the examples at
http://incubator.apache.org/sling/site/discover-sling-in-15-minutes.html
-Bertrand
Re: [VOTE] Use repository.a.o for deployments
On Wed, May 27, 2009 at 10:54 AM, Felix Meschberger fmesc...@gmail.com wrote: [X ] +1 use repository.a.o (Nexus repository) for deployment -- Bertrand
Re: Unable to run latest SNAPSHOT 6 espblog sample
Hi Glenn, On Tue, May 26, 2009 at 7:33 PM, Glenn Silverman gl...@glenn3.securesites.net wrote: I am unable to run the espblog sample following the README instructions. ... Navigating to http://localhost:8080/content/espblog/*.html generated the following error: HTTP ERROR 200 Problem accessing /content/espblog/*.html. Reason: OK Hmmmnot really helpful as an error message ;-) It looks like recent changes to the authentication mechanisms require logging in in a different way - I just added the following instructions to the espblog README.txt : First, login by requesting http://localhost:/?sling:authRequestLogin and using username=admin password=admin. This should display the Welcome to the Sling Launchpad index.html page. We should better integrate this login mechanism in the sample, but for now this should allow you to play with it. -Bertrand
Re: [DISCUSS] New strcuture for documentation on Sling site
Hi Mike, On Fri, May 22, 2009 at 11:08 AM, Mike Müller mike...@mysign.ch wrote: ...Okay, I scanned the whole docs now (took some time...) and would like to restructure things a little bit to make it more easy to find the right doc Cool, thanks! See below for a few comments on the new structure. NEW: - Documentation (Overview - was Documenting Sling [UPDATE]) - Getting started - What is Sling [NEW, extracts from existing home] - Discover Sling in 15 minutes [OK] - How Sling uses and integrates with JCR [NEW] I would prefer Sling and JCR as a title for the last item. - Engine, the heart of Sling - Architecture - Resources [UPDATE] - Request Parameters [OK] - Filters [OK] - Dispatching Requests [REWRITE] - Default Mapping and Rendering [REWRITE] - Eventing and Jobs [CHECK] -- Carsten can you have a look at it - Authentication [OK] I think Scripts and Servlets belongs here somewhere, as a general concept. - Development - Getting and building Sling [UPDATE] Here I would add a zero-tools development topic, explaining how to use Sling with a WebDAV mount for script-based development. - Maven Tips Tricks [UPDATE] - Setup with Eclipse 3.4 [NEW, from Wiki] - Maven Sling Plugin [UPDATE, got content from Felix] - Maven JspC Plugin [CHECK] - How to create a new bundles and services for Sling [NEW] - Logging [OK] [UPDATE] - RequestProgressTracker [NEW, from SLING-3] - Dependency Management [OK] - Repository Based Development [OK] (lack of Eclipse Plugin) - Bundles - MIME Type Support (commons/mime) [OK] - Internationalization Support (extensions/i18n) [UPDATE] - Manipulating Content/SlingPostServlet (servlets/post) [OK] - Content Loading (lack of JSON/XML) (jcr/contentloader) [UPDATE] ... a doc page for each bundle should be the future ambition... - Tutorials How-Tos - Launch Sling (was Provisioning and Startup) [REWRITE] - Installing and Upgrading Bundles [OK] -- link to [1] - ACL/ACE [NEW] - Default Sling JCR layout and nodetypes [NEW] - Implementing a ResourceProvider [NEW] - Apache Sling Rewriter [OK] (Code under whiteboard) - XSLT Processing Pipeline [OK] - Wiki - configuration (was Configuration Support) [OK] - Sling in production - Sling standalone [NEW] - Sling in a Servlet container [NEW] - Sling with Apache httpd [NEW] - Access Logging [NEW] - Sling API (JavaDoc) [OK] FAQ [DELETE] - should rather be integrated into the doc on the related themes. Note sure about that, a general FAQ is good to have. ... Next steps: * give me your input about the new structure and also missing topics... I'm more worried about a too ambitious plan than missing topics ;-) But the above looks good. * I begin to update the structure and content (and definitifely ask for help from the list for several topics) Cool -Bertrand
Re: [DISCUSS] New strcuture for documentation on Sling site
On Sun, May 24, 2009 at 11:56 PM, Alexander Klimetschek aklim...@day.com wrote: 2009/5/22 Dominik Süß dominik.su...@gmail.com: I like the idea of an overview page (the new documentation parent page) with a hot topics or better Getting Started box with a roadmap of links the user can follow to get a good overview of Sling. This would allow to have a technically correct hierarchy, but supporting newcommers who have no clue how Sling is organized and where to start. WDYT? +1 I like this as well, but I also think our docs need tags to provide several ways of navigating them. I don't think the Confluence export plugin that currently generates our website handles tags, but we could still add them to our pages already, something like: TAGS #servlets #scripts #javascript In the content of the page. For now this can be used by web search engines, and later we might create a Sling navigation app and run it on an ASF zone. The main website content can still come from static pages, but the navigation/tagging features would be dynamic. -Bertrand
Re: [PROPOSAL] Graduate Apache Sling as Top Level Project
On Mon, May 25, 2009 at 9:31 AM, Felix Meschberger fmesc...@gmail.com wrote: ...We have prepared the board resolution on our wiki at [3] ... [3] http://cwiki.apache.org/SLING/graduation-resolution-draft.html... The resolution looks good to me. (and I'm +1 on graduation, but kinda biased, being a Sling committer ;-) -Bertrand
Re: [DISCUSS] New strcuture for documentation on Sling site
2009/5/25 Dominik Süß dominik.su...@gmail.com: On Mon, May 25, 2009 at 9:21 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: ... TAGS #servlets #scripts #javascript In the content of the page. For now this can be used by web search engines, and later we might create a Sling navigation app and run it on an ASF zone. The main website content can still come from static pages, but the navigation/tagging features would be dynamic. ... Since I currently try to figure out new/unused ways to optimize navigation and user experience in hierarchical systems tagging seams to gain importance to me. The only thing the sling page really could need for this is a nice UI for 1-click access of the tagged content as well as a searchbox in the documentation part. Yes - my idea is a navigational UI that enhances the existing static website pages, but the website should also work without it. So more like a progressive enhancement of the webpages, rather than something that takes over the website. -Bertrand
[jira] Commented: (SLING-904) jcrinstall - take three
[ https://issues.apache.org/jira/browse/SLING-904?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12712668#action_12712668 ] Bertrand Delacretaz commented on SLING-904: --- In revision R776361, the new jcrinstall/it integration tests module uses Pax Exam to test the jcrinstall/osgi module, which provides the OsgiController service. This has unveiled some minor bugs, like in some cases not restarting a bundle after updating, which are fixed now. The remaining TODOs are: 1. Remove the start level changes in the jcrinstall service module, they should not be needed anymore. 2. Remove the dependency of the osgi module on org.slf4j, to minimize dependencies 3. If needed, break up the OsgiControllerImpl operations using smaller orderable tasks, according to the proposal at http://markmail.org/message/a6xx4dawsokl6lpx . This should help improve bundle management as discussed in the thread that led to this issue (http://markmail.org/message/ld6tkz6fdseknntx). jcrinstall - take three --- Key: SLING-904 URL: https://issues.apache.org/jira/browse/SLING-904 Project: Sling Issue Type: Improvement Components: JCR Install Reporter: Bertrand Delacretaz Refactor and reengineer jcrinstall based on the accumulated experiences of the take two, SLING-646. See discussion in http://markmail.org/message/ld6tkz6fdseknntx -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Sling Logo Issue
On Fri, May 22, 2009 at 2:32 PM, Pontus Amberg pontus.amb...@milso.se wrote: The small crack between the top of the S and the line connecting the S and g in the PNG version of the logo has always annoyed me. Good catch - I didn't notice it before, but now it's in my face all the time ;-) Apart from that, changes look good, thanks Felix! -Bertrand
[jira] Commented: (SLING-931) Felix webconsole not restarted after upgrading via jcrinstall
[ https://issues.apache.org/jira/browse/SLING-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12711058#action_12711058 ] Bertrand Delacretaz commented on SLING-931: --- Fixed in revision 776361, leaving this issue open until corresponding tests are added Felix webconsole not restarted after upgrading via jcrinstall - Key: SLING-931 URL: https://issues.apache.org/jira/browse/SLING-931 Project: Sling Issue Type: Bug Components: JCR Install Reporter: Bertrand Delacretaz After upgrading the Felix webconsole from 1.2.6 to 1.2.8 via jcrinstall, by copying the 1.2.8 bundle in a JCR repository folder that's watched by jcrinstall, the webconsole bundle is not restarted. AFAICS the failure scenario is: - jcrinstall updates the webconsole bundle and starts a package refresh -Several bundles that import the webconsole plugin interfaces are stopped and restarted -That causes more bundles to stop and restart, including eventually jcrinstall -As jcrinstall doesn't persist the list of bundles that must be restarted after the update, the webconsole restart is lost Steps to reproduce: Start the sling launchpad/app Install the Felix shell and shell text UI services (http://felix.apache.org/site/downloads.cgi) Install and start the Sling runmode and jcrinstall bundles. Uninstall the webconsole bundle using the Felix shell UI. Install and start the Felix webconsole 1.2.6 using the Felix shell UI. Refresh packages, from the Felix webconsole or shell. Try to install the Felix webconsole 1.2.8 via jcrinstall, by copying it in the repository under /libs/testing/install Result: /system/console does not display the console anymore After starting the console bundle from the Felix shell, things are back to normal -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release Apache Sling MIME type mapping support Version 2.1.0-incubator
On Mon, May 18, 2009 at 11:56 AM, Felix Meschberger fmesc...@gmail.com wrote: ...The main source artifacts have the following checksums: org.apache.sling.commons.mime-2.1.0-incubator-project.zip MD5: a3b4135a0cd6a9a3f779bba34cf335da SHA1: 0f1c866ef65a29433f1fae06aa3a898515c32c7e org.apache.sling.commons.mime-2.1.0-incubator-project.tar.gz MD5: 216169b0341102f47546cfb15f1c13d3 SHA1: 924767432aac9ceeaf3534b7c91e369cf0343f3a So, please vote on this release: [X ] +1 yes, release Verified the above two artifacts only, contents are identical to svn rev 776706, except for version numbers of course. -Bertrand
Re: AW: update launchpad/bundles/pom.xml to SNAPSHOT versions?
On Mon, May 18, 2009 at 10:11 AM, Carsten Ziegeler cziege...@apache.org wrote: ...I think all automatisms fail here; whenever someone thinks that a new bundle is ready for release/inclusing in the release, update the dependency in the launchpad/bundles Why not, but I'd like the launchpad/testing module to always test the trunk - so it might need its own set of dependencies, independent of the launchpad/bundles module. It was like that originally, and that changed when the launchpad/bundles was created. The constraints of the launchpad/app and webapp modules (use stable stuff) are different from those of the launchpad/testing module (test the latest trunk) so we might want to go back and have launchpad/testing use its own set of bundles version numbers. WDYT? -Bertrand
Re: AW: update launchpad/bundles/pom.xml to SNAPSHOT versions?
On Mon, May 18, 2009 at 10:57 AM, Carsten Ziegeler cziege...@apache.org wrote: Bertrand Delacretaz wrote: ...so we might want to go back and have launchpad/testing use its own set of bundles version numbers. WDYT? Ok, we can do this - so this is kind of doing like gump is doing its stuff. But I see the potential problem that we release our launchpad stuff which is never tested by the integration tests as they test some never stuff where problems might already be fixed/or different. This can be solved by (manually) running the launchpad/testing tests against an instance of Sling started by the app or webapp modules, like I did for the last release. Some tests might fail if they have been created for trunk stuff that's not being released yet, but even in this case noting the differences will be useful. -Bertrand
Re: [VOTE] Graduate Apache Sling as a top level project
On Mon, May 18, 2009 at 4:12 PM, Felix Meschberger fmesc...@gmail.com wrote: [X ] +1 Graduate as a top level project Commits still mostly come from Felix, Carsten and myself, but with the new committers and increased community activity the trend is definitely in the right direction. -Bertrand
Re: update launchpad/bundles/pom.xml to SNAPSHOT versions?
Hi Mike, On Fri, May 15, 2009 at 10:10 PM, Mike Müller mike...@mysign.ch wrote: ...Have you in mind to give users something more stable than the real snapshot if the build the standalone app or the web app? At the moment I use the launchpad app as the base for my tests. But I would like to do the tests with the latest sling source. So if my assumption about your doubt is right, maybe we should include another profile (something like snapshot or dev) in the pom which would include latest source Contrary to the other bundles which IMHO should reference stable stuff as long as they don't need bleeding edge, the launchpad/testing application is meant to point to snapshots all the time, to test the latest stuff. So you could use that webapp for your tests, starting it with mvn jetty:run. I haven't checked if it's pointing to snapshots though, if it's not we should changed it. -Bertrand
Re: AW: Content Loading question.
Hi, On Fri, May 15, 2009 at 11:53 PM, Ian Boston i...@tfd.co.uk wrote: I am not absolutely certain about this but I think the description is not in sync with the examples Note that the initial content found at [1] is verified by the InitialContentTest [2] when running the launchpad/testing integration tests. Contributions are welcome to expand the coverage of those tests. I have added this info to [3], so that people can look at the tests and hopefully provide more in the future. -Bertrand [1] http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/content/src/main/resources/content/sling-test [2] http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/testing/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/InitialContentTest.java [3] http://incubator.apache.org/sling/site/content-loading.html
Re: [RT] Generic scriptable launcher
On Thu, May 14, 2009 at 8:47 AM, Carsten Ziegeler cziege...@apache.org wrote: ...While I see the value of a launcher - I don't think that this is the concern of Sling - we are the framework which should run in every OSGi installation; so let's focus on the framework and leverage other efforts like pax+runner, Karaf etc. instead of doing this stuff ourselves Agree, I was actually thinking of creating the launcher as an independent tool outside of Sling, maybe at Apache Commons. Just wanted to see how much people like it here, as that could be useful for our launchpad configurations. -Bertrand
Re: [RT] Generic scriptable launcher
On Wed, May 13, 2009 at 9:04 PM, Felix Meschberger fmesc...@gmail.com wrote: Hi, Bertrand Delacretaz schrieb: I'm thinking of creating a generic launcher, using a text file definition to load and start jars, allowing a Sling launcher to take over and load and start bundles once a main class is started. This sounds a lot like Tanuki Java Service Wrapper ... Ok, I'll have a look. ...At first I thought: What may this be used for. Maybe just because I failed to understand the problem for which you present a solution. Is this about creating custom Sling configurations ?... It is about empowering users to create their own assemblies of jars and bundles, and share those assemblies in a simple and foolproof way. Now, this is certainly a valid request, to which we currently have two answers: * The launchpad/bundles project defines a package of bundles to be included in the app or webapp binary * A patch to extend the BootstrapInstaller to read more bundles for installation from the filesystem... Ok, but sharing the resulting assembly is not convenient, especially if your configuration involves omitting (removing) some launchpad bundles. ...Maybe we need an additional mechanism for setting up an initial set of bundles. Now, there's pax runner [1] which sports so called profiles, which may be exactly what you are envisioning ?... I'll have a closer look at that. -Bertrand [1] http://paxrunner.ops4j.org/space/Pax+Runner
Creating a user mailing list? (was: [DISCUSS] Graduation)
On Wed, May 13, 2009 at 8:31 PM, Felix Meschberger fmesc...@gmail.com wrote: Dominik Süß schrieb: ...BTW. at this point a users-mailinglist would really make sense since this mailinglist might be really confusing for a sling-rookie;) Is this user-mailinglist part of the graduationprocess? There is no hard relation-ship for having a users list and the graduation. A user list is more of a decission to split traffic. For now, I am not sure, whether we really need it. But if the community deems it useful to have two list, I am certainly open to also run a users list. Maybe to be set up during the graduation process I don't think need a user mailing list right now, IMHO our community is too small to warrant separate lists. This list currently has 130 subscribers according to http://people.apache.org/~coar/mlists.html. The problem with separate user and dev lists is that it tends to create an us and them feeling which I don't like, unless traffic is really to high for a single list. We can always create a user list later, nothing says this has to happen at graduation time. -Bertrand
Re: Releases in the future
On Tue, May 12, 2009 at 10:34 PM, Roy T. Fielding field...@gbiv.com wrote: On May 12, 2009, at 12:40 AM, Bertrand Delacretaz wrote: On Mon, May 11, 2009 at 10:29 PM, Roy T. Fielding field...@gbiv.com wrote: On May 11, 2009, at 12:03 PM, Felix Meschberger wrote: Carsten and I have been reasoning about the releases in the future, mainly the ones for end-users who just want to grab a binary and fire it off Apache only releases source code packages. Those other things you build are not releases -- they are binaries that individuals build and upload. How about naming those things binary packages instead of releases? A rose is still a rose ... We can still use the same process for releasing them, and include a disclaimer that they're not official releases and provided without warranty etc.. I don't see how we can use the same process for releasing them when part of that process requires comparison of the source code with what is in subversion. An ASF release is a group decision based on peer review, and I don't think anyone giving +1s on the binaries are actually doing JVM decompiles and source-level comparisons to verify the contents don't include some extra trojan horse. Running the tests is not sufficient. That's why the ASF does not vote on binaries. I'd rather not make it look like we are. Ok, I see your point. I suggest that we clarify how we do that next time we have a concrete case. -Bertrand
[jira] Closed: (SLING-946) jcrinstall integration tests fail on our Hudson build server
[ https://issues.apache.org/jira/browse/SLING-946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bertrand Delacretaz closed SLING-946. - Resolution: Fixed Using the latest bnd (revision 774406) fixed the problem. jcrinstall integration tests fail on our Hudson build server Key: SLING-946 URL: https://issues.apache.org/jira/browse/SLING-946 Project: Sling Issue Type: Bug Components: JCR Install Reporter: Bertrand Delacretaz Priority: Minor The jcrinstall integration tests in the http://hudson.zones.apache.org/hudson/view/Sling/job/sling-contrib-1.5 build fail with errors like java.io.FileNotFoundException: /home/hudson/hudson-slave/workspace/sling-contrib-1.5/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/15/cloned-bundles/observer_clone_1240993668015.jar For some reason, the tests cannot find the cloned bundles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
FYI, added some Pax Exam-based tests
Hi, See contrib/extensions/jcrinstall/it - I used Juanjo's whiteboard example (whiteboard/jvazquez/testing) as a base, thanks! Tests obviously run slower than pure JUnit tests, but not too slow, and it's fairly easy to assemble some bundles to test services. I have configured debugging so that -Dpax.exam.debug.port=1234 on the mvn command line activates remote debugging of the tests, which run in a separate VM. For my jcrinstall tests it would be nice to be able to grab bundles from the Maven repository using Pax Exam's mavenBundle() and friends, but I havent figured that out yet. -Bertrand
Re: Revision of Sling documentation, determining old stuff
Hi Mike, On Tue, May 12, 2009 at 10:24 PM, Mike Müller mike...@mysign.ch wrote: So please give me some feedback on the following pages: - Architecture (seems to be up-to-date) [1] Looks good - Eventing and Jobs (can someone check) [2] Looks good to me but Carsten is the man - Internationalization Support (can someone check, seems to be outdated, at least there's no getLocale() on SlingHttpServletRequest) [3] Correct. IMHO a typical example of a page that needs to have less details, to stand a better chance of staying in sync with the code. - Installing and Upgrading Bundles (can someone check seems to be outdated in favour of Felix management console) [4] Agreed, should point to http://felix.apache.org/site/apache-felix-web-console.html instead - Assembly (can someone check, seems not to be part of Sling, maybe CRX) [5] We are not using assemblies anymore AFAIK, page should be removed? - Apache Sling Rewriter (maybe ok, but can't find org.apache.sling.rewriter.*) [6] AFAIK the code is still under https://svn.eu.apache.org/repos/asf/incubator/sling/whiteboard/rewriter - Groovy Support (seems to be ok) [7] Looks good, didn't check the details. - XSLT Processing Pipeline (seems to be ok) [8] Looks good, didn't check the details. - Maven Sling Plugin (can someone check) [9] Looks good, didn't check the details. - Maven JspC Plugin (can someone check) [10] Don't know enough to say. BTW I didn't get why the new Sling release is Sling 5 and not Sling 4... Release 4 was broken so we didn't release it. Thanks for your investigations! -Bertrand [1] http://incubator.apache.org/sling/site/architecture.html [2] http://incubator.apache.org/sling/site/eventing-and-jobs.html [3] http://incubator.apache.org/sling/site/internationalization-support.html [4] http://incubator.apache.org/sling/site/installing-and-upgrading-bundles.html [5] http://incubator.apache.org/sling/site/assembly.html [6] http://incubator.apache.org/sling/site/rewriting-the-output-through-pipelines.html [7] http://incubator.apache.org/sling/site/groovy-support.html [8] http://incubator.apache.org/sling/site/xslt-processing-pipeline.html [9] http://incubator.apache.org/sling/site/sling.html [10] http://incubator.apache.org/sling/site/jspc.html
[RT] Generic scriptable launcher
Hi, I'm thinking of creating a generic launcher, using a text file definition to load and start jars, allowing a Sling launcher to take over and load and start bundles once a main class is started. Here's a rough idea - I haven't looked at Karaf closely yet, there's probably some overlap, but my idea is to create a generic Java launcher, having nothing to do with OSGi, that in turn launches an OSGi-aware main class. The launcher is a runnable jar, or a war file. It uses a text file named launch.txt to define what to launch, example below. # START launch.txt example properties: sling.home = ./sling org.apache.commons.launcher.protocols.maven.repository.1 = http://repo1.maven.org/maven2 org.apache.commons.launcher.protocols.maven.repository.2 = http://people.apache.org/repo/m2-incubating-repository protocols: # by default only the http and file protocol are provided to # load jar files, more can be added by loading protocol jars # The maven protocol, for example, grabs jar files from # repositories defined by the *.maven.repository properties # found above. jar http://some.repository/launcher-maven-protocol-1.4.2.jar md5=1231231239812cd21231987 bootstrap: # load a number of jars that are required to start the main class jar maven:org.apache.felix:org.osgi.compendium:jar:1.2.0 md5=1231231239812cd212315645 jar maven:org.apache.felix:org.osgi.core:jar:1.2.0 sha1=1231231239812cd21231123213 jar maven:org.apache.felix:org.osgi.foundation:jar:1.2.0 sha1=1231231239812cd2123112313 jar maven:org.apache.sling:org.apache.sling.launchpad.launcher:2.0.2-incubator md5=1231231239812cd2123112313 # now start the main class, from the org.apache.sling.launchpad.launcher jar main-class org.apache.sling.launchpad.launcher.Main -m launcher # The launcher stops processing here, and provides this file to the main class as its # standard input. The above launcher.Main processes the lines that follow the # above main-class statement # Load and start a few bundles, some with specific start levels bundle http://some.obr/some-bundle sha1=1231390890823121312 bundle maven:some.group:some.artifact:1.0 startlevel=2 md5=123213213984329843 # END launch.txt example Creating a launcher that will never change doesn't seem too hard, and then defining a Sling launchpad instance boils down to the launch.txt file. Using a text file to define bundles makes it easy for people to exchange configurations, as the text file fully defines the application assembly, based on the bundles URLs and digests. WDYT? -Bertrand
[jira] Commented: (SLING-946) jcrinstall integration tests fail on our Hudson build server
[ https://issues.apache.org/jira/browse/SLING-946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12708968#action_12708968 ] Bertrand Delacretaz commented on SLING-946: --- Tested a build on a Debian platform (instead of my mac) and all tests pass, so the problem is not the linux platform jcrinstall integration tests fail on our Hudson build server Key: SLING-946 URL: https://issues.apache.org/jira/browse/SLING-946 Project: Sling Issue Type: Bug Components: JCR Install Reporter: Bertrand Delacretaz Priority: Minor The jcrinstall integration tests in the http://hudson.zones.apache.org/hudson/view/Sling/job/sling-contrib-1.5 build fail with errors like java.io.FileNotFoundException: /home/hudson/hudson-slave/workspace/sling-contrib-1.5/contrib-1.5/launchpad/testing/target/launchpad-bundles/resources/bundles/15/cloned-bundles/observer_clone_1240993668015.jar For some reason, the tests cannot find the cloned bundles. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Releases in the future
Hi, On Mon, May 11, 2009 at 9:03 PM, Felix Meschberger fmesc...@gmail.com wrote: ...Basically, we will start releasing single bundles using the regular ASF release process. This should enable us to release much quicker than with big release we have done until now... +1, and if we could graduate soon that would make the release process faster ;-) ...For the consumer releases we are talking about 4 projects mainly: * launchpad/base - contains the launcher code, Felix framework and the OSGi core and compendium libraries. * launchpad/bundles - a very simple project to just pack together existing bundles * launchpad/app, launchpad/webapp - projects to create final app and web app from the base and bundles projects So to release a consumer product we update the launchpad/bundles project with all the bundles we want to include and prepare the releases of the launchpad/bundles, launchpad/app and launchpad/webapp projects Sounds good, and once we have a bundle repository in place, I could imagine changing the launchpad to be a minimal launcher shell, using a structured text file to define a list of bundles to load and maybe some configuration parameters. The empty shell would rarely or never change, maybe it wouldn't even contain the OSGi framework, but load it from URLs specified in the text file. That text file is maybe simply a script for the Felix shell or for Karaf (haven't looked at that closely yet). Future music...for now, I agree with what you suggest above - except maybe we shouldn't name those packages releases, I'll reply to Roy's comment about that. -Bertrand
Re: Releases in the future
On Mon, May 11, 2009 at 10:29 PM, Roy T. Fielding field...@gbiv.com wrote: On May 11, 2009, at 12:03 PM, Felix Meschberger wrote: Carsten and I have been reasoning about the releases in the future, mainly the ones for end-users who just want to grab a binary and fire it off Apache only releases source code packages. Those other things you build are not releases -- they are binaries that individuals build and upload. How about naming those things binary packages instead of releases? We can still use the same process for releasing them, and include a disclaimer that they're not official releases and provided without warranty etc.. That would help clarify things. -Bertrand
Re: [CONF] Apache Sling: Incubator Status Report (May 2009) (page edited)
Hi Felix, On Sat, May 9, 2009 at 10:14 PM, Felix Meschberger fmesc...@gmail.com wrote: ...Usually I copy it there just before the reporting deadline and mark the one here as read-only ... Ok, sorry about that. Copied the report back and made it read-only. -Bertrand conflue...@apache.org schrieb: Page Edited : SLING http://cwiki.apache.org/confluence/display/SLING : Incubator Status Report (May 2009) http://cwiki.apache.org/confluence/display/SLING/Incubator+Status+Report+%28May+2009%29 Incubator Status Report (May 2009) http://cwiki.apache.org/confluence/display/SLING/Incubator+Status+Report+%28May+2009%29 has been edited by Bertrand Delacretaz http://cwiki.apache.org/confluence/display/~bdelacretaz (May 08, 2009). (View changes) http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=116778originalVersion=4revisedVersion=5 Content: Report moved to http://wiki.apache.org/incubator/May2009^ Powered by Atlassian Confluence http://www.atlassian.com/software/confluence/default.jsp?clicked=footer (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request http://jira.atlassian.com/secure/BrowseProject.jspa?id=10470 Unsubscribe or edit your notifications preferences http://cwiki.apache.org/confluence/users/viewnotifications.action
[jira] Created: (SLING-959) NPE in webconsole/config
NPE in webconsole/config Key: SLING-959 URL: https://issues.apache.org/jira/browse/SLING-959 Project: Sling Issue Type: Bug Components: Console Reporter: Bertrand Delacretaz The Sling 5 release uses the Felix webconsole 1.2.8, which throws an NPE when accessing system/console/configMgr The root cause is FELIX-1028 The current workaround is to use a trunk build of the Felix webconsole - using the broken webconsole that's present in Sling 5 to update to that should work. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-960) Need webconsole smoke tests
Need webconsole smoke tests Key: SLING-960 URL: https://issues.apache.org/jira/browse/SLING-960 Project: Sling Issue Type: Test Components: Console Reporter: Bertrand Delacretaz Priority: Minor SLING-959 wasn't detected by our test suite, we should add some simple webconsole integration testing to catch such problems in the future. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Vote] Release Apache Sling 5 - webconsole config is broken
Hi, On Fri, May 8, 2009 at 6:14 PM, Ian Boston i...@tfd.co.uk wrote: I am seeing the following running the standalone launchpad with a clean build of the sling-5-incubator-source-release tag, (and a clear local repo for both o.a.sling and o.a.felix) should it be happening ? HTTP ERROR 500 ... java.lang.NullPointerException: Filter cannot be null at org.apache.felix.framework.FilterImpl.(FilterImpl.java:59)... Although there will soon be a workaround, having that in the release is ugly. And the fact that we missed it also indicates that something's missing in our release testing process - I have created SLING-960 about that. For now I have created SLING-959 - what do people think of releasing with that ugly bug? I know recutting and revoting on the release is a pain, so we might want to go ahead, as long as we document known issues with this release. Maybe a link to a JIRA query from http://incubator.apache.org/sling/site/downloads.cgi would be good, to display know issues in the current release and point to workarounds? -Bertrand
[jira] Commented: (SLING-960) Need webconsole smoke tests
[ https://issues.apache.org/jira/browse/SLING-960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12707996#action_12707996 ] Bertrand Delacretaz commented on SLING-960: --- I agree that it's not our business to test the webconsole itself, but when everybody votes +1 on a release without noticing that something as basic as the config console is broken, we have a problem. Those tests could manual tests part of a release test procedure document on the wiki, they don't necessarily need to be automated. Or we might contribute tests to the Felix project. Need webconsole smoke tests Key: SLING-960 URL: https://issues.apache.org/jira/browse/SLING-960 Project: Sling Issue Type: Test Components: Console Reporter: Bertrand Delacretaz Priority: Minor SLING-959 wasn't detected by our test suite, we should add some simple webconsole integration testing to catch such problems in the future. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Vote] Release Apache Sling 5
On Wed, May 6, 2009 at 5:33 PM, Carsten Ziegeler cziege...@apache.org wrote: ...I redid the release, which is not version 5 and we can vote again :)... I guess you mean *now* version 5 ;-) +1 on the release, details below. Signatures and digests verified. Tests with Maven version: 2.0.9, Java version: 1.5.0_16 on macosx 10.5.6. sling-5-incubator-source-release.tar.gz 2d3f26b986b12e4c3863c8352508cc6c sling-5-incubator-source-release.zip e60241ee568f76872684348690b069d5 Checked that those contain the exact same files. That source builds with mvn clean install after deleting the org/apache/sling in my local maven repository, but on my first build two tests failed in JspForwardTest (test result attached). Tried two more builds with no errors, didn't investigate more. The launchpad app: org.apache.sling.launchpad.app-5-incubator-bin.tar.gz bce9be4df9de0bb8e3f856dc83034fdb org.apache.sling.launchpad.app-5-incubator-bin.zip c96face22c569d5795ea549f729e2294 Checked that both contain the exact same files, which includes a useless nearly empty org.apache.sling.launchpad.app-5-incubator-sources.jar, no big deal. The runnable jar found in those passes all launchpad/testing integration tests, except those that use the launchpad/test-services bundle which is not present, that's correct. The launchpad webapp: org.apache.sling.launchpad.webapp-5-incubator.war e5e7acb1d7140f10e8247a4076ca094c Same test results as with the runnable jar, tested with tomcat 6.0.16. ...In addition I've built the corresponding maven artifacts of all modules... Didn't check those. Thanks for your work! -Bertrand --- Test set: org.apache.sling.launchpad.webapp.integrationtest.JspForwardTest --- Tests run: 5, Failures: 2, Errors: 0, Skipped: 0, Time elapsed: 3.07 sec FAILURE! testWithForward(org.apache.sling.launchpad.webapp.integrationtest.JspForwardTest) Time elapsed: 0.342 sec FAILURE! junit.framework.AssertionFailedError: Text of node A is not included (html body h1JSP template/h1 p class=mainText B 1241774350710/p h2Test 1/h2 ppathToInclude = /JspForwardTest/1241774350700/text_a_1241774350700/p pIncluding /JspForwardTest/1241774350700/text_a_1241774350700/p html body h1JSP template/h1 p class=mainText A 1241774350700/p h2Test 1/h2 h2Test 2/h2 h2Test 3/h2 h2Test 4/h2 /body /html h2Test 2/h2 h2Test 3/h2 h2Test 4/h2 /body /html ) at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.apache.sling.launchpad.webapp.integrationtest.JspForwardTest.testWithForward(JspForwardTest.java:112) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at junit.framework.TestCase.runTest(TestCase.java:168) at junit.framework.TestCase.runBare(TestCase.java:134) at junit.framework.TestResult$1.protect(TestResult.java:110) at junit.framework.TestResult.runProtected(TestResult.java:128) at junit.framework.TestResult.run(TestResult.java:113) at junit.framework.TestCase.run(TestCase.java:124) at junit.framework.TestSuite.runTest(TestSuite.java:232) at junit.framework.TestSuite.run(TestSuite.java:227) at org.junit.internal.runners.OldTestClassRunner.run(OldTestClassRunner.java:76) at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:62) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.executeTestSet(AbstractDirectoryTestSuite.java:140) at org.apache.maven.surefire.suite.AbstractDirectoryTestSuite.execute(AbstractDirectoryTestSuite.java:127) at org.apache.maven.surefire.Surefire.run(Surefire.java:177) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at
Re: [Vote] Release Apache Sling 5
On Fri, May 8, 2009 at 1:49 PM, Felix Meschberger fmesc...@gmail.com wrote: Hi, Ian Boston schrieb: We (other people in the Sakai community) have seen the same failures locally on one or two machines. It was thought to be down to other sling servers sitting on either port 8080, or but after stopping those instances and re-running the tests the passed and we didn't investigate further. BTW, this was a checkout of the tag and not a download of the release. Ian On 8 May 2009, at 11:24, Bertrand Delacretaz wrote: That source builds with mvn clean install after deleting the org/apache/sling in my local maven repository, but on my first build two tests failed in JspForwardTest (test result attached). Tried two more builds with no errors, didn't investigate more. This test is about whether forwarding in jsp works at all (this generally has no issue) and checking for the forward loop limit (this may occasionally fail, though I do not understand right now, why) In my tests it's not the loop test that failed, it's Text of node A is not included in testWithForward(), so include was not working. Wondering if this might have to do with some service not being completely started when the tests run. -Bertrand
Re: Use cases for bundle-based Jackrabbit customizations?
On Wed, May 6, 2009 at 2:49 PM, Ian Boston i...@tfd.co.uk wrote: At the moment we (Sakai) would might want to customze LoginModule and WorkspaceAccessmanager and need to customize SecurityManager so that we can get a custom DefaultAccessManager. ...At the moment, we have a big patch on the jackrabbit-server bundle, which IMHO is not sustainable. I think this might really be an issue for Jackrabbit rather than Sling. Happy to create a patch if it would help explain the detail I agree that this is more an issue for Jackrabbit in the end, but as several people seemed to have issues with that in Sling I thought here might be a good place to collect requirements. Creating a patch might be a good idea - even if it's supposed to go into Jackrabbit eventually, I think clarifying the issues here would be good. -Bertrand
Re: Use cases for bundle-based Jackrabbit customizations?
On Thu, May 7, 2009 at 12:46 PM, Jukka Zitting jukka.zitt...@gmail.com wrote:
...On Wed, May 6, 2009 at 11:33 AM, Bertrand Delacretaz
bdelacre...@apache.org wrote:
I'm trying to get an overview of the current issues related to
customizing an embedded Jackrabbit repository using Sling bundles.
Note that the current Jackrabbit configuration mechanism requires
direct access to all the *implementation* classes configured in the
repository.xml file. I'm not sure how this could best be made to work
with the cross-bundle class loading restrictions in an OSGi
environment...
One way that should work (didn't work before the recent upgrade of the
Felix framework) is to provide the customization classes in fragment
bundles that are attached to the jackrabbit server bundles. This makes
those classes available to that bundle exactly as if they were part of
the bundle.
Another option is to use dynamic imports in the jackrabbit server
bundle, and have the customization bundles export the implementation
classes.
Both the above solutions are suboptimal, but should allow Jackrabbit
extensions to come from different bundles.
I've had a look at https://issues.apache.org/jira/browse/JCR-1438
which is about using factories to instantiate the pluggable Jackrabbit
components, and I'm wondering if a central customizing method would
help, something like:
interface Customizer {
T getCustomizableComponentInstance(
Class T componentType, MapString, String options
}
Where standard Jackrabbit would use Class.forName() based on a
property in the options, and in an OSGi environment you'd plugin a
Customizer that grabs the appropriate OSGi service based on the type T
and options. Not sure if Jackrabbit requires Java 1.5 already, but it
not the idea can also work without generics.
-Bertrand
[jira] Commented: (SLING-931) Felix webconsole not restarted after upgrading via jcrinstall
[ https://issues.apache.org/jira/browse/SLING-931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12706318#action_12706318 ] Bertrand Delacretaz commented on SLING-931: --- In the above scenario, the jcrinstall service and its required bundles (runmode, jcrinstall.osgiworker) need to be installed and started. Felix webconsole not restarted after upgrading via jcrinstall - Key: SLING-931 URL: https://issues.apache.org/jira/browse/SLING-931 Project: Sling Issue Type: Bug Components: JCR Install Reporter: Bertrand Delacretaz After upgrading the Felix webconsole from 1.2.6 to 1.2.8 via jcrinstall, by copying the 1.2.8 bundle in a JCR repository folder that's watched by jcrinstall, the webconsole bundle is not restarted. AFAICS the failure scenario is: - jcrinstall updates the webconsole bundle and starts a package refresh -Several bundles that import the webconsole plugin interfaces are stopped and restarted -That causes more bundles to stop and restart, including eventually jcrinstall -As jcrinstall doesn't persist the list of bundles that must be restarted after the update, the webconsole restart is lost Steps to reproduce: Start the sling launchpad/app Install the Felix shell and shell text UI services (http://felix.apache.org/site/downloads.cgi) Install and start the Sling runmode and jcrinstall bundles. Uninstall the webconsole bundle using the Felix shell UI. Install and start the Felix webconsole 1.2.6 using the Felix shell UI. Refresh packages, from the Felix webconsole or shell. Try to install the Felix webconsole 1.2.8 via jcrinstall, by copying it in the repository under /libs/testing/install Result: /system/console does not display the console anymore After starting the console bundle from the Felix shell, things are back to normal -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Use cases for bundle-based Jackrabbit customizations?
Hi, I'm trying to get an overview of the current issues related to customizing an embedded Jackrabbit repository using Sling bundles. I tried to find the info in our archives but I'm not quite sure what the current status is. In an ideal world, I think it should be possible to use separate bundles to provide classes for all elements of the repository.xml configuration that have a class attribute. With the jackrabbit 1.5 repository.xml DTD, that would be the FileSystem, SecurityManager, LoginModule, WorkspaceAccessManager, PersistenceManager, SearchIndex, Journal, ISMLocking and DataStore. Now, in practice we might not need all of these things to come from separate bundles, as some customizations are not often needed. Could people give a quick description of their use cases that require customizing these things? Please also briefly indicate if/how that works now. The intention is to identify changes that we might need to make to the Jackrabbit bundles to enable those customizations. -Bertrand [1] http://jackrabbit.apache.org/jackrabbit-configuration.html
jcrinstall take three - OSGi-related tasks and priorities
Hi, I have refactored jcrinstall to use a separate bundle for all OSGi operations (SLING-904). This needs more work, but one thing that can be done now is to split the OSGi-related operations in smaller sequential tasks (one class per task type), executed in a specified order. I'm thinking of the following tasks, listed below in priority order - comments are welcome. Operations marked (*) are relevant for bundles only, others apply to both bundles and configurations. uninstall install or upgrade refresh packages (*) start (*) Configuration-related tasks will be executed before Bundle-related tasks. Notes: 1) Tasks sometimes need to be deferred for later execution. Configuration-related tasks, for example, cannot be executed if the (now optional) ConfigAdmin service is not present. 2) Multiple refresh packages tasks should be collapsed into a single one, executed after all pending install/upgrade/uninstall tasks, as shown above. 3) Before refreshing packages, the refresh packages task might create multiple start bundle tasks, one for each bundle that is currently active, to make sure those bundles are restarted after the refresh. 4) The worker thread execution loop needs to find out if new tasks have been added since the last loop iteration, and if that's the case walk the list of tasks to optimize it - for example changing install tasks to upgrade tasks if a bundle is already present, or merging multiple refresh packages tasks. Besides helping fix issues on which SLING-904 depends, all this should make the jcrinstall code simpler and easier to debug, especially as all tasks will be executed by a single worker thread. That's almost the case now, except that the OsgiController.executedScheduledOperations() method is still synchronous and creates a new thread every time. -Bertrand
Re: Registering Servlets and Filters
Hi, On Wed, May 6, 2009 at 11:12 PM, Andreas Kollegger akolleg...@tembopublic.org wrote: With the current Servlet Resolution wiki page out-of-sync, does anyone have a bare-bones example of registering a servlet and/or filter with the Sling framework?... The http://svn.apache.org/repos/asf/incubator/sling/trunk/launchpad/test-services/ example bundle contains a few servlets using different registration mechanisms. For filters, there's an example at [1]. -Bertrand [1] https://svn.eu.apache.org/repos/asf/incubator/sling/trunk/samples/simple-demo/src/main/java/org/apache/sling/sample/filter/ZipFilter.java
Sling board report draft (due May 13th)
Hi, See http://wiki.apache.org/incubator/May2009. Here's my suggested draft: Sling is a scriptable OSGI-based web framework that uses a Java Content Repository, such as Apache Jackrabbit, to store and manage content. Sling entered incubation on September 5th, 2007, and is actively preparing for graduation. There are no issues which require Incubator PMC or board attention at the moment. Community Lots of interest around Sling at ApacheCon in March, including fruitful discussions with people from the Sakai community who are starting to use Sling for a new version of their software, and starting to actively participate on our mailing lists. Meeting people from the Apache Felix and ServiceMix projects has helped build more community bridges around OSGi. Vidar Ramdal was elected as a committer and PPMC member. Juan José Vázquez Delgado, Sling committer since the start of incubation, became more active, contributed a pipelining module based on Cocoon 3, and is working on improved OSGi testing frameworks. Mike Mueller was granted write access to our wiki as a documentation committer, iCLA on file. In general, steadily increasing community activity with more contributions, discussions and patches. Mailing list stats (http://people.apache.org/~coar/mlists.html) also show a steady increase in subscribers, now at 130 subscribers and average of 17 posts/day on the sling dev list (there's no user list at the moment). Software Preparing the new release, awaiting imminent release of some dependencies to cut it. Continuous integration builds have been activated on hudson.zones.apache.org. Issues before graduation Sustained activity from at least two non-Day committers, along with the new release and increased community interest and engagement, seems to indicate that Sling should graduate soon. Licensing and other issues None -Bertrand
Re: Preparing the release
On Tue, May 5, 2009 at 10:35 AM, Felix Meschberger fmesc...@gmail.com wrote: snip cause=good stuff/ I agree with Felix. -Bertrand
Sling app -j option does not work (was: [jira] Closed: (SLING-954)...)
On Tue, May 5, 2009 at 12:08 PM, Felix Meschberger (JIRA) j...@apache.org wrote: ...Felix Meschberger closed SLING-954 I just tried this in launchpad/app, and java -jar target/org.apache.sling.launchpad.app-4-incubator-SNAPSHOT.jar -j says Unrecognized option j=j, although the -j option is provided in the usage message that follows. -Bertrand
Re: [IMP] Code freeze
On Tue, May 5, 2009 at 4:48 PM, Carsten Ziegeler cziege...@apache.org wrote: Ok, I'l start with the release process - I fear that this will take a little bit longer this time (until tomorrow I guess). Please refrain from committing stuff in the meantime It is ok to commit under contrib/extensions, right? -Bertrand
Re: Event Listeners
On Tue, May 5, 2009 at 5:04 PM, Carsten Ziegeler cziege...@apache.org wrote: Tobias Bocanegra wrote: sorry to bring this up again - but i'm a bit concerned that every JCR api functionality is duplicated in sling One of the aims of Sling is to make building apps on top of JCR easier. And the described functionality makes observation in many use cases easier. So it's not a duplication. It's a simplified interface. Is there a description of this new observation stuff somewhere? -Bertrand
Re: Hudson build is still unstable: sling-contrib-1. 5 » Apache Sling Launchpad Contrib Testing #13
On Mon, May 4, 2009 at 9:50 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: Hi, On Mon, May 4, 2009 at 8:27 AM, Carsten Ziegeler cziege...@apache.org wrote: Is it possible to configure Hudson to only send mails if the status changed? Yes, there's a Send e-mail for every unstable build option that's enabled by default. I've disabled it for now, but it would still be good to fix the build breakage. Thanks! The breakage is SLING-946, and that problem doesn't happen on my (macosx) box, so I'll have to investigate further - a java call to the bnd library is failing in the Hudson environment but works fine here, I'll try on a Linux box to see if I can reproduce the problem. -Bertrand
Re: Updated Hudson settings
On Mon, May 4, 2009 at 9:58 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: I've changed the Hudson settings a bit: Thanks! We're using https://issues.apache.org/jira/browse/SLING-920 to keep track of the Hudson setup, I have added your comments there. -Bertrand
[jira] Created: (SLING-952) ant task in dojo build does not use Maven proxy settings for downloading
ant task in dojo build does not use Maven proxy settings for downloading Key: SLING-952 URL: https://issues.apache.org/jira/browse/SLING-952 Project: Sling Issue Type: Bug Components: Extensions Reporter: Bertrand Delacretaz Priority: Minor The ant get task used in /contrib/extensions/dojo/pom.xml does not seem to use the current Maven proxy settings. Workaround is to download the dojo release file manually and place it in the download-cache folder. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-922) Load modules on startup from an external directory
[
https://issues.apache.org/jira/browse/SLING-922?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12705544#action_12705544
]
Bertrand Delacretaz commented on SLING-922:
---
...(3) The helper bundles are only provided as binaries.,,,I would probably
be more comfortable with the
source in SVN and creating the binaries during the test run (using the bnd
tool and ant script
for example). ..
FWIW, I'm doing something like this in the installClonedBundle() method of the
JcrinstallTestBase class [1]. The BundleCloner class uses bnd to create several
copies of test bundles with different symbolic names. See also SLING-946, for
some reason the bnd call currently fails on our Hudson build server.
[1]
http://svn.eu.apache.org/repos/asf/incubator/sling/trunk/contrib/launchpad/testing/src/test/java/org/apache/sling/launchpad/webapp/integrationtest/jcrinstall/JcrinstallTestBase.java
Load modules on startup from an external directory
--
Key: SLING-922
URL: https://issues.apache.org/jira/browse/SLING-922
Project: Sling
Issue Type: New Feature
Components: Launchpad, Launchpad Launcher
Reporter: Aaron Zeckoski
Assignee: Felix Meschberger
Attachments: binary-test-resources.zip, SLING-922.patch,
SLING922_fmeschbe.patch
Original Estimate: 72h
Remaining Estimate: 72h
Need a way to install and start bundles automatically from an external
directory (sling home) on startup. The ideas below are from the list.
--
I would like to be able to setup sling to start with a bunch of
installed bundles when it first is started. It seems like there are a
couple way to do this that I have found but neither is ideal:
1) Rebuild sling from source with the extra bundles in the launcher
pom (this seems to create a bunch of resources/# folders with bundles
in them)
2) Configure all bundles in the sling.properties file (this requires
the bundles to be in an accessible obr)
http://incubator.apache.org/sling/site/provisioning-and-startup.html
I would like to ideally do something in between like so:
Get a binary copy of the sling jar
Create a folder with sub-folders like /1 /10 /15
Put my bundles in the various subfolders
Configure sling.properties to point to the folder
Start sling and have all bundles in the sub-folders installed and started
- Aaron Zeckoski
===
Currently, as you say in (1), the BootstrapInstaller of the Sling
launchpad looks into its own resources enclosed in the JAR or WAR file
for bundles to install on startup.
How about extending this mechanism like this:
- Copy all bundles from enclosed resources to
${sling.home}/startup. This gives something like
${sling.home}/startup/0, /1, /10, /15, ...
Existing files are only replaced if the files
enclosed in the Sling launchpad jar/war file are
newer.
- Scan ${sling.home}/startup for bundles to install
in the same way as today the enclosed resources
are scanned directly.
So you could place your bundles in that structure and get them installed
at the requested start level (0 being default bundle start level).
A nice side effect of this is, that you can quickly see, which bundles
have been installed at all.
- Felix
=
I like this, and agree that this should replace the current mechanism.
How about adding a sling.properties option to completely ignore the
bundles that come from the Sling jar/war file? Might make it easier to
have precise control on what's installed.
-Bertrand
=
Maybe worth it to make this optional or controllable via a property in the
sling properties.
- Aaron Zeckoski
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Build failed in Hudson: sling-contrib-1.5 » Apa che Sling JCR OSGi Installer Service #15
On Mon, May 4, 2009 at 11:52 AM, Apache Hudson Server hud...@hudson.zones.apache.org wrote: See http://hudson.zones.apache.org/hudson/job/sling-contrib-1.5/org.apache.sling$org.apache.sling.jcr.jcrinstall/15/ My bad...just broke the tests ;-) -Bertrand
Re: Updated Hudson settings
On Mon, May 4, 2009 at 11:41 AM, Felix Meschberger fmesc...@gmail.com wrote: We're using https://issues.apache.org/jira/browse/SLING-920 to keep track of the Hudson setup, I have added your comments there. Shoudn't we document this on the Wiki or the Site ? We could, but a JIRA issue is a nice way to keep track of the history of our Hudson configurations. For now, Hudson is mentioned at http://incubator.apache.org/sling/site/project-information.html#ProjectInformation-ci with a link to that issue. -Bertrand
Re: Build failed in Hudson: sling-contrib-1.5 » Apa che Sling JCR OSGi Installer Service #17
On Mon, May 4, 2009 at 2:23 PM, Felix Meschberger fmesc...@gmail.com wrote: ...These are statements like: assertEquals(First install returns INSTALLED, INSTALLED, c.scheduleInstallOrUpdate(uri, data)); where the return value of scheduleInstallOrUpdate is being checked, which hopefully is flagged by the compiler because this method does not return anything since it is defined as public void Sure...I changed the return type this morning and did't change the tests. Shame on me ;-) -Bertrand
