SoftChalk Devel Notes - 2011

Owned by Former user (Deleted)
Last updated: Feb 24, 2011Version comment
6 min read

Feb. 10, 2011

Correspondence with Edia on support for SCORM in Sakai. Indications are that things have improved. I will talk with Sue about this later today.

Meanwhile, I'm working on fixing the Javascript security fix introduced in Sakai late last year. This fix prevents HTML code from being shown "in-line", which means embedded in the Sakai window. Unless certain things are done, such HTML files (like those uploaded by LessonBuilder) will be available for download, but not playing. This effectively prevents SoftChalk from running in Sakai. Stephen Marquard provides the following fix:

It's an entity property, i.e. you can set it on a file or folder in ContentHostingService. So the resolution order for whether to allow HTML served inline is:

  1. Is content.html.forcedownload=true set in sakai.properties? (default yes for 2.7.x, default no for 2.6.x). If no, then allow any HTML inline.
  2. Is the entity property SAKAI:allow_inline set on the containing folder of the item? If yes, serve it inline if HTML.
  3. Is the entity property SAKAI_allow_inline set on the item itself? If yes, serve it inline, if not, set content-disposition to attachment.

In 2.7.x, the property is exposed in the Resources tool UI for folders and items, but it can obviously also be set problematically.

Hope that provides a way to resolve the issue.

I have verified the main problem, now I need to put the fix in. When ever I create a collection via Content Hosting Service, I need to add the property above. That should fix the problem.

Properties will need to be added in:

  • LBGFile.add() - 1 place
  • LBGFolder.add() - 1 place.
  • LBGZip.handleAdd() - 3 places.

I created two constants, COLL_INLINE_PROP="SAKAI:allow_inline", and RSRC_INLINE_PROP="SAKAI_allow_inline". Personally, I think these property names should be the same. I think there is typo in Stephen's email. Also, there is a question on what value to set them to. True/false, I think, but how are they represented? I assumed "true" for now.

I'll give it a try. Implemented the fixes. A superficial test indicates that it is working.
I have checked this into the lbgateway trunk as version 72625.

I need to back these changes into the following branches of lbgateway:

  • 2.6.1
  • 2.6.2
  • 2.7.0

It should also be added to tagged release 15.
Some SVN work is needed. I should create tagged releases for 2.6.1, 2.6.2, 2.6.3, 2.7.0, and 2.7.1.
There should be branches for 2.5.x, 2.6.x, and 2.7.x.
Sakai 2.8.x is due to be released within the next few months.

Sue would like these changes to be installed in the SoftChalk GoGrid instances as well. Add the latest Edia SCORM player to the 2.7.x instance.

Feb. 16, 2011

I need to update the various tagged releases of lbgateway to match Sakai releases. Currently, I have the following in branches:

  • lbgateway-2.5.5/
  • lbgateway-2.6.1/
  • lbgateway-2.6.2/
  • lbgateway-2.6.x/
  • lbgateway-2.7.0/
  • lbgateway-ns-2.6.1/

In tags, I have:

  • lbgateway-15/

Truthfully, the only differences between the Sakai flavors is the Sakai version number in the pom.xml files. It kinda sucks that I can't inherit this from a central master file. There is one thing I could try. I can create a "softchalk.sakai.version" variable in the .m2/settings.properties file. That might be worth a shot.

I have added the property to my settings.properties file and made reference to !{softchalk.sakai.version} where version numbers are needed in the two pom.xml files.
Sadly, this doesn't work. I get errors that indicate that the property reference isn't being resolved.
I tried many flavors and varieties of declaring the variable in settings.xml, but none of are being resolved correctly. I don't really understand this, since the Maven documentation indicates that it should work. My guess is that it has something to do with the way Sakai has set up it's master pom files. It's just not going to work.

I sent a note to the Sakai-Dev list:

I have a Sakai tool that I maintain for SoftChalk called lbgateway. It
has two POMs that follow the general Sakai conventions. My problem is
with the parent references. The version number is hard coded to the
current version of Sakai, currently 2.7.1. Since this version number is
hard coded in the POMs, it means that I have to maintain separate tagged
builds for 2.6.0, 2.6.1, 2.6.2, 2.6.3, 2.7.0, and 2.7.1 (not to mention
the upcoming 2.8.0 release). Every time I make a minor bug fix to the
code, I have to update six (warning) tagged releases just because the version
number is hard coded.

Since the parent element in the POM refers to the Sakai master POM, I
don't really understand why the current Sakai version can't be defined
there. Instead, it is hard-wired into ALL Sakai tools.

I have tried setting a property in settings.xml along the lines of
"<softchalk.sakai.version>2.7.1</softchalk.sakai.version> and
referencing it in the POMs as ${softchalk.sakai.version}. In spite of
substantial Maven documentation to the contrary, the property reference
isn't resolved.

So I ask you, fellow Sakaigers, is this fixable? Is there a way to
centrally declare the current Sakai version so that I don't have to
maintain a half dozen tagged versions of a tool? Am I crazy to want this?

Anthony Whyte replied:

What Maven documentation suggests otherwise? Variable substitutions in parent poms, although demanded by many, has not been implemented in Maven 2x or 3x (as of yet).

See the long discussion in the yet unresolved MNG-624 as well as related MNG tickets.

http://jira.codehaus.org/browse/MNG-624

I had a look at the Jira mentioned. This is indeed a long-standing Maven request. The thread strongly suggests that what I want to do is impossible in the existing Maven application.

I sent the following note to Sue Evans:

I've been struggling a bit with a fairly obscure technical problem related to building lbgateway in a Sakai environment. You probably know that Sakai uses an application called Maven to build and deploy Sakai tools. Each tool is built according to a special file called a pom.xml. In this file, a reference is made to the current version of Sakai (2.7.1 at this time).

When ever I make a fix to lbgateway (like the recent fix for JavaScript malware problems), I have to make the same fix in branches for 2.6.x (currently 4 versions), 2.7.x (currently 2 versions), and trunk (one version. The only difference between these versions is the version number in the pom.xml file.

I have discussed this problem with Anthony Whyte of the Sakai Foundation. He indicates that this is a long standing problem in Maven that has not been fixed. It goes back to 2007 at this point (see http://jira.codehaus.org/browse/MNG-624). Sadly, it is not something that can be fixed easily in Sakai.

The question thus becomes how do we want to maintain the lbgateway code. I can see three options:

1. Continue the current practice of keeping separate tagged releases for each Sakai release.
2. Write a shell script to prompt for the version number and then fix up the poms before running them.
3. Ask our users (Sakai admin people who generally know what they are doing) to edit the pom files before building.

The current practice is time consuming and will only get worse as Sakai continues to make new releases. It clutters up the Subversion tree and requires a new lbgateway tagged release for new versions of Sakai when they come out, even if there is no substantive changes to lbgateway. It requires that SoftChalk users select the "correct" version of lbgateway from their Sakai environment.

Writing a shell script to "fix up" the poms is frankly a hack. While I could write such a shell script, I'd have to write several such scripts depending on the OS. It's kinda complicated and potentially error prone.

I actually prefer the third option. I can document how to edit these files (there are only two of them) such that any competent Sakai administrator could install the lbgateway application. It would mean that there would only be one version of lbgateway (the trunk version) maintained against the latest Sakai release. To install it in an older version would require editing the poms, a fairly simple matter.

Please let me know how SoftChalk would like to resolve this issue.

She opted for number 3, with endorsement from Jeff. It's really the simplest thing to do. As such, I'm only going to keep versioned tags of lbgateway around in SVN and document how to change the POM files.

Part of what I'm going to do in this is to capture back versions of lbgateway that were not save explicitly.

Branch

LBG Version

SCORM

lbgateway-2.5.5

13c

yes

lbgateway-2.6.1

13c

yes

lbgateway-2.6.2

16b

no

lbgateway-2.6.x

16b

no

lbgateway-2.7.0

17

no

lbgateway-ns-2.6.1

14ns

no

trunk

19

no

Base on the above search, I'm going to copy:

  • lbgateway-2.5.5 to lbgateway-13c
  • lbgateway-ns-2.6.1 to lbgateway-14ns
  • lbgateway-2.6.x to lbgateway-16b
  • trunk to lbgateway-19

there is already a tagged release for lbgatway-15.
Done. Checked in as rev. 72734.

Feb. 17, 2011

Michael Moses writes:

The IP 173.204.69.52 should be available now.
Sue was actually looking for info on starting and stopping the actual Sakai application, not the go grid servers. I'm sure it's readily available on the web.
Let me know if you need anything else.