What is the most proper way to accomplish all of the following:
Create a project in Eclipse
With an Apache Ant buildfile
That Hudson (or another more recommended CI system?) uses
And support for JUnit tests that are run by both Ant/Hudson and Eclipse
And check the proper folder structure into SVN so that future developers can replicate the build, and Hudson can automatically grab from SVN and run the Ant file to build/test/deploy the project
And the project has native libraries, if that makes any difference (I've already written an Ant task that can download and unzip the proper library files depending on the OS)
I already have my project with some source files and an Ant file, but I've been having trouble integrating it with Eclipse in an organized manner, so I would really love to start from a fresh Eclipse project, set it up correctly, and then copy my Ant file and my source files piece-by-piece into the project in the most Eclipse-compatible way.
I will be continuing to play around with everything in an attempt to get it working as I like it. But if you have experience with this sort of thing, perhaps at your workplace, please give as much information as you can.
My main goal here is to learn this once and use it in my future projects. For now, I am developing a client-server application consisting of a JOGL applet frontend (using JNLP files) and an unattended server app. Up until now I've been doing it all by hand: writing and building in Eclipse, dragging the applet jar into my FTP client, SSHing the server jar and restarting it by hand, and all with no testing process. I'm hoping that by the end, the build process will be something like this: test locally on my machine with a copy of the native libraries; commit code changes to SVN; Hudson svn updates, uses the Ant buildfile to compile and run all JUnit tests; if all the tests pass, it proceeds to copy the server jar to my dedicated server and restart the running server instance, and then copy the client jar to my web server.
When I start a new project, I generally take the following steps:
Create a new Java project in Eclipse, using the Java project wizard and opting to keep source and class files in separate directories ('src' and 'class')
Set up the project in Eclipse with the package structure you want
Create a new repository (or folder in your repository) for the project, with the normal /trunk/ /branches/ /tags/ set up
Using your SVN client, import the contents of the project folder Eclipse made for the project (at the level where the 'src' and 'class' directories are) into the trunk of the repository
Confirm everything is in Subversion correctly (check the trunk out to a new location)
Using Eclipse, delete the project (and the files on disk)
Create a new project using the 'Checkout projects from SVN' wizard, using the trunk of the repository
Create your Ant script, ensure the project builds correctly, and add the Ant script to the repository
Now, from Hudson:
Create a new job and set the Subversion URL to the root of the repository
Add a build set that will use Ant (I've always had to install my own version of Ant and ensure it's configured correctly to have this work) and will call the Ant script you
Use 'Build Now' to see if the job will build correctly
You can invoke your JUnit tests from Ant in the build script (first compile them with the javac task, then run them with the junit task). Hudson will track the test results if you ask it to.
You can use a shell script build step to copy your server jar to where it's needed, and restart the server instance. Like Mnementh said, it sounds like you've got the native libraries sorted...
If you are not tied to using ant, and are prepared to use Maven, then it is simply a matter of setting up Maven with the Eclipse plugin which generates the Eclipse projects for you.
Hudson already knows how to build Maven projects, so that is taken care of.
So long as you can pull your projects into eclipse, then it will be able to run the unit tests, and hudson can use the previously mentioned maven support to run the unit tests as well.
If you use Maven, then you will want to follow it's guidelines on how to create a project, here is a good starting point.
Hope this helps.
At our company we actually use Eclipse, Java, Ant, SVN, Junit and Hudson. That is all you mentioned except the native libraries. If you said your ant-buildscript already works with the native libraries that problem seems solved too. To integrate it well into eclipse you could do it in two ways: Use Ant also from Eclipse (has downsides) or the developer has to install the native library for his machine properly, so that Eclipse can compile without a problem and for continuous integration it will be downloaded by Ant.
Related
let's assume I have an android project in IntelliJ.
Now, I am changing some details on the strings.xml resource file, and after every change I build a new apk.
I want to create a second program that will automatically build an apk file. I could change the parameters for the strings.xml file, and then build automatically without accessing IntelliJ, is it possible? will it only be related to Java language? or could I build it in C# or any other language as well?
I did read about Maven and Ant, but I have no idea how to use them correctly, I would like an answer that will lead me to some examples or tutorials as well, thanks!
The common approach is to use three things:
Build system (Ant, Maven or Gradle) - for Android apps Gradle is
becoming standard
Version Control System (e.g. Git)
Continuous Integration Server (Jenkins, Travis or
other)
Gradle Build System
When you create default project in Android Studio, you already have it created with Gradle. Android Studio also allows you to convert project from Ant to Gradle. I cannot explain you, how to use Gradle in a single post, as it can be subject for whole article or even book. Basically, you have build.gradle file in which you can define dependencies in your project and build configuration. You can have installed Gradle in your system, but good practice is to use Gradle Wrapper, which is a single *.jar file and it can be used to build your application. Once you have your project configured with Gradle, you can build it from command line as follows:
./gradlew build
On MS Windows:
gradlew.bat build
Continuous Integration Server
When you have your project configured with Gradle, you can push its source code to your Git repository and create a job on your Continuous Integration server, which will be responsible for building your project. Within the build, you can create an artifact with compiled *.apk file, execute tests and run static code analysis. You can trigger your job via Git commit hooks or via polling on Continuous Integration server. It depends on chosen technology stack, but it can be automated.
If you want a lot of customization and free solution, Jenkins CI would be a good choice, but you'll have to configure a lot of stuff by yourself and host server by yourself. In my opinion, such choice can make sense in a team projects, when you have appropriate infrastructure and time to set it up. If you want an easy configuration and you're willing to spend some money or create an open-source project, I recommend using GitHub and Travis CI. It's also a good choice for individual developers. I'm not sure how to generate artifact with *.apk file on Travis CI, but I suppose it can be done and you can always ask support to help you. For sure, artifact be archived in Jenkins CI job.
I have a Java web project that uses Maven standard directory layout: java files gets into java (actually: /src/main/java), resources into resources, web content into webapp.
Then we wanted to improve our web layer, by adding bower, sass, gulp etc. Our gulp build compiles scss, minimize javascripts, optimize images etc, everything what you would expect. But this introduced 1) another build tool, gulp and 2) generated files by gulp.
Question is how to organize such project? One way could be:
(A) gulp builds into webapp folder
In this solution, all javascript,images,scss files are stored in /src/main/assets and gets build into the /src/main/webapp. Both sources and gulp-generated files gets committed to the git. The gradle build is independent from gulp, and it is ok for the users that does not have gulp installed - like those who needs to work only on backend. Also, CI servers does not depend on gulp stuff.
(B) use gulp from gradle during build
In this solution, gulp is called from gradle. Gradle therefore builds everything. And you must use gradle every time when you want to try something. Also, every developer needs to have gulp installed, what may be a problem for developers using windows (as i've been told). Also CI server should know how to run gulp.
My team is torn between these two options. Does anyone have any working experience with either of these solutions?
I'm currently using Java + Grunt + Maven. I've found there are two ways of packaging your frontend with your backend and the same will certainly apply to Gulp.
In the end it's up to what's best for your project/team. From my experience I usually use option B when working with others since the decoupling is easily worth the other issues. When I'm doing my own side projects I always go for option A because it's just easier to launch one webserver and to run a local environment closer to what DEV/PROD is like.
A) Put your frontend into the webapp folder (ex. https://github.com/kdubb1337/maven-grunt-webapp)
Benefits - You can launch your backend and do development all in one place and working with Spring security is a snap, even without OAUTH. Fewer issues working with two webservers up on your local environment when they would normally be bundled into one port on other environments.
B) Keep your frontend in a different folder, or even in a different repo that you clone into the root folder of your backend repo. (ex. https://github.com/kdubb1337/maven-grunt) see the 'yo' folder
Benefits - Fantastic decoupling so front end developers can live in joy without having to even install java locally or worry about recompiling your backend. Works great if you want Travis (or your favourite CI app) to do unit tests on the backend and the frontend.
EDIT I've found this awesome plugin you can use with maven/gradle to build the frontend https://github.com/eirslett/frontend-maven-plugin. Seems like the way to go, will be refactoring my starter projects with this guy for grunt and gulp
The current best practice here is to treat your frontend build as a separate project and put it in its own Maven or Gradle module. Have your Java build system invoke the JavaScript tooling (e.g., with the maven-exec-plugin) and save the output into the appropriate directory in target or build. Bundle up the results in a jar and serve off the classpath.
If you're using Bower, you only need the base Node install on your CI server, and your Java build can invoke the necessary build process from there, fetching JS packages as needed. Don't forget to (1) use --save and (2) exclude the JS modules directory from source control.
In addition, I suggest looking at RaveJS, which manages your JavaScript build and keeps you from having to configure watchers and such during development.
My recommended best practice is using the com.github.eirslett.frontend-maven-plugin (or the maven grunt plugin) to call the grunt/gulp build from mvn (in process resources goal). When CI builds, it's all integrated, even npm etc can be installed in mvn's target so you don't have bother to configure your CI server for npm.
When developers build, then mostly still just use one maven command. For JS/CSS/HTML developers, after mvn clean install, they can run grunt/gulp "watch" in the background to get their JS changes reflected immediately in the browser without incurring any maven overhead (just the wicked fast gulp/grunt tasks).
Deploy the UI components on default Tomcat webapp directory.
Deploy the class files on "wtpwebapps" (default directory for uploading war through eclipse) directory.
Setting Eclipse
Go to server tab, open properties for tomcat
(source: scotch.io)
Make sure, the location should be [workspace metadata]
Then double click on tomcat to open Tomcat overview.
(source: scotch.io)
Set server location to "Use tomcat location".
Grunt/Gulp Setting
Use the copy task to copy the build UI file to<tomcat installation directory>/webapps/<contextRoot>/
https://pub.scotch.io/#ankur841/eclipse-tomcat-deployment-with-gruntgulp-build
it might be a stupid question but how do I set up an environment to develop a test application using libvirt?
do I have to set up ant or maven project or can I just copy java files to my src folder in eclipse ?
Thanks
If you use Eclipse, you can build your classes and run your program in Eclipse without using Ant or Maven. In fact, Eclipse is usually completely ignorant of your Ant build.xml or your Maven pom.xml file. Eclipse uses its own build technology (although you can ask it to run your pom.xml or build.xml). However, a pure Eclipse way of building a project means there is no way to build and run your project except with Eclipse. If you have a continuous integration system, or someone downloads your project and simply wants to build your jar or war file, there's no way they can do it.
Actually, not entirely true. You could write a shell script to compile your code via the javac commands and jar it up via the jar command. What Maven and Ant do is give you a framework to help build your application and remove system dependencies.
Ant has an advantage of flexibility. You can do things easily in Ant that are harder to do in Maven. The disadvantage is that Ant has the flexibility to do things in a really, really bad way. I almost always recommend for developers to use Maven for new projects. It forces them to write their project in a standard way, and eliminates the need to write Ant build scripts which most developers really can't do.
What if you don't know Maven, but know Ant? I still recommend that you use Maven and take this as an opportunity to learn Maven.
I would like to generate Eclipse Java Project with my Java program. When I click a button: it will generate an eclipse project with the parameters I specified (source path, library, ...)
My questions are:
is there a way to do that ? and how ? (api).
it is possible to generate Net-beans project too ?
Best regards,
Florent
Maven enables this and many more things around creating, bulding, testing and developing Java projects.
Create a Java project from command line. Then, using Maven create NetBeans, Eclipse or IntelliJ IDEA specific project files. Or even easier, just import already created Maven project directly from these IDEs.
Create Java Project in Eclipse first. Then look into directory created. You should find there two files: .project and .classpath. These are the files you should create in your app to get what you want.
Also for eclipse available M2Eclipse plugin to provide some Maven feature from Eclipse IDE.
http://m2eclipse.sonatype.org/
While Maven is the way to go in the long term, the best way to start a project in Eclipse is:
Hit Ctrl+N and choose Java project
Fill in the project name fields
Copy your files from wherever they are to the newly created project (ensuring to preserve package hierarchy)
Refresh project from File menu
Create a Run / Debug profile to run your app.
It should be fairly simple to get up and running this way.
The reason people recommend Maven is because Eclipse is an IDE. It's great for development but its no good for resolving external dependencies or for command line / automated builds. Maven is an IDE neutral way of building and becomes essential the more dependencies a project pulls in.
Unfortunately Eclipse integration with Maven is pretty clumsy and can be summarized with these very broad steps:
Install Eclipse Helios
Install m2eclipse from the Help | Eclipse Marketplace
Mess around with eclipse.ini to make Eclipse start from a JDK.
Configure m2eclipse to use any existing Maven local repository
Hit Ctrl+N and create a new Maven project and skip archetype selection
Copy all the source files from the old project into the new ensuring to use Maven's conventions for file locations. (e.g. source goes in src/main/java)
Create a Run / Debug maven target to clean / install the app
I say broad steps because there are a lot of gotchas. For example if the source is Java 5+ you might have to tweak the pom to set the compiler level. Best to get Eclipse working and then worry about Maven.
Netbeans has vastly better out of the box support for Maven although IMO Eclipse is still the better IDE for other reasons.
I have been working solo on a project for some time, and now, new developers are likely to join the project for various reasons.
I, of course, use a version control software but I am afraid importing my project into Eclipse and making it run might prove a little difficult for new comers, and I want to make it as clean as possible.
When I first took over the project, it took me almost two days to have the project built and run it, I documented every step and fixed the most obvious errors, but not all, and I want the project to run as it is when imported.
The project is a mix of java projects for the backend, a j2ee project for the server and a flex project for the client.
The IDE is going to be Eclipse
The version control software is Perforce
Here are some of the specific problems I have right now, should I fix them, and how ?
Eclipse environment variables are used for libs, all the libs are in a folder in the j2ee project but are used by all the java projects (they have to be set in each IDE the project is imported into)
Runtime JRE is specified in .classpath for each project, so each projects property must be edited when trying to build the project in another environment
Apache server is specified in j2ee project property
To avoid exporting the jars of all the java projects into the j2ee project each time I modify the code, there are linked folders in the j2ee projects, linked to each java project bin folders
For (4) I will probably have to use maven, but is it possible to fix problem (1) (2) and (3) without using maven ?
The alternative is to have a one page set up instruction document
Also do you have any other general or specific advices as to how organize this whole mess.
Thank you
Dependency management is a must - use Maven. If you can't use maven, because you are already using ant, go with Ivy.
Make the project buildable with one click - be int ant build all or mvn package. Maven provides integration with the IDE (via the plugin).
Don't reply on IDE metadata. like .project and .classpath. You can still commit them to ease Eclipse users though, but don't restrict the IDE.
Provide build-on-save. Either using Eclipse WTP, or using the FilSync plugin (it sounds like a hack, but is pretty cool)
Use build profiles (maven provides them automatically) - to create different builds for different environments
It's not always possible to configure everything in your maven (or ant/ivy) scripts. For any additional actions, like installing app server - document then in a single file in the root of your project, describing step by step what should be installed, with what config options, etc. Thus the developers have only one place to look at and follow. The document can (and better) be plain .txt
A sidenote: use Continous Integration - download Hudson or TeamCity and configure it to build a project
From my very recent experience - we had a project we've been working on for 6 months. A colleague of mine had to re-import the project on a new machine. It took him 20 minutes. The project is configured with Maven.