[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
_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Oszkar Nagy]

Hi Ray,

First all help is welcome and greatly appreciated, so please do send
patches to me for the mentioned issues.

Regarding the SVN repo question:

I am not *very* familiar with the build process or the scripts executed
during the process, but here is some info which might help:

When you do a kernel build from the git repo, the build script will grab
the latest UX version from SVN:

https://source.sakaiproject.org/svn/ux/branches/K2-Sling/uxportal/src/main/webapp/   
for /dev
https://source.sakaiproject.org/svn/ux/branches/K2-Sling/uxwidgets/src/main/webapp/   
for /devwidgets

then the uxloader loads these.

/dev and /devwidgets can be stored anywhere locally on your machine by
using the "Apache Sling Filesystem Resource Provider" bundle and
configuring /dev and /devwidgets to point to the appropriate folders on
your hard drive (Configuration menu in the Felix console). This is how
we work on local instances at the moment.

Could you explain what do you mean by (sorry, I am not very familiar
with Java):

adding 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.


IMHO the UX part should be completely separated from any kernel/build
stuff so my gut feeling is not to mix anything else into the UX branch,
but of course I am open to any suggestion which makes development/setup
easie.r

Hope this helps,
Oszkar



On 05/10/2009 18:12, Ray Davis wrote:

> 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
> _______________________________________________
> sakai-ux mailing list
> sakai-ux@...
> http://collab.sakaiproject.org/mailman/listinfo/sakai-ux
>
> TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"
>    

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Ray Davis]

 > IMHO the UX part should be completely separated from any kernel/build
 > stuff so my gut feeling is not to mix anything else into the UX branch,
 > but of course I am open to any suggestion which makes development/setup
 > easie.r

Coincidentally, my first reaction on looking at the current
configuration was that the UX part was way too tangled with the kernel
build!  :)  The K2 build goes directly to Subversion and checks out and
incorporates whatever the current state of the UX branch happens to be,
which implies a magically tight coupling between the projects. My
suggested change would allow (but not require) separate builds and
deployments of *just* the UX part, so that (for example) we might have
one UX snapshot that's known to work with a tagged version of K2 code
and a different UX snapshot that works with a newer K2 branch.

So here's a tentative plan:

I'll make a Subversion branch for my work on SAKIII-49 and SAKIII-50.
After submitting patches for those bugs, I'll try the Maven cleanup and
make sure that a Filesystem Resource Provider development approach isn't
affected. I'm sure it won't be an issue, but testing is better than
confidence. :)

Sound OK?

Thanks,
Ray

On 10/5/09 11:09 AM, Oszkar Nagy wrote:

> Hi Ray,
>
> First all help is welcome and greatly appreciated, so please do send
> patches to me for the mentioned issues.
>
> Regarding the SVN repo question:
>
> I am not *very* familiar with the build process or the scripts executed
> during the process, but here is some info which might help:
>
> When you do a kernel build from the git repo, the build script will grab
> the latest UX version from SVN:
>
> https://source.sakaiproject.org/svn/ux/branches/K2-Sling/uxportal/src/main/webapp/   
> for /dev
> https://source.sakaiproject.org/svn/ux/branches/K2-Sling/uxwidgets/src/main/webapp/   
> for /devwidgets
>
> then the uxloader loads these.
>
> /dev and /devwidgets can be stored anywhere locally on your machine by
> using the "Apache Sling Filesystem Resource Provider" bundle and
> configuring /dev and /devwidgets to point to the appropriate folders on
> your hard drive (Configuration menu in the Felix console). This is how
> we work on local instances at the moment.
>
> Could you explain what do you mean by (sorry, I am not very familiar
> with Java):
>
> adding 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.
>
>
> IMHO the UX part should be completely separated from any kernel/build
> stuff so my gut feeling is not to mix anything else into the UX branch,
> but of course I am open to any suggestion which makes development/setup
> easie.r
>
> Hope this helps,
> Oszkar
>
>
>
> On 05/10/2009 18:12, Ray Davis wrote:
>> 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

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"

[Oszkar Nagy]

Sounds good Ray, and thanks for the clarification. As I said I am up for
everything which makes people's life easier who work on the front-end so
what you are proposing makes sense to me. Let me know how it goes, or if
you need any help.

Oszkar

On 05/10/2009 19:44, Ray Davis wrote:

> > IMHO the UX part should be completely separated from any kernel/build
> > stuff so my gut feeling is not to mix anything else into the UX branch,
> > but of course I am open to any suggestion which makes development/setup
> > easie.r
>
> Coincidentally, my first reaction on looking at the current
> configuration was that the UX part was way too tangled with the kernel
> build!  :)  The K2 build goes directly to Subversion and checks out
> and incorporates whatever the current state of the UX branch happens
> to be, which implies a magically tight coupling between the projects.
> My suggested change would allow (but not require) separate builds and
> deployments of *just* the UX part, so that (for example) we might have
> one UX snapshot that's known to work with a tagged version of K2 code
> and a different UX snapshot that works with a newer K2 branch.
>
> So here's a tentative plan:
>
> I'll make a Subversion branch for my work on SAKIII-49 and SAKIII-50.
> After submitting patches for those bugs, I'll try the Maven cleanup
> and make sure that a Filesystem Resource Provider development approach
> isn't affected. I'm sure it won't be an issue, but testing is better
> than confidence. :)
>
> Sound OK?
>
> Thanks,
> Ray
>
> On 10/5/09 11:09 AM, Oszkar Nagy wrote:
>> Hi Ray,
>>
>> First all help is welcome and greatly appreciated, so please do send
>> patches to me for the mentioned issues.
>>
>> Regarding the SVN repo question:
>>
>> I am not *very* familiar with the build process or the scripts
>> executed during the process, but here is some info which might help:
>>
>> When you do a kernel build from the git repo, the build script will
>> grab the latest UX version from SVN:
>>
>> https://source.sakaiproject.org/svn/ux/branches/K2-Sling/uxportal/src/main/webapp/   
>> for /dev
>> https://source.sakaiproject.org/svn/ux/branches/K2-Sling/uxwidgets/src/main/webapp/   
>> for /devwidgets
>>
>> then the uxloader loads these.
>>
>> /dev and /devwidgets can be stored anywhere locally on your machine
>> by using the "Apache Sling Filesystem Resource Provider" bundle and
>> configuring /dev and /devwidgets to point to the appropriate folders
>> on your hard drive (Configuration menu in the Felix console). This is
>> how we work on local instances at the moment.
>>
>> Could you explain what do you mean by (sorry, I am not very familiar
>> with Java):
>>
>> adding 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.
>>
>>
>> IMHO the UX part should be completely separated from any kernel/build
>> stuff so my gut feeling is not to mix anything else into the UX
>> branch, but of course I am open to any suggestion which makes
>> development/setup easie.r
>>
>> Hope this helps,
>> Oszkar
>>
>>
>>
>> On 05/10/2009 18:12, Ray Davis wrote:
>>> 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
>

_______________________________________________
sakai-ux mailing list
sakai-ux@...
http://collab.sakaiproject.org/mailman/listinfo/sakai-ux

TO UNSUBSCRIBE: send email to sakai-ux-unsubscribe@... with a subject of "unsubscribe"