[RESULT] [VOTE] Retire the Graffito project
Hi, On 6/1/07, Jukka Zitting [EMAIL PROTECTED] wrote: So, please vote on retiring the Graffito project. The result of this vote, if positive, will be used as a recommendation to the Incubator PMC to formally retire Graffito. The following votes were cast (* indicates a member of the Graffito PPMC) in the past two weeks: +1 Christophe Lombart * +1 Jukka Zitting * +1 Oliver Kiessler * +1 Carsten Ziegeler +0 David Sean Taylor * This vote is now closed and the consensus is to retire the project. I will ask the Incubator PMC to formally retire Graffito. BR, Jukka Zitting
Re: [RESULT] [VOTE] Retire the Graffito project
Hi, On 6/15/07, Sandro Böhme [EMAIL PROTECTED] wrote: I also voted with +1. Thanks for the reminder! Your original vote doesn't seem to have made it to the mailing list, see http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/200706.mbox/browser. With your vote the tally is: +1 Christophe Lombart * +1 Jukka Zitting * +1 Oliver Kiessler * +1 Carsten Ziegeler +0 David Sean Taylor * +1 Sandro Böhme * BR, Jukka Zitting
Re: [VOTE] Retire the Graffito project
Hi, On 6/1/07, Jukka Zitting [EMAIL PROTECTED] wrote: So, please vote on retiring the Graffito project. [x] +1, retire the Graffito project [ ] -1, do not retire the Graffito project It's unfortunate to see the project becoming dormant, but I guess retiring it is the best option for now. There are a number of good ideas in the codebase that I hope will live on in Jackrabbit, Portals, and other interested projects. BR, Jukka Zitting
[VOTE] Retire the Graffito project
Hi, As discussed before, now that the JCR mapping component has been moved to the Jackrabbit project I propose to retire the Graffito project from the Apache Incubator. The Graffito codebase would be moved to dormant state from where it can still be resurrected if renewed interest appears. So, please vote on retiring the Graffito project. The result of this vote, if positive, will be used as a recommendation to the Incubator PMC to formally retire Graffito. [ ] +1, retire the Graffito project [ ] -1, do not retire the Graffito project BR, Jukka Zitting
Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit
Hi, On 4/25/07, ruchi goel [EMAIL PROTECTED] wrote: Did not get the non-binding part of the vote ?? Everyone is welcome to participate in the vote and normally all votes are heard, but in tight cases only votes from the PMC members are binding to the project. For example if someone outside the Graffito PPMC had cast a non-binding -1 vote I would certainly have considered tabling the issue until more consensus is achieved, but a binding -1 vote from a Graffito committer would have vetoed the motion regardless of my opinion. BR, Jukka Zitting
Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit
Hi, On 4/23/07, Christophe Lombart [EMAIL PROTECTED] wrote: tha's ok now. We can move the code. OK, thanks. I've now moved the codebase to: http://svn.apache.org/repos/asf/jackrabbit/trunk/contrib/jackrabbit-jcr-mapping I just did a svn move from .../incubator/graffito/trunk/jcr, so the build scripts are a bit broken at the moment, but I'll look into that later today. I also moved all the open JCR Mapping issues into the Jackrabbit project in Jira. See the jcr-mapping component in the Jackrabbit project. Christophe is now a Jackrabbit committer, so he should have write access also the new location in subversion. Christophe, can you do a test commit to check that everything works fine? As for the future development of the JCR mapping component, I would like to welcome everyone who is interested to join the Jackrabbit development mailing list and to continue any related discussions there. BR, Jukka Zitting
Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit
Hi, On 4/25/07, Alexandru Popescu ☀ [EMAIL PROTECTED] wrote: I know I haven't committed anything in Graffitto for the last months, but this was mainly because I was not agreeing with its direction at the time, and I was clearly saying that I am still interested in only OCM. Having in mind the InfoQ is probably the biggest application using OCM I would definitely like to preserve my commit role on the OCM project. I believe the Jackrabbit PMC would be happy to have you on board. For now we looked at the recent commit activity when selecting who should be invited as a committer along with the codebase, but anyone who shows renewed activity will probably receive committer status very quickly based on earlier contributions. BR, Jukka Zitting
[RESULT] [VOTE] Move JCR Mapping to Jackrabbit
Hi, On 4/17/07, Jukka Zitting [EMAIL PROTECTED] wrote: As already discussed, I'd like to formally propose moving the JCR Mapping codebase and related pieces of code (http://svn.apache.org/repos/asf/incubator/graffito/trunk/jcr/) to the Apache Jackrabbit project. Please vote on whether to move the codebase. The vote is open for the next 72 hours, with binding votes from the Graffito PPMC. The vote passes with five binding +1 votes and three non-binding +1 votes. As the parallel vote on the Jackrabbit mailing list also passed, I will now proceed to move the codebase. The binding votes were: +1 Sandro Böhme +1 Christophe Lombart +1 Oliver Kiessler +1 Alexandru Popescu +1 Jukka Zitting The non-binding votes were: +1 Ruchi Goel +1 Felix Meschberger +1 Carsten Ziegeler BR, Jukka Zitting
Re: [RESULT] [VOTE] Move JCR Mapping to Jackrabbit
Hi, On 4/23/07, Christophe Lombart [EMAIL PROTECTED] wrote: I have some stuff to commit (probably at the end of the day). Can we wait until tomorrow ? If not, I will make changes in the new svn repo. No problem, there's no rush to get this done. Just ping me when you're ready. Meanwhile I'll try to figure out if we can move the open JCR Mapping issues over to the Jackrabbit project in Jira. BR, Jukka Zitting
Re: Graffito update
Hi, On 4/17/07, ruchi goel [EMAIL PROTECTED] wrote: I have some enhancements to be committed to jcr-mappng. Do you suggest that I should be doing it only after it gets moved to Jackrabbit project ? No need to wait, just submit your enhancements to the Graffito issue tracker. I'm not yet sure how in practice we'll transition JCR mapping issues in Graffito to Jackrabbit, but I'm confident that we'll find a way that isn't too disruptive. BR, Jukka Zitting
[VOTE] Move JCR Mapping to Jackrabbit
Hi, As already discussed, I'd like to formally propose moving the JCR Mapping codebase and related pieces of code (http://svn.apache.org/repos/asf/incubator/graffito/trunk/jcr/) to the Apache Jackrabbit project. Please vote on whether to move the codebase. The vote is open for the next 72 hours, with binding votes from the Graffito PPMC. I will call a parallel vote on the Jackrabbit PMC to accept the codebase. The move will happen only if both votes pass. [ ] +1 Move JCR Mapping to Jackrabbit [ ] -1 Do not move the component because ... Here's my +1 BR, Jukka Zitting
Graffito update
Hi, [Cc:ing [EMAIL PROTECTED] as the sponsoring PMC of Graffito, please follow up on graffito-dev] The time for a Graffito report is again coming up. My thoughts on the current status: * JCR Mapping: I unfortunately haven't had as much time as I would have wanted to push for a release of the JCR Mapping component, but there's still been activity thanks to Christophe, Felix, and Ruchi. I still think there's enough activity and interest to move the component into a Jackrabbit subproject. * Graffito: The rest of the Graffito project has seen no activity since the status discussions two months ago. Based on this I'd be ready to recommend terminating the Graffito project as dormant once the JCR Mapping component has been moved to Jackrabbit. Comments? BR, Jukka Zitting
Re: Graffito update
Hi, On 4/11/07, Evangelos Vlachogiannis [EMAIL PROTECTED] wrote: Does this mean that there wont be any portal CMS? The code is still there, but as of now it doesn't seem like there's too much interest in the idea. Does Jackrabbit include any JSR168 CMS portlet that can be used with Jetspeed2? No, at least not currently. BR, Jukka Zitting
Re: Graffito update
Hi, On 4/11/07, Christophe Lombart [EMAIL PROTECTED] wrote: When do you want to move the jcr mapping components into Jackrabbit? I originally wanted to push for a release of the component to get a clear baseline that the rest of the Graffito project could continue using until we get the component integrated in the regular Jackrabbit release process. But if we are to retire Graffito as dormant then having the release out is not so important. I'll poll the Jackrabbit PMC for opinions on how to best proceed with the move. BR, Jukka Zitting
Re: Graffito update
Hi, Thanks for the comments! Based on the feedback I've prepared the following report: report Graffito is a framework for content-based applications, especially in portlet environments. Graffito entered incubation on September 20, 2004. Despite recent efforts the level of activity within the Graffito project remains low. The only part of the project that enjoys continued interest and commit activity is the JCR Mapping component, whose transfer into a subproject of Apache Jackrabbit is being prepared. There is little indication that the level of activity within other parts of the Graffito project would increase in future, so we will most likely request termination of the project as dormant as soon as the JCR Mapping component has been moved to Apache Jackrabbit. /report BR, Jukka Zitting
Re: [Fwd: javadocs for Jackrabbit1.2 API]
Hi, On 3/1/07, ruchi goel [EMAIL PROTECTED] wrote: Christophe Lombart wrote: You should ask this kind of question on the Jackrabbit mailing list. I did , but did not get any response on jackrabbit alias. My bad, I was setting up the javadocs online but got distracted. I'll reploy on the Jackrabbit list when they're available. BR, Jukka Zitting
Re: dtd for custom_nodetypes.xml
Hi, On 2/26/07, ruchi goel [EMAIL PROTECTED] wrote: OK. But if you want to check if a nodetype is already registered, ( and reregister or do not register depending on your requirement) , you still need to iterate and register nodes one by one.So, what s the advantage of manager.registerNodeTypes(xml, JackrabbitNodeTypeManager.TEXT_XML); as opposed to ntReg.registerNodeType(def); I understand that manager.registerNodeTypes(xml, JackrabbitNodeTypeManager.TEXT_XML); can register in one shot , but may be it is a good idea to use it at the end of development , when you know you will not be registering or reregistering the nodes again and again. You could achieve the same effect by putting each additional node type (or set of them) in a new node type definition file. But you're right, the JackrabbitNodeTypeManager interface is (intentionally) not as powerful as the underlying NodeTypeManagerImpl and NodeTypeRegistry classes. The problem with your approach is that it requires explicit care from the node type definition writer to put the definitions in such an order that any dependencies between types are correctly ordered and that there are no circular dependencies. Another problem is that there are no guarantees that the internal methods (or their semantics) remain the same across Jackrabbit releases, as we only guarantee backwards compatibility for the JCR API and the extension interfaces defined in jackrabbit-api. More generally, the node type management support in Jackrabbit is still quite limited, i.e. you're restricted to just adding new types and making only trivial changes to existing types. Thus, during development I generally recreate the entire test repository when I need to make changes to my node type definitions. Obviously this is a poor solution when you need to upgrade production repositories. :-( BR, Jukka Zitting
Re: Graffito status followup
Hi, On 2/14/07, Christophe Lombart [EMAIL PROTECTED] wrote: Before starting the refactoring, I would like to be sure that everybody is agreed. Can we summarize like this : +1, sounds good to me. * Framework means a series of components/services that can be running alone (or integrated into specific applications). The framework offers also an integration with other existing frameworks/components. We might want to consider applying the OSGi component model in Graffito to help integration with other tools. * The persistence layer will use the OCM tools to map java classes into a JCR repo. * A tools is required to register a new class definition into a JCR repo. When registring a new java class, this tools will create the corresponfing node types. Register a new content java class has to be as simple as register a new jcr node type. There's a jcr-classloader component in Jackrabbit contribs that might come in handy. I'd also be interested in investigating options for content-to-object mappings as opposed to object-to-content mappings. I.e. could we automatically expose JCR content as Java objects (instead or in addition to JCR Nodes) to enable effortless integration with various JavaBean tools. BR, Jukka Zitting
Re: using jcr-mapping layer to access repsitory over RMI
Hi, On 2/14/07, ruchi goel [EMAIL PROTECTED] wrote: If I tweak the jcr-mapping layer to access a remote jcr repository, I should be still able to use jcr-mapping layer. Please confirm. I guess it should not be a problem , except for that custom node type registration should be done at the server end. Yes, I think this should work. Please file a bug report if it doesn't. :-) BR, Jukka Zitting
Re: Graffito status followup
Hi, On 2/13/07, Christophe Lombart [EMAIL PROTECTED] wrote: Following my previous mail, I would like to know if it is ok for everybody. As you can see, the scope is very high and I would like to start more details on the first point : Graffito Core. Sounds good to me. a. Graffito Core : all necessary low-level services to define, store, manage, audit, request and search content. If needed, it can give an access to different heterogenous content servers (JCR and propriatary servers). Graffito core have to be extensible. For example, a workflow service could be added into Graffito Core. Personally I'm most interested in a pure JCR solution, but a pluggable storage layer is also fine. What I'm most interested in at this level is the content model. Currently Graffito has a predefined set of Document and other content types, but also uses generic bean persistence. Should the Graffito Content Model be fixed by better specifying the core content interfaces, or should the Graffito Core support arbitrary content objects? BR, Jukka Zitting
JCR Mapping release
Hi, I'd like to push for the release of the JCR Mapping tool as a precondition of the discussed move to the Apache Jackrabbit project. To get started I suggest we create a target release like 0.9 in Jira and use it to track all the issues that should be solved before the release. Browsing quickly through the current JCR Mapping issues it seems that at least the following would be good candidates for a release: GRFT-40 Advanced support for JCR properties and node GRFT-72 Bug in org.apache.portals.graffito.jcr.persistence.atomictypeconverter.impl.UtilDateTypeConverterImpl GRFT-74 Provide Readme's for subprojects jcr-mapping and jcr-nodemanagement GRFT-84 ObjectConverterImpl wrong behavior when manipulating autoCreate and protected properties GRFT-99 ManageableCollectionUtil should not throw unsupported JcrMapping exception GRFT-106 Avoid INFINITE RECURSION when Object Model has cycles. I have some spare cycles over the next few weeks, so I can participate in making things happen. BR, Jukka Zitting
Graffito status followup
Hi, The ASF board asked us to report again this month on the outcome of the project status discussion we had recently. It seems that there's marked interest in the project, but as of now not much is happening. I'd like to resume the discussion and hopefully arrive in a conclusion that we could include in the next Incubator report. There was talk about better componentization of the project. What could this mean in practice? My view is that currently Graffito is more designed as a full framework rather than a set of independent components. Would it make sense to revisit this design decision, and what would be the amount of required vs. available effort for doing something like that? And more fundamentally, what would be the requirements and use cases for more independent components? Alternatively, assuming we keep the current architecture, what could be done to encourage and enable a more active community? Are there technical obstacles for trying out and adopting Graffito, do we need more documentation, or would some other measures help? I personally have some issues (discussed last autumn) with the current design which makes Graffito less appealing for some webapp projects I've been thinking of. I also found it a bit hard to grasp the underlying idea of Graffito, there is no clear metafor or a similar explanation of what Graffito is really about. It might be just me, but if similar views are more common, that might explain the low level of adoption we are still seeing. BR, Jukka Zitting
Re: JCR Mapping release
Hi, On 2/2/07, Christophe Lombart [EMAIL PROTECTED] wrote: ok good points. I will try to help. What about the doc for this release. I'm currently reviewing it. We should have at least proper readmes (GRFT-74) and check that the existing site documentation is up to date with the latest changes. Other than that I think the documentation is pretty good for an initial release. BR, Jukka Zitting
Re: Graffito status
Hi, On 1/10/07, Jukka Zitting [EMAIL PROTECTED] wrote: Pinging the mailing list for opinions on what to include in the Graffito status report. Thanks all for comments and ideas! See the end of this message for the report I drafted based on the discussion. BR, Jukka Zitting Graffito is a framework for content-based applications, especially in portlet environments. Graffito entered incubation on September 20, 2004. Top three items to resolve before graduation: 1. Build a self-sustaining community 2. Create an incubating Graffito release 3. Move the JCR mapping component to the Jackrabbit project There hasn't been much activity in the Graffito project since the last report. A discussion on what to do with the project that still hasn't reached critical mass after over two years of incubation is currently taking place. The perceived complexity of the project is seen by many as a barrier to start using or contributing to Graffito. Splitting the project into more manageable component projects was raised as one potential approach to reviving the codebase and project community.
Graffito status
Hi, Pinging the mailing list for opinions on what to include in the Graffito status report. I'm still interested in seeing the JCR mapping component migrated to Jackrabbit, but what about the rest of the project? Should we do something to try building a more active community around the project? The alternative would be to look at retiring the project. BR, Jukka Zitting
[jira] Resolved: (GRFT-95) Follow the new copyright and license guidelines
[ http://issues.apache.org/jira/browse/GRFT-95?page=all ] Jukka Zitting resolved GRFT-95. --- Resolution: Fixed Updated the existing license headers and copyright notices in revisions 469132-469133. Follow the new copyright and license guidelines --- Key: GRFT-95 URL: http://issues.apache.org/jira/browse/GRFT-95 Project: Graffito Issue Type: Task Reporter: Jukka Zitting Assigned To: Jukka Zitting Priority: Blocker Attachments: HEADER.txt The ASF board approved new guidelines for handling copyright notices and license headers in June. The guidelines suggest that the copyright notice be placed in the NOTICE file like this: Apache [PRODUCT_NAME] Copyright [] The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). (followed by possible other copyright statements) And insted of stating the copyright, the source file headers should state the license being granted. The following text should be used: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GRFT-89) Update the Graffito incubation status page
[ http://issues.apache.org/jira/browse/GRFT-89?page=all ] Jukka Zitting reassigned GRFT-89: - Assignee: Jukka Zitting Update the Graffito incubation status page -- Key: GRFT-89 URL: http://issues.apache.org/jira/browse/GRFT-89 Project: Graffito Issue Type: Improvement Reporter: Jukka Zitting Assigned To: Jukka Zitting Attachments: graffito-status.patch The Graffito incubation status page at http://incubator.apache.org/projects/graffito.html was last updated quite a while ago. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: JCR-Mapping: Mapping multiple properties or child nodes to a single field
Hi, On 10/17/06, Felix Meschberger [EMAIL PROTECTED] wrote: I could imagine, that such functionality could be of use for others, too. Therefore I am willing to give them to the project. Attached, you will find the three classes. NB: Currently the classes are in our own package, which would of course should be fixed when integrating with the JCR-Mapping project. The attachments were apparently lost along the way. Can you please file them in Jira? BR, Jukka Zitting
October status report for Graffito
Hi, Raphaël already started the October status report for Graffito, and I just added some more details. Check the Graffito section at http://wiki.apache.org/incubator/October2006 and let us know if you'd like to see any changes or additions. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: Re: Vote : Jukka as new new Graffito mentor
Hi, On 9/20/06, Christophe Lombart [EMAIL PROTECTED] wrote: Opps sorry. All votes are +1. Welcome to Jukka. Happy to see you in our team. I didn't know the ASF procedures in all details. So, what is the next step ? Thanks! I'll take the issue to the incubator mailing list and unless anyone says anything opposite, I'll add myself to the project records. I should already have commit access due to being a member of the Incubator PMC. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: Graffito at ApacheCon US
Hi, On 9/19/06, Christophe Lombart [EMAIL PROTECTED] wrote: I will not be present but we can prepare this presentation together. Let me know when you need help. Great, thanks! I'll be busy travelling the next week, so the week after (first week of October) is better. It's just a 5 minute lightning talk, with no slides or anything, so a list of key points to describe is probably good enough. Ideas on how to best summarize the various aspects of the project are very much welcome. :-) BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: JCR mapping release
Hi, On 9/19/06, Dan Connelly [EMAIL PROTECTED] wrote: In my opinion, there are Graffito jcr-mapping JIRAs open now which would block release in Jackrabbit 1.2. I disagree. The tool works and implements a number of useful use cases. It's not like there will be only one JCR mapping release, we can always make new releases with new features and improvements to existing features. In fact the Jackrabbit 1.1 release I'm wrapping together has quite a few known issues and outstanding feature requests, including some pretty major ones, just like the 1.0 release had before. The good thing is that Jackrabbit 1.1 implements quite a few of the issues that were open in 1.0. Release early, release often. :-) There are 16 unresolved Major or Critical JIRAs open on Graffito jcr-mapping.I do not see any myself at first glance that I would take out of the blocker category. How will it be determined which ones are blockers?Is it realistic to get a resolution on all 16 for an end-of-year release? As Alexandru already mentioned, contributions are welcome to close some of those issues. :-) Different people have different needs, so even if there are open issues that affect some people, others may still be able to use the tool without any problems. There will never be a release if we wait for everyone to be perfectly satisfied. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
JCR mapping release
Hi, To better prepare for a move to the Jackrabbit project, I'd like to propose making a release of the JCR mapping subproject. The code seems to be stable enough for a release and all the IP issues have already been resolved, so there should be no major remaining issues. Would someone like to step up as the release manager? It's a task that gets you pretty familiar with various policies and procedures of the ASF. I'll be happy to assist in any way I can. PS. I'd like to follow up with a release of also the full Graffito framework, but it's probably easier to do a more limited release first. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: JCR mapping release
Hi, On 9/18/06, Alexandru Popescu [EMAIL PROTECTED] wrote: Darn... if it wouldn't be that performance problem I was mentioning on the Jackrabbit list I would have done it. When would you like to have the release done? :-) I'd be very happy if we could include the JCR mapping tool in the Jackrabbit 1.2 release (Jackrabbit uses an integrated release cycle where all stable components are released together) that I'm tentatively planning for the end of this year. Having the JCR mapping release within a month or two would still give us good time to go through the actual transition to Jackrabbit before the end of the year. But that's just a suggestion, the schedule is up to the release manager and ultimately the PMC to decide. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: portlet content mode prototype
Hi, On 9/6/06, Edgar Poce [EMAIL PROTECTED] wrote: On 9/6/06, David Sean Taylor [EMAIL PROTECTED] wrote: Wondering why the two jars must go in endorsed directly, and not in the WEB-INF/lib directory. I'm not sure :(, I think I read in jackrabbit mailing list that it was the right way to go but I didn't investigate further. It was just a quick fix to make it work. with java 2 jackrabbit worked without problems, but in java 5 those libraries were removed and some problems araised. See http://issues.apache.org/jira/browse/JCR-46 for the background. Java 5 uses the core classloader to load the TransformerFactory implementation specified in the javax.xml.transform.TransformerFactory property. This is why the class needs to be in the endorsed directory instead of the normal classpath location if you want to use another transformer than the one included by default in Java 5. For Jackrabbit the problem was that our XSL transformation was using features not included in the default compiling transformer implementation in Java 5. Not having looked at the issue here I'm not sure if the same thing applies. Just reacting to Edgar's comment. :-) BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: JCR mapping vs. Jackrabbit update
Hi, On 9/1/06, Jukka Zitting [EMAIL PROTECTED] wrote: I just started a thread on the Jackrabbit dev list to gather opinions on possibly moving the JCR mapping tool into a Jackrabbit subproject. The feedback was very positive, so I don't think there'll be any problems from that side. I'm not 100% sure how to graduate a subproject of an incubating project into a subproject of another Apache project, but I think we can work that out along the way. I think the best way forward is to first make a release of the JCR mapping tool to go through and resolve all the licensing and other formal issues and then to ask the Incubator PMC to graduate the subproject into Apache Jackrabbit. That would also require the Apache Jackrabbit PMC to vote the mapping tool developers in as Jackrabbit committers. Does this sound like a good plan of action? Any comments or questions? BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Hi, On 8/28/06, Edgar Poce [EMAIL PROTECTED] wrote: On 8/27/06, Jukka Zitting [EMAIL PROTECTED] wrote: I'm not too familiar with the Alfresco codebase, but that's also a possible alternative to look at. IANAL but have you seen the license?, I don't think I could ever use it :( Ah, too bad, I had just understood it's a MPL derivative. I hate when companies do that, modify OS licenses in subtle ways. The extra constraints are related just to GUI applications, so they shouldn't matter for a repository implementation as long as any client applications use it through the standard API. In any case it's not something that could be brought to Apache. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Hi, On 8/27/06, Edgar Poce [EMAIL PROTECTED] wrote: On 8/26/06, Michael Wechner [EMAIL PROTECTED] wrote: Even if JCR is a great thing, it might not fit all purposes and one might be glad to have an alternative entry point, I agree with you. However I tend to think JCR is a good match for graffito. As far as I see in the sources most of the API/impl development effort was put on coding a subset of the features jackrabbit already provides. I guess that in case JCR is chosen as the only api to interact with the repository the development effort could focus on implementing the portlets for content management, and eventually adding features to the underlying jcr implementation. The JCR API is unfortunately not too easy to implement on top of existing content repositories or content access mechanisms. My understanding is that the goal of the API is more to provide a standard and feature-rich platform for building new content applications rather than to be a lowest common denominator for easy integration with all existining content stores. Thus, until (or if ever) there are readily available implementations of JCR on top of filesystems, generic databases, WebDAV, etc. I think it makes sense for Graffito to have it's own abstraction layer especially when the goal is to be able to work with a number of different backends. My concern for starting this thread was more related to the structure of the Graffito abstraction layer. I still don't quite see the rationale for using interfaces for plain data objects and the need for explicitly modelling the (configuration of) possible backend systems as separate Server interfaces. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Hi, On 8/27/06, Edgar Poce [EMAIL PROTECTED] wrote: To name a few first hand problems I faced: [...] That's a very good summary of the problem areas I've been facing as well. Would you like to follow up with that on the Jackrabbit mailing list? I think it would make for a great discussion with potential for outlining the long term design goals of Jackrabbit. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
[jira] Commented: (GRFT-94) Unsafe namespace registration in graffito-jcr-spring
[ http://issues.apache.org/jira/browse/GRFT-94?page=comments#action_12424005 ] Jukka Zitting commented on GRFT-94: --- Thanks for applying the patch! let me know if I can close the issue Feel free. My recent policy for Jira has been to leave resolved issues around until the next release before closing them, but that's just a way to make it easier to track all changes between releases (i.e. you can query for all resolved but not yet closed issues) even if the Fix Version tags haven't been set correctly. Unsafe namespace registration in graffito-jcr-spring Key: GRFT-94 URL: http://issues.apache.org/jira/browse/GRFT-94 Project: Graffito Issue Type: Improvement Reporter: Jukka Zitting Assigned To: Christophe Lombart Priority: Minor Attachments: graffito-jcr-spring.patch As discussed in JCR-409, the JCR NamespaceRegistry is not very friendly when adding new namespaces. For example the o.a.p.g.jcr.spring.JackrabbitSessionFactory class fails to correctly register the Graffito namespace if the default prefix has been mapped to some other namespace. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GRFT-95) Follow the new copyright and license guidelines
Follow the new copyright and license guidelines --- Key: GRFT-95 URL: http://issues.apache.org/jira/browse/GRFT-95 Project: Graffito Issue Type: Task Reporter: Jukka Zitting Priority: Minor The ASF board approved new guidelines for handling copyright notices and license headers in June. The guidelines suggest that the copyright notice be placed in the NOTICE file like this: Apache [PRODUCT_NAME] Copyright [] The Apache Software Foundation This product includes software developed at The Apache Software Foundation (http://www.apache.org/). (followed by possible other copyright statements) And insted of stating the copyright, the source file headers should state the license being granted. The following text should be used: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the License); you may not use this file except in compliance with the License. You may obtain a copy of the License at http://www.apache.org/licenses/LICENSE-2.0 Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Hi, On 7/21/06, Christophe Lombart [EMAIL PROTECTED] wrote: Right - There are simple data objects to store connection setting parameters. OK, that clears things. Do the Servers need to be interfaces, i.e. do you expect multiple different implementations of the data object classes? I'm on vacation today but next week I will review your jira issues and commit your patches. Thanks. Feel free to reject some of the issues if you think they don't make sense. I'm just raising the issues as I go along and run into things I don't grok. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
[jira] Created: (GRFT-90) Compile error in o.a.p.g.jcr.nodemanagement.impl.jackrabbit.NodeTypeManagerImpl
Compile error in o.a.p.g.jcr.nodemanagement.impl.jackrabbit.NodeTypeManagerImpl --- Key: GRFT-90 URL: http://issues.apache.org/jira/browse/GRFT-90 Project: Graffito Issue Type: Bug Components: JCR-Nodemanagement Reporter: Jukka Zitting The method createNodeTypes() in o.a.p.g.jcr.nodemanagement.impl.jackrabbit.NodeTypeManagerImpl (8 package levels!) refers to the nonexistent method getClassDescriptors() in class o.a.p.g.jcr.mapper.model.MappingDescriptor, causing the compile of jcr/jcr-nodemanagement to fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GRFT-90) Compile error in o.a.p.g.jcr.nodemanagement.impl.jackrabbit.NodeTypeManagerImpl
[ http://issues.apache.org/jira/browse/GRFT-90?page=all ] Jukka Zitting updated GRFT-90: -- Attachment: jcr-nodemanagement-compile.patch Attached a simple patch that fixes the compile failure. Compile error in o.a.p.g.jcr.nodemanagement.impl.jackrabbit.NodeTypeManagerImpl --- Key: GRFT-90 URL: http://issues.apache.org/jira/browse/GRFT-90 Project: Graffito Issue Type: Bug Components: JCR-Nodemanagement Reporter: Jukka Zitting Attachments: jcr-nodemanagement-compile.patch The method createNodeTypes() in o.a.p.g.jcr.nodemanagement.impl.jackrabbit.NodeTypeManagerImpl (8 package levels!) refers to the nonexistent method getClassDescriptors() in class o.a.p.g.jcr.mapper.model.MappingDescriptor, causing the compile of jcr/jcr-nodemanagement to fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GRFT-92) Remove the graffito-commons subproject
Remove the graffito-commons subproject -- Key: GRFT-92 URL: http://issues.apache.org/jira/browse/GRFT-92 Project: Graffito Issue Type: Improvement Reporter: Jukka Zitting It seems that the commons subproject only contains two small utility classes. Instead of maintaining a full subproject for those utility classes, I'd suggest moving them to the graffito-components subproject and removing graffito-commons. Feel free to resolve this issue as Won't Fix if there are plans to use graffito-commons for something more substantial. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Why the Webdav-/Graffito-/FileSystemServer interfaces?
Hi, Going deeper into the graffito-api project I started wondering why it contains the Webdav-, Graffito- and FileSystemServer interfaces? And more alarmingly, why does the ContentServerService interface contain factory methods to generate instances of those interfaces? My understanding from the web site documentation was that you could plug in any types of Server implementations into the Graffito framework, but those interfaces and the factory methods seem to suggest that only those three types of Servers are supported. Am I misunderstanding something here? BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
[jira] Created: (GRFT-93) Missing license headers in graffito-jcr-spring
Missing license headers in graffito-jcr-spring -- Key: GRFT-93 URL: http://issues.apache.org/jira/browse/GRFT-93 Project: Graffito Issue Type: Bug Reporter: Jukka Zitting The following files in o.a.p.g.jcr.spring are missing license headers: * JcrMappingCallback.java * JcrMappingOperations.java * JcrMappingTemplate.java * MappingDescriptorFactoryBean.java They were added a month ago in revision 414355 by Christophe Lombart with the message Review OCM/JCR Spring support, and seem to be created by Costin Leau. Christophe Costin, could you please add the standard license headers to these files? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GRFT-94) Unsafe namespace registration in graffito-jcr-spring
Unsafe namespace registration in graffito-jcr-spring Key: GRFT-94 URL: http://issues.apache.org/jira/browse/GRFT-94 Project: Graffito Issue Type: Improvement Reporter: Jukka Zitting Priority: Minor As discussed in JCR-409, the JCR NamespaceRegistry is not very friendly when adding new namespaces. For example the o.a.p.g.jcr.spring.JackrabbitSessionFactory class fails to correctly register the Graffito namespace if the default prefix has been mapped to some other namespace. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Why the Webdav-/Graffito-/FileSystemServer interfaces?
Hi, On 7/21/06, Jukka Zitting [EMAIL PROTECTED] wrote: Going deeper into the graffito-api project I started wondering why it contains the Webdav-, Graffito- and FileSystemServer interfaces? I traced the use of the Server interface back to just providing configuration interface to the appropriate Store implementation. Is it the intention that Server instances are just carriers of configuration parameters? BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
[jira] Updated: (GRFT-89) Update the Graffito incubation status page
[ http://issues.apache.org/jira/browse/GRFT-89?page=all ] Jukka Zitting updated GRFT-89: -- Attachment: graffito-status.patch Attached a patch (against incubator trunk) that updates the status page (and the generated html) with the latest incubation status reports, an up-to-date committer list, and project news from http://incubator.apache.org/graffito/news.html. Update the Graffito incubation status page -- Key: GRFT-89 URL: http://issues.apache.org/jira/browse/GRFT-89 Project: Graffito Issue Type: Improvement Reporter: Jukka Zitting Attachments: graffito-status.patch The Graffito incubation status page at http://incubator.apache.org/projects/graffito.html was last updated quite a while ago. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Graffito release plans?
Hi, On 7/15/06, Christophe Lombart [EMAIL PROTECTED] wrote: Ooops - I'm very sorry, the OCM unit tests are in : /jcr/jcr-mapping/src/test (not in /components/src/test) No problem. At the moment I'm really more interested in how the Graffito portlet components use the persistence API than in the specifics of the way it is implemented by the OCM tool. Once I've understood the Graffito core model, I'll have a better grasp on how the OCM tool fits into the picture. I hope you'll have the patience to help me through this. :-) What is the folder instance in this case? Is it a plain data object or an adapter to an underlying folder concept? it points to a plain data object. A usual pojo with simple getters/setters. Is this POJO class shared by the different persistence implementations (DB, JCR, etc.) or does each implementation have it's own POJO classes that implement the core model interfaces? What I'm getting at here is that if the folder in the example is a data object, why do we need the Folder interface? Wouldn't it make more sense to replace the Folder interface with a shared data object class? Can I implement my own Folder class and pass instances of it to the persistence layer? yes but you have to specify the interface Folder and the class MyFolder it in the mapping file. OK. But if I write a Graffito portal component that relies on this, wouldn't the requirement to have a JCR-specific mapping file break the indepence from the underlying persistence model? How would I map that custom class to a DB storage? BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: Graffito release plans?
Hi, On 7/13/06, Christophe Lombart [EMAIL PROTECTED] wrote: So, the current best place is certainly the Jackrabbit project. Jukka, can you start this process and discussion with other Jackrabbit commiters? Yes, I'll do that. I suppose all the Incubator IP issues have already been resolved for Graffito, so we'll have no trouble with that if we do choose to move the subproject to Jackrabbit. In any case, before actually going forward with something like this, we should enumerate the API requirements that Graffito has for the JCR subproject. Looking at the Server, Folder, and CmsObject interfaces, it seems to me that a direct JCR implementation (without the OCM mapping) would probably suit the needs even better. Do the components bypass the core model to access extra features of the OCM? (I'm sorry for my ignorance, if I'm missing something essential...) BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: Graffito release plans?
Hi, On 7/14/06, Christophe Lombart [EMAIL PROTECTED] wrote: The OCM tools looks like Hibernate, OJB, this is not tied to a specific object model. The mapping file gives you the flexibility to map any kind object graph into a JCR structures (node properties). Exactly. However, at least based on my initial scan, it seems that Graffito doesn't have a POJO object model (as in concrete value objects), but uses interfaces of the core model as a kind of an SPI layer. Thus there is a chance of either using direct JCR calls to implement the interfaces, or doing it with separate Java objects and the OCM tool. Looking at the Server, Folder, and CmsObject interfaces, it seems to me that a direct JCR implementation (without the OCM mapping) would probably suit the needs even better. Can you explain more ? I'm not sure that I understand you. It seems like there is a very natural mapping between the Graffito core model and the JCR node hierarchy. I'm wondering if a separate Java object layer is needed between, i.e. would it be more natural to have just JCRServer, JCRFolder, and JCRObject (etc.) classes that implement the API using direct JCR calls? There is certainly demand for a generic object-to-content mapping tool, but I'm wondering if Graffito is actually the best candidate for using it. Do the components bypass the core model to access extra features of the OCM? Which ones ? That's what I was asking. :-) Is there a component that uses the features of the underlying storage outside the API defined in the core model? BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: Graffito release plans?
Hi, On 7/14/06, Christophe Lombart [EMAIL PROTECTED] wrote: Ok I think there are some confusions here - sorry ! No problem, it's me who is being confused. There are so many components at various levels in the SVN source tree that I'm having problems identifying the overall structure. The Directory Layout page on the web site is great help, adding perhaps a dependency graph would make it even better. if you check the OCM unit tests (/components/src/test), this is not mandatory to implements a specific interface and/or a specific ancestor class. You are free to defined your own. OK, below is a snippet from one of the test cases: Folder folder = modelService.createFolder(); folder.setCreationDate(new Timestamp(System.currentTimeMillis())); folder.setLastModified(new Timestamp(System.currentTimeMillis())); folder.setName(folder1); folder.setUri(/graffitotest/folder1); modelService.addFolder(folder); What is the folder instance in this case? Is it a plain data object or an adapter to an underlying folder concept? Can I implement my own Folder class and pass instances of it to the persistence layer? Folder folder = new MyFolder(); modelService.addFolder(folder); When I retrieve that folder from the persistence layer, will it still be an instance of the MyFolder class? BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
[jira] Created: (GRFT-87) Update Jackrabbit dependencies to 1.0
Update Jackrabbit dependencies to 1.0 - Key: GRFT-87 URL: http://issues.apache.org/jira/browse/GRFT-87 Project: Graffito Issue Type: Improvement Components: JCR Store, JCR-Mapping, JCR-Nodemanagement Reporter: Jukka Zitting Priority: Trivial Update the Jackrabbit dependencies in the JCR subprojects to the official 1.0 release. This is also related to the GRFT-13 issue, as the Jackrabbit 1.0 jars are available from the standard Maven repository. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Graffito forwarding..
Hi, On 7/13/06, Christophe Lombart [EMAIL PROTECTED] wrote: I'm just wondering about your access right to the project. Do you have time to commit some changes in order to help us ? I'd be happy to have commit access, and I figure I'd get that automatically by virtue of becoming a mentor. Raphaël, will you ask the Incubator PMC to get me included as a Graffito mentor, or should I drive the process myself? Until that I can work by sending patches to Jira as a normal contributor. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
Re: Graffito release plans?
Hi, On 7/13/06, Costin Leau [EMAIL PROTECTED] wrote: # since both me and Spring Modules were mentioned, I though I should # clarify things a bit Thanks for joining! I think a mapping tool for JCR would be a very useful tool and I'd be glad to support it inside Spring Modules (I'm not sure if it makes sense to move it there). However, I think it's really premature to discuss such issue before the tool is finalized. That's reasonable. I haven't yet looked deeper into the code, so I'm not too familiar with the maturity of the subproject. What's the current status in terms of the main use cases? BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
[jira] Commented: (GRFT-2) Mailing list archives are not accessible
[ http://issues.apache.org/jira/browse/GRFT-2?page=comments#action_12420743 ] Jukka Zitting commented on GRFT-2: -- The archives seem to be accessible now. See also the archives at: http://mail-archives.apache.org/mod_mbox/incubator-graffito-dev/ http://mail-archives.apache.org/mod_mbox/incubator-graffito-commits/ Mailing list archives are not accessible Key: GRFT-2 URL: http://issues.apache.org/jira/browse/GRFT-2 Project: Graffito Type: Bug Reporter: Stephane Bailliez Priority: Minor Fix For: 1.0-a1-dev http://incubator.apache.org/graffito/mail-lists.html Looking into the archives (mbox ?) is not permitted -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Introducing myself
Hi graffito-dev! I just joined the mailing list after a long while of following the project by the web site and the incubation status reports. I'm a committer and the release manager of the Apache Jackrabbit project, whom some of you already know from the Jackrabbit mailing lists. I've been keeping an eye on Graffito as an approach of building applications on top of the JCR API, and would like to help increase the coupling between the Jackrabbit and Graffito communities. To do this I'm volunteering to join Raphaël as a mentor of Graffito, of course assuming that you'd have me as a mentor. I'm not a long-time Apache veteran and have few contacts with the Portals project, but I've got fresh hands-on experience from the Jackrabbit project ranging from early days of it's incubation to successful graduation. Along the way I touched virtually all parts of the incubation process and a good number of other practices that define the Apache Way. I'd love to share that experience with you. BR, Jukka Zitting -- Yukatan - http://yukatan.fi/ - [EMAIL PROTECTED] Software craftsmanship, JCR consulting, and Java development
