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] 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.
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: 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: 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: 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
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
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
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
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: [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: [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: [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] 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: 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
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: [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: 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
[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.
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: 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: 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
[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.
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
Content Technology track at the ApacheCon US 2009
Hi, [Sorry again for cross-posting, perhaps we should set up a jcr-interest@ mailing list somewhere] 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. The planners would like an indication of interest ASAP, so I will contact them about this if people think it's a good idea. In previous ApacheCons we've typically had a few related presentations and a BoF session or a Meetup. Based on that I think we could well organize something like a half-day track of presentations and workshops followed by a more informal community meetup in the evening. BR, Jukka Zitting
Re: Mixed line endings.
Hi, On Thu, Apr 23, 2009 at 4:43 PM, Ian Boston i...@tfd.co.uk wrote: does anyone else see the same in SVN [...] Yes, the files don't have svn:eol-style settings. BR, Jukka Zitting
Re: Content Technology track at the ApacheCon US 2009
Hi, See below for the proposal that I sent to the conference planners. BR, Jukka Zitting The Jackrabbit and Sling projects would like to organize a Content Technology track at the ApacheCon US 2009. The track would be focused on content repositories and content management based on the JCR and CMIS standards. We estimate that we could do something like a half-day track followed by a more informal meetup in the evening. This would be a natural extension to the meetups and normal sessions we've had in previous ApacheCons. We could also enlarge the scope of the track to cover a wider range of projects like Cocoon, Lenya, Portals, POI, etc. in which case the track could cover even something like 1-2 days. However, such plans are mostly speculative at the moment. The target audience of this track would mostly consist of web developers and CMS (both web and enterprise) developers and integrators. We might also do a more business-oriented session on the current status of standardization in the content management industry.
Re: SLING-880
Hi, On Thu, Apr 23, 2009 at 10:59 PM, Vidar Ramdal vi...@idium.no wrote: Being a new committer, I'm not sure how everything is supposed to be done. Can we (that is, I) apply the patch in SLING-880 [1], or does it need a review or a vote or something first? Sling uses the CTR policy (commit-then-review, [1]) so you're free to commit anything that you think is good for the project. If people disagree, they may then ask you to revert or revise the change (don't worry if this happens to you, it's just a sign that people pay attention and that you're pushing the limits :-). If you're working on some part of the code that you're not yet very familiar with or you're otherwise not sure whether a change you're about to make really works as expected, then you can voluntarily ask people to review the patch before you commit it. If you don't hear from anyone in a few days, then you can typically just assume lazy consensus and go forward with the commit. [1] http://www.apache.org/foundation/glossary.html#CommitThenReview BR, Jukka Zitting
Security in Sling
Hi, I was thinking about the implications of giving a user write access to a subtree of the repository. With that access the user could now upload a new script and create a node that invokes that script when rendered. What if the script contains something like System.exit(1)? Or something even more malicious? Do we have mechanisms for preventing attack scenarios like that? BR, Jukka Zitting
Re: Security in Sling
Hi, On Wed, Apr 22, 2009 at 12:40 PM, Torgeir Veimo torg...@pobox.com wrote: The servlet container usually have default security policies defined, which can easily be changed. Eg for tomcat, look at conf/catalina.policy. What would such a policy file look like, i.e. what codeBase should be used and what permissions granted? Also, I'm not sure how easy it would be to apply the Java security policies to things like ESP scripts. BR, Jukka Zitting
Re: Security in Sling
Hi, On Wed, Apr 22, 2009 at 2:22 PM, Tobias Bocanegra tri...@day.com wrote: System.exit() bears IMO no real risk, since it can be prevented by java security. I'd like to see the relevant java security settings. With all the OSGi stuff, JCR bundle loading, and script compiling in place I think coming up with a correct security policy is a major undertaking. Do we want to go down that path, or use alternative means like the proposed script resolution restrictions? BR, Jukka Zitting
Re: Hudson build fails to deploy sling-builder-4-incubator.pom, any clues?
Hi, On Wed, Apr 15, 2009 at 1:52 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: The Hudson build that I configured yesterday fails to deploy that pom to repository.apache.org, see error message below, details at [1] . Before I ask on the reposit...@apache.org list, does anyone have an idea what's going wrong? It's not a SNAPSHOT? BR, Jukka Zitting
Re: Experiment with the Hudson CI service, who wants an account?
Hi, On Wed, Apr 8, 2009 at 4:30 PM, Vidar Ramdal vi...@idium.no wrote: Is using Hudson part of some ASF policy? No. There are a number of different CI tools at use within Apache (Hudson, Continuum, Gump, etc.). Each project is free to choose what works best for them. It's even possible to request a project-specific Solaris zone for running custom build tools, but I'd recommend sticking with one of the generic CI servers to avoid the overhead of maintaining and documenting a custom setup. BR, Jukka Zitting
Re: [POLL] getting rid of scripting (almost)
Hi, +1 Good proposal! We don't want all those script kiddies ruining the good name of Sling 2.0.0 Enterprise Edition, S2EE. On Wed, Apr 1, 2009 at 10:05 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: With one exception, maybe...due to its inherent type safety, and available enterprise-level tooling, JSP is probably the only scripting language that deserves to stay. I would suggest that we only allow JSP documents using the XML syntax. Those pesky % characters are evil as noted also by Vidar in a different thread. Also, I propose that we disable the jsp:scriptlet/ element. All such code should be placed in tag libraries as proper Java classes. BR, Jukka Zitting
Re: How about renaming the bundles source code folder to core ?
Hi, On Tue, Mar 31, 2009 at 3:31 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: The names of the subfolders at the top of the Sling source code tree all make sense to me, except bundles: My rationale for the bundles name was that there we have all the OSGi bundles included in a normal Sling deployment. Renaming it to core would sound a bit strange to me, as we have stuff like all the extensions and scripting languages in there. BR, Jukka Zitting
Re: Public snapshots, javadocs and CI
Hi, On Tue, Mar 31, 2009 at 4:29 PM, Bertrand Delacretaz bdelacre...@apache.org wrote: I assume we need the artifacts created by our continuum server [1] to be pushed somewhere when the builds are successful, but I'm not sure how to set that up. RTFM links are welcome of course. The easiest way to do that is to use the new repository.apache.org server. See https://issues.apache.org/jira/browse/INFRA-1896 and related links for background. BR, Jukka Zitting
Re: Welcome Vidar Ramdal as our new Sling committer!
Hi, On Mon, Mar 30, 2009 at 11:11 AM, Bertrand Delacretaz bdelacre...@apache.org wrote: As a result, the Sling PPMC and the Incubator PMC recently voted to make Vidar a committer on Sling. Gratulerer og velkommen til teamet, Vidar! BR, Jukka Zitting
JCR meetup at 8pm on Tuesday
Hi all, I'd like to confirm the meetup schedule that has been discussed over various forums. Most notably, unlike originally planned the meetup will start at *8pm* on Tuesday, March 24th. See http://wiki.apache.org/jackrabbit/JcrMeetupMarch2009 for more details about the event. If you are in Amsterdam or nearby on Tuesday evening next week, you're welcome to join us to discuss all things JCR. The meetup is free for everyone to attend, but please sign up in advance at https://spreadsheets.google.com/viewform?formkey=cDFlMTdSV3dKT1lkYUlVa2lWUFdkQXc6MA. The meetup takes place at the Mövenpick hotel in central Amsterdam (Google map: http://tinyurl.com/da2rf3). I don't know yet the exact floor or room where the meetup takes place, but check the ApacheCon posters at the hotel for guidance. You can also call me at +41 76 417 56 70 if you have trouble finding your way there. See you there! BR, Jukka Zitting
Sling javadocs?
Hi, Something I look for every now and then. Do we have the javadocs of a) the latest trunk and b) the release up somewhere? BR, Jukka Zitting
Re: JCR/Sling meetup in Amsterdam, confirmed? (was: sling for apachecon site)
Hi, The latest sign up figures look more promising and we've secured sponsors for the meetup, so let's go forward with the event. To reduce the conflict with the Lucene meetup that at least a few of us would like to attend and to give late arrivals a better chance to attend the JCR meetup, I suggest that we start the meetup only at 8pm instead of the originally planned 7pm. BR, Jukka Zitting
Re: JCR/Sling meetup in Amsterdam, confirmed? (was: sling for apachecon site)
Hi, On Wed, Mar 18, 2009 at 12:33 PM, Vidar Ramdal vi...@idium.no wrote: On Wed, Mar 18, 2009 at 12:03 PM, Jukka Zitting jukka.zitt...@gmail.com wrote: To reduce the conflict with the Lucene meetup that at least a few of us would like to attend and to give late arrivals a better chance to attend the JCR meetup, I suggest that we start the meetup only at 8pm instead of the originally planned 7pm. On Tuesday 24th, right? Yes. BR, Jukka Zitting
Re: JCR/Sling meetup in Amsterdam, confirmed? (was: sling for apachecon site)
Hi, What's the general feeling about the meetup? There hasn't been too much enthusiasm on the signup page. I'd personally rather not overlay the JCR and Lucene meetups, and the Tuesday evening is already pretty crowded with the committers reception also taking place. Having the meetup on Monday would further detract from the number of attendees. So, I would in fact rather skip the meetup and focus all the energy to a larger BOF session. WDYT? Felix already proposed a Sling BOF in http://wiki.apache.org/apachecon/BirdsOfaFeatherEu09, and I guess we could expand the scope of the BOF to cover also Jackrabbit and other JCR topics. The downside of a BoF is that it's only open to ApacheCon attendees whereas a meetup would be open to everyone. BR, Jukka Zitting
[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.
Re: [VOTE] Source Tree Restructuring
Hi, +1 Looks good to me. BR, Jukka Zitting
Re: JCR meetup in Amsterdam?
Hi, On Fri, Feb 13, 2009 at 10:55 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: On Thu, Feb 12, 2009 at 11:05 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: The meetup will only happen if we can find enough attendees, presentations and sponsors. Please let me know, preferably already by the end of this week, if you'd be interested in participating. As was pointed out in private, I didn't leave any place for people to sign up. I just created a wiki page for that, see [1]. You can also email me in private if you like. [1] http://wiki.apache.org/jackrabbit/JcrMeetupMarch2009 Thanks for everyone who's already signed up on the wiki or in private email! However, we're still short of enough interest to make the meetup worth organizing. So please let me know if you're considering attending. If we can't find enough interest, we'll do just a normal BoF session at the ApacheCon. BR, Jukka Zitting
Re: JCR meetup in Amsterdam?
Hi, On Thu, Feb 12, 2009 at 11:05 AM, Jukka Zitting jukka.zitt...@gmail.com wrote: The meetup will only happen if we can find enough attendees, presentations and sponsors. Please let me know, preferably already by the end of this week, if you'd be interested in participating. As was pointed out in private, I didn't leave any place for people to sign up. I just created a wiki page for that, see [1]. You can also email me in private if you like. [1] http://wiki.apache.org/jackrabbit/JcrMeetupMarch2009 BR, Jukka Zitting
JCR meetup in Amsterdam?
Hi, [cross-posting since this is for both Jackrabbit and Sling people] Last year we had a JCR meetup event during the ApacheCon in Amsterdam [1]. Now there's a chance of doing one again this year during the ApacheCon at the end of March [2]. The three-hour event would take place in the evening either on Monday 23rd or on Tuesday 24th. The location is the Mövenpick hotel in central Amsterdam. The meetup will only happen if we can find enough attendees, presentations and sponsors. Please let me know, preferably already by the end of this week, if you'd be interested in participating. [ ] I'd like to attend on Monday, March 23 [ ] I'd like to attend on Tuesday, March 24 Presentations can be anything JCR-related and may last between five minutes and about half an hour. [ ] I'd like to present X on Monday, March 23 [ ] I'd like to present X on Tuesday, March 24 The event will be free for everyone to attend, but we still need to cover the rent of the meeting room and other related costs. To cover these costs we're looking for companies to sponsor the event. Sponsoring is not expensive, and by sponsoring you get to support the Jackrabbit and Sling projects and get your name attached to the event. You can contact me for more details. [1] http://wiki.apache.org/jackrabbit/JcrMeetupApril2008 [2] http://www.eu.apachecon.com/c/aceu2009/ BR, Jukka Zitting
Re: Source Tree Structure
Hi, On Thu, Feb 12, 2009 at 8:26 AM, Carsten Ziegeler cziege...@apache.org wrote: Please keep in mind that Sling is a very modular system consisting mainly of a variety of bundles. Sling has the intent to separately release single modules (bundles). This is one of the number one priorities for Sling - the big bang releases are just for convenience. OK. I just want to make it easy for a Sling user to grasp what a given release (or a trunk checkout) is about. For example, if I have all these individual component releases, how do I combine them to get a functional Sling installation? Perhaps we should better highlight the Sling Launchpad releases as the base that you need to get started, and other component releases as something that you can deploy to upgrade an already existing Sling installation. Both the current and the proposed layouts make the Launchpad look like just another OSGi bundle, and you'll need to dig deep into the READMEs to figure out how to get started. How about structuring the top level of the source tree like below to make the Launchpad components more prominent? trunk/ +--- parent/ +--- launchpad/ +--- bundles/ +--- contrib/ +--- examples/ +--- tests/ The bundles directory would contain all the bundles included by default in the Launchpad, and the contrib directory would contain other components that we don't think are ready yet for inclusion in the default installation. We could still group similar bundles together using subdirectories inside the bundles and contrib directories. BR, Jukka Zitting
Re: Sling board report is due February 11th
Hi, Looks good to me, thanks! BR, Jukka Zitting
Memory usage of the Sling build
Hi, Did we ever come up with a real solution as opposed to a workaround to the problem with Sling builds requiring lots of memory? I'm hitting a similar issue with Eclipse Ganymede (with the m2eclipse plugin), where my memory usage shoots up to 1-2GB (and possibly higher, but I use -Xmx2GB) quickly after I import and build the Sling components. I have Eclipse workspaces with 50+ open Maven projects in them working fine with 500MB memory, so this shouldn't be just about the number of Sling components. BR, Jukka Zitting
Re: Memory usage of the Sling build
Hi, On Wed, Jan 21, 2009 at 11:17 AM, Felix Meschberger fmesc...@gmail.com wrote: What you might try is omit the jackrabbit-server module from your build and check to see, whether this is really the culprit (of which I am pretty sure, though). OK, I'll try that for now. Thanks! BR, Jukka Zitting
Re: Board Report
Hi, On Wed, Nov 12, 2008 at 7:55 AM, Felix Meschberger [EMAIL PROTECTED] wrote: Report [1] is on file [2]. Excellent, thanks! BR, Jukka Zitting
Re: Replacing JcrResourceResolverFactory by a Sling ResourceResolverFactory
Hi, On Sun, Nov 9, 2008 at 7:11 PM, Felix Meschberger [EMAIL PROTECTED] wrote: My proposal is to add a first-class Sling service interface called ResourceResolverFactory which allows you to get a ResourceResolver instances in one single shot. The proposed ResourceResolverFactory looks pretty much like javax.jcr.Repository. The proposed credentials map defaults look like javax.jcr.SimpleCredentials and the workspaceName argument to Repository.login(). (BTW, what have things like workspace and session hints to do with credentials?) The proposed ResourceResolver.close() method is like Session.logout(). I find it troubling that Sling is reinventing JCR. This looks like a symptom that JCR is not optimal for the things Sling wants to do. From an architectural perspective I'd rather focus on improving JCR than layering extra levels of abstraction on top of it. BR, Jukka Zitting
Re: Trying to upload a package in CRX from dev to test... getting error
Hi, On Tue, Sep 30, 2008 at 8:52 AM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: Note that [1] explains how to update crx with the latest bleeding edge Sling stuff. On that note, should we make another Sling release? BR, Jukka Zitting
Re: Test
Hi, On Tue, Sep 9, 2008 at 9:26 AM, [EMAIL PROTECTED] wrote: Please ignore This is already the second test message from from you. If you need to test, please set up a test mailing list for that instead of spamming all members of this list! BR, Jukka Zitting
Re: Annoyance during update of bundles
Hi, On Fri, Aug 29, 2008 at 8:33 PM, Tobias Bocanegra [EMAIL PROTECTED] wrote: how about stalling requests until the update is complete ? That would also make startup time when a number of bundles are just being loaded much more predictable. Currently you just need to wait a while until all bundles are in place, otherwise you get various different failures when you try to access your application. BR, Jukka Zitting
Re: Capturing component output
Hi, On Wed, Aug 27, 2008 at 11:07 PM, Felix Meschberger [EMAIL PROTECTED] wrote: I have now fixed the wrong method. Maybe you can test again ? Thanks. OTOH, thinking again, I don't think, that the wrong response wrapper should have any influence here hmm, strange. Yeah, the behaviour is the same regardless of whether I use HttpServletRequestWrapper or SlingHttpServletRequestWrapper. BR, Jukka Zitting
[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.
Re: Capturing component output
Hi, On Wed, Aug 27, 2008 at 2:37 PM, Jukka Zitting [EMAIL PROTECTED] wrote: What am I doing wrong? I chatted with Felix and was able to resolve the issue. I'm using a selector to dispatch requests to my servlet component, and that selector is carried down in the request where it causes the RequestDispatcher to select my servlet again for processing the target resource. The preferred solution for fixing this would have been: RequestDispatcherOptions options = new RequestDispatcherOptions(); options.setReplaceSelectors(); RequestDispatcher dispatcher = request.getRequestDispatcher(path, options); ... but for some reason that didn't work (perhaps because the replace string is empty?). See SLING-633 for the related bug report. The somewhat surprising workaround I came up with for now is to add an extra suffix: RequestDispatcher dispatcher = request.getRequestDispatcher(path + .html); The funny thing is that in my browser I get the same output regardless of whether I address the target resource with or without the .html suffix. But for some reason adding it to the getRequestDispatcher() call affects the end result. BR, Jukka Zitting
Re: Sling component structure
Hi, On Fri, Jun 27, 2008 at 1:44 PM, Felix Meschberger [EMAIL PROTECTED] wrote: Yep. And a second one would be to separate them into multiple bundles covering mutiple areas of Sling, probably. My call for reducing the number of bundles seems to have failed miserably. ;-) BR, Jukka Zitting
Re: Sling component structure
Hi, On Thu, Jun 26, 2008 at 12:25 PM, Felix Meschberger [EMAIL PROTECTED] wrote: I do not envision weekly releases of single components. But there may well be one or two releases (or more) per month, yes. We also have this over at Felix and it works quite well. OK. I'm just wondering how it looks to a potential end user. Looking at the Felix download and news pages, it's quite difficult to determine whether an end user needs to care about all that. A release is not just an artifact pushed to the Maven repository, but also related stuff like release notes and relevant documentation updates. Each release should come at least with enough information to tell a user whether they should upgrade and what the effects will be if they do. I would only consider merging if it would make sense on a code-wise basis. Merging to simplify release management is IMHO wrong and bad. How about merging to simplify end user experience? Unless we can somehow automate upgrades (wouldn't it be cool if bundles and all the dependencies were automatically downloaded from the Maven repository... :-), our users could well end up manually managing a complex dependency tree. At least we should document the component dependencies somewhere. In the end, we should make everything a bundle. This enables all use cases, import and embedding. Because, remember: A bundle basically is just a JAR with special manifest headers. The bigger difference is how they are presented to the user in a running system. For example, on the web console, does it make sense that for example commons-collections can be individually removed or upgraded? How aware the end user should be of all the inter-component dependencies? IMHO, the fewer dependencies the user needs to worry about the better. For example, say I have a component that uses some fancy new Map implementation in a recent commons-collections release. When a user deploys my component, it would be nice if she didn't need to also worry about the commons-collections version. IMHO the same reasoning applies also to things like commons/json. BR, Jukka Zitting
Re: Building current trunk requires http://people.apache.org/repo/m2-incubating-repository
Hi, On Mon, Jun 23, 2008 at 6:05 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: FYI, building revision 670645 requires declaring the m2-incubating-repository, as the modules depend on the released sling parent POM, which does not contain the required repository definition. You noticed the same thing. :-) See SLING-555. BR, Jukka Zitting
[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.
Re: [Vote] Release Apache Sling
Hi, On Tue, Jun 17, 2008 at 1:26 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: it's that special time again! I've cut a new candidate to vote on. You'll find the releases at: http://people.apache.org/~cziegeler/releases/sling/releases [...] This is basically just one big release, so please cast your votes, the vote will be open for 72 hours. +1 Looks good. Thanks for the great work (and for addressing my previous concerns)! I checked the signatures, built and tested the code (on RHEL 4, Sun Java 1.5.0_10, Maven 2.0.9), checked the LICENSE and NOTICE files, etc. Everything OK. BR, Jukka Zitting
[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.
Re: License and notice files
Hi, On Mon, Jun 16, 2008 at 3:11 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On Mon, Jun 16, 2008 at 1:59 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Jukka Zitting wrote: ...d) Many of the generated bundles don't have complete NOTICE files (for example commons.log doesn't mention SLF4J even though SLF4J classes are included), but I wouldn't treat that as a blocker as the bundles are secondary release artifacts and the required information is still available in the LICENSE.* files. Great. Again these are things where Roy said we don't need them Jukka, are you talking about the NOTICE files under src/main/resources, i.e. the ones that get included in the binary artifacts? Yes. BR, Jukka Zitting
Re: License and notice files
Hi, On Mon, Jun 16, 2008 at 3:44 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: Jukka Zitting wrote: This is also my understanding, i.e. we should include the attribution in NOTICE. Ok, so please go ahead and just add it - i'm fine with that. OK. Actually if we can have everything at a single place seems to be easier for me. If you could just add the stuff, that would be great. OK, I'll do that. BR, Jukka Zitting
[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.
Re: Releasing tomorrow morning
Hi, On Mon, Jun 16, 2008 at 4:58 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: So if you have any outstanding issues please fix them or at least bring them up by tomorrow morning. I've now merged all the license information to LICENSE files (SLING-539) and updated the META-INF/NOTICE files to cover all included dependencies. See [1] for all the related changes. I also filed some followup issues: SLING-540: Clarify extensions/dojo licensing SLING-541: Clarify scripting/ruby licensing SLING-542: Clarify launchpad/jcrapp licensing None of these is a blocker for the release, but we may want to avoid pushing those bundles to the Maven repository. [1] https://issues.apache.org/jira/browse/SLING-539?page=com.atlassian.jira.plugin.ext.subversion:subversion-commits-tabpanel BR, Jukka Zitting
Re: License and notice files
Hi, On Thu, Jun 12, 2008 at 1:45 PM, Felix Meschberger [EMAIL PROTECTED] wrote: In Rev. 667038 I just commited a proposal to commons/log bundle [1] to what we have been discussing: Looks good. - The disclaimer is not part of the README.txt (yet), maybe this should be added as a section there replacing the existing DISCLAIMER file ? +1 - The src/main/resources/META-INF(LICENSE file has no reference to the LICENSE.slf4j file The LICENSE.* files seem pretty obvious, so I'm not sure if the reference is really needed. I'd say we either leave it as is (no references), or include all the license information in the single LICENSE file. - The src/main/resources/META-INF/NOTICE file contains an attribution of the SLF4J libraries. As I can see no requirement for such an attribution, I am not sure, whether this is required ? The license calls for the copyright notice [...] shall be included in all copies or substantial portions of the Software, and AFAIUI (and I may be wrong) the NOTICE file is the place for such copyright notices even when they are also included in the LICENSE file. PS. I looked at doing the same for the launchpad app and webapp components. Do we really need the separate -bin packaging, or could we just use the normal jar and war artifacts as the binary packages to go with the release? BR, Jukka Zitting
Re: License and notice files
Hi, On Thu, Jun 12, 2008 at 10:03 AM, Roy T. Fielding [EMAIL PROTECTED] wrote: On Jun 11, 2008, at 10:43 PM, Jukka Zitting wrote: PS. Of course, we could do just a source release to get started... :-) Once again, with feeling... the ASF only does source releases. Sure, but as long as Carsten plans to publish also the binary packages we should make sure that those binaries come with proper LICENSE and NOTICE files. BR, Jukka Zitting
Re: License and notice files
Hi, On Thu, Jun 12, 2008 at 7:46 AM, Roy T. Fielding [EMAIL PROTECTED] wrote: I am struggling to understand what is going on here. LICENSE and NOTICE refer to the copyrightable material in *this* package. Surely we don't distribute Derby and Xerces in *this* package, do we? Jetty? WTF? We do. The tricky thing with Maven is that even though the source release doesn't contain the dependencies, the build result still ends up containing them. Thus we have things like the Sling app and Sling webapp binaries that come with all the dependencies inside them. Also, to make matters even more interesting, AFAIK the plan is to also make each individual bundle artifact (some with, some without included dependencies) available in the Maven repository, so we should have proper NOTICEs also for those bits. I raised the generic issue on legal-discuss@ (see [1]) to gather feedback on how to best handle that complexity. [1] http://markmail.org/message/bttmkavpicxxg7gl PS. Of course, we could do just a source release to get started... :-) BR, Jukka Zitting
Re: [Vote] Release Sling
Hi, On Fri, Jun 6, 2008 at 12:01 PM, Jukka Zitting [EMAIL PROTECTED] wrote: -1 until we clarify whether we can actually use the JSON code, see [1] and [2]. I just realized the potential issue when reviewing the licenses. As mentioned in [2] there seems to be an alternatively licensed version of the code that we might need to switch to. [1] http://markmail.org/message/gglluph3ifuyqiwq [2] http://markmail.org/message/nzyximv23dvncnai As discussed in [1], the consensus on legal-discuss seems to be that the license is OK for us, so I'm lifting this -1. However, we should do something about the top level NOTICE and LICENSE files, so I'm still -1 on the release as-is. Also, it worries me that things like the W3C copyright and license information from the jackrabbit-core dependency are nowhere mentioned. Is it expected that users should go through two levels of jar packaging to find all the relevant license and copyright information? Other than that I think the release looks good. I checked the following artifacts: 75eb13ce016cc059888de8838e7a501e sling-2.0.0-incubator-release.tar.gz 2a92c3bb2d054e838acdc023c8bf843a org.apache.sling.launchpad.app-2.0.2-incubator-bin.tar.gz 83b4e9de62baf44612a9208595322f3b org.apache.sling.launchpad.webapp-2.0.2-incubator.tar.gz BR, Jukka Zitting
Re: VOTE CANCELLED [was Re: [Vote] Release Sling]
Hi, On Tue, Jun 10, 2008 at 11:45 AM, Carsten Ziegeler [EMAIL PROTECTED] wrote: So I hereby cancel the vote to fix these remaining issues. Thanks! Once we're finished I would like that some people check the NOTICE files *before* I cut a new release. It would be great, Jukka, if you could check them at that point as well. I'll do that. BR, Jukka Zitting
Re: [Vote] Release Sling
Hi, On Mon, Jun 9, 2008 at 10:31 AM, Greg Klebus [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 6:32 PM, Carsten Ziegeler [EMAIL PROTECTED] wrote: let's give it a second try. I cut a new candidate as outlined today. I was just wondering where we are with the release, given licensing concern(s) pointed out by Jukka. Could we expect the release in the next couple of days? The consensus on legal-discuss@ seems to be that we can include the JSON code in Sling, i.e. the Good, not Evil condition is not a FOU clause that we need to worry about. I'll wait until tomorrow and lift my -1 unless anyone objects on legal-discuss. Anyway, my -1 on the aggregate LICENSE and NOTICE files still stands, IMHO we need to fix those before we release. I'll continue my review today to see if there's something else we should fix. BR, Jukka Zitting
Re: [sling-scala commit] r10 - in trunk/scala-standalone: . src
Hi, On Fri, Jun 6, 2008 at 10:25 AM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: I have setup the GSoC google code project commits to be sent here, but I see that's too noisy, I'll stop that now. Is anyone opposed to using [EMAIL PROTECTED] for those notifications? Since we're using sling-commits for commit notifications and SLING Jira for tracking progress, could we also grant Janandith limited commit access to sling svn? Two practical reasons: a) The google code commit notifications seem to use a bounce detection mechanism that prevents the sender address to be permanently allowed to bypass moderation, causing all commit messages to be individually moderated. b) If and when the code becomes a part of Sling proper, it would be nice if we could keep the full svn history. The easiest way to do that is to have the code in sling svn right from the beginning. BR, Jukka Zitting
Re: [Vote] Release Sling
Hi, -1 until we clarify whether we can actually use the JSON code, see [1] and [2]. I just realized the potential issue when reviewing the licenses. As mentioned in [2] there seems to be an alternatively licensed version of the code that we might need to switch to. [1] http://markmail.org/message/gglluph3ifuyqiwq [2] http://markmail.org/message/nzyximv23dvncnai BR, Jukka Zitting
Re: [Vote] Release Sling
Hi, On Fri, Jun 6, 2008 at 12:21 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 11:17 AM, Jukka Zitting [EMAIL PROTECTED] wrote: ...Also, -1 for the inadequate NOTICE and LICENSE files in the app and webapp packages. The files may be correct for the individual bundles contained in the packages (didn't yet check too carefully), but IMHO it's even more important that the aggregate files are in proper shape What do you mean by inadequate? If we consider that the app and webapp include all other bundles, their NOTICE files should be the aggregate of all bundle's NOTICEs (avoiding repeats of course), is that what you mean? Yes. The top level NOTICE and LICENSE files should contain information about the licensing and copyright status of everything included in the package. As a bare minimum they should at least refer to the information inside the bundles. BR, Jukka Zitting
Re: [Vote] Release Sling
Hi, Also, -1 for the inadequate NOTICE and LICENSE files in the app and webapp packages. The files may be correct for the individual bundles contained in the packages (didn't yet check too carefully), but IMHO it's even more important that the aggregate files are in proper shape. BR, Jukka Zitting
Re: [sling-scala commit] r10 - in trunk/scala-standalone: . src
Hi, On Fri, Jun 6, 2008 at 12:58 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: On Fri, Jun 6, 2008 at 9:34 AM, Jukka Zitting [EMAIL PROTECTED] wrote: ...Since we're using sling-commits for commit notifications and SLING Jira for tracking progress, could we also grant Janandith limited commit access to sling svn?... That would be nice, do you think Apache infrastructure currently allows that? We discussed that on infrastructure-dev some while ago, see [1], and at least there infra didn't have objections, see especially [2]. [1] http://markmail.org/message/x5qkbqzgsvqamzfw [2] http://markmail.org/message/muhpgalbo3tmgnqy BR, Jukka Zitting
Contributor account (Was: [sling-scala commit] r10 - in trunk/scala-standalone: . src)
Hi, On Fri, Jun 6, 2008 at 1:47 PM, Bertrand Delacretaz [EMAIL PROTECTED] wrote: I see the idea, and as the mentor I'd be ready to sponsor Janandith as a partial committer in a specific whiteboard area or our subversion repository (after he provides an ICLA, which should be on its way). I didn't really get how that's setup though, can you clarify, or let me know what's needed to make this happen? I'd call for a vote first, of course. Pretty much like adding a normal committer, the only differences would be in restricting the scope of committership (no PPMC membership and perhaps with time or access restrictions, like only for the summer and/or just the whiteboard area). The commit vote should mention these restrictions. Once voted, the account request to infra would be just like any other committer account request. Once the account is ready, the svn-authorization file would be updated according to the selected access restrictions. BR, Jukka Zitting
