[Cary Clark]

I’ve just updated to
Version: CI 2018.8.0
Build id: 16.0.0-20180802

I have a project that has a bunch of Hibernate-based mapping files, domain & value objects, and DAO’s in it. After the workspace migration, I cleaned the project and get the dialog shown in attachment Build-Error-2018-02-21.png and this error in the .log file when I try to build:

java.lang.IllegalStateException: There should be no remaining edge at this point.
at org.eclipse.core.internal.resources.ComputeProjectOrder.buildFilteredDigraph(ComputeProjectOrder.java:722)
at org.eclipse.core.internal.resources.Workspace.computeProjectBuildConfigOrderGraph(Workspace.java:978)
at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:484)
at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:408)
at org.eclipse.ui.actions.BuildAction$1.runInWorkspace(BuildAction.java:288)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:39)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:60)

The forums and Google have nothing.

Any suggestions?

Thanks,
Cary

• This topic was modified 6 years, 2 months ago by Cary Clark.

Attachments:

You must be logged in to view attached files.

[support-swapna]

Cary,

Thank you for updating to MyEclipse 2018. Sorry that you are seeing this issue.
I tried to replicate the problem with a Hibernate project created in MyEclipse 2017 but do not see any problems with the build.

1. Can you please share with us more details about the project, Hibernate version, MyEclipse version in which it is created ?
2. When you opened the workspace in MyEclipse 2018, is the migration suggested for the project in question? Did you see any errors during migration? If you can remember, what exact changes did you make to the project to successfully migrate it?
3. Please share with us the complete .log file by clicking on the ‘Export Log’ icon in the Error Log view to help us get full details of the errors logged.
4. If possible, please also share with us the zipped project files to help us replicate the problem at our end. If you have concerns sharing the source code with us, then please strip the source code and send us all the .* files (.settings folder, .classpath, .project etc) and configuration files.

Apologies for inconvenience caused.

–Swapna
Genuitec Support

[Cary Clark]

This project was created years and years ago. It was being built in, IIRC, ME 2010 when I came around in 2014. We’ve moved through the newer versions: 2015, 2016, 2017 CI, and now 2018 CI.

Facets:
=======

• EJB 3.1
• Hibernate 4.1
• Java 1.7
• Spring 4.1 – Though I don’t understand why ME INSISTS on making it a Spring project. It’s not. I’ve removed everything that I can find in the .settings files and .project that are Spring related.

This project was migrated without issue. I had to recreate some app server definitions because it didn’t see the one I had, for whatever reason. Once I did that, the project migrated.

I’ve attached a slimmed down project that was created by copying the problematic one and removing most of the source code. The same error is exhibited. I’ve also attached a copy of .log from a clean startup until the error.

Attachments:

You must be logged in to view attached files.

[Brian Fernandes]

Cary,

Thank you for taking the time to put together a reduced project; unfortunately, I could not reproduce the error after importing it. There are a number of user containers that are referenced which we don’t have (so I removed these entries), but I suspect the build issue may be caused by the project stafftrack_utility that the current project references.

1) To figure out why the Spring facet is being added, could you send us a similar reduced project before it is migrated? For instance, I can see a .springBeans file in your project which could result in the Spring facet addition – but I do not know if that was added by the migration process, or whether it was already present.

2) I’m assuming every time you try to build stafftrack_data_access_genuitec you get the error you mentioned in your first post, correct? Can you go to the Project Properties > Java Build Path > Projects tab and remove the reference to this project?

If this prevents the error from showing up, we can proceed with further investigation in that direction. Was that project migrated as well?

[Cary Clark]

Well, I introduced the problem in stafftrack_data_access_genuitec by adding stafftrack_utility when I first cloned it just to get the classes to compile. I should have removed it when I whacked all of them except EntityManagerProducer.java. Once I removed it, the build error disappears. Not surprisingly, the real project needs those classes. But, they are not referenced via a Project Properties > Java Build Path > Projects entry.

The real stafftrack_data_access and stafftrack_utility are part of stafftrack_ear:

stafftrack_ear
    |
     -lib
       |
       stafftrack_utility
    |
    stafftrack_data_access
    ...
    other ejb jar's
    and some war's
    ...

I did a lot of sleuthing:

• Filesystem level cloned stafftrack_utility into stafftrack_utility_genuitec
• Changed stafftrack_utility_genuitec’s .profile project name accordingly
• Since it’s not part of the EAR, I added necessary jar’s to stafftrack_utility_genuitec’s Project Properties > Java Build Path > Libraries list and removed the EAR Libraries entry to get a clean compile
• Changed stafftrack_data_access_genuitec’s Project Properties > Java Build Path > Projects from stafftrack_utility to stafftrack_utility_genuitec

The build error no longer occurred; stafftrack_data_access_genuitec built fine. I determined that the difference between stafftrack_utility_genuitec which allowed a build and stafftrack_utility which could not build is the memberhsip in stafftrack_ear. To test this, I went to stafftrack_ear’s Project Properties > Deployment > Deployment Assembly and added stafftrack_utility_genuitec via Add > Project. I left the default deploy into lib/stafftrack_utility_genuitec.jar. This added that Project Reference to stafftrack_utility_genuitec. The build of stafftrack_data_access_genuitec failed. Quick removal of it from stafftrack_ear’s Deployment Assembly allowed stafftrack_data_access_genuitec to build again.

So, somewhere along the chain of resolving things, stafftrack_utility.jar in stafftrack_ear/lib is making something lose its mind.

FWIW, stafftrack_utility is a plain java project. It’s not JPA, EJB, dynamic web, Spring…nothing. As its name implies, it’s just a bunch of misc utility classes. It has the Java and Utility Module Project Natures checked.

• This reply was modified 6 years, 2 months ago by Cary Clark. Reason: trying to correct EAR layout formatting

[Brian Fernandes]

Cary,

Thank you for the detailed notes. We’ve tried to reproduce this as closely as possible with the information you’ve provided, EAR membership and all, but unfortunately we’ve had no luck reproducing this problem. I believe the deployment assembly mechanism is working as expecting, adding the references it deems required.

Are you able to ascertain that both the deployment assembly, and the project references across the projects involved were the same in the previous version of MyEclipse as well? If you could spot a difference that might give us some clues about what is going on.

I can think of two options going forward:
1) Give us a bunch of dummy projects which exhibit the problem – given that we’ve been unable to reproduce with what you’ve already provided, we’ll probably need all 3 projects, without missing references. Might help if you import them into a new workspace and reproduce the problem before sending them on.

2) We can schedule a meeting next week where we can attempt to figure this out live, with the actual projects in your workspace.

Do let us know what you would prefer, hope we’re able to figure this out in short order!

[Cary Clark]

I’ve stripped down 2 projects – stafftrack_data_access_genuitec and stafftrack_utility_genuitec – and attached them in StafftrackGenuitecProjects-2018-08-29.zip. All the metadata files are as their real counterparts. I have removed all the real classes; each only contains HelloME2018. I removed all the build path library containers from both projects.

stafftrack_utility_genuitec has no build path project containers and compiles fine on my machine. The only build path library that stafftrack_data_access_genuitec is to stafftrack_utility_genuitec. It has the same error of “java.lang.IllegalStateException: There should be no remaining edge at this point.” with that in place. With stafftrack_utility_genuitec removed as a build path project, it compiles fine. The fact that there is no actual dependency doesn’t seem to affect things.

I’ll be off for the rest of the week as well as Monday and Tuesday of next week.

Thanks,
Cary

Attachments:

You must be logged in to view attached files.

[Brian Fernandes]

Cary,

Perhaps unsurprising at this point, but we were still unable to replicate these issues even when using exactly the same projects you attached. We did add the EAR project, which was not in your archive though.

We’ve been seeing a few compilation issues reported due to the fact that MyEclipse itself is running with Java 10, issues which have been fixed by changing the IDE to use Java 8 as it did before. Do you mind trying this and let us know if it works? Please see this post for details on changing to Java 8: https://www.genuitec.com/forums/topic/errors-running-builder-java-builder-2/#post-597365

[Cary Clark]

I’ve switched it to use JDK 1.8 but the error still exists.

I did not include any EAR in my build of the 2 *_genuitec projects. I only built stafftrack_utility_genuitec and had specify that as a dependency.

I have also created a completely fresh workspace, added my app server and JRE, and imported the projects into it with the same resulting error.

[Cary Clark]

Given the Eclipse core nature of this stacktrace, I opened Bug 538752 in the Eclipse Bugzilla.

[Cary Clark]

Bug 538752 has been fixed @ Eclipse. Unfortunately, it’s not slotted for general release until 4.10. Given that ME just went up to 4.8, is there any strategic decision at this time of when you’ll move ME up? I know it’s a constant game of keep-up.

Thanks,
Cary

• This reply was modified 6 years ago by Cary Clark.

[support-swapna]

Cary,

Thank you for the update. One of the dev team members will get back to you about the MyEclipse migration schedule.

Thank you for your patience.

–Swapna
Genuitec Support

[Author]

Posts