I have an Eclipse Dynamic Web Project that has multiple deployment descriptors (2 extra) that are adversely affecting deployment:
I do not know how extra came to be, nor how to get rid of them. There is only 1 web.xml file in the project located in WebContent/WEB-INF
How do I eliminate the extra descriptors?
Edit
Created a new Dynamic Web Project in workspace. The new project only has 1 deployment descriptor:
Furthermore, the contents of the .settings folder:
Whereas the .settings folder for the project with the extra deployment descriptors:
I had the same problem and a simple right click on the project and "Refresh" erased the duplicates ones
You can also fix this issue by doing the following:
-Clean server
-Run as->Maven build...
-Goals: clean install
-Run (after completion console window should say BUILD SUCCESS.. else fix your errors..)
-Maven -> Update Project
These steps only work if you are using Maven build tool.. but they worked for me as I was facing a similar issue with multiple deployment descriptors, and because of this my server was unable to pick up my coding changes
Related
I have 3 C projects (prj_1, prj_2 and prj_3) in my workspace. prj_3 is referenced by prj_2 and prj_2 is referenced by prj_1.
For each project I have 4 build configurations as x86_win_debug, x86_win_release, x86_linux_debug and x86_linux_release.
The problem arises when I want to change the build configuration of prj_1 from one to another. I have to change the build configuration of the sub-projects (referenced projects) one by one manually. Is there any way to automate this process without using my own makefile? i.e. I change the build configuration of prj_1 to x86_win_debug and I want all the sub-projects be compiled with x86_win_debug configuration even if their last configurations are different then x86_win_debug. Is that possible?
This is possible with the "Project References" settings in the "Paths and Symbols" page of your project's properties. See also the related Eclipse help entry.
I have just tested this by deleting the associated build folder from the referenced project and building the dependent project.
The structure is as follows:
Actually deployed module is EAR.
EAR contains WAR module, and WAR module contains another JAR module.
In this last JAR, there are some generated classes and their parent folder is also used as source folder. Its path is "target/generated-sources/java".
The problem that is killing me, is that the deployed application throws ClassNotFoundException on server start, and the classes in question are the generated ones.
Now the trick:
if I explicitly change the Deployment Assembly in WAR project in Eclipse not to contain JAR project as "project", but as an archive from the JAR's project "target" folder, JBoss sees the generated classes and starts.
This solution however works only until next eclipse maven project update, so manual edit of deployment assembly is not really a solution.
Any ideas how to deploy or reorganise packages correctly?
OK, seems I have found the solution.
I looked through the build-path of the mentioned JAR file and saw that the entry Output folder pointed to target/test-classes.
After changing this entry to target/classes the application deploys and starts without any missing generated classes.
This is what worked for me:
Expand the 'target' folder of your maven project inside Eclipse (Project Explorer View);
Refresh it (F5);
Right click on your project on 'Servers' tab, then select "Full Publish";
Start your JBoss.
I had to enforce the JBoss Tool "Full Publish" to get an updated version of my target folder by Refreshing it manually on eclipse.
I don't know why but sometimes the Publishing from maven projects (even Full Publishes) do not copy classes from the target Project as it is in the file system. Maybe it's using some outdated memory info or some cache...
Anyway, this is what works for me.
After an update to Eclipse 4.15 and JBoss tools I got this problem too.
My solution: project -> properties -> Java Build Path --> Source
There my Output folder from my source was linked to project/target/classes, I changed this to project/target/project-projectversion/WEB-INF/classes
When I looked into the standalone JBoss folder I saw the folder structure of my source, but the classes where missing, when I changed the output folder the classes pop up and everything worked like before.
I am pretty sure the update made the problems.
when I use an external tomcat everything is just fine. but I need to deploy my project on internal eclipse tomcat server in order to be able to use DCEVM class hot swapping.
When I try to start tomcat server from within eclipse it says it is not able to find one of my service classes I mentioned in my spring security configuration file as a bean.
I also tried to add the project to tomcat class path but it did not solve my problem.
UPDATE
I found out the problem is because when I deploy my web project to eclipse tomcat server, no .class is copied to:
C:\Users\Meysam\workspace\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\villapweb\WEB-INF\classes
in fact, this folder contains my src/java/main package structure but no .class is copied in it.
lib folder is fine though (e.g. all dependencies of maven and other stuff copies in the path it is supposed to)
I think there might be something wrong with m2e-wtp plugin. I dont know what!
I am using eclipse 4.3 BTW.
SOLVED
I Solved this issue following these steps:
right click on project in eclipse > properties > project facets
in the right panel select runtimes and select your target server. Apply and ok.
in the server modules list right click on project module and click clean module work directory
right click on the server itself and you can clean both server and tomcat work directory one after another
if that didn't work, try project > clean and also toggle "build automatically" option under project menu item.
Thats it. tomcat now copies all .class files to the target server and you see no ClassNotFound exception as tomcat starts up.
[Copied to answer section]
I Solved this issue following these steps:
right click on project in eclipse > properties > project facets
in the right panel select runtimes and select your target server. Apply
and ok.
in the server modules list
right click on project module and
click clean module work directory right click on the server itself
and you can clean both server and tomcat work directory one after
another
if that didn't work, try project > clean and also toggle
"build automatically" option under project
Thats it. tomcat now copies all .class files to the target server and you see no ClassNotFound exception as tomcat starts up.
I've followed the steps on the answer but It still wouldn't work for me, so, besides doing these steps once, I've found that doing a refresh on the target after doing a clean install automatically triggers the "Republish" status on the server, so when the server is executed all changes on the compiled classes (new classes and changes to existing ones) are then copied to wtpwebapps when the server is started.
I had almost the same problem - one of my projects did not make it to the deployment area (its jar). What i did is 1) remove the appliction from tomcat 2) clean tomcat work directory 3) most important: project - clean - all. Then i added the application again and... problem solved
I had the same problem in Web Dynamic project converted to Maven project.
I found error in properties->Deployment Assembly->right panel.
There was source=src folder and deploy path=WEB-INF/classes. Classes couldn't be found by Eclipse.
Changed to source=target/classes.
I am using Eclipse 4.2 and JBoss 7.
I have Build automatically checked in Eclipse.
Even then I have to build and redeploy the EAR file to JBOSS to test any code changes I make in Eclipse debug mode.
Am I missing something here?
THanks,
What the "Build automatically" option in eclipse do is that when you modify the source code of a class, this one will be automatically compiled, which doesn't mean that all the whole project that contains the class (i.e. war, jar, ear ...) is redeployed in the server. But of course it helps in the speed of deployment, because the classes you've been modifying are already compiled when you manually build or deploy the project.
On the other hand, to avoid problems with redeployments, you'd better set up JBoss to delete the files related to the application keeps in the work directory, when the application is undeployed / redeployed. Look at this stackoverflow thread for more information.
Concerning the "Build automatically" option:
In order for the Deployment Scanner in JBoss to work, you have to have it turned on in JBoss.
Also, you need to add your project to the JBoss server in the Servers window. Look for the "Add or Remove..." option.
Once your project is added, any changes you make to your code will get detected and your module will be redeployed automatically in the background. Failing that and assuming your project doesn't have a snag, you can use mvn install & mvn jboss-as:deploy to manual update your module.
Beware, sometimes mvn doesn't pick up the latest java code. This seems to be a project configuration issue more than anything. Re-creating the project seems to correct the issue.
Also, keep an eye out for duplicate persistence.xml files.
You only need one.
I am currently trying to get my headless pde-build working but I am stuck on a point where I do not know how to continue.
The problem is how to define the related target platform to compile the plugins against.
I have a build.bat with the following call (all in one line!):
java -jar D:\target\eclipse\plugins\org.eclipse.equinox.launcher_1.0.201.R35x_v20090715.jar
-application org.eclipse.ant.core.antRunner
-f D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml
-Dbuilder=c:\pde-build\scripts %*
I tried to create the target eclipse platform from different parts: The eclipse SDK, RCP SDK, Delta Pack, PDE-SDK in all combinations but none of them worked well.
I got the following error:
BUILD FAILED
D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_20100114\scripts\productBuild\productBuild.xml:18: Cannot fin
d ${eclipse.pdebuild.scripts}/build.xml imported from D:\target\eclipse\plugins\org.eclipse.pde.build_3.5.2.R35x_2010011
4\scripts\productBuild\productBuild.xml
where the variable ${eclipse.pdebuild.scripts} does not got resolved. I also tried to give this parameter via the command line but then I got another error regarding missing svn task which is absolutely confusing as this is working with my local eclipse installation referenced.
When I replace the path from d:/target/eclipse to my local eclipse installation the pde build works as expected!
This leads my to the point that the configuration of the target eclipse is not correct but in the moment I have no idea how to configure this!
My goal is the automate the pde build first on my local site without referencing my local eclipse and later on integrate this building process into our running cruisecontrol instance.
As I saw already another question about defining the target eclipse I would be happy if anyone can contribute hints or facts regarding the problem.
Regards,
Andreas
When performing a headless build, the target can be separate from the eclipse that is actually running the build itself. The problem you had here is that the eclipse that you were using to run the build did not have PDE/Build properly installed.
This is why the ${eclipse.pdebuild.scripts} was not set, because PDE/Build was not installed into that eclipse instance, the org.eclipse.pde.build bundle was not resolved and the code that sets this property never got called. Similarly, the necessary ant classpath entries for PDE/Build tasks would not have been set up properly either.
You need the Eclipse with PDE installed inside to run the build, but the target for the build can be separate from this.
In the build.properties file found under -Dbuilder=c:\pde-build\scripts you can set several properties:
baseLocation This is a path to an eclipse that is your target.
buildDirectory This is where the build will actually take place, source is fetched to plugins/ and features/ subfolders, but if there are already binary plugins located here then those become part of the target as well.
pluginPath This is a list of paths (separated with ';' on windows or ':' on linux) containing other locations that should be considered as part of your target. These locations can be several things:
The root of an eclipse-like install with plugins/ and features/ subfolders. This is a good way to provide the delta-pack instead of just unzipping it on top of an eclipse install.
The root of a workspace-like folder, where all subfolders are treated as plugins or features depending on the presence of a manifest or feature.xml.
The root of a bundle or feature, or the jar for a bundle.
If you are doing a p2 build (p2.gathering = true) you can also provide p2 repositories under a ${repoBaseLocation} which will be transformed and placed under ${transformedRepoLocation} and will become part of your target, and the p2 metadata there will get reused during the build.
after some more time of investigation I found out, what I did wrong so far. As I mentioned above defining the target platform is not that easy as copying the SDK and plugins in into one location (as it was in early times of eclipse dev).
The working solution by now is the following: Copying the eclipse SDK into the target location and run this version. Install inside this the neccessary PDE-Tools to enable plugin development. After that, close the IDE and copy the delta pack + the respective svn plugin (I used org.eclipse.pde.build.svn-1.0.1RC2 from sourceforge) into the target platform and you're done.
Now my automated PDE build is running as expected.
Only minor issue now is the following: The result product contains eclipse-specific menu entries which are not there when I ran this from inside my dev-eclipse.
Any hints on that?
I just posted an answer to my question on this kind of topics, may be this can help you:
Plugin product VS Feature product