Monthly Archives: July 2008

Compiling the kernel

Maybe you want to be the first on your block to make a patch for the new kernel. So you need to check out, modify, and compile the new kernel. You may even want to test your changes in Tomcat :)
When Ian wakes up, he might tell me that I am completely wrong – but this worked:
cd ~/dev/sakai-trunk
svn co https://source.sakaiproject.org/svn/kernel/trunk kernel
I check this out into the same directory as sakai – not inside of the sakai directory – so ls looks like this
charles-severances-macbook-air:sakai-trunk csev$ pwd
/Users/csev/dev/sakai-trunk
charles-severances-macbook-air:sakai-trunk csev$ ls -ld kernel sakai
drwxr-xr-x 23 csev staff 782 Jul 30 14:39 kernel
drwxr-xr-x 73 csev staff 2482 Jul 30 15:21 sakai
Then I go into the kernel directory and type this:
mvn -Dmaven.test.skip=true -Dmaven.tomcat.home=/Users/csev/dev/sakai-trunk/apache-tomcat-5.5.23/ clean install sakai:deploy
This is the same thing I type to compile sakai.
It compiles kernel – puts it into my maven repo and then puts it right into my Tomcat!
Voila!

My K1 Experience

I am back up with K1 – it was not so hard – My instructions are a little different than Ian’s because I use vi and no debugger. A key here is that you don’t have to switch to how Ian does his tomcat stuff – just for K1 – I did my normal process (different than Ian’s) and it all still came up fine – so whatever your process is – it should work as well.
I include my steps
Whacked the repo (per Ian)
rm -rf ~/.m2/repository/org/sakaiproject
Whacked my tomcat
rm -rf ~/dev/sakai-trunk/apache-tomcat-5.5.23/
Unzipped a new fresh tomcat 5.5.23
cd ~/dev/sakai-trunk/
curl -O http://source.sakaiproject.org/mirrors/ibiblio/maven/tomcat/zips/apache-tomcat-5.5.23.zip
unzip -q apache-tomcat-5.5.23.zip
chmod +x apache-tomcat-5.5.23/bin/*.sh
Clean check out
svn co https://source.sakaiproject.org/svn/sakai/trunk/ sakai
Full compile attempt – Failed with the following message
[INFO] Failed to resolve artifact.
GroupId: org.sakaiproject
ArtifactId: master
Version: SNAPSHOT
Reason: Unable to download the artifact from any repository
org.sakaiproject:master:pom:SNAPSHOT
from the specified remote repositories:
central (http://repo1.maven.org/maven2)
Do the master thing – as per Ian:
cd sakai/master/
mvn install
— BUILD Successful
Full compile:
mvn -Dmaven.test.skip=true -Dmaven.tomcat.home=/Users/csev/dev/sakai-trunk/apache-tomcat-5.5.23/ clean install sakai:deploy
Started tomcat – navigate to http://localhost:8080/
Viola – Sakai is back with K1
Now – I am wondering where site code went… Hmmm. I was busily working on SAK-13482 and was ready to check in – when I realized the world had just changed out from under me – that will wait until Ina gets back.
NICE WORK IAN!

Kernel 1 – In the house

Our trunk is now reorganized to define a kernel – this will be a few days of angst – the contrib folks will need to react – Ian has provided a nice XSLT to get the pom.xml files fixed with minimal pain.
This will also make the 2-5-x branch management a little more dicey for 2-5-3, etc.
Progress is needed and this is a great time to take this plunge – when we have 2.5.2 in hand – and the 2-5-x branch is in pretty good shape – and we have some time before the 2.6 code freeze.
Folks not working on the deep bits of Sakai – might want to avoid doing an update for a few days – if you are working in the new Kernel area – you pretty much need to update and help figure out the new way.
Here is Ian’s note.
Again – thanks for the fine work, Ian!

Continue reading

Sakai K1 Kernel Commit Policies

The Sakai K1 Kernel will be in our svn pretty soon! This is a great milestone for Sakai – it moves us toward a much more manageable source tree given the kinds of resources we have available in the community.
For me this is a welcome move back toward a “do-ocracy” – at least for this very technical bit of the code. Do-ocracy and dem-ocracy have their places – and in particular for Sakai – with a large,complex user interface that end-users touch daily – it is important to not be a pure do-ocracy. But for the deepest bits of our code – the kernel – pretty much Apache Rules need to apply here with no grey area.
Ian recently posted the following vote to the dev list – lots of folks want comfortable grey areas like we have had in the past out of necessity. As folk might expect from me – I prefer grey only when there is a reason for grey.
Here is Ian’s question:
Going forwards I would like to adopt a more Apache like policy to kernel modifications in K1… namely
1. non kernel committers have to submit patches to Jira for review
2. commits < 10 lines that dont change functionality can be committed by kernel comitters 3. all commits > 10 line that change functionality have to be submitted as patches to Jira for review, review is light weight and commit is relatively fast afterwards.
If some one wants a branch, thats fine, but the above practice still stands, they need to create a patch and submit that patch to jira.
Please vote.
Ian
Here is my answer – pretty much grey-less as you might expect :)

Continue reading

New Feature in SimpleLTI for Sakai – Note to Self

Add feature so that properties of the form
common.toolid.launch=String
Act as if they came from the LTI Proxy Tool Registration file with
“final” set to true. If these are set in the sakai.properties *and*
in the tool registation, the sakai.properties – wins.
For example:
sakai.simplelti.launch=http://simplelti.appspot.com/launch
sakai.simplelti.password=secret
When the IMS SimpleLTI tool is multiply registered, each common tool id
can do this separately.

Apple iPhone (Original) Geotagging photos with iPhone 2.0 Software

This is what I know so far:
When you upgrade your original iPhone to the 2.0 software – you can do geotagging of photos.
When I pull the photos into iPhoto – and do CMD-I I see GPS coordinates. These are as right as they can be using triangulation/Wifi tricks – but they are at least *close*.
It seems that FLickr does not see the meta data yet – flick does not even know that the photo came from an iPhone.
But I am sure this will all work out.
I wish I knew a site that I could upload a photo and have it dump all the metadata.
Given that I don’t have 3G in Lansing where I live and that Geotagging was my most important feature – it means that I don’t have to rush right out to get the new iPhone – I will still get one eventually – I will just let the craziness die down a bit.

BlackBoard Sakai Connector – Inside Higher Education

I was interviewed for Inside Higher Education in regards to the BlackBoard/Sakai Connector:
http://www.insidehighered.com/news/2008/07/15/sakai
I added a comment to the article:
When dealing with a company – we should always assume that their purpose is to increase profit. Increasingly, companies realize that by creating *truly open* ecologies around their product – they make *more* money rather then less money. When customers perceive the market as “fair” generally overall investment increases across the board. When there is a real or perceived battle between open source and proprietary companies, many organizations with money “stand pat” and invest in neither until things settle down.
Part of making a truly open ecology is standards – I work with IMS (www.imsglobal.org) and we have been developing standards like IMS Learning Tools Interoperability and others that touch on these areas. Blackboard is participating in these efforts and we hope that much of the aspects of the connector will ultimately be covered by formal, published, and interoperable standards.
But it is a delicate balancing act – products and standards move at different paces – if we wait for a perfect standard – products will be held off forever. If we never build a product – we never reveal the fine technical details needed in the standard.
When I look at all of this, the balance tips towards being engaged in the effort and trying to influence the direction to ultimately improve the experience of teachers and learners regardless of what enterprise CMS system their school or campus happens to have installed.

Continue reading