I'd like to see the following for bookmarks and for 'birthing' projects in general.

- The project should be maven based and follow the outline here http://www.ja-sig.org/wiki/x/QgIl -- Along these lines project leads need SSH access to the ja-sig.org machine to publish maven artifacts & sites - The 'main' web-presence for the project should be in confluence, weather a whole space or just a set of pages in the Portlets/Channels/Services spaces - The project confluence presence should link to the maven generated site. The separation here is that the confluence space is more end user documentation where as the maven site is generated developer documentation.
- Lists should be created, as JimH stated this is a very cheap process.
- A Jira project should be created for the project.

Bookmarks has all of this except a more focused presence in Confluence and mailing lists. Things we can solve this week.

-Eric

PS: I'd like to get feedback on that list and stick it in the wiki eventually.



Chris Doyle wrote:

I would very much love to see this project break out of the aforementioned “trappings of projectness” as well, yes. Is there a venue preference for its web presence (wiki vs. http://www.ja-sig.org/products/portlets/bookmarks/)? I’m a fan of cleaning up the Channels and Portlets spaces in the wiki, following suit with the great work being done in the uPortal manual space. I’m also a fan of creating supporting e-mail lists for such projects, so long as it doesn’t create more of an administrative burden than it’s worth. Any thoughts on naming convention for such lists (<project>@lists.ja-sig.org)?

--Chris

*From:* [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] *On Behalf Of *Andrew Petro
*Sent:* Saturday, June 02, 2007 1:14 PM
*To:* [email protected]
*Subject:* Re: [uportal-dev] Bookmarks Portlet

Chris,


The incremental approach sounds best, yes.  I have no problem being
listed as the project lead, so long as it's okay with everyone else.

+1 [1] for an incremental approach involving making these improvements in bookmarks /trunk and frequently tagging and releasing working code.

Thanks to some last-minute assistance by Eric and others, this Bookmarks Portlet will ship with uPortal 2.6.0 as an example showcasing the JSR-168 support. I'd love to see it be feasible to include updated versions of the portlet in subsequent patch releases of 2.6.

Chris, per our discussion at the JHU dev meeting, I wonder if this is an opportunity to build out the "trappings of projectness" around this project -- a clearer web presence, whether in confluence or at http://www.ja-sig.org/products/portlets/bookmarks/. Email list(s) dedicated to discussing developing and deploying this portlet could help to give it identity?

Andrew

[1]: (including the Apache sense of implicit volunteerism to help if necessary)

-----Original Message-----
From: [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>
[mailto:[EMAIL PROTECTED] On Behalf Of Eric
Dalquist
Sent: Saturday, June 02, 2007 9:44 AM
To: [email protected] <mailto:[email protected]>
Subject: Re: [uportal-dev] Bookmarks Portlet
Sounds wonderful Chris. With the current place bookmarks is I think you can probably do the development in the trunk. If we need to fix something in 1.0.7 we can just branch back there and fix it. My first thought as to how to approach the changes would be in an incremental fashion so things still work after each change. That may not be possible for all changes but it is a noble goal :) Also would you be interested in being listed as the project lead for bookmarks? All that means is you get to cut releases (or delegate that responsibility) and manage the Jira project. Thanks for the interest in moving bookmarks forward.
-Eric
Chris Doyle wrote:
    I just wanted to give everyone a quick heads-up regarding some work I

am
    interested in tackling (pending the groups' blessings, of course).

Last
    year I began working on (yet another) Bookmarks Portlet here at JHU,

    which was prior to my awareness of Eric's.  At the developer's meeting

    in April, I shared my progress with Eric and we agreed it might be

    beneficial to try and merge some of the more useful features of mine

in
    with his.  Most notably, I have implemented features that address the

    following open issues:

      PBOOK-7    Drag and drop folder and bookmark moving

      PBOOK-24   Seeding the bookmarks portlet

      PBOOK-25   Multiply publishable

      PBOOK-26   Multiply subscribable (*partially begun work on

    subscription mechanism)

      PBOOK-27   Read-only, administrator updatable mode

      PBOOK-29   CBookmarks upgrade path

      PBOOK-42   Provide a user option for default folder state

    To begin this work, I'd like to create a new working development

branch
    in SVN:

    https://www.ja-sig.org/svn/portlets/BookmarksPortlet/branches/JHU

    I don't anticipate being able to complete the merge in time for the

    upcoming conference, but would like to aim for a release later this

    summer.  How does this all sound to everyone?

    Just a little background on my current version...

      - It's already Maven-ized (using Maven2)

      - I use the Spring Portlet MVC (the project is very Spring-y in

    general)

      - I use the concept of "groupings" or sets of bookmarks:

             - Conceptually, one XBEL document = one grouping

             - Groupings can be "pushed" to specific uPortal

    users/groups

             - Administration of groupings can be delegated to

    specific users/groups

             - Groupings can be set to read-only

      - There are some nice portlet parameters for configuration

      - I have written some web services around it using Axis2

             - I developed and use both a Java client, as well as a

    JS client via AJAX

             - due to AJAX web service calls, there are very few

    actual page reloads

      - I wrote a conversion utility used to upgrade from CBookmarks

      - Caching using ehcache

      - The UI is pretty nice (floating DIVs for input, dropdown

    menus, etc.)

      - Drag and Drop!  :)

    All that being said, there are also some major deficiencies,

    limitations, and definitely some portability obstacles to be

addressed.
    (Everything is a constant work in progress, right?)  But I think I

might
    be ambitious (or crazy) enough to give this merge a try.

    Thoughts?  Blessings?  Curses?

    Thanks,

    --Chris

--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in 
Denver, CO USA.
Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity 
Management, and Open Source
For more information & registration visit: http://www.ja-sig.org/conferences/07summer/index.html
---
You are currently subscribed to [email protected] 
<mailto:[email protected]> as: %%emailaddr%%.
To unsubscribe send a blank email to [EMAIL PROTECTED] <mailto:[EMAIL 
PROTECTED]>


--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in Denver, CO USA.

Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity Management, and Open Source

For more information & registration visit: http://www.ja-sig.org/conferences/07summer/index.html
---
You are currently subscribed to [email protected] as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED]


--
Join your friends and colleagues at JA-SIG with Altitude: June 24-27, 2007 in Denver, CO USA.

Featuring keynotes by: Phil Windley, Matt Raible, Matt Asay
Sessions on topics including: CAS, uPortal, Portlets, Sakai, Identity Management, and Open Source

For more information & registration visit: http://www.ja-sig.org/conferences/07summer/index.html
---
You are currently subscribed to [email protected] as: %%emailaddr%%. To unsubscribe send a blank email to [EMAIL PROTECTED]

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature

Reply via email to