Is it possible to write Jenkins plugins using Python (via Jython), and if so, where would I get started? I don't know Java (and don't have a real interest in learning it at the moment) so being able to use Python would be nice for me.
There's no docs on that. Frankly your problem with be you must understand how the interfaces and extensions map from java to jython to write it.
Here are links on writing Jenkins plugins
Let's you embed either Jython or Python scripts and run them from a plugin If all you nee to do is run a simple script, that be what you need.
If your goal is to execute Jython code within Jenkins, you may want to have a look at the Jython Plugin.
Starting version 1.6, you can actually install Jython packages (say if you have your own library you'd like to use), and it'll automatically sync up the packages across all Jenkins slaves.
Since Jython can produce Java classes I see no reason why this should not work.
Note that you will need to learn at least some things about Java (mostly the platform, not necessarily the language) in order to be able to write plugins for Jenkins.
Related
I am trying to use Vowpal Wabbit through Java. I have downloaded and successfully compiled the code from GitHub. The command line tool works fine.
After having a quick look at the repository (especially here), I can only assume that using it through Java is supposed to be already possible, and I don't really want to reinvent the wheel.
A wrapper around Vowpal Wabbit that allows use through Java. This wrapper is designed to be self contained. Because
of the use of JNI, a number of platforms are supported in this JAR.
I have added the maven dependency (found here) to my project, but without any kind of document, I don't really know where to start.
I have seen in another question that it seems to be possible to use VW with Java, but the guy only uses Runtime.getRuntime.exec() to call his bash command, and I can't find any documentation about any other way of doing (and there are only 2 questions mixing VW and Java on SO, which doesn't help).
I am new to JNI, so most likely there is something easy that I don't see.
To be perfectly clear, my questions are :
Should I just make a valid vw command and use it through Runtime.getRuntime.exec()? This doesn't seem to be the spirit of JNI, for there is no need for any wrapper/library for this. Plus, this doesn't make it very portable.
Where (the hell) is the (Java API) documentation ?
Any kind of help or guidance would be welcome.
I was one of the two primary authors of the VW JNI wrapper. Since the posting of this question the interface has significantly changed. We now encourage users to compile the native side on their own and provide it on the java.library.path. We have updated the README significantly to show how to use the library from Java.
I totally agree with your criticism that we have not published the Java API. I will work on that the next time I modify this code. In the meantime please feel free to clone the library and run mvn install and you can generate the Java API docs yourself. They should be quite detailed as we spent a lot of effort writing detailed docs.
You may checkout vowpal wabbit JNI wrapper we've built in Indeed: https://github.com/indeedeng/vowpal-wabbit-java.
We wrote integration test that can work as usage examples and we wrote API documentation as well. Check "using the library" section of README.
Hope this will help.
I don't think this adds a lot, but none of the previous answers really provided a clear answer. Like #Macchiatow mentioned, to use the Java wrapper which comes with Vowpal Wabbit, you would:
(on the project root dir) make all java or make java
cd into java and verify the installation with mvn test
you'd then mvn install to have the Java API jarred up and placed in your local maven repository. Supposedly this builds the JNI parts on your machine, so as to fit the C/C++ libraries of your platform if you have the necessary native C/C++ libraries installed and available to the make command.
you'd supposedly be able to include the vowpal package/s from those jars in the build tool used in your own project (ant/maven/boot/leiningen/sbt/etc. as in here).
For more background maybe see the Vowpal Wabbit Java readme. I think what it tries to say there, is that if you want a ready made jar from maven central, you should make sure it's the same vowpal version you're using, but without knowing more I'd guess if you built it like above, you are by definition using the same version.
I've had the above process work off a fresh clone, with Ubuntu 16.04 and Java 8.
This link may be of some help with regards to setting up a JNI wrapper.
I wasn't able to find Java API documentation anywhere, but Java code seems well documented - did you maybe try generating Javadoc yourself from the code?
There is indeed Java JNI wrapper to have a basic access to VW. By basic I mean to teach your model and to predict probability later on. They also provide Python library that can do far more than wrapper for Java. Recently I was forced to expose few more VW methods to Java by extending code provided.
Back to the questions:
Rather use the vw-jni artifact available in central maven repo and clone their code and run make all java. I some cases compiling code yourself will be the only solution, as for example provided artifact won't run on OpenSuse (my case)
Code available pretty straight forward. VWLearners::create is a factory to get an instance of VW from Java.
I'm messing around with Sonar, there are a limited amount of tutorials and guides on how to get sonar up and running without a pom.xml.
When I use Maven it's über simple, 2 commands and you're up and running!
But let's play with the thought that you want to use Sonar on a project that doesn't use maven, or pom.xml-files for that reason.
Is this possible?
You're not obliged to use Maven if you want to run Sonar analyses. You can also use Ant (see doc) or simply the Java Runner (see doc).
The Java Runner is really the simplest way, and this is actually the preferred way when analysing applications built with other languages than Java (for instance C#, PHP, Groovy, Python, Cobol, C/C++, ...)
The main advantage of using Maven for Java projects is that it compiles the project and runs the unit tests for you.
Using Ant can certainly be a bit more complex, however we provide sample applications that you can use to get started.
Although I have not tried it personally, I think you certainly can. See this link http://docs.codehaus.org/display/SONAR/Analyse+with+Ant+Task+1.0
But be prepared to spend some time to get it working since it will not be as simple as mvn sonar:sonar
I'm primarily a Python developer working in an environment where just about every important batch is run by a Hudson or Jenkins server. I've written a python library which uses Hudson's python API which allows me trivially write Hudson clients in Python.
I'm looking for a Java class which will help me do the same kinds of things, but without any Python.
The neat thing about my home-made python library is that it allows me to work at a very high-level. Consumers of my library are entirely shielded from the complexities of what goes on within Hudson. Most of the things I need to do can be expressed in one-line functions:
For example I can search for and download artifacts. I can find jobs whose results match certain criteria. I can even remotely trigger jobs or query the status of jobs. The only problems with my library are that for boring legal reasons it must remain closed-source, and being Python I've no hope of being able to integrate it into Ant.
I'd like to make a lot of my Hudson magic work from Ant scripts - and for this I need to re-implement some of my Hudson stuff as an ant-task in Java. For that I'd need a java library which exposes a lot of what Hudson does at a high level. Does such a project exist? If so can you let me know where I can find it?
Updated: I already built a Python based solution Python Jenkins API - I'm after a Java equivalent of this.
jenkins cli
is that what you need?
What do you use to automatically deploy applications for various kinds of server applications (web, socket, daemon) that uses various technologies (different DBs, languages, etc)?
Here we use Python, Java and Ruby, and may use other languages as well in the future.
Update: I ended up using Puppet to manage all server setup, configs AND deploy. To trigger the deploy of newer versions I ended up using Python Fabric scripts.
I use Puppet for some of the deployements / initial configuration of server. Maven and Ant for Java based projects.
You could use Ant, Makefile, or a batch script. Or a combination of them.
Go for KWateeSDCM. It comes with a straightforward web GUI and does not require obscure scripting and integrates nicely with your build chain via a REST API.
We use Maven and pull out to the ant-plugin when required. In turn the ant-plugin very occasionally calls out to some native scripting language/application/packager/whatever but we're finding that over time we can generally find a Maven or ANT plugin/task to do the trick.
You might want to look up Continuous Deployment, it's a pretty hot topic in the build and CI space right now.
For Python you could use Fabric or Paver
For Ruby, there's capistrano and 'vlad the deployer'
For Java, it's the Ant.
For PHP/Python projects I also use Peritor Webistrano, a neat frontend for capistrano. It involves changing a few of the default recipes to remove the rails-specific stuff, but it's worth it once you get it setup correctly.
I think the best choice you could do is using maven. Even if maven is mostly used for Java projects, you can with the right plugins (or the one you write) deploy anything anywhere.
you can use maven, ant, ivy along with hudson for java projects.
We use Ant or Maven for different projects we have in house (depending on the need and how old the project is too...). We tend to use Jenkins (formerly known as Hudson) as our build and deployment tool.
And then we encourage developers to write code that does not hard code to DB's, URL's, etc. We try to abstract via the container (ie, Data Sources, pure JMS API's, etc) when running within an app server. And we tend to abstract environment specifics via properties files that we look up at runtime. The path to the properties file is to be defined as a variable on the server. This way we can be flexible enough to build code once and move it through to all our environments.
I've grown disillusioned with Groovy based alternatives to Ant. AntBuilder doesn't work from within Eclipse, the Groovy plugin for Eclipse is disappointing, and Gradle just isn't ready yet.
The Ant documentation has a section titled "Using Ant Tasks Outside of Ant" which gives a teaser for how to use the Ant libraries from Java code. There's another example here:
http://www.mail-archive.com/dev#ant.apache.org/msg16310.html
In theory it seems simple enough to replace build.xml with Build.java. The Ant documentation hints at some undocumented dependencies that I'll have to discover (undocumented from the point of view of using Ant from within Java).
Given the level of disappointment with Ant scripting, I wonder why this hasn't been done before. Perhaps it has and isn't a good build system.
Has anyone tried writing build files in Java using the Ant libraries?
Our build system is primarily based upon exactly what you describe, and it works very well indeed. We use the Ant tasks (especially the file-manipulation tasks) from custom java programs which assemble the application using auto-discovery of convention-based application module layout.
You may need some glue Ant XML, to do things like compile the build scripts themselves, and to actually invoke the java to perform the build, but it's minor.
Not only is java more readable than Ant, especially when it comes to conditional execution, but it's vastly quicker. Our Ant-based build used to take a minute or so to assemble an EAR, now the java based version takes about 5 seconds.
You had a fine idea. Cliff Click had a similar idea: http://blogs.azulsystems.com/cliff/2008/01/i-hate-makefile.html
If you go through with it I advise you to keep it as simple as possible so your build system doesn't need a [non-trivial] build system itself.
Given that Java is compiled, this is kind of a chicken and egg problem. You need to build your Build.java to build your project.
Ant currently supports inline scripting using BeanShell, Groovy and a bunch of others, that can really help reduce the need for that.
EDIT: In response to Dean's multiple comments, if your build consists strictly of a long proceedure, then indeed you don't need ant's build script. However, the power of the build script is that it ensures that dependencies are only executed once while allowing for mulitiple entry points, something that is far from trivial if you roll your own.
If you don't like the XML format, you are not alone, the author of ANT agrees with you. However, if your view of the build process is something that can be launched from your IDE as its only launch point, I would say that your build needs are quite simple.
EDIT2: I upvoted skaffman's answer because it speaks directly to the question. In the comments we seem to agree that the approach is fine for a procedural build, but would not work for a declarative one, and that you need at least a little ANT xml to get the ball rolling with your Build.java to avoid the chicken and egg problem. That seems to get to the crux of the matter.
An important point seems to have gotten lost here.
Ant is written in Java and what I'm looking for is a better way to use the Ant tasks (APIs in the Ant libraries) than through xml. For the life of me I can't see how using xml to invoke Java would ever be better or easier than using Java to invoke Java.
The one obstacle is that the xml approach is documented whereas the Java approach is not documented so I'll have to download and get familiar with the Ant code.
I held back from posting this question for a couple of weeks because I was sure that someone had done this before and that my google-foo just needed improving. It just seems so obvious to use Java to call the Ant APIs instead of xml that I'm still surprised that there wasn't a parallel Java-based approach developed for Ant as well as the xml approach.
Just because it is obvious doesn't mean that someone has done it before, though.
While I suppose its possible, you would probably be better off with shell scripts then writing a full on java program to simply automate builds.
You would be missing out on one of the key uses for ant, which are the easy-to-specify filesets and easy to read in properties.
I have stuck with ant as Groovy is too close to writing an entire application to just build your real application. Too complicated for the trouble.
While using Ant tasks inside Java programs is fairly easy, I probably would stick to Ant build files if I were you. If you're doing some groovy development, if Eclipse doesn't do what you need, maybe you need to look elsewhere(IntelliJ, NetBeans, etc.).