Bug 334448

Comment 1 Scott Lewis 2011-01-14 21:59:45 EST

Fix released to master.

Comment 2 Markus Kuppe 2011-01-15 02:20:24 EST

Why has all the code in remoteservice.ui been commented? IMO if there is still code referring those constants, they shouldn't be removed. 

Generally I would assume that they would be deprecate first for a release cycle.

Comment 3 Scott Lewis 2011-01-15 10:19:14 EST

(In reply to comment #2)
> Why has all the code in remoteservice.ui been commented? IMO if there is still
> code referring those constants, they shouldn't be removed. 
> 
> Generally I would assume that they would be deprecate first for a release
> cycle.

Well, I would like to remove the constants that are only referred to in remoteservice.ui in our codebase...since these constants are effectively obsolete with OSGi remote services and potentially could create a lot of confusion.  Since this is a major release for the remoteservice API (for other reasons) it makes sense to do it now.  

I've also obsoleted the example that is on the 'sending' side of the remoteservice.ui.

Deprecation is possible...with actual removal in a future major version change...and perhaps that's the way to go.  But I was thinking that a major release change wasn't to be wasted.

Comment 4 Markus Kuppe 2011-01-15 14:44:36 EST

(In reply to comment #3)

> Well, I would like to remove the constants that are only referred to in
> remoteservice.ui in our codebase...since these constants are effectively
> obsolete with OSGi remote services and potentially could create a lot of
> confusion.  Since this is a major release for the remoteservice API (for other
> reasons) it makes sense to do it now.  
> 
> I've also obsoleted the example that is on the 'sending' side of the
> remoteservice.ui.
> 
> Deprecation is possible...with actual removal in a future major version
> change...and perhaps that's the way to go.  But I was thinking that a major
> release change wasn't to be wasted.

I'm fine with removing the constants (eventually). But please do not break the remoteservice.ui in the process. If we don't have the resources currently to adapt remoteservce.ui to newly introduced constants, I say let the old ones stay and deprecate 'em.

Comment 5 Scott Lewis 2011-01-15 15:13:47 EST

(In reply to comment #4)
> (In reply to comment #3)

> 
> I'm fine with removing the constants (eventually). But please do not break the
> remoteservice.ui in the process. If we don't have the resources currently to
> adapt remoteservce.ui to newly introduced constants, I say let the old ones
> stay and deprecate 'em.

My main reason for wanting to remove the remoteservice ui code is that with the constants deprecated as well as the example environment info server removed (which I've done) the unmodified remoteservice ui code is not just useless...it's actually sort of misdirecting...because it uses and depends upon deprecated constants. 

As you say, I don't have time right away to fix the remoteservice ui code (and the way to fix it would be to use/depend upon the OSGi remote services admin EndpointDescription class)...so I'm willing to replace the old Constants, deprecate them and put back the remote service ui as you say...but I'm still a little leary about that...because it basically leaves functionality in remoteservice ui that won't work with anything, and it also uses and presents  a mechanism to do something (discover remote services) that is non-standard...when a standard mechanism now exists in ECF.  That's the confusing part.

Comment 6 Scott Lewis 2011-01-15 16:16:11 EST

As discussed, I've added back the code in remoteservice.ui, as well as the constants in Constants.java.  I've marked all of these constants as deprecated.

released to master.