I want to test my OSGI app in Pax Exam, but i have some trouble with starting Application from one of my plug-ins.
I use Equinox and there is some equinox-specific class that extends org.eclipse.equinox.app.IApplication. This class can be then selected in Eclipse Application Launcher and is first class to be run (in my case it controls app lifecycle).
When I run Pax Exam test, all bundles are resolved, but my IApplication is not started.
How can I run this kind of application in Pax Exam?
Additionally how can I pass some app arguments? I see only some frameworkProperty (-F) and systemProperty (-D), but i need some regular app arguments.
As far as I can tell IApplication is not part of equinox but part of the eclipse plattform. So I think it is not directly supported in pax exam. Pax exam will only start the OSGi framework and load and start the bundles you specify.
So the way to make this work might be to load the eclipse bundles that take care of the start of applications. I am not sure though how this would work in detail.
When using eclipse specific stuff you make your application less portable. So maybe you can achieve the same thing with pure OSGi infrastructure?
Or is the application you want to test an eclipse RCP application? In this case pax exam is probably not the best test facility. Some UI test frameworks would match better in this case. (e.g. https://developers.google.com/java-dev-tools/wintester/html/)
The IApplication is part of Equinox, and uses the registry to find out what is installed. So as well as including the appropriate jars in PAX, you'll also need to ensure that you start at least declarative services and the extension registry bundles, as otherwise the IApplication stuff won't be found.
Secondly there is no bundle that calls the EclipseStarter class, which is the thing that handles the main arguments, and which passes that through to the runtime. So unless you're doing that yourself, you will find that the application won't run at all.
If you're starting Eclipse specifically you might find some Eclipse-specific arguments to specify these as Java system properties:
http://help.eclipse.org/luna/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fruntime-options.html
for example, you could specify -Dapplication.id=yourapp
You might also try eclipse.commands as a newline-separated list of arguments.
Related
my question is about developing a suite of applications using NetBeans Platform 8.x and modifying the harness.
We would like to modify the harness independently for the apps, and be able to commit that into source control. The modified harnesses work when they replace the existing one in the NetBeans installation. We have modified the harnesses and placed them inside the suite directory (as just a directory) for the command line app and the GUI app. Ideally we would like to carry on using the platform installed at the default location but modify the harness per app?
What we have tried:
We defined:
suite.dir=${basedir}
harness.dir=${suite.dir}/harness
This works great for the clean and build targets. But it does not work for the GUI invoked package as installers action.
Looking at the source for:
org.netbeans.modules.apisupport.installer.actions.BuildInstallersAction()
it is not immediately clear how to achieve this because it makes use of InstalledFileLocator.getDefault().locate
to find the harness.
Is there away to direct the installer 'build' to use the modified harness in ${suite.dir}/harness ?
Or is the only option to register our own action to replace BuildInstallersAction() ? - if that is possible?
We are trying to avoid having to copy the entire platform source (as seems to be suggested in harness\README - may be I have misunderstood it?) as well, we only modify the harness.
Thanks
Trevor
I am trying to manage my dependencies of my play framework application. I am trying to remove/update some jar that exists in my classpath. Does that even possible?
It would be great to get an explanation of how does play framework manages classloaders. I understood that in order to obtain hot redeployment of code in development mode Play is restarting the application classloader and loads all classes again. Does it right?
Thanks a lot!
It's not really Play managing the hot reloading but rather the Play SBT plugin.
A Play application's main method is in play.core.server.NettyServer. The method receives a reloader of type SBTLink and each time a request hits the server, the application delegates the task of checking if there have been any code changes to the reloader.
If there has been a code change then the existing classloader is removed and replaced with a new one which includes the updated bytecode. The application is restarted but, of course, the JVM is not.
Play is not designed to provision dynamic swapping of Jars at runtime. For this, you would need to look at things like OSGi (which I would not personally recommend after a few years of working with it).
What is the right way to make an RCP application that is “ready for plugins”? I have struggled to do this basic concept and am trying to accomplish this in Eclipse 3.7 (latest 3.x version).
Step 1
I would like to explore this by using 3 eclipse plugin projects:
• HelloWorldRCP
• HelloWorldPluginA
• HelloWorldPluginB
Would it make sense to make HelloWorldRCP with all the common things such as a menu-bar with an Edit menu including cut, copy and paste menu items? The HelloWorldPluginA could add an additional menu-item called “Alpha” and HelloWorldPluginB could add yet another menu-item called “Beta”? However, the cut, copy and paste functionality could still work within Plugin A and B?
Step 2
Next, how do I deploy this as a “product”? I have made a new product configuration and defined the dependencies from the default runtime configuration that was made. I do notice that there are a lot of dependency jars that are included, but I don’t think I use them. For example, I don’t use data-binding to my knowledge, but it keeps coming up as a required dependency.
I go to Export | Eclipse Product and an executable environment is created in my desired folder. However, when I copy this to another machine it seems to keep referencing the original machines Java installation location. How does one get around this?
I have tried to bundle a jre with the Product Export but nothing is created. I have also just tried copying my jre6 as a jre folder. This does seem to work.
Next problem here is the 32/64 bit Java execution environments. What is advised here? I have been aiming to build on 32 bit only and then hopefully that will run on 32 or 64bit platforms. Is this correct?
Step 3
I need to web-start this now. The old way of initiating an Eclipse 3.5 application, using a startup.jar has changed. I now use the equinox launcher and reference it in the jnlp instead of the startup.jar. However, I keep getting an exception which seems related to the 32/64 bit equinox win32_64 jar. I notice that the export writes a folder and not a jar. I read somewhere that this is a “clever trick” to allow compatibility for both 32 and 64bit runtime environments.
The problem here is that I need a jar and not a folder so that I can sign the jars required and deploy accordingly.
Does anyone have a Java Web-start example for and Eclipse 3.7 RCP application? Or any advice?
You are going to need a lot of time to learn everything you've asked about here.
Here is one of the best places to start... http://www.vogella.com/eclipse.html
That site covers a lot of basics. But you need a little more than basics.
The best example of a working RCP product with some of the features you require can be found at ... http://max-server.myftp.org/trac/mp3m
This guy (Kai) makes all of the source code available via SVN, and he has some very advanced stuff going on in his application. He also has a good blog with some advanced RCP tips and tricks. http://www.toedter.com/blog/
Another thing you'll want to investigate is Tycho. I realize that you didn't mention anything about building your application, but I've found that using Tycho for building has made my most recent foray into Eclipse RCP 100 times better than the other times I've done RCP work. So, my advice, get to know Tycho. http://wiki.eclipse.org/Tycho/Reference_Card
The learning curve of Eclipse RCP is somewhat steep, but I think it's worth the effort.
Good Luck!
Our msbuild process creates a variety of zip packages for deployment (mostly web sites, but other things as well). We have a variety of recurring problems that keep sneaking back - files included that shouldn't be, missing resources. This screams for automated validation. The criteria to test for are simple
Validation of foosite package:
Resource files are present.
No test result files, obj files, or other build artifacts
And so forth.
Ideally, I could use nunit or mstest, which everone is familiar with. Msbuild knows where the packages are. We have a lot of packages, possible concurrent builds on different branches. Ergo, the location of the packages and names of the packages are not deterministic - so the tests don't know where the packages are.
What is the simplest way to feed msbuild information to mstest or nunit? The answer to this question would one possible answer, however, that question got architectural advice instead of an answer. I know this isn't a unit test, but the test framework is handy, anyway. I could create an exe to validate the build - but why add a couple hours to the project?
Or, do you have a better suggestion for automatically validating build packages? (MSIs, zips, whatever)?
What I've ended up doing is having a bunch of custom MS build tasks which spin up a virtual machine on Virtual Server, copy the MSI onto the machine, silently deploy it and then validate against it. I used PSExec to start the MSI. It could then use the MSTest command line runner to use MSTest and run your test bits.
This is probably overkill for you, but using a VM allows you to start clean and not be affected by any previous installs on your dev box.
If you want a fast fail, like a unit test, then I suggest you create unit tests against your packages. Such a test would unzip the .ZIP packages, and run some asserts against the contents.
You could even use some TDD techniques against the packages. For instance, if you have a deployment fail because a particular file is missing, then write a unit test that fails because the file is missing; change the build so that the file is present; then make sure the unit test succeeds.
But in general, deployment issues are broader than that, and I echo the suggestion from blowdart. Deploy into one or more virtual machines, then run automates tests over the deployed environments. These tests would not only test for simple things like was there an error returned during the installation itself; they would also check things like were the IIS virtual directories set up correctly, with the correct properties and contents, and does the web site basically run.
I'd use several different virtual machines to test different deployment scenarios: one for a clean deploy; one for an upgrade from version .-1, etc. It's possible that the same, or similar IVT tests could be run for each environment.
Even if you can't do this all at once, the thought process involved in this exercise should lead to a more formal definition of what your deployment environment really is. You this will be helpful when you get a chance to embody this formal definition in actual tests.
Are there any differences between the original CruiseControl and the .NET port? I've compared the 2, but can't find any big differences except the language it has been developed in. I want to use either one of them for (automated) testing of web applications, using Selenium and Subversion, perhaps even Groovy but don't know which to choose.
[edit]
After looking at CC and Hudson, I've chosen Hudson for it's simplicity, it already has plugins to run Groovy scripts and Selenium as well
Choose me, choose me! (I work on the original CruiseControl.)
I've never used CC.NET but from what I know I agree that they are pretty comparable. Probably the most important difference is cross-platform vs. Windows only.
Now I wonder how long until someone comes by and says their both crap and you should try Hudson? ;)
(And of course there are lots of other choices...)
CruiseControl.NET (cc.net henceforth) has build queues (http://confluence.public.thoughtworks.org/display/CCNET/Project+Configuration+Block), which allows you to serialize builds that depends on a certain build order. I'm in the process of emulating this behavior in the java version of cruisecontrol but the functionality doesn't map one to one. The reason however, that I'm at all moving from the .net to the java version is that the .net version core dumps with mono (cc.net nightly build and mono nightly build as of two months ago). The fault lies with monos thread handling but voids attempts to get cc.net up and running.
The documentation on this can be tricky to find, if you don't notice the version numbers that the configuration examples/documentation adhere to (confluence.public.thoughtworks.org has the updated configuration documentation whereas ccnet.sourceforge.net has not. I know that the ccnet is most likely a dead site, but if your're not carefully reading the datestamps on every page you're visiting, this may bite you).
Furthermore, the sourcecontrol blocks for cvs and svn in cc.net are more granular and featurerich than their counterpart in the java version, but this has not been a problem in my work. The java version is also easy to extend/modify re: plugin behavior, but you would really just like to see this kind of work going upstream instead of forking.
I'm fairly impressed with both the java version and the fork in .net (modulo mono runtime behavior), but you really do not want to try any of the other forks of cruisecontrol. I've had peripheral experience with hudson, and the features were just not compelling enough to veer me from cruisecontrol. Hudson has a (somewhat coloured) comparison map of Hudson and CruiseControl (java) at http://hudson.gotdns.com/wiki/display/HUDSON/Home
A viable alternative is the python implemented buildbot (http://buildbot.net/trac). It does not have fancy gui dashboards and the setup is somewhat more commandline-bound, but if you're doing distributed builds, it's very easy to set up and get running.
I think for you it will come down to operating system, original can run on nix, and .net version runs on windows.
There are other automated build utilities that can do this as well, such as TeamCity in the windows space, and cruisecontrol.rb in the ruby world.
Also there is a PowerShell based build utility called pSake that can poll subversion and perform tasks.