4.3 support for startlevels

24 views
Skip to first unread message

Scott Lewis

unread,
Oct 16, 2019, 8:47:45 PM10/16/19
to bndtools-dev
Thanks for the support for startlevels in 4.3...i.e as documented for bnd here:


wrt the -runstartlevel instruction as documented here:  https://bnd.bndtools.org/instructions/runstartlevel.html

1) Is it possible to define the -runbundles contents (including startlevels) by hand?...i.e. rather than using one the bnd/bndtools resolve and the order types?

2) If the answer is 'yes' about hand-creating the start-levels and other info in -runbundles:  Is there some way to prevent the subsequent over-writing of the -runbundles information...whether resolution is done by command line bnd or bndtools (e.g. disable the Resolve)?   As if hand-created one possibly wouldn't want the next Resolve to write over.

3) Is there a way to introduce new/other order types?

Thanksinadvance.


Peter Kriens

unread,
Oct 21, 2019, 2:36:18 AM10/21/19
to bndtoo...@googlegroups.com
On 17 Oct 2019, at 02:47, Scott Lewis <scott...@gmail.com> wrote:
Thanks for the support for startlevels in 4.3...i.e as documented for bnd here:
wrt the -runstartlevel instruction as documented here:  https://bnd.bndtools.org/instructions/runstartlevel.html

1) Is it possible to define the -runbundles contents (including startlevels) by hand?...i.e. rather than using one the bnd/bndtools resolve and the order types?
Yes, you can just set -runbundles manually. Just don't use the resolve button.


2) If the answer is 'yes' about hand-creating the start-levels and other info in -runbundles:  Is there some way to prevent the subsequent over-writing of the -runbundles information...whether resolution is done by command line bnd or bndtools (e.g. disable the Resolve)?   As if hand-created one possibly wouldn't want the next Resolve to write over.
Well, you can set -runbundles.manual for example. However, if you accidentally use the resolve function you will get the value of -runbundles.manual and -runbundles.

3) Is there a way to introduce new/other order types?
Yes, file an issue :-) The ordering requires code and is therefore restricted to changes in the code base. 

Kind regards,

Peter Kriens


Thanksinadvance.



--
You received this message because you are subscribed to the Google Groups "bndtools-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/bndtools-dev/fed119e4-2105-4d56-a3f3-cd5201ddb876%40googlegroups.com.

Scott Lewis

unread,
Oct 21, 2019, 5:25:34 PM10/21/19
to bndtools-dev

On Sunday, October 20, 2019 at 11:36:18 PM UTC-7, peter.kriens wrote:
<stuff deleted>
 
 2) If the answer is 'yes' about hand-creating the start-levels and other info in -runbundles:  Is there some way to prevent the subsequent over-writing of the -runbundles information...whether resolution is done by command line bnd or bndtools (e.g. disable the Resolve)?   As if hand-created one possibly wouldn't want the next Resolve to write over.
Well, you can set -runbundles.manual for example. However, if you accidentally use the resolve function you will get the value of -runbundles.manual and -runbundles.

 I can't immediately find the docs on the behavior of -runbundles.manual.  Are there docs for it somewhere?

3) Is there a way to introduce new/other order types?
Yes, file an issue :-) The ordering requires code and is therefore restricted to changes in the code base. 

How about supporting a properties file...e.g.:

org.my.company.foo=20

where 20 is the start-level for org.my.company.foo bundle?   Or maybe even:

org.my.*=25

Possibly in combination with the existing ones?  (e.g. done after the whatever auto-generation is selected)?  I imagine bundle version needs to be supported for generality.

I'm open to alternatives about this if they fit better with bnd/bndtools, and willing to assist in impl if you point me in the right code directions.   I'm just looking for something that won't force existing working apps to rework their start levels in order to use bndtools to develop and test new bundles. 

Scott

Peter Kriens

unread,
Oct 22, 2019, 3:13:58 AM10/22/19
to bndtoo...@googlegroups.com
On 21 Oct 2019, at 23:25, Scott Lewis <scott...@gmail.com> wrote:
On Sunday, October 20, 2019 at 11:36:18 PM UTC-7, peter.kriens wrote:
<stuff deleted> 
 2) If the answer is 'yes' about hand-creating the start-levels and other info in -runbundles:  Is there some way to prevent the subsequent over-writing of the -runbundles information...whether resolution is done by command line bnd or bndtools (e.g. disable the Resolve)?   As if hand-created one possibly wouldn't want the next Resolve to write over.
Well, you can set -runbundles.manual for example. However, if you accidentally use the resolve function you will get the value of -runbundles.manual and -runbundles.
 I can't immediately find the docs on the behavior of -runbundles.manual.  Are there docs for it somewhere?
-runbundles is a _merged instruction. This means that when bnd uses this instruction it merges it with all properties that match `-runbundles*`. See


3) Is there a way to introduce new/other order types?
Yes, file an issue :-) The ordering requires code and is therefore restricted to changes in the code base. 
How about supporting a properties file...e.g.:
org.my.company.foo=20

where 20 is the start-level for org.my.company.foo bundle?   Or maybe even:

org.my.*=25
Did you read:


You can use `-runbundles+` to assign start levels to specific bundles by matching with a glob their bundle symbolic name. This should do exactly what you want. If you missed that, did you read


Kind regards,

Peter Kriens




Possibly in combination with the existing ones?  (e.g. done after the whatever auto-generation is selected)?  I imagine bundle version needs to be supported for generality.

I'm open to alternatives about this if they fit better with bnd/bndtools, and willing to assist in impl if you point me in the right code directions.   I'm just looking for something that won't force existing working apps to rework their start levels in order to use bndtools to develop and test new bundles. 

Scott


--
You received this message because you are subscribed to the Google Groups "bndtools-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bndtools-dev...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages