I created an app using create-app with Grails 2.3.7, I noticed there is a wrapper directory with jars inside.
Isn't the dependecies are handled by maven(.m2) or ivy?
What is it for? Why is it located inside the grails application and should I include it under version control?
Grails Wrapper
The Grails Wrapper allows a Grails application to build without having to install Grails and configure a GRAILS_HOME environment variable. The wrapper includes a small shell script and a couple of small bootstrap jar files that typically would be checked in to source code control along with the rest of the project.
The first time the wrapper is executed it will download and configure a Grails installation. This wrapper makes it more simple to setup a development environment, configure CI and manage upgrades to future versions of Grails. When the application is upgraded to the next version of Grails, the wrapper is updated and checked in to the source code control system and the next time developers update their workspace and run the wrapper, they will automatically be using the correct version of Grails.Taken from
See the Wrapper Documentation for more details.
And see this link
But on Grails 2.3.7 there is no shell script for wrapper is described above , but the jar that need to run GRAILS without installing are insalled by default
asm-3.2.jar
asm-tree-3.2.jar
grails-wrapper-runtime-2.3.7.jar
grails-wrapper.properties
springloaded-1.1.5.RELEASE.jar
Related
I'm converting some backends to modules and am perplexed on setting up the development environment configuration. I'm using Java in Eclipse but not Maven. The architecture is very simple:
Front end module is default. Basic GAE/GWT app. Puts items on task queue.
Back end module processes task queue.
With the old backend architecture one debug configuration would start up the development server that would service the GWT DevMode UI and the backend task processing.
The crux of the issue is that the arguments to DevMode provide for a -war command line argument. Now that we no longer have a single war file (there is an ear containing two war files), we have to start them independently. This is fine, we can create a Launch Group that starts up the frontend and backend.
The problem is that each war file gets it's own
WEB-INF/appengine-generated/local_db.bin, which essentially creates two standalone applications. Am I missing something here? I need to be able to put a breakpoint on my front-end RPC service and in the servlet that handles task queue items in the new backend and have both of them hit in one debugging session.
Thanks for any thoughts.
If you follow the instructions here, this will create a modularized application structure in Eclipse, and not using Maven at all. You will need Eclipse WTP in order to have the required project types available (Enterprise Application Project and Dynamic Web Project).
The Eclipse project structure should look as follows:
<<Enterprise Application Project>> ear-app
|
| (refers to)
|
<<Dynamic Web Project>> app-module-1 "default"
<<Dynamic Web Project>> app-module-2 "any_name_2"
<<Dynamic Web Project>> app-module-3 "any_name_3"
<<Dynamic Web Project>> app-module-4 "any_name_4"
The value of "name" refers to the "module" element in appengine-web.xml, while the physical web project can have any name.
Please note that you need to switch into J2EE perspective in order to have the GPE WTP menu options available, they do not show up in the standard Java perspective.
Next, you need to link the EAR project to a new local server instance (of type "Google App Engine").
Only one of the web modules must be flagged as "default" in appengine-web.xml.
Upon deployment of the EAR to the local server, the datastore location is in WEB-INF/appengine-generated/local_db.bin of the default web module, and it is shared between the web modules.
I'm having similar problems figuring out how to implement multiple modules in the MyEclipse plugin for Google App Engine. The best information I've found just says to use Maven.
"Although Java EE supports WAR files, module configuration uses unpacked WAR directories only. App Engine's Java SDK includes an Apache Maven tool that can build a skeletal EAR structure for you." (source: https://developers.google.com/appengine/docs/java/modules/)
I also found this:
"A Maven project has a different layout than an Eclipse project. So, if you wish to use a Maven project with Eclipse, you need to do a bit more work. You have the following options:
1] Import a Maven project for App Engine into Eclipse as a Web Tools Platform (WTP) project, as described in Importing an Existing Maven Project.
2] Import the Maven project into Eclipse using an appropriate Maven integration plugin such as m2eclipse.
3] Set up two debug configurations, one for the Maven project in devserver (mvn appengine:devserver), and one for a Remote Java Application that you use to connect the Eclipse debug client to the devserver jvm. For details on how to do this, see ..." (source: https://developers.google.com/appengine/docs/java/tools/maven#creating_a_new_maven_app_engine_project_using_skeleton-archetype)
I know you said you're not using Maven, but might you consider trying it?
I do have own developed Java library (MyLib), which I later publish on private Maven repository and have it as Maven dependency in another webapp project (MyWebapp). If I have both projects - MyLib and MyWebapp at the same time opened in Eclipse - is there a way somehow to configure MyWebapp so, that local changes made to MyLib would be directly added to MyWebapp while building/deploying it? The issue is that during development it is not really comfortable always to make some changes in MyLib, make a build, deploy to Maven repository and then make a MyWebapp build, deploy it and only then I can see how the changes are affecting the webapp project...
I would like to reduce the overhead while developing and willing to see how changes are working out. Of course when it comes to real releases the above described flow does really make sense and works great.
Thanks!
There is no simple "just tick this option" solution, unfortunately. You can chose between these options:
Convert MyLib into a Maven module and add it to the sources of MyWebapp. This, of course, will make it harder later to reuse the library alone.
Stop deploying the application. If you look at the classpath in Eclipse, m2e should have added the dependency as a project from the workspace (instead of depending on the JAR in the repository). If not: There is an option for this.
The next step is to create another project which depends on Jetty and MyWebapp. Create a Java application in there (i.e. a file with main()) which creates a Jetty server and configure it to use the current classpath. That way, you can start the webapp just like any other Java application without deploying - Jetty will simply load classes from the classpath that m2e assembled.
we recently migrated to Maven Build manager & git hub repository for our Java web-app. Also i switched to eclipse as eclipse has good set of plugins.
As a new bie, i am simply running mvn clean package from terminal at the code root directory. And then moving the compiled code i.e., /target/SNAPSHOT/* to tomcat/webapps/ROOT location.
And then starting Tomcat7 server. The process is time taking especially when i do code changes in Java & configuration .xml files.
I want to do it completely in IDE environment as i did earlier in Netbeans, update code -> build and run in debug mode, -> do code changes and then commit.
Heard of egit & m2e in eclipse for maven & github integration, but not sure how to use it.
Please walk me through the steps required in doing so. I am completely new to eclipse.
--
Thanks
You might want to consider using maven-jetty-plugin http://docs.codehaus.org/display/JETTY/Maven+Jetty+Plugin for running the webapp. You will not need to copy over stuff to tomcat. After configuring this plugin, you can simply run your application by doing mvn jetty:run
I generally do not like running webapps inside Eclipse. It's a personal prefrence, but it is always nice to have an IDE neutral way of building and running your applications. If you have m2e things should work simply fine. I have seen maven-jetty-plugin having hot pluggability where if you changed your web.xml, jetty would reload your application.
We use Git for version control and Maven for dependency management and build automation. Once your project has successfully imported into Eclipse and recognized as a valid java web project, you don't need either Git or Maven in order to build/run it inside IDE. Just creat a server using you existing tomcat installation, add the project to server, then select Run as > Run on Server.
The Complete Guide:
Creating a server
Adding projects to a server
Starting a server
For more details, check out Testing and publishing on your server.
Eclipse Vaadin plugin has cool autobuild feature. Just clicking "restart application" in debug console will bring up to date application version to live.
Unfortunately importing maven generated vaadin project(using m2e) and copy-pasting .project buildCommands and natures from vaadin eclipse plugin generated project does not works.
I'm unnable to "Run on server...", tomcat does not deploy app for unknown reason. I can see app in wtpapps folder but it still does not deploys.
You can build your Vaadin app as a regular Java library, by itself (not as a WAR, or anything complicated). Then do two things: Create another project that builds the actual WAR file, and create another project that sets up Jetty for direct execution (google for details on how to get Vaadin operating under Jetty standalone, using Jetty as a library). With that in place you can treat your Vaadin UI like a regular java program (fast, direct restart through the standard debug window), and still have it be a WAR file for deployment.
See this thread for details on how to set up Jetty (look for Launcher).
I have also stumbled upon this problem some time ago and eventually found this:
http://www.streamhead.com/maven-spring-vaadin-appengine/
It eventually helped me to get up and running after a scenario that has been very similar to what you have described.
I'm looking for a tool to run java server processes as daemon services in Linux (and potentially on Windows and other OS's). I'm looking for the best practices when it comes to how to build production capable scripts and launch configuration.
I'm familiar with best practices when it comes to a project's build, using Apache Maven, or something like Apache ANT + Ivy to manage your build process and manage external dependencies and build artifacts and assemblies.
When it comes to creating a project's assembly containing configuration and launch scripts along with all the compiled code and dependencies I'm unclear what the best choice is. Is there a good open source project that I could look at as an example, that bundles a service wrapper and configuration scripts with their build process?
I've been able to use Maven with the Jetty Launch plugin to run my Web applications, Terracotta Maven plugin to test multiple JVM clustered server nodes and I've used Maven's exec:java to run my custom Java servers, but I'm not sure using Maven in that capacity is really "production" quality, also it means my production servers depend on building the servers from source and downloading dependencies from potentially unavailable servers.
Here are some potential things I'm looking for in a Java service launcher solution:
Should run as a Linux service or Windows service process
Can be built using a Maven plugin or Ant script and allow me to process configuration files and scripts
Should be able to include all my project's dependencies from Apache Ant
Should be able to pull in a full Java Web Application server (e.g. Jetty 7) and be configured with my custom Web application's war
Should be able to handle a standard Java daemon service (custom java server)
Some of the options I've been looking at are Java Service Wrapper, which is used in the Maven appassembler plugin.
Also using Maven's assembly plugin and custom assembly descriptors allows me to tailor the build output.
The Java Service Wrapper seems to be quite common. I've seen it used by a few people, most notably in nexus.
The preferred (aka "best practice") way to implement Linux services of all kinds is to create a shell script that can start, stop and restart the service and put it into /etc/init.d. Then add appropriately symlinks to it from the relevant "rc.*" directories. Refer to the Linux "man" entries for "init(8)", "chkconfig(8)" and so on.