This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.

Bug 31061

Summary: VCS operations do not work on locales
Product: utilities Reporter: Martin Entlicher <mentlicher>
Component: PropertiesAssignee: issues@utilities <issues>
Status: RESOLVED FIXED    
Severity: blocker CC: dstrupl, jglick
Priority: P3    
Version: 3.x   
Hardware: Sun   
OS: Solaris   
Issue Type: DEFECT Exception Reporter:
Bug Depends on: 16389, 48263    
Bug Blocks:    
Attachments: The exception thrown on rename of a locale.

Description Martin Entlicher 2003-02-14 11:20:59 UTC
Expand a property DataObject, that contains more
locales.
Select one locale and choose Rename from the popup
menu.
The exception is thrown.

It seems, that the list of actions is the same as
on the DataObject node. Is this really supposed to
work or is it just a bug?
There're also filesystem actions. This brings VCS
actions to individual locales, which is good. But
unfortunately these actions act on all locales in
the properties DataObject regardless on which
locale was selected, this is a bug.
Comment 1 Martin Entlicher 2003-02-14 11:22:43 UTC
Created attachment 8957 [details]
The exception thrown on rename of a locale.
Comment 2 _ pkuzel 2003-02-24 10:55:11 UTC
Typical FilterNode surprise in NodeAction, no one is safe from them :-).

Code reads that properties module tries to simulate its secondary
files as standalone data objects. It means that it creates
AbstractNodes for them that provide FileSystemAction, etc.

What machinery do VCS actions use? I guess they grab DataObject cookie
then list all files and perform an action over them. Is it public
contract? Then I can return a FilteringDataObject that lists as
primary file actual locale, hidding its secondaries.
Comment 3 _ pkuzel 2003-02-25 15:50:10 UTC
The exception is eliminated.

VCS operations on single locales is a low priority bug.
Comment 4 Martin Entlicher 2003-03-06 12:11:31 UTC
> What machinery do VCS actions use? I guess they grab DataObject
> cookie then list all files and perform an action over them. Is it
> public contract?

Yes, exactly.

> Then I can return a FilteringDataObject that lists as  primary file
> actual locale, hidding its secondaries.

Yes, this looks like a good solution.
Comment 5 Martin Entlicher 2003-03-06 12:17:25 UTC
*** Issue 30453 has been marked as a duplicate of this issue. ***
Comment 6 _ pkuzel 2003-03-06 13:44:19 UTC
I'm not sure if can create the filtering DataObject under current data
systems. FileObjects are already recognized by master DataObject so I
cannot construct 

public DataObject(FileObject pf, DataLoader loader) throws
DataObjectExistsException

because it always throws DataObjectExistsException.

David does the new datasystems address it?
Martin will CVS stick forever with DataObjects instead of file objects
or defining a FileObjectCookie?
Comment 7 Martin Entlicher 2003-03-06 13:52:47 UTC
> will CVS stick forever with DataObjects instead of file objects
> or defining a FileObjectCookie?

I know nothing about FileObjectCookie. VCS modules work on
FileObjects, but the VCS action must get the FileObjects from
somewhere. Currently the only way goes through selected Nodes ->
DataObjects -> FileObjects. It depends on the new DataSystems design
how this path will change. I can use whatever approach that gives me
currently selected FileObjects at the end.
Comment 8 _ pkuzel 2003-03-06 13:58:11 UTC
virtual FileObjectsCookie:

  public FileObject[] getFileObjects();

You could grab it in your NodeAction and tralala... DataNode would
automatically delegate to DataObject.

You can fill it as an API request against openide.
Comment 9 Jesse Glick 2003-03-18 10:13:32 UTC
Ken F. - not an I18N issue, this is just a plain code bug.

Possible new Datasystems II would solve this sort of thing
automatically - you would just get FileObject's directly from the
node's lookup.
Comment 10 _ pkuzel 2003-03-18 10:17:00 UTC
Jesse do you have specifics issue number to establish dependency on.
16389 is too general.
Comment 11 Jesse Glick 2003-03-18 10:54:17 UTC
There is no more specific issue number currently. Ask dkonecny to file
some issues under the #16389 umbrella if you think it's important.
Comment 12 _ pkuzel 2003-03-18 14:34:35 UTC
I have updated issue 16389 to point to the most recent proposal.
Comment 13 Jaroslav Tulach 2008-04-04 15:57:18 UTC
I guess this is fixed with new vcs, is it not?
Comment 14 Marian Petras 2008-04-16 15:19:14 UTC
This was fixed in the new integration of versioning systems into NB 5.0.