All,
we have multiple applications that we develop in IBM RAD 7.5.
Since, RAD does build all the applications that are required, I was wondering how can I achieve the same using ant files.
What I wanted to know is apart from my application specific libraries (that I will know where they are etc), which other jar files should my application point to?
I am talking about IBM WAS runtime libraries etc, so that my application builds successfully.
Is there a standard guideline by IBM on this?
Thanks.
The JARs provided in WAS_HOME/dev/ in WebSphere Application Server 7.0 and later, such as was_public.jar or j2ee.jar, are intended specifically for this purpose.
#bkail's answer is probably what you want if you're on one of those more recent versions of WAS (I don't have v7 or v8 installation to verify).
Another option is to expand the Server Runtime library that you have added to your RAD Java Build Path, you'll see the jars you want to include for your Ant build.
However, if you're actually running within RAD, you'll be pointing to a full server runtime which contains more than you need to simply compile. In that case, you can add one of the "WebSphere Application Server vX stub" runtimes just to see which jars those include; they are the minimum for compiling.
Which specific jars are in that environment will depend on your version of WAS, any installed Feature Packs, and probably even Fixpack levels. In many cases - depending on which APIs you're using - all that's needed to compile is j2ee.jar.
(You probably already realize this, but remember that you only need those jars in your classpath to compile, you don't want to deploy them in your WAR since they're already part of WAS.)
Related
How do I deal with this situation where the user's machine may not have dll like msvcp100.dll, msvcp100.dll? I don't want to my software not install on user's machine because this kind of error. I've been thinking in either find a tool and copy every single needed dll to the executable file run or try build a static version of Qt (may have sort of same result, in the end). I've seen applications that doesn't provide those dlls and it's up to user to get them, install etc. It may be a issue for those users, finding the right dll matching version and all. I'd like to avoid it.
How is this usually solved in a real world application?
You redistribute them in your installer.
Deployment of Qt apps is an uneasy issue. One should understand that you need to redistribute a compiler's dlls, as well as Qt dlls. For the msvc 2010 compiler you may just put the msvcp100.dll and msvcr100.dll files near your executable file.
As for Qt, the easiest way for windows deployment is to use the windeployqt command prompt util.
Update. How is this usually solved in real applications?
There is no fully automatic tools, which could determine all the dependencies, because the deployment of applications is a complex task. For example, you application can depend on many things such as libraries dlls, compiler's dlls, registry keys, drivers, environment variables, computer reboot requirement, ActiveX/COM components, other installed applications, etc...
But there are tools that can help you in this matter. They can be configured once for target project and then work all the time. This is called Build Automation, another similar concept is a Continuous Integration. As for the creation installation packages for end users, there is a lot of tools such as Nullsoft Scriptable Install System, Inno Setup, Qt Installer Framework, WiX, etc...List of installation software.
the installer script, put a command to download the dll that the application needs to run, and in the application source code, put it to use the dll's ONLY in the folder where it is running
If you are using the NSI installer, use this example
I've created a Class Mediator in which I want to intersect two policies. I've created the Class Mediator with Carbon Studio for Eclipse, which automatically adds some predefined libs to the build path of my project.
One of the libs is neethi-2.0.4.wso2v1.jar.
If I want to use the intersect-method I get an exception. If I have a look at the source I see that the intersect-method just throws an "UnsupportedOperationException".
So the given neethi lib is useless for intersection, therefore I want to use the newest Neethi lib (aka neethi-3.0.2.lib) for intersection inside my class mediator.
Could you tell me how I can include third party libs, especially in my use case these ones, that should override the once used inside the esb( neethi-2.0.4.wso2v1.jar).
Thanks
Developer Studio adds these libs to your project classpath, so that developers do not get build errors in the source code.
Therefore those libraries are only for the development time and available only with Dev Studio. They are not the libraries used in the runtime of the server.
Runtime libraries are provided by the WSO2 Carbon Server runtime. So this UnsupportedOperationException is thrown by the server is occurred due to the version of the neethi in the server does not support it. So you need to upgrade the library in the server runtime.
But as you can see, WSO2 have forked the neethi codebase and have some custom implementations on the forked source. So IMO, simply upgrading the version would not help.
Anyway you need to actually upgrade the library and see whether you face any issues with it.
To upgrade the versions, you can either create a Java Library artifact for newer Neethi library and include it in the CAR file and deploy the CAR file or copy the new Neethi library to <CARBON_HOME>/repository/components/lib location while the server is running.
You can find the current Neethi library in the <CARBON_HOME>/repository/components/plugins location. If you find some error or exception similar to "Linkage Error", then try to remove the older version of the library. But it would cause some other exceptions.
So IMO the bottom line is, you will face some issues with the version upgrade. But yes of course you can give a try and see, whether we can overcome them. Give it a try and post your observations here. We will try our best to assist you.
We are building a program under Linux which works within a specific Ubuntu version just fine. But we would like to have the same binary running on Ubuntu 10.04 and 11.10.
It would be completly ok to build the application on the 10.04 platform. But when I do this, I have dependencies to specific library versions (eg. libboost_thread.so.1.40.0) which are not aviable on 11.10 because it uses newer versions. The system is build using QMake.
I am looking for a tutorial or starting point how to solve these dependency conflicts for multiple Ubuntu platforms.
If nobody else feels like taking a swing at this I may as well inject something.
I am going to make a few assumptions.
You are distributing a binary/closed source application
You want to distribute it yourself
Thus ruling out the whole "just let the distro/users build it for their setup themselves".
Looking at how others have resolved similar issues I can see that it is common to include the shared libraries with your application and then use a loader/wrapper, what you want to call it, script that modifies the environment before launching the application. Specifically they modify the LD_LIBRARY_PATH to include the /lib folder included with the application.
The script could be as simple as.
#!/bin/sh
LD_LIBRARY_PATH=./lib ./myAppReal
That is how I solved distributing a Qt4 application to users having distributions not shipping newer than Qt-3.3.6 (in 2009... seriously). Edit: Might also say by users I mean the 5-ish people at the company paying for development, spec failure on our part not asking them to be more specific when they said cross-platform on modern operating systems.
Now someone will probably find about a dozen things wrong with this, but that's good, I can update and learn as we go.
EDIT: As JimR said this comes with security implications, if you leave your libs folder world writable someone may use it to inject malicious code into your application. Depending on how you plan on deploying it may or not be a real issue, but you should be aware of it.
We have a bunch of C/C++ modules and projects for QNX4, QNX6 and Linux. All of these are written in Eclipse/QNX Momentics and we use Project Sets (psf files) to combine different modules into projects as required. The projects are built using make. The psf files specify which modules are required for a certain project.
I have looked at two CI/Nightly build systems (BuildBot, Apache Continuum), but neither works particularly well with psf files, or supports them directly.
Does any one know of a CI system that would allow me to work with them, without having to use scripts to check stuff out, etc?
Btw, we are using CVS for versioning.
I only have experience (limited) with CruiseControl. It is very flexible and extensible, and has a number of plugins for third-party tools and version control systems; however it runs of Windows; you did not specify a platform. Of course you development platform and CI server platform need not be the same however.
I ended up using Hudson along with Ant and ant4eclipse plugin. Ant4Eclipse works with ProjectSet files, so it is perfect. Ant can also do Telnet and so I use it for QNX4
I've got an SDK I'm working on and the previous developer just dropped the DLLs in System32 (Apparently a serious offense: see here)
So assuming I move them out into \Program Files\\SDK (or whatever), how do I make sure that all the apps that needs those DLLs can access them? And to clarify, all apps that access these are doing early (static) binding to the DLLs at compile time so I can't pass the full path to them or anything. They need to be able to find it just given the DLL filename only.
Along the same lines, what about including a particular version of MSVCR80.dll? They all depend on this but I need to make sure they get a specific version (the one I include).
Any ideas?
An SDK is by definition a development kit. It's not a deployment patch...
What this means is that the applications that depend on those assemblies should ship with them and install them into their local \program files.. directories.
The reason for this is let's say you decide to do a breaking change by eliminating an entry point for example. By installing your "SDK", it has the potential to stop older programs from functioning.
You could take a play from the Java handbook and update the PATH environment variable. Whenever a program makes a call to an external assembly it searches along that environment variable until it finds it.
Of course, this could still result in the problem showing up. So your best bet is to just install the SDK into Program Files and let the developers of the products that depend on your toolkit decide whether they want to update their versions or not.
UPDATE
As I'm thinking about this, one last possibility is to GAC your assemblies. In the event you do so, bear in mind that they should be strongly named and properly versioned so as not to step on each other. I don't recommend this route because it hides the actual locations of the assemblies and makes uninstalling a little more difficult then simply hitting delete on your directory.
I can't tell you about your own DLLs, but you should never redistribute Microsoft DLLs alone.
You always have to use Microsoft Redistributable Package.
For example, if your application depends on dll from Dev Studio 2005 SP1, you should redistribute your application with Microsoft Visual Studio 2005 SP1 redistributable. The same applies to 2008. MS provide MSI based installer and Merge Module to include in your own product installer.
You are asking about "DLL Hell", something I had thought every Windows developer was familiar with. The order of search for DLLs is:
the directory the exex that calls them was loaded from
the current directory
various Windows directories (as discussed in your previous question)
directories in the PATH variable
As the Windows directories should be ruled out, that leaves you with three options.
You can put your install path in the search path, which will allow the applications to find them.
Alternatively, you can deploy the DLL's into the same directory as the application that depends on them.
I believe the first is better from an SDK perspective - it'll make development easier. But I think the second is better for when the application gets deployed to end-users, unless you expect there may be many consumers on a single system so the disk and memory footprint of having copies of the DLL are prohibitive.
If you can't install the dlls into the same directory as the exe using them you could append your directory to the PATH environment variable.
You don't say which version of Windows you're using, as the details are slightly different from what I remember.
You could also put your version of MSVCR80.dll in the same folder. However, you'd have to ensure that your folder was before the system one on the path otherwise the linker would pick up the "standard" one first. However, if you adopted the "local" dlls approach then you wouldn't have this problem as Windows searches the local directory first and so will pick up your version of MSVCR80.dll.
Is your version the latest or a previous version? You might be better off getting your app to work with that version or later and then allow the users to update their machines as required. This also illustrates why you should never mess with the dlls in \Windows or \Windows\system32 as, as others have pointed out, you could break other applications by changing the version of this dll.