[Scott Hamilton]

Hi there!

We upgraded recently from MyEclipse 9.1 to 10.6. Everything seems to be working for us but one feature seems no longer to be present that worked great in 9.x.

Before when we made a change to a pom, or if a pom changed through an update from our code repository, MyEclipse and Maven4MyEclipse seemed to detect this and automatically it would update the dependencies for the project, so the dependency changes would immediately show up in the maven classpath.

NOW, after the upgrade to 10.6, this no longer happens unless I force Maven4MyEclipse to update the dependencies, e.g. by right-clicking on the project whose pom I know changed and selecting Maven4MyEclipse -> Update Dependencies.

I’m hoping this is just a configuration somewhere that I missed where we can turn this back on?

Below is the MyEclipse installation configuration details, if that helps.

Thanks!

*** Date:
Tuesday, October 2, 2012 9:00:46 AM EDT

*** System properties:
OS=Windows7
OS version=6.1.0
OS arch=amd64
Profile arch=x86_64
Window system=win32
Java version=1.7.0_07
Workspace=file:/R:/src/b1210/
VM Args=-Dosgi.nls.warnings=ignore
-XX:MaxPermSize=768m
-XX:ReservedCodeCacheSize=128m
-Xmx3g
-Djava.class.path=R:\bin\myeclipse-10\../genuitec-common/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar

*** Subscription information
Product Id: E3MP (MyEclipse Professional Subscription)
License version: 3.0
Full Maintenance Included
Subscription expiration date (YYYYMMDD): 20130525
Number of users: 50

*** Eclipse details:
MyEclipse Enterprise Workbench

Version: 10.6
Build id: 10.6-20120727

Blueprint: MyEclipse 10

com.genuitec.myeclipse.database – 10.6.0.me201207261914
com.genuitec.myeclipse.desktop – 10.6.0.me201207261914
com.genuitec.myeclipse.editor – 10.6.0.me201207261914
com.genuitec.myeclipse.enterprise.workbench – 10.6.0.me201207261914
com.genuitec.myeclipse.jboss – 10.6.0.me201207261914
com.genuitec.myeclipse.jsf – 10.6.0.me201207261914
com.genuitec.myeclipse.maven – 10.6.0.me201207261914
com.genuitec.myeclipse.persistence – 10.6.0.me201207261914
com.genuitec.myeclipse.pulse – 10.6.0.me201207261914
com.genuitec.myeclipse.struts – 10.6.0.me201207261914
com.genuitec.myeclipse.tomcat – 10.6.0.me201207261914
com.genuitec.myeclipse.visualvm – 10.6.0.me201207261914
com.genuitec.myeclipse.visualvm.server – 10.6.0.me201207261914
org.eclipse.datatools.connectivity.feature – 1.9.0.me201207261914
org.eclipse.datatools.enablement.feature – 1.9.0.me201207261914
org.eclipse.datatools.modelbase.feature – 1.9.0.v201106031100-77078CcNBHCBYKYEbNV
org.eclipse.datatools.sqldevtools.feature – 1.9.0.me201207261914
org.eclipse.emf – 2.7.0.v20110606-0949
org.eclipse.gef – 3.7.0.v20110425-2050-777D-81B2Bz0685C3A6E34272
org.eclipse.graphiti.feature – 0.8.0.v20110607-1252
org.eclipse.jpt.jpa.feature – 3.0.0.me201207261914
org.eclipse.jpt.jpadiagrameditor.feature – 1.0.0.me201207261914
org.eclipse.jst.common.fproj.enablement.jdt – 3.3.0.me201207261914
org.eclipse.jst.enterprise_ui.feature – 3.3.0.me201207261914
org.eclipse.jst.server_adapters.ext.feature – 3.3.0.me201207261914
org.eclipse.jst.server_adapters.feature – 3.2.100.me201207261914
org.eclipse.jst.server_ui.feature – 3.3.0.me201207261914
org.eclipse.jst.ws.axis2tools.feature – 1.1.200.me201207261914
org.eclipse.m2e.feature – 1.0.0.me201207261914
org.eclipse.sapphire.platform – 0.3.0.201106221325
org.eclipse.wst.common.fproj – 3.3.0.me201207261914
org.eclipse.wst.server_adapters.feature – 3.2.100.me201207261914
org.eclipse.xsd – 2.7.0.v20110606-0949
org.springframework.ide.eclipse.feature – 2.9.1.me201207261914

biz.junginger.ExploreFS_Feature – 1.0.0
com.plateau.devtools.feature.CodeReviewsManager – 2.0.3
com.versionone.v1.feature – 2.0.0
com.yourkit.profiler – 9.5.6.9540
edu.umd.cs.findbugs.plugin.eclipse – 2.0.0.20120807
jetbrains.teamcity.feature – 7.1.0.23978
jetbrains.teamcity.feature.codequality – 7.1.0.23978
net.sf.eclipsecs – 5.5.0.201111092104
net.sf.jautodoc.feature – 1.10.0
org.apache.ivy.feature – 2.3.0.cr120120416000235
org.apache.ivyde.feature – 2.2.0.beta1-201203282058-RELEASE
org.eclipse.cvs – 1.3.100.v20110520-0800-7B78FHl9VF7BD7KBM4GP9C
org.eclipse.draw2d – 3.7.0.v20110425-2050-46-7w3122153603161
org.eclipse.equinox.p2.core.feature – 1.0.1.v20110906-1605-8290FZ9FVKHVRKtmx3fpNuo02129
org.eclipse.equinox.p2.extras.feature – 1.0.1.v20110906-1605-7A4FD4DiVOMap8cHSc6vPuny4gqO
org.eclipse.equinox.p2.rcp.feature – 1.0.1.v20110906-1605-782EqBqNKGVkiV-PUsgz-uny4gqO
org.eclipse.equinox.p2.user.ui – 2.1.2.R37x_v20110815-1155-6-Bk8pYWZz0qUTX5I15GZWwbXkrl
org.eclipse.help – 1.3.0.v20110530-0844-7i7uFFmFFl8nvqbDpEqTvx
org.eclipse.jdt – 3.7.2.v20120120-1414-7z8gFcuFMP7BW5XTz0jLTnz0l9B1
org.eclipse.jsf.feature – 3.3.0.me201207261914
org.eclipse.pde – 3.7.2.v20120120-1420-7b7rFUOFEx2Xnqafnpz0E–0
org.eclipse.platform – 3.7.2.v20120207-1839-9gF7UHPDFxGjd-PqDr2jX_4yKaumkoHTz04_q-q
org.eclipse.rcp – 3.7.2.v20120120-1424-9DB5FmnFq5JCf1UA38R-kz0S0272
org.testng.eclipse – 6.7.0.20120825_1316
org.tigris.jira – 0.9.2
org.tigris.jira.core – 0.9.2
org.tigris.subversion.clientadapter.feature – 1.8.1
org.tigris.subversion.clientadapter.javahl.feature – 1.7.3
org.tigris.subversion.subclipse – 1.8.5

Eclipse startup command=-os
win32
-ws
win32
-arch
x86_64
-showsplash
-launcher
R:\bin\myeclipse-10\myeclipse.exe
-name
Myeclipse
–launcher.library
R:\bin\myeclipse-10\../genuitec-common/plugins/org.eclipse.equinox.launcher.i18n.win32.win32.x86_64_4.2.0.v201201111650\eclipse_4201.dll
-startup
R:\bin\myeclipse-10\../genuitec-common/plugins/org.eclipse.equinox.launcher_1.2.0.v20110502.jar
-install
R:\bin\myeclipse-10
-showlocation
-configuration
R:\bin\myeclipse-10\configuration
-vm
R:\bin\jdk1.7.0_07.64\bin\..\jre\bin\server\jvm.dll

[Brian Fernandes]

Scott,

In MyEclipse 10, the Maven tooling changed such that an upgrade process was required to convert older projects. Either you refused to upgrade (which should have been automatically offered) or some bug in the upgrade process prevented your project from being correctly upgraded. As a result, I believe your project may have an older builder which was responsible for the behavior you describe, but it is now defunct in MyEclipse 10.

a) Could you tell me if you were offered the upgrade and applied it?

b) Can you go to “MyEclipse > Upgrade Projects for MyEclipse 9 and above …” and see if you are offered an upgrade for the project in question? If yes, please go ahead and update the project, this should fix the problem.

c) If you still experience the issue, can you please paste the .project file of your project here? I’ll let you know what change must be made.

[Scott Hamilton]

Indeed, that seemed to be the trick. We had been still transitioning between ME9 and ME10 and I had manually rigged the .project files so that both environments would function during this transition period. Thus we had both the old and new maven natures, but no maven project builders. (In ME9, these were not necessary and added overhead to our build process, so we left them out. We’ll re-evaluate their impact once we complete our ME10 transition.)

So to summarize, it looks like the ABSENCE of the maven builder in the .project file is what causes this. If I add this back in (which the project upgrade does automatically), changes to the pom automatically affect the maven classpath builder.

Thanks for the help!
Scott

[Scott Hamilton]

Actually, this raises a question in my mind… So our projects are maven-based in the sense that we use the maven classpath container, but we use MyEclipse’s JDT compiler so that we ensure we get the JDT warnings. We also use FindBugs plugin.

IF we re-import these projects as pure maven projects, MyEclipse constructs its project such that it will not use the java builder, but just the maven builder. This doesn’t work for us for the reasons above plus MyEclipse won’t seem to recognize these files as Java and display in the IDE the errors and warnings from the file.

If I have both the java builder (with the .classpath necessary) and the maven builder, things SEEM to be working as they should.

My question, however, is whether this will result in the maven builder doing a redundant compile of the class files, duplicating what the java builder is doing with JDT?

[Brian Fernandes]

Scott,

Thanks for reporting back. Glad to know that the upgrade process was doing the right thing and you’re all fixed up.

[Brian Fernandes]

Scott,

I missed your second response as it appeared while I was keying in my earlier response.

IF we re-import these projects as pure maven projects, MyEclipse constructs its project such that it will not use the java builder, but just the maven builder.

There is a special wizard that allows you to import pure maven projects (by pure, I mean projects which have nothing to do with Eclipse at all – no .project or .classpath files). I’m assuming you are using this wizard, please correct me if I’m wrong (File > Import > Maven4MyEclipse > Existing Maven Projects). This process should definitley add the Java builder and all Java settings required. Based on your pom.xml, source folders will be marked as source folders to be recognized by the JDT. Could you confirm how you are importing the project?

To answer your question on the Maven builder – the function of the Maven builder in Eclipse is to keep the Eclipse configuration in synch with your Maven / pom.xml configuration. So we’re talking about making sure dependencies that you add are added to the Maven classpath container in Eclipse or source folders are correctly recognized, etc. – it isn’t really the Maven runtime and will not result in an additional compile.

Hope this helps, let me know if you have further questions.

[Scott Hamilton]

Very helpful, thanks.

We did notice that the maven builder also affects how resources are copied. For instance if you have files under src/main/resources, those are copied into target/classes apparently through the maven builder. I am concluding this based on 2 things: when setting up a maven project, the default src path to the resources has an excludes=”**”, presumably to tell Eclipse not to copy files from there into the output folder, and then second, if the pom.xml has a <resources> section, this affects WHAT is copied and from where. We saw this take effect when adding the maven builder to our projects (and adding the exclude in the .classpath).

I think we’re in good shape now, however.

To answer your question about how we imported these projects, I don’t have a straightforward answer, as these projects “grew up” through eclipse and MyEclipse and along the way were mavenized. At that time, I do not believe that anyone started over with the project files, but “added in” the maven nature, builder and settings. It is likely that if we restarted from scratch to recreate the projects through this import that they would look differently.

I’ll try that with a couple of the projects and see what the differences really are.

[Author]

Posts