I'm developing simple Java application in Eclipse Oxygen. I would like to ask Eclipse to copy binary files to testing machine automatically when it builds. How to achieve that? How to run script on remote Linux machine that restarts application when binary is copied?
UPD
Since Eclipse builds project very often I would like to have Deploy functionality according to request. How to achieve this option?
Look at the 'Builders' page of the project 'Properties'.
You can add an 'Ant' script or a program to be run when the project is built along with the other builders.
Builders normally run quite a lot so you may want to turn 'Build automatically' off.
It is also possible to write an Eclipse plugin which contributes additional builder types - but that is more work.
Related
I have a Java application I've developed in Eclipse. To package it into a .jar, I simply run File->Export->Runnable JAR file with copy jar files into sub folder selected.
For deployment, I turn over the compiled jar file along with my source code and the deployment team packages it up and deploys it to our systems. One of the responsiblities of the deployment team is to verify that the source code that is turned over compiles into the binary that is turned over with it. This is the only Java program the deployment team works with so they don't have Eclipse available to import my source code and validate it against what I provided them. For the time being, they have just been taking my word for it, but that needs to change. They will need to compile the code on their own and make sure it matches what I've given them.
How would they go about doing this? I suppose one option is to get all of them up and running Eclipse, but that seems like an overkill. Is there something they can run outside of Eclipse without having Eclipse installed to generate a jar file that they could validate is the same as what I've provided?
Thank you for any assistance.
First, how can they tell that what you supplied "matches"? That doesn't really make sense.
What they really want to do is to build their own deployment artifacts from your source. They can either set up Eclipse and use that as their build tool, or you and they can agree to use a build tool such as Maven or Gradle. These tools integrate with Eclipse, but they are designed to run stand-alone or as part of a tool like Hudson or Bamboo, which will perform build on a schedule or when a VCS is updated.
A client used Maven and Bamboo, along with the rest of the Atlassian suite, to handle enormous builds based on contributions of more than 100 developers. That included running JUnit tests, test coverage, and code quality tools.
I have a vague memory that I've seen a build system for Java or some other JVM lang which you could run in continous mode (so to speak). This would make the build system run in the background, watching the source dir for changes. As soon as a source file changes, the build system kicks in and re-runs relevant parts of the build process to produce a fresh artifact.
Ring any bells?
Thanks
Is it the gradle daemon?
This keeps gradle running in the background because it has long start up times - and scans the file system to identify when files change.
There are lots of engines that support continual checkouts/building/testing (e.g. Jenkins nee Hudson, CruiseControl, TeamCity etc.).
If you're looking at JVM languages other than Java, then (for example) the Maven Scala plugin supports continuous building and testing upon file changes. e.g.
$ mvn scala:cctest
will run the compile/test cycle in a loop watching for source changes and acting upon them.
If your build tool or language doesn't support this natively, it's trivial to write a shell script to watch a directory structure and execute another script/tool upon change. See this SO question for solutions.
I figured out that it was in fact sbt that I meant. There is another question here on SO relating to how to build Java projects: Use SBT to Build Pure Java Project. Thanks everyone for your help.
I'm currently working on a project on Java Applet, Frames and now i have to deploy it. But the problem is this how can i hide the source code of the project? I've to deploy it to a local user on Windows OS. How can i make the .exe of the code?
There are many options you have.
If you just want to wrap the Java code in an executable file that works in Windows. You have:
Launch4j
JSmooth
Both are good.
If you want to wrap as a service so that you can perform myapp.bat {install|start|stop}, you have
Java Service Wrapper
If you just want to have a couple of bat/shell scripts auto generated at the build time that will launch your app on double clicking. You may look into Maven, there is a good Maven plugin called AppAssembler
Maven AppAssembler Plugin
The best tool for building .exe is InstallJammer
It also provides wizard type installation with all options.
I'm a C# guy trying to learn Java. I understand the syntax and the basic architecture of the Java platform, and have no problem doing smaller projects myself, but I'd really like to be able to download some open source projects to learn from the work of others. However, I'm running into a stumbling block that I can't seem to find any information on.
When I download an open source .NET project, I can open the .sln file with visual studio and everything just loads. Sure, there's occasionally a missing reference or something, but there's really very little configuration required to get things going. I'm not sensing the same ease of use with Java. I'm using eclipse at the moment, and it feels like for every project I have to create a brand new Eclipse project using "create from existing source", and almost nothing compiles properly without significant reconfiguration. In the case of web projects, it's even worse, because Eclipse doesn't appear to support creating a web project from existing source. I have to create a standard Java project from source, then then apparently modify the project file to include the bindings for the web toolkit stuff to work properly.
Assuming I want to be able to contribute to a project later on, I shouldn't have to be making such drastic changes to the file structure to get my IDE to a workable state. What am I missing?
The best way to go about this, is to first remove the IDE from the equation. In C# there is only one environment, so the presence of the default IDE is assumed. In Java a default IDE does not exist.
In the end Java is all about java source files and supporting jars. If you figure out what those are, your 99% of the way home. Then you can apply you favorite build system for the set. Some project require a runtime environment, like a webserver to handle the JSP files. If you understand what the basic setup is (as specified by the specification) you can quickly setup your IDE to handle that.
If I get a project with java files and supporting jars, I fire up Eclipse, create a new project, point it to the project's base directory and Eclipse will automatically detect what it finds and set up the project accordingly.
But projects often come with a build environment included. The trick is to figure out which one:
if a build.xml file is present, it is using ANT. This is a "make" like tool. You can execute "ant" in the directory where the build file is (if you have ANT installed) and it will try to compile. All IDE's like Eclipse and NetBeans recognize the build.xml file and allow for starting ant from inside the IDE. There is no guarantee the supporting jars will be present.
if a pom.xml file is present, it is using Maven. Maven is also a make like tool, but enforces a much stricter build cycle. Plus (and this probably is its biggest advantage) it automatically downloads supporting jars. If you have Maven installed you will be amazed at what it downloads... just sit tight, it'll work out in the end. IDE's usually require a plugin to support pom.xml, but then you automatically have the whole project setup at once.
if a .project file is present, it usually is a Eclipse project
if a nbproject directory is present, it is a NetBeans project
Getting to know a build environment / IDE is more work that trying to setup a project in the one you know. So I always try to get it running in Eclipse. Usually projects are quite simple to get running once you know your IDE.
Having multiple ways of doing things is not always pleasant, but it's the cost of having an open community. If there is only one IDE it makes things easier, but I like the fact that there are more people trying to figure out what the best way is to get things done.
In some cases you really may have to make drastic changes. A well-designed build system will require no configuration at all on most platforms and perhaps a few changes on exotic platforms. However, there is no single standard build system for Java; some people use Eclipse, some people use Apache Ant, and others use Apache Maven or Apache Maven2. If you were to create a project from scratch, then Maven or Ant is probably the ideal way to go. If you use the NetBeans IDE, projects that you create will automatically contain an Ant build file (so that it can be built on all systems using Ant), but will add additional metadata so that it is recognized by NetBeans IDE. If you create a Maven project, either using Maven directly or using an IDE such as Eclipse or NetBeans, then that same project can be loaded in either NetBeans or Eclipse without any additional configuration changes (although you may need to install a plugin for Eclipse for it to recognize Maven projects; NetBeans recognizes Maven projects out of the box). If you are starting a project from scratch, you may be interested in the Java Project Template. If you are contributing to an existing project, how you view/edit the project depends on the build system chosen; if the project already uses Maven or Ant, loading it with other IDEs should be fairly simple, while if the project uses a specific IDE's quirks or uses some more exotic build system, it may be harder.
I've finally managed to create a Netbeans project out of an old standalone (not Web-) Java application which consisted only out of single .java sources. Now I have basically two questions regarding Netbeans Subversion interaction and application deployment:
Do you check in all the Netbeans project files into the repository, normally?
If I build the project using Netbeans (or ant) I get a .jar file and some additional jar libraries. In order for the app to run properly on the server, some additional config files and directories (log/ for example) are needed. The application itself is a J2SE application (no frameworks) which runs from the command line on a Linux platform. How would you deploy and install such an application? It would also be nice if I could see what version of app is currently installed (maybe by appending the version number to the installed app path).
Thanks for any tips.
No, not usually. Anything specific to NetBeans (or Eclipse, IntteliJ, etc), I don't check in; try to make it build from the command line with your ant script and produce exactly what you want. The build.xml is something that can be used for other IDEs, or in use with Anthill or CruiseControl for automated builds/continuous integration, so that should be checked in. Check in what is needed to produce/create your artifacts.
You don't specify what type of server, or what exact type of application. Some apps are deployed via JNLP/WebStart to be downloaded by multiple users, and have different rules than something deployed standalone for one user on a server to run with no GUI as a monitoring application. I cannot help you more with that unless you can give some more details about your application, the server environment, etc.
Regarding the config files, how do you access those? Are they static and never going to change (something you can load using a ResourceBundle)? ? You can add them to the jar file to look them up in the ResourceBundle, but it all depends on what you are doing there. If they have to be outside the jar file for modification without recompiling, have them copied with an installer script.
As for directories, must they already exist? Or does the application check for their existence, and create them if necessary? If the app can create them if absent, you have no need to create them. If they need to be there, you could make it part of the install script to create those folders before the jar files are installed.
Version number could be as simple as adding an about box somewhere in the app, and looking up the version string in a config/properties file. It has to be maintained, but at least you would be able to access something that would let you know you have deployed build 9876.5.4.321 (or whatever version numbering scheme you use).
Ideally, you should not tie down your application sources and config to a particular IDE.
Questionwise,
I suggest you do not. Keep you repository structure independent of the IDE
You might have to change your application so that it's structure is very generic and can be edited in any IDE.
Is this a web app? A standalone Java app? If you clarify these, it would be easier to answer your query.
We don't check in the /build or the /dist directories.
We tend to use this structure for our Netbeans projects in SVN:
/project1/
/trunk
/tags/
/1.0
/1.1
/binaries/
/1.0
/1.1
When a change is need we check out the netbeans project from trunk/ and make changes to it and check it back in. Once a release of the project is needed we do an SVN copy of the netbeans project files to the next tag version. We also take a copy of the deployable (JAR or WAR) and place it in the version directory under binaries along with any dependencies and config files.
By doing this we have a clean, versioned deployable that is separate from the source. Are deployables are version in the name - project1-1.0.jar, project1-1.1jar and so on.
I disagree with talonx about keeping your source non-IDE specific - by not storing IDE files in SVN along with you source you are adding extra complication to the checkout, change, checkin, deploy cycle. If you store the IDE project files in SVN you can simply check out the project, fire up the IDE and hit build. You don't have to go through the steps of setting up a new project in the IDE, including the files you SVNed, setting up dependencies etc. It saves time and means all developers are working with the same setup, which reduces errors and discrepancies. The last thing you want is for a developer to check out a project to make a small bug fix and have to spend time having to find dependencies and set stuff up.
To answer question #2 -- who's your consumer for this app?
If it's an internal app and only you (or other developers) are going to be deploying it, then what you have is perfectly all right. Throw in a README file explaining the required directories.
If you're sending it out to a client to install, that's a different question, and you should use an installer. There are a few installers out there that wrap an ant script and your resources, which is a nice approach particularly if you don't need the GUI... just write a simple ant script to put everything in the right place.
Version number is up to you -- naming the JARs isn't a bad idea. I also have a habit of printing out the version number on startup, which can come in handy.