To make the problem explicit, there's several versions in that repo: 

org.apache.commons.net   1.4.0
org.apache.commons.net   2.1.0
org.apache.commons.net   2.2.0
org.apache.commons.net   3.1.0


There are likely 100 readers of this list that could give better "pom 
advice" than I could ... but, I could give some. 

My main advice is "don't do that". :)  That is, don't put the restriction 
in the "pom" ... again, others can chime in here. 

But, I suspect you not only want the restriction at "build time", but also 
at "run time", right? 

If so, your manifest.mf files that "prereq" org.apache.commons.net should 
specify a range that is acceptable to you at runtime, and then, I believe, 
it doesn't matter what's in the Orbit repository, your build will "pull" 
an acceptable version. You can do it with "require bundle", but for many 
of these "common packages" its recommended to use "import package", for 
example, 

Import-Package: org.apache.commons.net;version="[2.2.0,3.0.0)" 
(or, what ever exact packages you need from that bundle). 

Its my understanding that will suffice to get that specific version you 
want an "skip" the 2.1 and 3.1 versions. (But, I'm still learning maven 
and tycho). 

Does this make sense? Do you currently specify a "minimum" version only? 

I could be wrong and maybe there is some pom restrictions to apply too ... 
but, know these manifest restrictions are important. 

If you are already doing that, though, and still not working ... then 
suspect others can better advice how to use "targets" in your pom file. 
http://wiki.eclipse.org/Tycho/Target_Platform#Target_platform_configuration

I'll look forward to learning myself! 





From:   David Dykstal/Rochester/IBM@IBMUS
To:     Cross project issues <cross-project-issues-dev@eclipse.org>, 
Date:   01/24/2013 12:45 PM
Subject:        Re: [cross-project-issues-dev] Heads up ... new 
"Recommended" Orbit     repo for Juno SR2
Sent by:        cross-project-issues-dev-boun...@eclipse.org



Dave -- 

TM needs to use version 2.2 of org.apache.commons.net from the repository. 
I haven't yet figured out how to specify this version restriction in our 
pom.xml file. Can you offer any advice here? 

-- David Dykstal,  Architect - Rational Developer for Power Systems 



From:        David M Williams/Raleigh/IBM@IBMUS 
To:        Cross project issues (cross-project-issues-dev@eclipse.org) 
<cross-project-issues-dev@eclipse.org>, 
Date:        01/24/2013 11:23 AM 
Subject:        [cross-project-issues-dev] Heads up ... new "Recommended" 
Orbit        repo for Juno SR2 
Sent by:        cross-project-issues-dev-boun...@eclipse.org 



This morning I renamed our latest "M build" to an "R build" for use in 
Juno SR2. 

http://download.eclipse.org/tools/orbit/downloads/drops/R20130118183705/ 

I will leave M builds in place until Tuesday, 1/27, to give time for 
anyone using them time to switch their builds scripts (or pom.xml files) 
... but remove them on 1/28 as a not-so-friendly-reminder to update if you 
haven't already. (Of course, if anyone needs an extra day or two, just 
ask). 

The only bundle that's changed from previous R build is org.apache.ant (to 
fix a label/name problem) but several new ones were added for project(s) 
that need them in an R-build. 

< org.apache.ant_1.8.3.v20120321-1730.jar 
< org.apache.ant.source_1.8.3.v20120321-1730.jar 

> org.apache.ant_1.8.3.v201301120609.jar 
> org.apache.ant.source_1.8.3.v201301120609.jar 

> javaewah_0.5.6.v201210150900.jar 
> javaewah.source_0.5.6.v201210150900.jar 
> org.apache.commons.compress_1.3.0.v201212111400.jar 
> org.apache.commons.compress_1.4.1.v201301140946.jar 
> org.apache.commons.compress.source_1.3.0.v201212111400.jar 
> org.apache.commons.compress.source_1.4.1.v201301140946.jar 
> org.kohsuke.args4j_2.0.21.v201301150030.jar 
> org.kohsuke.args4j.source_2.0.21.v201301150030.jar 

Thanks, _______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Reply via email to