Re: [uportal-dev] Resource Server as its own 1st-class project

2009-04-29 Thread Eric Dalquist

Gary,

It is a separate project: 
https://www.ja-sig.org/svn/sandbox/resource-server/


It has been submitted for incubation as its own project. There are 
release artifacts in the Jasig maven repository tagged 1.0.0-RC2. The 
area it needs help with right now is documentation, examples of the 
Maven dependency configuration for using the taglib and where to find 
the WAR file. Also some documentation on how to request new resources be 
added to the project.


-Eric

Gary Weaver wrote:
Does anyone else think that it would be a good idea to move to split 
off the uPortal 3.1 resource server as a separate project and download 
from uPortal hosted by JASIG?


http://www.ja-sig.org/wiki/display/UPC/Resource+Server

It seems like it would be a good idea if people would start using it 
for web development (especially for JSR-168/JSR-286 portlet 
development) in such a way that they could have multiple webapps or 
portlets rely on the same versioned resource bundle for similar 
functionality. For example, javascript bugs (like browser 
incompatibilities that may have been missed in testing) could be fixed 
in one place and not require alteration of many custom portlets that 
use similar functionality.


So if I were writing a portlet or any other webapp, you could just say 
in the documentation to configure that portlet/webapp to point at the 
resource server (webapp) wherever it is hosted, and deploy the X and Y 
packages to the server that the portlet/webapp depends on.


It would probably take some work to get it there, but I think that 
more widespread adoption might be key to its success and use. If you 
think this is a bad idea, then how do you propose that the issue of 
duplicated javascript be solved? (and note that having portlets, etc. 
poms depend on the same dependencies that bundle resources means 
having to debuild and redeploy a number of portlets, which is more 
disruptive and difficult than just deploying resource bundles separate 
from portlets.)


Thanks,
Gary

 Original Message 
Subject: Re: [jasig-ue] recommended way of sharing javascript 
between portlets

Date: Tue, 28 Apr 2009 10:04:12 -0400
From: Gary Weaver gary.wea...@duke.edu
Reply-To: jasig...@lists.ja-sig.org
To: jasig...@lists.ja-sig.org
References: 49f1f167.6050...@duke.edu 
2b938a27bb91494ea4223733c3da13fc2d53caa...@arborexch01.utorarbor.utorad.utoronto.ca 
28648_1240604099_zzg0t38drjkgn.00_49f21d9d.2050...@duke.edu 
49f63429.2080...@doit.wisc.edu 
8860_1240925657_zzg0t7q252qu4.00_49f705c9.3040...@duke.edu 
49f70928.9000...@doit.wisc.edu




Could it be offered as a separate download on its own project site in 
JASIG? That would be the best, because then those writing 
JSR168/JSR286 portlets could just include in the install documentation 
that the portlet by default expects to be using the resource server. 
That those using other portals besides uPortal could use it also, but 
more importantly, people would be more likely to use it since they 
wouldn't be as tied to uPortal (since they would need download uPortal 
to get the resource server webapp out of it). Also, if the resource 
server was useful to others outside of just portlet development, they 
could use it also.


Oops- I totally misunderstood about the references in that page to 
web.xml meaning the resource server webapp's web.xml. BTW- is there a 
portlet archetype hosted by JASIG or anyone else? (I know that is 
off-topic, but while on the subject...)


Gary


Eric Dalquist wrote:
It is a stand-alone webapp, all you need to do is deploy the WAR 
along side whatever webapp you want to use it with.


More examples would be great, usage in a static page would simply 
reference the ResourceServer file explicitly in the page, ex: 
*/ResourceServingWebapp/rs/jquery/1.3.1/jquery-1.3.1.js* With the 
catch that you're dependent on the ResourceServingWebapp being 
available then.


This isn't something that is used as an archtype for a project, 
perhaps we need to document that a bit better. You deploy the 
ResourceServingWebapp webapp in your container and then there is a 
JAR you include in your webapp to allow you to use the tag library. 
Thats all, nothing else special about your webapp is needed. uPortal 
3.1 doesn't even bother with the tag library. It just references 
files under /ResourceServingWebapp explicitly and it is a required 
webapp to be deployed alongside uPortal.


-Eric

Gary Weaver wrote:

Eric,

That's perfect! :) !!!

It would be even better if it were available as a standalone 
resource server that could be used for older versions of uPortal and 
other portal servers (maybe make it a separate product, but include 
it with uPortal 3.1 and up).


And the documentation is great! If you could add some more 
copy/pasteable example code to use for config of portlets, etc. in 
http://www.ja-sig.org/wiki/display/UPC/Using+the+Resource+Server 
that would help people get started even faster. (And maybe add that 
a Maven 2 

Re: [uportal-dev] Resource Server as its own 1st-class project

2009-04-29 Thread Gary Weaver

Eric,

Awesome!

Sorry, I had assumed that it was just meant to be for uPortal, instead 
it being considered as a project on the same level as uPortal and CAS 
(which is what I mean by it being its own 1st-class project).


I'll plan to go ahead as soon as I can to download RC2 (from the 
1.0.0-RC2 dir under 
http://developer.jasig.org/repo/content/repositories/m2/org/jasig/resourceserver/resource-server-webapp/ 
) and give it a try.


Some questions:

* Are there examples in uPortal or portlet code/configuration that use 
it already outside of that wiki pages at 
http://www.ja-sig.org/wiki/display/UPC/Resource+Server that we could 
look at?
* Do you think that a new wiki space should be created to keep its 
documentation separate from uPortal, or should there be a generic space 
for documentation for all JASIG sandbox projects that are not uPortal or 
CAS specific?
* Do you think that it needs its own mailing lists, or that there should 
be generic mailing lists for projects like it that are not CAS or 
uPortal specific?
* Is the plan eventually (assuming it is accepted) for a spot to be 
created under the main JASIG page at http://www.jasig.org/ for it?


Thanks for your help,

Gary


Eric Dalquist wrote:

Gary,

It is a separate project: 
https://www.ja-sig.org/svn/sandbox/resource-server/


It has been submitted for incubation as its own project. There are 
release artifacts in the Jasig maven repository tagged 1.0.0-RC2. The 
area it needs help with right now is documentation, examples of the 
Maven dependency configuration for using the taglib and where to find 
the WAR file. Also some documentation on how to request new resources 
be added to the project.


-Eric

Gary Weaver wrote:
Does anyone else think that it would be a good idea to move to split 
off the uPortal 3.1 resource server as a separate project and 
download from uPortal hosted by JASIG?


http://www.ja-sig.org/wiki/display/UPC/Resource+Server

It seems like it would be a good idea if people would start using it 
for web development (especially for JSR-168/JSR-286 portlet 
development) in such a way that they could have multiple webapps or 
portlets rely on the same versioned resource bundle for similar 
functionality. For example, javascript bugs (like browser 
incompatibilities that may have been missed in testing) could be 
fixed in one place and not require alteration of many custom portlets 
that use similar functionality.


So if I were writing a portlet or any other webapp, you could just 
say in the documentation to configure that portlet/webapp to point at 
the resource server (webapp) wherever it is hosted, and deploy the X 
and Y packages to the server that the portlet/webapp depends on.


It would probably take some work to get it there, but I think that 
more widespread adoption might be key to its success and use. If you 
think this is a bad idea, then how do you propose that the issue of 
duplicated javascript be solved? (and note that having portlets, etc. 
poms depend on the same dependencies that bundle resources means 
having to debuild and redeploy a number of portlets, which is more 
disruptive and difficult than just deploying resource bundles 
separate from portlets.)


Thanks,
Gary

 Original Message 
Subject: Re: [jasig-ue] recommended way of sharing javascript 
between portlets

Date: Tue, 28 Apr 2009 10:04:12 -0400
From: Gary Weaver gary.wea...@duke.edu
Reply-To: jasig...@lists.ja-sig.org
To: jasig...@lists.ja-sig.org
References: 49f1f167.6050...@duke.edu 
2b938a27bb91494ea4223733c3da13fc2d53caa...@arborexch01.utorarbor.utorad.utoronto.ca 
28648_1240604099_zzg0t38drjkgn.00_49f21d9d.2050...@duke.edu 
49f63429.2080...@doit.wisc.edu 
8860_1240925657_zzg0t7q252qu4.00_49f705c9.3040...@duke.edu 
49f70928.9000...@doit.wisc.edu




Could it be offered as a separate download on its own project site in 
JASIG? That would be the best, because then those writing 
JSR168/JSR286 portlets could just include in the install 
documentation that the portlet by default expects to be using the 
resource server. That those using other portals besides uPortal could 
use it also, but more importantly, people would be more likely to use 
it since they wouldn't be as tied to uPortal (since they would need 
download uPortal to get the resource server webapp out of it). Also, 
if the resource server was useful to others outside of just portlet 
development, they could use it also.


Oops- I totally misunderstood about the references in that page to 
web.xml meaning the resource server webapp's web.xml. BTW- is there a 
portlet archetype hosted by JASIG or anyone else? (I know that is 
off-topic, but while on the subject...)


Gary


Eric Dalquist wrote:
It is a stand-alone webapp, all you need to do is deploy the WAR 
along side whatever webapp you want to use it with.


More examples would be great, usage in a static page would simply 
reference the ResourceServer file explicitly in the page,