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
Related
I am new to jenkins so i don't know in depth about it. But in recent days we wanted to change from svn repository to GIT in which we have a java project created in dynamic web project. Now we have to deploy this project in jenkins. But i read that in jenkins only projects created in maven are accepted but not any other. Our project is a huge project and its created using dynamic web project. So if we want to convert to maven project will there be any code changes like many??
What are the jar files or any configuration files needed for the change??
I don't know whether this question is quite suitable to ask or not but we have less time and i am completely new to jenkins.Any suggestions or answers will be valuable to me
You will need to think about how you will run your application in production. Will you run it as a packaged war file in tomcat, jetty or another JEE server or will you run it using an embedded server (embedded tomcat etc) where the server is packaged with your application as an executable jar file.
Once you work that out you should think about how you are going to build the application, Maven, Gradle and Ant + Ivy are your three main options. Jenkins supports all of these options, not just maven. Besides being able to help you build your application in a standardized way, these tools will be able to help you manage your dependencies.
There really is not much configuration required once you know how to use the tools and your dependencies can be removed from your /lib folder (or wherever you are currently storing them) as a result.
So take some time to read up about each one, make your choice and then apply it to your project. It is a worthwhile investment and something you will use over an over again.
Jenkins makes a LOT of things easier if you have a Maven project, but you can specify a free form project where you can specify your own build command. This is not coupled with the git/svn repository.
Experiment with Jenkins. It is rather nice, and can do a lot of things when you learn it better.
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 project with maven, this a multimodule project
Mainproject
project1 - jar
project2 - jar
project3 - web
Now that I finished the project I want to test it on the server but don't know how to upload them, on my computer I have added a plug for tomcat which deploys the war file to tomcat automatically, but the server doesn't have maven.
What is the way for moving to production with this kind of projects?
Should I just upload the target directories for each module?
Thanks
You're asking a few questions here. There is the "how do I test on a server" one, and there is "what is the way for moving to production" one. And they can be quite different.
I have assumed that the JAR files in the project are used by the WAR file and packaged within its WEB-INF/lib directory. If I'm wrong, that's cool. Just this sort of information is handy to know.
Maven is a build tool. It is not a deployment tool. What you have at the end of this, is a WAR file. If you run mvn install (or mvn deploy) you have a SNAPSHOT version of the WAR file. This would be suitable for quick, ad-hoc testing to other machines. But you would most likely use methods approriate for the hosting container for making them available. Note: a Maven DEPLOY is a different thing from a DEPLOY a war file to tomcat.
To my mind, if you're putting anything into production, or in front of a customer, or in front of a testing group, you should use Maven to make a Release of the product. That is, using the release plugin (via the release:prepare and release:plugin goals) to create a non-SNAPSHOT release of your artifact (in this case, a official version of the WAR file). Once you have that WAR file, you can migrate it to your production server in whatever way is easiest (copy, deploy into tomcat in the best way). You haven't mentioned if there are database requirements for this web application, and that would need to be considered before you change any production application.
But, once you have official versions, you have tags of source code, and you can accurately know what code is being run.
What I don't think you're going to get is being able to automatically copy the WAR file into a production server from your development environment. Here be dragons.
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.
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.