JBoss Tools / Eclipse Luna not adding required libraries to EAR

[meacod]

Hi all,

I'm attempting to upgrade our environment to Eclipse Luna w/ JBoss Tools from our current Indigo instance. Most things are sorted well enough, but I'm running into a wall when deploying our application to a JBoss server within Eclipse.

As far as I can see, the lib/ directory of the .ear file generated contains none of the transitive dependencies from Maven that we would normally expect to see, and as a result the application does not deploy or run correctly on the server. For clarity, we use the 'use workspace metadata' deployment option on the JBoss server within Eclipse. (This is a JBoss Enterprise Application Platform 5.x server instance in Eclipse, and we're using JBoss EAP 5.2)

By contrast, if I right click on the relevant project within Eclipse and say Export... .ear file, the resulting .ear contains all the .jars that I'd expect inside the lib/ folder (there's over 50 of these things, so it's pretty easy to spot the difference). Subsequently dropping this .ear into the deploy directory of JBoss and starting a server manually has the application working fine.

Has anyone ever encountered this sort of issue within JBoss Tools / Luna, and if so what steps were taken to try and remediate it?

I've added a stack trace below from the server console in Eclipse which reflects the missing libraries.

Cheers for any help.

Dave.

[2014-12-08 12:20:20,693] [      HDScanner] WARN  HDScanner Failed to add deployment: vfsfile:/C:/dev/workspace/eclipse/workspace-e44/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_AS_5.11418012246473/deploy/app.ear/

org.jboss.deployers.spi.DeploymentException: Exception determining structure: AbstractVFSDeployment(app.ear)

  at org.jboss.deployers.spi.DeploymentException.rethrowAsDeploymentException(DeploymentException.java:49)

  at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:85)

  at org.jboss.deployers.plugins.main.MainDeployerImpl.determineStructure(MainDeployerImpl.java:1001)

  at org.jboss.deployers.plugins.main.MainDeployerImpl.determineDeploymentContext(MainDeployerImpl.java:437)

  at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:387)

  at org.jboss.deployers.plugins.main.MainDeployerImpl.addDeployment(MainDeployerImpl.java:297)

  at org.jboss.system.server.profileservice.repository.MainDeployerAdapter.addDeployment(MainDeployerAdapter.java:86)

  at org.jboss.system.server.profileservice.hotdeploy.HDScanner.scan(HDScanner.java:385)

  at org.jboss.system.server.profileservice.hotdeploy.HDScanner.run(HDScanner.java:294)

  at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)

  at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)

  at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)

  at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)

  at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)

  at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)

  at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)

  at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)

  at java.lang.Thread.run(Thread.java:662)

Caused by: java.lang.RuntimeException: Error determining structure: app.ear

  at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:307)

  at org.jboss.deployers.vfs.plugins.structure.StructureDeployerWrapper.determineStructure(StructureDeployerWrapper.java:73)

  at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.doDetermineStructure(VFSStructuralDeployersImpl.java:196)

  at org.jboss.deployers.vfs.plugins.structure.VFSStructuralDeployersImpl.determineStructure(VFSStructuralDeployersImpl.java:221)

  at org.jboss.deployers.structure.spi.helpers.AbstractStructuralDeployers.determineStructure(AbstractStructuralDeployers.java:77)

  ... 16 more

Caused by: java.lang.RuntimeException: relevant-ejb-8.10.0-SNAPSHOT.jar module listed in application.xml does not exist within .ear vfsfile:/C:/dev/workspace/eclipse/workspace-e44/.metadata/.plugins/org.jboss.ide.eclipse.as.core/JBoss_AS_5.11418012246473/deploy/app.ear/

  at org.jboss.deployment.EARStructure.determineStructure(EARStructure.java:274)

  ... 20 more

[maxandersen]

Hey,

Sorry to hear you are having problems.

I've seen a few report similar issues JBIDE-18860 being the latest one but it is not exactly the same as yours.

But JBIDE-18860 and others before it all rooted in some kind of error during the configuration of eclipse based on the pom.xml that was not valid. i.e. pom.xml requiring java6 but using JavaEE 7 features (that requires minimum Java7) which then resulted in the configuration to fail and thus remaining setup for packaging was not done.

To investigate, can you tell if there any error markers in the problem view and/or anything in the eclipse error log ?

(your stacktrace above is from the actual running server which is less interesting since it just verifies something is not right in the packaged/deployed application)

And finally, any chance of you being able to share the project with us or reproduce the issue in a smaller scale than the full 50+ lib project ?

Thank you!

[rob.stryker]

We've had a lot of success in the past at debugging and assisting users when minimal projects that can reproduce the error are provided to us. At the moment, we're still trying to figure out in what ways the tools are failing our users, and whether there's a common cause between them that can be fixed with additional workflows or assistance for users. If you can provide a minimal project, I'm sure we'll be able to tell you what (if anything) is wrong with your project configuration, as well as improve the workflow in the future.

[dlmiles]

How many missing lib/** transitives are:

* 3rdparty project from Maven Central (or other outside repository)

* projects that are private/corporate projects from your corporate repository

* projects that are open in the Eclipse workspace

Do you have SpringIDE (or STS or similar from spring.io) installed?  If so what version?   Can you look at https://jira.spring.io/browse/IDE-1357 and consider implementing the workaround (if relevant) ?

Do you have a directory like workspace/.metadata/.plugins/org.jboss.ide.eclipse.as.core/*/*[dD]eploy/  which contains one or more JARs that are missing from the EAR ?   [I've noticed JARs showing up here that didn't make it to the EAR]

What method/mode of deployment with JBossAS/WildflyAS do you use ?  This mode is set in the server runtime Open action, then select the tab 'Deployment', the default is 'Use the JBoss deploy folder'.  [Checking your are using defaults]

What is the full path on your system to the Eclipse workspace ?  The EAR project ?  The AS runtime ?  [Checking you don't cross filesystems with this one]

JBIDE-18860 is a work in progress, the main cause of initial problem(s) is the SpringIDE/STS bug/issue causing M2E to fail 100% every time when Updating Project.  Thus it never completed, thus it never set many things up correctly and/or reported error markers about issues correctly.  However JBIDE-18860 is not over yet, I need to spend more time making the environment more complex.

[maxandersen]

Do you have SpringIDE (or STS or similar from spring.io) installed?  If so what version?   Can you look at https://jira.spring.io/browse/IDE-1357 and consider implementing the workaround (if relevant) ?

What workaround are you referring to here ?

As far as I can see there are no workarounds to it.

I pinged lead of STS to ask into it and he explains it is known issue but they are looking for steps on how to reproduce it - if you can provide such that would be great.

[dlmiles]

The workaround is explained in the IDE-1357 report, manually uninstall that one plugin, this fixes the bug report and I have not yet come across any loss of spring/m2e features that I was actually using.

[maxandersen]

The plugin[1] seem to provide integration with automatically configuring and enabling spring related features on your project plus various spring related shortcuts thus I'm sure it does get used by a lot of people thus suggesting we go into springIDE (which we don't support, just make it easy to install) and remove it is not really an option.

[1] spring-ide/plugin.xml at master · spring-projects/spring-ide · GitHub

[dlmiles]

I'm sure it (the spring IDE m2e support) does get used by a lot of people too.

However I am only suggesting they remove the affected buggy spring plugin, if they are affected by the bug.  (aka a workaround)

The easiest test for me to see if you are affected by the bug, make your workspace so that 2 or more projects have out-of-date pom.xml (this usually results in an error marker for each project explaining such) and require Maven -> Update Project to be run.  Run the dialog and select 2 or more projects to Maven -> Update Project.  It will bail out not completing the first, it will have configured some things on the 1st project and may look like it worked on that project, but it will not perform any action on the 2nd or Nth project.  In addition the Eclipse Error Log will have a stack trace, which is available at the IDE-1357 from the reference to the mailing list post.

[meacod]

Hi all, thanks for the responses.

In terms of the eclipse error log, there are no error markers etc present. Unfortunately I can't show the project, and there's not a particularly easy way of simplifying it into a small example either (I realise this makes help more difficult).

In response to Darryl:

• We don't use SpringIDE.
• We're using "use workspace metadata" as the deployment option and the deploy folder looks like: C:\dev\workspace\eclipse\workspace_name\.metadata\.plugins\org.jboss.ide.eclipse.as.core\JBoss_Enterprise_Application_Platform_5.x1418180089644\deploy
• The actual local server deploy folder resides at C:\local_server\deploy\app\ and this contains the pre-built config jars etc for the application
• In terms of the dependencies, the idea is to have a minimal set of projects open (for the code that I am working on) and the rest should come from the corporate repository. The core project is open, and I see the jar produced for core in the lib/ folder, but nothing else - ie all the jars that I would expect to be brought in via maven at deploy time in Eclipse.

As an experiment, I will try closing the core project and simply working with the ear project itself, and see if even the core jar disappears from lib/ under these circumstances...

[meacod]

...and just to follow up on my experiment, closing the core project took away the core jar.

Seems that the lib/ folder is only containing the jars of those projects that I have open inside Eclipse. So even when I have Maven dependencies/snapshots updated deploying to the server using workspace metadata isn't pulling in anything from the Maven repository and sticking it into that lib folder

[meacod]

So... here's an interesting development, I found the missing .jar files... and they're all inside the JBoss installation's directory (sort of)

Remembering the Eclipse server instance is using workspace metadata going here: C:\dev\workspace\eclipse\workspace_name\.metadata\.plugins\org.jboss.ide.eclipse.as.core\JBoss_Enterprise_Application_Platform_5.x1418180089644\deploy

And the JBoss install resides here: C:\local_server\deploy\app\

My 'missing' jars all show up here: C:\local_server\Applications\JBoss\jboss-eap-5.2\jboss-as\server\app\tmp\vfs-nested.tmp

Anyone have some input on why this might be? I thought this was a temp directory for JBoss, I've no idea how these jars end up in there but not the actual server deployment...

[rob.stryker]

The only thing I can confirm here is that we do not ever copy files to that folder.  We may have at some time copied files to the tmp folder, but certainly not the tmp/vfs-nested.tmp folder.   I am very surprised any missing files are showing up there, since that would mean the server somehow gained access to them and copied them there itself.  But since they're missing in the metadata location, well... I have no idea. I've never heard of anything like this.

[meacod]

Thanks Rob. In my search I've come across items like this: http://stackoverflow.com/questions/3112271/huge-amount-of-jar-files-in-jboss-server-web-tmp-vfs-nested-tmp-directory that seem to imply others find things stacking up in that folder too (although they're concerned more with wasted space, whereas I'm worried about the lib/ never getting populated.)

I've replicated the problem inside Eclipse Kepler too.

Are you able to expand on what /tmp (and more specifically, vfs-nested.tmp) are there to do?

[dlmiles]

Do not worry about files inside the JBoss tmp/** directory, this is probably being done to stop JAR locking from occurring on windows.  This is where the Windows operating system will not allow you to delete a file if there is a progress on the system with an open file handle (this claim is not completely true the Windows API does have a flag to the open file system call, but it is not set by default and most programs don't use it).  So the JBoss AS copies the JARs to the tmp/** folder and loads the JAR that is used to deploy from there.  This frees the deployment folder location from JAR locking issues, allowing IDE to make direct modifications.

Yes this is an issue for developers who might make a lot of deployments over a week/month and there should not be a problem in simply cleaning the tmp/** location while the AS is shutdown, presuming you don't have any important persistent data being kept there.

What I am interested in is the Eclipse location C:\dev\workspace\eclipse\workspace_name\.metadata\.plugins\org.jboss.ide.eclipse.as.core\JBoss_Enterprise_Application_Platform_5.x1418180089644\deploy and similar.

So the lead on from this, do you find a JAR in the above path that ends up missing from the.

I would agree with your findings so far.  That is the EAR lib/ folder is missing JARs that using Maven from command line (or from Eclipse Maven launcher) would build an EAR that is populated correctly.  I would also agree that this seems to be the transient JARs that are missing.

So the next question, can a JBoss IDE developer use the EAR functionality to cause the layout of the deployment location exploded EAR to include the transient Maven dependencies ?  If so what steps should be taken to observe this.  I can try to re-create it, then try to establish what differences cause it to fail.

David Meacock can you confirm the various project you have have the Eclipse Project Facets set accordingly ?   Right click top node of project, Configuration -> Project Facets.  In particular the EAR, any WARs (Dynamic Web Projects), any standard JARs (Utility Project), any EJB, etc...

[meacod]

So there's four projects in my current workspace.

One is simply a maven parent project, no facets.

The next is our app; it has the EAR facet version 1.4

Then there's the core project; it has both the Java (1.6) and Utility Module facets

Finally there's the test project, and it does not have facets configured.