Re: [cross-project-issues-dev] Heads up ... new "Recommended" Orbit repo

[David Dykstal <david_dykstal@xxxxxxxxxx>]

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"
<Martin.Oberhuber@xxxxxxxxxxxxx>
To:      
 Cross project issues
<cross-project-issues-dev@xxxxxxxxxxx>, 
Date:      
 01/24/2013 12:35 PM
Subject:    
   Re: [cross-project-issues-dev]
Heads up ... new "Recommended"        Orbit
       repo for Juno SR2
Sent by:    
   cross-project-issues-dev-bounces@xxxxxxxxxxx

---

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: cross-project-issues-dev-bounces@xxxxxxxxxxx
[mailto:cross-project-issues-dev-bounces@xxxxxxxxxxx]
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

I'll look forward to learning myself! 





From:        David
Dykstal/Rochester/IBM@IBMUS
To:        Cross project
issues <cross-project-issues-dev@xxxxxxxxxxx>,
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-bounces@xxxxxxxxxxx

---

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@xxxxxxxxxxx)
<cross-project-issues-dev@xxxxxxxxxxx>,
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-bounces@xxxxxxxxxxx

---

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@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev