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]

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
> *)
>
> 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

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]

Marshall Schor wrote:

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
*)

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 is there anything we can do to avoid this issue ?
Maybe we can use another version of eclipse as dependency.

I also noticed that our eclipse plugins depend on different eclipse
version, would it be an advantage to only depend on one ?

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]

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]

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

[Marshall Schor]

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:


org.eclipse.core
resources
[3.3.0,4.0.0)
provided


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:


org.eclipse.core
resources
[3.2.9,4.0.0)
provided


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:


org.eclipse.swt.win32.win32
x86
[3.2.9,4.0.0)
provided


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

[Marshall Schor]

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

[Jukka Zitting]

Hi,

On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor  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

[Marshall Schor]

Jukka Zitting wrote:
> Hi,
>
> On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor  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:


org.eclipse.swt.win32.win32
x86
3.3.0  Fails
provided



org.eclipse.swt.win32.win32
x86
3.2.9  Fails
provided



org.eclipse.swt.win32.win32
x86
3.3.0-v3346  Works
provided


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
 

  org.eclipse
  text
  [3.3.0,4.0.0)


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
>
>
>   

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]

Marshall Schor wrote:

Jukka Zitting wrote:
  

Hi,

On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor  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:


org.eclipse.swt.win32.win32
x86
3.3.0  Fails
provided



org.eclipse.swt.win32.win32
x86
3.2.9  Fails
provided



org.eclipse.swt.win32.win32
x86
3.3.0-v3346  Works
provided

  

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

[Marshall Schor]

Jörn Kottmann wrote:
> Marshall Schor wrote:
>> Jukka Zitting wrote:
>>  
>>> Hi,
>>>
>>> On Tue, Sep 22, 2009 at 3:36 PM, Marshall Schor  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:
>>
>> 
>> org.eclipse.swt.win32.win32
>> x86
>> 3.3.0  Fails
>> provided
>> 
>>
>> 
>> org.eclipse.swt.win32.win32
>> x86
>> 3.2.9  Fails
>> provided
>> 
>>
>> 
>> org.eclipse.swt.win32.win32
>> x86
>> 3.3.0-v3346  Works
>> provided
>> 
>>   
> 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

[Jörn Kottmann]

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  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:


org.eclipse.swt.win32.win32
x86
3.3.0  Fails
provided



org.eclipse.swt.win32.win32
x86
3.2.9  Fails
provided



org.eclipse.swt.win32.win32
x86
3.3.0-v3346  Works
provided

  
  

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

[Marshall Schor]

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 
> 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:

 
 org.eclipse.swt.win32.win32
 x86
 3.3.0  Fails
 provided
 

 
 org.eclipse.swt.win32.win32
 x86
 3.2.9  Fails
 provided
 

 
 org.eclipse.swt.win32.win32
 x86
 3.3.0-v3346  Works
 provided
 
 
>>> 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]

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 
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:


org.eclipse.swt.win32.win32
x86
3.3.0  Fails
provided



org.eclipse.swt.win32.win32
x86
3.2.9  Fails
provided



org.eclipse.swt.win32.win32
x86
3.3.0-v3346  Works
provided


  

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

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]

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 
>>> 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:
>>
>> 
>> org.eclipse.swt.win32.win32
>> x86
>> 3.3.0  Fails
>> provided
>> 
>>
>> 
>> org.eclipse.swt.win32.win32
>> x86
>> 3.2.9  Fails
>> provided
>> 
>>
>> 
>> org.eclipse.swt.win32.win32
>> x86
>> 3.3.0-v3346 
>> Works
>> provided
>> 
>>   
> 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]

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 
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:


org.eclipse.swt.win32.win32
x86
3.3.0  Fails
provided



org.eclipse.swt.win32.win32
x86
3.2.9  Fails
provided



org.eclipse.swt.win32.win32
x86
3.3.0-v3346 
Works
provided

  
  

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:
   
   org.eclipse.core
   runtime
   [3.3.0.0,4.0.0)
   provided
   
   
   org.eclipse.equinox
   app
   
   
   

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

[Marshall Schor]

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 
> 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:

 
 org.eclipse.swt.win32.win32
 x86
 3.3.0  Fails
 provided
 

 
 org.eclipse.swt.win32.win32
 x86
 3.2.9  Fails
 provided
 

 
 org.eclipse.swt.win32.win32
 x86
 3.3.0-v3346 
 Works
 provided
 
 
>>> 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:
>
>org.eclipse.core
>runtime
>[3.3.0.0,4.0.0)
>provided
>
>
>org.eclipse.equinox
>app
>
>
>
>
> 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?