Community
Participate
Working Groups
We are beginning to add tooling support for DBWS in Dali. For that the Dali jpt.dbws.eclipselink.core.gen bundle is depending on persistence.dbws.builder, which depends on persistence.core. It appears that the persistence.core bundle is referencing back to persistence.dbws.builder which creates the following error in the Webtools releng.wtpbuilder: ... The following error occurred while executing this line: 741869 [build-wtp-dali-sdk] /opt/public/webtools/basebuilders/R37_M4/org.eclipse.releng.basebuilder/plugins/org.eclipse.pde.build_3.6.100.v20101122/scripts/genericTargets.xml:107: A cycle was detected when generating the classpath org.eclipse.jpt.dbws.eclipselink.core.gen_1.0.0.v201102020000, org.eclipse.persistence.dbws.builder_2.3.0.v20110129-r8902, org.eclipse.persistence.core_2.3.0.v20110129-r8902, org.eclipse.persistence.dbws.builder_2.3.0.v20110129-r8902. ...
Created attachment 188205 [details] Full WTP Build log
Created attachment 188206 [details] Dependency Analysis in PDE
My guess is that this has something to do with the imported packages, which are known to be problematic for creating these types of cycles. The core bundle must be pulling dependencies from dbws.builder. The core is probably doing this because the dbws.builder bundle is re-exporting all of its dependencies, which re-export all of their dependencies, and so-on, down the tree. I'm guessing this may be the root issue, but I am not 100% sure. Generally speaking it is considered safer to not re-export dependencies, and perhaps this is one of the reasons why. The good news is that we may be able to build even with this cycle do to a flag in the build that will allow building to continue when cycles are detected in bundles. As a result this may not be a blocker, but it is something that should be addressed for Indigo. Changing severity to major for now.
I spoke with Mike about this, and we decided to try to test the re-export theory on one of my Indigo M4 workspaces that reported circular dependencies. Removing the re-exportsdid nothing to resolve the circular refences that were being reported. Removing the builder project from the workspace resolved them. However we ould find no common references in manifest or code. Finally, we decided to remove core's export of xsd. That resolved the circular dependency issues, with builder still in the workspace. The thing is most EclipseLink bundles export their xsds in a xsd "package" which technically violates the split-package rule, but didn't cause any side-effects til now. I don't know the full ramifications of changing this, but we could change the location of xsds per bundle, or only export them all from one bundle. If code changes are involved, this will also effect the layout of the EclipseLink jar, and possibly have other side-effects. We need to bring the other dev leads in on this. Given the oddities of PDE and the fact that this was found with an early milestone of Indigo, I'm still not convinced this is the 'real' issue. It'll need to be investigated further to isolate what exactly in the xsd could be causing a 'circular' reference. This may really be a bug with the IDE.
It looks like you have probably discovered the culprit with the xsd package, but I think it is the core bundle's importing of the xsd package that is the problem. I didn't notice that before, but I think you are creating the dependency from core to builder (and every bundle that exports xsd) by importing the xsd package on core. Is there a reason that core bundle needs to import the xsd package?
I'm not certain if there is any reason to import xsd by core or the other bundles. it may simply be a bug in the bnd file (missing -noimport flag), or I may have exluded the flag for a specific reason I don't recall. I'll check with Tom and Peter.
It looks like the core import of xsd is probably a bug. However, the bigger issue is the split package issue. I'm going to pull Blaise in on this issue, because the moxy, builder, and core bundles export "xsd". The correct solution seems to be setting up each bundle export a specific package, and make the necessary code changes: xsd/core, xsd/moxy, xsd/dbws/builder (or something like that). The imports should also be removed unless necessary (which I'm told it shouldn't be - if it is an xsd is in the wrong package).
Separating the xsds into component level packages seems like the right approach. In addition to the ones listed the JPA specific schemas should also be pulled into an xsd/jpa directory. Ideally this directory would live in the JPA component instead of the core component.
Created attachment 188445 [details] sear results for "xsd/" I've spoken with Tom. and he concurs with Blaise's position. Specifically jpa xsds should reside in their own package, and 'ideally' should be in the jpa component. He believes that there was areason that core needed it though, and it was put there to resolve a circular dependency. I've searched the code, and it appears that this is no longer the case (at least a search of "xsd/" in all trunk .java files resulted in only six code references to the xsd location; three in tests, two more in core and one in jpa. The jpa xsd is only referenced by jpa. The two references in core appear to be to reference the project schema, and the other is for the sessions schema. the search result is attached.
As a result, I propose the following: In the core: - eclipselink_orm_2_2.xsd is moved to 'xsd/jpa' and refence to it adjusted in org.eclipse.persistence.internal.jpa.metadata.xml.XMLEntityMappingsReader - the other xsds are moved to 'xsd/core' and references in org.eclipse.persistence.sessions.factories.XMLProjectReader and org.eclipse.persistence.sessions.factories.XMLSessionConfigLoader are also adjusted accordingly. In MOXy: - no code changes appear necessary, but all XSDs would move from 'xsd' to 'xsd/moxy' In DBWS Builder: - no code changes appear necessary but all XSDs would move from 'xsd' to 'xsd/dbws/builder' However, JPA is also including other xsds at: org\eclipse\persistence\jpa, so I'm wondering if that standard is a better one to follow. Thoughts?
In order to keep the bug in sync with the current discussion: -Neil suggested putting them in o.e.p.<component> or o.e.p.<component>.xsd -Mike N. voted for the later. -Tom pointed out that most libraries simply put them in the root of the component (mostly voting for o.e.p.<component>). specifically: o.e.p for core, o.e.p.jpa for jpa, o.e.p.jaxb for moxy, o.e.p.dbws.builder for the dbws builder tool. - Peter concurred, but pointed out that the jpa bundle in core would need to move. - Doug concurred. I've discovered that there are also dbws XSDs, and o.e.p.dbws.builder is not an existent package. I'm going to talk to Mike N. about it because o.e.p.tools.dbws may be too generic, but sent out the following email to the thread: To recap, the current plan under consideration is: - move core XSDs to org.eclipse.persistence - move the jpa XSD (eclipselink_orm_2_2.xsd) from core to jpa under org.eclipse.persistence.jpa - move moxy XSDs to org.eclipse.persistence.jaxb - move dbws XSDs to org.eclipse.persistence.dbws - move builder XSDs to org.eclipse.persistence.tools.dbws (o.e.p.dbws.builder is not an existent package). (the fragments and sdo do not have any).
Created attachment 188716 [details] Patchfile for fix. 336179: Fix circular dependency between core/builder by removing split packages for "xsd" in bundles: - Copy xsd files to o.e.p.<component> in resource dir of bundles. - o.e.p (core) - o.e.p.jpa (copy jpa xsd from core to this loc in jpa) - o.e.p.jaxb (moxy) - o.e.p.dbws - o.e.p.tools.dbws - move XSDs to o.e.p.<component> in bundles and eclipselink.jar (bnd and build changes) - alter effected code (6 java files: 2 core, 1 jpa, 3 moxy.test) - update bnd and build files - add missing manifest for dbws.builder project Transaction passed Tom's review, and SRG. LRG passed Edwin's review of 4 errors (4 he believes they are unrelated and recommended merge). I will be merging an additional transaction that removes the old xsd location from the repository tomorrow (after a successful nightly build). Unchanged: commonj.sdo still has xsd files in a xsd location. I need to consult with Blaise before considering a change. Since that is the only location, the split xsd package issue has been resolved (At least within the EclipseLink project).
The patch has been merged. Will remove the old Xsd locations tomorrow am.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
