I installed Tomcat using the Windows installer ages ago and it runs fine as a service on my development laptop. Now I'm mavenising my project and would like to use Cargo (or something similar) to deploy updated WARs onto the local Tomcat.
I can't find any fully worked examples of a POM file containing the right XML to do this and am struggling with the partial examples on the Cargo site.
Does anyone have a POM they can post or know of an example in the wild they can link to?
FWIW the error I get is this - though I've tried many different combinations of parameters:
Cannot create configuration. There's
no registered configuration for the
parameters (container [id =
[tomcat6x], type = [local]],
configuration type [existing]).
Actually there are no valid types
registered for this configuration.
Maybe you've made a mistake spelling
it?
I'm not even sure I know exactly what the error means by a "type" in the first place!
Update: I eventually found the m2eclipse WTP integration plugin, which frankly rocks!
Is there a reason to use just cargo?
You can try the maven tomcat plugin in order to deploy your wars to tomcat. See the instructions about configuration and deployment.
Related
I am new to rest, so I followed this tutorial exactly the way its mentioned here:
However, I get a requested resource not found error when I hit the URI mentioned there, that is,
http://localhost:8080/RestletDemo/service/helloWorld
My build was successful.
This is the first time I am posting a question, my apologies for any ambiguity. Do let me know if you need more information.
It's difficult to figure out your problem like that. I have a look at your link and the problem of the provided code is that there are a lot of plumbing. Things could be much more simpler leveraging for example bean converters (Jackson one for example).
However, I didn't see anything strange in this code. Perhaps it's a configuration problem within your servlet container. For example, when using Tomcat with WTP in Eclipse, I need to check the item "Publish module contexts to separate XML files" to make things work.
I just submitted a very simple Restlet project targetting servlet and without all these plumbing. I made it work under Eclipse with WTP 2 (Tomcat7). You can reach it here:
https://github.com/templth/restlet-stackoverflow/tree/master/restlet/test-restlet-servlet
Since it use Maven, to use it, you can simply :
mvn eclipse:eclipse and then import it into Eclipse. You can then create a server (WTP) and add the project
mvn package and deploy the corresponding war into a servlet container (Tomcat or something else)
Hope it helps you,
Thierry
I am using IntelliJ (14.0.3) and Wildfly (8).
When I recompile my Java classes, hot swapping is easy and everything works just fine. However, my HTML, JS and CSS files will not hot swap for me. I am sure it is just a configuration issue and was hoping for some help.
My HTML data is in:
<root>/<war_module>/src/main/webapp
My run/debug is setup for:
Before launch: Make, Build Artifacts
Make
Build 'mymodule:war' artifact
I had the exact same problem, this is how it worked for me:
After configuring your JBoss server (Wildfly), setup an artifact of type exploded, in my case I selected Web Application: Exploded, and then in the Output directory add .war to the end of the name.
In case you need a .ear, simply select JavaEE Application: exploded instead, but anyways always remember to add manually the extension.
After setting this artifact to work with your Application Server, in the edit configurations of your Wildfly server select the option Update resources in the list of options in the section On frame deactivation.
So every time you modify and save static content, it will update these changes as soon as you focus something else outside the IDE, like the browser.
(This question is asked on Maven User mailing list too)
I have recently faced a strange problem, that I cannot even able to judge the cause or source of problem. It will be great if someone can give me some direction:
(The story may be a bit long)
I am using Nexus 1.8.0 as our company's repository manager. I use it as proxy of external repo, and hosting our own repository.
There are many repositories in Nexus. I have one repository group (let's call it PUBLIC) which groups all public repositories, including maven central, codehaus etc.
There is another repository group (let's call it EXT) which we put 3rd party artifacts.
In our project, we used org.codehaus.mojo:native2ascii-maven-plugin.
Due to a bug at that time, instead of using the publicly available org.codehaus.mojo:native2ascii-maven-plugin:1.0-alpha-1, I have fixed the bug and deploy it to our EXT repository, and called it org.codehaus.mojo:native2ascii-maven-plugin:1.0-alpha-1.1 (i.e. used a new version number 1.0-alpha-1.1 instead of 1.0-alpha-1)
This have been running fine for several years.
However recently a new developer tries to get the code and build, using Maven 2.2.1. Strange things happened: the build failed. By inspecting result of mvn -X clean install, it states that POM of native2ascii-maven-plugin:1.0-alpha-1.1 cannot be downloaded from PUBLIC, therefore it will use a default emtpy POM, which cause the build problem.
By inspecting the local repository, I found that only the JAR of native2ascii-maven-plugin:1.0-alpha-1.1 was downloaded. I am sure that there is no native2ascii-maven-plugin:1.0-alpha-1.1 in PUBLIC repository, and the SHA of the JAR matches with native2ascii-maven-plugin:1.0-alpha-1.1 in EXT. It seems that, Maven is capable to download the JAR correctly from EXT repo, but when it tries to download the POM afterwards, Maven mistakenly think that it should be downloaded from PUBLIC. Because PUBLIC do not contains 1.0-alpha-1.1, Maven assume there is no POM.
I have EXT repo defined before PUBLIC in my settings.xml. What even more strange is, I tried to block accessing in Nexus for native2ascii-maven-plugin from PUBLIC. Maven, instead of getting the POM from repository EXT, it get from central directly. At last I add PUBLIC as mirror for central, and Maven can build correctly, because EXT is the the only repo that contains native2ascii-maven-plugin. Maven seems tries to download the POM from every repository else which contains native2ascii-maven-plugin in despite of the version number, except from EXT
I simply cannot understand why this will happen. This have been used for years, and it used to be fine even several weeks before (I have other new developers, who can correctly download the plugin, several weeks ago). May anyone guide me the possible cause of the problem? I have neither changed anything in my repo, nor changed version of Maven. Why Maven's "download" behavior suddenly changed?
It's hard to say.
First my theory on why it no longer works. I am guessing this "worked for years" because at one time it worked, and afterwards everything was in your local repository (<home>/.m2/repository). Later, something broke, but you never noticed because you had everything local. The new developer did not have a populated local repository so when they built for the first time, they had failures.
Now my suggestion which may not work out for you. When using Nexus, I think its best to create a single "group" repository that links in all other repositories, and configure the group to order the priority of the linked repositories. So for you, in the group, you would list EXT first, then PUBLIC. Your POMs and/or settings would reference only the group repository. This may just duplicate what you are already doing through other means, but at least it is moving the ordering rules up into Nexus. I would rename your local repository (so you can revert back if necessary) and try re-building to see if everything resolves correctly.
You might want to consider a continuous build tool like Hudson that periodically deletes its own local repository so you can catch issues like this sooner.
At last I managed to find out the "cause" of the problem. It is due to my fault, combined with still-unknown behavior of Maven. I add this as an answer to ease future reference for other people.
They key problem is that I missed plugin version for this specific project (I did put corresponding pluginManagement for other projects, and other plugins for this project... I wonder how come I made this mistake this time)
The way to reproduce the problem:
A separate repository to store the plugin (in my case, org.codehaus.mojo:native2ascii-maven-plugin:1.0-alpha-1.1)
In project POM, add plugin, without version. For example,
<plugins>
<plugin>
<groupId>org.codehaus.mojo</groupId>
<artifactId>native2ascii-maven-plugin</artifactId>
<plugin>
</plugins>
in settings.xml, avoid defining mirrors (i.e. the settings.xml contains list of repositories and pluginRepositories only)
With such setup, first purge the local repository. Then build the project. After build, inspect the directory in local repository for that plugin (in my case .m2\repository\org\codehaus\mojo\native2ascii-maven-plugin\1.0-alpha-1.1), you will find only the JAR presents, without corresponding POM. (Caused by Maven successfully get the plugin JAR corresponding to the pluginRepositories in settings.xml, but trying to get the POM from a weird location)
With the same setup, put the version in project POM, clean up the local repo, and build again. Everything is fine now.
The reason for work fine even for a recently clean CI environment, is probably due to other "correct" project made the plugin downloaded correctly, which can be used by this "incorrect" project. A periodic purge in local repository in CI won't necessary help much on this too because for that many projects, the chance is always very high for other "correct" project build earlier than that "incorrect" project.
The reason behind such behavior of Maven is still unknown, but at least in a "correct" POM (with plugin version correctly declared), Maven works fine. I will raise this as a issue for Maven though.
I'd start off by agreeing with SingleShot in that Continuous Integration - even a simple smoke test where you simply compile and run unit tests on the trunk - would have prevented you getting into the situation of assuming that the because the build works on one machine, it does not work on the other.
This have been running fine for several years.
That's the kicker with Maven repositories - all you need to do is download it once succesfully, and you'll be forever good to go. Just because it's been working successfully from your local repository doesn't mean it was working.
It is fine several months ago (coz I have migrated our CI server and I have a clean env to build, and everything is fine).
Interesting. So my theory would be then to go and make sure the new developer is set up correctly - that the settings.xml file is in place and is being read (I've had instances that the settings.xml is THERE, but in the wrong place!). It's a simple one, but Maven does not fail if there's no settings.xml, it just uses a default that may have you seeing ghosts.
You mentioned that you use maven 2.2.1 and I can only ask you to doublecheck, we had some strange behavior concerning downloading jars from internal repo that was caused by OSX Lion update that comes with maven3. Our fix was to redeploy affected project.
If I understand it properly, SpringSource has a public OBR which contains OSGi bundles for many third party jars. I would like to use it in Eclipse, but I can't get Eclipse to connect to it.
I have tried:
http://ebr.springsource.com
It hangs there for ages, and returns as error:
Error reading update site http://ebr.springsource.com.
The XML stream is not a valid default "site.xml" file.
The root tag is not site.
And I have tried:
http://ebr.springsource.com/repository
Which returns quickly as error:
No repository found at http://ebr.springsource.com/repository.
So, what URL am I meant to use?
[EDIT] Made some research after getting my first answer. I found this site which claims to have a list of public OBR repositories:
OSGi Bundle Repository:
http://www.osgi.org/obr/browse?cmd=repository&_xml=1
Spring Enterprise Bundle Repository:
http://sigil.codecauldron.org/spring-external.obr
http://sigil.codecauldron.org/spring-release.obr
But none of them work with Eclipse either. I'm just more confused now.
What I (think I) understand is:
1) SpringSource EBR is a Repository of OSGi Bundles, without being a "OSGi Bundle Repository". This makes no sense to me. What's the point?
2) An "OSGi Bundle Repository" is just a XML file that defines the configuration of a Repository of OSGi Bundles.
So, If I give http://sigil.codecauldron.org/spring-external.obr to Eclipse, instead of http://ebr.springsource.com, I would expect Eclipse to use the content of that file to access http://ebr.springsource.com, but it doesn't work either.
So which one of the possible reason is it:
1) http://sigil.codecauldron.org/spring-external.obr is outdated or wrong
2) http://sigil.codecauldron.org/spring-external.obr is not compatible with Eclipse (apparently, it works with Apache Felix)
3) An "Eclipse Update Site" is NOT an OBR (and neither is it a Maven Repository), although it should also contain OSGi bundles. If that is the case, then it wouldn't make much sense either, since Eclipse is OSGi-based.
SpringSource EBR is not an Eclipse Update Site, so it cannot be used this way. It is also not an OBR, at least currently. But Eclipse PDE doesn't use OBR anyway (though Bndtools does).
You can use it as a Maven repository, I think.
I finally have my application in IntelliJ and deploying to JBoss. I'd like to get hot deploy working but it looks like I need to understand how IntelliJ and JBoss interact.
When I build my project in IntelliJ and then start JBoss, the ear file does not appear in the deploy directory so I assume that there is some magic that IntelliJ does so that JBoss reads from a different folder. What is happening during this step?
Thanks :)
I know this is an old and apparently answered question, but unfortunately the links provided in the accepted answer didn't give me the simple details I was looking for. For anyone also trying to understand how IntelliJ IDEA deploys your exploded war to JBoss without copying files to the deployments folder, here's what I've found while deploying locally from IDEA 14 (EAP) to JBoss 7.1.1.Final:
After you've created an "exploded war" artifact for your project (or it has automatically been created for you), IDEA will build your provided sources and place the output in the directory set in the artifact options (you can change this setting to place the output inside the deployments folder inside your jboss installation).
IDEA will update your JBoss configuration file (/standalone/configuration/standalone.xml) and add a "deployment" node inside the deployments section. This entry simply defines a name, a runtime name and the exploded war root folder for your project, which will point to the output directory of your artifact set in IDEA.
When JBoss is started (either manually or from your run/debug configuration in IDEA), it will automatically deploy your artifact. Be warned that if your files are in the output directory of your project and you clean it, JBoss will still try to find the directory, thus encountering errors in your next attempt to start it: org.jboss.as.server.deployment.DeploymentUnitProcessingException: Failed to mount deployment content, Failed to process phase STRUCTURE of deployment and java.io.FileNotFoundException to name a few.
Please refer to the documentation.
Basically, you need an exploded Artifact configuration with the directory name ending with .ear.
Build | Make performs hot deployment as well as Update action (which is configurable and can update only resources, resources and classes, optionally redeploy or restart the server).
Instead of copying your application to JBoss, IDEA runs it with appropriate parameters so that it uses Artifact directory instead. Configuration is very flexible and you can just change the artifact directory location to reside under JBoss directory.