You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by "Valentin Valchev (JIRA)" <ji...@apache.org> on 2011/09/07 08:15:12 UTC
[jira] [Created] (FELIX-3105) WebConsole bundle should export
packages from embedded jars
WebConsole bundle should export packages from embedded jars
-----------------------------------------------------------
Key: FELIX-3105
URL: https://issues.apache.org/jira/browse/FELIX-3105
Project: Felix
Issue Type: Bug
Components: Web Console
Affects Versions: webconsole-3.1.8
Reporter: Valentin Valchev
Assignee: Felix Meschberger
Priority: Blocker
Fix For: webconsole-3.1.10
Currently webconsole bundle (non bare variant) contains build-in org.json, commons fileupload, commons io, osgi service tracker. These packages should be exported because they will be needed when we move SCR & Deployment Packages plugins in separate jars.
Until that is done, I cannot finish separation of the plugins.
Felix, WHYT? Shall we do that? If yes - just reassign the issue to me.
See also:
https://issues.apache.org/jira/browse/FELIX-3099
https://issues.apache.org/jira/browse/FELIX-3100
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105)
WebConsole bundle should export packages from embedded jars)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
On 09.09.2011 17:59, Valentin Valchev wrote:
> Hello,
> On 8.9.2011 г. 09:51 ч., Felix Meschberger wrote:
>> Hi all,
>>
>> On 07.09.2011 20:26, Valentin Valchev wrote:
>>> Btw what about the OBR plugin? Shall it remain build-in or moved as
>>> separate plugin?
>> Now, this starts to be an interesting discussion ;-)
>>
>> This is the current plugin setup in the Web Console:
>>
>> (1) Plugins I consider core and which should be kept:
>> - Bundle
>> - Services
>> - License
>> - System Properties
> Thinking of that, maybe we can add also another one - Framework
> Properties, that the user can obtain from
> BundleContext.getProperty(String key), since framework properties are
> important, but it's not actually necessary to be system properties.
The problem here is, that there is no way to enumerate the framework
properties (as in BundleContext.getPropertyNames() or similar). So, the
only thing you can do is print a number of well-known properties....
>> (2) Plugins already considered for breaking out
>> - Deployment Admin -- FELIX-3099
>> - DS - FELIX-3100
>> - Shell - FELIX-3107
>>
>> (3) Plugins still in the Web Console which might/should be split off
>> - Configuration Admin
>> - LogService
> I think that these should be build-in. Configuration and Log service are
> so common, that we can make them available by default.
Ok
>> - Preferences Service
>> - Wire Admin
> Could go into common bundle 'compendium plugins'. So with one bundle you
> can install almost all OSGi-related plugins/printers.
We have split most compendium supports in separate bundles and keep to
inline (LogService, Configuration Admin). I think it would be strange to
move these two in a single bundle ...
>> - Thread
>> - OBR
>>
>> The idea of also breaking out the Thread configuration printer is to
>> easier support thread dump funcitonality introduced with Java 5 and 6
>> through the JMX Thread API. Also this could be aligned with the Apache
>> Kato project, particularly KATO-14.
> Yes, but still Thread information is general information, that can be
> used for system analysis and the information will be still usable, if
> you don't have that JMX API. So I vote for leaving Thread info into the
> main web console. Additional functionality could be provided by separate
> bundle - like that memory plugin, that already uses the JMX API I think.
Arguably, yes. So lets keep it inside for now.
Regards
Felix
>> Now, that we started breaking out plugins, we should probably be
>> consequent and break out non-central plugins.
>>
>> Regards
>> Felix
>>
>>
>
Re: [WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105)
WebConsole bundle should export packages from embedded jars)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi Valentin,
On 12.09.2011 16:52, Valentin Valchev wrote:
> Hello Felix,
> I've just committed the new plugins and removed the old code from
> webconsole.
Cool.
> Didn't resolved this issue: https://issues.apache.org/jira/browse/FELIX-3111
> because there is no version in Jira for obr-plugin. Can you add one?
I have created the webconsole-obr-plugin 1.0.0 version.
> I also don't know how to add these plugins to build by default. Is there
> something like main pom file that builds everything related to the
> apache felix project?
There is a reactor pom.xml in the root folder. It currently only lists
the events plugin and none of the other new plugin projects.
To be honest, I never really use the reactor to build everything. Rather
I just build on demand and otherwise just use released versions of the
bundles in my projects.
Which leads me to suggesting that we soon release the stuff ;-)
Regards
Felix
> Regards,
> Valentin Valchev
>
>
> On 12.9.2011 г. 14:42 ч., Felix Meschberger wrote:
>> Hi,
>>
>> On 12.09.2011 08:52, Valentin Valchev wrote:
>>> Hi Felix,
>>> I have the following plugins already separated:
>>> deppack
>>> ds (declarative services)
>>> shell
>>> obr
>>>
>>> The question is can I commit now?
>> Sure, go ahead.
>>
>> Regards
>> Felix
Re: [WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105)
WebConsole bundle should export packages from embedded jars)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
On 12.09.2011 08:52, Valentin Valchev wrote:
> Hi Felix,
> I have the following plugins already separated:
> deppack
> ds (declarative services)
> shell
> obr
>
> The question is can I commit now?
Sure, go ahead.
Regards
Felix
> Regards,
> Valentin
>
> On 9.9.2011 г. 18:59 ч., Valentin Valchev wrote:
>> Hello,
>> On 8.9.2011 г. 09:51 ч., Felix Meschberger wrote:
>>> Hi all,
>>>
>>> On 07.09.2011 20:26, Valentin Valchev wrote:
>>>> Btw what about the OBR plugin? Shall it remain build-in or moved as
>>>> separate plugin?
>>> Now, this starts to be an interesting discussion ;-)
>>>
>>> This is the current plugin setup in the Web Console:
>>>
>>> (1) Plugins I consider core and which should be kept:
>>> - Bundle
>>> - Services
>>> - License
>>> - System Properties
>> Thinking of that, maybe we can add also another one - Framework
>> Properties, that the user can obtain from
>> BundleContext.getProperty(String key), since framework properties are
>> important, but it's not actually necessary to be system properties.
>>> (2) Plugins already considered for breaking out
>>> - Deployment Admin -- FELIX-3099
>>> - DS - FELIX-3100
>>> - Shell - FELIX-3107
>>>
>>> (3) Plugins still in the Web Console which might/should be split off
>>> - Configuration Admin
>>> - LogService
>> I think that these should be build-in. Configuration and Log service are
>> so common, that we can make them available by default.
>>> - Preferences Service
>>> - Wire Admin
>> Could go into common bundle 'compendium plugins'. So with one bundle you
>> can install almost all OSGi-related plugins/printers.
>>> - Thread
>>> - OBR
>>>
>>> The idea of also breaking out the Thread configuration printer is to
>>> easier support thread dump funcitonality introduced with Java 5 and 6
>>> through the JMX Thread API. Also this could be aligned with the Apache
>>> Kato project, particularly KATO-14.
>> Yes, but still Thread information is general information, that can be
>> used for system analysis and the information will be still usable, if
>> you don't have that JMX API. So I vote for leaving Thread info into the
>> main web console. Additional functionality could be provided by separate
>> bundle - like that memory plugin, that already uses the JMX API I think.
>>> Now, that we started breaking out plugins, we should probably be
>>> consequent and break out non-central plugins.
>>>
>>> Regards
>>> Felix
>>>
>>>
>
Re: [WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105)
WebConsole bundle should export packages from embedded jars)
Posted by Valentin Valchev <v_...@prosyst.bg>.
Hi Felix,
I have the following plugins already separated:
deppack
ds (declarative services)
shell
obr
The question is can I commit now?
Regards,
Valentin
On 9.9.2011 г. 18:59 ч., Valentin Valchev wrote:
> Hello,
> On 8.9.2011 г. 09:51 ч., Felix Meschberger wrote:
>> Hi all,
>>
>> On 07.09.2011 20:26, Valentin Valchev wrote:
>>> Btw what about the OBR plugin? Shall it remain build-in or moved as
>>> separate plugin?
>> Now, this starts to be an interesting discussion ;-)
>>
>> This is the current plugin setup in the Web Console:
>>
>> (1) Plugins I consider core and which should be kept:
>> - Bundle
>> - Services
>> - License
>> - System Properties
> Thinking of that, maybe we can add also another one - Framework
> Properties, that the user can obtain from
> BundleContext.getProperty(String key), since framework properties are
> important, but it's not actually necessary to be system properties.
>> (2) Plugins already considered for breaking out
>> - Deployment Admin -- FELIX-3099
>> - DS - FELIX-3100
>> - Shell - FELIX-3107
>>
>> (3) Plugins still in the Web Console which might/should be split off
>> - Configuration Admin
>> - LogService
> I think that these should be build-in. Configuration and Log service are
> so common, that we can make them available by default.
>> - Preferences Service
>> - Wire Admin
> Could go into common bundle 'compendium plugins'. So with one bundle you
> can install almost all OSGi-related plugins/printers.
>> - Thread
>> - OBR
>>
>> The idea of also breaking out the Thread configuration printer is to
>> easier support thread dump funcitonality introduced with Java 5 and 6
>> through the JMX Thread API. Also this could be aligned with the Apache
>> Kato project, particularly KATO-14.
> Yes, but still Thread information is general information, that can be
> used for system analysis and the information will be still usable, if
> you don't have that JMX API. So I vote for leaving Thread info into the
> main web console. Additional functionality could be provided by separate
> bundle - like that memory plugin, that already uses the JMX API I think.
>> Now, that we started breaking out plugins, we should probably be
>> consequent and break out non-central plugins.
>>
>> Regards
>> Felix
>>
>>
>
--
-------------------------------------------------
Valentin Valchev · Lead Software Engineer
ProSyst Labs EOOD
1606 Sofia, Bulgaria · 48 Vladajska Str.
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17
http://www.prosyst.com · v.valchev@prosyst.bg
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------
Re: [WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105)
WebConsole bundle should export packages from embedded jars)
Posted by Valentin Valchev <v_...@prosyst.bg>.
Hello,
On 8.9.2011 г. 09:51 ч., Felix Meschberger wrote:
> Hi all,
>
> On 07.09.2011 20:26, Valentin Valchev wrote:
>> Btw what about the OBR plugin? Shall it remain build-in or moved as
>> separate plugin?
> Now, this starts to be an interesting discussion ;-)
>
> This is the current plugin setup in the Web Console:
>
> (1) Plugins I consider core and which should be kept:
> - Bundle
> - Services
> - License
> - System Properties
Thinking of that, maybe we can add also another one - Framework
Properties, that the user can obtain from
BundleContext.getProperty(String key), since framework properties are
important, but it's not actually necessary to be system properties.
>
> (2) Plugins already considered for breaking out
> - Deployment Admin -- FELIX-3099
> - DS - FELIX-3100
> - Shell - FELIX-3107
>
> (3) Plugins still in the Web Console which might/should be split off
> - Configuration Admin
> - LogService
I think that these should be build-in. Configuration and Log service are
so common, that we can make them available by default.
> - Preferences Service
> - Wire Admin
Could go into common bundle 'compendium plugins'. So with one bundle you
can install almost all OSGi-related plugins/printers.
> - Thread
> - OBR
>
> The idea of also breaking out the Thread configuration printer is to
> easier support thread dump funcitonality introduced with Java 5 and 6
> through the JMX Thread API. Also this could be aligned with the Apache
> Kato project, particularly KATO-14.
Yes, but still Thread information is general information, that can be
used for system analysis and the information will be still usable, if
you don't have that JMX API. So I vote for leaving Thread info into the
main web console. Additional functionality could be provided by separate
bundle - like that memory plugin, that already uses the JMX API I think.
>
> Now, that we started breaking out plugins, we should probably be
> consequent and break out non-central plugins.
>
> Regards
> Felix
>
>
--
-------------------------------------------------
Valentin Valchev · Lead Software Engineer
ProSyst Labs EOOD
1606 Sofia, Bulgaria · 48 Vladajska Str.
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17
http://www.prosyst.com · v.valchev@prosyst.bg
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------
[WebConsole] Breaking out plugins (was Re: [jira] [Created] (FELIX-3105)
WebConsole bundle should export packages from embedded jars)
Posted by Felix Meschberger <fm...@adobe.com>.
Hi all,
On 07.09.2011 20:26, Valentin Valchev wrote:
> Btw what about the OBR plugin? Shall it remain build-in or moved as
> separate plugin?
Now, this starts to be an interesting discussion ;-)
This is the current plugin setup in the Web Console:
(1) Plugins I consider core and which should be kept:
- Bundle
- Services
- License
- System Properties
(2) Plugins already considered for breaking out
- Deployment Admin -- FELIX-3099
- DS - FELIX-3100
- Shell - FELIX-3107
(3) Plugins still in the Web Console which might/should be split off
- Configuration Admin
- LogService
- Preferences Service
- Wire Admin
- Thread
- OBR
The idea of also breaking out the Thread configuration printer is to
easier support thread dump funcitonality introduced with Java 5 and 6
through the JMX Thread API. Also this could be aligned with the Apache
Kato project, particularly KATO-14.
Now, that we started breaking out plugins, we should probably be
consequent and break out non-central plugins.
Regards
Felix
Re: [jira] [Created] (FELIX-3105) WebConsole bundle should export
packages from embedded jars
Posted by Valentin Valchev <v_...@prosyst.bg>.
Btw what about the OBR plugin? Shall it remain build-in or moved as
separate plugin?
On 7.9.2011 г. 17:57 ч., Felix Meschberger wrote:
> Hi,
>
> On 07.09.2011 14:35, Valentin Valchev wrote:
>> On 7.9.2011 г. 12:35 ч., Felix Meschberger wrote:
>>> Hi,
>>>
>>> On 07.09.2011 08:15, Valentin Valchev (JIRA) wrote:
>>>> WebConsole bundle should export packages from embedded jars
>>>> Currently webconsole bundle (non bare variant) contains build-in org.json, commons fileupload, commons io, osgi service tracker. These packages should be exported because they will be needed when we move SCR & Deployment Packages plugins in separate jars.
>>> I always wanted ot have a single web console plugin with all
>>> dependencies included for simple deployment. Which is why these
>>> dependencies (particuarly org.json, commons fileupload and commons io)
>>> are included in the web console...
>>>
>>> Now, this may not be best OSGi practice ....
>>>
>>> Now, exporting this API from the web console sounds like wrong to me.
>>>
>>> Thus I suggest, we change gears and
>>>
>>> * drop the full bundle build
>> 1+
>>> * promote the bare build to be the official build
>> 1+
>>> * thus import org.json, commons fileupload, and commons io
>> 1+ (though we might need OSGi-enabled org.json bundle.
>>> * we may still embed and not export Service Tracker (as could the new
>>> bundles if required) because
>> -1 - why embedding? All OSGi frameworks provide it. Even it it is not
>> provided by the system bundle, you can install a bundle that provides
>> the package. And I think that tracker is widely used, so it could be
>> also imported.
> I know the Felix framework exports it from the system bundle and the
> equinox used to not export it from the system bundle which caused me to
> include it in the first place.
>
> But, I am ok with not embedding it (and importing it instead).
>>> AFAICT there is no need to share these classes.
>>>
>>> Finally to mark this change, we might target the next release to be 4.0.
>> Well it makes sense. People need to update how they use web console and
>> yes - the change is radical, so major version update will warn them that
>> update will not be trivial.
> Excellent. So we have a plan and 3105 and be implemented as such ;-)
>
> Regards
> Felix
>
>>> WDYT ?
>>>
>>> Regards
>>> Felix
>>>
>>>
>> Regards,
>> Valentin
>>
>
>
>
--
-------------------------------------------------
Valentin Valchev · Lead Software Engineer
ProSyst Labs EOOD
1606 Sofia, Bulgaria · 48 Vladajska Str.
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17
http://www.prosyst.com · v.valchev@prosyst.bg
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------
Re: [jira] [Created] (FELIX-3105) WebConsole bundle should export
packages from embedded jars
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
On 07.09.2011 14:35, Valentin Valchev wrote:
> On 7.9.2011 г. 12:35 ч., Felix Meschberger wrote:
>> Hi,
>>
>> On 07.09.2011 08:15, Valentin Valchev (JIRA) wrote:
>>> WebConsole bundle should export packages from embedded jars
>>> Currently webconsole bundle (non bare variant) contains build-in org.json, commons fileupload, commons io, osgi service tracker. These packages should be exported because they will be needed when we move SCR & Deployment Packages plugins in separate jars.
>> I always wanted ot have a single web console plugin with all
>> dependencies included for simple deployment. Which is why these
>> dependencies (particuarly org.json, commons fileupload and commons io)
>> are included in the web console...
>>
>> Now, this may not be best OSGi practice ....
>>
>> Now, exporting this API from the web console sounds like wrong to me.
>>
>> Thus I suggest, we change gears and
>>
>> * drop the full bundle build
> 1+
>> * promote the bare build to be the official build
> 1+
>> * thus import org.json, commons fileupload, and commons io
> 1+ (though we might need OSGi-enabled org.json bundle.
>> * we may still embed and not export Service Tracker (as could the new
>> bundles if required) because
> -1 - why embedding? All OSGi frameworks provide it. Even it it is not
> provided by the system bundle, you can install a bundle that provides
> the package. And I think that tracker is widely used, so it could be
> also imported.
I know the Felix framework exports it from the system bundle and the
equinox used to not export it from the system bundle which caused me to
include it in the first place.
But, I am ok with not embedding it (and importing it instead).
>> AFAICT there is no need to share these classes.
>>
>> Finally to mark this change, we might target the next release to be 4.0.
> Well it makes sense. People need to update how they use web console and
> yes - the change is radical, so major version update will warn them that
> update will not be trivial.
Excellent. So we have a plan and 3105 and be implemented as such ;-)
Regards
Felix
>> WDYT ?
>>
>> Regards
>> Felix
>>
>>
> Regards,
> Valentin
>
Re: [jira] [Created] (FELIX-3105) WebConsole bundle should export
packages from embedded jars
Posted by Valentin Valchev <v_...@prosyst.bg>.
On 7.9.2011 г. 12:35 ч., Felix Meschberger wrote:
> Hi,
>
> On 07.09.2011 08:15, Valentin Valchev (JIRA) wrote:
>> WebConsole bundle should export packages from embedded jars
>> Currently webconsole bundle (non bare variant) contains build-in org.json, commons fileupload, commons io, osgi service tracker. These packages should be exported because they will be needed when we move SCR & Deployment Packages plugins in separate jars.
> I always wanted ot have a single web console plugin with all
> dependencies included for simple deployment. Which is why these
> dependencies (particuarly org.json, commons fileupload and commons io)
> are included in the web console...
>
> Now, this may not be best OSGi practice ....
>
> Now, exporting this API from the web console sounds like wrong to me.
>
> Thus I suggest, we change gears and
>
> * drop the full bundle build
1+
> * promote the bare build to be the official build
1+
> * thus import org.json, commons fileupload, and commons io
1+ (though we might need OSGi-enabled org.json bundle.
> * we may still embed and not export Service Tracker (as could the new
> bundles if required) because
-1 - why embedding? All OSGi frameworks provide it. Even it it is not
provided by the system bundle, you can install a bundle that provides
the package. And I think that tracker is widely used, so it could be
also imported.
> AFAICT there is no need to share these classes.
>
> Finally to mark this change, we might target the next release to be 4.0.
Well it makes sense. People need to update how they use web console and
yes - the change is radical, so major version update will warn them that
update will not be trivial.
>
> WDYT ?
>
> Regards
> Felix
>
>
Regards,
Valentin
--
-------------------------------------------------
Valentin Valchev · Lead Software Engineer
ProSyst Labs EOOD
1606 Sofia, Bulgaria · 48 Vladajska Str.
Tel. +359 (0)2 952 35 81; Fax +359 (0)2 953 26 17
http://www.prosyst.com · v.valchev@prosyst.bg
-------------------------------------------------
stay in touch with your product.
-------------------------------------------------
Re: [jira] [Created] (FELIX-3105) WebConsole bundle should export
packages from embedded jars
Posted by Felix Meschberger <fm...@adobe.com>.
Hi,
On 07.09.2011 08:15, Valentin Valchev (JIRA) wrote:
> WebConsole bundle should export packages from embedded jars
> Currently webconsole bundle (non bare variant) contains build-in org.json, commons fileupload, commons io, osgi service tracker. These packages should be exported because they will be needed when we move SCR & Deployment Packages plugins in separate jars.
I always wanted ot have a single web console plugin with all
dependencies included for simple deployment. Which is why these
dependencies (particuarly org.json, commons fileupload and commons io)
are included in the web console...
Now, this may not be best OSGi practice ....
Now, exporting this API from the web console sounds like wrong to me.
Thus I suggest, we change gears and
* drop the full bundle build
* promote the bare build to be the official build
* thus import org.json, commons fileupload, and commons io
* we may still embed and not export Service Tracker (as could the new
bundles if required) because
AFAICT there is no need to share these classes.
Finally to mark this change, we might target the next release to be 4.0.
WDYT ?
Regards
Felix
[jira] [Closed] (FELIX-3105) WebConsole bundle should export
packages from embedded jars
Posted by "Felix Meschberger (Closed) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger closed FELIX-3105.
------------------------------------
Nothing more to do here.
> WebConsole bundle should export packages from embedded jars
> -----------------------------------------------------------
>
> Key: FELIX-3105
> URL: https://issues.apache.org/jira/browse/FELIX-3105
> Project: Felix
> Issue Type: Bug
> Components: Web Console
> Affects Versions: webconsole-3.1.8
> Reporter: Valentin Valchev
> Assignee: Felix Meschberger
> Priority: Blocker
>
> Currently webconsole bundle (non bare variant) contains build-in org.json, commons fileupload, commons io, osgi service tracker. These packages should be exported because they will be needed when we move SCR & Deployment Packages plugins in separate jars.
> Until that is done, I cannot finish separation of the plugins.
> Felix, WHYT? Shall we do that? If yes - just reassign the issue to me.
> See also:
> https://issues.apache.org/jira/browse/FELIX-3099
> https://issues.apache.org/jira/browse/FELIX-3100
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (FELIX-3105) WebConsole bundle should export
packages from embedded jars
Posted by "Felix Meschberger (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/FELIX-3105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Felix Meschberger resolved FELIX-3105.
--------------------------------------
Resolution: Won't Fix
Fix Version/s: (was: webconsole-3.2.0)
By dropping the full build as of FELIX-3279 we don't need to fix this.
> WebConsole bundle should export packages from embedded jars
> -----------------------------------------------------------
>
> Key: FELIX-3105
> URL: https://issues.apache.org/jira/browse/FELIX-3105
> Project: Felix
> Issue Type: Bug
> Components: Web Console
> Affects Versions: webconsole-3.1.8
> Reporter: Valentin Valchev
> Assignee: Felix Meschberger
> Priority: Blocker
>
> Currently webconsole bundle (non bare variant) contains build-in org.json, commons fileupload, commons io, osgi service tracker. These packages should be exported because they will be needed when we move SCR & Deployment Packages plugins in separate jars.
> Until that is done, I cannot finish separation of the plugins.
> Felix, WHYT? Shall we do that? If yes - just reassign the issue to me.
> See also:
> https://issues.apache.org/jira/browse/FELIX-3099
> https://issues.apache.org/jira/browse/FELIX-3100
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira