Tip # 72 (case insensitive code completion) - select Tools > Options > Editor. Check or unCheck the ‘Case Sensitive Code Completion checkbox. You no longer have to use Camel Case for proper code completion (like in NetBeans 5.5). Discussed here in Roumen’s blog : http://blogs.sun.com/roumen/entry/netbeans_quick_tip_25_insensitive

Tip 71 : Auto-Complete Any String (Hippie Expand)
Tip 72 : Make Code-Completion Case (In)sensitive

What is both tips about? I am really annoying with keep on typing control-space for auto complete. I want the auto complete turn on all the time so that every key stroke will trigger the auto complete.

The best auto complete I use is the auto complete from Vim, it will search all the variable you already declare or it will search for the file system name or any string you had type from the current file or other file which you included without the need to type control-space. I also using Visual Studio which also show the auto complete with the Visual Assist add-on.

Can I do that with netbean also?

The reason one needs to subscribe is all of the actions will need to be available some how, and those actions classpaths will need to be available. It seems along with subscribing a new model is needed to support modules overall in the on demand features so that specifics of the classpath may be left loaded in memory while others are left out until needed or that in the layer.xml a module may define actions and other UI information which may be provided for the user so they may enter into specific actions without the full module really being loaded.

For instance, if a modules only user interface entry point is an action, then if it is deactivated it won’t show up for a user, and they’ll never be able to use it without first manually activating it.

So, definitely would be good, but will take more thought and resources than is in the current design of the on demand features, and it would need to be a system wide design outside of just the UI gestures module.

See the full article here : http://javapassion.com/handsonlabs/javatestcodecoverage/index.html

Right now you are providing some j2ee jars on javac classpath - this is non-standard and you rely on implementation details of project infrastructure (What jars will be preferred for compilation in the IDE? Yours or jars provided by the registered server?). So now your project structure IS non-standard, adapted to continuous build system.

For new project you can check “Use dedicated library for server JAR files” in second step and this is exactly the thing you need. When this option is used, no change to project.properties and no special configuration of javac classpath is needed. It will work for cont. build system, in the command line and in the IDE as well.

If you have the existing project, just create new global library of “Server Library” type and put the j2ee jars there (jars you are now providing for continuous build, but which doesn’t make sense for IDE usage).

After this change it should work out-of-box.

I completely understand that I CAN pass it as argument to Ant in each project’s configuration in Hudson, but the question is WHY should I have to. If I have hundreds of Java projects configured in my build server, I then have to edit the configuration for each one and pass the property to ant statically. this can turn into a maintenance nightmare, especially if other required properties are added in later versions of NetBeans.

Would the solution here be to perhaps remove the FAIL check for the j2ee.platform.classpath property that was added in NetBeans 6.1 ? :

<fail unless=”j2ee.platform.classpath”>
The Java EE server classpath is not correctly set up. Your active server type is ${j2ee.server.type}.
Either open the project in the IDE and assign the server or setup the server classpath manually.
For example like this:
ant -Duser.properties.file= (where you put the property “j2ee.platform.classpath” in a .properties file)
or ant -Dj2ee.platform.classpath= (where no properties file is used)
</fail>

NetBeans 6.0 seemed to work fine without it. Just some thoughts. ]]> http://pronetbeans.com/archives/29#comment-328 phejl Thu, 27 Mar 2008 09:33:37 +0000 http://pronetbeans.com/archives/29#comment-328 Well, you are probably supplying the platform jars on javac classpath, I suppose (otherwise the project wouldn't compile complaining about missing javax.servlet and similar). j2ee.platform.properties is the value provided by the server, so it is placed in private.properties. It is bit dubious to place it to project.properties. You have several options. 1) When calling ant use ant -Dj2ee.platform.classpath=. This is much cleaner I would say. 2) You are using dedicated library folder a) new project - just select "Use dedicated library for server JAR files" in second step b) existing project - create server library and place your j2ee platform jars there, add the library to project (better than placing platform jars to javac classpath) Well, you are probably supplying the platform jars on javac classpath, I suppose (otherwise the project wouldn’t compile complaining about missing javax.servlet and similar).

j2ee.platform.properties is the value provided by the server, so it is placed in private.properties. It is bit dubious to place it to project.properties. You have several options.

1) When calling ant use ant -Dj2ee.platform.classpath=. This is much cleaner I would say.
2) You are using dedicated library folder
a) new project - just select “Use dedicated library for server JAR files” in second step
b) existing project - create server library and place your j2ee platform jars there, add the library to project (better than placing platform jars to javac classpath)