Deprecation summary page

classic Classic list List threaded Threaded
11 messages Options
Clay Fenlason Clay Fenlason
Reply | Threaded
Open this post in threaded view
|

Deprecation summary page

I'd promised I was going to work this up this past weekend, but I've
been sick the last few days, and it's been delayed. Still not quite
finished, but I'm feeling poorly again and need to rest a bit, so I
won't delay circulating the link [1]. The latest on JCR and Static
covers still isn't there.

Comments and other edits of course welcome.

HTH

~Clay

[1] http://confluence.sakaiproject.org//x/EhsQB
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Clay Fenlason Clay Fenlason
Reply | Threaded
Open this post in threaded view
|

Re: Deprecation summary page

Some outstanding questions I'd like to get more comment on:

1) I've led off with a proposed deprecation policy draft. [1] Thoughts
about this?

2) I've tried to represent the JCR and Static Cover issues as well as
I understand them [1], but would welcome clarity from my betters. At
the time of this writing, we're still ping-ponging the issue of
whether to actually flag static covers as deprecated, but seem to have
come to agreement on the rest (retain them, but remove their use from
core code).

3) The Kernel Utils proposal seems to me unhelpfully vague. It does
not, for example, explain if anything will be done for 2.7. I'm
inclined to think that this would be appropriate for kernel 1.2, but
not kernel 1.1 (ie. Sakai 2.7). Is there a list of shovel-ready
3rd-party utils?

4) I confess to a bit of uncertainty about the state of the two
Profile tools. I was under the impression in December [2] that the two
profiles couldn't work together, but it looks like Steve managed to
complete the work that allowed them to do so [3]. And yet something
about Aaron's description of removing remaining dependencies to
Profile 1 makes me wonder if in fact they can still be swapped with
sakai properties. Can someone confirm?

In any event, since Steve says they can work together, I've altered
the proposal to simply say that Profile classic should be stealthed
and marked as deprecated.

~Clay

[1] http://confluence.sakaiproject.org//x/EhsQB
[2] http://n2.nabble.com/Fwd-Building-Sakai-2-7-0-Profile2-v-Profile-tt4155769.html#a4155769
[3] http://confluence.sakaiproject.org/display/MGT/2.7+Deprecations?focusedCommentId=68164488#comment-68164488

On Tue, Mar 23, 2010 at 4:31 PM, Clay Fenlason
<[hidden email]> wrote:

> I'd promised I was going to work this up this past weekend, but I've
> been sick the last few days, and it's been delayed. Still not quite
> finished, but I'm feeling poorly again and need to rest a bit, so I
> won't delay circulating the link [1]. The latest on JCR and Static
> covers still isn't there.
>
> Comments and other edits of course welcome.
>
> HTH
>
> ~Clay
>
> [1] http://confluence.sakaiproject.org//x/EhsQB
>
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
David Horwitz David Horwitz
Reply | Threaded
Open this post in threaded view
|

Re: Deprecation summary page

See bellow
> 3) The Kernel Utils proposal seems to me unhelpfully vague. It does
> not, for example, explain if anything will be done for 2.7. I'm
> inclined to think that this would be appropriate for kernel 1.2, but
> not kernel 1.1 (ie. Sakai 2.7). Is there a list of shovel-ready
> 3rd-party utils?
>
>  
This is in fact a formalization of work that started a while back. Some
methods where marked in 1.0 kernel. All the javadoc deprecation noticed
list the commons-lang method their equivalent to.


> 4) I confess to a bit of uncertainty about the state of the two
> Profile tools. I was under the impression in December [2] that the two
> profiles couldn't work together, but it looks like Steve managed to
> complete the work that allowed them to do so [3]. And yet something
> about Aaron's description of removing remaining dependencies to
> Profile 1 makes me wonder if in fact they can still be swapped with
> sakai properties. Can someone confirm?
>
> In any event, since Steve says they can work together, I've altered
> the proposal to simply say that Profile classic should be stealthed
> and marked as deprecated.
>
> ~Clay
>
> [1] http://confluence.sakaiproject.org//x/EhsQB
> [2] http://n2.nabble.com/Fwd-Building-Sakai-2-7-0-Profile2-v-Profile-tt4155769.html#a4155769
> [3] http://confluence.sakaiproject.org/display/MGT/2.7+Deprecations?focusedCommentId=68164488#comment-68164488
>
> On Tue, Mar 23, 2010 at 4:31 PM, Clay Fenlason
> <[hidden email]> wrote:
>  
>> I'd promised I was going to work this up this past weekend, but I've
>> been sick the last few days, and it's been delayed. Still not quite
>> finished, but I'm feeling poorly again and need to rest a bit, so I
>> won't delay circulating the link [1]. The latest on JCR and Static
>> covers still isn't there.
>>
>> Comments and other edits of course welcome.
>>
>> HTH
>>
>> ~Clay
>>
>> [1] http://confluence.sakaiproject.org//x/EhsQB
>>
>>    
> _______________________________________________
> management mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>  
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Aaron Zeckoski-3 Aaron Zeckoski-3
Reply | Threaded
Open this post in threaded view
|

Re: [Building Sakai] Deprecation summary page

In reply to this post by Clay Fenlason
> 4) I confess to a bit of uncertainty about the state of the two
> Profile tools. I was under the impression in December [2] that the two
> profiles couldn't work together, but it looks like Steve managed to
> complete the work that allowed them to do so [3]. And yet something
> about Aaron's description of removing remaining dependencies to
> Profile 1 makes me wonder if in fact they can still be swapped with
> sakai properties. Can someone confirm?
>
> In any event, since Steve says they can work together, I've altered
> the proposal to simply say that Profile classic should be stealthed
> and marked as deprecated.

The issue is not with profile 1 itself but with other tools like
roster that have a direct dependency on the profile 1 tool. Aside from
tool to tool dependencies being a poor practice it also makes it
impossible for someone to remove the profile 1 tool if they are not
using it (without removing all the tools that depend on it). At an
absolute minimum we need to remove these dependencies.

There isn't really a way to mark a tool as deprecated.

-AZ


On Wed, Mar 24, 2010 at 1:46 PM, Clay Fenlason
<[hidden email]> wrote:

> Some outstanding questions I'd like to get more comment on:
>
> 1) I've led off with a proposed deprecation policy draft. [1] Thoughts
> about this?
>
> 2) I've tried to represent the JCR and Static Cover issues as well as
> I understand them [1], but would welcome clarity from my betters. At
> the time of this writing, we're still ping-ponging the issue of
> whether to actually flag static covers as deprecated, but seem to have
> come to agreement on the rest (retain them, but remove their use from
> core code).
>
> 3) The Kernel Utils proposal seems to me unhelpfully vague. It does
> not, for example, explain if anything will be done for 2.7. I'm
> inclined to think that this would be appropriate for kernel 1.2, but
> not kernel 1.1 (ie. Sakai 2.7). Is there a list of shovel-ready
> 3rd-party utils?
>
> 4) I confess to a bit of uncertainty about the state of the two
> Profile tools. I was under the impression in December [2] that the two
> profiles couldn't work together, but it looks like Steve managed to
> complete the work that allowed them to do so [3]. And yet something
> about Aaron's description of removing remaining dependencies to
> Profile 1 makes me wonder if in fact they can still be swapped with
> sakai properties. Can someone confirm?
>
> In any event, since Steve says they can work together, I've altered
> the proposal to simply say that Profile classic should be stealthed
> and marked as deprecated.
>
> ~Clay
>
> [1] http://confluence.sakaiproject.org//x/EhsQB
> [2] http://n2.nabble.com/Fwd-Building-Sakai-2-7-0-Profile2-v-Profile-tt4155769.html#a4155769
> [3] http://confluence.sakaiproject.org/display/MGT/2.7+Deprecations?focusedCommentId=68164488#comment-68164488
>
> On Tue, Mar 23, 2010 at 4:31 PM, Clay Fenlason
> <[hidden email]> wrote:
>> I'd promised I was going to work this up this past weekend, but I've
>> been sick the last few days, and it's been delayed. Still not quite
>> finished, but I'm feeling poorly again and need to rest a bit, so I
>> won't delay circulating the link [1]. The latest on JCR and Static
>> covers still isn't there.
>>
>> Comments and other edits of course welcome.
>>
>> HTH
>>
>> ~Clay
>>
>> [1] http://confluence.sakaiproject.org//x/EhsQB
>>
> _______________________________________________
> sakai-dev mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>



--
Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Clay Fenlason Clay Fenlason
Reply | Threaded
Open this post in threaded view
|

Re: [Building Sakai] Deprecation summary page

Some comments in-line:

On Wed, Mar 24, 2010 at 10:14 AM, Aaron Zeckoski <[hidden email]> wrote:

>> 4) I confess to a bit of uncertainty about the state of the two
>> Profile tools. I was under the impression in December [2] that the two
>> profiles couldn't work together, but it looks like Steve managed to
>> complete the work that allowed them to do so [3]. And yet something
>> about Aaron's description of removing remaining dependencies to
>> Profile 1 makes me wonder if in fact they can still be swapped with
>> sakai properties. Can someone confirm?
>>
>> In any event, since Steve says they can work together, I've altered
>> the proposal to simply say that Profile classic should be stealthed
>> and marked as deprecated.
>
> The issue is not with profile 1 itself but with other tools like
> roster that have a direct dependency on the profile 1 tool. Aside from
> tool to tool dependencies being a poor practice it also makes it
> impossible for someone to remove the profile 1 tool if they are not
> using it (without removing all the tools that depend on it). At an
> absolute minimum we need to remove these dependencies.
>

Right, but just so I'm clear (though I suspect this isn't really a
question for Aaron, I don't want the question to be lost), is it the
case that:

a) Profile classic is still in 2.7.x?
b) if you unstealth it, it should continue to function as before?

> There isn't really a way to mark a tool as deprecated.

In the policy draft I've put forward, tool deprecation entails:

1) Stealthing the tool
2) Listing it as deprecated in the release notes, and announcing the
same on-list
3) Removing it to contrib in the next feature release, assuming there
aren't extenuating circumstances that would argue for keeping it
around longer (eg. if a migration path still needs to be worked out)

~Clay

>
> On Wed, Mar 24, 2010 at 1:46 PM, Clay Fenlason
> <[hidden email]> wrote:
>> Some outstanding questions I'd like to get more comment on:
>>
>> 1) I've led off with a proposed deprecation policy draft. [1] Thoughts
>> about this?
>>
>> 2) I've tried to represent the JCR and Static Cover issues as well as
>> I understand them [1], but would welcome clarity from my betters. At
>> the time of this writing, we're still ping-ponging the issue of
>> whether to actually flag static covers as deprecated, but seem to have
>> come to agreement on the rest (retain them, but remove their use from
>> core code).
>>
>> 3) The Kernel Utils proposal seems to me unhelpfully vague. It does
>> not, for example, explain if anything will be done for 2.7. I'm
>> inclined to think that this would be appropriate for kernel 1.2, but
>> not kernel 1.1 (ie. Sakai 2.7). Is there a list of shovel-ready
>> 3rd-party utils?
>>
>> 4) I confess to a bit of uncertainty about the state of the two
>> Profile tools. I was under the impression in December [2] that the two
>> profiles couldn't work together, but it looks like Steve managed to
>> complete the work that allowed them to do so [3]. And yet something
>> about Aaron's description of removing remaining dependencies to
>> Profile 1 makes me wonder if in fact they can still be swapped with
>> sakai properties. Can someone confirm?
>>
>> In any event, since Steve says they can work together, I've altered
>> the proposal to simply say that Profile classic should be stealthed
>> and marked as deprecated.
>>
>> ~Clay
>>
>> [1] http://confluence.sakaiproject.org//x/EhsQB
>> [2] http://n2.nabble.com/Fwd-Building-Sakai-2-7-0-Profile2-v-Profile-tt4155769.html#a4155769
>> [3] http://confluence.sakaiproject.org/display/MGT/2.7+Deprecations?focusedCommentId=68164488#comment-68164488
>>
>> On Tue, Mar 23, 2010 at 4:31 PM, Clay Fenlason
>> <[hidden email]> wrote:
>>> I'd promised I was going to work this up this past weekend, but I've
>>> been sick the last few days, and it's been delayed. Still not quite
>>> finished, but I'm feeling poorly again and need to rest a bit, so I
>>> won't delay circulating the link [1]. The latest on JCR and Static
>>> covers still isn't there.
>>>
>>> Comments and other edits of course welcome.
>>>
>>> HTH
>>>
>>> ~Clay
>>>
>>> [1] http://confluence.sakaiproject.org//x/EhsQB
>>>
>> _______________________________________________
>> sakai-dev mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>>
>
>
>
> --
> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
>
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
David Horwitz David Horwitz
Reply | Threaded
Open this post in threaded view
|

Re: [Building Sakai] Deprecation summary page

Hi

> a) Profile classic is still in 2.7.x?
>  
yes
> b) if you unstealth it, it should continue to function as before?
>
>  
Because of the way its used "stealthed" doesn't realy apply to profile
classic. You could leave it in your my workspaces templates and it would
continue to work as before...


D


>> There isn't really a way to mark a tool as deprecated.
>>    
> In the policy draft I've put forward, tool deprecation entails:
>
> 1) Stealthing the tool
> 2) Listing it as deprecated in the release notes, and announcing the
> same on-list
> 3) Removing it to contrib in the next feature release, assuming there
> aren't extenuating circumstances that would argue for keeping it
> around longer (eg. if a migration path still needs to be worked out)
>
> ~Clay
>
>  
>> On Wed, Mar 24, 2010 at 1:46 PM, Clay Fenlason
>> <[hidden email]> wrote:
>>    
>>> Some outstanding questions I'd like to get more comment on:
>>>
>>> 1) I've led off with a proposed deprecation policy draft. [1] Thoughts
>>> about this?
>>>
>>> 2) I've tried to represent the JCR and Static Cover issues as well as
>>> I understand them [1], but would welcome clarity from my betters. At
>>> the time of this writing, we're still ping-ponging the issue of
>>> whether to actually flag static covers as deprecated, but seem to have
>>> come to agreement on the rest (retain them, but remove their use from
>>> core code).
>>>
>>> 3) The Kernel Utils proposal seems to me unhelpfully vague. It does
>>> not, for example, explain if anything will be done for 2.7. I'm
>>> inclined to think that this would be appropriate for kernel 1.2, but
>>> not kernel 1.1 (ie. Sakai 2.7). Is there a list of shovel-ready
>>> 3rd-party utils?
>>>
>>> 4) I confess to a bit of uncertainty about the state of the two
>>> Profile tools. I was under the impression in December [2] that the two
>>> profiles couldn't work together, but it looks like Steve managed to
>>> complete the work that allowed them to do so [3]. And yet something
>>> about Aaron's description of removing remaining dependencies to
>>> Profile 1 makes me wonder if in fact they can still be swapped with
>>> sakai properties. Can someone confirm?
>>>
>>> In any event, since Steve says they can work together, I've altered
>>> the proposal to simply say that Profile classic should be stealthed
>>> and marked as deprecated.
>>>
>>> ~Clay
>>>
>>> [1] http://confluence.sakaiproject.org//x/EhsQB
>>> [2] http://n2.nabble.com/Fwd-Building-Sakai-2-7-0-Profile2-v-Profile-tt4155769.html#a4155769
>>> [3] http://confluence.sakaiproject.org/display/MGT/2.7+Deprecations?focusedCommentId=68164488#comment-68164488
>>>
>>> On Tue, Mar 23, 2010 at 4:31 PM, Clay Fenlason
>>> <[hidden email]> wrote:
>>>      
>>>> I'd promised I was going to work this up this past weekend, but I've
>>>> been sick the last few days, and it's been delayed. Still not quite
>>>> finished, but I'm feeling poorly again and need to rest a bit, so I
>>>> won't delay circulating the link [1]. The latest on JCR and Static
>>>> covers still isn't there.
>>>>
>>>> Comments and other edits of course welcome.
>>>>
>>>> HTH
>>>>
>>>> ~Clay
>>>>
>>>> [1] http://confluence.sakaiproject.org//x/EhsQB
>>>>
>>>>        
>>> _______________________________________________
>>> sakai-dev mailing list
>>> [hidden email]
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>>>
>>>      
>>
>>
>> --
>> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
>>
>>    
> _______________________________________________
> sakai-dev mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>  
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Clay Fenlason Clay Fenlason
Reply | Threaded
Open this post in threaded view
|

Re: [Building Sakai] Deprecation summary page

OK, got it. Thanks.

~Clay

On Wed, Mar 24, 2010 at 10:31 AM, David Horwitz <[hidden email]> wrote:

> Hi
>
>> a) Profile classic is still in 2.7.x?
>>
> yes
>> b) if you unstealth it, it should continue to function as before?
>>
>>
> Because of the way its used "stealthed" doesn't realy apply to profile
> classic. You could leave it in your my workspaces templates and it would
> continue to work as before...
>
>
> D
>
>
>>> There isn't really a way to mark a tool as deprecated.
>>>
>> In the policy draft I've put forward, tool deprecation entails:
>>
>> 1) Stealthing the tool
>> 2) Listing it as deprecated in the release notes, and announcing the
>> same on-list
>> 3) Removing it to contrib in the next feature release, assuming there
>> aren't extenuating circumstances that would argue for keeping it
>> around longer (eg. if a migration path still needs to be worked out)
>>
>> ~Clay
>>
>>
>>> On Wed, Mar 24, 2010 at 1:46 PM, Clay Fenlason
>>> <[hidden email]> wrote:
>>>
>>>> Some outstanding questions I'd like to get more comment on:
>>>>
>>>> 1) I've led off with a proposed deprecation policy draft. [1] Thoughts
>>>> about this?
>>>>
>>>> 2) I've tried to represent the JCR and Static Cover issues as well as
>>>> I understand them [1], but would welcome clarity from my betters. At
>>>> the time of this writing, we're still ping-ponging the issue of
>>>> whether to actually flag static covers as deprecated, but seem to have
>>>> come to agreement on the rest (retain them, but remove their use from
>>>> core code).
>>>>
>>>> 3) The Kernel Utils proposal seems to me unhelpfully vague. It does
>>>> not, for example, explain if anything will be done for 2.7. I'm
>>>> inclined to think that this would be appropriate for kernel 1.2, but
>>>> not kernel 1.1 (ie. Sakai 2.7). Is there a list of shovel-ready
>>>> 3rd-party utils?
>>>>
>>>> 4) I confess to a bit of uncertainty about the state of the two
>>>> Profile tools. I was under the impression in December [2] that the two
>>>> profiles couldn't work together, but it looks like Steve managed to
>>>> complete the work that allowed them to do so [3]. And yet something
>>>> about Aaron's description of removing remaining dependencies to
>>>> Profile 1 makes me wonder if in fact they can still be swapped with
>>>> sakai properties. Can someone confirm?
>>>>
>>>> In any event, since Steve says they can work together, I've altered
>>>> the proposal to simply say that Profile classic should be stealthed
>>>> and marked as deprecated.
>>>>
>>>> ~Clay
>>>>
>>>> [1] http://confluence.sakaiproject.org//x/EhsQB
>>>> [2] http://n2.nabble.com/Fwd-Building-Sakai-2-7-0-Profile2-v-Profile-tt4155769.html#a4155769
>>>> [3] http://confluence.sakaiproject.org/display/MGT/2.7+Deprecations?focusedCommentId=68164488#comment-68164488
>>>>
>>>> On Tue, Mar 23, 2010 at 4:31 PM, Clay Fenlason
>>>> <[hidden email]> wrote:
>>>>
>>>>> I'd promised I was going to work this up this past weekend, but I've
>>>>> been sick the last few days, and it's been delayed. Still not quite
>>>>> finished, but I'm feeling poorly again and need to rest a bit, so I
>>>>> won't delay circulating the link [1]. The latest on JCR and Static
>>>>> covers still isn't there.
>>>>>
>>>>> Comments and other edits of course welcome.
>>>>>
>>>>> HTH
>>>>>
>>>>> ~Clay
>>>>>
>>>>> [1] http://confluence.sakaiproject.org//x/EhsQB
>>>>>
>>>>>
>>>> _______________________________________________
>>>> sakai-dev mailing list
>>>> [hidden email]
>>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>>
>>>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>>>>
>>>>
>>>
>>>
>>> --
>>> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
>>>
>>>
>> _______________________________________________
>> sakai-dev mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>>
>
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Steve Swinsburg-3 Steve Swinsburg-3
Reply | Threaded
Open this post in threaded view
|

Re: [Building Sakai] Deprecation summary page


The actual Profile classic tool can be removed (ie the webapp).  As Aaron pointed out, Roster depends on the Profile classic API, so at the moment, that needs to stay.

Profile2 provides an implementation of the ProfileManager that gets it's data from Profile2, so the Roster can use this instead. This is currently in place and can be switched around via an entry in sakai.properties:

# Set this to tell the ProfileManager to get it's data from Profile2.
# If left unset, any tools that use the ProfileManager from the original profile tool (ie Roster)
# will continue to use the data from org.sakaiproject.api.app.profile.LegacyProfileManager.
# So you must set this to enable the integrations.
# If you are using a version of Sakai prior to 2.7, you need to apply the patch attached to
# http://jira.sakaiproject.org/browse/SAK-17573 in order for this property to have any effect
profile.manager.integration.bean=org.sakaiproject.profile2.legacy.ProfileManager
However, the Roster is still looking at the Profile/ProfileImpl models from the Profile classic API for it's information. Some work needs to be done with the Roster to abstract this part out to somewhere else. 

For now, we should be able to remove the profile classic tool and leave the API.

cheers,
Steve


On 25/03/2010, at 1:34 AM, Clay Fenlason wrote:

OK, got it. Thanks.

~Clay

On Wed, Mar 24, 2010 at 10:31 AM, David Horwitz <[hidden email]> wrote:
Hi

a) Profile classic is still in 2.7.x?

yes
b) if you unstealth it, it should continue to function as before?


Because of the way its used "stealthed" doesn't realy apply to profile
classic. You could leave it in your my workspaces templates and it would
continue to work as before...


D


There isn't really a way to mark a tool as deprecated.

In the policy draft I've put forward, tool deprecation entails:

1) Stealthing the tool
2) Listing it as deprecated in the release notes, and announcing the
same on-list
3) Removing it to contrib in the next feature release, assuming there
aren't extenuating circumstances that would argue for keeping it
around longer (eg. if a migration path still needs to be worked out)

~Clay


On Wed, Mar 24, 2010 at 1:46 PM, Clay Fenlason
<[hidden email]> wrote:

Some outstanding questions I'd like to get more comment on:

1) I've led off with a proposed deprecation policy draft. [1] Thoughts
about this?

2) I've tried to represent the JCR and Static Cover issues as well as
I understand them [1], but would welcome clarity from my betters. At
the time of this writing, we're still ping-ponging the issue of
whether to actually flag static covers as deprecated, but seem to have
come to agreement on the rest (retain them, but remove their use from
core code).

3) The Kernel Utils proposal seems to me unhelpfully vague. It does
not, for example, explain if anything will be done for 2.7. I'm
inclined to think that this would be appropriate for kernel 1.2, but
not kernel 1.1 (ie. Sakai 2.7). Is there a list of shovel-ready
3rd-party utils?

4) I confess to a bit of uncertainty about the state of the two
Profile tools. I was under the impression in December [2] that the two
profiles couldn't work together, but it looks like Steve managed to
complete the work that allowed them to do so [3]. And yet something
about Aaron's description of removing remaining dependencies to
Profile 1 makes me wonder if in fact they can still be swapped with
sakai properties. Can someone confirm?

In any event, since Steve says they can work together, I've altered
the proposal to simply say that Profile classic should be stealthed
and marked as deprecated.

~Clay

[1] http://confluence.sakaiproject.org//x/EhsQB
[2] http://n2.nabble.com/Fwd-Building-Sakai-2-7-0-Profile2-v-Profile-tt4155769.html#a4155769
[3] http://confluence.sakaiproject.org/display/MGT/2.7+Deprecations?focusedCommentId=68164488#comment-68164488

On Tue, Mar 23, 2010 at 4:31 PM, Clay Fenlason
<[hidden email]> wrote:

I'd promised I was going to work this up this past weekend, but I've
been sick the last few days, and it's been delayed. Still not quite
finished, but I'm feeling poorly again and need to rest a bit, so I
won't delay circulating the link [1]. The latest on JCR and Static
covers still isn't there.

Comments and other edits of course welcome.

HTH

~Clay

[1] http://confluence.sakaiproject.org//x/EhsQB


_______________________________________________
sakai-dev mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"




--
Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile


_______________________________________________
sakai-dev mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/sakai-dev

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"


_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"


_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

smime.p7s (4K) Download Attachment
Clay Fenlason Clay Fenlason
Reply | Threaded
Open this post in threaded view
|

Re: [Building Sakai] Deprecation summary page

OK, good to know, but to be clear, I think it's the clear preference
for 2.7 for Profile classic to remain as an option. We have done
nothing in prior releases to signal its departure, and yanking it out
of 2.7 at this stage has the potential to be disruptive. It would be
surprising if someone missed it, but we should operate on that basis.

Post-2.7, we should look at moving it from trunk to contrib. Perhaps
very soon post-2.7.

Incidentally, is Profile 2 *called* 'Profile 2' in 2.7.x (in the
interface)? I think we should label both simply 'Profile,' and leave
it to institutions to configure for the classic version in the
unlikely event they opt to.

~Clay

On Wed, Mar 24, 2010 at 6:08 PM, Steve Swinsburg
<[hidden email]> wrote:

>
> The actual Profile classic tool can be removed (ie the webapp).  As Aaron
> pointed out, Roster depends on the Profile classic API, so at the moment,
> that needs to stay.
> Profile2 provides an implementation of the ProfileManager that gets it's
> data from Profile2, so the Roster can use this instead. This is currently in
> place and can be switched around via an entry in sakai.properties:
>
> # Set this to tell the ProfileManager to get it's data from Profile2.
> # If left unset, any tools that use the ProfileManager from the original
> profile tool (ie Roster)
> # will continue to use the data from
> org.sakaiproject.api.app.profile.LegacyProfileManager.
> # So you must set this to enable the integrations.
> # If you are using a version of Sakai prior to 2.7, you need to apply the
> patch attached to
> # http://jira.sakaiproject.org/browse/SAK-17573 in order for this property
> to have any effect
> profile.manager.integration.bean=org.sakaiproject.profile2.legacy.ProfileManager
>
> However, the Roster is still looking at the Profile/ProfileImpl models from
> the Profile classic API for it's information. Some work needs to be done
> with the Roster to abstract this part out to somewhere else.
> For now, we should be able to remove the profile classic tool and leave the
> API.
> cheers,
> Steve
>
> On 25/03/2010, at 1:34 AM, Clay Fenlason wrote:
>
> OK, got it. Thanks.
>
> ~Clay
>
> On Wed, Mar 24, 2010 at 10:31 AM, David Horwitz <[hidden email]>
> wrote:
>
> Hi
>
> a) Profile classic is still in 2.7.x?
>
> yes
>
> b) if you unstealth it, it should continue to function as before?
>
>
> Because of the way its used "stealthed" doesn't realy apply to profile
>
> classic. You could leave it in your my workspaces templates and it would
>
> continue to work as before...
>
>
> D
>
>
> There isn't really a way to mark a tool as deprecated.
>
> In the policy draft I've put forward, tool deprecation entails:
>
> 1) Stealthing the tool
>
> 2) Listing it as deprecated in the release notes, and announcing the
>
> same on-list
>
> 3) Removing it to contrib in the next feature release, assuming there
>
> aren't extenuating circumstances that would argue for keeping it
>
> around longer (eg. if a migration path still needs to be worked out)
>
> ~Clay
>
>
> On Wed, Mar 24, 2010 at 1:46 PM, Clay Fenlason
>
> <[hidden email]> wrote:
>
> Some outstanding questions I'd like to get more comment on:
>
> 1) I've led off with a proposed deprecation policy draft. [1] Thoughts
>
> about this?
>
> 2) I've tried to represent the JCR and Static Cover issues as well as
>
> I understand them [1], but would welcome clarity from my betters. At
>
> the time of this writing, we're still ping-ponging the issue of
>
> whether to actually flag static covers as deprecated, but seem to have
>
> come to agreement on the rest (retain them, but remove their use from
>
> core code).
>
> 3) The Kernel Utils proposal seems to me unhelpfully vague. It does
>
> not, for example, explain if anything will be done for 2.7. I'm
>
> inclined to think that this would be appropriate for kernel 1.2, but
>
> not kernel 1.1 (ie. Sakai 2.7). Is there a list of shovel-ready
>
> 3rd-party utils?
>
> 4) I confess to a bit of uncertainty about the state of the two
>
> Profile tools. I was under the impression in December [2] that the two
>
> profiles couldn't work together, but it looks like Steve managed to
>
> complete the work that allowed them to do so [3]. And yet something
>
> about Aaron's description of removing remaining dependencies to
>
> Profile 1 makes me wonder if in fact they can still be swapped with
>
> sakai properties. Can someone confirm?
>
> In any event, since Steve says they can work together, I've altered
>
> the proposal to simply say that Profile classic should be stealthed
>
> and marked as deprecated.
>
> ~Clay
>
> [1] http://confluence.sakaiproject.org//x/EhsQB
>
> [2]
> http://n2.nabble.com/Fwd-Building-Sakai-2-7-0-Profile2-v-Profile-tt4155769.html#a4155769
>
> [3]
> http://confluence.sakaiproject.org/display/MGT/2.7+Deprecations?focusedCommentId=68164488#comment-68164488
>
> On Tue, Mar 23, 2010 at 4:31 PM, Clay Fenlason
>
> <[hidden email]> wrote:
>
> I'd promised I was going to work this up this past weekend, but I've
>
> been sick the last few days, and it's been delayed. Still not quite
>
> finished, but I'm feeling poorly again and need to rest a bit, so I
>
> won't delay circulating the link [1]. The latest on JCR and Static
>
> covers still isn't there.
>
> Comments and other edits of course welcome.
>
> HTH
>
> ~Clay
>
> [1] http://confluence.sakaiproject.org//x/EhsQB
>
>
> _______________________________________________
>
> sakai-dev mailing list
>
> [hidden email]
>
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to [hidden email]
> with a subject of "unsubscribe"
>
>
>
>
> --
>
> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
>
>
> _______________________________________________
>
> sakai-dev mailing list
>
> [hidden email]
>
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to [hidden email]
> with a subject of "unsubscribe"
>
>
> _______________________________________________
> management mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to [hidden email]
> with a subject of "unsubscribe"
>
>
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
Steve Swinsburg-3 Steve Swinsburg-3
Reply | Threaded
Open this post in threaded view
|

Re: [Building Sakai] Deprecation summary page

Hi Clay,

Yes everything you said is fine and is the track we are taking with this. See inline.

> clear preference for 2.7 for Profile classic to remain as an option.

I'm fine with leaving in Profile classic as an option, this is why I did the work for both to coexist side by side so that people had the choice.

> Incidentally, is Profile 2 *called* 'Profile 2' in 2.7.x (in the interface)?


The name of the Profile2 tool has been changed to be just 'Profile'.

cheers,
Steve



On 25/03/2010, at 10:01 AM, Clay Fenlason wrote:

> OK, good to know, but to be clear, I think it's the clear preference
> for 2.7 for Profile classic to remain as an option. We have done
> nothing in prior releases to signal its departure, and yanking it out
> of 2.7 at this stage has the potential to be disruptive. It would be
> surprising if someone missed it, but we should operate on that basis.
>
> Post-2.7, we should look at moving it from trunk to contrib. Perhaps
> very soon post-2.7.
>
> Incidentally, is Profile 2 *called* 'Profile 2' in 2.7.x (in the
> interface)? I think we should label both simply 'Profile,' and leave
> it to institutions to configure for the classic version in the
> unlikely event they opt to.
>
> ~Clay
>
> On Wed, Mar 24, 2010 at 6:08 PM, Steve Swinsburg
> <[hidden email]> wrote:
>>
>> The actual Profile classic tool can be removed (ie the webapp).  As Aaron
>> pointed out, Roster depends on the Profile classic API, so at the moment,
>> that needs to stay.
>> Profile2 provides an implementation of the ProfileManager that gets it's
>> data from Profile2, so the Roster can use this instead. This is currently in
>> place and can be switched around via an entry in sakai.properties:
>>
>> # Set this to tell the ProfileManager to get it's data from Profile2.
>> # If left unset, any tools that use the ProfileManager from the original
>> profile tool (ie Roster)
>> # will continue to use the data from
>> org.sakaiproject.api.app.profile.LegacyProfileManager.
>> # So you must set this to enable the integrations.
>> # If you are using a version of Sakai prior to 2.7, you need to apply the
>> patch attached to
>> # http://jira.sakaiproject.org/browse/SAK-17573 in order for this property
>> to have any effect
>> profile.manager.integration.bean=org.sakaiproject.profile2.legacy.ProfileManager
>>
>> However, the Roster is still looking at the Profile/ProfileImpl models from
>> the Profile classic API for it's information. Some work needs to be done
>> with the Roster to abstract this part out to somewhere else.
>> For now, we should be able to remove the profile classic tool and leave the
>> API.
>> cheers,
>> Steve
>>
>> On 25/03/2010, at 1:34 AM, Clay Fenlason wrote:
>>
>> OK, got it. Thanks.
>>
>> ~Clay
>>
>> On Wed, Mar 24, 2010 at 10:31 AM, David Horwitz <[hidden email]>
>> wrote:
>>
>> Hi
>>
>> a) Profile classic is still in 2.7.x?
>>
>> yes
>>
>> b) if you unstealth it, it should continue to function as before?
>>
>>
>> Because of the way its used "stealthed" doesn't realy apply to profile
>>
>> classic. You could leave it in your my workspaces templates and it would
>>
>> continue to work as before...
>>
>>
>> D
>>
>>
>> There isn't really a way to mark a tool as deprecated.
>>
>> In the policy draft I've put forward, tool deprecation entails:
>>
>> 1) Stealthing the tool
>>
>> 2) Listing it as deprecated in the release notes, and announcing the
>>
>> same on-list
>>
>> 3) Removing it to contrib in the next feature release, assuming there
>>
>> aren't extenuating circumstances that would argue for keeping it
>>
>> around longer (eg. if a migration path still needs to be worked out)
>>
>> ~Clay
>>
>>
>> On Wed, Mar 24, 2010 at 1:46 PM, Clay Fenlason
>>
>> <[hidden email]> wrote:
>>
>> Some outstanding questions I'd like to get more comment on:
>>
>> 1) I've led off with a proposed deprecation policy draft. [1] Thoughts
>>
>> about this?
>>
>> 2) I've tried to represent the JCR and Static Cover issues as well as
>>
>> I understand them [1], but would welcome clarity from my betters. At
>>
>> the time of this writing, we're still ping-ponging the issue of
>>
>> whether to actually flag static covers as deprecated, but seem to have
>>
>> come to agreement on the rest (retain them, but remove their use from
>>
>> core code).
>>
>> 3) The Kernel Utils proposal seems to me unhelpfully vague. It does
>>
>> not, for example, explain if anything will be done for 2.7. I'm
>>
>> inclined to think that this would be appropriate for kernel 1.2, but
>>
>> not kernel 1.1 (ie. Sakai 2.7). Is there a list of shovel-ready
>>
>> 3rd-party utils?
>>
>> 4) I confess to a bit of uncertainty about the state of the two
>>
>> Profile tools. I was under the impression in December [2] that the two
>>
>> profiles couldn't work together, but it looks like Steve managed to
>>
>> complete the work that allowed them to do so [3]. And yet something
>>
>> about Aaron's description of removing remaining dependencies to
>>
>> Profile 1 makes me wonder if in fact they can still be swapped with
>>
>> sakai properties. Can someone confirm?
>>
>> In any event, since Steve says they can work together, I've altered
>>
>> the proposal to simply say that Profile classic should be stealthed
>>
>> and marked as deprecated.
>>
>> ~Clay
>>
>> [1] http://confluence.sakaiproject.org//x/EhsQB
>>
>> [2]
>> http://n2.nabble.com/Fwd-Building-Sakai-2-7-0-Profile2-v-Profile-tt4155769.html#a4155769
>>
>> [3]
>> http://confluence.sakaiproject.org/display/MGT/2.7+Deprecations?focusedCommentId=68164488#comment-68164488
>>
>> On Tue, Mar 23, 2010 at 4:31 PM, Clay Fenlason
>>
>> <[hidden email]> wrote:
>>
>> I'd promised I was going to work this up this past weekend, but I've
>>
>> been sick the last few days, and it's been delayed. Still not quite
>>
>> finished, but I'm feeling poorly again and need to rest a bit, so I
>>
>> won't delay circulating the link [1]. The latest on JCR and Static
>>
>> covers still isn't there.
>>
>> Comments and other edits of course welcome.
>>
>> HTH
>>
>> ~Clay
>>
>> [1] http://confluence.sakaiproject.org//x/EhsQB
>>
>>
>> _______________________________________________
>>
>> sakai-dev mailing list
>>
>> [hidden email]
>>
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to [hidden email]
>> with a subject of "unsubscribe"
>>
>>
>>
>>
>> --
>>
>> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
>>
>>
>> _______________________________________________
>>
>> sakai-dev mailing list
>>
>> [hidden email]
>>
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to [hidden email]
>> with a subject of "unsubscribe"
>>
>>
>> _______________________________________________
>> management mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/management
>>
>> TO UNSUBSCRIBE: send email to [hidden email]
>> with a subject of "unsubscribe"
>>
>>
> _______________________________________________
> management mailing list
> [hidden email]
> http://collab.sakaiproject.org/mailman/listinfo/management
>
> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"

smime.p7s (4K) Download Attachment
Clay Fenlason Clay Fenlason
Reply | Threaded
Open this post in threaded view
|

Re: [Building Sakai] Deprecation summary page

Terrific. Thanks for your extra work that went toward this peaceful coexistence.

~Clay

On Wed, Mar 24, 2010 at 7:09 PM, Steve Swinsburg
<[hidden email]> wrote:

> Hi Clay,
>
> Yes everything you said is fine and is the track we are taking with this. See inline.
>
>> clear preference for 2.7 for Profile classic to remain as an option.
>
> I'm fine with leaving in Profile classic as an option, this is why I did the work for both to coexist side by side so that people had the choice.
>
>> Incidentally, is Profile 2 *called* 'Profile 2' in 2.7.x (in the interface)?
>
>
> The name of the Profile2 tool has been changed to be just 'Profile'.
>
> cheers,
> Steve
>
>
>
> On 25/03/2010, at 10:01 AM, Clay Fenlason wrote:
>
>> OK, good to know, but to be clear, I think it's the clear preference
>> for 2.7 for Profile classic to remain as an option. We have done
>> nothing in prior releases to signal its departure, and yanking it out
>> of 2.7 at this stage has the potential to be disruptive. It would be
>> surprising if someone missed it, but we should operate on that basis.
>>
>> Post-2.7, we should look at moving it from trunk to contrib. Perhaps
>> very soon post-2.7.
>>
>> Incidentally, is Profile 2 *called* 'Profile 2' in 2.7.x (in the
>> interface)? I think we should label both simply 'Profile,' and leave
>> it to institutions to configure for the classic version in the
>> unlikely event they opt to.
>>
>> ~Clay
>>
>> On Wed, Mar 24, 2010 at 6:08 PM, Steve Swinsburg
>> <[hidden email]> wrote:
>>>
>>> The actual Profile classic tool can be removed (ie the webapp).  As Aaron
>>> pointed out, Roster depends on the Profile classic API, so at the moment,
>>> that needs to stay.
>>> Profile2 provides an implementation of the ProfileManager that gets it's
>>> data from Profile2, so the Roster can use this instead. This is currently in
>>> place and can be switched around via an entry in sakai.properties:
>>>
>>> # Set this to tell the ProfileManager to get it's data from Profile2.
>>> # If left unset, any tools that use the ProfileManager from the original
>>> profile tool (ie Roster)
>>> # will continue to use the data from
>>> org.sakaiproject.api.app.profile.LegacyProfileManager.
>>> # So you must set this to enable the integrations.
>>> # If you are using a version of Sakai prior to 2.7, you need to apply the
>>> patch attached to
>>> # http://jira.sakaiproject.org/browse/SAK-17573 in order for this property
>>> to have any effect
>>> profile.manager.integration.bean=org.sakaiproject.profile2.legacy.ProfileManager
>>>
>>> However, the Roster is still looking at the Profile/ProfileImpl models from
>>> the Profile classic API for it's information. Some work needs to be done
>>> with the Roster to abstract this part out to somewhere else.
>>> For now, we should be able to remove the profile classic tool and leave the
>>> API.
>>> cheers,
>>> Steve
>>>
>>> On 25/03/2010, at 1:34 AM, Clay Fenlason wrote:
>>>
>>> OK, got it. Thanks.
>>>
>>> ~Clay
>>>
>>> On Wed, Mar 24, 2010 at 10:31 AM, David Horwitz <[hidden email]>
>>> wrote:
>>>
>>> Hi
>>>
>>> a) Profile classic is still in 2.7.x?
>>>
>>> yes
>>>
>>> b) if you unstealth it, it should continue to function as before?
>>>
>>>
>>> Because of the way its used "stealthed" doesn't realy apply to profile
>>>
>>> classic. You could leave it in your my workspaces templates and it would
>>>
>>> continue to work as before...
>>>
>>>
>>> D
>>>
>>>
>>> There isn't really a way to mark a tool as deprecated.
>>>
>>> In the policy draft I've put forward, tool deprecation entails:
>>>
>>> 1) Stealthing the tool
>>>
>>> 2) Listing it as deprecated in the release notes, and announcing the
>>>
>>> same on-list
>>>
>>> 3) Removing it to contrib in the next feature release, assuming there
>>>
>>> aren't extenuating circumstances that would argue for keeping it
>>>
>>> around longer (eg. if a migration path still needs to be worked out)
>>>
>>> ~Clay
>>>
>>>
>>> On Wed, Mar 24, 2010 at 1:46 PM, Clay Fenlason
>>>
>>> <[hidden email]> wrote:
>>>
>>> Some outstanding questions I'd like to get more comment on:
>>>
>>> 1) I've led off with a proposed deprecation policy draft. [1] Thoughts
>>>
>>> about this?
>>>
>>> 2) I've tried to represent the JCR and Static Cover issues as well as
>>>
>>> I understand them [1], but would welcome clarity from my betters. At
>>>
>>> the time of this writing, we're still ping-ponging the issue of
>>>
>>> whether to actually flag static covers as deprecated, but seem to have
>>>
>>> come to agreement on the rest (retain them, but remove their use from
>>>
>>> core code).
>>>
>>> 3) The Kernel Utils proposal seems to me unhelpfully vague. It does
>>>
>>> not, for example, explain if anything will be done for 2.7. I'm
>>>
>>> inclined to think that this would be appropriate for kernel 1.2, but
>>>
>>> not kernel 1.1 (ie. Sakai 2.7). Is there a list of shovel-ready
>>>
>>> 3rd-party utils?
>>>
>>> 4) I confess to a bit of uncertainty about the state of the two
>>>
>>> Profile tools. I was under the impression in December [2] that the two
>>>
>>> profiles couldn't work together, but it looks like Steve managed to
>>>
>>> complete the work that allowed them to do so [3]. And yet something
>>>
>>> about Aaron's description of removing remaining dependencies to
>>>
>>> Profile 1 makes me wonder if in fact they can still be swapped with
>>>
>>> sakai properties. Can someone confirm?
>>>
>>> In any event, since Steve says they can work together, I've altered
>>>
>>> the proposal to simply say that Profile classic should be stealthed
>>>
>>> and marked as deprecated.
>>>
>>> ~Clay
>>>
>>> [1] http://confluence.sakaiproject.org//x/EhsQB
>>>
>>> [2]
>>> http://n2.nabble.com/Fwd-Building-Sakai-2-7-0-Profile2-v-Profile-tt4155769.html#a4155769
>>>
>>> [3]
>>> http://confluence.sakaiproject.org/display/MGT/2.7+Deprecations?focusedCommentId=68164488#comment-68164488
>>>
>>> On Tue, Mar 23, 2010 at 4:31 PM, Clay Fenlason
>>>
>>> <[hidden email]> wrote:
>>>
>>> I'd promised I was going to work this up this past weekend, but I've
>>>
>>> been sick the last few days, and it's been delayed. Still not quite
>>>
>>> finished, but I'm feeling poorly again and need to rest a bit, so I
>>>
>>> won't delay circulating the link [1]. The latest on JCR and Static
>>>
>>> covers still isn't there.
>>>
>>> Comments and other edits of course welcome.
>>>
>>> HTH
>>>
>>> ~Clay
>>>
>>> [1] http://confluence.sakaiproject.org//x/EhsQB
>>>
>>>
>>> _______________________________________________
>>>
>>> sakai-dev mailing list
>>>
>>> [hidden email]
>>>
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to [hidden email]
>>> with a subject of "unsubscribe"
>>>
>>>
>>>
>>>
>>> --
>>>
>>> Aaron Zeckoski - Software Engineer - http://tinyurl.com/azprofile
>>>
>>>
>>> _______________________________________________
>>>
>>> sakai-dev mailing list
>>>
>>> [hidden email]
>>>
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to [hidden email]
>>> with a subject of "unsubscribe"
>>>
>>>
>>> _______________________________________________
>>> management mailing list
>>> [hidden email]
>>> http://collab.sakaiproject.org/mailman/listinfo/management
>>>
>>> TO UNSUBSCRIBE: send email to [hidden email]
>>> with a subject of "unsubscribe"
>>>
>>>
>> _______________________________________________
>> management mailing list
>> [hidden email]
>> http://collab.sakaiproject.org/mailman/listinfo/management
>>
>> TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"
>
>
_______________________________________________
management mailing list
[hidden email]
http://collab.sakaiproject.org/mailman/listinfo/management

TO UNSUBSCRIBE: send email to [hidden email] with a subject of "unsubscribe"