The Java Text Copy Paste Module/Plugin now works in NetBeans 6.0. I tested it and am using it in 6.0. The module helps copy and paste text from and to Java source code. This module works well with SQL or HTML or XML which needs to be embedded in Java source code or needs to be extracted from Java source code. Look for the "Java Text Copy and Paste" context menu inside Java source files. There are no default hot keys for the functionality. I suggest playing around with the different actions to get a feel for how they work. + signs are pre-pended at the beginning of lines of source to make hand editing of generated code easier.
This module allows source code to be selected then formatted back into the text format it was before converted into Java source. It also allows one to select XML, HTML, or SQL in their favorite tool (as text) and then paste into the NetBeans Java editor where it is automatically formatted as Java source code. I find I use it all the time and comes in very handy.
Version 1.1 added a new way to copy the text from the editor which keeps newlines in the selected text yet removes any newlines fromJ the actual Java sources.
Version 1.2 adds tested support for NetBeans 6.0 and corrects a bug which deals with concurrent access of the edited document. The bug has not shown any issues yet, but possibly could as concurrent access could have unknown results.
Version 1.3 fixes an issue dealing with the context menu sorting and NetBeans 6.0.
Enjoy!
2007-07-24
Sharing classes with modules and non-module based JARs in a NetBeans RCP Application
Sometimes, such as when using JPA or Hibernate from more than one module, it is necessary to share classes between any number of modules and non-module based libraries/JARs in a NetBeans RCP/Platform based application. The reason this solution is needed is because some libraries, and even at times modules, need to be able to see classes from other libraries and modules at runtime to use certain patterns and these classes and modules have a cyclic dependency because of the type of classes being used. JPA or Hibernate are perfect examples where the entity manager will reside in one library and needs to be able to create instances of classes from another library or module, which also references other JPA or Hibernate classes themselves, using annotations or XML descriptors. This usually happens dynamically at runtime in these type situations.
In NetBeans the module system provides good separation. The problem is this can at times be too strict. To work around this issue you need to create a custom platform and then find the platform#/core directory under the platform directory and put the libraries and JARs in it. I will update this later to explain how to setup a custom platform.
Once you have the libraries in the core directory they can be used by any module or other library at runtime. These JARs can be copied to the core folder at build time and before distribution using ANT, so it is a good idea to make this custom platform reside relative to your project. Another good reason to have them reside relative to the project is that these common JAR files will have to be referenced by your module projects. To reference these JARs from your module projects you will have to edit project.properties and add a property:
cp.extra
which is a colon delimited list of JAR files needed for the classes the particular module needs to reference. Once cp.extra is setup, any errors you may see in the Java editor, related to these classes, should disappear and you can actually compile your project.
It is best to avoid doing this if possible as it removes the ability to use different versions of the same libraries by different modules while also removing the ability to auto-update these libraries, but when it is not possible to avoid such things then they are certainly needed. You wouldn't shoot yourself in the foot for spite, nor do I suspect you would not complete your project just because it best to not step outside the bounds of the regular module class loaders.
In NetBeans the module system provides good separation. The problem is this can at times be too strict. To work around this issue you need to create a custom platform and then find the platform#/core directory under the platform directory and put the libraries and JARs in it. I will update this later to explain how to setup a custom platform.
Once you have the libraries in the core directory they can be used by any module or other library at runtime. These JARs can be copied to the core folder at build time and before distribution using ANT, so it is a good idea to make this custom platform reside relative to your project. Another good reason to have them reside relative to the project is that these common JAR files will have to be referenced by your module projects. To reference these JARs from your module projects you will have to edit project.properties and add a property:
cp.extra
which is a colon delimited list of JAR files needed for the classes the particular module needs to reference. Once cp.extra is setup, any errors you may see in the Java editor, related to these classes, should disappear and you can actually compile your project.
It is best to avoid doing this if possible as it removes the ability to use different versions of the same libraries by different modules while also removing the ability to auto-update these libraries, but when it is not possible to avoid such things then they are certainly needed. You wouldn't shoot yourself in the foot for spite, nor do I suspect you would not complete your project just because it best to not step outside the bounds of the regular module class loaders.
2007-07-09
Eclipse 3.3 Europa SPAM, regular emails, and magazine articles related to simultaneous project releases
Not wanting to start a flame war, but I want to talk about this. I have been getting "alot" of SPAM from places like bzmedia and ZD (Ziff-Davis) about Eclipse 3.3 Europa. I have also been getting emails from my magazine subscriptions such as eWeek and SD Times. I have also seen articles in my different magazines about it.
The main talking point in the articles and emails I'm referring focuses on the simultaneous release of 21 projects in the Eclipse IDE. These are the core Eclipse projects, so I'm not talking about 3rd party projects. This means the plug-ins/projects will all run with Eclipse 3.3, so you don't have plug-in Z supported in 3.3 yet X and Y are only supported up to 3.2.
It is no secret I'm a member of the NetBeans community. I certainly don't try to hide the fact. Anyways, NetBeans has been doing this for years. JSP, Web, EE, Swing UI, Mobile developer, NetBeans RCP, etc have always been released together and work in the current version of the IDE. I think it is good that Eclipse is doing this now, but I also think the apparent amount of resources going into highlighting this fact, promoting it, and that it took this long for it to happen is funny.
The main talking point in the articles and emails I'm referring focuses on the simultaneous release of 21 projects in the Eclipse IDE. These are the core Eclipse projects, so I'm not talking about 3rd party projects. This means the plug-ins/projects will all run with Eclipse 3.3, so you don't have plug-in Z supported in 3.3 yet X and Y are only supported up to 3.2.
It is no secret I'm a member of the NetBeans community. I certainly don't try to hide the fact. Anyways, NetBeans has been doing this for years. JSP, Web, EE, Swing UI, Mobile developer, NetBeans RCP, etc have always been released together and work in the current version of the IDE. I think it is good that Eclipse is doing this now, but I also think the apparent amount of resources going into highlighting this fact, promoting it, and that it took this long for it to happen is funny.
Subscribe to:
Posts (Atom)