Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jukka Zitting wrote: Hi, On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor m...@schor.com wrote: With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? Sounds good. Is there a reason why you use a version range instead of one specific version? The original reason I think is to allow different versions of Eclipse to be used. But, since this provided, meaning that the jar is not included, but instead comes from the Eclipse environment in which the jar runs, I think it we could use just single versions. Nevertheless, coding a version range here serves to document that the intention is that the plugin should work within that version range. I tried the following: dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.2.9/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0-v3346/version Works scopeprovided/scope /dependency Can you please commit the updated versions ? Done. Thanks for the reminder :-). The main uimaj pom is updated to no longer include the alternative Eclipse repo - now only maven central repo and the incubator repositories are included. Just tried to build UIMA on a fresh machine over at a friends place, but it could not find various eclipse plugins. Does that has to do with that change ? I would guess so - I ran mvn dependency:tree on many of the ones I changed to insure it could still find things, but maybe I missed one or 2 - could you post details? No, I think uimaj-ep-debug failed, but I do not have more details, the cas editor also could not be build. If that does not help, I can try to reproduce the error on my machine and post detailed information. Jörn Well, now that I try again, everything is broken... It fails for me, too. I tried various things to fix this, and could get the basic uimaj-ep-debug plugin to find the one Eclipse component in the maven central repo that it depends on, but that plugin has lots of dependencies, and they cannot be found in the maven central repo. So I don't think we've gotten to the bottom of this issue. I'm going to revert back to using the alternate eclipse repo, and at least get things working again (I hope). Sorry for breaking the build - but something was hiding this breakage from me before. What do you think about explicitly excluding org.eclipse.equinox.app from the org.eclipse.core.runtime dependency ? It would then be declared like this: dependency groupIdorg.eclipse.core/groupId artifactIdruntime/artifactId version[3.3.0.0,4.0.0)/version scopeprovided/scope exclusions exclusion groupIdorg.eclipse.equinox/groupId artifactIdapp/artifactId /exclusion /exclusions /dependency Not that I would prefer this way, but maybe it is better than having a build which fails under certain circumstances. Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jukka Zitting wrote: Hi, On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor m...@schor.com wrote: With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? Sounds good. Is there a reason why you use a version range instead of one specific version? The original reason I think is to allow different versions of Eclipse to be used. But, since this provided, meaning that the jar is not included, but instead comes from the Eclipse environment in which the jar runs, I think it we could use just single versions. Nevertheless, coding a version range here serves to document that the intention is that the plugin should work within that version range. I tried the following: dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.2.9/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0-v3346/version Works scopeprovided/scope /dependency Can you please commit the updated versions ? Done. Thanks for the reminder :-). The main uimaj pom is updated to no longer include the alternative Eclipse repo - now only maven central repo and the incubator repositories are included. Just tried to build UIMA on a fresh machine over at a friends place, but it could not find various eclipse plugins. Does that has to do with that change ? I would guess so - I ran mvn dependency:tree on many of the ones I changed to insure it could still find things, but maybe I missed one or 2 - could you post details? No, I think uimaj-ep-debug failed, but I do not have more details, the cas editor also could not be build. If that does not help, I can try to reproduce the error on my machine and post detailed information. Jörn Well, now that I try again, everything is broken... It fails for me, too. I tried various things to fix this, and could get the basic uimaj-ep-debug plugin to find the one Eclipse component in the maven central repo that it depends on, but that plugin has lots of dependencies, and they cannot be found in the maven central repo. So I don't think we've gotten to the bottom of this issue. I'm going to revert back to using the alternate eclipse repo, and at least get things working again (I hope). Sorry for breaking the build - but something was hiding this breakage from me before. What do you think about explicitly excluding org.eclipse.equinox.app from the org.eclipse.core.runtime dependency ? It would then be declared like this: dependency groupIdorg.eclipse.core/groupId artifactIdruntime/artifactId version[3.3.0.0,4.0.0)/version scopeprovided/scope exclusions exclusion groupIdorg.eclipse.equinox/groupId artifactIdapp/artifactId /exclusion /exclusions /dependency Not that I would prefer this way, but maybe it is better than having a build which fails under certain circumstances. I tried this approach when I started yesterday to look into what happened with the build. I started with the uimaj-ep-debug - which includes just one dependency from Eclipse. So I could fix that one dependency using the trick of backing off a notch, but it, in turn, had 5 dependencies, each of which would need to be excluded. The org.eclipse.core.runtime in the main maven2 (central) repo has 7 dependencies, which would need to be excluded. So - although this would work, I think, it makes for very long POMs, all just to try and get around some issue with version comparisons. I would prefer to keep the POMs simpler. Are there any remaining issues with this re: building? Do you know of a circumstance where the approach we have now would fail to build? -Marshall Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Marshall Schor wrote: Jukka Zitting wrote: Hi, On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor m...@schor.com wrote: With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? Sounds good. Is there a reason why you use a version range instead of one specific version? The original reason I think is to allow different versions of Eclipse to be used. But, since this provided, meaning that the jar is not included, but instead comes from the Eclipse environment in which the jar runs, I think it we could use just single versions. Nevertheless, coding a version range here serves to document that the intention is that the plugin should work within that version range. I tried the following: dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.2.9/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0-v3346/version Works scopeprovided/scope /dependency Can you please commit the updated versions ? As said before the eclipse runtime provides all dependencies, so it does not matter against which we compile as long as it is the minimal supported version (3.3.0), otherwise APIs could be used which are not available in 3.3.0. Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Jörn Kottmann wrote: Marshall Schor wrote: Jukka Zitting wrote: Hi, On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor m...@schor.com wrote: With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? Sounds good. Is there a reason why you use a version range instead of one specific version? The original reason I think is to allow different versions of Eclipse to be used. But, since this provided, meaning that the jar is not included, but instead comes from the Eclipse environment in which the jar runs, I think it we could use just single versions. Nevertheless, coding a version range here serves to document that the intention is that the plugin should work within that version range. I tried the following: dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.2.9/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0-v3346/version Works scopeprovided/scope /dependency Can you please commit the updated versions ? Done. Thanks for the reminder :-). The main uimaj pom is updated to no longer include the alternative Eclipse repo - now only maven central repo and the incubator repositories are included. -Marshall As said before the eclipse runtime provides all dependencies, so it does not matter against which we compile as long as it is the minimal supported version (3.3.0), otherwise APIs could be used which are not available in 3.3.0. Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jukka Zitting wrote: Hi, On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor m...@schor.com wrote: With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? Sounds good. Is there a reason why you use a version range instead of one specific version? The original reason I think is to allow different versions of Eclipse to be used. But, since this provided, meaning that the jar is not included, but instead comes from the Eclipse environment in which the jar runs, I think it we could use just single versions. Nevertheless, coding a version range here serves to document that the intention is that the plugin should work within that version range. I tried the following: dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.2.9/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0-v3346/version Works scopeprovided/scope /dependency Can you please commit the updated versions ? Done. Thanks for the reminder :-). The main uimaj pom is updated to no longer include the alternative Eclipse repo - now only maven central repo and the incubator repositories are included. Just tried to build UIMA on a fresh machine over at a friends place, but it could not find various eclipse plugins. Does that has to do with that change ? Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jukka Zitting wrote: Hi, On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor m...@schor.com wrote: With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? Sounds good. Is there a reason why you use a version range instead of one specific version? The original reason I think is to allow different versions of Eclipse to be used. But, since this provided, meaning that the jar is not included, but instead comes from the Eclipse environment in which the jar runs, I think it we could use just single versions. Nevertheless, coding a version range here serves to document that the intention is that the plugin should work within that version range. I tried the following: dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.2.9/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0-v3346/version Works scopeprovided/scope /dependency Can you please commit the updated versions ? Done. Thanks for the reminder :-). The main uimaj pom is updated to no longer include the alternative Eclipse repo - now only maven central repo and the incubator repositories are included. Just tried to build UIMA on a fresh machine over at a friends place, but it could not find various eclipse plugins. Does that has to do with that change ? I would guess so - I ran mvn dependency:tree on many of the ones I changed to insure it could still find things, but maybe I missed one or 2 - could you post details? -Marshall Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: Jukka Zitting wrote: Hi, On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor m...@schor.com wrote: With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? Sounds good. Is there a reason why you use a version range instead of one specific version? The original reason I think is to allow different versions of Eclipse to be used. But, since this provided, meaning that the jar is not included, but instead comes from the Eclipse environment in which the jar runs, I think it we could use just single versions. Nevertheless, coding a version range here serves to document that the intention is that the plugin should work within that version range. I tried the following: dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.2.9/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0-v3346/version Works scopeprovided/scope /dependency Can you please commit the updated versions ? Done. Thanks for the reminder :-). The main uimaj pom is updated to no longer include the alternative Eclipse repo - now only maven central repo and the incubator repositories are included. Just tried to build UIMA on a fresh machine over at a friends place, but it could not find various eclipse plugins. Does that has to do with that change ? I would guess so - I ran mvn dependency:tree on many of the ones I changed to insure it could still find things, but maybe I missed one or 2 - could you post details? No, I think uimaj-ep-debug failed, but I do not have more details, the cas editor also could not be build. If that does not help, I can try to reproduce the error on my machine and post detailed information. Jörn Well, now that I try again, everything is broken... It fails for me, too. I tried various things to fix this, and could get the basic uimaj-ep-debug plugin to find the one Eclipse component in the maven central repo that it depends on, but that plugin has lots of dependencies, and they cannot be found in the maven central repo. So I don't think we've gotten to the bottom of this issue. I'm going to revert back to using the alternate eclipse repo, and at least get things working again (I hope). Sorry for breaking the build - but something was hiding this breakage from me before. -Marshall
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Jörn Kottmann wrote: Marshall Schor wrote: ... Marshall is there anything we can do to avoid this issue ? I learned another maven command-line thing that purges your local repository of just the things in a particular Pom. The command is: mvn dependency:purge-local-repository Maybe we can use another version of eclipse as dependency. I think this is definitely worth investigating. It's quite possible that later version of Eclipse jar uploading to the central maven repo have found a way around this. I also noticed that our eclipse plugins depend on different eclipse version, would it be an advantage to only depend on one ? I don't think there's any advantage. What happens I think, is that these jars are used to make the compile step work, but at runtime, these jars are all provided by the particular Eclipse environment. -Marshall Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Maybe we can use another version of eclipse as dependency. I think this is definitely worth investigating. It's quite possible that later version of Eclipse jar uploading to the central maven repo have found a way around this. We could update to eclipse 3.4. I also noticed that our eclipse plugins depend on different eclipse version, would it be an advantage to only depend on one ? I don't think there's any advantage. What happens I think, is that these jars are used to make the compile step work, but at runtime, these jars are all provided by the particular Eclipse environment. Yes, but maven downloads both versions of eclipse, using only one version makes the initial build faster. Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
I discovered a way around this. It basically involves coding around the maven version comparison issue. I tried it out on the cas-editor, and got it to work. Here's what's involved: In the POM, when you state a dependency: dependency groupIdorg.eclipse.core/groupId artifactIdresources/artifactId version[3.3.0,4.0.0)/version scopeprovided/scope /dependency it fails because what's in the repo is 3.3.0-vXXetc. To make this work, just change the dependency to one notch lower: dependency groupIdorg.eclipse.core/groupId artifactIdresources/artifactId version[3.2.9,4.0.0)/version scopeprovided/scope /dependency I did this and it *almost* worked - there was one other change needed: the dependency for SWT win32 support in the main repo has a different groupId/artifactId and needed to be changed to: dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version[3.2.9,4.0.0)/version scopeprovided/scope /dependency With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? -Marshall Marshall Schor wrote: Jörn Kottmann wrote: Marshall Schor wrote: ... Marshall is there anything we can do to avoid this issue ? I learned another maven command-line thing that purges your local repository of just the things in a particular Pom. The command is: mvn dependency:purge-local-repository Maybe we can use another version of eclipse as dependency. I think this is definitely worth investigating. It's quite possible that later version of Eclipse jar uploading to the central maven repo have found a way around this. I also noticed that our eclipse plugins depend on different eclipse version, would it be an advantage to only depend on one ? I don't think there's any advantage. What happens I think, is that these jars are used to make the compile step work, but at runtime, these jars are all provided by the particular Eclipse environment. -Marshall Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Jörn Kottmann wrote: Maybe we can use another version of eclipse as dependency. I think this is definitely worth investigating. It's quite possible that later version of Eclipse jar uploading to the central maven repo have found a way around this. We could update to eclipse 3.4. See my other note on another way around this. I don't think updating to 3.4 would help because I don't even see the 3.4 levels in the maven central repo. I also noticed that our eclipse plugins depend on different eclipse version, would it be an advantage to only depend on one ? I don't think there's any advantage. What happens I think, is that these jars are used to make the compile step work, but at runtime, these jars are all provided by the particular Eclipse environment. Yes, but maven downloads both versions of eclipse, using only one version makes the initial build faster. You're right - I hadn't thought of that :-).. So this is something I would be in favor of changing (at some point). -Marshall Jörn
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Hi, On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor m...@schor.com wrote: With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? Sounds good. Is there a reason why you use a version range instead of one specific version? Maven policy is pretty good at ensuring that a single released version never changes, but if you explicitly use a version range for a dependency, it's impossible to say for sure which version gets included in the build. BR, Jukka Zitting
Re: getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Jukka Zitting wrote: Hi, On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor m...@schor.com wrote: With this change, we can remove all references to a special Eclipse repository location. I'm in favor of this; what do others think? Sounds good. Is there a reason why you use a version range instead of one specific version? The original reason I think is to allow different versions of Eclipse to be used. But, since this provided, meaning that the jar is not included, but instead comes from the Eclipse environment in which the jar runs, I think it we could use just single versions. Nevertheless, coding a version range here serves to document that the intention is that the plugin should work within that version range. I tried the following: dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.2.9/version Fails scopeprovided/scope /dependency dependency groupIdorg.eclipse.swt.win32.win32/groupId artifactIdx86/artifactId version3.3.0-v3346/version Works scopeprovided/scope /dependency So, if we go with a fixed version number, it has to include the -XX part of the version in order to match. -- READ THIS NEXT PART ! -- Now, for the interesting part. Maven appears to have *partially* fixed this problem. If you type mvn dependency:tree for this project, you will see that maven is able to find/locate/download transitive dependencies. To do this it is locating these where the POMs for the components having the dependencies specify them using the [3.3.0,4.0.0) syntax. Here's an example. The uimaj-ep-cas-editor project depends on org.eclipse.jface:text and gets version 3.3.0-v20070606-0010 In maven central repo that pom http://repo1.maven.org/maven2/org/eclipse/jface/text/3.3.0-v20070606-0010/text-3.3.0-v20070606-0010.pom has a dependency on org.eclipse:text which is resolved to version 3.3.0-v20070606-0010, but which is specified as dependency groupIdorg.eclipse/groupId artifactIdtext/artifactId version[3.3.0,4.0.0)/version /dependency So - they've changed (fixed) the comparison in maven for *transitive* version specs, it seems. -Marshall Maven policy is pretty good at ensuring that a single released version never changes, but if you explicitly use a version range for a dependency, it's impossible to say for sure which version gets included in the build. BR, Jukka Zitting
getting to the bottom of maven problem building uimaj-ep-cas-editor: solution was to delete from the local .m2 repo some bad eclipse poms
Two users recently had the experience of trying for the first time to build the uimaj-ep-cas-editor project. They got errors that looked like: [INFO] Failed to resolve artifact. Couldn't find a version in [1.0.0-v20070423, 1.0.0-v20070606] to match range [1.0.0,2.0.0) org.eclipse.equinox:app:jar:null from the specified remote repositories: central (*http://repo1.maven.org/maven2*), ApacheIncubatorRepository (*http://people.apache.org/repo/m2-incubating-repository*), eclipsePlugins (*http://repo1.maven.org/eclipse http://repo2.maven.org/eclipse*) Path to dependency: 1) org.apache.uima:uimaj-ep-cas-editor:bundle:2.3.0.incubating-SNAPSHOT 2) org.eclipse.core:runtime:jar:3.3.100-v20070530 This is correct, because the POM downloaded from maven's central repo for the core.runtime jar of Eclipse specifies it depends on the app.jar version [1.0.0, 2.0.0). This, according to maven's versioning rules, truly makes no match for the versions in maven's central repo for this artifact, because maven's compare routines states that a.b.c- comes before a.b.c and therefore, the minimum required version: 1.0.0 is greater than the available versions: 1.0.0-v20070423 etc. It turns out that there are 2 versions of the Eclipse repo - and the other version has the right dependency information. The other repo is specified in our top level parent POM - it's http://repo1.maven.org/eclipse (the central maven repo is: http://repo1.maven.org/maven2 ) So, if someone uses maven in a way that references and downloads to their local repo Eclipse parts using the default central maven repo, they will get POMs that don't work for some purposes. If they later try and build the UIMA project, even though we have the repo specified in our uimaj/pom.xml parent pom, that doesn't do anything, because the (wrong) pom has already been downloaded from maven central. Of course, you can fix this by deleting the eclipse section of your local repository, forcing maven to download from the correct repo (using the uimaj parent POM spec for the repository). (I also checked the dates in case the fixed version was newer - but it's older...) -Marshall
