Deprecation summary page
Locked
 
|
Clay Fenlason |
Deprecation summary page
|
|
|
Clay Fenlason |
Re: Deprecation summary page
|
|
|
|
David Horwitz |
Re: Deprecation summary page
|
|
|
|
Aaron Zeckoski-3 |
Re: [Building Sakai] Deprecation summary page
|
|
|
|
Clay Fenlason |
Re: [Building Sakai] Deprecation summary page
|
|
|
|
David Horwitz |
Re: [Building Sakai] Deprecation summary page
|
|
|
|
Clay Fenlason |
Re: [Building Sakai] Deprecation summary page
|
|
|
|
Steve Swinsburg-3 |
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:
_______________________________________________ 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) |
|
Clay Fenlason |
Re: [Building Sakai] Deprecation summary page
|
|
|
|
Steve Swinsburg-3 |
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" |
|
|
Clay Fenlason |
Re: [Building Sakai] Deprecation summary page
|
|
| Free forum by Nabble | Edit this page |