I would look into the filters that can be applied to a target platform
specification in Tycho. Maybe this is the solution for your problem:

  http://wiki.eclipse.org/Tycho/Target_Platform#Filtering

Regards, Markus

On Thu, Jan 24, 2013 at 7:47 PM, David Dykstal <[email protected]>wrote:

> Martin brings up a good point I hadn't thought about - given users the
> capability of installing a later version. In which case we want to include
> 2.2, but not restrict specifically to it.
>
> I believe I can do this by pointing to an earlier orbit repository during
> our builds, but that could have undesirable side-effects by limiting access
> to other orbit components.
>
> If anyone knows how to do this restriction as Martin points out, I'd sure
> like to know.
>
> -- David Dykstal,  Architect - Rational Developer for Power Systems
>
>
>
> From:        "Oberhuber, Martin" <[email protected]>
> To:        Cross project issues <[email protected]>,
> Date:        01/24/2013 12:35 PM
> Subject:        Re: [cross-project-issues-dev] Heads up ... new
> "Recommended"        Orbit        repo for Juno SR2
> Sent by:        [email protected]
> ------------------------------
>
>
>
> Hi David (and all),
>
> We only want a build-time selection of Commons Net 2.2 from Orbit.
>
> The MANIFEST.MF at runtime should be open to allow [2.2,4.0) or even
> higher (as per the recent ICU4J discussion).
> The reason for picking 2.2 by default is that it’s known to work safely
> whereas 3.1 can produce a deadlock in some situations with Telnet.
> End users should be able to deploy 3.2 (which is not in Orbit yet) or 3.1
> (if they are not affected by the deadlock situation).
>
> Does anybody know how to enforce a particular bundle version install at
> build time with Maven ?
>
> Thanks,
> Martin
> --
> *Martin Oberhuber*, SMTS / Product Architect – Development Tools, *Wind
> River*
> direct +43.662.457915.85  fax +43.662.457915.6
>
> *From:* [email protected] [
> mailto:[email protected]<[email protected]>]
> *On Behalf Of *David M Williams*
> Sent:* Thursday, January 24, 2013 7:11 PM*
> To:* Cross project issues*
> Subject:* Re: [cross-project-issues-dev] Heads up ... new "Recommended"
> Orbit repo for Juno SR2
>
> 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
> *<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 
> <*[email protected]*<[email protected]>>,
>
> Date:        01/24/2013 12:45 PM
> Subject:        Re: [cross-project-issues-dev] Heads up ... new
> "Recommended" Orbit        repo for Juno SR2
> Sent by:        
> *[email protected]*<[email protected]>
> ------------------------------
>
>
>
>
> 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 
> (*[email protected]*<[email protected]>)
> <*[email protected]*<[email protected]>>,
>
> Date:        01/24/2013 11:23 AM
> Subject:        [cross-project-issues-dev] Heads up ... new "Recommended"
> Orbit        repo for Juno SR2
> Sent by:        
> *[email protected]*<[email protected]>
> ------------------------------
>
>
>
>
> 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/
> *<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*
> **[email protected]*<[email protected]>
> *
> **https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev*<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> _______________________________________________
> cross-project-issues-dev mailing list*
> **[email protected]*<[email protected]>
> *
> *
> *https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev*<https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev>
> _______________________________________________
> cross-project-issues-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>
> _______________________________________________
> cross-project-issues-dev mailing list
> [email protected]
> https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
>


-- 

###
EclipseSource Group
Telefon: +49 721 664733-0 (GMT +2)
Telefax: +49 721 66473329

http://eclipsesource.com


Innoopract Informationssysteme GmbH
Lammstrasse 21, 76133 Karlsruhe Germany
General Manager: Jochen Krause
Registered Office: Karlsruhe, Commercial Register Mannheim HRB 107883
_______________________________________________
cross-project-issues-dev mailing list
[email protected]
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev

Reply via email to