We Keep Coding

Automatic build of GAE maven project from eclipse

I have a google app engine project with java using maven, and every time I want to see the changes I made even to a simple jsp or html, I have to run clean install then run the server. I want to know if it's possible to see the changes without having to go through this long process.
I have a GAE project structure that contains a war and ear folders.
I run the clean install on the war, then I go to the ear folder to run the "appengine:devapp".

Yes, it's possible to make the development process more agile and see the changes on JSP/HTML files w/o having to redeploy the whole application again. In a nutshell, all you need to do is to copy the files to the target directory. There are several ways to do that, ANT is one of the options.
I friend of mine wrote an article several months ago explaining this process in more details. Take a look: http://fabiouechi.blogspot.com.br/2013/07/smart-appengine-devserver-restarts-for.html
cheers!

Cannot debug project created with NB6.9.1 within NB7+ (has JAR dependency which uses JNI)

I just tried to migrate our working Java projects from Netbeans 6.9.1 to Netbeans 7.2 and I'm experiencing a problem due to one of our project dependencies being an external JAR which uses JNI.
I created a copy of our project directory and simply opened the copies of NB projects originally created with the older version of the IDE. Everything went smooth. I can build the projects and run compiled executable JAR-s outside of Netbeans without any problems.
However when I try to debug the project, the application fails to init properly due to said dependency JAR with JNI. It's like the JAR is failing to find a DLL associated with it (giving me java.lang.UnsatisfiedLinkError as a result). This does not happen with 6.9.1!
Why would this be happening? Do I need to explicitly set java.library.path in NB7+?
There were no changes made to the projects (not by us) and the same JDK is being used in both versions of the IDE. I suspect the newer version applies changes to the project setup silently and breaks something in the process. Anyone experienced something similar?
Edit 1:
Tried fiddling with project.properties, setting -Djava.library.path VM arg, different JDKs/JREs, ... all to no avail. This is driving me nuts. Obviously I'm doing something wrong.

I figured out what went wrong. This only became apparent after I got source of the external JAR (ext.jar from now on) in form of a Netbeans project so I could debug it.
ext.jar may load one of several DLLs depending on certain conditions. It constructs a file path to the appropriate DLL by using SomeClass.class.getProtectionDomain().getCodeSource().getLocation().getFile() and then calls System.load(path) with it's value. This path is different between the two versions of Netbeans. ext.jar is actually being used by another JAR (which is also a Netbeans project), which in turn is used by the main executable JAR of the application (also a project).
Main JAR (Netbeans project)
˪ Common JAR (Netbeans project)
˪ External JAR with JNI (ext.jar)
All external libraries in our project setup are placed within a directory at the same level where all the projects reside. This enables multiple projects to use a common set of libraries. Projects use relative paths to reference the libs.
CommonLibraries
MainJARProjdir
CommonJARProjdir
RandomProjdir1
…
RandomProjdirN
When Main is built, Common must be built before it (Common is a project dependecy of Main). In the process of building Common (by default) all dependency JARs get copied to ${common.proj.dir}/dist/lib. The copy process is of course unaware of the fact that it should copy DLLs along with ext.jar.
The root of the problem is however different handling of dependencies in 6.9.1 and 7+. If I specify ext.jar to be a dependency to both Main and Common (which is what was done, even though Main doesn't directly use any code from it) 6.9.1 will use the ../CommonLibraries/ext.jar when debugging, which always has all the required DLLs beside it, while 7+ will always use ${common.proj.dir}/dist/lib/ext.jar, which is missing the DLLs.
After recognizing what the problem is, the solution becomes trivial. I added a -post-clean target to build.xml of Common, which simply copies required DLLs from ../CommonLibraries/ to ${common.proj.dir}/dist/lib/ after each clean. It worked. This should be done either way – for completeness sake.
The reason for different handling of dependencies in the two versions of the IDE appears to be a new checkbox which is present in Project Properties/Build/Packaging called Copy Dependent Libraries. Ticking that off for Common also works. Note that this checkbox is enabled by default (even for library projects).

how to build project after code changes without mvn clean install?

I have a project in eclipse, a java app with appengine sdk and maven as my builder.
The .class files are not refreshed until i launch clean install, so every change i do in code i have to run:
mvn clean install
mvn eclipse:clean
mvn eclipse:eclipse
and then try to launch my app.
Help me please it's really annoying. Thanks

I know this is a very old post but I recently came across this issue while working with STS and Websphere application server. Hope this helps anyone to come across this ancient relic of a post.
Have a look at the "FileSync" plugin in the Eclipse marketplace. It allows to sync your workspace files with external directories (think your application server). After you install "FileSync" you can configure it to "copy/paste" your workspace files directly to your application server's exploded .war directory. It might take a little playing around with to get your files copied in a j2ee compliant format but it worked like a charm for me. Once its configured you basically just update files, save them, and your application is ready to go!

You are probably looking for a hot deployment feature. When working wit ha webapp, in most cases it is not enough just to compile a java class - usually you have to create a war package, and nearly always you have to redeploy the new code to the app server.
mvn package should be enough to create the war. You don't need to run mvn clean as long as you don't remove or rename any file. That would make things faster.
To achieve hot deployment (i.e. to get the new code instantaneously on the web-engine dev server) you need to do do some extra work, however. Make sure you use the Google Plugin for Eclipse - you can use it along with maven. The plugin at least should take care of static files hot deployment. Running the application in debug mode with Eclipse helps a bit as well as it is capable of replacing the methods' bodies on the fly.
Find further information answers to this question.

It's unclear from the question exactly what is happening and why. To figure this out, we would need to see the pom.xml and the "tree" command output showing the relevant folders and files. Then we could compare that to what the relevant maven plugin should be doing, and work from there.
As it stands, this is a quite old question in which it's unclear exactly what's happening, and OP has disappeared a long time ago. If this issue occurred today, the best thing to do would be to post to the App Engine Public Issue Tracker, although this could be inappropriate if the issue weren't in the App Engine SDK (or related maven plugins) but came from a third-party maven plugin not behaving properly (maven-compiler-plugin, for example). However, until a more in-depth analysis were performed, it would be difficult to know in advance.

Getting hot-reload of your App Engine application working is easy using only the Eclipse m2e plugin actually, and doesn't require the GPE plugin or any other special connectors:
1) Create your App Engine app as a Maven project in Eclipse as you would normally, using one of the provided Google archetypes or another custom archetype.
2) Configure your project, and do an initial build with mvn clean install in the root of the project to create the initial target/<artifact>-<version> WAR directory.
3) Start the development server with mvn appengine:devserver in the project root and ensure you can view your locally served app in a browser. Leave the development server running.
4) In Eclipse, make sure that Project -> Build automatically is checked.
Now, whenever you save a .java file Eclipse will automatically build the corresponding .class file under target/<artifact>-<version>/WEB-INF/classes. In a Maven project, this directory is set as the output directory for classes in your .classpath. The development server will detect the file change and do a hot-reload of your application so that the changes will appear immediately when you refresh your app in the browser.

JavaEE compiling files

I feel like a 4-year old who has a slice of bread with pb and a slice with jelly and is asking how to make a sandwich..
I've been given the responsibility of maintaining a javaEE website that was done by our parent company that no loner supports us. I'm relatively new to JavaEE and I'm trying to figure out how to recompile the files that need to be modified from within the root folder of the site.
I downloaded NetBeans to help me with this, but still can't figure it out. My problem is that the java files can't find any of the packages and resources they are dependent on. As far as I know, the resources are there.. although, I do see some packages starting with "com." and "javax.", and I don't see a 'com' or 'javax' folder anywhere.. I believe my problem has something to do with setting the class path in the project properties in NetBeans.. I tried that but either I'm not doing it right, or its not working. This whole Java compilation is so foreign to me, it'd be really great if someone could lead me in the right direction of getting this website compiled.
I posted a pick of the folder hierarchy of the website to help:
I'm trying to compile the RecordAdd.java file here specifically at the moment. Some of the packages it is trying to import come from its parent folder, asp, of the folder it is in, easp. The file is also trying to import com.icesoft.faces.component.*; where '*' consists of several different imports of the parent packages. I don't see a com folder like I mentioned, but I do see icefaces.jar files in the lib folder in WEB-INF folder. I've tried putting these folders in NetBeans Library-Compile category classpath, but that didn't do anything.
I'm not doing something right, that is probably a basic knowledge of compiling java projects, but I'm just not getting it. I really appreciate any help, just please don't be too harsh. Thanks!

Try to find out which IDE the original devs used. I see a nbproject folder which indicated Netbeans (unless that was created by you) so try opening the project in Netbeans as a Java EE project. I'd also try to open it in Eclipse, it has good importing capabilities and can sometimes figure out the classpath on it's own. Download the Java EE version of Eclipse and install the Web Tools Project. You can also try to see if there is a build file that will compile and generate a war file for you (something like build.xml).

It should be simple if the project was created in netbeans. Just go to File -> Open Project. Navigate to where the project is located. You will know if the folder is a project, because netbeans recognizes it and a different icon is displayed instead of a regular folder icon. Once you open your project, you can right click compile the project.
You don't use java compiler yourself to compile java files in a project. Compiling and building are done by tools like ant, maven... It's automated.

Importing existing projects into netbeans is a great way to loose a half a day.
I'm assuming that since there's a nbproject directory, this was built through netbeans, which should give you a leg up.
In the "Open Project" wizard, the top level of your application (not necessarily the sources) should have a friendly globe icon for a web application (.war) or a triangle for EE application (.ear). Open the triangle if there is one. Web applications can be packaged with EE applications through netbeans, so if the Web App you're trying to compile belongs to one, some of the build properties may be associated with it.
Looking at the file nbproject/build-impl.xml should give you hints about where your libraries folder was located. Make sure this path matches in your project properties under the Libraries header. These libraries can be shared among projects and therefore likely out of this projects directory structure and referenced or native to this project alone in which case jars are copied in to your lib folder.
There may be additional reference or server issues that netbeans detects (and gives a paltry error message for) which can be found in the project context menu under "Resolve Reference Issues" or "Resolve Missing Server". In netbeans projects are built against the servers they're run on right in the IDE. Check that you have the servers you want configured under Tools-> Servers, then ensure that server is linked in your project properties under Run.
This may not solve all your problems, but is a good start. Good Luck!

Deploy java (command line) app using Netbeans / ant

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.