[DG: User Experience] The state of ux/branches/K2-Sling

[Ray Davis]

I sent the following message to the K2 group, but Ian told me it should 
go to the UX group instead. I actually wasn't aware that 3akai project 
governance was divided at the moment -- I've been assuming I'll be 
contributing both client-side and server-side code and that everyone 
working on the 3akai UX embedded in a K2 build also follows 
sakai-kernel. Along those lines, please let me know if you would rather 
I *not* work on these two bugs this week:

http://jira.sakaiproject.org/browse/SAKIII-49
http://jira.sakaiproject.org/browse/SAKIII-50

Here's my is-this-a-bug-or-not? question, though:

Most of the current client-side code for 3akai is in a Subversion branch 
of the earlier UX demo:

https://source.sakaiproject.org/svn/ux/branches/K2-Sling

Currently it gets incorporated into a Git-fetched K2 build by 
bundles/uxloader/pom.xml using Maven to check out (or update) the 
Subversion-stored files and then positioning them inside an OSGi bundle 
for deployment. So far as I can tell, the pom.xml Maven configurations 
inside the UX K2-Sling directories (which build WAR files instead of 
OSGi bundles) are no longer being used at all.

1. Does that all sound correct?

2. If so, would anyone object if I (or someone else) added a functional 
Maven set-up to the UX K2-Sling branch so that the OSGi bundle was 
created within the project? Besides simplifying the K2 POMs, that might 
make it easier to tag and snapshot UX builds and get more stable 3akai 
deployments. (Currently there's no way to really predict what 
combination you'll get from a K2 build, and I hit so many integration 
failures last month that I finally ended up storing snapshots of working 
K2 builds to a local repository.)

If you currently ignore Maven while working on the Subversion UX branch, 
you should be able to go right on ignoring Maven after that change. :)

Thanks,
Ray