Re: svn commit: r669994 - in /ofbiz/trunk: applications/party/config/ applications/party/webapp/partymgr/party/ framework/common/config/ framework/common/servicedef/ framework/common/src/org/ofbiz/common/login/ framework/security/config/ framework/se

[Bruno Busco]

David,
I think it will be beneficial to all contributors to have a list of what we
would like to have included in the framework-only release, don't you?

It will tell how far we are and to have, generally, more efforts on these
tasks.
Why don't define the framework-only version in JIRA and schedule for that
the task-list ?

Thank you,
-Bruno

2008/6/20 David E Jones <[hidden email]>:

>
> This looks good Adrian, thanks for working on it.
>
> This was on my own little list of things I'd like to see added to the
> framework before we do the framework-only release, so I'm really happy to
> see it in!
>
> -David
>
>
> On Jun 20, 2008, at 11:09 AM, [hidden email] wrote:
>
>  Author: adrianc
>> Date: Fri Jun 20 10:09:19 2008
>> New Revision: 669994
>>
>> URL: http://svn.apache.org/viewvc?rev=669994&view=rev
>> Log:
>> Added LDAP user authentication, based on work contributed by Mohamed Amine
>> Azzi and Torsten Schlabach -
>> https://issues.apache.org/jira/browse/OFBIZ-811.
>>
>> Internationalization note: this commit contains new UI labels.
>>
>> Added:
>>
>> ofbiz/trunk/framework/common/src/org/ofbiz/common/login/LdapAuthenticationServices.java
>>   (with props)
>>   ofbiz/trunk/framework/security/config/jndiLdap.properties   (with props)
>> Modified:
>>   ofbiz/trunk/applications/party/config/PartyUiLabels.xml
>>   ofbiz/trunk/applications/party/webapp/partymgr/party/PartyForms.xml
>>   ofbiz/trunk/framework/common/config/SecurityextUiLabels.xml
>>   ofbiz/trunk/framework/common/servicedef/services.xml
>>
>> ofbiz/trunk/framework/common/src/org/ofbiz/common/login/LoginServices.java
>>   ofbiz/trunk/framework/security/config/security.properties
>>   ofbiz/trunk/framework/security/entitydef/entitymodel.xml
>>
>
>

[Jacques Le Roux]

This sounds like a good idea, maybe a wiki page like http://docs.ofbiz.org/display/OFBADMIN/New+Features+Roadmap+-+Living+Document 
would be better ?

Jacques

From: "Bruno Busco" <[hidden email]>

> David,
> I think it will be beneficial to all contributors to have a list of what we
> would like to have included in the framework-only release, don't you?
>
> It will tell how far we are and to have, generally, more efforts on these
> tasks.
> Why don't define the framework-only version in JIRA and schedule for that
> the task-list ?
>
> Thank you,
> -Bruno
>
> 2008/6/20 David E Jones <[hidden email]>:
>
>>
>> This looks good Adrian, thanks for working on it.
>>
>> This was on my own little list of things I'd like to see added to the
>> framework before we do the framework-only release, so I'm really happy to
>> see it in!
>>
>> -David
>>
>>
>> On Jun 20, 2008, at 11:09 AM, [hidden email] wrote:
>>
>>  Author: adrianc
>>> Date: Fri Jun 20 10:09:19 2008
>>> New Revision: 669994
>>>
>>> URL: http://svn.apache.org/viewvc?rev=669994&view=rev
>>> Log:
>>> Added LDAP user authentication, based on work contributed by Mohamed Amine
>>> Azzi and Torsten Schlabach -
>>> https://issues.apache.org/jira/browse/OFBIZ-811.
>>>
>>> Internationalization note: this commit contains new UI labels.
>>>
>>> Added:
>>>
>>> ofbiz/trunk/framework/common/src/org/ofbiz/common/login/LdapAuthenticationServices.java
>>>   (with props)
>>>   ofbiz/trunk/framework/security/config/jndiLdap.properties   (with props)
>>> Modified:
>>>   ofbiz/trunk/applications/party/config/PartyUiLabels.xml
>>>   ofbiz/trunk/applications/party/webapp/partymgr/party/PartyForms.xml
>>>   ofbiz/trunk/framework/common/config/SecurityextUiLabels.xml
>>>   ofbiz/trunk/framework/common/servicedef/services.xml
>>>
>>> ofbiz/trunk/framework/common/src/org/ofbiz/common/login/LoginServices.java
>>>   ofbiz/trunk/framework/security/config/security.properties
>>>   ofbiz/trunk/framework/security/entitydef/entitymodel.xml
>>>
>>
>>
>

[Jacopo Cappellato-3]

I think that Bruno's suggestion of creating a "framework-candidate-
release-x" version in Jira would be useful, especially because there  
is no official (or even unofficial) list of features/fixes to go in  
the framework... probably each of us has its own preferences.
Of course we should try to keep the list small.

Jacopo

On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:

> David,
> I think it will be beneficial to all contributors to have a list of  
> what we
> would like to have included in the framework-only release, don't you?
>
> It will tell how far we are and to have, generally, more efforts on  
> these
> tasks.
> Why don't define the framework-only version in JIRA and schedule for  
> that
> the task-list ?
>
> Thank you,
> -Bruno
>
> 2008/6/20 David E Jones <[hidden email]>:
>
>>
>> This looks good Adrian, thanks for working on it.
>>
>> This was on my own little list of things I'd like to see added to the
>> framework before we do the framework-only release, so I'm really  
>> happy to
>> see it in!
>>
>> -David
>>
>>
>>

[David E Jones]

Like Jacopo hinted at, this is a community-driven effort and is  
therefore a bit chaotic.

The main thing I was requesting from the community is to focus on the  
framework for a little while so we can stabilize and clean up the  
framework in preparation for a binary release of it (leading toward a  
good binary release of the whole project... but starting with  
something smaller and easier).

Anyway, I do have a list of things I've been thinking about and  
collecting, some from years ago. What I want to avoid though is making  
my list the official list, or even any sort of majority of the  
official list. In other words, I want this to be a community effort  
more than I want to have everything on my pet list done.

Still, I do like the idea of starting to compile a list of things we'd  
all like to see go into the framework, and it's probably about time to  
do that rather than having more random (less communicated) efforts on  
different things.

I'm thinking that a confluence/wiki page might be a better place for  
now though, given the tentative nature of some of these things, and  
often a need for discussion before more concrete plans are made.

What do others think of this?

-David


On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote:

> I think that Bruno's suggestion of creating a "framework-candidate-
> release-x" version in Jira would be useful, especially because there  
> is no official (or even unofficial) list of features/fixes to go in  
> the framework... probably each of us has its own preferences.
> Of course we should try to keep the list small.
>
> Jacopo
>
> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>
>> David,
>> I think it will be beneficial to all contributors to have a list of  
>> what we
>> would like to have included in the framework-only release, don't you?
>>
>> It will tell how far we are and to have, generally, more efforts on  
>> these
>> tasks.
>> Why don't define the framework-only version in JIRA and schedule  
>> for that
>> the task-list ?
>>
>> Thank you,
>> -Bruno
>>
>> 2008/6/20 David E Jones <[hidden email]>:
>>
>>>
>>> This looks good Adrian, thanks for working on it.
>>>
>>> This was on my own little list of things I'd like to see added to  
>>> the
>>> framework before we do the framework-only release, so I'm really  
>>> happy to
>>> see it in!
>>>
>>> -David
>>>
>>>
>>>
>

[Jacques Le Roux]

+1 for Confluence
BTW, should we not add a <call-groovy> in minilang (or did I miss something) ?

Jacques

From: "David E Jones" <[hidden email]>

>
> Like Jacopo hinted at, this is a community-driven effort and is  
> therefore a bit chaotic.
>
> The main thing I was requesting from the community is to focus on the  
> framework for a little while so we can stabilize and clean up the  
> framework in preparation for a binary release of it (leading toward a  
> good binary release of the whole project... but starting with  
> something smaller and easier).
>
> Anyway, I do have a list of things I've been thinking about and  
> collecting, some from years ago. What I want to avoid though is making  
> my list the official list, or even any sort of majority of the  
> official list. In other words, I want this to be a community effort  
> more than I want to have everything on my pet list done.
>
> Still, I do like the idea of starting to compile a list of things we'd  
> all like to see go into the framework, and it's probably about time to  
> do that rather than having more random (less communicated) efforts on  
> different things.
>
> I'm thinking that a confluence/wiki page might be a better place for  
> now though, given the tentative nature of some of these things, and  
> often a need for discussion before more concrete plans are made.
>
> What do others think of this?
>
> -David
>
>
> On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote:
>
>> I think that Bruno's suggestion of creating a "framework-candidate-
>> release-x" version in Jira would be useful, especially because there  
>> is no official (or even unofficial) list of features/fixes to go in  
>> the framework... probably each of us has its own preferences.
>> Of course we should try to keep the list small.
>>
>> Jacopo
>>
>> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>>
>>> David,
>>> I think it will be beneficial to all contributors to have a list of  
>>> what we
>>> would like to have included in the framework-only release, don't you?
>>>
>>> It will tell how far we are and to have, generally, more efforts on  
>>> these
>>> tasks.
>>> Why don't define the framework-only version in JIRA and schedule  
>>> for that
>>> the task-list ?
>>>
>>> Thank you,
>>> -Bruno
>>>
>>> 2008/6/20 David E Jones <[hidden email]>:
>>>
>>>>
>>>> This looks good Adrian, thanks for working on it.
>>>>
>>>> This was on my own little list of things I'd like to see added to  
>>>> the
>>>> framework before we do the framework-only release, so I'm really  
>>>> happy to
>>>> see it in!
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>
>

[Ashish Vijaywargiya]

+1 for adding <call-groovy> in minilang.

I can work on it in my free time as voluntarily if we would like to include
it in framework release.
Please let me know your thoughts on it.

--
Ashish


On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux <
[hidden email]> wrote:

> +1 for Confluence
> BTW, should we not add a <call-groovy> in minilang (or did I miss
> something) ?
>
> Jacques
>
> From: "David E Jones" <[hidden email]>
>
>
>> Like Jacopo hinted at, this is a community-driven effort and is  therefore
>> a bit chaotic.
>>
>> The main thing I was requesting from the community is to focus on the
>>  framework for a little while so we can stabilize and clean up the
>>  framework in preparation for a binary release of it (leading toward a  good
>> binary release of the whole project... but starting with  something smaller
>> and easier).
>>
>> Anyway, I do have a list of things I've been thinking about and
>>  collecting, some from years ago. What I want to avoid though is making  my
>> list the official list, or even any sort of majority of the  official list.
>> In other words, I want this to be a community effort  more than I want to
>> have everything on my pet list done.
>>
>> Still, I do like the idea of starting to compile a list of things we'd
>>  all like to see go into the framework, and it's probably about time to  do
>> that rather than having more random (less communicated) efforts on
>>  different things.
>>
>> I'm thinking that a confluence/wiki page might be a better place for  now
>> though, given the tentative nature of some of these things, and  often a
>> need for discussion before more concrete plans are made.
>>
>> What do others think of this?
>>
>> -David
>>
>>
>> On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote:
>>
>>  I think that Bruno's suggestion of creating a "framework-candidate-
>>> release-x" version in Jira would be useful, especially because there  is no
>>> official (or even unofficial) list of features/fixes to go in  the
>>> framework... probably each of us has its own preferences.
>>> Of course we should try to keep the list small.
>>>
>>> Jacopo
>>>
>>> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>>>
>>>  David,
>>>> I think it will be beneficial to all contributors to have a list of
>>>>  what we
>>>> would like to have included in the framework-only release, don't you?
>>>>
>>>> It will tell how far we are and to have, generally, more efforts on
>>>>  these
>>>> tasks.
>>>> Why don't define the framework-only version in JIRA and schedule  for
>>>> that
>>>> the task-list ?
>>>>
>>>> Thank you,
>>>> -Bruno
>>>>
>>>> 2008/6/20 David E Jones <[hidden email]>:
>>>>
>>>>
>>>>> This looks good Adrian, thanks for working on it.
>>>>>
>>>>> This was on my own little list of things I'd like to see added to  the
>>>>> framework before we do the framework-only release, so I'm really  happy
>>>>> to
>>>>> see it in!
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>>>
>>>
>>

[Jacopo Cappellato-3]

What if we just add a <call-script/> element instead?

We could then replace all the <call-bsh /> element to the new one.
The new one will use the file suffix to use the proper Processor  
(.groovy, .bsh etc...)
And we may add an optional parameter for the type ("groovy", "bsh"  
etc... that can be used if the script files don't have the right  
suffix).

For example

<call-script location="component://pathtoscript/myscript.groovy"/>
<call-script location="component://pathtoscript/myscript.bsh"/>
<call-script location="component://pathtoscript/mygroovyscript.grv"  
type="groovy"/>

Jacopo



On Jun 26, 2008, at 11:10 AM, Ashish Vijaywargiya wrote:

> +1 for adding <call-groovy> in minilang.
>
> I can work on it in my free time as voluntarily if we would like to  
> include
> it in framework release.
> Please let me know your thoughts on it.
>
> --
> Ashish
>
>
> On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> +1 for Confluence
>> BTW, should we not add a <call-groovy> in minilang (or did I miss
>> something) ?
>>
>> Jacques
>>
>> From: "David E Jones" <[hidden email]>
>>
>>
>>> Like Jacopo hinted at, this is a community-driven effort and is  
>>> therefore
>>> a bit chaotic.
>>>
>>> The main thing I was requesting from the community is to focus on  
>>> the
>>> framework for a little while so we can stabilize and clean up the
>>> framework in preparation for a binary release of it (leading  
>>> toward a  good
>>> binary release of the whole project... but starting with  
>>> something smaller
>>> and easier).
>>>
>>> Anyway, I do have a list of things I've been thinking about and
>>> collecting, some from years ago. What I want to avoid though is  
>>> making  my
>>> list the official list, or even any sort of majority of the  
>>> official list.
>>> In other words, I want this to be a community effort  more than I  
>>> want to
>>> have everything on my pet list done.
>>>
>>> Still, I do like the idea of starting to compile a list of things  
>>> we'd
>>> all like to see go into the framework, and it's probably about  
>>> time to  do
>>> that rather than having more random (less communicated) efforts on
>>> different things.
>>>
>>> I'm thinking that a confluence/wiki page might be a better place  
>>> for  now
>>> though, given the tentative nature of some of these things, and  
>>> often a
>>> need for discussion before more concrete plans are made.
>>>
>>> What do others think of this?
>>>
>>> -David
>>>
>>>
>>> On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote:
>>>
>>> I think that Bruno's suggestion of creating a "framework-candidate-
>>>> release-x" version in Jira would be useful, especially because  
>>>> there  is no
>>>> official (or even unofficial) list of features/fixes to go in  the
>>>> framework... probably each of us has its own preferences.
>>>> Of course we should try to keep the list small.
>>>>
>>>> Jacopo
>>>>
>>>> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>>>>
>>>> David,
>>>>> I think it will be beneficial to all contributors to have a list  
>>>>> of
>>>>> what we
>>>>> would like to have included in the framework-only release, don't  
>>>>> you?
>>>>>
>>>>> It will tell how far we are and to have, generally, more efforts  
>>>>> on
>>>>> these
>>>>> tasks.
>>>>> Why don't define the framework-only version in JIRA and  
>>>>> schedule  for
>>>>> that
>>>>> the task-list ?
>>>>>
>>>>> Thank you,
>>>>> -Bruno
>>>>>
>>>>> 2008/6/20 David E Jones <[hidden email]>:
>>>>>
>>>>>
>>>>>> This looks good Adrian, thanks for working on it.
>>>>>>
>>>>>> This was on my own little list of things I'd like to see added  
>>>>>> to  the
>>>>>> framework before we do the framework-only release, so I'm  
>>>>>> really  happy
>>>>>> to
>>>>>> see it in!
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>

[Ashish Vijaywargiya]

Jacopo I liked the idea while we include the script file in Screen
Definition.
But if you will notice Jacques was talking about the Mini Lang call-bsh
replacement to call-groovy.

Please let me know your thoughts in reference to Mini Lang.
Thanks !

--
Ashish


On Thu, Jun 26, 2008 at 5:34 AM, Jacopo Cappellato <
[hidden email]> wrote:

> What if we just add a <call-script/> element instead?
>
> We could then replace all the <call-bsh /> element to the new one.
> The new one will use the file suffix to use the proper Processor (.groovy,
> .bsh etc...)
> And we may add an optional parameter for the type ("groovy", "bsh" etc...
> that can be used if the script files don't have the right suffix).
>
> For example
>
> <call-script location="component://pathtoscript/myscript.groovy"/>
> <call-script location="component://pathtoscript/myscript.bsh"/>
> <call-script location="component://pathtoscript/mygroovyscript.grv"
> type="groovy"/>
>
> Jacopo
>
>
>
>
> On Jun 26, 2008, at 11:10 AM, Ashish Vijaywargiya wrote:
>
>  +1 for adding <call-groovy> in minilang.
>>
>> I can work on it in my free time as voluntarily if we would like to
>> include
>> it in framework release.
>> Please let me know your thoughts on it.
>>
>> --
>> Ashish
>>
>>
>> On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux <
>> [hidden email]> wrote:
>>
>>  +1 for Confluence
>>> BTW, should we not add a <call-groovy> in minilang (or did I miss
>>> something) ?
>>>
>>> Jacques
>>>
>>> From: "David E Jones" <[hidden email]>
>>>
>>>
>>>  Like Jacopo hinted at, this is a community-driven effort and is
>>>>  therefore
>>>> a bit chaotic.
>>>>
>>>> The main thing I was requesting from the community is to focus on the
>>>> framework for a little while so we can stabilize and clean up the
>>>> framework in preparation for a binary release of it (leading toward a
>>>>  good
>>>> binary release of the whole project... but starting with  something
>>>> smaller
>>>> and easier).
>>>>
>>>> Anyway, I do have a list of things I've been thinking about and
>>>> collecting, some from years ago. What I want to avoid though is making
>>>>  my
>>>> list the official list, or even any sort of majority of the  official
>>>> list.
>>>> In other words, I want this to be a community effort  more than I want
>>>> to
>>>> have everything on my pet list done.
>>>>
>>>> Still, I do like the idea of starting to compile a list of things we'd
>>>> all like to see go into the framework, and it's probably about time to
>>>>  do
>>>> that rather than having more random (less communicated) efforts on
>>>> different things.
>>>>
>>>> I'm thinking that a confluence/wiki page might be a better place for
>>>>  now
>>>> though, given the tentative nature of some of these things, and  often a
>>>> need for discussion before more concrete plans are made.
>>>>
>>>> What do others think of this?
>>>>
>>>> -David
>>>>
>>>>
>>>> On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote:
>>>>
>>>> I think that Bruno's suggestion of creating a "framework-candidate-
>>>>
>>>>> release-x" version in Jira would be useful, especially because there
>>>>>  is no
>>>>> official (or even unofficial) list of features/fixes to go in  the
>>>>> framework... probably each of us has its own preferences.
>>>>> Of course we should try to keep the list small.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>>>>>
>>>>> David,
>>>>>
>>>>>> I think it will be beneficial to all contributors to have a list of
>>>>>> what we
>>>>>> would like to have included in the framework-only release, don't you?
>>>>>>
>>>>>> It will tell how far we are and to have, generally, more efforts on
>>>>>> these
>>>>>> tasks.
>>>>>> Why don't define the framework-only version in JIRA and schedule  for
>>>>>> that
>>>>>> the task-list ?
>>>>>>
>>>>>> Thank you,
>>>>>> -Bruno
>>>>>>
>>>>>> 2008/6/20 David E Jones <[hidden email]>:
>>>>>>
>>>>>>
>>>>>>  This looks good Adrian, thanks for working on it.
>>>>>>>
>>>>>>> This was on my own little list of things I'd like to see added to
>>>>>>>  the
>>>>>>> framework before we do the framework-only release, so I'm really
>>>>>>>  happy
>>>>>>> to
>>>>>>> see it in!
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>
>>>>
>

[Jacopo Cappellato-3]

Ashish,

yes, what I meant that we could implement the new Minilang operation:  
"call-script"

That operation could then be used to replace the existing "call-bsh"  
operation (that could be deprecated) and also it will be used to call  
Groovy scripts.

Jacopo


On Jun 26, 2008, at 11:54 AM, Ashish Vijaywargiya wrote:

> Jacopo I liked the idea while we include the script file in Screen
> Definition.
> But if you will notice Jacques was talking about the Mini Lang call-
> bsh
> replacement to call-groovy.
>
> Please let me know your thoughts in reference to Mini Lang.
> Thanks !
>
> --
> Ashish
>
>
> On Thu, Jun 26, 2008 at 5:34 AM, Jacopo Cappellato <
> [hidden email]> wrote:
>
>> What if we just add a <call-script/> element instead?
>>
>> We could then replace all the <call-bsh /> element to the new one.
>> The new one will use the file suffix to use the proper Processor  
>> (.groovy,
>> .bsh etc...)
>> And we may add an optional parameter for the type ("groovy", "bsh"  
>> etc...
>> that can be used if the script files don't have the right suffix).
>>
>> For example
>>
>> <call-script location="component://pathtoscript/myscript.groovy"/>
>> <call-script location="component://pathtoscript/myscript.bsh"/>
>> <call-script location="component://pathtoscript/mygroovyscript.grv"
>> type="groovy"/>
>>
>> Jacopo
>>
>>
>>
>>
>> On Jun 26, 2008, at 11:10 AM, Ashish Vijaywargiya wrote:
>>
>> +1 for adding <call-groovy> in minilang.
>>>
>>> I can work on it in my free time as voluntarily if we would like to
>>> include
>>> it in framework release.
>>> Please let me know your thoughts on it.
>>>
>>> --
>>> Ashish
>>>
>>>
>>> On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux <
>>> [hidden email]> wrote:
>>>
>>> +1 for Confluence
>>>> BTW, should we not add a <call-groovy> in minilang (or did I miss
>>>> something) ?
>>>>
>>>> Jacques
>>>>
>>>> From: "David E Jones" <[hidden email]>
>>>>
>>>>
>>>> Like Jacopo hinted at, this is a community-driven effort and is
>>>>> therefore
>>>>> a bit chaotic.
>>>>>
>>>>> The main thing I was requesting from the community is to focus  
>>>>> on the
>>>>> framework for a little while so we can stabilize and clean up the
>>>>> framework in preparation for a binary release of it (leading  
>>>>> toward a
>>>>> good
>>>>> binary release of the whole project... but starting with  
>>>>> something
>>>>> smaller
>>>>> and easier).
>>>>>
>>>>> Anyway, I do have a list of things I've been thinking about and
>>>>> collecting, some from years ago. What I want to avoid though is  
>>>>> making
>>>>> my
>>>>> list the official list, or even any sort of majority of the  
>>>>> official
>>>>> list.
>>>>> In other words, I want this to be a community effort  more than  
>>>>> I want
>>>>> to
>>>>> have everything on my pet list done.
>>>>>
>>>>> Still, I do like the idea of starting to compile a list of  
>>>>> things we'd
>>>>> all like to see go into the framework, and it's probably about  
>>>>> time to
>>>>> do
>>>>> that rather than having more random (less communicated) efforts on
>>>>> different things.
>>>>>
>>>>> I'm thinking that a confluence/wiki page might be a better place  
>>>>> for
>>>>> now
>>>>> though, given the tentative nature of some of these things, and  
>>>>> often a
>>>>> need for discussion before more concrete plans are made.
>>>>>
>>>>> What do others think of this?
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>> On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote:
>>>>>
>>>>> I think that Bruno's suggestion of creating a "framework-
>>>>> candidate-
>>>>>
>>>>>> release-x" version in Jira would be useful, especially because  
>>>>>> there
>>>>>> is no
>>>>>> official (or even unofficial) list of features/fixes to go in  
>>>>>> the
>>>>>> framework... probably each of us has its own preferences.
>>>>>> Of course we should try to keep the list small.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>>>>>>
>>>>>> David,
>>>>>>
>>>>>>> I think it will be beneficial to all contributors to have a  
>>>>>>> list of
>>>>>>> what we
>>>>>>> would like to have included in the framework-only release,  
>>>>>>> don't you?
>>>>>>>
>>>>>>> It will tell how far we are and to have, generally, more  
>>>>>>> efforts on
>>>>>>> these
>>>>>>> tasks.
>>>>>>> Why don't define the framework-only version in JIRA and  
>>>>>>> schedule  for
>>>>>>> that
>>>>>>> the task-list ?
>>>>>>>
>>>>>>> Thank you,
>>>>>>> -Bruno
>>>>>>>
>>>>>>> 2008/6/20 David E Jones <[hidden email]>:
>>>>>>>
>>>>>>>
>>>>>>> This looks good Adrian, thanks for working on it.
>>>>>>>>
>>>>>>>> This was on my own little list of things I'd like to see  
>>>>>>>> added to
>>>>>>>> the
>>>>>>>> framework before we do the framework-only release, so I'm  
>>>>>>>> really
>>>>>>>> happy
>>>>>>>> to
>>>>>>>> see it in!
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>
>>>>>
>>

[Ashish Vijaywargiya]

Jacopo,

Thanks for the clarification.
Let's see what other's has to say about it.

--
Ashish

On Thu, Jun 26, 2008 at 6:11 AM, Jacopo Cappellato <
[hidden email]> wrote:

> Ashish,
>
> yes, what I meant that we could implement the new Minilang operation:
> "call-script"
>
> That operation could then be used to replace the existing "call-bsh"
> operation (that could be deprecated) and also it will be used to call Groovy
> scripts.
>
> Jacopo
>
>
>
> On Jun 26, 2008, at 11:54 AM, Ashish Vijaywargiya wrote:
>
>  Jacopo I liked the idea while we include the script file in Screen
>> Definition.
>> But if you will notice Jacques was talking about the Mini Lang call-bsh
>> replacement to call-groovy.
>>
>> Please let me know your thoughts in reference to Mini Lang.
>> Thanks !
>>
>> --
>> Ashish
>>
>>
>> On Thu, Jun 26, 2008 at 5:34 AM, Jacopo Cappellato <
>> [hidden email]> wrote:
>>
>>  What if we just add a <call-script/> element instead?
>>>
>>> We could then replace all the <call-bsh /> element to the new one.
>>> The new one will use the file suffix to use the proper Processor
>>> (.groovy,
>>> .bsh etc...)
>>> And we may add an optional parameter for the type ("groovy", "bsh" etc...
>>> that can be used if the script files don't have the right suffix).
>>>
>>> For example
>>>
>>> <call-script location="component://pathtoscript/myscript.groovy"/>
>>> <call-script location="component://pathtoscript/myscript.bsh"/>
>>> <call-script location="component://pathtoscript/mygroovyscript.grv"
>>> type="groovy"/>
>>>
>>> Jacopo
>>>
>>>
>>>
>>>
>>> On Jun 26, 2008, at 11:10 AM, Ashish Vijaywargiya wrote:
>>>
>>> +1 for adding <call-groovy> in minilang.
>>>
>>>>
>>>> I can work on it in my free time as voluntarily if we would like to
>>>> include
>>>> it in framework release.
>>>> Please let me know your thoughts on it.
>>>>
>>>> --
>>>> Ashish
>>>>
>>>>
>>>> On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux <
>>>> [hidden email]> wrote:
>>>>
>>>> +1 for Confluence
>>>>
>>>>> BTW, should we not add a <call-groovy> in minilang (or did I miss
>>>>> something) ?
>>>>>
>>>>> Jacques
>>>>>
>>>>> From: "David E Jones" <[hidden email]>
>>>>>
>>>>>
>>>>> Like Jacopo hinted at, this is a community-driven effort and is
>>>>>
>>>>>> therefore
>>>>>> a bit chaotic.
>>>>>>
>>>>>> The main thing I was requesting from the community is to focus on the
>>>>>> framework for a little while so we can stabilize and clean up the
>>>>>> framework in preparation for a binary release of it (leading toward a
>>>>>> good
>>>>>> binary release of the whole project... but starting with  something
>>>>>> smaller
>>>>>> and easier).
>>>>>>
>>>>>> Anyway, I do have a list of things I've been thinking about and
>>>>>> collecting, some from years ago. What I want to avoid though is making
>>>>>> my
>>>>>> list the official list, or even any sort of majority of the  official
>>>>>> list.
>>>>>> In other words, I want this to be a community effort  more than I want
>>>>>> to
>>>>>> have everything on my pet list done.
>>>>>>
>>>>>> Still, I do like the idea of starting to compile a list of things we'd
>>>>>> all like to see go into the framework, and it's probably about time to
>>>>>> do
>>>>>> that rather than having more random (less communicated) efforts on
>>>>>> different things.
>>>>>>
>>>>>> I'm thinking that a confluence/wiki page might be a better place for
>>>>>> now
>>>>>> though, given the tentative nature of some of these things, and  often
>>>>>> a
>>>>>> need for discussion before more concrete plans are made.
>>>>>>
>>>>>> What do others think of this?
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>> On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote:
>>>>>>
>>>>>> I think that Bruno's suggestion of creating a "framework-candidate-
>>>>>>
>>>>>>  release-x" version in Jira would be useful, especially because there
>>>>>>> is no
>>>>>>> official (or even unofficial) list of features/fixes to go in  the
>>>>>>> framework... probably each of us has its own preferences.
>>>>>>> Of course we should try to keep the list small.
>>>>>>>
>>>>>>> Jacopo
>>>>>>>
>>>>>>> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>>>>>>>
>>>>>>> David,
>>>>>>>
>>>>>>>  I think it will be beneficial to all contributors to have a list of
>>>>>>>> what we
>>>>>>>> would like to have included in the framework-only release, don't
>>>>>>>> you?
>>>>>>>>
>>>>>>>> It will tell how far we are and to have, generally, more efforts on
>>>>>>>> these
>>>>>>>> tasks.
>>>>>>>> Why don't define the framework-only version in JIRA and schedule
>>>>>>>>  for
>>>>>>>> that
>>>>>>>> the task-list ?
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> -Bruno
>>>>>>>>
>>>>>>>> 2008/6/20 David E Jones <[hidden email]>:
>>>>>>>>
>>>>>>>>
>>>>>>>> This looks good Adrian, thanks for working on it.
>>>>>>>>
>>>>>>>>>
>>>>>>>>> This was on my own little list of things I'd like to see added to
>>>>>>>>> the
>>>>>>>>> framework before we do the framework-only release, so I'm really
>>>>>>>>> happy
>>>>>>>>> to
>>>>>>>>> see it in!
>>>>>>>>>
>>>>>>>>> -David
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>
>>>
>

[David E Jones]

I like the idea for simple-method. One thing to keep in mind is that  
many scripts are included "in-line" under the current call-bsh tag  
rather than referred to as a file, so we'll have to have the type  
attribute that was mentioned, and we should probably have it default  
to "groovy" (and also support "bsh" or something).

BTW, on a related note, I do NOT like the idea of supporting scripts  
in-line in a screen's action area. It would clutter the screen  
definition making it harder to read and maintain, and it would limit  
reusability of the scripts.

-David


On Jun 26, 2008, at 5:49 AM, Ashish Vijaywargiya wrote:

> Jacopo,
>
> Thanks for the clarification.
> Let's see what other's has to say about it.
>
> --
> Ashish
>
> On Thu, Jun 26, 2008 at 6:11 AM, Jacopo Cappellato <
> [hidden email]> wrote:
>
>> Ashish,
>>
>> yes, what I meant that we could implement the new Minilang operation:
>> "call-script"
>>
>> That operation could then be used to replace the existing "call-bsh"
>> operation (that could be deprecated) and also it will be used to  
>> call Groovy
>> scripts.
>>
>> Jacopo
>>
>>
>>
>> On Jun 26, 2008, at 11:54 AM, Ashish Vijaywargiya wrote:
>>
>> Jacopo I liked the idea while we include the script file in Screen
>>> Definition.
>>> But if you will notice Jacques was talking about the Mini Lang  
>>> call-bsh
>>> replacement to call-groovy.
>>>
>>> Please let me know your thoughts in reference to Mini Lang.
>>> Thanks !
>>>
>>> --
>>> Ashish
>>>
>>>
>>> On Thu, Jun 26, 2008 at 5:34 AM, Jacopo Cappellato <
>>> [hidden email]> wrote:
>>>
>>> What if we just add a <call-script/> element instead?
>>>>
>>>> We could then replace all the <call-bsh /> element to the new one.
>>>> The new one will use the file suffix to use the proper Processor
>>>> (.groovy,
>>>> .bsh etc...)
>>>> And we may add an optional parameter for the type ("groovy",  
>>>> "bsh" etc...
>>>> that can be used if the script files don't have the right suffix).
>>>>
>>>> For example
>>>>
>>>> <call-script location="component://pathtoscript/myscript.groovy"/>
>>>> <call-script location="component://pathtoscript/myscript.bsh"/>
>>>> <call-script location="component://pathtoscript/mygroovyscript.grv"
>>>> type="groovy"/>
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>
>>>>
>>>> On Jun 26, 2008, at 11:10 AM, Ashish Vijaywargiya wrote:
>>>>
>>>> +1 for adding <call-groovy> in minilang.
>>>>
>>>>>
>>>>> I can work on it in my free time as voluntarily if we would like  
>>>>> to
>>>>> include
>>>>> it in framework release.
>>>>> Please let me know your thoughts on it.
>>>>>
>>>>> --
>>>>> Ashish
>>>>>
>>>>>
>>>>> On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux <
>>>>> [hidden email]> wrote:
>>>>>
>>>>> +1 for Confluence
>>>>>
>>>>>> BTW, should we not add a <call-groovy> in minilang (or did I miss
>>>>>> something) ?
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>> From: "David E Jones" <[hidden email]>
>>>>>>
>>>>>>
>>>>>> Like Jacopo hinted at, this is a community-driven effort and is
>>>>>>
>>>>>>> therefore
>>>>>>> a bit chaotic.
>>>>>>>
>>>>>>> The main thing I was requesting from the community is to focus  
>>>>>>> on the
>>>>>>> framework for a little while so we can stabilize and clean up  
>>>>>>> the
>>>>>>> framework in preparation for a binary release of it (leading  
>>>>>>> toward a
>>>>>>> good
>>>>>>> binary release of the whole project... but starting with  
>>>>>>> something
>>>>>>> smaller
>>>>>>> and easier).
>>>>>>>
>>>>>>> Anyway, I do have a list of things I've been thinking about and
>>>>>>> collecting, some from years ago. What I want to avoid though  
>>>>>>> is making
>>>>>>> my
>>>>>>> list the official list, or even any sort of majority of the  
>>>>>>> official
>>>>>>> list.
>>>>>>> In other words, I want this to be a community effort  more  
>>>>>>> than I want
>>>>>>> to
>>>>>>> have everything on my pet list done.
>>>>>>>
>>>>>>> Still, I do like the idea of starting to compile a list of  
>>>>>>> things we'd
>>>>>>> all like to see go into the framework, and it's probably about  
>>>>>>> time to
>>>>>>> do
>>>>>>> that rather than having more random (less communicated)  
>>>>>>> efforts on
>>>>>>> different things.
>>>>>>>
>>>>>>> I'm thinking that a confluence/wiki page might be a better  
>>>>>>> place for
>>>>>>> now
>>>>>>> though, given the tentative nature of some of these things,  
>>>>>>> and  often
>>>>>>> a
>>>>>>> need for discussion before more concrete plans are made.
>>>>>>>
>>>>>>> What do others think of this?
>>>>>>>
>>>>>>> -David
>>>>>>>
>>>>>>>
>>>>>>> On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote:
>>>>>>>
>>>>>>> I think that Bruno's suggestion of creating a "framework-
>>>>>>> candidate-
>>>>>>>
>>>>>>> release-x" version in Jira would be useful, especially because  
>>>>>>> there
>>>>>>>> is no
>>>>>>>> official (or even unofficial) list of features/fixes to go  
>>>>>>>> in  the
>>>>>>>> framework... probably each of us has its own preferences.
>>>>>>>> Of course we should try to keep the list small.
>>>>>>>>
>>>>>>>> Jacopo
>>>>>>>>
>>>>>>>> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>>>>>>>>
>>>>>>>> David,
>>>>>>>>
>>>>>>>> I think it will be beneficial to all contributors to have a  
>>>>>>>> list of
>>>>>>>>> what we
>>>>>>>>> would like to have included in the framework-only release,  
>>>>>>>>> don't
>>>>>>>>> you?
>>>>>>>>>
>>>>>>>>> It will tell how far we are and to have, generally, more  
>>>>>>>>> efforts on
>>>>>>>>> these
>>>>>>>>> tasks.
>>>>>>>>> Why don't define the framework-only version in JIRA and  
>>>>>>>>> schedule
>>>>>>>>> for
>>>>>>>>> that
>>>>>>>>> the task-list ?
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> -Bruno
>>>>>>>>>
>>>>>>>>> 2008/6/20 David E Jones <[hidden email]>:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> This looks good Adrian, thanks for working on it.
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This was on my own little list of things I'd like to see  
>>>>>>>>>> added to
>>>>>>>>>> the
>>>>>>>>>> framework before we do the framework-only release, so I'm  
>>>>>>>>>> really
>>>>>>>>>> happy
>>>>>>>>>> to
>>>>>>>>>> see it in!
>>>>>>>>>>
>>>>>>>>>> -David
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>
>>

[Jacopo Cappellato-3]

On Jun 26, 2008, at 4:03 PM, David E Jones wrote:

>
> I like the idea for simple-method. One thing to keep in mind is that  
> many scripts are included "in-line" under the current call-bsh tag  
> rather than referred to as a file, so we'll have to have the type  
> attribute that was mentioned, and we should probably have it default  
> to "groovy" (and also support "bsh" or something).
>

David, thanks for bringing this to our attention. This is a really  
good point.

> BTW, on a related note, I do NOT like the idea of supporting scripts  
> in-line in a screen's action area. It would clutter the screen  
> definition making it harder to read and maintain, and it would limit  
> reusability of the scripts.
>

Yes, I agree... I don't think anyone is working on this right now :-)

Jacopo

> -David
>
>
> On Jun 26, 2008, at 5:49 AM, Ashish Vijaywargiya wrote:
>
>> Jacopo,
>>
>> Thanks for the clarification.
>> Let's see what other's has to say about it.
>>
>> --
>> Ashish
>>
>> On Thu, Jun 26, 2008 at 6:11 AM, Jacopo Cappellato <
>> [hidden email]> wrote:
>>
>>> Ashish,
>>>
>>> yes, what I meant that we could implement the new Minilang  
>>> operation:
>>> "call-script"
>>>
>>> That operation could then be used to replace the existing "call-bsh"
>>> operation (that could be deprecated) and also it will be used to  
>>> call Groovy
>>> scripts.
>>>
>>> Jacopo
>>>
>>>
>>>
>>> On Jun 26, 2008, at 11:54 AM, Ashish Vijaywargiya wrote:
>>>
>>> Jacopo I liked the idea while we include the script file in Screen
>>>> Definition.
>>>> But if you will notice Jacques was talking about the Mini Lang  
>>>> call-bsh
>>>> replacement to call-groovy.
>>>>
>>>> Please let me know your thoughts in reference to Mini Lang.
>>>> Thanks !
>>>>
>>>> --
>>>> Ashish
>>>>
>>>>
>>>> On Thu, Jun 26, 2008 at 5:34 AM, Jacopo Cappellato <
>>>> [hidden email]> wrote:
>>>>
>>>> What if we just add a <call-script/> element instead?
>>>>>
>>>>> We could then replace all the <call-bsh /> element to the new one.
>>>>> The new one will use the file suffix to use the proper Processor
>>>>> (.groovy,
>>>>> .bsh etc...)
>>>>> And we may add an optional parameter for the type ("groovy",  
>>>>> "bsh" etc...
>>>>> that can be used if the script files don't have the right suffix).
>>>>>
>>>>> For example
>>>>>
>>>>> <call-script location="component://pathtoscript/myscript.groovy"/>
>>>>> <call-script location="component://pathtoscript/myscript.bsh"/>
>>>>> <call-script location="component://pathtoscript/
>>>>> mygroovyscript.grv"
>>>>> type="groovy"/>
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Jun 26, 2008, at 11:10 AM, Ashish Vijaywargiya wrote:
>>>>>
>>>>> +1 for adding <call-groovy> in minilang.
>>>>>
>>>>>>
>>>>>> I can work on it in my free time as voluntarily if we would  
>>>>>> like to
>>>>>> include
>>>>>> it in framework release.
>>>>>> Please let me know your thoughts on it.
>>>>>>
>>>>>> --
>>>>>> Ashish
>>>>>>
>>>>>>
>>>>>> On Wed, Jun 25, 2008 at 5:50 PM, Jacques Le Roux <
>>>>>> [hidden email]> wrote:
>>>>>>
>>>>>> +1 for Confluence
>>>>>>
>>>>>>> BTW, should we not add a <call-groovy> in minilang (or did I  
>>>>>>> miss
>>>>>>> something) ?
>>>>>>>
>>>>>>> Jacques
>>>>>>>
>>>>>>> From: "David E Jones" <[hidden email]>
>>>>>>>
>>>>>>>
>>>>>>> Like Jacopo hinted at, this is a community-driven effort and is
>>>>>>>
>>>>>>>> therefore
>>>>>>>> a bit chaotic.
>>>>>>>>
>>>>>>>> The main thing I was requesting from the community is to  
>>>>>>>> focus on the
>>>>>>>> framework for a little while so we can stabilize and clean up  
>>>>>>>> the
>>>>>>>> framework in preparation for a binary release of it (leading  
>>>>>>>> toward a
>>>>>>>> good
>>>>>>>> binary release of the whole project... but starting with  
>>>>>>>> something
>>>>>>>> smaller
>>>>>>>> and easier).
>>>>>>>>
>>>>>>>> Anyway, I do have a list of things I've been thinking about and
>>>>>>>> collecting, some from years ago. What I want to avoid though  
>>>>>>>> is making
>>>>>>>> my
>>>>>>>> list the official list, or even any sort of majority of the  
>>>>>>>> official
>>>>>>>> list.
>>>>>>>> In other words, I want this to be a community effort  more  
>>>>>>>> than I want
>>>>>>>> to
>>>>>>>> have everything on my pet list done.
>>>>>>>>
>>>>>>>> Still, I do like the idea of starting to compile a list of  
>>>>>>>> things we'd
>>>>>>>> all like to see go into the framework, and it's probably  
>>>>>>>> about time to
>>>>>>>> do
>>>>>>>> that rather than having more random (less communicated)  
>>>>>>>> efforts on
>>>>>>>> different things.
>>>>>>>>
>>>>>>>> I'm thinking that a confluence/wiki page might be a better  
>>>>>>>> place for
>>>>>>>> now
>>>>>>>> though, given the tentative nature of some of these things,  
>>>>>>>> and  often
>>>>>>>> a
>>>>>>>> need for discussion before more concrete plans are made.
>>>>>>>>
>>>>>>>> What do others think of this?
>>>>>>>>
>>>>>>>> -David
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jun 22, 2008, at 12:07 AM, Jacopo Cappellato wrote:
>>>>>>>>
>>>>>>>> I think that Bruno's suggestion of creating a "framework-
>>>>>>>> candidate-
>>>>>>>>
>>>>>>>> release-x" version in Jira would be useful, especially  
>>>>>>>> because there
>>>>>>>>> is no
>>>>>>>>> official (or even unofficial) list of features/fixes to go  
>>>>>>>>> in  the
>>>>>>>>> framework... probably each of us has its own preferences.
>>>>>>>>> Of course we should try to keep the list small.
>>>>>>>>>
>>>>>>>>> Jacopo
>>>>>>>>>
>>>>>>>>> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>>>>>>>>>
>>>>>>>>> David,
>>>>>>>>>
>>>>>>>>> I think it will be beneficial to all contributors to have a  
>>>>>>>>> list of
>>>>>>>>>> what we
>>>>>>>>>> would like to have included in the framework-only release,  
>>>>>>>>>> don't
>>>>>>>>>> you?
>>>>>>>>>>
>>>>>>>>>> It will tell how far we are and to have, generally, more  
>>>>>>>>>> efforts on
>>>>>>>>>> these
>>>>>>>>>> tasks.
>>>>>>>>>> Why don't define the framework-only version in JIRA and  
>>>>>>>>>> schedule
>>>>>>>>>> for
>>>>>>>>>> that
>>>>>>>>>> the task-list ?
>>>>>>>>>>
>>>>>>>>>> Thank you,
>>>>>>>>>> -Bruno
>>>>>>>>>>
>>>>>>>>>> 2008/6/20 David E Jones <[hidden email]>:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> This looks good Adrian, thanks for working on it.
>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> This was on my own little list of things I'd like to see  
>>>>>>>>>>> added to
>>>>>>>>>>> the
>>>>>>>>>>> framework before we do the framework-only release, so I'm  
>>>>>>>>>>> really
>>>>>>>>>>> happy
>>>>>>>>>>> to
>>>>>>>>>>> see it in!
>>>>>>>>>>>
>>>>>>>>>>> -David
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>>
>

[Adrian Crum]

Was anything done with this? Do we have a Jira issue or Wiki page?

-Adrian

Jacopo Cappellato wrote:

> I think that Bruno's suggestion of creating a
> "framework-candidate-release-x" version in Jira would be useful,
> especially because there is no official (or even unofficial) list of
> features/fixes to go in the framework... probably each of us has its own
> preferences.
> Of course we should try to keep the list small.
>
> Jacopo
>
> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>
>> David,
>> I think it will be beneficial to all contributors to have a list of
>> what we
>> would like to have included in the framework-only release, don't you?
>>
>> It will tell how far we are and to have, generally, more efforts on these
>> tasks.
>> Why don't define the framework-only version in JIRA and schedule for that
>> the task-list ?
>>
>> Thank you,
>> -Bruno
>>
>> 2008/6/20 David E Jones <[hidden email]>:
>>
>>>
>>> This looks good Adrian, thanks for working on it.
>>>
>>> This was on my own little list of things I'd like to see added to the
>>> framework before we do the framework-only release, so I'm really
>>> happy to
>>> see it in!
>>>
>>> -David
>>>
>>>
>>>
>
>

[Adrian Crum]

I created a Jira issue for this and added one sub task -

https://issues.apache.org/jira/browse/OFBIZ-1867

-Adrian

Adrian Crum wrote:

> Was anything done with this? Do we have a Jira issue or Wiki page?
>
> -Adrian
>
> Jacopo Cappellato wrote:
>> I think that Bruno's suggestion of creating a
>> "framework-candidate-release-x" version in Jira would be useful,
>> especially because there is no official (or even unofficial) list of
>> features/fixes to go in the framework... probably each of us has its
>> own preferences.
>> Of course we should try to keep the list small.
>>
>> Jacopo
>>
>> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>>
>>> David,
>>> I think it will be beneficial to all contributors to have a list of
>>> what we
>>> would like to have included in the framework-only release, don't you?
>>>
>>> It will tell how far we are and to have, generally, more efforts on
>>> these
>>> tasks.
>>> Why don't define the framework-only version in JIRA and schedule for
>>> that
>>> the task-list ?
>>>
>>> Thank you,
>>> -Bruno
>>>
>>> 2008/6/20 David E Jones <[hidden email]>:
>>>
>>>>
>>>> This looks good Adrian, thanks for working on it.
>>>>
>>>> This was on my own little list of things I'd like to see added to the
>>>> framework before we do the framework-only release, so I'm really
>>>> happy to
>>>> see it in!
>>>>
>>>> -David
>>>>
>>>>
>>>>
>>
>>
>

[Jacopo Cappellato-3]

Adrian,

thanks for doing this.

Another thing I would like to discuss is to move the default location  
for catalog and product images (uploaded from the Catalog application)  
outside of the framework: from framework/images to somewhere in the  
runtime folder.
This is just an idea, there could be technical issues (like loading  
resources that are outside of the "images" web application)... but I  
think that it would be fine to isolate the framework from any of the  
runtime events.

Jacopo


On Jul 9, 2008, at 4:41 PM, Adrian Crum wrote:

> I created a Jira issue for this and added one sub task -
>
> https://issues.apache.org/jira/browse/OFBIZ-1867
>
> -Adrian
>
> Adrian Crum wrote:
>> Was anything done with this? Do we have a Jira issue or Wiki page?
>> -Adrian
>> Jacopo Cappellato wrote:
>>> I think that Bruno's suggestion of creating a "framework-candidate-
>>> release-x" version in Jira would be useful, especially because  
>>> there is no official (or even unofficial) list of features/fixes  
>>> to go in the framework... probably each of us has its own  
>>> preferences.
>>> Of course we should try to keep the list small.
>>>
>>> Jacopo
>>>
>>> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>>>
>>>> David,
>>>> I think it will be beneficial to all contributors to have a list  
>>>> of what we
>>>> would like to have included in the framework-only release, don't  
>>>> you?
>>>>
>>>> It will tell how far we are and to have, generally, more efforts  
>>>> on these
>>>> tasks.
>>>> Why don't define the framework-only version in JIRA and schedule  
>>>> for that
>>>> the task-list ?
>>>>
>>>> Thank you,
>>>> -Bruno
>>>>
>>>> 2008/6/20 David E Jones <[hidden email]>:
>>>>
>>>>>
>>>>> This looks good Adrian, thanks for working on it.
>>>>>
>>>>> This was on my own little list of things I'd like to see added  
>>>>> to the
>>>>> framework before we do the framework-only release, so I'm really  
>>>>> happy to
>>>>> see it in!
>>>>>
>>>>> -David
>>>>>
>>>>>
>>>>>
>>>
>>>

[Adrian Crum]

I think the reason images are kept there is because they are considered
"static content" and could be located on another server - for
performance reasons.

-Adrian

Jacopo Cappellato wrote:

> Adrian,
>
> thanks for doing this.
>
> Another thing I would like to discuss is to move the default location
> for catalog and product images (uploaded from the Catalog application)
> outside of the framework: from framework/images to somewhere in the
> runtime folder.
> This is just an idea, there could be technical issues (like loading
> resources that are outside of the "images" web application)... but I
> think that it would be fine to isolate the framework from any of the
> runtime events.
>
> Jacopo
>
>
> On Jul 9, 2008, at 4:41 PM, Adrian Crum wrote:
>
>> I created a Jira issue for this and added one sub task -
>>
>> https://issues.apache.org/jira/browse/OFBIZ-1867
>>
>> -Adrian
>>
>> Adrian Crum wrote:
>>> Was anything done with this? Do we have a Jira issue or Wiki page?
>>> -Adrian
>>> Jacopo Cappellato wrote:
>>>> I think that Bruno's suggestion of creating a
>>>> "framework-candidate-release-x" version in Jira would be useful,
>>>> especially because there is no official (or even unofficial) list of
>>>> features/fixes to go in the framework... probably each of us has its
>>>> own preferences.
>>>> Of course we should try to keep the list small.
>>>>
>>>> Jacopo
>>>>
>>>> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>>>>
>>>>> David,
>>>>> I think it will be beneficial to all contributors to have a list of
>>>>> what we
>>>>> would like to have included in the framework-only release, don't you?
>>>>>
>>>>> It will tell how far we are and to have, generally, more efforts on
>>>>> these
>>>>> tasks.
>>>>> Why don't define the framework-only version in JIRA and schedule
>>>>> for that
>>>>> the task-list ?
>>>>>
>>>>> Thank you,
>>>>> -Bruno
>>>>>
>>>>> 2008/6/20 David E Jones <[hidden email]>:
>>>>>
>>>>>>
>>>>>> This looks good Adrian, thanks for working on it.
>>>>>>
>>>>>> This was on my own little list of things I'd like to see added to the
>>>>>> framework before we do the framework-only release, so I'm really
>>>>>> happy to
>>>>>> see it in!
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>
>

[Jacques Le Roux]

From: "Jacopo Cappellato" <[hidden email]>

> Adrian,
>
> thanks for doing this.
>
> Another thing I would like to discuss is to move the default location  
> for catalog and product images (uploaded from the Catalog application)  
> outside of the framework: from framework/images to somewhere in the  
> runtime folder.
> This is just an idea, there could be technical issues (like loading  
> resources that are outside of the "images" web application)... but I  
> think that it would be fine to isolate the framework from any of the  
> runtime events.

+1 (no ideas about the constraints)

Jacques
 

> Jacopo
>
>
> On Jul 9, 2008, at 4:41 PM, Adrian Crum wrote:
>
>> I created a Jira issue for this and added one sub task -
>>
>> https://issues.apache.org/jira/browse/OFBIZ-1867
>>
>> -Adrian
>>
>> Adrian Crum wrote:
>>> Was anything done with this? Do we have a Jira issue or Wiki page?
>>> -Adrian
>>> Jacopo Cappellato wrote:
>>>> I think that Bruno's suggestion of creating a "framework-candidate-
>>>> release-x" version in Jira would be useful, especially because  
>>>> there is no official (or even unofficial) list of features/fixes  
>>>> to go in the framework... probably each of us has its own  
>>>> preferences.
>>>> Of course we should try to keep the list small.
>>>>
>>>> Jacopo
>>>>
>>>> On Jun 21, 2008, at 7:28 AM, Bruno Busco wrote:
>>>>
>>>>> David,
>>>>> I think it will be beneficial to all contributors to have a list  
>>>>> of what we
>>>>> would like to have included in the framework-only release, don't  
>>>>> you?
>>>>>
>>>>> It will tell how far we are and to have, generally, more efforts  
>>>>> on these
>>>>> tasks.
>>>>> Why don't define the framework-only version in JIRA and schedule  
>>>>> for that
>>>>> the task-list ?
>>>>>
>>>>> Thank you,
>>>>> -Bruno
>>>>>
>>>>> 2008/6/20 David E Jones <[hidden email]>:
>>>>>
>>>>>>
>>>>>> This looks good Adrian, thanks for working on it.
>>>>>>
>>>>>> This was on my own little list of things I'd like to see added  
>>>>>> to the
>>>>>> framework before we do the framework-only release, so I'm really  
>>>>>> happy to
>>>>>> see it in!
>>>>>>
>>>>>> -David
>>>>>>
>>>>>>
>>>>>>
>>>>
>>>>
>