I am trying to set up a Jenkins Server to build my IntelliJ-project (using BitBucketfor VCS (git)).
I have been able to set up IntelliJ to build correctly locally, and I am pushing it to bitbucket. I have also managed to set up Jenkins to get the code from BitBucket.
The problems to actually doing the build process itself, my problem being that I can't seem to figure out how to set it up with Ant / Maven, which I have never used before.
Any good suggestions?
PS: I am still searching for tutorials or anything that gives some help towards achieving this, and will be updating if I find something that helps.
Jenkins can fetch the code from the repository to its workspace, but it cannot build it for you. You need to give him the tool to do that. Popular choices are Maven/Ant/Gradle to handle project building for you.
You need to refer to the proper documentation for either Maven or Ant. The process is too broad and project-specific for me to go into details here, but Jenkins provides nice integration for both. If you know neither of them, I think I'd suggest Maven, but it's up to personal preferences and project needs.
You should first try to build project locally. Once you acomplish that, doing that with Jenkins shouldn't be a problem.
Related
What's the right way of working with an Eclipse Java project with GIT?
I have the plugin EGIT installed and a simple java project. I did a commit/push of this java project by using the GIT bash console. I pushed only the source files.
Is that correct? Should I use Eclipse IDE somehow to make the init, commit and push? I couldn't find how to do this in Eclipse.
How should I retrieve the project from another machine? Should I use GIT console to retrieve the project or Eclipse?
I did the procedure in several ways, but they failed.
The generic answer is: whatever works for you, works.
We have a large git repository, and users with eclipse and intellij.
Some IDE users use specific plugins, such as Egit, others simply use the "default" support that most IDEs are shipped with. Such users simply go command line, or maybe, some other 3rd party tool.
Me, personally, I only rely on the IDE to show me the history of a file, or sometimes to quickly diff to revisions. Anything else I do on the command line.
From that point of view, as said: anything that works for you, works for you. You can use eclipse to manage the aspects of a git repository, but you don't have to.
Personally, I suggest to first get a good book on git, and to then extensively study the command line tooling. You also seem to be confused between the responsibilities of your IDE, and your source code management system.
I have an existing project in Eclipse (let's call it "NotPlayProj") which has a lot of java code still under development. I made a new eclipse project using play 2.1.0 (let's call it "PlayProj"). My goal is to use code from NotPlayProj in PlayProj and have both Eclipse and the Play compiler notice changes in either project.
If I go into the properties for PlayProj and add NotPlayProj via the Project tab, then method completion and inclusion works within eclipse, but the Play compile doesn't see the result. I've looked at Play modules and those don't seem to do what I want.
Is there any way to do this, ideally without modifying the NotPlayProj?
Edit ---
I've looked at http://www.playframework.com/documentation/2.0/SBTDependencies which shows how to export a jar from NotPlayProj into the PlayProj/lib directory, but this requires a manual export for each time NotPlayProject changes. I suspect that the Managed dependency section is supposed to cover this, but I've never used SBT before and am therefore probably missing something basic.
What you need is continuous integration.
Have a look at Jenkins: http://jenkins-ci.org/
You should setup a Continuous integration server and customize the builds you need.
Example:
You have your PlayProj running in some server, it needs to be able to use some of the latest classes from the other project called NoPlayProj.
Rebuild is a must, things such as downtime zero are difficult to achieve(At least I don't think this is what you are asking for either).
The steps you need to automate with Jenkins are:
1 - Build and deploy the latest version of NoPlayProj which is located in some repositorium
2 - Build and deploy the latest version of PlayProj which is located in some repositorium and also is contains your last commit where you updated the dependency that exist with NoPlayProj
A not very complex build and deployment instructions can be configured in Jenkins. This should speed you up a bit.
Also another suggestion would be to mavenize both projects if possible, this will help you manage the dependencies easier.
Just to clarify one thing, you said: My goal is to use code from NotPlayProj in PlayProj and have both Eclipse and the Play compiler notice changes in either project.
Well the order in which you execute the builds will be dependent in what you want to do as long as you update the dependency before you commit the code.
One last thing, if you don't want to deploy you don't have to do so you can create the Jenkins jobs, in such ways that you only build. With Jenkins you can do a lot of stuff, also you could execute some help scripts of your own that can provide you additional functionality.
I hope this was useful.
To let Eclipse see changes in NotPlayProj when working with PlayProj, it's enough to change configuration of PlayProj. Properties-> Java build path -> Projects -> Add NotPlayProj as dependency.
There is no straightforward way to let Play compiler handle dependencies, until you package it as jar. Consider configuration of simple ant task (External tools configuration -> Ant build ), which will copy your jar file. Task can be triggered by pressing the key or button.
With managed dependencies, every time you made change in NotPlayProj, you have to manually rebuild it. To let Ivy/Maven put dependency in your local repository. After that Play will take latest snapshot from your local repository.
Both approaches requires some efforts. Maybe you can take a look at Python scripts, which run Play, maybe it's enough to extend classpath with NotPlayProj when executing play start
Though I've never used the play framework, I would think that there is a format that both the play framework and eclipse understand and that is Maven. Look at http://www.playframework.com/modules/maven-head/home
I am very new to Jenkins. I have gone throught the tutorial of jenkins and I want to create a build job for simple java project. I know how to create a freestylebuild but I dont see any connection between the build and the project. Whats happening exactly. I have my project in eclipse and how can i create a build to the project. How do i know that it is the exact build for this project.
Can anyone please help me.
the best thing to do would be to move your build to some standard command line tool, like ant, maven, ivy, gradle etc and then you can reuse the same build from your IDE and on jenkins. note that this doesnt mean giving up using your IDE - many IDEs can import these types of projects directly and give you all the benefits youre used to in an IDE. it simply means that you get a build thats "portable" and not tied down to the specific IDE your using.
personally i think maven is best supported in this regard, but its mostly a matter of personal preference.
I have a project that's currently built with ant that pulls the latest trunk version of Solr in through git and then builds through ant. I'm pretty used to Maven and its system for dependencies at this point and find our old ant way of doing things pretty messy and hard to maintain. With that said, basically everywhere I seem to look online, people are building solr with Ant, and the few tutorials I found for doing things with Maven are all along the lines of this one, which doesn't seem to work.
So, to be clear, all I'm looking for here is a clean way to develop the project in Eclipse and to be able to deploy it. I'm sure someone must have done this before and must have a good answer. I'd be really interested in hearing it.
I just got it working by throwing all dependencies into Maven, making my own repo for a pegged version of Solr 4.0-SNAPSHOT, copying the web.xml from it into src/main/webapp/WEB-INF/, and running things through mvn jetty:run with salient variables passed in as arguments as:
mvn jetty:run -Dsolr.dataDir="./solr-data" -Dsolr.master-host="localhost" -Dsolr.solr.home="./solr-home"
This method is officially unsupported, but it means I no longer have to bother with ugly ant configs or holding all of Lucene and Solr in git repos attached to my project, so I could build from them. It also means changing/updating versions just requires a one line change in my pom.xml instead of digging through and switching a whole ton of extraneous configs. I'm pretty happy, and once I got a better feel for how Solr is supposed to work, reconfiguring the project really wasn't that bad.
This answer is probably more a comment, but a comment is too small to expose it all.
I know nothing about Solr, but from a neutral point of view, I would say you have two options:
Mavenize Solr (looks like what is suggested by your article). Maybe you could post another question on what problems you encounter using their solution.
Invoke the original ant tasks using the maven-antrun-plugin. This would also probably require to attach the built jars (or if it only contains classes/resources, jar them first). You could decide to install them locally using maven-install-plugin or attach them with maven-build-helper-plugin.
In eclipse, there are plenty of tricks to access the built files. You could simply add the project as a dependency.
This second option should work, but I don't find it very clean
You should be able to use Maven if you want, I know some of the Solr developers do. Have a look here: http://wiki.apache.org/solr/HowToContribute#Maven. This isn't the most supported way though, and I can't help you with this since I never tried it.
I actually work with Solr + Ant and there's basically a task for everything: ant test, ant dist and so on. I agree that's a bit old fashioned, but it works. Lately the build has been improved a lot introducing Ivy as dependency management tool, in order to remove all jars from the source tree.
Let me know if you have some specific problems with ant, maybe I can help you more.
I am trying to set up a headless build for a big eclipse feature, containing other features and plugins.
As some needed plugins are generated using GMF and EMF, the build workflow must be something like this:
SVN Check-out
Invoke Generation
Run Tests
Build all
Publish update-site
Over the last couple of weeks, i played around with PDE Headless Build and Buckminster. Anyhow i still got problems with both and can't decide on which i should spent my effort.
So what would you prefer? What experience you made? Anybody out there who needed to set up a similiar workflow before?
Thank you for all answers :)
Buckminster sits on top of PDE build, so there's no getting away from PDE build in the near future.
You could try another free plug-in that sits on top of PDE build: Plugin Builder as it does the generation of the ANT XML and the nasty map file that PDE build requires. It even has the extension for SVN-based map files as opposed to CSV. I successfully setup Plugin Builder running from Hudson for my team's build needs.
Another alternative is to look at Tycho (Tycho is the OSGi/Eclipse related bit of the next version of Maven). It is a work-in-progress and it does use PDE build under the covers. I tried and failed with some experiments with Tycho, but they do have a recent new alpha/beta build, so you may have more success (and there are other people who are successfully using it).
The only problem I've had with PDE build is the map file for checking out. I wrote my own ant task to do the checkout for me using SVN, based on conventions on where the plugins are located, instead of having to explicitly state in the map file all the file paths. Worked wonders and now I can just add plugins to my svn repository and refer to them in the feature.xml and it just works.
We're building using buckminster(check out, compiling, testing and byte obfuscation). I haven't tried a PDE-script, but if you have a complicated setup with a lot of dependencies on other libraries/projects I think buckminster will scale better.
I've recently started to move our entire Eclipse build-infrastructure from PDE build to Buckminster, and I have mostly good things to say about Buckminster. While builds based on the PDE build scripts/templates tend to be very brittle and requires a large amount of surrounding infrastructure to work, Buckminster feels quite robust and does not require any significant additional scripting around it. Buckminster does take a while to get into, but thanks to the excellent documentation and the very helpful newsgroup, I was able to get a full build to work in a few days.
Buckminster is what Eclipse should've had from the very beginning to handle headless builds.