I have quite non-standard web app configuration: my web.xml file is located not in the WEB-INF folder, but is copied by maven from some another place (please don't ask why).
For that I'm using maven-war-plugin approach in my pom.xml: <webXml>${project.some.webapp.path}/web.xml</webXml>
It works fine when I call mvn install.
But, when I make 'Build project' (incremental build) in eclipse - it doesn't copy web.xml into the WEB-INF folder, as well as other maven-war-plugin features, like webResources. (it seems its just doesn't use its configuration at all during the incr build)
What can you advice in my case?
There's currently no option for this (I'm looking for one right now). In fact, it would work if there was an option in Eclipse to always run a full build (that's what you do when invoking «Build project») instead of an auto-build that runs an incremental-build, which only look at resources directory (by doing a delta). So many actions are not performed, such as copy-resources and so on, even if you've set up other directories, maven doesn't look into these because of the ignoreDelta incremental option.
I'm looking for a way to force the full build in every case, but it may need to change the core code of Eclipse.
Related
We build with IDEA a Maven-managed web application for which we generate bundles with Webpack fairly often in main/webapp/resources. Ideally these files shouldn’t be indexed, but if I exclude them in Project Structure or in the Project tree, they aren’t included in the .war file when we run Tomcat (within IDEA). Is there a way to exclude files from indexing and still include them in the web app?
Thanks.
The crux of the matter is that the (exploded) .war file that IDEA generates when running Tomcat within the IDE follows different rules than the one you get executing mvn package. Whatever you exclude in IDEA is also removed from the webapp.
There are two ways to solve the issue.
1. Build using Maven
The first one is to have Maven build your module instead of IDEA. To do that you need to change the Before launch command: remove the default, click on +, choose Run Maven Goal and type in Command line something like -DskipTests -pl {module_name} package (see image below).
The profile will be picked up from whatever you have selected in IDEA (that was unexpectedly clever from the guys at IntelliJ, so kudos to them) but it has the drawback that it makes a full build each time you start Tomcat. In our case that’s roughly 25 seconds, which is quite a lot.
2. Edit the artifact
The second way, which is faster because it takes advantage of the automatic compilation of classes that IDEA makes in the background, is to edit the war artifact. To do so go to Build → Build Artifacts... → :war exploded → Edit..., select the tab Output Layout and create a directory of the same name (resources in my case) and add a Directory Content entry. Check the following image for details.
You will also need to change the Before launch similarly to the first solution, but just select the affected artifact.
UPDATE
Because the default war and exploded wars are imported from Maven, any change to e.g. the selected profile accompanied by a clean command reverts the artifact to the default layout, so if you use this solution you’d better create a duplicate war artifact.
I mean, I want a developer to be able to check out a project and not have to change anything to in order to get it to build and run. One problem I have run up against is that the proper compiler has to be added to the Build Path -- is there a way this can be done? I realize that the actual JDK will still have to be downloaded but could it be clear from looking at Eclipse which JDK is needed?
The build path is usually stored in a file called .classpath under the project directory, consisting of the classpath entries that were added in Eclipse. Among the entries in the file is one which points to the JRE library.
There is no "complete" configuration that can be saved. Every configuration is stored in a separate file. Some are stored in the project directory. Others are stored in the root directory of your workspace. You'd have to pick exactly which configuration you want to save.
One way to save a configuration for the project and its dependencies is to use a project management tool like Maven. It can configure the required JDK to compile the project (it can even enforce this rule), needed dependencies, etc.
If you set up your project to use an Execution Environment as its JRE Library (as opposed to the "Workspace default" option), then check in the .classpath and .project files, then checkout is a simple process. Execution Environment is an abstraction of the actual JRE/JDK that's installed on any machine/workspace; Eclipse uses that to map to a physical JDK in whatever workspace it's working in.
As others have mentioned, using Maven (or, even better, Gradle) to manage the dependencies will help, too - as long as every developer has the m2e (Maven integration for Eclipse) features installed into his Eclipse.
I have a plain Java project (not a plugin project) which I want to add to a classpath of a eclipse plugin which I am developing. But in web projects I can add that project as a build path and it works fine. But I tried same thing in eclipse plugin, I am able to compile successfully, but at run time I am getting java.lang.ClassNotFoundException.
I know OSGi quite well and I know how to add OSGi into an classpath (using export-packages) but what I want is to add Standard, non-osgi project into an classpath, so that I wont' get runtime errors. Is there anyway I can achieve this?
I can export project as a jar file or make it as a plugin project and it would work fine. But that's not my option currently because, still that API is in pre-alpha stage, and there would be lot of changes going on. So I am trying to avoid pain of exporting it as jar file everytime. Is there any option for me other than this?
I have a similar situation: I want non-OSGi Maven dependencies integrated into the classpath of my plugin. I succeeded with a roundabout solution, which I think is the best I could get.
I have a build step outside of Eclipse where I copy the class files of the dependency into the plugin's lib folder. The lib folder is specified in MANIFEST.MF as an entry in Bundle-ClassPath and (here comes the hack) as a source folder in build.properties. That was the only way to make the plugin work both when launched from within Eclipse and when exported.
I need to do a Java web project. I'm going to be using Eclipse.
I thought of using Spring MVC. As far as I can tell - it's gonna require me to add some "extra" stuff to a "clean" Java web project. I don't mind that - the thing is - one of the project requirements is - that I'll be able to send the project to someone else - that doesn't have any extra installation and/or configuration - and he will be able to compile the project.
Is that possible with Spring MVC? Does the Spring MVC framework is just a "JAR" like addition to the project - therefore - the project can be shared without a problem?
Thanks.
Short answer: yes, you are right.
To use Spring in your Java web project, you generally need to add two things:
the appropriate Spring configuration file(s) (XML)
the appropriate Spring JAR files (traditionally placed in /WEB-INF/lib, the same as other JARs). By the way, it is NOT a single JAR file, but several JAR files.
That is all there is to it.
Spring has nothing to do with "sharing the project".
To "share" the project with someone else, you put it on the SCM of your choice and your collaborators will be able to get the code and work on it.
Building the project is a different aspect. To correctly compile the project you have to make sure that all the classes and/or jars are visible in the classpath (and runtime if you want to execute the code). Spring is made of a bunch of jars that, depending on which classes of the framework you use, must be in the classpath (eg. putting them in the /WEB-INF/lib directory). You may version them as well, or just version the configuration (I'm thinking about Maven for example, that will take care of resolving the dependencies).
Another piece of the puzzle is making all of this work in your IDE. This is a matter of taste. I prefer not to version ide-specific files (in the case of Eclipse, .settings and .project files/folders). You can do that, making sure you do not use absolute path anywhere, and technically you will be able to import the project without problems from another machine.
Yes.
If the other person has nothing extra installed and configured, namely no build tool, you need to put every needed Spring and other Jar into a folder, typically called "lib" and tell him to add them into his compile process. If he just uses the JDK he will get an enormous command line. It is much better to use a build tool like Maven or Ant+Ivy for building and dependency resolution. But that would be an "extra installation" per your question.
If he has Eclipse installed like you have and you use Eclipse internal for building:
Put the JARs in a lib folder
Configure the build path
Make a local test build
Export the project as zip (File menu > Export)
" The other person needs to import the project into his workspace
The exported project should not have any absolute paths as long as you didn't set some deliberately in the build path.
This works but is not exactly best practice. Installing a build tool like Maven is absolutely worth the time and should be preferred under any circumstances. It will save you a lot of time and nerves.
I'm working with some very old, monolithic software that is basically a heavily customized JBoss deployment. Unfortunately, this means that JBoss can't be started from the "Servers" view in Eclipse, it must be started as a Windows service or via the command line. There are multiple WARs/EARs, but the WAR classloaders are rarely used and most of the actual class files are located in jboss/shared/lib as .jars.
We need a way to run a Maven build in Eclipse (via m2e) and deploy the class files in the resulting .jar to C:/product/jboss/shared/lib so that when we start JBoss, we can use Eclipse to debug (as a remote java application). Ideally, the artifact that Maven pushes will not overwrite the existing .jar file that was originally installed. For example, if the Maven project builds an artifact named myjar-1.0.0.jar, we need a way to deploy the classes inside of myjar-1.0.0.jar to C:/product/jboss/shared/lib/classes so that they are picked up by the classloader prior to C:/product/jboss/shared/lib/myjar-1.0.0.jar, which was installed with the product.
Currently, our (very hacky) solution is this:
Under the project configuration's Java Build Path > Source tab, we use the "symlink" functionality under Advanced to map the Default Output Directory (e.g. project/target/classes) to a class folder (e.g. C:/product/jboss/shared/lib/classFolder). This modifies the .project file, which is checked into source control.
We build the project normally with a m2e launcher (e.g. clean install).
Assuming the Maven build is successful, we run an Eclipse project build. This pushes the class files to C:/product/jboss/shared/lib/classFolder:
We restart JBoss. Since classFolders take precedence over jars, JBoss will load the classes in C:/product/jboss/shared/lib/classFolder, which are identical to the classes in our Eclipse workspace.
We attach to JBoss and debug the project as a remote java application.
Pros:
We're able to push our new classes to JBoss and test them without backing up the original jars and copy/pasting the new ones by hand (jar hell).
Cons:
We're compiling twice -- once with the maven-compiler-plugin, and
once with an Eclipse project build (Java Builder).
The symlink functionality is hit or miss in my experience. Sometimes we need to
do the refresh project/close project/build project dance to get it to
work.
Is there a better way to do this? I cannot force them to restructure the project so heavily that all deployables are container-agnostic WARs, but our developers need to be able to make changes and quickly test them without manually copy/pasting .jars.
How old is old?
Have you looked at the Cargo plugin?
http://cargo.codehaus.org/Quick+start
It can deploy to JBoss 3.x.
It has a Java API so you should be able to write something to extend it to do what you want.
Why are you trying to deploying classes instead of jar files?
You can still remote debug via Eclipse with jar files.
Worst case scenario - use Ant.
Maven is not designed for this kind of stuff, trying to force it to work will just cause you pain.
Once you have got Maven generated the right artifacts, work out what you would do manually and then script it via Ant.
I would try looking at the maven-dependency-plugin which has the possibility of copying artifacts to different location.
Please check your Deployment Assembly (project -> properties -> Deployment Assembly) and verify if your maven libs are there.