I'm developing my first maven application and now i have this trouble, i performed the following commands
mvn compile
mvn package
mvn jboss-as-deploy
the deploy process ends without errors but in my JBOSS_HOME\standalone\deployments i don't find the .war
why?
Try to set targetDir option (maybe the default is overriden in your environoment?). See http://docs.jboss.org/jbossas/7/plugins/maven/latest/deploy-mojo.html.
The $JBOSS_HOME/standalone/deployments directory is not where deployments are stored. If you look in that directory there is a README file that explains it's what the directory is used for.
The jboss-as-maven-plugin uses the deployment API's to deploy the content to the server. This generally ends up in $JBOSS_HOME/standalone/data/content for a standalone server. Though you really shouldn't be doing anything with files in that directory.
Related
I am doing auto deployment of Java Application using Maven and Jenkins, but it is getting failed.Here is the console output:
I have set the environment varaibles and also downloaded and configure all the required plugins. Need help to solve this issue.
Thanks
First of all: Please copy/paste messages instead of using images.
Secondly, the message said that you probably misconfigured the directory for the settings.xml. The settings.xml is usually in the directory .m2 in the user directory, but it can also be supplied from somewhere else.
I have a Jenkins job that uses a script to build my project. On the following line, the script fails mvn -e -X -Dgit='$git' release:prepare.
Because I want to search for the cause of this, I want to go to the Jenkins server and run mvn -e -X -Dgit='$git' release:prepare from the command line, to see if it works.
Does Jenkins store the projects' source code somewhere, such that I can go to that folder and call Maven?
If yes, then where?
Yes, It Stores the project files for the job by default at
/var/lib/jenkins/workspace/{your-job-name}
This is where jenkins suppose the project files to be present or it pulls it from a source before start working/building from it.
Quote from Andrew M.:
"Hudson/Jenkins doesn't quite work that way. It stores configurations and job information in /var/lib/jenkins by default (if you're using the .deb package). If you want to setup persistence for a specific application, that's something you'll want to handle yourself - Hudson is a continuous integration server, not a test framework.
Check out the Wiki article on Continuous Integration for an overview of what to expect."
From this Question on serverfault.
This worked for me:
/var/jenkins/workspace/JobNameExample
but, if your build machine (node) is a different than the one where Jenkins is running (manager), You need specify it:
/var/jenkins/workspace/JobNameExample/label/NodeName
Where you can define label too:
jenkins stores its workspace files currently in /var/jenkins_home/workspace/project_name
I am running from docker though!
Congratulations on the spring state machine, I found it yesterday and have been trying it out, specifically the turnstile example running in STS. I found it very easy and intuitive to build a FSM.
Because spring shell doesn't work well in STS I tracked down the instructions to run the examples from the command line in the reference doc,
"java -jar
spring-statemachine-samples-turnstile-1.0.0.BUILD-SNAPSHOT.jar"
,
but running it got an error
"no main manifest attribute, in spring-statemachine-samples-turnstile-1.0.0.BUILD-SNAPSHOT.jar".
Although not even a novice in using gradle, I tried fixing this by adding this line to build.gradle in the jar section
"manifest.attributes['Main-Class'] = 'demo.turnstile.Application'"
(which doesn't handle the various sub-projects I know) but got this error
"NoClassDefFoundError: org/springframework/shell/Bootstrap".
If it is possible to run the samples from gradle, could you include them in the reference document? I tried running the samples using
gradle run
but it there was no interaction with the shell scripts.
Samples are designed to be run as executable jar and with shell so that you can interact without a need to recompile with every change. Your error indicates that you didn't build that sample jar as mentioned in docs.
./gradlew clean build -x test
This will automatically use spring boot plugin which will add the necessary jar manifest headers to jar meta info to make it a true executable jar. Essentially every every sample is a spring boot app.
Building SM sample projects in Windows Environment:
Open Command prompt (windows key + r -->cmd-->Enter), Change directory to project root folder spring-statemachine-master (Inside the Extracted folder).
Run gradlew install to get all spring dependencies copied to local machine.
Run gradlew clean build -x test to get the spring shell jars built. Courtesy Janne
These steps should ideally get all .jar built, look into \build\libs folder of respective sample project for jar files.
Run the like any other java jar file java -jar [jar-file-name.jar] (make sure to be change directory to jar file directory location).
One more thing where I was stuck was, How to give events to SM:
It's like this sm event EVENT_NAME_AS_DEFINED_IN_CLASS. Ref
E.g.: sm event RINSE --> to washer project
We have the following project setup: Maven, Eclipse, Subversion. Eclipse Launch configurations are in a separate docs folder next to the pom.xml. The launch configurations run something like mvn clean install -Pdev or mvn tomee:run -pl something-ear
The good thing is that a shared run configuration is picked up by the IDE and shown in the External Tools run commands. This way, every developer that checks out this project immediately has access to run the build.
We would like to have something similar using IntelliJ IDEA, but I haven't found a good equivalent. What I have considered so far:
Share run scripts
My first idea was to replace the launch configurations with run scripts. I just could not figure out how to have those run scripts run inside IntelliJ IDEA just the way a Maven goal would be executed.
Share IDEA project configuration
The IDEA project configuration (specifically .idea/runConfigurations) inside the checked out directory is not a good solution. We have (speaking one IDEA project with different IDEA modules depending on the task at hand: as a developer you might need multiple IDEA modules (and sub-modules) in the same IDEA project
An IDEA project consisting of the following modules is not something unusal
projectA/trunk
projectB/tags/1.2
projectC/branches/some-change
My preferred solution would remove all IDE-specific configuration from the repository and have some kind of run definitions either in the project folder or a folder next to the pom.xml that a developer can run from the command line or from her IDE of choice.
The optimal solution would let me define something like this in the pom:
<runConfigs>
<default>clean install</default>
<container>tomee:run -pl something-ear</container>
</runConfigs>
This configuration would then be picked up by the IDE and provided as a run or launch configuration to the developer.
Any ideas or suggestions?
Thank you very much!
My current approach is a hybrid solution:
No configuration in the separate modules
One IDEA project configuration with run configurations managed in VCS
The .idea/runConfigurations directory is versioned separately from the project sources. It contains commands with a working directory set relative to the PROJECT_DIR:
<MavenRunnerParameters>
…
<option name="workingDirPath" value="$PROJECT_DIR$/path/to/submodule" />
</MavenRunnerParameters>
When setting up a new project, the developer also checks out this folder and has a set of pre-configured launch configurations for all projects. The downsides are
All launch configurations are managed centrally instead of with the module
The IDEA project directory has a fixed location relative to the modules. If you set up another project, you will have to change the run configurations
The setup does not clearly state how changes to the launch configurations are shared with other developers
I am running jboss 7.1, maven 3, and a java ee6 application that generates an .ear
I am doing a mvn clean package jboss:as-deployand Jboss-as-maven-plugin 1.5 does its thing--I can view my app using http://localhost:8080...
just fine, but I want to know where the actual .ear is being put.
It is not in my jboss7.../standalone/deployments folder. So where is it? My app is obviously running in jboss 7.1 just fine, but I can't find the .ear file. I know that there is an .ear in Eclipse's 'target' directory, but that wasn't produced by jboss-as-maven-plugin is it? I hope you can understand my confusion--don't all .ear files need to be in the deployments directory? I also do see my .ear file inside my hidden .m2/repository directory, but does this have any interaction with jboss-as-maven-plugin? Maybe there is some hidden sym-linking between my Eclipse project's 'target' directory and the jboss7.1 standalone/deployment directory?
p.s. I am used to using a hard-deploy option with the other plugin jboss-maven that requires you to say jboss:hard-deploy which just copies the .ear to your deployments folder. Then jboss would pick up the new .ear and redeploy automatically. I get the sense that jboss-as-maven-plugin is the preferred plugin so that's why I am bothering.
The jboss-as-maven-plugin uses the deployment API so it doesn't copy the file to the deployments directory for the scanner to pick it up. It deploys just as if you deployed it from the web console or via CLI. The files should be located somewhere in the $JBOSS_HOME/standalone/data/ directory.
You're welcome to open an issue, for a discussion around it at least. I'm not sure how I feel about adding a goal for it, but here isn't the place to discuss that :)