Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [dsdp-mtj-dev] Issue with device rename 
It works fine for me.

-----Original Message-----
From: dsdp-mtj-dev-bounces@xxxxxxxxxxx on behalf of Marques David-wtv368
Sent: Wed 5/27/2009 12:53 PM
To: Mobile Tools for The Java Platform mailing list
Subject: Re: [dsdp-mtj-dev] Issue with device rename
 
Hello All,

    Code committed to SVN. Please take some time to look at it so we make sure I didn't miss anything. Appreciate your help!

Regards,

David Marques

David Marques wrote: 

	Hello Everyone,
	
	    I am working on this now.
	
	Regards,
	
	David Marques
	
	Craig Setera wrote: 

		As I mentioned yesterday, I'm +1 for this solution.
		
		On 5/27/09 10:43 AM, Sandin Diego-WDS057 wrote: 

			+1 for Gorkem proposal. 
			
			-----Original Message-----
			From: dsdp-mtj-dev-bounces@xxxxxxxxxxx on behalf of Marques David-wtv368
			Sent: Tue 5/26/2009 1:47 PM
			To: Mobile Tools for The Java Platform mailing list
			Subject: Re: [dsdp-mtj-dev] Issue with device rename
			 
			Hello All,
			
			    Gorkem, think that your proposal is quite reasonable for now. I vote for disabling the renaming... What does everyone else think ??
			
			Regards,
			
			David Marques
			
			Gorkem Ercan wrote: 
			
				The problems caused by this bug is very severe,  In addition to the reported stuff on the bug reports, once a device is renamed actually the classpath container stops working because MTJRuntime is not aware of the renaming. As a result the java project is left without a midp classpath container. Also the JavaME properties for a project starts throwing NPEs as well. 
				
				I have studied for a fix for the issue. The problem is spread all over because name is used as an identifier on many places and even on most unexpected places. I am convinced that trying to fix this for 1.0 is going to introduce unknown number of bugs. 
				
				I think the best way to proceed for 1.0 is to disable renaming of devices ( remove or make the field read-only on preferences dialog), the functionality does not even come close to working anyway and someone commented that it is not an important feature.
				--
				Gorkem
				
				
				
				
				
				On Tue, May 26, 2009 at 6:42 PM, Dan Murphy <dgemurphy@xxxxxxxxx> <mailto:dgemurphy@xxxxxxxxx>  wrote:
				
			
					As a user, I'd prefer not to have an editor that doesn't open in 1.0, but it's not a trivial fix and I appreciate it's rather late to start introducing too much new code... I'm also not sure how many people do rename the device / group in real life.
					
					
					
					2009/5/26 Craig Setera <craigjunk@xxxxxxxxxx> <mailto:craigjunk@xxxxxxxxxx>  
			
			
						A couple of comments here...
						
						1) There *is* a getIdentifier on device objects now.  This is something that I knew we needed and I added in the previous patch.  It currently just returns the name, but changing that should not affect the API.
						
						2) This problem has existed since EclipseME days.  People have lived with it for quite some time. While it isn't ideal, I'm also not convinced that it is a blocker must-fix issue this late in the game.
						
						What are the thoughts on what would need to change in the API to make this work?  There is the concept of a listener.  Is the thinking that there would be an addListener type method on IDevice?
						
						Craig
						
			
						On 5/26/09 9:36 AM, Paula Gustavo-WGP010 wrote: 
			
							Hi,
			
							 
			
							Currently there are a couple of bugs related to renaming a device. The problem is that now there are no listeners that notify MTJ when a device is renamed on the registry. This causes problems like the ones related at 277078 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=277078> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=277078>   and 276084 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=276084> <https://bugs.eclipse.org/bugs/show_bug.cgi?id=276084>  . In order to solve them, it will probably be required to do changes both on the API and MTJ metadata. And we would also need to add some migrations to import MTJ v0.9.x projects.
			
							 
			
							I would like to get a feedback from the rest of the list about this issue. Can we live with it in a 1.0 or is this a must fix? If this is a must, we will need help to review the change and make sure we don't' break anything.
			
							 
			
							J
			
							gep
			
							________________________________
			
			
							_______________________________________________
							dsdp-mtj-dev mailing list
							dsdp-mtj-dev@xxxxxxxxxxx
							https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
							  
			
			
						_______________________________________________
						dsdp-mtj-dev mailing list
						dsdp-mtj-dev@xxxxxxxxxxx
						https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
						
						
			
			
			
					_______________________________________________
					dsdp-mtj-dev mailing list
					dsdp-mtj-dev@xxxxxxxxxxx
					https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
					
					
			
			
				
				
			________________________________
			
			
				_______________________________________________
				dsdp-mtj-dev mailing list
				dsdp-mtj-dev@xxxxxxxxxxx
				https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
				  
			
			
			
			  
			________________________________


			_______________________________________________
			dsdp-mtj-dev mailing list
			dsdp-mtj-dev@xxxxxxxxxxx
			https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
			  

		________________________________


		_______________________________________________
		dsdp-mtj-dev mailing list
		dsdp-mtj-dev@xxxxxxxxxxx
		https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev
		  


	
	
________________________________


	_______________________________________________
	dsdp-mtj-dev mailing list
	dsdp-mtj-dev@xxxxxxxxxxx
	https://dev.eclipse.org/mailman/listinfo/dsdp-mtj-dev

<<winmail.dat>>

Back to the top