| Summary: | tweak project selection dialog | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Igor Fedorenko <igor> |
| Component: | m2e | Assignee: | Project Inbox <m2e.core-inbox> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | matthew, mkleint |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
|
Description
Igor Fedorenko
* Actions to expand/collapse all and individual project tree nodes would also be nice. I have made a few of these changes but accidentally used the wrong bug in the commit message: http://git.eclipse.org/c/m2e/m2e-core.git/commit/?id=4ab6896523ca6c2a6a8bc8563101fd1a023a991b I haven't done any filtering so far, I don't believe there are any JFace filtered trees with checkboxes so we'd need to write something custom. (In reply to comment #0) > Maven project selection dialog introduced as part of bug 342910 and now also > used by update project configuration action needs another pass to improve > polish and usability. This is not a definitive list, but here are some ideas > > * show only selected projects by default, but have a way to uncover (and hide > again) unselected projects. Currently all projects are always shown, which > makes it hard to see selected projects when running update on a small number of > projects from a large workspace. The current way is simpler and aligned with what "clean" and PDE-> Update ClassPath" dialogs look like. > > * filter projects by name, groupId or artifactId. again, finding project that > you need can be hard in a large workspace. Both this and the previous item seem to indicate that you have done a selection (before opening the dialog) but want to update it inside in a complex manner. Why? Is it that common? I haven't really noticed anything like that on my side when using the clean/update CP actions in the last year. Is the maven thing different? in what way? > > * action to select/deselect all module (or nested?) project of a given parent. The list appears flat to me (in my workspace). Again that aligns with the way other project lists work. When/why would I want to work with modules? > > * pass dialog title as constructor parameter, so update dependencies and update > configuration actions can show the same dialog with different title >> >> * action to select/deselect all module (or nested?) project of a given parent. > >The list appears flat to me (in my workspace). Again that aligns with the way >other project lists work. When/why would I want to work with modules? I stand corrected, the latest build has indeed hierarchy of projects/modules. Closing old/stale bugreports. |