Comment 1 David Williams 2013-11-19 21:39:45 EST

Tom, any recent changes in Equinox? Seems like the "nightly" is past this point where I'm seeing the error ... so suspect not. 

Thanh, Jan, any tips on how to debug (or fix) this cyclic dependency? 

If it is caused by changes for 400518 (currently only in my local test repo) I'm assuming it is because the .target file introduces a certain "order" to the bundles that is not there when just giving the "whole site"? 

I'll see if I can find out which bundles from orbit 'services' and 'io' use ... and maybe reverse how ever currently listed?

Comment 2 David Williams 2013-11-19 22:22:34 EST

I don't see any obvious "cycles" in the two bundles mentioned. 

From manifest.mf, it's pretty obvious that org.eclipse.equinox.io requires packages from org.eclipse.osgi.services, but from 'services' nothing obvious requires org.eclipse.equinox.io. 

org.eclipse.osgi.services does have some optional dependencies on some orbit bundles, javax.servlet.http and javax.servlet ... but, can't imagine they'd have dependencies on equinox.io. 

So, I'm thinking something pretty subtle or ... perhaps a bug in Tycho?

Comment 3 David Williams 2013-11-19 22:27:15 EST

In my work for bug 400518, I followed the example that Jan pointed to in bug 400518 comment 10. But, I did deviate, based on the advise from Tobias in bug 400518 comment 12 to use includeMode="slicer" instead of includeMode="planner" as in the example. 

Perhaps I'll try "planner" ... might even have to read the doc :)

Comment 4 David Williams 2013-11-20 01:26:55 EST

Doc didn't help :( 
Didn't even mention "planner" vs. "slicer", but when I tried "planner" seemed even worse, the error would occur "quicker" and was similar to 

[ERROR] Cannot resolve project dependencies:
[ERROR]   Software being installed: javax.xml 1.3.4.v201005080400
[ERROR]   Missing requirement: javax.xml 1.3.4.v201005080400 requires 'bundle org.eclipse.osgi 0.0.0' but it could not be found

I will also note, then using "planner", the .target file would not load as a PDE Target file (in workbench IDE) but the file does load ok (as PDE target) when "slicer" specified. 

Since this error occurs in "pom update" ... I think I will try skipping that step of the build (for my local test) and see if error still occurs.

Comment 5 David Williams 2013-11-20 01:32:48 EST

Yep, same error during normal build section, not just pom update. 

[ERROR] The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='org.eclipse.osgi:org.eclipse.osgi.services:3.4.0-SNAPSHOT'}' and 'Vertex{label='org.eclipse.equinox:org.eclipse.equinox.io:1.1.0-SNAPSHOT'}' introduces to cycle in the graph org.eclipse.equinox:org.eclipse.equinox.io:1.1.0-SNAPSHOT --> org.eclipse.osgi:org.eclipse.osgi.services:3.4.0-SNAPSHOT --> org.eclipse.equinox:org.eclipse.equinox.io:1.1.0-SNAPSHOT -> [Help 1]
org.apache.maven.ProjectCycleException: The projects in the reactor contain a cyclic reference: Edge between 'Vertex{label='org.eclipse.osgi:org.eclipse.osgi.services:3.4.0-SNAPSHOT'}' and 'Vertex{label='org.eclipse.equinox:org.eclipse.equinox.io:1.1.0-SNAPSHOT'}' introduces to cycle in the graph org.eclipse.equinox:org.eclipse.equinox.io:1.1.0-SNAPSHOT --> org.eclipse.osgi:org.eclipse.osgi.services:3.4.0-SNAPSHOT --> org.eclipse.equinox:org.eclipse.equinox.io:1.1.0-SNAPSHOT
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:298)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:153)
        at org.apache.maven.cli.MavenCli.execute(MavenCli.java:555)
        at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:214)
        at org.apache.maven.cli.MavenCli.main(MavenCli.java:158)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.lang.reflect.Method.invoke(Method.java:606)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
        at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
        at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:414)
        at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:357)
Caused by: org.codehaus.plexus.util.dag.CycleDetectedException: Edge between 'Vertex{label='org.eclipse.osgi:org.eclipse.osgi.services:3.4.0-SNAPSHOT'}' and 'Vertex{label='org.eclipse.equinox:org.eclipse.equinox.io:1.1.0-SNAPSHOT'}' introduces to cycle in the graph org.eclipse.equinox:org.eclipse.equinox.io:1.1.0-SNAPSHOT --> org.eclipse.osgi:org.eclipse.osgi.services:3.4.0-SNAPSHOT --> org.eclipse.equinox:org.eclipse.equinox.io:1.1.0-SNAPSHOT
        at org.codehaus.plexus.util.dag.DAG.addEdge(DAG.java:143)
        at org.apache.maven.project.ProjectSorter.addEdge(ProjectSorter.java:219)
        at org.apache.maven.project.ProjectSorter.addEdge(ProjectSorter.java:184)
        at org.apache.maven.project.ProjectSorter.<init>(ProjectSorter.java:115)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:286)
        ... 12 more
[ERROR]
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/ProjectCycleException
/shared/eclipse/buildsdavidw/4I
exitcode was a legal, non-zero numeric return code
run-maven-build.sh exiting with exitrc: 1

Comment 6 David Williams 2013-11-20 02:14:53 EST

I think I see to "root" of this issue ... but not yet solution. 

org.eclipse.osgi.services "requires" javax.microedition.io in a p2.inf file (its optional, at runtime, but think Tycho considers all "optionals" as "required" at build time). 

And org.eclipse.equinox.io provides (exports) javax.microedition.io (and imports it ... in case its provided by VM, I presume). 

But org.eclipse.equinox.io requires various other things from org.eclipse.osgi.services, hence the cycle. 

And "easy" answer is if there is something from Orbit that provides this, that is not in my list, since we do not package/distribute it (my list was just formed empirically :) 

I'll attach current .target file, but I don't off-hand see anything in Orbit that provides javax.microedition.io .... might be something I don't have loaded?

Comment 7 David Williams 2013-11-20 02:17:10 EST

Created attachment 237570 [details]
current list of observed required orbit bundles

Comment 8 David Williams 2013-11-20 02:50:26 EST

I've satisfied my self that there is nothing "hidden" in Orbit that provides javax.microedition.io ... only org.eclipse.equinox.io does. 

I'm wondering if I've messed up "useBREE" resolution in my local test builds which would make all this invalid, if so.

Comment 9 Jan Sievers 2013-11-20 02:58:14 EST

(In reply to David Williams from comment #8)
> I've satisfied my self that there is nothing "hidden" in Orbit that provides
> javax.microedition.io ... only org.eclipse.equinox.io does. 
> 
> I'm wondering if I've messed up "useBREE" resolution in my local test builds
> which would make all this invalid, if so.

FWIW package javax.microedition.io is a system package provided by OSGi execution environments CDC-1.0/Foundation-1.0 , CDC-1.1/Foundation-1.1

So if you use one of the CDC profiles as BREE, the package should be provided by the system bundle

Comment 10 David Williams 2013-11-20 04:26:33 EST

(In reply to David Williams from comment #8)
> I've satisfied my self that there is nothing "hidden" in Orbit that provides
> javax.microedition.io ... only org.eclipse.equinox.io does. 
> 
> I'm wondering if I've messed up "useBREE" resolution in my local test builds
> which would make all this invalid, if so.

Thanks Jan, that's what led me to check my "useBREE" settings, but they all look right to me. Ironically, it's org.eclipse.equinox.io that specifies 
Bundle-RequiredExecutionEnvironment: OSGi/Minimum-1.0
(yet provides an implementation of javax.microedition.io

But, that bundle requires org.eclipse.osgi.services which specifies 
Bundle-RequiredExecutionEnvironment: J2SE-1.5
and I doubt it can be easily lowered to OSGi/Minimum-1.0?

Seems like a true cycle, and not sure why it doesn't show up if "whole repositories" used and why it shows up if specific bundles specified via target files.  

On Wednesday (well, my Wednesday work day :) I will prepare full "patch" so others can see whole picture and see if I'm make an error ... 

(And we can try a test build on build.eclipse.org, but pretty sure my local system is representative.)
 
Tom, any chance the cycle is a "mistake" in the p2.inf file of org.eclipse.osgi.services and javax.microedition.io is no longer an optional requirement? 

If I comment out that part of the p2.inf file, things resolve without cycle: 

#requires.2.namespace = java.package
#requires.2.name = javax.microedition.io
#requires.2.greedy = false
#requires.2.optional = true

Comment 11 David Williams 2013-11-20 04:51:25 EST

FYI, I attached "orbit-prereqs" target artifact and associated changes to bug 400518. 

I think if I "activate it", it will cause this bug ... so will wait for some review and comments here in this bug.

Comment 12 Thomas Watson 2013-11-20 08:31:52 EST

(In reply to David Williams from comment #10)
> Tom, any chance the cycle is a "mistake" in the p2.inf file of
> org.eclipse.osgi.services and javax.microedition.io is no longer an optional
> requirement? 
> 
> If I comment out that part of the p2.inf file, things resolve without cycle: 
> 
> #requires.2.namespace = java.package
> #requires.2.name = javax.microedition.io
> #requires.2.greedy = false
> #requires.2.optional = true

Yes that is a mistake that should have been removed when I moved the org.osgi.service.io package over to org.eclipse.equinox.io in bug 411404.

I removed the lines from p2.inf in:

http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/?id=5463b7b97865f939bf367ae27db18d1f02aa131a

Comment 13 Thomas Watson 2013-11-20 08:37:19 EST

(In reply to David Williams from comment #10)
> Thanks Jan, that's what led me to check my "useBREE" settings, but they all
> look right to me. Ironically, it's org.eclipse.equinox.io that specifies 
> Bundle-RequiredExecutionEnvironment: OSGi/Minimum-1.0
> (yet provides an implementation of javax.microedition.io

It also imports javax.microedition.io this is so it can run on VMs that do not have the package (non ME VMs).

> 
> But, that bundle requires org.eclipse.osgi.services which specifies 
> Bundle-RequiredExecutionEnvironment: J2SE-1.5
> and I doubt it can be easily lowered to OSGi/Minimum-1.0?

No idea why we would force org.eclipse.osgi.services down to OSGi/Minimum-1.0 just because some unrelated bundle happens to import some packages from it.  I guess this goes back to the other topic where tycho/cbi wants to force BREEs up the complete chain of dependencies (sigh).

Comment 14 David Williams 2013-11-20 09:28:56 EST

(In reply to Thomas Watson from comment #12)
> (In reply to David Williams from comment #10)
> > Tom, any chance the cycle is a "mistake" in the p2.inf file of
> > org.eclipse.osgi.services and javax.microedition.io is no longer an optional
> > requirement? 
> > 
> > If I comment out that part of the p2.inf file, things resolve without cycle: 
> > 
> > #requires.2.namespace = java.package
> > #requires.2.name = javax.microedition.io
> > #requires.2.greedy = false
> > #requires.2.optional = true
> 
> Yes that is a mistake that should have been removed when I moved the
> org.osgi.service.io package over to org.eclipse.equinox.io in bug 411404.
> 
> I removed the lines from p2.inf in:
> 
> http://git.eclipse.org/c/equinox/rt.equinox.framework.git/commit/
> ?id=5463b7b97865f939bf367ae27db18d1f02aa131a

Well, that was easy, after working on this for days and staying up most the night! 

Guess there are "hidden" advantages to tighting our pre-reqs ... besides this one, I've also found two other, less serious ones, in doing this work: bug 422101 and bug 422102. 



> > But, that bundle requires org.eclipse.osgi.services which specifies 
> > Bundle-RequiredExecutionEnvironment: J2SE-1.5
> > and I doubt it can be easily lowered to OSGi/Minimum-1.0?
> 
> No idea why we would force org.eclipse.osgi.services down to
> OSGi/Minimum-1.0 just because some unrelated bundle happens to import some
> packages from it.  I guess this goes back to the other topic where tycho/cbi
> wants to force BREEs up the complete chain of dependencies (sigh).

To be clear, this should be fine with the "requires" removed from p2.inf ... it was only if the bundle really did (optionally) require javax.microedition.io that there would have been any need/benefit to "moving down" the BREE requirement. (i.e. not one of the problematic cases of Tycho thinking all bundles should be at same BREE level). 

In closing, I'll do a test build today, but believe this bug can be marked fixed, and the focus will return to bug 400518.

Comment 15 David Williams 2013-11-20 11:56:35 EST

Test build progressing well, so assuming all is well. First "unit tested" build will be tonight's N-build.