Hi all Wouldn't it be better in this situation to pack the newest Version 3.2 from commons net to Orbit. Even if this comes up a little late and the R Version of Orbit is already promoted for Juno SR2. As Apache has released 3.2 this would be IMHO the better way than to pack an version which is two years old into the EPP. I would do the update but David Dykstal would have to open a (high prio?) CQ from the TM Project to use Apache Commons Net 3.2 so Orbit could open a piggyback.
What do you think? Or * From: "Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx<mailto:[email protected]>> * Date: Thu, 24 Jan 2013 18:30:34 +0000 * Accept-language: en-US * Delivered-to: [email protected]<mailto:[email protected]> * Thread-index: AQHN+leHmRtU+ONw4kCQt/T6cQwZMJhZRdgAgAAH+ID//34PkA== * Thread-topic: [cross-project-issues-dev] Heads up ... new "Recommended" Orbit repo for Juno SR2 ________________________________ 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 --- Stephan Leicht Vogt Senior Software Engineer BSI Business Systems Integration AG Täfernstrasse 16a, CH-5405 Baden Phone (direct): +41 56 484 19 47 www.bsiag.com<http://www.bsiag.com/>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ cross-project-issues-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
