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> >>>>>>>> <groupId>org.eclipse.swt.win32.win32</groupId> >>>>>>>> <artifactId>x86</artifactId> >>>>>>>> <version>3.3.0</version> <<<<<<<< Fails >>>>>>>> <scope>provided</scope> >>>>>>>> </dependency> >>>>>>>> >>>>>>>> <dependency> >>>>>>>> <groupId>org.eclipse.swt.win32.win32</groupId> >>>>>>>> <artifactId>x86</artifactId> >>>>>>>> <version>3.2.9</version> <<<<<<<< Fails >>>>>>>> <scope>provided</scope> >>>>>>>> </dependency> >>>>>>>> >>>>>>>> <dependency> >>>>>>>> <groupId>org.eclipse.swt.win32.win32</groupId> >>>>>>>> <artifactId>x86</artifactId> >>>>>>>> <version>3.3.0-v3346</version> <<<<<<<< >>>>>>>> Works >>>>>>>> <scope>provided</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> > <groupId>org.eclipse.core</groupId> > <artifactId>runtime</artifactId> > <version>[3.3.0.0,4.0.0)</version> > <scope>provided</scope> > <exclusions> > <exclusion> > <groupId>org.eclipse.equinox</groupId> > <artifactId>app</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 > >
