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 215135 - Support ViewGroup's
Summary: Support ViewGroup's
Status: RESOLVED FIXED
Alias: None
Product: connecteddeveloper
Classification: Unclassified
Component: Hudson (show other bugs)
Version: 7.2
Hardware: All All
: P3 normal (vote)
Assignee: Jesse Glick
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-03 17:15 UTC by Jesse Glick
Modified: 2013-05-02 12:03 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Patch in progress, for possible early review (31.77 KB, patch)
2013-01-07 23:47 UTC, Jesse Glick
Details | Diff
Patch - Updated ProjectHudsonProvider.Association (10.24 KB, patch)
2013-03-01 09:52 UTC, Jaroslav Havlin
Details | Diff
Patch - Updated ProjectHudsonProvider.Association v2 (10.29 KB, patch)
2013-03-01 10:31 UTC, Jaroslav Havlin
Details | Diff
Patch - HudsonJob.getName() return path to the job (7.28 KB, patch)
2013-03-04 16:38 UTC, Jaroslav Havlin
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2012-07-03 17:15:15 UTC
While simple jobs are displayed correctly by NB, when using the Folders plugin [1] 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.

[1] http://www.cloudbees.com/jenkins-enterprise-by-cloudbees-features-folders-plugin.cb
Comment 1 Jesse Glick 2012-07-03 17:16:01 UTC
I may try to implement at some point.
Comment 2 Jesse Glick 2013-01-07 16:56:36 UTC
Tonda recommends considering this for 7.3.1 (assuming I can produce a reasonable patch).
Comment 3 Jesse Glick 2013-01-07 23:47:05 UTC
Created attachment 129977 [details]
Patch in progress, for possible early review
Comment 4 Jesse Glick 2013-02-27 15:14:17 UTC
Any initial feedback? Shall I polish this up and mark PATCH_AVAILABLE?
Comment 5 Jaroslav Havlin 2013-02-27 16:48:41 UTC
(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)?
Thank you!
Comment 6 Jesse Glick 2013-02-27 18:08:47 UTC
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.
Comment 7 Jaroslav Havlin 2013-02-28 16:46:33 UTC
(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.
Comment 8 Jesse Glick 2013-02-28 18:37:33 UTC
Thanks! Probably makes more sense for me to play with the rest of this, since I can test it most easily.
Comment 9 Jaroslav Havlin 2013-03-01 09:52:15 UTC
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?
Comment 10 Jaroslav Havlin 2013-03-01 10:31:22 UTC
Created attachment 132056 [details]
Patch - Updated ProjectHudsonProvider.Association v2

Some methods and instance fields refactored.
Comment 11 Jesse Glick 2013-03-01 16:56:10 UTC
(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.
Comment 12 Quality Engineering 2013-03-02 01:51:38 UTC
Integrated into 'main-golden', will be available in build *201303012300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/d1f1f5f35c2a
User: Jesse Glick <jglick@netbeans.org>
Log: #215135: support folders.
Comment 13 Jaroslav Havlin 2013-03-04 12:50:56 UTC
> Updated patch from comment #10 looks good to me.
Thank you. Applied as http://hg.netbeans.org/core-main/rev/651e1291f237
Comment 14 Jaroslav Havlin 2013-03-04 16:38:03 UTC
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.
Comment 15 Jesse Glick 2013-03-06 00:24:56 UTC
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.
Comment 16 Quality Engineering 2013-03-06 01:52:23 UTC
Integrated into 'main-golden', will be available in build *201303052300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/651e1291f237
User: Jaroslav Havlin <jhavlin@netbeans.org>
Log: #215135: ProjectHudsonProvider.Association supports jobs nested in folders
Comment 17 Jaroslav Havlin 2013-03-06 08:41:15 UTC
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.
Comment 18 Quality Engineering 2013-03-07 01:57:12 UTC
Integrated into 'main-golden', will be available in build *201303062300* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/590423437216
User: Jaroslav Havlin <jhavlin@netbeans.org>
Log: #215135: HudsonJob.getName() should contain full path to the job
Comment 19 Tomas Danek 2013-05-02 10:58:56 UTC
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.
Comment 20 Jesse Glick 2013-05-02 12:03:58 UTC
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.