I am new for both tools , And not getting completely .
Why Gradle is targeted for deployment if I am deploying with Capistrano ?
See also Gradle Overview.
Gradle is built from the Groovy programming language, and is considered a build language, and less of a deployment tool. You can perform compilation of JVM languages, package it, and upload it to a repository easily, but it has little strength in deployment of web applications, unless you are directly deploying a WAR or EAR file.
Capistrano is built from the Ruby language, but is considered more powerful for deployment, and is less of a build language (Rake is the dominant Ruby build language). Capistrano's strength lies in being able to connect to a remote host, and execute commands on it, or copy out code to live on a webserver.
It is my opinion that Gradle would be a better language for all things JVM related, and Capistrano would be useful for PHP, Rails, or other types of web applications.
Use gradle-ssh-plugin with gradle as Capistrano replacement.
Here is an usage example.
Related
I've been learning about groovy and it works nicely with eclipse via the eclipse groovy plugin. I've been informed that I should use griffon if I want to write desktop applications.
Is it possible to add libraries/jars/etc to my groovy install so that I can create griffon applications? (I know that I could try this instead, but it doesn't really do what I want.)
Griffon is more than just a set of libraries, it's a full blown framework that provides a command line tool that takes care of many things, like processing resources, launching the application, packaging and deployment. It's also extensible via plugins. This being said, you cannot build a Griffon application with just its runtime libraries placed under ~/.groovy/lib
While working with Scala frameworks such as Play! and Lift I was really amazed how these frameworks manage to create a full development stack from the source code up to the web application container (Jetty).
Right now I'm trying to configure a project on my own with the following features:
Automatic deployment on Tomcat 7 (I'm not using Jetty as I require JEE6 support)
WAR file packaging
Is it possible to do it with a build tool such as SBT or Maven?
Note: My goal is to create my own project structure, not using an existing framework (even though I'm taking some ideas from them).
There is a web plugin for SBT:
https://github.com/JamesEarlDouglas/xsbt-web-plugin
It gives you war packaging, but not automatic deployment (other than on Jetty, which it integrates, but which you don't have to use).
That said, I'd like to see a fork of that plugin that removes the Jetty dependency and adds an automatic external deployment option. Shouldn't be too hard to do.
The base of our enterprise application is OSGI and we have several Java projects that are logically OSGI bundles. We use Maven to compile the application using the Maven Bundle plugin. But this process is time consuming and makes it impossible to debug the application. We also use the Runner and Pax(:provison) plugins to run the application. If we could rely on the Auto build function of Eclipse and also debug the application it would make our lives so much easier. Is there a way to configure Eclipse to be able to compile (and may be run) an OSGI-based application?
I'm not entirely sure if I understand you, but here goes.
Well, running/debugging OSGi applications in Eclipse is really easy, as long as your bundles reside in PDE aware projects or at least are on your target platform.
Do you have the source of all your bundles? Debugging without source isn't all that useful. If you do, can you just import all the source of your bundles into your Eclipse workspace?
Otherwise you can create a target platform, add all your bundles to that. (as a first attempt, I'd say dump all your bundles in a directory and point the target platform there)
Either way, then you should be able to Run (or debug)-> OSGi framework -> New -> Pick your bundles -> Start
You can both pick bundles from or target platform and from your workspace.
For building, you can use Eclipse Plugin Development Environment (PDE). Despite its name, it isn't specific to building Eclipse plugins and can be used for working on pure OSGi bundles. Eclipse plugins are OSGi bundles with some extras.
Cannot help you with the running or debugging part, although I do know that some enterprise-oriented OSGi platforms provide extensions to PDE.
If you're already using the maven bundle plugin, you may find that PDE's manifest-first approach isn't a good fit with your existing code-first build (I assume at the end you want both an IDE build for development and debugging, and a command-line build for continuous integration and automated testing).
You have two choices. As others have suggested, you can use Eclipse's integrated PDE, and use Tycho for your maven build. Tycho uses the same data used by PDE, so you don't have to write things down more than once. Alternatively, you can stick with the maven bundle plugin and use bndtools within Eclipse. Like the bundle plugin, bndtools is code-first, so you won't need to worry about maintaining manifests. However, you may find there isn't quite as big a set of features in bndtools as in PDE, and I'd suggest still checking your manifests by hand to make sure you understand what's being generated. Whether you prefer manifest-first or code-first is a bit of a heated philosophical debate.
Look at bndtools. bndtools is using the same bnd that is underlying the maven bundle plugin. You can even use bndtools together with m2e. bndtools is available from the Eclipse market place.
The eclipse plugin development environment is a pretty handy tool when creating from scratch a set of OSGi bundles that need to work together. Particularly this is true when trying to get all the package imports and exports and other manifest fluff right during development, or if there are third party jars that need to be embedded. But trying to retrofit a maven build process around this afterwards seems to be pretty tricky, mainly because most of the maven plugins for bundling/OSGi build the manifest themselves, whereas using the PDE, you are handcrafting the manifest.
What is the best way to retrofit a maven build process to a bunde/set of bundles, that dont respect the standard maven project layout, and already have handcrafted manifests?
Use Tycho. It lacks some documentation, but it does just that: builds the plugins using the PDE semantics (actually, it uses PDE compiler internally). So, all you need is to create almost empty pom.xml's for your modules.
I need to automate the building and deployment of (several) BPEL applications to a weblogic server.
I now do it using jDeveloper 11g, but I guess there should be some command line tools to do it. (I come from a Microsoft /.NET / Visual Studio background, and I can automate the deployment of my .NET applications using the command line and msbuild)
Does anyone know how to do that via the command line?
I don't have any experience with BPEL on Oracle WebLogic but according to this documentation a BPEL application is packaged as a standard EAR. I don't know exactly how your sources are structured under JDeveloper but you best option here to automate the packaging and the deployment of this EAR is IMO to use Ant (or Maven but if all this is totally new for you I would recommend using Ant).
Maybe this tutorial can help you to get started for the packaging part (basically, how to use the ear task). And for the deployment, I suggest to use the wldeploy Ant task (which wraps the weblogic.Deployer utility). I've mentioned them in this recent answer.
Also have a look at this question, it seems that JDeveloper might have some support to achieve this task (but I have zero knowledge of it so I can't provide any guidance, JDeveloper is not really widely used).
I assume you are using Oracle SOA Suite 11g? If so, have a look at Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite, particularly the section 38.7 Deploying SOA Composite Applications and the subsection 38.7.5 Managing SOA Composite Applications with Scripts.
You may also find useful advice in the Oracle BPEL forums.