User-agent: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20111105 Thunderbird/8.0
Hi Boris,
On 1/10/2012 7:19 AM, Borislav Kapukaranov wrote:
Hi Scott,
We've taken the p2 bundles + dependencies from the Equinox
SDK package.
Hmm. I wasn't aware that Equinox wasn't putting the httpclient
provider in the Equinox SDK package. For reliability reasons, I
would suggest that they *do* include the httpclient provider in the
SDK package...but I'm not the maintainer of that package.
What other bundles do you think we can add to our current
list to benefit from the improved http transport you mentioned?
The httpclient provider consists of two small ECF bundles:
org.eclipse.ecf.provider.filetransfer.httpclient
and
org.eclipse.ecf.provider.filetransfer.httpclient.ssl
these are dependent upon the apache httpclient 3.1 bundle...that we
get from Orbit. apache httpclient also depends upon apache a)
commons codec and b) commons logging...so there are 3 bundles from
orbit that we get:
Also can you see any bundles becoming obsolete when we
replace the transport? I'd like to keep the p2 bundles + their
dependencies tight in the nano distribution and I'm looking for
a minimal working set. :)
I understand. The ECF httpclient provider bundles are very
small...but unfortunately the apache httpclient bundle(s) are not as
small as I would like.
So for you, I think it comes down to a choice between code size and
reliability. The reason the httpclient provider was added in the
first place was to make up for reliability deficiencies in the jre
urlconnection runtime behavior...but it is possible that some/all of
the issues with the urlconnection impl have been fixed (by
Oracle/Sun).
Thanksinadvance for the attention. It should be an easy
fix, I believe.
As for the new version of the httpclient, we got
the "old" http transport when we started consuming
p2 and basically this is what was included along
with p2.
Hmmm. We've been including the httpclient provider to
p2/Platform for a couple of major Eclipse releases now
(3.6, 3.7 at least), but maybe it's not included in some
(Equinox sdk?) distribution of p2. It's definitely been
in Eclipse for at least two years now.
My assumption is that when p2 starts bundling
with the new ECF version and httpclient we would
automatically get these when we update our p2
version to a newer milestone.
That should work just fine...as you indicate with bug
below the Equinox/p2 team is moving to using the latest
release build (3.5.4) of ECF filetransfer. But given
what you say above, I'm not sure what distro of p2/ECF
filetransfer you are using to create nano...as it seems
that maybe whatever you are using doesn't by default
include the httpclient-based provider? I know that for
Eclipse the httpclient-based provider is included/used.
Currently we are using M03 and I saw in bug367794 that the update of
the httpcleint and ECF in p2 will happen in M05.
Right...it's actually happening right now (this week's
integration build) is my understanding.
So it will be in Eclipse...but if you are not using the
Eclipse distro of Equinox/p2/ecf filetransfer then you
might not get it (I don't control how/what's included in
various Equinox distros).
I corresponded with Thomas Watson about this
resolution problem with httpclient 3.1 in
virgo, and he said:
A bundle that expresses a Bundle-RequiredExcecutionEnvironment: J2SE-1.2
must be able to run on J2SE-1.4 and higher. I would like to understand
what issue you see when the bundle does not also list J2SE-1.4.
Tom
<I explained what I was seeing>
Hmmm, it is possible Virgo is using a custom java profile that does not
list J2SE-1.2 in the property org.osgi.framework.executionenvironment.
That would be a bug in Virgo, if that is the case.
Tom
[Scott] Should I open a bug for this
against Virgo nano?...as it seems that given
this the Orbit folks are not going to change
the httpclient ee.
Thanks,
Scott
On 1/3/2012 9:19 PM, Scott Lewis wrote:
On 1/3/2012
9:03 PM, Scott Lewis wrote:
Hi Boris,
<stuff deleted>
One thing
that I noticed while trying to
install the httpclient 3.1 bundle
from Orbit with a new feature...the
httpclient bundle from Orbit
wouldn't resolve:
org.osgi.framework.BundleException:
The bundle
"org.apache.commons.httpclient_3.1.0.v201012070820
[100]" could not be resolved.
Reason: Missing
Constraint:
Bundle-RequiredExecutionEnvironment:
CDC-1.0/Foundation-1.0,J2SE-1.2
I've verified that if I add J2SE-1.4
to the set of required execution
environments for the
org.apache.commons.httpclient bundle,
then it will install in Virgo just
fine. Unfortunately, this bundle
(httpclient 3.1.0) is currently
maintained by Orbit committers...not
be me or the ECF project.
I've sent a note to the Orbit dev
mailing list, to find out if j2se 1.4
can be added to the httpclient 3.1.0
min ee.
Thanks,
Scott
Does this make sense to you? Does
Virgo Nano not provide these
execution environments?
Anyway...hopefully we can jointly
work these things out. Please let
me know what you think.
Thanks,
Scott
On 1/3/2012 9:28 AM, Borislav
Kapukaranov wrote:
Sure, you
can find it on the Virgo
milestones download page,
under the Virgo Nano name.
You can access telnet via
"telnet localhost 2401", the p2
commands are available there.
Ok...thanks...I will do
this. Sorry I haven't
been keeping up on all the
Virgo Nano work...sounds
great. Is there a
distribution available?
If so...could you point me
in the right direction?
Thanks much,
Scott
On 12/29/2011 5:59 AM,
Borislav Kapukaranov
wrote:
Hey
Scott,
Just tested
installing ECF's
remote services on
Virgo Nano and, as
expected, it went
quite smoothly.
The bundles got
installed fine.
If you'd like
you can play with
Virgo Nano and the
p2 commands to see
if there are any
problems with the
remote services
lurking around.
On 9/23/2011
1:02 AM,
Kapukaranov,
Borislav
wrote:
Hey
Scott,
As
of 3.5
equinox.common
should come
out of the box
with Virgo as
p2 has
dependency to
it too.
You’ll
notice the bug doesn’t provide much content – that will change
once I push
the baseline
of the p2
integration
and build from
then on for
the remaining
features.
I
have the
integration
prepared
locally and
it’s looking
good, e.g. the
startup time
on Windows was
decreased more
than twice…
but I’m
waiting on two
p2
enhancements [1][2] to get resolved. Without them the code won’t be
building and
working
properly.
In
the end if it
turns out
these are
taking a lot
of time to
resolve we’ll
just update
EBR with the
working
versions until
an official
build is ready
and start
producing 3.5
alphas.
Do
you have the
update site of
the ECF's
remote
services? I’d
be happy to
try it.
Sure. ECF's
3.5.2 release
repo [1]. In
this repo
there are a
few
features...the
one that is of
interest for
this use case
(instead of
Eclipse), is
entitled 'ECF
Remote
Services
Target
Components'.
Here [2] is a
detailed
description of
adding this
feature to
one's target
platform.
Also see [3]
for a 'getting
started'
tutorial (with
examples,
etc).
In a previous
note, Lorie
referenced
this wiki page
[4] (thanks
Lorie). The
one thing that
I wanted to
add was that I
think that
much of what's
described on
this page [4]
is now
actually
*unnecessary*...due
to changes for
ECF's
implementation
of the Remote
Service Admin
spec. This
wiki
page...although
still
valid/supported,
I
believe...requires
more
programming
than is now
strictly
necessary. I
will try to
update it and
simplify it
when I can.
