My current task in the company is to implement IVY dependency management.
Now I hit the following libraries that I couldn't find in usual Maven repositories, such as http://mvnrepository.com:
com.ibm.mq.jar
com.ibm.mq.pcf.jar
...
and so forth (they are all with the prefix: com.ibm.mq).
I could found them on a separated website: http://www.java2s.com/
But it's not Maven compatible.
So, where could I found those? What's the best solution to overcome this?
I'm thinking, uploading them manually to the team nexus. But is this the usual procedure in such cases?
Thanks a lot in advance.
Best place to find those is directly from IBM. Please see this answer for the different versions of the WMQ Java/JMS client available.
As for the best way to package these, please be aware that if you want IBM to support them you need to install the client code rather than just bundling in the jar files. The reason IBM is reluctant to support non-standard installs should concern you as well if the app is to be installed in Production. The full client includes considerable additional functionality such as diagnostics, trace functions, crypto libs, JSSE, etc. In addition, it is the only install against which you can apply IBM's maintenance.
If you install the jars from a 3rd party site such as the one linked above, do you even know what version they are? Has any of the maintenance been applied? Have the latest patches been applied? Since IBM only distributes the full client, and OEMs are not authorized to distribute the jar files except as part of their application, any site offering the WMQ jar files is by definition pirating them.
I realize that requiring you to do the full client install is considered burdensome when you are used to being able to just grab some jars and go. On the other hand, if you don't need support then you might install the WMQ Client on a VM somewhere, keep it up to date and grab the jar files from there. That way you have a known-good set of files that are all in sync and to which you can apply maintenance.
If you'd like to suggest to IBM that they need a lighter-weight Java solution, feel free to raise the requirement (or vote on it if it already exists) at the IBM Request For Enhancement (RFE) Community.
Related
I am developing a Java framework/API to solve a problem at a client. The code/idea is my property (not the client's). I think it might be useful for others, so I would like to publish it as a open source project.
By publishing I mean bringing it out in the open - making it available as a Maven project.
I can think of conforming to Maven structure, proper documentation/example usage available on a web site, and unit tests, maybe some code coverage threshold.
But does it have to be run by some committee? Do I have to present it to somebody? What steps do I need to take to eventually have it available as a Maven dependency?
There's no committee or approval process that I know of. All you have to do is put your code into a public Github repo. This is how open source software works.
Per Kapep's excellent suggestion below, you have to choose a license as well. Apache, Creative Commons, Gnu, MIT - these are a few of your choices. Know what they mean before you decide.
Your problem begins on that day - you'll have to make others aware of it and see if it's adopted by others. If it's good, you'll have the nice problems of dealing with a user base and having others change your code. If not, it'll languish in the repo.
I need to create an Installer for my company's product. Can anyone please suggest some tools to start with.
Requirements are:
Support for copying/editing/extracting etc
Support for Ant based targets
Support for adding custom Java code in the workflow
If JRE can be bundled along.
Need to bundle following application server: JBoss, Weblogic, Websphere
Cross platform support (Win/Linux/Solaris)
Support 32-bit and 64-bit platforms
Cloud support - To check for upgrades, download and install. Check for available patches etc.
Customizable by customers for adding their custom changes
Suggestions please.
Regards,
I have used Opsware (now HP)before, but it's not free. It will basically kick off RPMs or batch scripts to do the job. But you can simply create those without the product.
https://en.wikipedia.org/wiki/Opsware
After exhausting all conceivable options over a matter of weeks, and after the drudgery of the back and forth with subpar IBM support, I have come to the conclusion that the only explanation for why my specific development environment fails to run a custom theme where other environments have no problems must have something to do with bad data in configurations contained in the embedded Derby database that comes packaged in the WebSphere Portal profile.
Google gives me no insights into the error I am running into, and I have confirmed the correctness of every single configuration file that even has the slightest chance of impacting the use of the Portal within a simple page. Any and all types of caching or logs have been disabled and purged and tracing reveals no additional information that is helpful to diagnosing the problem.
Are there any scripts within the installation of Portal that can be run to wipe and rebuild the embedded database? If not is the only option to scorch earth? The schema and data are cryptic to me, but if it is possible to diagnose the database for specific problems are there any tools that can do that or do I need detailed architectural knowledge to have any hope of finding bad data in this software?
I finally discovered what the problem is and it does indeed have nothing to do with a corrupt database, but in actuality is an inherent conflict with packaged WAR files having Subversion metadata information on the WAS Portal platform.
When running any WAR or EAR file in WAS or any WAS based product, make sure to exclude all Subversion metadata files and folders from the build. It apparently brings WAS and Portal to its knees.
I was trying to understand deployment scenarios for Sling/JCR when I started wondering if I could simply use the Sling Launchpad and simply start the server using the jar. My project needs simplicity more than performance, but is there something seriously wrong with this approach? Alternatively, is there a good place where Sling/JCR deployment is discussed in detail?
I don't think we have a detailed description on how to deploy Sling applications, the best might be to ask on the users mailing list ( http://sling.apache.org/site/project-information.html#ProjectInformation-lists ) so that others can share their experiences.
As for starting with the launchpad I don't see a problem with that, that's pretty much how we are using Sling in Adobe CQ5. We have our own customized launcher that adds a few features, mostly related to upgrades management, but the basics are the same.
Although the few details of your project, I can say that Sling-Launchpad is a very useful tool to start an OSGi environment with selectable bundles. You just make a list of bundles to be included in the environment. It is very actively used in Apache Stanbol project. For the details you can investigate the various launchers of Stanbol e.g full, full-war, etc. Those launchers produce a single jar file including the necessary files to start the server.
Cryo-answer, maybe better late than never.
As long as you're not after a clustered config, the sling trunk build now has a debian contrib module that packages the launchpad jar in a debian package. It's a simplistic packaging mechanism that doesn't fully exploit all possible use cases, but it does setup logging and provide an etc/defaults for for config setup.
I have a server with many executables files (.exe, .dll) but this files used to link to another executables too... and so on.
To prevent deployment errors, I need a way to search for every dependency and it's dependencies and check for any platform incompatibility (32 or 64 bits).
I have no problem to detect the binaries's platform but I don't know how to get a list of dependencies.
Any suggestion?
Check out http://www.dependencywalker.com/ - this is the best tool for seeing the module dependency hierarchy.
This question seems to get asked regularly here. I don't recommend reverse engineering your dependencies as you propose. The problem is the on different platforms the dependencies may differ. If you can you should work it out from the source. This is not as hard as it may seem at first glance.
For managed code you can use Reflection to go through all the managed dependencies, and the Dependency Walker that tenfour pointed out should help with the native. Problems will arise when you start factoring in other types of dependencies that are not as easily checked: registry keys, COM, configuration files/settings.
Your best bet would be to develop a set of acceptance tests for deploying to your server or setting up some of staging before pushing to a live server. This will help catch deployment errors as well as a number of other functional defects that might have slipped through initial testing.