NetBeans 6.8 is there since December 2009. It did not look like a very important upgrade at first. At least not very important for Platform developers. But using the new version of platform, some things which may appear small at first, has been visibly improved. The most important improvements are listed here (according to my personal feelings). For a complete overview of changes in platform API you can take a look here.
Wrapped libraries
That was one of the major headaches source. Developing modules for NetBeans (as for other platforms) requires sometimes links to other libraries. Third-party libraries, other than the modules provided by the platform, needs to be linked and wrapped in your custom pluggins or platform-based applications.
Wrapping libraries was done in the past in two ways. By creating a module library wrapper plugin for every library which need to be imported. But when you have to link a bigger library, which have a lot of jars, that was a pain. Because a module library wrapper could be created only for one jar. You can end up with easy to have twenty-thirty libraries only to link to something like apache logging libraries or Seam or similar.
The second approach was to create a big jar with all jars from library. For this operation, NetBeans is helpfull, but you have other two problem to solve. First is that the new jar will have it's own manifest. That means that if there is information in manifest files of every jar, that information is lost or not complete. If that information is important, you have a nice problem to solve. The second is that you can loose control over which libraries you have, which versions. Become very difficult in time to maintain the upgrades.
Solution is the new wrapped libraries feature. Now each plugin module in NetBeans can have it's own dependencies on external libraries. For configuration, you have a new tab panel to add as much as needed libraries. The cool thing is that you can specify also the source code and javadocs for every wrapped jar. That was not possible in the old versions.
ActionListeners are everywhere
That could not look as important as it is. In the old versions you could use ActionListeners only for always enabled type of actions. Not you can use the same interface also for context aware and callback action types. That is really cool, even it does not sounds like that at first. A main aspect here is that it is used a "well known" interface.
The first consequence is that if you want to migrate a swing-based app on NetBeans platform, is easier because you just have to pipe your actions. The second consequence is that you don't have to use specific platform interfaces like cookies. I don't say that cookies were bad, but they are old and there is better and much usable alternative.
Declarative Asynchronous actions
That's small, but makes code cleaner and flexible. Also throws away the need to manage yourself the asynchronous behavior of your actions. Nice done.
Enhanced IO API
We already had colors and links. And it was very useful. But now is even more flexible.
You can color the output as you like because you can output with IOColorPrint.print. So you can made your output lines from peaces colored independently. You can also put more hypelinks on the same line. You can, again, add an importance marker, which improves readability on verbose outputs. Finally, you can specify the parent of an IOTab and set its icon and tooltip message. All of them are small things, but used together can be very helpful on creating really effective and friendly output for your application. I appreciate very much an application which let you know what is going on.
Annotations
That's not a specific point. There are some very useful annotations added. The point is, thought, not the specific annotations added. But the trend to use as much as possible annotations. I hope that this trend will continue. I already used @OptionsPanelController.SubRegistration and @ConvertAsJavaBean. But there are more, take a look.
March 8, 2010
December 23, 2009
Common misconceptions about EJB
Java Enterprise is often a topic for many programmers in the free world (non m$ like one, I suppose ..). I don't think it was always a first option. There were and still there are pros and cons discussions. Still, Java Enterprise is an available solution. Thought, with a lot of books and good articles around, I often hear simply "amazing" thoughts about Java Enterprise. What is worst is that many of these are believed by so called Java Enterprise developers.
A lot of people still have some misconceptions about Java Enterprise. How this could happen? Perhaps due to the degree of configuration complexity of the firsts variants of the standard. Maybe because of the rigidity of the Sun guys, who kept in iron hands the previous releases (previous than 3.0). Perhaps because in the past the standard was not under JCP. Maybe none of this. I really don't know. But I will present some thoughts that I heard, and give some opinions on that.
EJB is for web applications
Simply wrong. Java Enterprise has nothing to do with web applications. To be more exact, Java Enterprise has the same link to web applications, as it has with other type of client applications. EJB is about business, about business distributed components and about integration. The consumers of these components can be any type of application that understands JNDI and IIOP, nothing more. Even if we see around a lot of web frameworks that are well integrated with EJB, that does not mean EJB is only for web.
With JPA you don't have to work with databases
I always considered that a good programmer is a lazy person. But a lazy programmer is a programmer which chooses to work less but smart instead of easy but with repeated tasks. If you choose EJB with persistence, than you choose to work with an abstract layer, which models your business. You choose to separate these layers. That does not exclude to improve the performance of database. There are often situations when a proper index can solve a big bottleneck. Don't be extreme on that. Persistence layer let you concentrate more on your functionality, don't exclude tuning database process.
EJB applications are always lazy
That is not true. I agree that Java Enterprise comes with a penalty performance. There is a cost for the ease of design and for generality. My idea is that every design tries to solve some classes of problems in trade of others. The art in application design (if there is one) is to make a good trade on that. It’s like in chess. If you want a benefit you have to leave something. The choices are core of the process. If your choices are good, the penalties are not relevant for your business. Going back to EJB, the initial performance penalties are traded for other benefits. As a sample, putting in place a cluster or a cache is not an easy job in state-of-art systems, in EJB this task is very easy. By choosing what components to be cached, the caching levels, by choosing a proper clustering structure you can benefit a lot. A common thing that is missed is the usage of entity managers. A almost always saw that the entity managers used are the default ones provided by wizards. That’s a bad choice. You must reconsider every opportunity. There are a lot of services for EJB components which can be configured with ease, that's the point. Don't put on work the wizards and consider you work done. You work begun after the wizards. Remember well, the choices are very important, and EJB container makes that job very easy.
Use EJB everywhere, is the best
Nothing is the best for everything. EJB has its place in software fauna. But it’s not best for anything you can think of. Sometimes you must consider using light web frameworks, sometimes is better to use light web scripting languages with fast databases. I can give clear receipts. If I put my two cents in, the rigid thinking does not do you any favors.
EJB is only about components and services for these components
I don’t agree. It’s true that components and container services for these components worth a lot. But there is something more, which I consider at least as important as the previous. This valuable thing is integration with external systems. I lot of people forgot that. But one of the main goals of EJB is the integration of external systems. The integration potential is, sometimes, the main reason to choose EJB in place of others technologies. We can review the times when EJB was put on place. A lot of big software consumers had a lot of big systems provided by different software vendors. It is a usual. Every system produces a part of the big picture. A lot of effort and money and knowledge are buried in those systems. The next step is to obtain the big picture. You can’t rewrite everything from scratch. You have to integrate the existent system. You have to put all the pieces together. EJB is good at that. Did you hear about resource adapters? Did you saw a detailed sample of a CORBA component written in C working with EJB? I bet you don’t. Unfortunately I never saw books with covers well this topic. Three pages from five hundred are not enough, but that is the sad average. I am still waiting for a good book to cover this, to exploit this potential.
A lot of people still have some misconceptions about Java Enterprise. How this could happen? Perhaps due to the degree of configuration complexity of the firsts variants of the standard. Maybe because of the rigidity of the Sun guys, who kept in iron hands the previous releases (previous than 3.0). Perhaps because in the past the standard was not under JCP. Maybe none of this. I really don't know. But I will present some thoughts that I heard, and give some opinions on that.
EJB is for web applications
Simply wrong. Java Enterprise has nothing to do with web applications. To be more exact, Java Enterprise has the same link to web applications, as it has with other type of client applications. EJB is about business, about business distributed components and about integration. The consumers of these components can be any type of application that understands JNDI and IIOP, nothing more. Even if we see around a lot of web frameworks that are well integrated with EJB, that does not mean EJB is only for web.
With JPA you don't have to work with databases
I always considered that a good programmer is a lazy person. But a lazy programmer is a programmer which chooses to work less but smart instead of easy but with repeated tasks. If you choose EJB with persistence, than you choose to work with an abstract layer, which models your business. You choose to separate these layers. That does not exclude to improve the performance of database. There are often situations when a proper index can solve a big bottleneck. Don't be extreme on that. Persistence layer let you concentrate more on your functionality, don't exclude tuning database process.
EJB applications are always lazy
That is not true. I agree that Java Enterprise comes with a penalty performance. There is a cost for the ease of design and for generality. My idea is that every design tries to solve some classes of problems in trade of others. The art in application design (if there is one) is to make a good trade on that. It’s like in chess. If you want a benefit you have to leave something. The choices are core of the process. If your choices are good, the penalties are not relevant for your business. Going back to EJB, the initial performance penalties are traded for other benefits. As a sample, putting in place a cluster or a cache is not an easy job in state-of-art systems, in EJB this task is very easy. By choosing what components to be cached, the caching levels, by choosing a proper clustering structure you can benefit a lot. A common thing that is missed is the usage of entity managers. A almost always saw that the entity managers used are the default ones provided by wizards. That’s a bad choice. You must reconsider every opportunity. There are a lot of services for EJB components which can be configured with ease, that's the point. Don't put on work the wizards and consider you work done. You work begun after the wizards. Remember well, the choices are very important, and EJB container makes that job very easy.
Use EJB everywhere, is the best
Nothing is the best for everything. EJB has its place in software fauna. But it’s not best for anything you can think of. Sometimes you must consider using light web frameworks, sometimes is better to use light web scripting languages with fast databases. I can give clear receipts. If I put my two cents in, the rigid thinking does not do you any favors.
EJB is only about components and services for these components
I don’t agree. It’s true that components and container services for these components worth a lot. But there is something more, which I consider at least as important as the previous. This valuable thing is integration with external systems. I lot of people forgot that. But one of the main goals of EJB is the integration of external systems. The integration potential is, sometimes, the main reason to choose EJB in place of others technologies. We can review the times when EJB was put on place. A lot of big software consumers had a lot of big systems provided by different software vendors. It is a usual. Every system produces a part of the big picture. A lot of effort and money and knowledge are buried in those systems. The next step is to obtain the big picture. You can’t rewrite everything from scratch. You have to integrate the existent system. You have to put all the pieces together. EJB is good at that. Did you hear about resource adapters? Did you saw a detailed sample of a CORBA component written in C working with EJB? I bet you don’t. Unfortunately I never saw books with covers well this topic. Three pages from five hundred are not enough, but that is the sad average. I am still waiting for a good book to cover this, to exploit this potential.
November 25, 2009
NetBeans Platform: Output windows in simple words
I/O APIs is among the most used modules from NetBeans Platform. This is one of the most common way to show information about your activity. The name can be misleading, but is much simpler that it seems. This module manages the output windows which you already have or you can create, where text information can be put.
There are a a lot of scenarios where you need output windows. You need them to show logs for bootstrapping tasks, to show log information, to receive feedback from a compiler or builder or other type of tool.
The story about output windows in NetBeans can be simple or complicated. The hard way is to implement yourself everything and control everything. That could be feasible if you plan to implement a rich output windows with a lot of controls on it. But for simple scenarios, what you have from the platform is simple enough.
Setup
From your NetBeans Platform module, all you have to do is to add "I/O APIs" as a module dependency. That's all.
"Hello world!" from output window
IOProvider is a factory for output window components. These output windows are represented by InputOutput class and hosted into a container, represented by IOContainer. It's easy and enough to proceed. First, we ask for the default provider to get an InputOutput with a specific title. We can create a new one or get an existing one. After that we activate the output and write to it. Here's the code.
Put some colors and behavior on lines
We can easily color the line from output. Also we can put some action on the line. If we create a line with an listener (our listener), the line from output would behave as a hyperlink in a browser. When the listened line will be selected, clicked or deleted, we can do something through listener. Let's see some more code.
Put some decorations on output windows
Using another class from the package, IOTab, you can easily add a tooltip text and a small icon on an output window. As a sample:
And you can do more..
There is also a simple way to add some Swing actions on output window. The output window has a small toolbar on the left side of it. If you pass an array of Swing Actions on the moment of creation, these actions will be available for use on your output window. Just to name a very often scenario: you have a long process to run, you want to give full text feedback, but you want to be able to stop the process when you think is appropriate. Just create a Swing Action to fire the canceling job and add it to the InputOutput.
Thought there are some limitations: you can't put here more than 5 actions and each action should have the property Action.SMALL_ICON defined.
Have fun with InputOutput windows!
There are a a lot of scenarios where you need output windows. You need them to show logs for bootstrapping tasks, to show log information, to receive feedback from a compiler or builder or other type of tool.
The story about output windows in NetBeans can be simple or complicated. The hard way is to implement yourself everything and control everything. That could be feasible if you plan to implement a rich output windows with a lot of controls on it. But for simple scenarios, what you have from the platform is simple enough.
Setup
From your NetBeans Platform module, all you have to do is to add "I/O APIs" as a module dependency. That's all.
"Hello world!" from output window
IOProvider is a factory for output window components. These output windows are represented by InputOutput class and hosted into a container, represented by IOContainer. It's easy and enough to proceed. First, we ask for the default provider to get an InputOutput with a specific title. We can create a new one or get an existing one. After that we activate the output and write to it. Here's the code.
InputOutput io = IOProvider.getDefault().getIO("TestIO", true);
io.select();
io.getOut().print("Hello world!");
Put some colors and behavior on lines
We can easily color the line from output. Also we can put some action on the line. If we create a line with an listener (our listener), the line from output would behave as a hyperlink in a browser. When the listened line will be selected, clicked or deleted, we can do something through listener. Let's see some more code.
try {
InputOutput io = IOProvider.getDefault().getIO("My title", false);
IOColorLines.println(io, "This is a yellow line", Color.yellow);
IOColorLines.println(io, "This is e red important line",
null, true, Color.red);
IOColorLines.println(io, "one dynamic line with event",
new LineListener(), true, Color.green);
} catch (IOException ex) {
Logger.getLogger(SameIOAction.class.getName()).log(
Level.SEVERE, null, ex);
}
[...]
class Listener implements OutputListener {
public void outputLineSelected(OutputEvent ev) {
JOptionPane.showMessageDialog(null, "line with content " +
ev.getLine() + " was selected");
}
public void outputLineAction(OutputEvent ev) {
JOptionPane.showMessageDialog(null, "line with content " +
ev.getLine() + " was actioned");
}
public void outputLineCleared(OutputEvent ev) {
JOptionPane.showMessageDialog(null, "line with content " +
ev.getLine() + " was cleared");
}
}
Put some decorations on output windows
Using another class from the package, IOTab, you can easily add a tooltip text and a small icon on an output window. As a sample:
InputOutput io = IOProvider.getDefault().getIO("My title", false);
IOTab.setToolTipText(io, "My tooltip text for Hello world!");
[..]
And you can do more..
There is also a simple way to add some Swing actions on output window. The output window has a small toolbar on the left side of it. If you pass an array of Swing Actions on the moment of creation, these actions will be available for use on your output window. Just to name a very often scenario: you have a long process to run, you want to give full text feedback, but you want to be able to stop the process when you think is appropriate. Just create a Swing Action to fire the canceling job and add it to the InputOutput.
Action[] actionList = new Action[5];
[..] // add actions here
InputOutput io = IOProvider.getDefault().getIO("My title", actionList);
Thought there are some limitations: you can't put here more than 5 actions and each action should have the property Action.SMALL_ICON defined.
Have fun with InputOutput windows!
November 3, 2009
NetBeans Platform: Implement Perforce client - part IV
Automatically add, checkout, delete or move files
This is the last article about the Perforce client. That does not mean that is fully implemented, niether I will abandon the project. The NetBeans Perforce client will continue to be developed. By me, and hopefully by others. The point with this string of articles it to illustrate in which way it can be implemented a versioning client in NetBeans.
Since last article, the Perforce client was enriched with many functionalities. Thought, only the last one is relevant for our purpose. The topic is how to integrate into Perforce the IDE file manipulation operations like add, delete, rename, move or edit. You can add here also, how to handle the same situations, when files were modified outside IDE.
The key to this functionality is a class called VCSInterceptor. This class is used by NetBeans to announce the eventually versioning system about some change over files. Either if the change was operated form inside or outside of IDE.
I will split the methods from VCSInterceptor into five categories: queries, delete, move, create and change. You can find the source (comments are very intereting to read) here. Take a close look there.
queries
This category contain only one method isMutable(File file). This method is used to ovveride the default behavior proposed by the versioning systems which uses read-only files. When a file is read only, the IDE will see the file in this state, so it will not edit it. But when this method returns true, you let the IDE know that you actually can edit the file, even if is marked as read-only from the file system.
delete
beforeDelete and doDelete work together. The first let the IDE know if you want to implement the delete action for the specified file, in the second method you actually write the delete operation. There is another one method, afterDelete. This method is called after the file was deleted from the files system. Besides the moment of the notification, there is another very important difference. All methods are called when a delete operation was realized from IDE, but only the later (afterDelete) is fired when a file was deleted outside IDE. Take this into consideration when you implement the delete handling.
move
beforeMove, doMove, afterMove. Follows the same pattern as for delete operation. beforeMove is used to tell to the IDE that is want or don't want to handle the file move. doMove implements the real move action and afterMove is called (hard to believe, but ) .. after the mov operation. The only difference from delete is that all operations are called only for IDE file rename/move opertions. For this kind of operations outside IDE, NetBeans will fire two events: afterDelete for the source and afterCreate for the target.
create
Following the same pattern, for create we have beforeCreate, doCreate and afterCreate. Adding new files from outside IDE will fire only the last event (like on delete operations). I will go on, I hate to repeat.
change
This breaks the pattern. There is an beforeEdit method called when a file is about to be opened in edit mode. The is a perfect moment to do a checkout if you are in IDE. After that we have two events, beforeChange and afterChange. These events are related to content. beforeChange is called before the file content are about to be changed. afterChange end the cycle. One thing to mention here is that only afterChange is called if the file is updated outside IDE (javadoc does not mention that, but you can trust me on that). The later is a perfect place to put a checkout for outside IDE file modifications.
Just before presenting the source code for that, I have to mention that you don't need to implement all methods. These methods tries to catch all the possible events for all the possible versioning system scenarios. In my case i found to be enough to implement only 7 from 13. And I hope I covered all.
Here is the interceptor code:
This is the last article about the Perforce client. That does not mean that is fully implemented, niether I will abandon the project. The NetBeans Perforce client will continue to be developed. By me, and hopefully by others. The point with this string of articles it to illustrate in which way it can be implemented a versioning client in NetBeans.
Since last article, the Perforce client was enriched with many functionalities. Thought, only the last one is relevant for our purpose. The topic is how to integrate into Perforce the IDE file manipulation operations like add, delete, rename, move or edit. You can add here also, how to handle the same situations, when files were modified outside IDE.
The key to this functionality is a class called VCSInterceptor. This class is used by NetBeans to announce the eventually versioning system about some change over files. Either if the change was operated form inside or outside of IDE.
I will split the methods from VCSInterceptor into five categories: queries, delete, move, create and change. You can find the source (comments are very intereting to read) here. Take a close look there.
queries
This category contain only one method isMutable(File file). This method is used to ovveride the default behavior proposed by the versioning systems which uses read-only files. When a file is read only, the IDE will see the file in this state, so it will not edit it. But when this method returns true, you let the IDE know that you actually can edit the file, even if is marked as read-only from the file system.
delete
beforeDelete and doDelete work together. The first let the IDE know if you want to implement the delete action for the specified file, in the second method you actually write the delete operation. There is another one method, afterDelete. This method is called after the file was deleted from the files system. Besides the moment of the notification, there is another very important difference. All methods are called when a delete operation was realized from IDE, but only the later (afterDelete) is fired when a file was deleted outside IDE. Take this into consideration when you implement the delete handling.
move
beforeMove, doMove, afterMove. Follows the same pattern as for delete operation. beforeMove is used to tell to the IDE that is want or don't want to handle the file move. doMove implements the real move action and afterMove is called (hard to believe, but ) .. after the mov operation. The only difference from delete is that all operations are called only for IDE file rename/move opertions. For this kind of operations outside IDE, NetBeans will fire two events: afterDelete for the source and afterCreate for the target.
create
Following the same pattern, for create we have beforeCreate, doCreate and afterCreate. Adding new files from outside IDE will fire only the last event (like on delete operations). I will go on, I hate to repeat.
change
This breaks the pattern. There is an beforeEdit method called when a file is about to be opened in edit mode. The is a perfect moment to do a checkout if you are in IDE. After that we have two events, beforeChange and afterChange. These events are related to content. beforeChange is called before the file content are about to be changed. afterChange end the cycle. One thing to mention here is that only afterChange is called if the file is updated outside IDE (javadoc does not mention that, but you can trust me on that). The later is a perfect place to put a checkout for outside IDE file modifications.
Just before presenting the source code for that, I have to mention that you don't need to implement all methods. These methods tries to catch all the possible events for all the possible versioning system scenarios. In my case i found to be enough to implement only 7 from 13. And I hope I covered all.
Here is the interceptor code:
public class PerforceInterceptor extends VCSInterceptor {
@Override
public boolean isMutable(File file) {
return true; // really, for all? we will see that
}
/**
* Automatically add to perforce the new added file.
* The code is here to handle also the files added from outside IDE.
*
* @param file file in question
*/
@Override
public void afterCreate(File file) {
if (PerforceModuleConfig.getInstance().isPerforceExcluded(file)) {
return;
}
FileStatus status = getUpdatedFileStatus(file);
if (status == null || FileStatus.STATUS_UNKNOWN.equals(status)) {
try {
// this is what we really care
P4Client p4client = PerforceSystem.getP4Client();
p4client.actionAdd(file);
} catch (PerforceActionException ex) {
Exceptions.printStackTrace(ex);
}
}
}
/**
* Called when a file is uptodate and is about to be modified.
* The file is automatically checked out.
*
* @param file file in question
*/
@Override
public void beforeEdit(final File file) {
if (PerforceModuleConfig.getInstance().isPerforceExcluded(file)) {
return;
}
FileStatus status = getUpdatedFileStatus(file);
if (!FileStatus.STATUS_VERSIONED_UPTODATE.equals(status)) {
return;
}
try {
P4Client p4client = PerforceSystem.getP4Client();
p4client.actionEdit(file);
} catch (PerforceActionException ex) {
Exceptions.printStackTrace(ex);
}
}
/**
* Check out the uptodate file. The method is called when the file was
* modified outside IDE.
* Same logic as {@link #beforeEdit(java.io.File) }.
*
* @param file file in question
*/
@Override
public void afterChange(File file) {
beforeEdit(file);
}
/**
* Mark for delete files which are delete from outside/inside IDE.
* Handle different scenarios depending on the status of the file.
*
* @param file file in question
*/
@Override
public void afterDelete(File file) {
try {
P4Client p4client = PerforceSystem.getP4Client();
FileStatus status = getUpdatedFileStatus(file);
if (status == null) {
return;
}
switch (status) {
case STATUS_VERSIONED_ADD:
p4client.actionRevert(file);
if (file.exists()) {
file.delete();
}
break;
case STATUS_VERSIONED_UPTODATE:
p4client.actionDelete(file);
break;
case STATUS_VERSIONED_EDIT:
p4client.actionRevert(file);
if (file.exists()) {
p4client.actionDelete(file);
}
break;
}
} catch (PerforceActionException ex) {
Exceptions.printStackTrace(ex);
}
}
@Override
public boolean beforeMove(File file, File file1) {
if (PerforceModuleConfig.getInstance().isPerforceExcluded(file)) {
return false;
}
return true;
}
@Override
@SuppressWarnings("fallthrough")
public void doMove(File source, File target) throws IOException {
try {
P4Client p4client = PerforceSystem.getP4Client();
FileStatus status = getUpdatedFileStatus(source);
if (status == null) {
return;
}
switch (status) {
case STATUS_VERSIONED_UPTODATE:
p4client.actionEdit(source);
case STATUS_VERSIONED_ADD:
case STATUS_VERSIONED_EDIT:
p4client.actionMove(source, target);
}
} catch (Exception ex) {
Exceptions.printStackTrace(ex);
}
}
/**
* Retrieves the file status. If the cache is not hit, we do it the hard
* way, we push in cache the value from perforce system.
*
* @param file file in question
* @return the status of the file or null if the file is not handled at all.
*/
private FileStatus getUpdatedFileStatus(File file) {
FileStatusCache cache = PerforceSystem.getCache();
FileInformation fileInfo = cache.getFileInfo(file);
if (fileInfo == null) {
cache.refreshFiles(new String[]{file.getAbsolutePath()});
fileInfo = cache.getFileInfo(file);
}
return (fileInfo == null) ? null : fileInfo.getStatus();
}
} As I said, foolow the source code and the project PerforceNB on kenai site at http://kenai.com/projects/perforcenb/. See you.
October 13, 2009
Dynamic libraries in NetBeans
I hear often that NetBeans is not as configurable as Eclipse (as a sample). Don't want to start a religious blind war, you'll find nothing like that here.
Regarding this problem my answer is that NetBeans is configurable, but not in a ways as you would expect at the first glance. NetBeans for some things offers a limited GUI to manage things. As a sample, when you create a library. You have a GUI which gives you the possibility to create one. You can build that library only in one way: by selecting individual jars and folders for classes, sources and javadocs (I talk about Java SE libraries). If you want to create a customized library, there's no other GUI possibility.
But you have programming. By offering a friendly and stable API you can extend the platform and IDE as you like. If you know Emacs and Lisp you know what I mean. Is the same philosophy as in Unix/Linux world. No need of GUIs with thousands of screens full of usually unused information. A text file well commented is more than enough. In NetBeans is translated: "You have a very well documented API, stable, samples, why do you need a GUI?".
I will give a 10 minute way to create dynamic libraries in NetBeans. In 10 minutes spent you can do much more than with the best GUI ever.
First, what do I mean by dynamic library. I library which can change in time by your own rules. As a sample, you could want to upgrade the jar files without selecting the new jar files according to the new versions. Or, you would like to have your libraries in different folders (one for development, other for testing machine). Or simply, you know somehow where are your libraries, you have some piece of code to get this information, but you don't want to spent you vacation selecting dozens of jars. You imagination is your limit. With this very simple method you can achieve that in minutes.
First you need to create a NetBeans module project. Call it how do you like, is not important. You do that by File -> New Project -> NetBeans Modules -> Module. After Next, you give a name to your module and can choose Standalone Module. After another next you give the base package, a code name and you have it.
First we will create a class which extends ModuleInstall. This class will be called when the module is started up. In order to do this, we have to add an manifest entry like:
This class has a method called restored(). This method is called when the module is restored during startup. Here we will put our code:
And that is all. One thing though. You need to add dependencies to some Platform Libraries. In the contextual menu of the project action Properties -> Libraries -> Add. If you don't know what dependency you need simply put the class name in filter field and you will find what you search for.
I consider that NetBeans is a tool for programmers. And programmers don't fear coding. That is why this the best tool to configure your environment. Much flexible and better that a GUI.
Hope you like it.
Regarding this problem my answer is that NetBeans is configurable, but not in a ways as you would expect at the first glance. NetBeans for some things offers a limited GUI to manage things. As a sample, when you create a library. You have a GUI which gives you the possibility to create one. You can build that library only in one way: by selecting individual jars and folders for classes, sources and javadocs (I talk about Java SE libraries). If you want to create a customized library, there's no other GUI possibility.
But you have programming. By offering a friendly and stable API you can extend the platform and IDE as you like. If you know Emacs and Lisp you know what I mean. Is the same philosophy as in Unix/Linux world. No need of GUIs with thousands of screens full of usually unused information. A text file well commented is more than enough. In NetBeans is translated: "You have a very well documented API, stable, samples, why do you need a GUI?".
I will give a 10 minute way to create dynamic libraries in NetBeans. In 10 minutes spent you can do much more than with the best GUI ever.
First, what do I mean by dynamic library. I library which can change in time by your own rules. As a sample, you could want to upgrade the jar files without selecting the new jar files according to the new versions. Or, you would like to have your libraries in different folders (one for development, other for testing machine). Or simply, you know somehow where are your libraries, you have some piece of code to get this information, but you don't want to spent you vacation selecting dozens of jars. You imagination is your limit. With this very simple method you can achieve that in minutes.
First you need to create a NetBeans module project. Call it how do you like, is not important. You do that by File -> New Project -> NetBeans Modules -> Module. After Next, you give a name to your module and can choose Standalone Module. After another next you give the base package, a code name and you have it.
First we will create a class which extends ModuleInstall. This class will be called when the module is started up. In order to do this, we have to add an manifest entry like:
OpenIDE-Module-Install: com/my/package/MyModuleInstall.class
This class has a method called restored(). This method is called when the module is restored during startup. Here we will put our code:
public class ModuleHook extends ModuleInstall {
public void restored() {
Map<String, List<URL>> map = new HashMap<String, List<URL>>();
List<URL> classpath = new ArrayList<URL>();
map.put("classpath", classpath);
List<URL> javadoc = new ArrayList<URL>();
map.put("javadoc", javadoc);
// fill the URL map as you like, with jars, sources and javadocs
// .....
// by the way, you can use FileUtil.urlForArchiveOrDir(File file)
// to easy get an URL from a File
Library library = libraryManager.getDefault().getLibrary(
"MyLibrary");
if (library != null) {
// remove it if is an old version there
LibraryManager.getDefault().removeLibrary(library);
}
LibraryManager.getDefault().createLibrary("j2se", "MyLibrary", map);
}
}
And that is all. One thing though. You need to add dependencies to some Platform Libraries. In the contextual menu of the project action Properties -> Libraries -> Add. If you don't know what dependency you need simply put the class name in filter field and you will find what you search for.
I consider that NetBeans is a tool for programmers. And programmers don't fear coding. That is why this the best tool to configure your environment. Much flexible and better that a GUI.
Hope you like it.
Subscribe to:
Posts (Atom)