Like I said, the IDE team may chime in with a solution; I don't use non-root locally like ever, so I wouldn't have known it was not working myself.
I think many devs share the opinion that they need to make their environment match (somewhat) the production environment, but that's really not the case with Liferay development.
When you think about it, your code, whether a portlet or a hook or a theme or whatever, really doesn't have application server specific code and often not really environment-specific code. Because we use app server and database agnostic code, that means development aspects can be separated from operational aspects.
I find myself doing something similar for front-end development - I develop and test using chrome, not because my users are all using chrome, just because I find the developer tools easier to use in chrome. So I'll get the work done using chrome and worry about IE when I'm done and ready to move to test.
The one aspect that I will flip on is developing against the same database type as used in production, but that's really only for custom query development. I've seen developers get bitten too many times by getting a query working against mysql in development but fails miserably when using Oracle, simply because the SQL interpreter for mysql is a more forgiving than Oracle's. But if you're using native ServiceBuilder code (Hibernate-based) or DQ, then mysql or hsql is just fine because in the end the underlying framework will generate the right sql for the target DB.
I think this is a unique aspect of developing for Liferay; if I were building web applications (servlets), I would probably want a development environment matching production because many of the layers Liferay has added to isolate and eliminate app server/database differences just wouldn't be there in a normal servlet app.
Anyway I'll climb down off of my soapbox now, I'm sure you're not looking for some sort of general philosophical debate
Come meet me at the LSNA!
I think many devs share the opinion that they need to make their environment match (somewhat) the production environment, but that's really not the case with Liferay development.
When you think about it, your code, whether a portlet or a hook or a theme or whatever, really doesn't have application server specific code and often not really environment-specific code. Because we use app server and database agnostic code, that means development aspects can be separated from operational aspects.
I find myself doing something similar for front-end development - I develop and test using chrome, not because my users are all using chrome, just because I find the developer tools easier to use in chrome. So I'll get the work done using chrome and worry about IE when I'm done and ready to move to test.
The one aspect that I will flip on is developing against the same database type as used in production, but that's really only for custom query development. I've seen developers get bitten too many times by getting a query working against mysql in development but fails miserably when using Oracle, simply because the SQL interpreter for mysql is a more forgiving than Oracle's. But if you're using native ServiceBuilder code (Hibernate-based) or DQ, then mysql or hsql is just fine because in the end the underlying framework will generate the right sql for the target DB.
I think this is a unique aspect of developing for Liferay; if I were building web applications (servlets), I would probably want a development environment matching production because many of the layers Liferay has added to isolate and eliminate app server/database differences just wouldn't be there in a normal servlet app.
Anyway I'll climb down off of my soapbox now, I'm sure you're not looking for some sort of general philosophical debate
Come meet me at the LSNA!
