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.
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 am working on server-allinone in Eclipse. I would like to make
some custom bundles part of the basic bundles running on the Target.
Is there a way to do so from the configurations?
Conceptually, what is running on the target, consists of three logical parts:
The actual OSGi framework implementation (Apache Felix, Equinox, ...).
The "management agent" that Apache ACE provides.
All the bundles that make up your application.
Anything that is part of #3 can be easily installed, updated and uninstalled by ACE. ACE also has a mechanism that allows the management agent (#2) to update itself (which obviously is a bit of a special case). That is where ACE stops, it has not built-in mechanism to update #1, even though there has been some talk about providing a mechanism for that as well. You have to draw the line at some point though, as beyond that you could also ask yourself who is going to update the JVM, the OS and the bootloader.
Anyway, back to your question. If you want to make those custom bundles part of the basic bundles that are running on the target, conceptually they become part of the framework and you have no way in ACE to ever update them. If that is fine, just create a custom launcher that, besides installing the management agent, also installs these bundles. If that is not fine you need to add those bundles to the actual management agent bundle so they become part of that. That way you can update them as part of that bundle. However, I would like to challenge you and ask you why these bundles cannot be part of the application? Is there a special reason they must be pre-installed (updatable or not)?
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.
I'm working with an application that uses and manages a large amount of OSGi services and implementations for each service, with properties, dynamism and so. Using the command line of the Equinox console is useful, with commands like services or list -c . However, it is difficult to see specific implementations of services, and obtain a current snapshot of bounded or available services to consume. For example, you can see if the bundle references are satisfied, but you can't see which are the implementations of those satisfied references (although there are another mechanisms, of course).
So, the idea is to find a GUI with organized information (for example, using graphs) to increase the performance when you are developing in OSGi. Maybe there is one GUI in Eclipse plug-in perspective, but I can't find it.
If you don't know anything like this, I've in mind to create my own for my thesis :)
Eclipse has its Plug-in Registry view:
Window > Show View > Other... > Plug-in Development -> Plug-in Registry
This view comes with the Plug-in Development Environment (PDE), so you'll need to either use Eclipse Classic or Eclipse for Plug-in Developers or install it additionally through the standard Eclipse update mechanism.
The view can show the plugins, running in the current Eclipse instance and group them by plugin, extension points or services. I believe the last option is what you are searching for.
Although there was some work to make this view show remote content as well, it appears that this functionality hasn't made it to the normal Eclipse release.
Another tool, which can assist you in OSGi development is mToolkit. It is open source project, specifically aimed at helping developing in OSGi environments.
It provides similar view to the Plug-in Registry, but it only shows information about the OSGi bundles and services. It doesn't support nothing outside OSGi specification, so no plug-in registry inspection.
The Apache Felix console provides a web interface to manage OSGi services (and many other things) - I haven't tested it with Equinox but it has minimal dependencies so it should work in most OSGi environments. See http://felix.apache.org/site/apache-felix-web-console.html
I would checkout Peter Krien's Xray http://softwaresimplexity.blogspot.com/2012/07/xray-again.html
Have you looked at Knopflerfish and Apache Felix UIs? I think, they could be installed on top of Equinox as well.
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.