Created attachment 106440 [details]
stacktrace

Subversion module prevents from creation of DataObject for .svn metadata files. OthersRootChildren tries to create such a DO (although the folder is hidden). Could that be evaded in maven?

The node displays configured resource roots for the project. I have no clue why $basedir/.svn/ would have been listed there. I tried opening ejb/ejb-container from my GFv3 checkout without problems.

The immediate bug is that DataFolder.findFolder throws an IAE for an argument which is indeed a folder, contrary to its documentation. If the DataObject.find fails, or does not return a DataFolder, then findFolder should construct a DataFolder anyway.

I improved the javadoc in ergonomics#6a9e9c0d5bbb. Now the caller needs to deal with it.

There is then no way of predicting which folder-type FileObject's findFolder will accept, so the caller needs to catch IllegalArgumentException - this is not a very helpful API.

As I said, I was unable to reproduce the problem and can't guess at how to do so.

True, the IAE is not nice API contract. Too bad we did not keep the DataObjectNotFoundEx in the signature.

In NetBeans IDE 7.0 the IAE can only be thrown for folder which are not visible according to VisibilityQueury.

(In reply to comment #6)
> Too bad we did not keep the DataObjectNotFoundEx in the signature.

And the problem could not be fixed as I suggested before, by creating a DataFolder not in the pool: DataFolder.<init>(FileObject) just throws an exception, meaning it would be better deleted than left there but nonfunctional.

> In NetBeans IDE 7.0 the IAE can only be thrown for folder which are not visible
> according to VisibilityQuery.

Thanks for the tip - by disproving this claim I found how to reproduce the bug! If in Tools > Options > Miscellaneous > Files you set Ignored Files Pattern to e.g. ^stoopid$ and then open e.g. nbm-maven-plugin, you get tons of exceptions - not just from here, but from the package view, etc. This is because various bits of code look for visible subdirs and then try to create folder nodes for them. (Obviously this is a user error, but one we should defend better against.)

What this says to me is that SvnMetadataFolderLoader either should not exist, or should be accompanied by a VQI which always treats .svn dirs as invisible, regardless of user settings. It seems there is already SubversionVisibilityQuery but apparently it doesn't work.

> What this says to me is that SvnMetadataFolderLoader either should not exist,
> or should be accompanied by a VQI which always treats .svn dirs as invisible,
> regardless of user settings. It seems there is already
> SubversionVisibilityQuery but apparently it doesn't work.
it happend that the visibility of vcs metadata was always handled by the ignore (visibility?) settings in Tools > Options > Miscellaneous > Files. On top of it some vcs systems implement a VQ which handles additional, more complex logic - e.g. hide svn removed folders until they are committed and vanish from the local disk. On the other hand - e.g. Mercurial implements no visibility query.

we can hide the .svn|_svn via SubversionVQ but from what i've tried, the the exception appears anyway...

(In reply to comment #8)
> Mercurial implements no visibility query.

Probably should - hide the .hg folder. Anyway it is much less likely for this to matter for Hg (or Git) since metadata is all at the top level, not inside the package tree.

> we can hide the .svn|_svn via SubversionVQ but from what i've tried, the the
> exception appears anyway...

Check what VisibilityQuery actually returns.

> Check what VisibilityQuery actually returns.
false and .svn and anything bellow isn't visible in the IDE. ignored patterns are set to ^stoopka$

Well if you still see exceptions in that case, maybe it's a different bug.

Integrated into 'main-golden', will be available in build *201103020001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/6a9e9c0d5bbb
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #195985: Documenting when IllegalStateException is thrown in greater detail

*** Bug 195917 has been marked as a duplicate of this bug. ***

(In reply to comment #11)
> Well if you still see exceptions in that case, maybe it's a different bug.
right - it had a different stacktrace

few other things related to the vcs visibility queries:
1.) there is 1 VcsVisibilityQueryImplementation registered in the lookup which delegates to the relevant vcs system for a given file. This proces might take some time due to eventual disk access in VCSManager as well as because of the slow isVisible() execution in the particular vcs system. Therefore vcsVQ.isVisible() returns an optimistic fake true (or a cached value if available), asynchronously checks for the real value and fires visibility changed if necessary. 

As for now the described mechanism works fine:
A) we typically have to deal only with a few deleted folders, so caching only a few values etc. 
B) it doesn't really hurt to return true for a svn deleted folder and reevaluate a moment later

From now on:
ad A) we would have to deal with a lot more .svn folders. Might have some impact in the IDE...
ab B) we always have to return false for .svn so the necessary evaluation can't be made asynchronously as described in 1.)

2.) hiding svn metadata via svnVQ wouldn't work for cases of mixed vcs setups - e.g. hgsvn (see also http://netbeans.org/bugzilla/show_bug.cgi?id=174305) as the VcsVisibilityQueryImplementation would delegate only to the hgVQ.

- simply adding if(isMetadata(file)) into the current svnVQ wouldn't work at least due to 1B.) and 2.)

posible fixes:
I.) register one more VQ for each vcs system - e.g svnMetadataVQ. This would be suboptimal and confusing. 

II.) add a new method (e.g. isHiddenMetadata() ) to  o.n.m.versioning.spi.VCSVisibilityQuery. The method would be synchronously called in VcsVisibilityQueryImplementation for each vcs system. Would mean an API change - a bit too late for 7.0

III.) instead for adding o.n.m.versioning.spi.VCSVisibilityQuery.isHiddenMetadata() add a new attribute  ( e.g. isHiddenMetadata ) into VCSInterceptor.getAttribute() and call this similar as in II.) . 

if there are no objections or better suggestions i would prefer III.) for 7.0 and replace with II.) after.

(In reply to comment #14)
> we always have to return false for .svn so the necessary evaluation can't
> be made asynchronously

Right. I would suggest just returning false for the well-known VCS metadata folder names:

CVS (maybe)
.svn (or _svn on Windows?)
.hg
.git

cf.: https://svn.apache.org/repos/asf/ant/core/trunk/src/main/org/apache/tools/ant/DirectoryScanner.java

> Would mean an API change - a bit too late for 7.0

Not necessarily for a bugfix.

> add a new attribute (e.g. isHiddenMetadata) into VCSInterceptor.getAttribute()

That is still an API change, just harder to track and document.

(In reply to comment #15)
> (In reply to comment #14)
> > we always have to return false for .svn so the necessary evaluation can't
> > be made asynchronously
> 
> Right. I would suggest just returning false for the well-known VCS metadata
> folder names:
hardcoded directly in VcsVisibilityQueryImplementation? as a hotfix instead of an api change before 7.0? 


> .svn (or _svn on Windows?)
_svn is only a subversion workaround for some setups on windows. has something to do with IIS if i remember right

> > add a new attribute (e.g. isHiddenMetadata) into VCSInterceptor.getAttribute()
> That is still an API change, just harder to track and document.
providedextension in masterfs delegates to vsc only if requested attribute starts with "ProvidedExtensions" so "isHiddenMetadata" woud be a contract only inbetween VCS, but of course it would still have an impact on the VQ result, so yes indeed, api change. i've missed that.

(In reply to comment #16)
> hardcoded directly in VcsVisibilityQueryImplementation? as a hotfix instead of
> an api change before 7.0? 

That's another possibility.

(In reply to comment #17)
> (In reply to comment #16)
> > hardcoded directly in VcsVisibilityQueryImplementation? as a hotfix instead of
> > an api change before 7.0? 
> 
> That's another possibility.

hotfixed in core-main #7bc1b5d0e796
filed a new issue to cover a proper fix via api change - #196290

Integrated into 'main-golden', will be available in build *201103050000* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/7bc1b5d0e796
User: Tomas Stupka <tstupka@netbeans.org>
Log: issue #195985 - java.io.IOException: Do not create DO for .svn metadata: C:\Sun\glassfishV31svn\trunk\v3\ejb\ejb-container\src\main\.svn

*** Bug 197573 has been marked as a duplicate of this bug. ***

*** Bug 197573 has been marked as a duplicate of this bug. ***

It is a SVN bug. Do not reassign bug to language features.
Simple steps to reproduce:
- create in terminal folder ".svn"
- in IDE add to favorites created folder
- see exeption.

(In reply to comment #22)
Why do you reopen a fixed bug??? Closing again.
> It is a SVN bug. Do not reassign bug to language features.
> Simple steps to reproduce:
> - create in terminal folder ".svn"
> - in IDE add to favorites created folder
> - see exeption.
The steps have no relation to this bug, they relate to bug #210404 that will be fixed by Favorites module's owner.

(In reply to comment #23)
> The steps have no relation to this bug, they relate to bug #210404 that will be
> fixed by Favorites module's owner.
Sorry, look on huge list exceptions reports with fresh enteris. Why all features must satisfy svn specific requirements? Why svn forbid browsing of .svn folder? It seems svn requirements are an unsubstantiated.

(In reply to comment #24)
> (In reply to comment #23)
> > The steps have no relation to this bug, they relate to bug #210404 that will be
> > fixed by Favorites module's owner.
> Sorry, look on huge list exceptions reports with fresh enteris. Why all
> features must satisfy svn specific requirements? Why svn forbid browsing of
> .svn folder? It seems svn requirements are an unsubstantiated.
maybe the message is a bit confusing. it's not about .svn in particular, but about a .svn folder being hidden. Why should anybody try to create a DO for a hidden folder?

Subversion simply does not want anyone from operating and playing with svn metadata. This is the way to prevent from copying or moving the .svn folder around the IDE when renaming/moving a versioned folder.
BTW, there's nothing illegal about Subversion preventing from creating a DO and the IllegalArgumentException - see the javadoc for DataFolder.find, callers should be ready for that.

(In reply to comment #26)
> Subversion simply does not want anyone from operating and playing with svn
> metadata. This is the way to prevent from copying or moving the .svn folder
> around the IDE when renaming/moving a versioned folder.
> BTW, there's nothing illegal about Subversion preventing from creating a DO and
> the IllegalArgumentException - see the javadoc for DataFolder.find, callers
> should be ready for that.
Thanks for explanation. It make sense.