>> One is a push list (http://www.patternfly.org/pattern-library/forms-and-controls/dual-list-selector/) and the other one is a tree with triple-state checkboxes (e.g. https://www.patternfly.org/pattern-library/widgets/#bootstrap-tree-view or http://www.patternfly.org/patternfly-ng/#/treelist). The second option is just one scribble bcause it is very close to what we have right now.

>>>> The first one has the big advantage that it is really clear what the user selected. The disadvantage in our case is, that it's also easy to select sub-packages instead of the top level package. Countermeasures could be a useful description or a dialog box warning the user that selecting all those sub packages is not a great idea.

>> I really like the pick list for this, as I think it closely matches what we actually want the user to do. I share your concerns here, and I think that a description would be good. We could also potentially trigger a warning if a very large # of items are selected, as this is almost always a mistake.

+ 1 if we're going with the push list.

>>>> The triple-state checkbox is on the last page of the pdf I linked. This would help to lower the risk of users selecting sub packages rather than top level packages. Displaying what will be included in the analysis and what will be excluded should help to mitigate this risk.

>> I'm not opposed to tri-state actually, I just have realized that this will take quite a bit of thinking to build a solid spec for the requirements.

Not necessarily. I'm thinking of a very simple solution here: if parent is selected and not all children are selected, then add all non-selected children to the exclude list and ad the highest possible levels to the include list. This is done for each level. So when having:
de
  sub1
  sub2
  sub3
    sub3sub1
    sub3sub2


and the user let's say selects sub1 and sub3sub2, the result should be: included: de ; excluded de.sub1, de.sub3.sub3sub1.

This however really requires some logic on the frontend and basically you need to crawl through the parts of the tree where packages have been selected in order to determine which haven't been selected in that subset and should therefore be excluded from the analysis.

I am probably forgetting something here, please free to just say 'are you blind? you obviously forget the case when...' :)
 

>> I have also discovered that lazy loading actually isn't the problem, btw. Even with very large datasets, I was able to load the data upfront, but I had to be careful about how much was rendered by the tree component at a time, as its checkbox detection falls over with very large trees. The actual data set is not that large, even with your example application, and could also easily be optimized.

>> In general, figuring out how to track the checked state without crawling the entire tree on every change is the biggest challenge with this approach. angular-tree-component has a lot of open performance bugs related to this as well. 

To be honest I didn't have a look at the related open bugs with that. Does the above solution maybe help to circumvent crawling the entire tree? I could imagine that since checking a box, let's say, sub1 limits what needs to be crawled. When having lazy loading (or just taking into consideration what is displayed / "opened") it should be really just a small portion of the tree.
 
Ultimately there eis probably no option to prevent users from 'doing it wrong' as in selecting com.sub1, com.sub2 etc. instead of selecting com and excluding com.exclude1. In fact, in the eclipse plugin we right now even enforce this kind of anti-pattern since the package selection there displays the flat package list for selection. But that's another story (I will open a ticket for that).

>>>> I am a fan of your idea, Jess, to not show 3rd party packages upfront - but rather give the user the option to load them if really needed. One page 1 is what I had in mind together with the push list, for the triple state check box tree something similar can be done.

>> I think the pick-list pattern lends itself to this kind of filtering as well. I do wonder about deselection with the picklist tree that you've shown though. What about only making it possible to deselect the top level item on the right side? I think that would more strongly encourage only selecting the highest level items.

I am not sure I totally understand that. Back to the above example to help me understand it :)
On the right side (included packages) is:
de
  sub1
  sub2
  sub3
    sub3sub1
    sub3sub2
Let's assume this is eveyrthing under the package 'de'

Now the user wants to exclude de.sub3.sub3sub2 but we just allow 'de' to be excluded? It seems to me that this would actually lead to what we don't want users to do, because then a user would have to specifically select de.sub1|2 and de.sub3.sub3sub1 - which means 'de' as a top level package is not included. This way we pass more packages and the user maybe needs to adjust the packages when a new app gets added.
I probably just misunderstood you - can you help me out here?