Re: Mixed line endings.
Hi, On Thu, Apr 23, 2009 at 5:08 PM, Ian Boston i...@tfd.co.uk wrote: Isn't that normally put in ~/.subversion/config or does its presence there add it to the file of first commit ? Yes, all committers should have settings like http://www.apache.org/dev/svn-eol-style.txt in their Subversion config file. Then svn will automatically add the correct svn:eol-style properties when new files are added. should I be doing anything in git locally ? My patches contain ^M which doesn't look great :) I just added svn:eol-style settings to quite a few files in Sling. I'm not sure how well those settings are reflected in Git, but you may want to try rebasing your local changes to the latest changes from svn. BR, Jukka Zitting
Re: Content Technology track at the ApacheCon US 2009
Hi, On Mon, Apr 27, 2009 at 9:54 AM, Michael Wechner michael.wech...@wyona.com wrote: Jukka Zitting schrieb: The ApacheCon planners are asking for Apache projects to self-organize content for the upcoming ApacheCon US in November this year. It would be cool to have a track related to content repositories and content management. Jackrabbit and Sling would form a nice core for such a track, but we could also include sessions on things like Chemistry and other related projects. Maybe lenya devs could also participate Sure, that would be great! I didn't yet hear back from the conference planners about this. I'll ping them again. PS. I've created an initial planning page [1] for the proposed content track. [1] http://wiki.apache.org/jackrabbit/ContentTrackApacheConUs2009 BR, Jukka Zitting
Re: Content Technology track at the ApacheCon US 2009
Hi, On Thu, Apr 23, 2009 at 4:26 PM, Paolo Mottadelli paolo@gmail.com wrote: On Thu, Apr 23, 2009 at 2:58 PM, Paolo Mottadelli paolo@gmail.com wrote: I'm forwarding this message to the POI community, which is strongly willing to join some other project. I've just had a first positive feedback for POI joining the Content Track. Which is the time frame we have to manage in designing the proposal? Not sure. We just made the extended deadline last Thursday for expressing initial interest. AFAIK, once the conference planners respond with an OK, we have a few weeks to plan the program for the track. The plan will then be presented to the conference planners who make final decisions on the conference schedule. BR, Jukka Zitting
Re: Hudson build emails stuck in moderation?
Hi, On Tue, Apr 28, 2009 at 4:33 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: Our Hudson builds (SLING-920) are supposed to send email to sling-comm...@incubator.apache.org but I haven't seen any Hudson messages there. There should be a message this afternoon as the sling-trunk-1.5 build finally works (revision 769352 fixed it). Are any messages stuck in moderation by any chance? The commit mailing list only allows mail from @apache.org, so the messages from hud...@hudson.zones.apache.org never make it to the moderators. I'll see if I can explicitly allow hud...@hudson.zones.apache.org to post to sling-comm...@. BR, Jukka Zitting
Re: Hudson build emails stuck in moderation?
Hi, On Wed, Apr 29, 2009 at 9:38 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: I'll see if I can explicitly allow hud...@hudson.zones.apache.org to post to sling-comm...@. OK, done. Not sure if it works though, it could be that the @apache.org filter is applied before the normal moderation stuff. More generally, should we rather direct the Hudson posts to d...@? IMHO the commits@ list should be used only as a record of changes to svn and the web site. BR, Jukka Zitting
Re: Hudson build emails stuck in moderation?
Hi, On Wed, Apr 29, 2009 at 10:30 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: Right, and those messages are easy to filter anyway. I'll configure the notifications to send them here. Thanks. OK, good. I just added the required -allow rule for hud...@hudson.zones.apache.org to post also to sling-...@. BR, Jukka Zitting
Re: Sling Release
Hi, Ping. Anyone interested in pushing out a new release? BR, Jukka Zitting
Re: Sling Release
Hi, On Wed, Apr 29, 2009 at 2:53 PM, Felix Meschberger fmesc...@gmail.com wrote: Jukka Zitting schrieb: Ping. Anyone interested in pushing out a new release? I am not sure how interested he really is ;-) But IIRC Carsten agreed to stand in as the RM for it. Yeah, I saw that. Just pinging on whether we're still doing the release. BR, Jukka Zitting
Re: [VOTE] Update to Community Roles and Processes
Hi, On Thu, Apr 30, 2009 at 11:07 PM, Felix Meschberger fmesc...@gmail.com wrote: I think it is about time to put this draft on vote and accept or drop it. Would it be better to turn this first into a [DISCUSS] thread and restart the vote like a week later? We had discussion on this already last summer, but now that I look back to it, it happened on sling-priv...@. It would be good to get feedback and consensus also from the larger community (who are most affected by the policy change!) before nailing it down. BR, Jukka Zitting
Re: [VOTE] Update to Community Roles and Processes
Hi, On Fri, May 1, 2009 at 11:58 AM, Felix Meschberger fmesc...@gmail.com wrote: We can leave the vote open for more time, no problem with me. And we can continue to discuss. OK, thanks. +1 to the proposed changes, with a note that IMHO the division between committers and (P)PMC members should only be used to lower the barrier for committership, not to raise the barrier for (P)PMC membership. BR, Jukka Zitting
Re: JCR2 upgrade plans ?
Hi, On Thu, Apr 30, 2009 at 6:59 PM, Ian Boston i...@tfd.co.uk wrote: With JR trunk having branched 1.x off and now heading for 2.0. What plans, if any does Sling have for moving to 2.0 and 283 support? With my Jackrabbit release manager hat on I'd recommend that Sling wait until Jackrabbit 2.0 is officially out before upgrading to JCR 2.0. At current rate of things I would expect Jackrabbit 2.0 to be out sometime within the second half of this year. BR, Jukka Zitting
Re: JCR2 upgrade plans ?
Hi, On Mon, May 4, 2009 at 8:29 AM, Carsten Ziegeler cziege...@apache.org wrote: I think that Sling should be able to run on JCR 1.0 for a long time; we shouldn't tie us to a new version; however, of course we might have some optional functionality requiring JCR 2.0. From a functionality perspective JCR 1.0 already covers mostly everything Sling needs, though there are a few things in JCR 2.0 like the more flexible node type handling (setPrimaryType!) and improved query features that may be of interest to Sling. And regardless of the JCR API version, it probably makes sense for Sling to upgrade to Jackrabbit 2.x once it's available. BR, Jukka Zitting
Re: Hudson build is still unstable: sling-contrib-1. 5 » Apache Sling Launchpad Contrib Testing #13
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. BR, Jukka Zitting
Re: JCR2 upgrade plans ?
Hi, On Sun, May 3, 2009 at 7:10 AM, Felix Meschberger fmesc...@gmail.com wrote: In fact, many Jackrabbit libraries already come as bundles (jackrabbit-api, jackrabbit-jcr-commons, jackrabbit-jcr-rmi), why not the rest also ? Good question. Patches/commits are welcome. :-) There's already an issue reported for this (https://issues.apache.org/jira/browse/JCR-1991), but so far nobody has had the time or know-how to make this happen. I'd love to have OSGi metadata included already in Jackrabbit 1.6. BR, Jukka Zitting
Updated Hudson settings
Hi, I've changed the Hudson settings a bit: * Changed the svn poll interval from 15 minutes to 1 hour based on infra recommendation * Removed the timed nightly build option, as the build jobs are already executed whenever there are code or dependency changes. Extra nightly builds serve little purpose and only produce the still broken notifications that people find annoying. * Disabled the Send e-mail for every unstable build option for sling-contrib-1.5, though in light of the above changes I think it could (should?) be re-enabled. A still broken notification is IMHO quite useful when it's bound to actual changes that people commit. BR, Jukka Zitting
Re: Updated Hudson settings
Hi, One more change: * The sling-trunk-1.6 job is now only build after a successful sling-trunk-1.5. This way we won't get duplicate warnings (separately for 1.5 and 1.6) about broken builds. BR, Jukka Zitting
Re: [IMP] Code freeze
Hi, 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. During the release process the build will be broken as the it will reference artifacts which are not available in a public repo - but on my machine :) Branch? BR, Jukka Zitting
Re: [IMP] Code freeze
Hi, On Tue, May 5, 2009 at 5:09 PM, Carsten Ziegeler cziege...@apache.org wrote: Jukka Zitting wrote: Branch? We're not branching for a release; we only branch if really necessary. Why? Doing the release preparation in a branch would allow others to continue using trunk for normal development. I don't actively develop Sling, so my opinion carries little weight on this matter. I'm just curious about why you think branching is a bad idea. BR, Jukka Zitting
Re: [Vote] Release Apache Sling 5
Hi, On Wed, May 6, 2009 at 5:33 PM, Carsten Ziegeler cziege...@apache.org wrote: This is basically just one big release, so please cast your votes, the vote will be open for 72 hours. +1 Looks good. One comment going forward: The top level LICENSE and NOTICE files in the launchpad binaries do not cover the licensing information of all the code included in those packages. The embedded bundles in those packages seem to contain all the required licensing metadata (which is why I don't vote -1), but the top level files should at least point to this more detailed information. BR, Jukka Zitting
Re: Use cases for bundle-based Jackrabbit customizations?
Hi, 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. There's an ongoing effort in Jackrabbit to make the configuration handling more flexible (JCR-1438), with the ultimate goal of being able to configure Jackrabbit using OSGi services or an IoC container. I've already been able to implement parts of the issue (see the related commits in Jackrabbit), but there's still quite a lot of work remaining with the more complex configuration entries. BR, Jukka Zitting
Re: [Vote] Release Apache Sling 5 - webconsole config is broken
Hi, On Mon, May 11, 2009 at 11:26 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: 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. There'll never be a perfect release and in many cases having even a buggy release with known workarounds is much better than having no release at all. So I say we shouldn't cancel this release because of this issue. We can always create a new release as soon as the problem is solved. Release often! BR, Jukka Zitting
Re: [RT] Generic scriptable launcher
Hi, On Wed, May 13, 2009 at 4:57 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: 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. See below for a somewhat related experiment I recently did for launching Apache Tika using Maven 2 as the launch engine. Running mvn -f tika.xml exec:java would download all the required jars, set up the correct classpath and launch the configured main class. The interesting thing here is that the only essential part of the script below are the Maven coordinates of the tika-app jar. With a little bit of scripting you could boil the startup command down to something like mvnrun org.apache.tika tika-app 0.4-SNAPSHOT with no Tika-specific configuration files required. And such a tool could be used to download and launch any runnable jar (and the full set of dependencies) in the Maven repository. Of course this doesn't do any of the OSGi stuff, but as you mention, the OSGi startup could well be handled as a second stage. BR, Jukka Zitting tika.xml project xmlns=http://maven.apache.org/POM/4.0.0; xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance; xsi:schemaLocation=http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd modelVersion4.0.0/modelVersion groupIdorg.example/groupId artifactIdapplication/artifactId versionSNAPSHOT/version packagingpom/packaging build plugins plugin groupIdorg.codehaus.mojo/groupId artifactIdexec-maven-plugin/artifactId executions execution goals goaljava/goal /goals /execution /executions configuration mainClassorg.apache.tika.gui.TikaGUI/mainClass /configuration /plugin /plugins /build dependencies dependency groupIdorg.apache.tika/groupId artifactIdtika-app/artifactId version0.4-SNAPSHOT/version /dependency /dependencies /project
Re: [VOTE] Graduate Apache Sling as a top level project
Hi, [x] +1 Graduate as a top level project mentor hat on Day employees are still behind the majority of Sling commits, but the project has shown ability to welcome new ideas and contributors and to include them as equal members in the development and decision making processes. Also the other graduation criteria have been met and I don't think there's anything more that the Incubator can give to Sling. Thanks to everyone who's been participating so far, and good luck to Apache Sling as a standalone TLP! /mentor hat on BR, Jukka Zitting
Re: [VOTE] Release Apache Sling MIME type mapping support Version 2.1.0-incubator
Hi, Sorry for the late response... 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.tar.gz MD5: 216169b0341102f47546cfb15f1c13d3 SHA1: 924767432aac9ceeaf3534b7c91e369cf0343f3a So, please vote on this release: [x] +1 yes, release Looks good. PS. Do we really need so many -bin and -project packages? IMHO it would be simpler if we had just a single -project package and dropped all the -bin packages unless someone really needs them. BR, Jukka Zitting
Re: (In)Security in Sling
Hi, On Tue, May 26, 2009 at 5:15 PM, John Crawford craw...@gmail.com wrote: Is there a better way to handle this? Access control. BR, Jukka Zitting
Re: [CONF] Apache Sling Website: Discover Sling in 15 minutes (page edited)
Hi, On Fri, Apr 24, 2009 at 8:57 AM, conflue...@apache.org wrote: Reviewed 2009-09-24, this page's information is in sync with the current Sling codebase. As noted by Tako Schotanus in a chat, this does seem to prove that Sling's really the future! BR, Jukka Zitting
Google Analytics for the Sling web site
Hi, Jackrabbit is using Google Analytics to track usage of the jackrabbit.apache.org web site, and I was wondering if Sling would be interested in similar data. See [1] for an example report. [1] http://markmail.org/download.xqy?id=7xwz2anfrp4tfikonumber=1 BR, Jukka Zitting
Caching for ResourceResolver.map()
Hi, I have a case where we're doing lots of reverse mappings with the ResourceResolver.map() method and all the repository accesses caused by that are hurting performance. In general I'm not a big fan of extra caching, but in this case it seems like the only easy way to solve the problem. Would it make sense to embed such caching into JcrResourceResolver2 or should it rather be a separate add-on layer? The former approach would avoid complexities with the HttpServletRequest argument affecting the caching, while the latter would make it easier to only apply the caching in limited cases where it's truly needed (though at the cost of the cache not being global). BR, Jukka Zitting
Re: Caching for ResourceResolver.map()
Hi,
On Wed, Jun 10, 2009 at 3:10 PM, Carsten Ziegelercziege...@apache.org wrote:
While caching in the resource resolver might be a good idea anyway,
perhaps caching one layer above might give even more benefit. Instead
of querying the resource resolver a lot, caching above the resolver
would even avoid querying the resolver.
This turns out to be the best approach in my case. Especially since a
new ResourceResolver gets instantiated for each new request, which
makes it more difficult to add global caching.
However, since the resolution process depends on access rights, I
currently need to do something like this to include the potential
username in the cache key:
String user = ;
Session session = resourceResolver.adaptTo(Session.class);
if (session != null) {
user = session.getUserId();
}
This seems a bit fragile, so I was wondering if getting the username
from the request would work better:
String user = ;
Principal principal = request.getUserPrincipal();
if (principal != null) {
user = principal.getName();
}
I guess there are cases where the JCR Session (or whatever is used for
resource resolution) is authenticated using something else than the
user principal associated with the HTTP request.
Ultimately we should probably solve the performance issue on the
repository layer by making path lookups (especially negative ones)
blazingly fast. They're already pretty good in Jackrabbit, but for my
use case I'd need about an order of magnitude more performance. With a
simple high-level cache I was able to achieve this.
BR,
Jukka Zitting
Re: launchpad app Snapshot
Hi, On Thu, Jun 11, 2009 at 3:27 PM, Bertrand Delacretazbdelacre...@apache.org wrote: I haven't found any info about artifact attachments in the hudson docs or issue tracker, does anyone know more about that? Not really. Hudson does hook rather deeply into Maven so I would assume it to pick up any attached artifacts from the build, but apparently that's not the case here. It's always possible to tick off the deploy option from Hudson and instead configure the Maven build to use the normal deploy goal. The downside of this is the potential for partial deployments of multi-module projects. BR, Jukka Zitting
Re: Make our first release available on central Maven repo? (was: Problems with dependency paths)
Hi, On Fri, Jun 12, 2009 at 8:46 AM, Felix Meschbergerfmesc...@gmail.com wrote: My first try to would be to checkout the Sling 3 tag and deploy it to repository.apache.org setting the altDeploymentRepository property appropriately. I'd rather not do that, as then we'd have separate copies of the same artifacts with different checksums and signatures. We could ask the people at reposit...@apache.org to copy the existing artifacts from p.a.o to r.a.o. BR, Jukka Zitting
Re: SLING-490, SystemStatus service discussion
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? Additionally it could query jcrinstall for config status before starting to respond to HTTP requests. 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. PS. I've skipped most of the background for this, so I'm probably missing something essential here... Be gentle. :-) BR, Jukka Zitting
Re: Caching for ResourceResolver.map()
Hi, On Thu, Jun 11, 2009 at 3:08 PM, Felix Meschbergerfmesc...@gmail.com wrote: Not sure, whether it really is the best approach. Though it is true, that the ResourceResolver instance is created on each request, it is still created from the JcrResourceResolverFactory, which might as well be the holder of the cache and provide the user-specific subset of the cache to the per-request-ResourceResolver. I explored this idea a bit, and came up with a patch I submitted in SLING-1010. BR, Jukka Zitting
Re: git://git.apache.org/sling.git
Hi, On Fri, Jun 26, 2009 at 10:58 AM, Ian Bostoni...@tfd.co.uk wrote: Now that the svn repo has moved, has the git mirror been updated ? I have now updated the Git mirror to use the new svn location for new commits. BR, Jukka Zitting
[jira] Commented: (SLING-251) Add mapping for user homes
[ https://issues.apache.org/jira/browse/SLING-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569818#action_12569818 ] Jukka Zitting commented on SLING-251: - Is this a form of vanity URLs or an answer to a problem that has no other solution? In other words, what's the reason not to use http://host/home/tripod/test? Add mapping for user homes -- Key: SLING-251 URL: https://issues.apache.org/jira/browse/SLING-251 Project: Sling Issue Type: Improvement Components: Resource Reporter: Tobias Bocanegra it would be very practical to have a mapping to 'user homes'. i.e. like the unix tilde expansion: http://host/~/test would resolve to a resource: /home/tripod/test (if the request is authenticated as 'tripod'). i don't think that the reverse mapping is needed. the user home root resource (i.e. /home) needs to be configurable. possible default values for the user root are: /home /users /people but i prefer /home -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-251) Add mapping for user homes
[ https://issues.apache.org/jira/browse/SLING-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12569879#action_12569879 ] Jukka Zitting commented on SLING-251: - Couldn't we solve the same needs much more generally with a symlink mechanism? Add mapping for user homes -- Key: SLING-251 URL: https://issues.apache.org/jira/browse/SLING-251 Project: Sling Issue Type: Improvement Components: Resource Reporter: Tobias Bocanegra it would be very practical to have a mapping to 'user homes'. i.e. like the unix tilde expansion: http://host/~/test would resolve to a resource: /home/tripod/test (if the request is authenticated as 'tripod'). i don't think that the reverse mapping is needed. the user home root resource (i.e. /home) needs to be configurable. possible default values for the user root are: /home /users /people but i prefer /home -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-251) Add mapping for user homes
[ https://issues.apache.org/jira/browse/SLING-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12570341#action_12570341 ] Jukka Zitting commented on SLING-251: - Ah, I see what you mean. Is there a use case for user home URLs that don't contain the username? Add mapping for user homes -- Key: SLING-251 URL: https://issues.apache.org/jira/browse/SLING-251 Project: Sling Issue Type: Improvement Components: Resource Reporter: Tobias Bocanegra it would be very practical to have a mapping to 'user homes'. i.e. like the unix tilde expansion: http://host/~/test would resolve to a resource: /home/tripod/test (if the request is authenticated as 'tripod'). i don't think that the reverse mapping is needed. the user home root resource (i.e. /home) needs to be configurable. possible default values for the user root are: /home /users /people but i prefer /home -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-315) Groovy support
[ https://issues.apache.org/jira/browse/SLING-315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12576983#action_12576983 ] Jukka Zitting commented on SLING-315: - The problem regarding licensing I have is putting a binary from dev.java.net into the Apache SVN. It's fine as long as the license is acceptable and our LICENSE and NOTICE files are updated accordingly. The same rules apply also for releases that include such externally developed components. Groovy support -- Key: SLING-315 URL: https://issues.apache.org/jira/browse/SLING-315 Project: Sling Issue Type: New Feature Components: Scripting Affects Versions: 2.0.0 Environment: all Reporter: Christian Sprecher Priority: Minor Attachments: diff.txt, groovy-engine-1.0.jar, groovy.tar.gz Original Estimate: 48h Remaining Estimate: 48h Implement Groovy as an option for scripting language support. A patch with a possible implementation will be attached -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-539) Merge LICENSE.* information to LICENSE files
Merge LICENSE.* information to LICENSE files Key: SLING-539 URL: https://issues.apache.org/jira/browse/SLING-539 Project: Sling Issue Type: Improvement Components: General Reporter: Jukka Zitting Assignee: Jukka Zitting Fix For: 2.0.0 As discussed on the mailing list, we should merge third party license information from LICENSE.* files to the LICENSE files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-541) Clarify scripting/ruby licensing
Clarify scripting/ruby licensing Key: SLING-541 URL: https://issues.apache.org/jira/browse/SLING-541 Project: Sling Issue Type: Improvement Components: Scripting Reporter: Jukka Zitting The extensions/ruby component comes with the LICENSE.jruby file (which should be merged to LICENSE) and a jruby.codehaus.org notice, but I'm not sure if that covers everything included. The generated bundle contains lots of Ruby code and Java packages like com.sun.jna, jline, and org.joda.time that seem to come under different licenses. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-542) Clarify launchpad/jcrapp licensing
Clarify launchpad/jcrapp licensing -- Key: SLING-542 URL: https://issues.apache.org/jira/browse/SLING-542 Project: Sling Issue Type: Improvement Components: Launchpad Reporter: Jukka Zitting Priority: Minor The launchpad/jcrapp component doesn't come with correct LICENSE and NOTICE files to be included in the generated bundle. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-539) Merge LICENSE.* information to LICENSE files
[ https://issues.apache.org/jira/browse/SLING-539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved SLING-539. - Resolution: Fixed Resolving as Fixed with these followup issues: SLING-540: Clarify extensions/dojo licensing SLING-541: Clarify scripting/ruby licensing SLING-542: Clarify launchpad/jcrapp licensing Merge LICENSE.* information to LICENSE files Key: SLING-539 URL: https://issues.apache.org/jira/browse/SLING-539 Project: Sling Issue Type: Improvement Components: General Reporter: Jukka Zitting Assignee: Jukka Zitting Fix For: 2.0.0 As discussed on the mailing list, we should merge third party license information from LICENSE.* files to the LICENSE files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-540) Clarify extensions/dojo licensing
[ https://issues.apache.org/jira/browse/SLING-540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12605530#action_12605530 ] Jukka Zitting commented on SLING-540: - AFAIK all the code in Dojo should be OK for us to distribute, we just need to label it accordingly. It should be OK to cover this by including a generic look there for specific licenses and notices reference in the LICENSE and NOTICE files. But it would be good to review the stuff that's in there before publishing this bundle as a binary. Clarify extensions/dojo licensing - Key: SLING-540 URL: https://issues.apache.org/jira/browse/SLING-540 Project: Sling Issue Type: Improvement Components: Extensions Reporter: Jukka Zitting Priority: Minor The extensions/dojo component comes with the LICENSE_dojo file (which should be merged to LICENSE) and a The Dojo Foundation notice, but I'm not sure if that covers everything included. The LICENSE_dojo mentions: Some modules may not be the copyright of the Dojo Foundation. These modules contain explicit declarations of copyright in both the LICENSE files in the directories in which they reside and in the code itself. No external contributions are allowed under licenses which are fundamentally incompatible with the AFL or BSD licenses that Dojo is distributed under, so there shouldn't be any surprises but we may need to add something like a generic see the individual files for applicable copyright and license information clause to our LICENSE and NOTICE files. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-555) mvn install on svn checkout fails if sling-3-incubator is not available
mvn install on svn checkout fails if sling-3-incubator is not available --- Key: SLING-555 URL: https://issues.apache.org/jira/browse/SLING-555 Project: Sling Issue Type: Bug Components: General Reporter: Jukka Zitting Carsten recently (revision 670566) added the incubating repository to the parent POM in svn. But since many components refer to version 3-incubator (instead of 4-incubator-SNAPSHOT) as the parent POM, this repository reference is not picked up by the build. And if the 3-incubator version of the parent POM is not available in the local Maven repository, the build fails as Maven does not know where to download it from (since the components don't refer to 4-incubator-SNAPSHOT version of the parent POM...). Moving the repository reference to the reactor POM also won't help. The options I see are: 1) Make components use 4-incubator-SNAPSHOT as the parent POM version 2) Make the 3-incubator version of the parent POM explicitly available in svn 3) Add the incubator repository reference to all component POMs 4) Publish the 3-incubator version of the parent POM to the standard Maven repository -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-555) mvn install on svn checkout fails if sling-3-incubator is not available
[ https://issues.apache.org/jira/browse/SLING-555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12607255#action_12607255 ] Jukka Zitting commented on SLING-555: - As noted by Bertrand on the mailing list, we could also instruct people to add the incubating repository to the Maven configuration in ~/.m2/settings.xml. mvn install on svn checkout fails if sling-3-incubator is not available --- Key: SLING-555 URL: https://issues.apache.org/jira/browse/SLING-555 Project: Sling Issue Type: Bug Components: General Reporter: Jukka Zitting Carsten recently (revision 670566) added the incubating repository to the parent POM in svn. But since many components refer to version 3-incubator (instead of 4-incubator-SNAPSHOT) as the parent POM, this repository reference is not picked up by the build. And if the 3-incubator version of the parent POM is not available in the local Maven repository, the build fails as Maven does not know where to download it from (since the components don't refer to 4-incubator-SNAPSHOT version of the parent POM...). Moving the repository reference to the reactor POM also won't help. The options I see are: 1) Make components use 4-incubator-SNAPSHOT as the parent POM version 2) Make the 3-incubator version of the parent POM explicitly available in svn 3) Add the incubator repository reference to all component POMs 4) Publish the 3-incubator version of the parent POM to the standard Maven repository -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-633) RequestDispatcherOptions.setReplaceSelectors() doesn't work
RequestDispatcherOptions.setReplaceSelectors() doesn't work - Key: SLING-633 URL: https://issues.apache.org/jira/browse/SLING-633 Project: Sling Issue Type: Bug Components: Engine Environment: org.apache.sling.engine from revision 685501 Reporter: Jukka Zitting Priority: Minor As discussed on the mailing list (see http://markmail.org/message/fphyjdeb2oecjqdn), there is an issue when using the RequestDispatcher to include other components when the including component is addressed with a selector and the included component is not. Using the following code doesn't work as expected, the original (selector-dispatched) servlet is still invoked for the included resource: RequestDispatcherOptions options = new RequestDispatcherOptions(); options.setReplaceSelectors(); RequestDispatcher dispatcher = request.getRequestDispatcher(path, options); Could it be that an empty replacement string is treated as non-existent? Strangely enough the following code works, even though when addressing the resource directly in my browser, I get the same result with or without the .html suffix: RequestDispatcher dispatcher = request.getRequestDispatcher(path + .html); -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-877) Avoid calling Locale.getAvailableLocales() because it is very slow
[
https://issues.apache.org/jira/browse/SLING-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12678709#action_12678709
]
Jukka Zitting commented on SLING-877:
-
I would even question the need for the Locale.getISOLanguages() and
Locale.getISOCountries() calls in the method. A Locale instance is just an
identifier of the desired locale, so I'd argue that we should use the
user-specified value as-is without trying to filter or map it according to what
values the system may know about.
The method could well be something as simple as this:
String[] parts = localeString.split(_);
switch (parts.length) {
case 0: // empty locale string, use the default
return Locale.getDefault();
case 1: // only language
return new Locale(parts[0]);
case 2: // country is also available
return new Locale(parts[0], parts[1]);
case 3: // language, country and variant
default: // ... and skip everything after that
return new Locale(parts[0], parts[1], parts[2]);
}
Avoid calling Locale.getAvailableLocales() because it is very slow
--
Key: SLING-877
URL: https://issues.apache.org/jira/browse/SLING-877
Project: Sling
Issue Type: Improvement
Components: Extensions
Reporter: Thomas Mueller
Attachments: JcrResourceBundleProvider.patch
Currently, JcrResourceBundleProvider.toLocale calls
Locale.getAvailableLocales().
The first call to this method is very slow (3.4 seconds on my machine) because
it scans many jar files.
http://svn.apache.org/viewvc/incubator/sling/trunk/bundles/extensions/i18n/src/main/java/org/apache/sling/i18n/impl/JcrResourceBundleProvider.java?view=markup
It looks like calling this method is not required.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-941) Lots of svn:eol-style settings missing
Lots of svn:eol-style settings missing -- Key: SLING-941 URL: https://issues.apache.org/jira/browse/SLING-941 Project: Sling Issue Type: Improvement Components: General Reporter: Jukka Zitting The Sling trunk has lots of files with missing svn:eol-style settings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SLING-941) Lots of svn:eol-style settings missing
[ https://issues.apache.org/jira/browse/SLING-941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting resolved SLING-941. - Resolution: Fixed Assignee: Jukka Zitting I fixed all the missing svn:eol-styles I could find. Lots of svn:eol-style settings missing -- Key: SLING-941 URL: https://issues.apache.org/jira/browse/SLING-941 Project: Sling Issue Type: Improvement Components: General Reporter: Jukka Zitting Assignee: Jukka Zitting The Sling trunk has lots of files with missing svn:eol-style settings. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SLING-920) Hudson continuous integration setup
[ https://issues.apache.org/jira/browse/SLING-920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12705520#action_12705520 ] Jukka Zitting commented on SLING-920: - One more change * The sling-trunk-1.6 job is now only build after a successful sling-trunk-1.5. This way we won't get duplicate warnings (separately for 1.5 and 1.6) about broken builds. Hudson continuous integration setup --- Key: SLING-920 URL: https://issues.apache.org/jira/browse/SLING-920 Project: Sling Issue Type: Task Components: Testing Reporter: Bertrand Delacretaz Use this issue to record changes to the Hudson continuous environment setup at http://hudson.zones.apache.org/hudson/view/Sling/ -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SLING-1010) Add cache to speed up resolution of missing JCR resources
Add cache to speed up resolution of missing JCR resources - Key: SLING-1010 URL: https://issues.apache.org/jira/browse/SLING-1010 Project: Sling Issue Type: Improvement Components: JCR Resource Reporter: Jukka Zitting Priority: Minor As recently discussed [1], I'm trying to speed up resolution of resources that don't exist. The resource resolution algorithm in Sling is very powerful, but it also needs to look at many different paths when a particular resource does not exist. I've implemented a simple cache that is designed to work around this performance issue until the speed of such negative repository path lookups has improved. [1] http://markmail.org/message/wlamd7xvagaexmzu -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SLING-1010) Add cache to speed up resolution of missing JCR resources
[ https://issues.apache.org/jira/browse/SLING-1010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jukka Zitting updated SLING-1010: - Attachment: MissingPathCache.patch Attached the proposed patch (against bundles/jcr/resource). Note that I haven't yet run too many performance tests to justify this cache. I have a very specific use case where the effect is quite noticeable, but I'm not yet sure how well this works in general (it's a source of some extra lock contention, there may be observation and memory overheads that I'm overlooking, etc.). The cache also only works properly if the installation only accesses a single workspace and no namespace remappings are used. Due to these concerns the cache is disabled by default and there's a configuration option for enabling it if needed. Add cache to speed up resolution of missing JCR resources - Key: SLING-1010 URL: https://issues.apache.org/jira/browse/SLING-1010 Project: Sling Issue Type: Improvement Components: JCR Resource Reporter: Jukka Zitting Priority: Minor Attachments: MissingPathCache.patch As recently discussed [1], I'm trying to speed up resolution of resources that don't exist. The resource resolution algorithm in Sling is very powerful, but it also needs to look at many different paths when a particular resource does not exist. I've implemented a simple cache that is designed to work around this performance issue until the speed of such negative repository path lookups has improved. [1] http://markmail.org/message/wlamd7xvagaexmzu -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
