cziege...@apache.org
wrote:
Hi,
right now we have a policy for handling provisional OSGi API (API
that is
currently drafted in the OSGi expert groups but not final or
officially
released yet):
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
about this before I committed :-)
david jencks
On May 15, 2014, at 11:14 PM, Carsten Ziegeler cziege...@apache.org
wrote:
Hi,
right now we have a policy for handling provisional OSGi API (API
that is
currently drafted in the OSGi expert groups but not final or
officially
released
, 2014, at 11:14 PM, Carsten Ziegeler cziege...@apache.org
wrote:
Hi,
right now we have a policy for handling provisional OSGi API (API
that is
currently drafted in the OSGi expert groups but not final or
officially
released yet):
http://felix.apache.org/documentation/development/provisional
Ziegeler cziege...@apache.org
wrote:
Hi,
right now we have a policy for handling provisional OSGi API (API
that is
currently drafted in the OSGi expert groups but not final or
officially
released yet):
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
On 19 May 2014 10:54, Marcel Offermans marcel.offerm...@luminis.nl wrote:
Hello David,
On 19 May 2014, at 10:22 , David Bosschaert david.bosscha...@gmail.com
wrote:
On 5/16/14, 20:43 , David Jencks wrote:
for instance, debugging the conformance test suite will be more or less
impossible,
integration tests.
thanks for reminding me to think about this before I committed :-)
david jencks
On May 15, 2014, at 11:14 PM, Carsten Ziegeler cziege...@apache.org
wrote:
Hi,
right now we have a policy for handling provisional OSGi API (API
that is
currently drafted in the OSGi
On May 15, 2014, at 11:14 PM, Carsten Ziegeler cziege...@apache.org
wrote:
Hi,
right now we have a policy for handling provisional OSGi API (API that is
currently drafted in the OSGi expert groups but not final or officially
released yet):
http://felix.apache.org/documentation
I committed :-)
david jencks
On May 15, 2014, at 11:14 PM, Carsten Ziegeler cziege...@apache.org wrote:
Hi,
right now we have a policy for handling provisional OSGi API (API that is
currently drafted in the OSGi expert groups but not final or officially
released yet):
http://felix.apache.org
Hi,
right now we have a policy for handling provisional OSGi API (API that is
currently drafted in the OSGi expert groups but not final or officially
released yet):
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
While the policy is good and nice, it requires
:-)
david jencks
On May 15, 2014, at 11:14 PM, Carsten Ziegeler cziege...@apache.org wrote:
Hi,
right now we have a policy for handling provisional OSGi API (API that is
currently drafted in the OSGi expert groups but not final or officially
released yet):
http://felix.apache.org
:
Hi,
right now we have a policy for handling provisional OSGi API (API that is
currently drafted in the OSGi expert groups but not final or officially
released yet):
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
While the policy is good and nice, it requires
jencks
On May 15, 2014, at 11:14 PM, Carsten Ziegeler cziege...@apache.org
wrote:
Hi,
right now we have a policy for handling provisional OSGi API (API that is
currently drafted in the OSGi expert groups but not final or officially
released yet):
http://felix.apache.org/documentation
an
unshaded bundle for unshaded integration tests.
thanks for reminding me to think about this before I committed :-)
david jencks
On May 15, 2014, at 11:14 PM, Carsten Ziegeler cziege...@apache.org wrote:
Hi,
right now we have a policy for handling provisional OSGi API (API
Ziegeler cziege...@apache.org
wrote:
Hi,
right now we have a policy for handling provisional OSGi API (API
that is
currently drafted in the OSGi expert groups but not final or officially
released yet):
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
While the policy
...@apache.org wrote:
Hi,
right now we have a policy for handling provisional OSGi API (API that is
currently drafted in the OSGi expert groups but not final or officially
released yet):
http://felix.apache.org/documentation/development/provisional-osgi-api-policy.html
While the policy is good
a little fast and loose with our
handling
of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo
0.6.0
releases, we've started to evolve a policy on how to handle
this, but
nothing has been decided concretely. This is problematic since
it leads
different people to different decisions. Thus
a little fast and loose with our
handling
of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo
0.6.0
releases, we've started to evolve a policy on how to handle
this, but
nothing has been decided concretely. This is problematic since
it leads
different people to different decisions. Thus
need to mandate a global Felix
policy for
this and subprojects can choose to support two APIs if they want.
- richard
Regards
Felix
Am 17.09.2010 18:35, schrieb Richard S. Hall:
For a long time, we've played a little fast and loose
with our
handling
of provisional OSGi API
to support two APIs if they want.
- richard
Regards
Felix
Am 17.09.2010 18:35, schrieb Richard S. Hall:
For a long time, we've played a little fast and loose
with our
handling
of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo
0.6.0
releases, we've started to evolve
time, we've played a little fast and loose
with our
handling
of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo
0.6.0
releases, we've started to evolve a policy on how to handle
this, but
nothing has been decided concretely. This is problematic since
it leads
different people to different
:
For a long time, we've played a little fast and loose
with our
handling
of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo
0.6.0
releases, we've started to evolve a policy on how to handle
this, but
nothing has been decided concretely. This is problematic
since
it leads
two APIs if they
want.
- richard
Regards
Felix
Am 17.09.2010 18:35, schrieb Richard S. Hall:
For a long time, we've played a little fast and loose
with our
handling
of provisional OSGi API. Starting with the OBR 1.6.0 and
Gogo
0.6.0
releases, we've started to evolve
Regards
Felix
Am 17.09.2010 18:35, schrieb Richard S. Hall:
For a long time, we've played a little fast and loose
with our
handling
of provisional OSGi API. Starting with the OBR 1.6.0
and Gogo
0.6.0
releases, we've started to evolve a policy on how to
handle
this, but
nothing has been
with our
handling
of provisional OSGi API. Starting with the OBR 1.6.0
and Gogo
0.6.0
releases, we've started to evolve a policy on how to
handle
this, but
nothing has been decided concretely. This is problematic
since
it leads
different people to different decisions. Thus, its about
time we
defined
, I don't think we need to mandate a global Felix policy for
this and subprojects can choose to support two APIs if they want.
- richard
Regards
Felix
Am 17.09.2010 18:35, schrieb Richard S. Hall:
For a long time, we've played a little fast and loose with our
handling
of provisional
think we need to mandate a global Felix policy for
this and subprojects can choose to support two APIs if they want.
-richard
Regards
Felix
Am 17.09.2010 18:35, schrieb Richard S. Hall:
For a long time, we've played a little fast and loose with our
handling
of provisional OSGi API
think we need to mandate a global Felix
policy for
this and subprojects can choose to support two APIs if they want.
-richard
Regards
Felix
Am 17.09.2010 18:35, schrieb Richard S. Hall:
For a long time, we've played a little fast and loose with our
handling
of provisional OSGi API
played a little fast and loose with our
handling
of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo
0.6.0
releases, we've started to evolve a policy on how to handle
this, but
nothing has been decided concretely. This is problematic since
it leads
different people to different
policy for
this and subprojects can choose to support two APIs if they want.
- richard
Regards
Felix
Am 17.09.2010 18:35, schrieb Richard S. Hall:
For a long time, we've played a little fast and loose with our handling
of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo 0.6.0
played a little fast and loose with our handling
of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo 0.6.0
releases, we've started to evolve a policy on how to handle this, but
nothing has been decided concretely. This is problematic since it leads
different people to different decisions. Thus
, we've played a little fast and loose with our handling
of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo 0.6.0
releases, we've started to evolve a policy on how to handle this, but
nothing has been decided concretely. This is problematic since it leads
different people to different decisions
we need to mandate a global
Felix policy for this and subprojects can choose to support two APIs if
they want.
- richard
Regards
Felix
Am 17.09.2010 18:35, schrieb Richard S. Hall:
For a long time, we've played a little fast and loose with our handling
of provisional OSGi API. Starting
:
For a long time, we've played a little fast and loose with our handling
of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo 0.6.0
releases, we've started to evolve a policy on how to handle this, but
nothing has been decided concretely. This is problematic since it leads
different
.
Regards
Felix
Am 17.09.2010 18:35, schrieb Richard S. Hall:
For a long time, we've played a little fast and loose with our handling
of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo 0.6.0
releases, we've started to evolve a policy on how to handle this, but
nothing has been
releases the official API, we can still keep our
internal API for certain period of time thus supporting both API, if we
so wish.
Regards
Felix
Am 17.09.2010 18:35, schrieb Richard S. Hall:
For a long time, we've played a little fast and loose with our handling
of provisional OSGi API. Starting
For a long time, we've played a little fast and loose with our
handling of provisional OSGi API. Starting with the OBR 1.6.0 and Gogo
0.6.0 releases, we've started to evolve a policy on how to handle this,
but nothing has been decided concretely. This is problematic since it
leads different
On 17 Sep 2010, at 18:35 , Richard S. Hall wrote:
From my point of view, approach (1) might not be awesome, but it results in a
simpler process than (2). So, I'd recommend (1). If the majority prefers (2),
then we can do that (although I think we'll have to run the decision by the
board
On 9/17/10 11:36, Marcel Offermans wrote:
On 17 Sep 2010, at 18:35 , Richard S. Hall wrote:
From my point of view, approach (1) might not be awesome, but it results in a
simpler process than (2). So, I'd recommend (1). If the majority prefers (2),
then we can do that (although I think
On 9/17/10 12:11, Richard S. Hall wrote:
On 9/17/10 11:36, Marcel Offermans wrote:
On 17 Sep 2010, at 18:35 , Richard S. Hall wrote:
From my point of view, approach (1) might not be awesome, but it
results in a simpler process than (2). So, I'd recommend (1). If the
majority prefers (2),
On 17 Sep 2010, at 21:12 , Richard S. Hall wrote:
On 9/17/10 12:11, Richard S. Hall wrote:
On 9/17/10 11:36, Marcel Offermans wrote:
On 17 Sep 2010, at 18:35 , Richard S. Hall wrote:
From my point of view, approach (1) might not be awesome, but it results
in a simpler process than (2). So,
On 9/17/10 12:54, Marcel Offermans wrote:
On 17 Sep 2010, at 21:12 , Richard S. Hall wrote:
On 9/17/10 12:11, Richard S. Hall wrote:
On 9/17/10 11:36, Marcel Offermans wrote:
On 17 Sep 2010, at 18:35 , Richard S. Hall wrote:
From my point of view, approach (1) might not be awesome, but it
On 17 Sep 2010, at 22:27 , Richard S. Hall wrote:
On 9/17/10 12:54, Marcel Offermans wrote:
On 17 Sep 2010, at 21:12 , Richard S. Hall wrote:
On 9/17/10 12:11, Richard S. Hall wrote:
On 9/17/10 11:36, Marcel Offermans wrote:
On 17 Sep 2010, at 18:35 , Richard S. Hall wrote:
From my point
On 9/17/10 13:41, Marcel Offermans wrote:
On 17 Sep 2010, at 22:27 , Richard S. Hall wrote:
On 9/17/10 12:54, Marcel Offermans wrote:
On 17 Sep 2010, at 21:12 , Richard S. Hall wrote:
On 9/17/10 12:11, Richard S. Hall wrote:
On 9/17/10 11:36, Marcel Offermans wrote:
On 17 Sep 2010, at
43 matches
Mail list logo
