Created attachment 33576 [details]
patch to implement this

cmc->hjs: What do you think ? Can I put this in ?

patch looks reasonable to me. but  you should try to get a word from is on this :)

IS: I suppose the patch will work and bring fast good results. But you kill much
functionality of the very general method  "get_all_items_from_script". 
This method simply collects all key - value pairs.  You can define all key -
value pairs language specific.

Key (de) = "abc";
Key (en-US) = "def";
Value (de) = "ghi";
Value (en-US) = "jkl";

Your patch does not support this language functionality.  I think, this is never
used for ProfileItems, but currently it can be used. Besides it is used for many
other scp items (files, dirs, ...).

Another solution is possible:  The file jvmfwk3.ini does not cotain any dynamic
part, that has to be exchanged during packing or installation process. Therefore
it could be possible to change jvmfwk3.ini from a Profile to a File in scp2, to
deliver it and to pack it like most other files.
Then the content of this file can be changed independently from any scp
restrictions. 

the underlying problem isn't limited to this case (jvmfwk3.ini). all keys (left
side) where the value (right side) is some kind of list will require something
simila once the desire pops up to modify this list based on settings in the
build environment.

if this is that generic, why not introduce a

(key_name_pattern)(language_pattern) = multiple
(key_name_pattern)List(language_pattern)

mapping? could be a cheap way to introduce a generic list mechanism without
changing the processing all over the complete script.

This seems to be much functionality for a little collector function. I do not
think that get_all_items_from_script is a good place for this. What happens if
"Value" is language dependent and "ValueList" not? Or vice versa? There are
other functions called later that take care of this language stuff.
get_all_items_from_script only has to collect all the content.
I do not think that it is a good idea to duplicate all this language specific code.

And do we really need a global "List" mechanism for all possible keys? For Name,
Style, Date, Order, ...? And do we always want to control whether there is a
correlated List-entry for all of this keys? I suppose a much simpler solution:

First of all we need keys with unique names for the ValueLists. Otherwise only
the last  ValueList would survive get_all_items_from_script.

<code>

ProfileItem gid_Profileitem_Jvmfwk_Uno_Java_Jfw_Classpath_Urls
    ProfileID = gid_Profile_Jvmfwk_Ini;
    ModuleID = gid_Module_Root;
    Section = "Bootstrap";
    Order = 7;
    Key = "UNO_JAVA_JFW_CLASSPATH_URLS";
    Value = "${${$ORIGIN/$UNO_SETTINGS:PKG_UserUnoFile}
    ValueList1 = ${${$ORIGIN/$UNO_SETTINGS:PKG_SharedUnoFile}
    ValueList2 = $ORIGIN/classes/jurt.jar
    ValueList3 = $ORIGIN/classes/sandbox.jar
    ValueList4 = $ORIGIN/classes/commonwizards.jar 
End

</code>

Then all the normal processing happens, until everything is evaluated and the
File is really created. This happens in create_profiles in profiles.pm.

Instead of simply using the existing value:

<code>
my $value = $oneprofileitem->{'Value'};
</code>

it would now be possible to add all existing ValueLists (separated by blanks?).

<code>
my $value = $oneprofileitem->{'Value'};
for ( my $j = 1; $j <= 10; $j++ )
{
    my $key = "ValueList" . $j;
    if ( $oneprofileitem->{$key} ) { $value = $value . " " .
$oneprofileitem->{$key}; }
</code>

Using the for-loop an ordering of different ValueLists can be introduced. And of
course the maximum number should be determined before. But perhaps you prefer a
foreach without ordering.
Anyhow, I would prefer such a version, where the value is determined as late as
possible.

Created attachment 33620 [details]
patch 2

So would that alternative patch be acceptable to everyone ?

For me this patch is acceptable (but please do not use the variable "j" because
it is already used in the surrounding loop).

accepted for consideration post jaxpapi integration

done in systemjava

reopen for qa

ready for qa

back to fixed

ok

.