[jbosstools-dev] My super cool Eclipse extensions

[Max Rydahl Andersen]

>> 3) It seem to just look at the toplevel dir, I think it should look 
>> recursively like Import project(s) does and then show which projects 
>> and what guessed project types it will be imported as.
> Making it working recursively will probably take ages and show a lot 
> of choices to the user, who would get frightened by the amount of 
> things to configure.
> But I agree it would be nice. I'll think about it.

our runtime detection recursively scan about 500 dirs no my disk without 
problems.

importing multiple nested projects like all of jbosstools takes 
miliseconds with the "old" approach.

I don't think it will be as slow as you think.

>> 4) In general I think the UI would be better if similar to import so 
>> you dont have to just get the OS specific browser as the first thing 
>> (i.e. being able to easily type full path and/or get list of what 
>> projects will be imported would make it easier to comprehend what is 
>> going on IMO)
> On that I disagree. If we want the operation to feel simple, it has to 
> be simple at first, showing a FileDialog after a menu is pretty usual 
> and efficient for most software I hardly believe mimicking that 
> behaviour is 90% of the benefit of this change.

I dont understand that sentence. The current UI is slow and 
non-informative of what will happen. Sure, it works great if you 
actually get to select the rigth folder in first go and it guesses the 
import correctly...but thats pretty damn never ;)

> Allowing to easily type full path is something I can do with my OS 
> browser.

yes, but not with all file dialogs. OSX especially sucks. You need to 
know to press ctrl+shift+G and whatnot.

>> 5) it would be really nice if this feature would be automatically 
>> called if I dragged a folder to eclipse window
> I agree, I'll try to implement that.

>> 7) import of a multimodule project like jbosstools-browsersim only 
>> result in one top root level project (if I used the maven import it 
>> would have imported the others)
> Yes, and I think it's good like this. What I think would be a nice 
> continuation of the process would be to show Maven modules differently 
> in Project Explorer to allow open/import from there. Cf 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=424317 .

You think it is good it does not actually import the nested projects ? 
...so you don't want to show a more userfriendly UI for the first step, 
but you are okey requiring users to after import of a nested project 
structure having to manually import them just because it is a maven 
project ?

>> 8) it made the target folder in 
>> org.jboss.tools.vpe.browsersim.debugger the source folder for the 
>> java project - not sure why. it is a PDE project that can be deduced 
>> from meta-inf and build.properties...
> No doubt it's a bug. The current detectors/configurators are 
> "cumulative", so it runs default Java configurator even on a Maven or 
> PDE project.

yeah I think that will not work in many cases. They need to be a tad 
smarter.

>> that said this is a really nice feature and would like to see how we 
>> could include it into jbosstools and definitely try get it into 
>> eclipse Mars.
> Technically, it could be integrated easily in JBoss Tools: no 
> additional deps or nothing else, already builds with JBT parent pom 
> and TP.

main problem is that it has dependencies to alot of things so we can't 
install it piecemal (i.e. I Assume the maven recognizer requires m2e to 
be installed)

> But as you noticed, it requires some fixes/improvements.
> About having it part of Mars, it's something that I think cannot 
> really happen, because IBM people already decided what they will work 
> on, and this is not part of their short-list. Cf Dani's answers to 
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=427768 .

I do not grok what this issue of nested resources has to do with simpler 
imports ?

and if we already provide the code why would they not be okey to look at 
the contribution ?

> Sorted by priority of mine (top is higher):
> * 2
> * 6
> * 8
> * 5
> * 3
> * 1
> * 7, 4

I think 7,4 are critical since most projects are not just single 
projects these days.

i.e. I can't use this to import any of our basic quickstarts unless I do 
them one by one.

/max
http://about.me/maxandersen