Re: Re: Project Groups - UI proposal ready

Jesse Glick wrote:
> Petr Jiřička wrote:
>> I consider project groups a potentially suitable mechanism for
>> addressing the project sharability and headless build requirements
> 
> This is a much bigger and more complicated issue which I am in no way 
> intending to address with the project group feature, which is purely an 
> attempt to make it easier to open and close related projects more 
> quickly than is currently possible. However, any major sharability 
> feature could probably be integrated at the GUI level with project 
> groups, perhaps using the Folder group kind.

While I agree that project sharability is out of the scope of your 
proposal, I think lack of sharability is a major blocker for adopting 
NetBeans and we should attempt to address it in NetBeans 6. I'd like to 
make sure that the solution for project groups is not conceptually 
incompatible with a future solution for project shareability, and it is 
indeed possible to base the shareability solution on the project group 
concepts. That's why I am interested in it in the context of this UI 
review.

> 
>> would it be sometimes useful to share some types of project groups
>> among users, rather than making them private as you suggest? Again,
>> the Folder group and Master project group look like good candidates,
>> as they are intrinsically the same for all users.
> 
> But for these group kinds, there is no real reason to share the 
> definitions, as the definitions are trivial and can be recreated in a 
> moment in another developer's IDE if desired.

Well, at least you would need to share the information that "this folder 
represents a project group" (so you can list it in the group switching 
UI), wouldn't you? Also, for the purpose of project sharing you may need 
to associate additional information with the project group, such as (and 
this is speculative) the "default location of the libraries folder" 
(place where the IDE copies JUnit and other jars from the Library Manager).

> It would be more logical 
> to share a non-autosynch free group, although I am not convinced there 
> is a lot of value in this. Sharing an autosynch free group would be a 
> bad idea because just opening any other project for a quick peek would 
> change a definition file in version control, very likely causing a merge 
> conflict on your next update.

Agreed.
Petr

> 
> -J.
>