While simple jobs are displayed correctly by NB, when using the Folders plugin  a folder is displayed like a plain job with no builds or any other content. Needs to display contained jobs & subfolders according to api/xml?tree=primaryView[jobs[name]]. Generally this would be true of any ViewGroup, which plugins may implement. (*) The idea is similar to displaying Maven modules as nested items, the implementation for which could probably be refactored slightly to handle the more general case.
Also ProjectHudsonProvider.Association.fromString gets confused by URLs like $server/job/folder/job/subfolder/job/actualJob/ - these need to be parsed so that the $server URL is correctly identified. Association.getJob etc. might also need work.
(*) ViewGroup is a longstanding interface, but the getPrimaryView method was added recently to Jenkins, so a Hudson-compatible plugin implementing this interface might implement only getViews and you would need to search for one named 'All'. On the other hand a plugin can also just have a @Exported public View getPrimaryView() which is not an @Override - the remote API will serve it just the same.
I may try to implement at some point.
Tonda recommends considering this for 7.3.1 (assuming I can produce a reasonable patch).
Created attachment 129977 [details]
Patch in progress, for possible early review
Any initial feedback? Shall I polish this up and mark PATCH_AVAILABLE?
(In reply to comment #4)
> Any initial feedback? Shall I polish this up and mark PATCH_AVAILABLE?
I'm sorry for big delay in answering.
The patch seems fine. If you can polish it up, it would be great. If not, I'll do it (it seems that only @since tags are missing, or is there something else that needs to be finished)?
The basic folder browsing seems to work fine, but ProjectHudsonProvider.Association still needs to be fixed, and there are some other places where code incorrectly assumes that job.name == fullName. I do not think anything is harmed by committing the current patch, though I would consider it incomplete.
(In reply to comment #6)
> The basic folder browsing seems to work fine, but
> ProjectHudsonProvider.Association still needs to be fixed, and there are some
> other places where code incorrectly assumes that job.name == fullName. I do not
> think anything is harmed by committing the current patch, though I would
> consider it incomplete.
Integrated as http://hg.netbeans.org/core-main/rev/d1f1f5f35c2a
I'll modify ProjectHudsonProvider.Association so that it uses job URL internally, and try to find other places that need fixing.
Thanks! Probably makes more sense for me to play with the rest of this, since I can test it most easily.
Created attachment 132055 [details]
Patch - Updated ProjectHudsonProvider.Association
(In reply to comment #8)
> Thanks! Probably makes more sense for me to play with the rest of this,
> since I can test it most easily.
I've already managed to install CloudBees Folder plugin and started working on the fix. Can you please check the patch? (I'm still considering some refactoring, but the algorithm should be final.)
The association now stores full job URL.
When the Job URL is constructed from string, it can be now ambiguous what is the Hudson instance URL and what is the job path.
E.g. http://host/job/hudson/job/MyJob will be parsed as job "MyJob" in folder "hudson" on instance "http://host/", but it could be also job "MyJob" on instance "http://host/job/hudson/".
I suppose this is a minor issue. What do you think?
Created attachment 132056 [details]
Patch - Updated ProjectHudsonProvider.Association v2
Some methods and instance fields refactored.
(In reply to comment #9)
> Can you please check the patch?
Updated patch from comment #10 looks good to me.
> I suppose this is a minor issue.
Yes, I doubt many people are using a "job" path component in the application’s context path. Anyway PHP.A is not critical functionality.
Integrated into 'main-golden', will be available in build *201303012300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jesse Glick <firstname.lastname@example.org>
Log: #215135: support folders.
> Updated patch from comment #10 looks good to me.
Thank you. Applied as http://hg.netbeans.org/core-main/rev/651e1291f237
Created attachment 132158 [details]
Patch - HudsonJob.getName() return path to the job
I've tried to find other cases where jobs are identified by their names only, and I concluded that it could be easier to have full job path in HudsonJob.getName().
E.g. job at URL "http://host/job/folder1/job/folder1/job/SomeJob" would return "folder1/folder2/SomeJob" from getName() method.
Jesse, please let me know if you think this is not a good idea. I tested it and it seems to work fine, but I could miss some problems that may appear in the future when some other Hudson/Jenkins plugins are installed. Thanks.
Looks reasonable to me.
I see that for HudsonInstanceProperties.split/join you have to work around the historical use of '/' as a separator between job names; tricky enough that a unit test for it would be best.
Integrated into 'main-golden', will be available in build *201303052300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Havlin <email@example.com>
Log: #215135: ProjectHudsonProvider.Association supports jobs nested in folders
Test added, integrated as http://hg.netbeans.org/core-main/rev/590423437216
Closing. Please reopen if there are some other parts that need fixing.
Thank you, Jesse.
Integrated into 'main-golden', will be available in build *201303062300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
User: Jaroslav Havlin <firstname.lastname@example.org>
Log: #215135: HudsonJob.getName() should contain full path to the job
Jesse, can you please verify in dev build and let us know if this is ok (and is worth) to put in 7.3.1 (7.3 patch2)? Thanks in advance.
I will verify in dev when I get a chance, but considering the magnitude and character of the changes I think they would be too risky to backport.