I have two modules, the Main module and the Included module.
If I start the Main module it will show an interface with an iFrame which contains the Included module with some additional controls around it. I can also start the Included module separately.
I have solved this by having two separate .gwt.xml files and two separate entrypoints and the result is then placed in the same war folder.
If I use GWT Compile in eclipse I can add both my entrypoints to the list and it will compile both modules and everything will work correctly.
However if I click the "Run" button in eclipse to have my application run in devmode, then it will only recompile the entrypoint that I access in my browser. If I access the Main entrypoint then I will get a popup saying "gwt module may need to be recompiled" and devmode will not automatically recompile my Include entrypoint.
Is there someway that I can get devmode in eclipse to -always- recompile all of my modules?
As I understand it, you use an IFrame that contains the host page of a secondary GWT module. This frame's content must also be loaded using the gwt.codesvr=127.0.0.1:9997 parameter, or it would just load the latest compiled version of the GWT javascript without using the devmode server.
You should also make sure the debug configuration in Eclipse contains both modules. You can verify that by not clicking the button directly, but using the menu to open the "Debug Configurations" menu. Assuming you clicked on the "Debug" button before, you should find an existing GWT debug configuration there. Make sure that both modules are listed in the "GWT" tab.
If you have your modules in two different projects, you might have to use two instances of the dev mode server. (remember to use different ports)
Add you included module to your main module.
You can do this by adding
<inherits name="fully qualified name of your module"/>
this code in your main.gwt.xml file.
I would contend that this is more of a "project setup" problem, than "how can I get Eclipse to compile all my modules" problem. The reason I say this is, I have yet to see a GWT project where two entry points were necessary/made sense. The main reason to have separate entry points is for reuse (Dev Guide, Dividing code into multiple modules).
The way I would approach the problem is to have your Main module, which includes the controls and iFrame (and have it inherit your Included module), so the same as you are now. Where I would differ is I would set up the Included module to not have an entry point. Instead, if you have a reason to run it separately from the Main module, I would create a "drive"/"launcher" module that also inherits the Included module. However, instead of controls and an iFrame like the Main module, this driver module would consist merely of an entry point and a place to attach your Included module.
You might also check out this question for more discussion in this same vein: Multiple Entry Points in GWT.
Related
I am setting up Selenium right now and i have to copy the Selenium files into my eclipse project. Unfortunately, every tutorial has different files which they are adding to the Eclipse project, mostly because they are using older Selenium versions.
Currently, i just added all jar. files from the "libs" folder and also the jar file called "client-combined-3.5.3-nodeps". So i hope these are all files i need.
My question is, what happens if some files are missing? Is Selenium then not usable correctly?
Selenium Java client provides us the APIs through different packages. So when we need to use the APIs we have to make the necessary imports as well.
Now, if you miss out to add certain Selenium related jars in your Project, some methods from your main() or #test Class may not get resolved due to absence of the imports. Hence your program/script will show you errors as unresolved methods and will the program will not get compiled/executed.
Hence, it's always a good idea to add all the jars in your project from the released Selenium Client SDK.
At times, there may exist certain methods which are defined in multiple packages. For example method abc() may be defined in java.util.pqr; as well as in org.openqa.selenium.xyz;. In those cases we have to make our imports wisely as per our requirement.
I would like to develop GUI application with plugins. The plugins contains VCL Forms which are inherited from Base Forms in the Plugin-Core library. The main application can select which plugin to load dynamically, and then which Form subclasses to display.
In the users side, I would like to deploy main .EXE, the Plugin-Core library, and many plugin libraries for different models. I could release new or modify existed plugin libraries to users to display new Forms for new devices without modifying the main .EXE and the Plugin-Core library.
The first version I developed uses DLL approach, namely both the Plugin-Core library and the plugins are in DLL form. Everything is just fine on the users side. However, in the developers side, the plugin DLL project can not be linked without Base Forms defined in the Plugin-Core DLL project. It means that the Base Forms are actually statically linked in each plugin DLL project, and if someday I modify the Base Forms and rebuild the Plugin-Core DLL project, I have to rebuild all plugin DLL projects and re-release plugin .DLL s to users, too.
After searching and asking in StackOverflow, I realized the limitation that VCL Forms can NOT be inherited across DLL boundary is due to RTTI conflict(?). The suggested solution is to modify the libraries from DLL to BPL form, which is the second version I developed. Everything is also fine except the following two:
The dynamic loaded Form from plugin BPL is separated from the main .EXE in Windows taskbar. It is not what I desired. The solution is that I enabled "Build with runtime packages" in the .EXE project.
After I enabled "Build with runtime packages" in the .EXE project, I have to release other .BPLs to the users, such as vcl.bpl and rtl.bpl. This is not perfectly what I desired.
I would like to know that the above two issues can be resolved at the same time? In my thought, I could resolve both two issues if I:
Disable "Build with runtime packages" in .EXE project.
Enable "Build with runtime packages" in all .BPL projects.
In this way, the .EXE can run without vcl.bpl and rtl.bpl bundled, and the plugin .BPL s can be loaded successfully because the dependent units are already part of the main .EXE? Am I correct? However, the "Build with runtime packages" checkbox is disabled in all .BPL project options. As a result I don't have a chance to check whether the solution works or not. I am sorry for the lengthy description and I can not attach picture due to company's Internet security policy.
The dynamic loaded Form from plugin BPL is separated from the main .EXE in Windows taskbar. It is not what I desired. The solution is that I enabled "Build with runtime packages" in the .EXE project.
After loading a BPL, pass the EXE's Application.Handle to the BPL and assign it to the BPL's own Application.Handle before it creates any Form instances.
Alternatively, on Windows 7+, you can have the EXE call SetCurrentProcessExplicitAppUserModelID() to establish a App ID for its taskbar button. Then each Form in the BPLs can use SHGetPropertyStoreForWindow() and IPropertyStore.SetValue(PKEY_AppUserModel_ID) to set the same App ID for their windows. Multiple windows with the same App ID are grouped together under a single taskbar button.
See MSDN for more details: Application User Model IDs (AppUserModelIDs)
I would like to know that the above two issues can be resolved at the same time? In my thought, I could resolve both two issues if I:
Disable "Build with runtime packages" in .EXE project.
Enable "Build with runtime packages" in all .BPL projects.
In this way, the .EXE can run without vcl.bpl and rtl.bpl bundled, and the plugin .BPL s can be loaded successfully because the dependent units are already part of the main .EXE? Am I correct?
No. BPLs cannot use the EXE's built-in units like that.
If you disable "Build with Runtime Packages", the RTL/VCL units will be statically linked into the executable file. The problem with doing that is multiple copies of a given unit cannot be loaded in memory at the same time, so you wouldn't be able to load multiple BPLs together (or even at all) if the same RTL/VCL units are statically linked into multiple BPLs, or even the EXE itself.
If you enable "Build with Runtime Packages", the executable file will be dependent on the RTL/VCL BPLs, which must then be deployed.
So, if your EXE and BPLs share common units, those units must be loaded via shared BPL(s) so only one copy of the units exist in memory. There is no avoiding that when writing custom BPLs. Which means at a minimum you usually have to deploy RTL.BPL if you are using basic RTL functionalities, and VCL.BPL for UIs.
I have been struggling a while now to try to reuse the RemoteService implementation from one GWT project into a new one.
Here's the big picture:
I have a working smartgwt-mobile project and we now decided we wanted a desktop version of the same project, using regular smart-gwt. The GUI of this new app will obviously be different but the server side code will be exactly the same.
I tried to just "borrow" the RemoteService interface, its async counterpart and the whole server package by either linking the package folders in the other project inside the new source structure (I am using Eclipse with GWT plugin) or by adding the borrowed code path as a filtered source folder to the build path, and while this satisfies the Eclipse dependency checker, the GWT compiler is unable to find the borrowed code suggesting I need to add "inherit" declarations in the module .gwt.xml file.
When I do this and recompile it now expects a second module .gwt.xml file in the root of the borrowed code which is not acceptable because it would affect the other project.
I have been reading up on the GWT module documentation but I fail to see how to implement such a scheme. It may actually be impossible to do what I am trying to achieve.
I would be willing, if that solves the problem, to create a third project that simply defines a GWT RemoteService module that then will be inherited by both the mobile and desktop smartgwt projects.
Does anybody have suggestions about how to tackle this issue?
I'l agree to "third project that simply defines a GWT RemoteService module that then will be inherited by both the mobile and desktop smartgwt projects"
Why because, I'm just already doing this. Yes that is Obviously an DAO project(DB layer) which has all my DB business logic methods there.
And its always better to maintain separate DAO layer to expose your data to services(ex.webservices).
So here's how I solved the issue.
The problem with linking to an existing GWT project source folders is that the GWT compiler always (at least that's what it looks like) expects to find a GWT module definition file (.gwt.xml). I have not been able to link in the source folders in such a way that the GWT compiler is happy, even though the Eclipse dependency resolver has no problem with it.
So I created a third project using the GWT Eclipse plugin. I unchecked the "Create Sample Code" option, so I ended up with an empty GWT project. I then selected 'Add' > 'New' > 'Other' > 'Google' > 'Module', entered a module name, e.g. 'myModule', a package name, e.g. 'com.myCompany.myModule' and clicked 'Finish'. The GWT New Module wizard created the package and a child package under it named 'com.myCompany.myModule.client' and I created 'com.myCompany.myModule.server' myself.
Now I copied the RemoteService and related classes (The implementation and Async version ), plus all the server side code the RemoteService code calls from the original project I wanted to borrow from and pasted it into the new project. Very soon I had all dependencies satisfied and I opened the Build Path dialog on the new Smart-GWT web app project and included the GWT RemoteService Module Project in the projects tab. Last thing to do was adding an inherit element to the .gwt.xml file:
<inherits name='com.myCompany.myModule.MyModule'/>
Voilá: That's all there is to it. If you select 'GWT Compile Project' It compiles and runs in dev mode without warnings.
I now still have to delete the shared code from the first project and inherit from the module, bat that is simply a repetition of what I already did.
In the end this was much less painful as I imagined it to be, so I recommend this approach.
We have an application developed in NetBeans, based on the NetBeans platform. There's a 3'rd party program that we have a runtime dependency on, more specifically a jar in the other progams lib folder.
How should we include the other progam's jar in our classpath?
The recommendation from the other progam's manufacturer is to set environment variable CLASSPATH to include
C:\Progam Files\Other Program\lib\theJAR.jar
And if that's not possible, we should copy theJAR.jar to JRE-HOME\lib\ext
We must not copy theJAR.jar anywhere else, that might cause it to stop working...
Now NetBeans takes no notice of what's on environment variable CLASSPATH. Their recommended way seems to be to make a wrapper, but that would lead to copying the jar, unless there's some way to make a wrapper module that points to CLASSPATH?
At the moment we are copying the jar into JRE-HOME\lib\ext. But then there's unnecessary hassle when we install some java update.
Do you have any solution to this problem? It seems like something that might be simple, but I haven't found the right place to look yet...
Edit: The application is ant-based.
From the documentation for the Module System API's overview of the runtime infrastructure (bottom of the page under the section "Common Problems and Solutions"):
Q: Can my module add a library JAR to the classpath from outside the
IDE [read: platform] installation?...
A: Not easily. You have a few options:
Add an entry to ide.cfg [your app's .config file]. For example:
-cp:a c:\eak\lib\eak.jar This startup file provides the ability to add classpath entries to the IDE's Java invocation.
...
It goes on to list two more options. The second option is the same solution you've come up with. The third is to "partition your module and use a new classloader" which I can't recommend either way since I have no experience doing this (but it's worth a read).
Assuming that this first option is what you are looking for, you will need to add a custom .conf file to your project and point to it in your project.properties file, like so: app.conf=nbproject/my.conf. This will add your custom .conf file to your app's install directory instead of the default config file that is normally added. Of course, you'll need to add the -cp:a c:\eak\lib\eak.jar entry to this custom config file in order to load the .jar.
During development you'll need to add the following entry to the project.properties file: run.args.extra=-cp:a c:\eak\lib\eak.jar. This will pass the command line option to your debug instance.
You can add that .jar file by following the steps below:
In the left side panel named "Projects" open your project and right click on the "Libraries", then select "Add JAR/Folder...".
Then select your .jar file from the location where you have stored it in the next dialog box that opens and then press "Open".
Vola Finished!!! (with the same process you can add other libraries also like JavaCV, JMF,etc)
And Now You Can Use That .Jar File From Your Project Library.
Hope It Helps.
For a few weeks I've been trying out GWT. Now I want to integrate a new module i made in GWT with an existing Web application. My problem is that I wan t the module to be put in a subdirectory of the webapp. Currently the code is put in ${webappDirectory}, but I want it in ${webappDirectory}/protected.
Any thoughts?
GWT always compiles to a subfolder (named after the compiled module, or its rename-to attribute) of the -war folder you give it as argument; and it makes no assumption as to where the host page (the page that loads the *.nocache.js file) lives.
That means you can very well have your host page in a protected subfolder and have it load ../protected-gwt/protected-gwt.nocache.js.
If you really do want to put the compiled JS into the protected folder you'll have to either use it as the -war folder (and pass -deploy as argument to the GWT compiler pointing to the parent folder's WEB-INF/deploy –or somewhere else– if you don't want a protected/WEB-INF/deploy folder to be created), or move the files later, during your build process.
In any case, this will impact your ability to use the DevMode; one simple thing that's assured to work, is to deploy your webapp and launch the DevMode in -noserver mode.