[Building Sakai] KNL-342 and tool registration files

[Maurer, Christopher Wayne]

I'm in favor of this as well.  We have a number of tools where our only customization is adding/removing a category.

Chris

From: Matthew Jones <jonespm at umich.edu<mailto:jonespm at umich.edu>>
Date: Mon, 25 Apr 2011 10:16:15 -0400
To: Seth Theriault <slt at columbia.edu<mailto:slt at columbia.edu>>
Cc: <sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org>>
Subject: Re: [Building Sakai] KNL-342 and tool registration files

I was +1 on this patch (KNL-342) when I saw it and was thinking of the same thing. Because of SAK-13688, tool registration for JSR-168 portlets happens very similar to this, and it makes configuring LTI tools much easier.

Being able to change things in the tool registration locally that you can't override in tools.properties (which is just description and title) would be nice.

* We have a number of cloned web content tools (UMICH-150, UMICH-151, UMICH-271) to support the annotated url feature (SAK-19369). These all have to be placed in the webapp/WEB-INF directory of a branched tool.

* I also have to run xslt to add and remove categories from the tool registration during the local build process for a number of tools we have to change categories for. [1]

* I think we also have some tool configuration changes.

It would be nice to just copy all of these to the local directory so we don't need to branch the actual tools. I can foresee a the possibility desire for tool registration at runtime someday, this is better than what we've got now.

[1] https://source.sakaiproject.org/svn/msub/umich.edu/ctools/builds/trunk/groovybuild/xslt/fixcategory.xslt

On Sun, Apr 24, 2011 at 10:06 PM, Seth Theriault <slt at columbia.edu<mailto:slt at columbia.edu>> wrote:
Hello,

It was suggested to me recently to take a look at KNL-342, where
one of the contributed patches that allows you to override tool
registrations via files in the ${sakai.home} directory.

I am interested in this overrride capability for 2.6/1.0.x as it
seems to solve a local-patch maintenance problem. Anyone have
opinions?

Seth

_______________________________________________
sakai-dev mailing list
sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org>
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org<mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"

_______________________________________________ sakai-dev mailing list sakai-dev at collab.sakaiproject.org<mailto:sakai-dev at collab.sakaiproject.org> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev TO UNSUBSCRIBE: send email to sakai-dev-unsubscribe at collab.sakaiproject.org<mailto:sakai-dev-unsubscribe at collab.sakaiproject.org> with a subject of "unsubscribe"
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110425/174dba67/attachment.html