You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@ofbiz.apache.org by Adrian Crum <ad...@sandglass-software.com> on 2012/04/15 10:38:14 UTC
Mini-language Overhaul, Part 2
I am still working on the Mini-language Reference page:
https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference
but it is taking longer than I expected due to the enormity of the task.
I would like to get some preliminary code changes committed to the
project before the next release branch is created, so I am asking the
developer community for a preliminary review of the reference and the
proposed changes.
Here is what I would like to do before creation of the next release
branch (in sequence):
1. Reformat all Mini-language Java code. This would be a single,
separate commit.
2. Get developer community approval of the "Attribute Types" reference
section, the <set> element section, and the deprecated items marked in red.
3. Remove from the Mini-language Java code all deprecated items that are
marked in red in the reference.
4. Make some small changes to the Java code API in preparation for
future work. The API changes will not change Mini-language behavior in
any way.
5. Update the <set> element Java code and schema to match the reference.
The changes to the <set> element are the most important and they will
have the biggest impact on Mini-language code. The updated <set> element
will still work with existing Mini-language code, but it will issue
warnings about syntax changes. I'm thinking this approach will give
users of the new release branch an opportunity to update their
Mini-language code.
I will continue working on the reference after the release branch is
created and solicit developer community review of the finished draft
before any more work is done.
So, please take a few minutes to review the "Attribute Types" reference
section and the <set> element section and let me know if you see any
problems with them.
-Adrian
Re: Mini-language Overhaul, Part 2
Posted by Pierre Smits <pi...@gmail.com>.
Hi Adrian,
Before removal of deprecated minilang functions I would be wise to assess
the implications in current trunk. It would make sense to remove them and
then find out that parts of functionality (in whatever application) doesn't
work any more. With enduser annoyance as a result. And this is not
something we should let happen.
If the assessment is done prior to removal, then fixing the issues
identified can also be planned.
Regards,
Pierre
Op 20 april 2012 15:33 schreef Adrian Crum <
adrian.crum@sandglass-software.com> het volgende:
> Hans,
>
> Please read the discussions on this subject and the Mini-language
> reference page.
>
> The mini-language unit tests are practically non-existent, and I will be
> adding them as I go along. Keep in mind that an overhaul means things will
> change - that is the whole point of the effort.
>
> -Adrian
>
>
> On 4/20/2012 12:33 PM, Hans Bakker wrote:
>
>> Hi Adrian,
>>
>> i very much appreciate your work on this. But as you sure expected,
>> please keep in mind backward compatibility?
>> Can you also please add some junit tests to check the functionality did
>> not change?
>>
>> Regards
>> Hans
>>
>> On 04/20/2012 05:37 PM, Adrian Crum wrote:
>>
>>> I have completed steps 1 and 4. I would like to work on step 3 next:
>>> Remove from the Mini-language Java code all deprecated items that are
>>> marked in red in the reference.
>>>
>>> If there are no objections over the next few days I will begin work on
>>> that.
>>>
>>> -Adrian
>>>
>>> On 4/19/2012 12:09 PM, Adrian Crum wrote:
>>>
>>>> That is correct - if I make the non-functional changes before the
>>>> release branch is created, then future trunk fixes will be easier to
>>>> backport to the release branch. A separate fix will be needed for versions
>>>> prior to 12.x.
>>>>
>>>> -Adrian
>>>>
>>>> On 4/19/2012 7:29 AM, Jacopo Cappellato wrote:
>>>>
>>>>> On the other hand, if we include the changes in the upcoming release
>>>>> branch as Adrian suggests, it may be easier to backport bug fixes from
>>>>> trunk: if trunk and release12.04 will have different Minilang syntax we
>>>>> will get a lot of conflicts when backporting patches.
>>>>>
>>>>> Jacopo
>>>>>
>>>>> On Apr 15, 2012, at 11:11 AM, Jacopo Cappellato wrote:
>>>>>
>>>>> Wouldn't be better to cut the 12.04 branch and then start the
>>>>>> refactoring work on trunk?
>>>>>> This will remove some workload for backporting bug fixes in the new
>>>>>> branch; then we will have one year to complete the refactoring that will be
>>>>>> available in 13.04; users of 12.04 will have to upgrade all their Minilang
>>>>>> before moving to 13.04 and this in my opinion is a clear and good way to go.
>>>>>>
>>>>>> Jacopo
>>>>>>
>>>>>>
>>>>>> On Apr 15, 2012, at 10:38 AM, Adrian Crum wrote:
>>>>>>
>>>>>> I am still working on the Mini-language Reference page:
>>>>>>>
>>>>>>> https://cwiki.apache.org/**confluence/display/OFBADMIN/**
>>>>>>> Mini-language+Reference<https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference>
>>>>>>>
>>>>>>> but it is taking longer than I expected due to the enormity of the
>>>>>>> task. I would like to get some preliminary code changes committed to the
>>>>>>> project before the next release branch is created, so I am asking the
>>>>>>> developer community for a preliminary review of the reference and the
>>>>>>> proposed changes.
>>>>>>>
>>>>>>> Here is what I would like to do before creation of the next release
>>>>>>> branch (in sequence):
>>>>>>>
>>>>>>> 1. Reformat all Mini-language Java code. This would be a single,
>>>>>>> separate commit.
>>>>>>> 2. Get developer community approval of the "Attribute Types"
>>>>>>> reference section, the<set> element section, and the deprecated items
>>>>>>> marked in red.
>>>>>>> 3. Remove from the Mini-language Java code all deprecated items that
>>>>>>> are marked in red in the reference.
>>>>>>> 4. Make some small changes to the Java code API in preparation for
>>>>>>> future work. The API changes will not change Mini-language behavior in any
>>>>>>> way.
>>>>>>> 5. Update the<set> element Java code and schema to match the
>>>>>>> reference.
>>>>>>>
>>>>>>> The changes to the<set> element are the most important and they
>>>>>>> will have the biggest impact on Mini-language code. The updated<set>
>>>>>>> element will still work with existing Mini-language code, but it will
>>>>>>> issue warnings about syntax changes. I'm thinking this approach will give
>>>>>>> users of the new release branch an opportunity to update their
>>>>>>> Mini-language code.
>>>>>>>
>>>>>>> I will continue working on the reference after the release branch is
>>>>>>> created and solicit developer community review of the finished draft before
>>>>>>> any more work is done.
>>>>>>>
>>>>>>> So, please take a few minutes to review the "Attribute Types"
>>>>>>> reference section and the<set> element section and let me know if you see
>>>>>>> any problems with them.
>>>>>>>
>>>>>>> -Adrian
>>>>>>>
>>>>>>>
>>
Re: Mini-language Overhaul, Part 2
Posted by Adrian Crum <ad...@sandglass-software.com>.
Hans,
Please read the discussions on this subject and the Mini-language
reference page.
The mini-language unit tests are practically non-existent, and I will be
adding them as I go along. Keep in mind that an overhaul means things
will change - that is the whole point of the effort.
-Adrian
On 4/20/2012 12:33 PM, Hans Bakker wrote:
> Hi Adrian,
>
> i very much appreciate your work on this. But as you sure expected,
> please keep in mind backward compatibility?
> Can you also please add some junit tests to check the functionality
> did not change?
>
> Regards
> Hans
>
> On 04/20/2012 05:37 PM, Adrian Crum wrote:
>> I have completed steps 1 and 4. I would like to work on step 3 next:
>> Remove from the Mini-language Java code all deprecated items that are
>> marked in red in the reference.
>>
>> If there are no objections over the next few days I will begin work
>> on that.
>>
>> -Adrian
>>
>> On 4/19/2012 12:09 PM, Adrian Crum wrote:
>>> That is correct - if I make the non-functional changes before the
>>> release branch is created, then future trunk fixes will be easier to
>>> backport to the release branch. A separate fix will be needed for
>>> versions prior to 12.x.
>>>
>>> -Adrian
>>>
>>> On 4/19/2012 7:29 AM, Jacopo Cappellato wrote:
>>>> On the other hand, if we include the changes in the upcoming
>>>> release branch as Adrian suggests, it may be easier to backport bug
>>>> fixes from trunk: if trunk and release12.04 will have different
>>>> Minilang syntax we will get a lot of conflicts when backporting
>>>> patches.
>>>>
>>>> Jacopo
>>>>
>>>> On Apr 15, 2012, at 11:11 AM, Jacopo Cappellato wrote:
>>>>
>>>>> Wouldn't be better to cut the 12.04 branch and then start the
>>>>> refactoring work on trunk?
>>>>> This will remove some workload for backporting bug fixes in the
>>>>> new branch; then we will have one year to complete the refactoring
>>>>> that will be available in 13.04; users of 12.04 will have to
>>>>> upgrade all their Minilang before moving to 13.04 and this in my
>>>>> opinion is a clear and good way to go.
>>>>>
>>>>> Jacopo
>>>>>
>>>>>
>>>>> On Apr 15, 2012, at 10:38 AM, Adrian Crum wrote:
>>>>>
>>>>>> I am still working on the Mini-language Reference page:
>>>>>>
>>>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference
>>>>>>
>>>>>>
>>>>>> but it is taking longer than I expected due to the enormity of
>>>>>> the task. I would like to get some preliminary code changes
>>>>>> committed to the project before the next release branch is
>>>>>> created, so I am asking the developer community for a preliminary
>>>>>> review of the reference and the proposed changes.
>>>>>>
>>>>>> Here is what I would like to do before creation of the next
>>>>>> release branch (in sequence):
>>>>>>
>>>>>> 1. Reformat all Mini-language Java code. This would be a single,
>>>>>> separate commit.
>>>>>> 2. Get developer community approval of the "Attribute Types"
>>>>>> reference section, the<set> element section, and the deprecated
>>>>>> items marked in red.
>>>>>> 3. Remove from the Mini-language Java code all deprecated items
>>>>>> that are marked in red in the reference.
>>>>>> 4. Make some small changes to the Java code API in preparation
>>>>>> for future work. The API changes will not change Mini-language
>>>>>> behavior in any way.
>>>>>> 5. Update the<set> element Java code and schema to match the
>>>>>> reference.
>>>>>>
>>>>>> The changes to the<set> element are the most important and they
>>>>>> will have the biggest impact on Mini-language code. The
>>>>>> updated<set> element will still work with existing Mini-language
>>>>>> code, but it will issue warnings about syntax changes. I'm
>>>>>> thinking this approach will give users of the new release branch
>>>>>> an opportunity to update their Mini-language code.
>>>>>>
>>>>>> I will continue working on the reference after the release branch
>>>>>> is created and solicit developer community review of the finished
>>>>>> draft before any more work is done.
>>>>>>
>>>>>> So, please take a few minutes to review the "Attribute Types"
>>>>>> reference section and the<set> element section and let me know
>>>>>> if you see any problems with them.
>>>>>>
>>>>>> -Adrian
>>>>>>
>
Re: Mini-language Overhaul, Part 2
Posted by Hans Bakker <ma...@antwebsystems.com>.
Hi Adrian,
i very much appreciate your work on this. But as you sure expected,
please keep in mind backward compatibility?
Can you also please add some junit tests to check the functionality did
not change?
Regards
Hans
On 04/20/2012 05:37 PM, Adrian Crum wrote:
> I have completed steps 1 and 4. I would like to work on step 3 next:
> Remove from the Mini-language Java code all deprecated items that are
> marked in red in the reference.
>
> If there are no objections over the next few days I will begin work on
> that.
>
> -Adrian
>
> On 4/19/2012 12:09 PM, Adrian Crum wrote:
>> That is correct - if I make the non-functional changes before the
>> release branch is created, then future trunk fixes will be easier to
>> backport to the release branch. A separate fix will be needed for
>> versions prior to 12.x.
>>
>> -Adrian
>>
>> On 4/19/2012 7:29 AM, Jacopo Cappellato wrote:
>>> On the other hand, if we include the changes in the upcoming release
>>> branch as Adrian suggests, it may be easier to backport bug fixes
>>> from trunk: if trunk and release12.04 will have different Minilang
>>> syntax we will get a lot of conflicts when backporting patches.
>>>
>>> Jacopo
>>>
>>> On Apr 15, 2012, at 11:11 AM, Jacopo Cappellato wrote:
>>>
>>>> Wouldn't be better to cut the 12.04 branch and then start the
>>>> refactoring work on trunk?
>>>> This will remove some workload for backporting bug fixes in the new
>>>> branch; then we will have one year to complete the refactoring that
>>>> will be available in 13.04; users of 12.04 will have to upgrade all
>>>> their Minilang before moving to 13.04 and this in my opinion is a
>>>> clear and good way to go.
>>>>
>>>> Jacopo
>>>>
>>>>
>>>> On Apr 15, 2012, at 10:38 AM, Adrian Crum wrote:
>>>>
>>>>> I am still working on the Mini-language Reference page:
>>>>>
>>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference
>>>>>
>>>>>
>>>>> but it is taking longer than I expected due to the enormity of the
>>>>> task. I would like to get some preliminary code changes committed
>>>>> to the project before the next release branch is created, so I am
>>>>> asking the developer community for a preliminary review of the
>>>>> reference and the proposed changes.
>>>>>
>>>>> Here is what I would like to do before creation of the next
>>>>> release branch (in sequence):
>>>>>
>>>>> 1. Reformat all Mini-language Java code. This would be a single,
>>>>> separate commit.
>>>>> 2. Get developer community approval of the "Attribute Types"
>>>>> reference section, the<set> element section, and the deprecated
>>>>> items marked in red.
>>>>> 3. Remove from the Mini-language Java code all deprecated items
>>>>> that are marked in red in the reference.
>>>>> 4. Make some small changes to the Java code API in preparation for
>>>>> future work. The API changes will not change Mini-language
>>>>> behavior in any way.
>>>>> 5. Update the<set> element Java code and schema to match the
>>>>> reference.
>>>>>
>>>>> The changes to the<set> element are the most important and they
>>>>> will have the biggest impact on Mini-language code. The
>>>>> updated<set> element will still work with existing Mini-language
>>>>> code, but it will issue warnings about syntax changes. I'm
>>>>> thinking this approach will give users of the new release branch
>>>>> an opportunity to update their Mini-language code.
>>>>>
>>>>> I will continue working on the reference after the release branch
>>>>> is created and solicit developer community review of the finished
>>>>> draft before any more work is done.
>>>>>
>>>>> So, please take a few minutes to review the "Attribute Types"
>>>>> reference section and the<set> element section and let me know if
>>>>> you see any problems with them.
>>>>>
>>>>> -Adrian
>>>>>
Re: Mini-language Overhaul, Part 2
Posted by Adrian Crum <ad...@sandglass-software.com>.
I have completed steps 1 and 4. I would like to work on step 3 next:
Remove from the Mini-language Java code all deprecated items that are
marked in red in the reference.
If there are no objections over the next few days I will begin work on that.
-Adrian
On 4/19/2012 12:09 PM, Adrian Crum wrote:
> That is correct - if I make the non-functional changes before the
> release branch is created, then future trunk fixes will be easier to
> backport to the release branch. A separate fix will be needed for
> versions prior to 12.x.
>
> -Adrian
>
> On 4/19/2012 7:29 AM, Jacopo Cappellato wrote:
>> On the other hand, if we include the changes in the upcoming release
>> branch as Adrian suggests, it may be easier to backport bug fixes
>> from trunk: if trunk and release12.04 will have different Minilang
>> syntax we will get a lot of conflicts when backporting patches.
>>
>> Jacopo
>>
>> On Apr 15, 2012, at 11:11 AM, Jacopo Cappellato wrote:
>>
>>> Wouldn't be better to cut the 12.04 branch and then start the
>>> refactoring work on trunk?
>>> This will remove some workload for backporting bug fixes in the new
>>> branch; then we will have one year to complete the refactoring that
>>> will be available in 13.04; users of 12.04 will have to upgrade all
>>> their Minilang before moving to 13.04 and this in my opinion is a
>>> clear and good way to go.
>>>
>>> Jacopo
>>>
>>>
>>> On Apr 15, 2012, at 10:38 AM, Adrian Crum wrote:
>>>
>>>> I am still working on the Mini-language Reference page:
>>>>
>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference
>>>>
>>>>
>>>> but it is taking longer than I expected due to the enormity of the
>>>> task. I would like to get some preliminary code changes committed
>>>> to the project before the next release branch is created, so I am
>>>> asking the developer community for a preliminary review of the
>>>> reference and the proposed changes.
>>>>
>>>> Here is what I would like to do before creation of the next release
>>>> branch (in sequence):
>>>>
>>>> 1. Reformat all Mini-language Java code. This would be a single,
>>>> separate commit.
>>>> 2. Get developer community approval of the "Attribute Types"
>>>> reference section, the<set> element section, and the deprecated
>>>> items marked in red.
>>>> 3. Remove from the Mini-language Java code all deprecated items
>>>> that are marked in red in the reference.
>>>> 4. Make some small changes to the Java code API in preparation for
>>>> future work. The API changes will not change Mini-language behavior
>>>> in any way.
>>>> 5. Update the<set> element Java code and schema to match the
>>>> reference.
>>>>
>>>> The changes to the<set> element are the most important and they
>>>> will have the biggest impact on Mini-language code. The
>>>> updated<set> element will still work with existing Mini-language
>>>> code, but it will issue warnings about syntax changes. I'm thinking
>>>> this approach will give users of the new release branch an
>>>> opportunity to update their Mini-language code.
>>>>
>>>> I will continue working on the reference after the release branch
>>>> is created and solicit developer community review of the finished
>>>> draft before any more work is done.
>>>>
>>>> So, please take a few minutes to review the "Attribute Types"
>>>> reference section and the<set> element section and let me know if
>>>> you see any problems with them.
>>>>
>>>> -Adrian
>>>>
Re: Mini-language Overhaul, Part 2
Posted by Adrian Crum <ad...@sandglass-software.com>.
That is correct - if I make the non-functional changes before the
release branch is created, then future trunk fixes will be easier to
backport to the release branch. A separate fix will be needed for
versions prior to 12.x.
-Adrian
On 4/19/2012 7:29 AM, Jacopo Cappellato wrote:
> On the other hand, if we include the changes in the upcoming release branch as Adrian suggests, it may be easier to backport bug fixes from trunk: if trunk and release12.04 will have different Minilang syntax we will get a lot of conflicts when backporting patches.
>
> Jacopo
>
> On Apr 15, 2012, at 11:11 AM, Jacopo Cappellato wrote:
>
>> Wouldn't be better to cut the 12.04 branch and then start the refactoring work on trunk?
>> This will remove some workload for backporting bug fixes in the new branch; then we will have one year to complete the refactoring that will be available in 13.04; users of 12.04 will have to upgrade all their Minilang before moving to 13.04 and this in my opinion is a clear and good way to go.
>>
>> Jacopo
>>
>>
>> On Apr 15, 2012, at 10:38 AM, Adrian Crum wrote:
>>
>>> I am still working on the Mini-language Reference page:
>>>
>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference
>>>
>>> but it is taking longer than I expected due to the enormity of the task. I would like to get some preliminary code changes committed to the project before the next release branch is created, so I am asking the developer community for a preliminary review of the reference and the proposed changes.
>>>
>>> Here is what I would like to do before creation of the next release branch (in sequence):
>>>
>>> 1. Reformat all Mini-language Java code. This would be a single, separate commit.
>>> 2. Get developer community approval of the "Attribute Types" reference section, the<set> element section, and the deprecated items marked in red.
>>> 3. Remove from the Mini-language Java code all deprecated items that are marked in red in the reference.
>>> 4. Make some small changes to the Java code API in preparation for future work. The API changes will not change Mini-language behavior in any way.
>>> 5. Update the<set> element Java code and schema to match the reference.
>>>
>>> The changes to the<set> element are the most important and they will have the biggest impact on Mini-language code. The updated<set> element will still work with existing Mini-language code, but it will issue warnings about syntax changes. I'm thinking this approach will give users of the new release branch an opportunity to update their Mini-language code.
>>>
>>> I will continue working on the reference after the release branch is created and solicit developer community review of the finished draft before any more work is done.
>>>
>>> So, please take a few minutes to review the "Attribute Types" reference section and the<set> element section and let me know if you see any problems with them.
>>>
>>> -Adrian
>>>
Re: Mini-language Overhaul, Part 2
Posted by Jacques Le Roux <ja...@les7arts.com>.
Yes trunk is the bleeding edge anyway...
Jacques
From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> On the other hand, if we include the changes in the upcoming release branch as Adrian suggests, it may be easier to backport bug
> fixes from trunk: if trunk and release12.04 will have different Minilang syntax we will get a lot of conflicts when backporting
> patches.
>
> Jacopo
>
> On Apr 15, 2012, at 11:11 AM, Jacopo Cappellato wrote:
>
>> Wouldn't be better to cut the 12.04 branch and then start the refactoring work on trunk?
>> This will remove some workload for backporting bug fixes in the new branch; then we will have one year to complete the
>> refactoring that will be available in 13.04; users of 12.04 will have to upgrade all their Minilang before moving to 13.04 and
>> this in my opinion is a clear and good way to go.
>>
>> Jacopo
>>
>>
>> On Apr 15, 2012, at 10:38 AM, Adrian Crum wrote:
>>
>>> I am still working on the Mini-language Reference page:
>>>
>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference
>>>
>>> but it is taking longer than I expected due to the enormity of the task. I would like to get some preliminary code changes
>>> committed to the project before the next release branch is created, so I am asking the developer community for a preliminary
>>> review of the reference and the proposed changes.
>>>
>>> Here is what I would like to do before creation of the next release branch (in sequence):
>>>
>>> 1. Reformat all Mini-language Java code. This would be a single, separate commit.
>>> 2. Get developer community approval of the "Attribute Types" reference section, the <set> element section, and the deprecated
>>> items marked in red.
>>> 3. Remove from the Mini-language Java code all deprecated items that are marked in red in the reference.
>>> 4. Make some small changes to the Java code API in preparation for future work. The API changes will not change Mini-language
>>> behavior in any way.
>>> 5. Update the <set> element Java code and schema to match the reference.
>>>
>>> The changes to the <set> element are the most important and they will have the biggest impact on Mini-language code. The updated
>>> <set> element will still work with existing Mini-language code, but it will issue warnings about syntax changes. I'm thinking
>>> this approach will give users of the new release branch an opportunity to update their Mini-language code.
>>>
>>> I will continue working on the reference after the release branch is created and solicit developer community review of the
>>> finished draft before any more work is done.
>>>
>>> So, please take a few minutes to review the "Attribute Types" reference section and the <set> element section and let me know if
>>> you see any problems with them.
>>>
>>> -Adrian
>>>
>>
>
>
Re: Mini-language Overhaul, Part 2
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
On the other hand, if we include the changes in the upcoming release branch as Adrian suggests, it may be easier to backport bug fixes from trunk: if trunk and release12.04 will have different Minilang syntax we will get a lot of conflicts when backporting patches.
Jacopo
On Apr 15, 2012, at 11:11 AM, Jacopo Cappellato wrote:
> Wouldn't be better to cut the 12.04 branch and then start the refactoring work on trunk?
> This will remove some workload for backporting bug fixes in the new branch; then we will have one year to complete the refactoring that will be available in 13.04; users of 12.04 will have to upgrade all their Minilang before moving to 13.04 and this in my opinion is a clear and good way to go.
>
> Jacopo
>
>
> On Apr 15, 2012, at 10:38 AM, Adrian Crum wrote:
>
>> I am still working on the Mini-language Reference page:
>>
>> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference
>>
>> but it is taking longer than I expected due to the enormity of the task. I would like to get some preliminary code changes committed to the project before the next release branch is created, so I am asking the developer community for a preliminary review of the reference and the proposed changes.
>>
>> Here is what I would like to do before creation of the next release branch (in sequence):
>>
>> 1. Reformat all Mini-language Java code. This would be a single, separate commit.
>> 2. Get developer community approval of the "Attribute Types" reference section, the <set> element section, and the deprecated items marked in red.
>> 3. Remove from the Mini-language Java code all deprecated items that are marked in red in the reference.
>> 4. Make some small changes to the Java code API in preparation for future work. The API changes will not change Mini-language behavior in any way.
>> 5. Update the <set> element Java code and schema to match the reference.
>>
>> The changes to the <set> element are the most important and they will have the biggest impact on Mini-language code. The updated <set> element will still work with existing Mini-language code, but it will issue warnings about syntax changes. I'm thinking this approach will give users of the new release branch an opportunity to update their Mini-language code.
>>
>> I will continue working on the reference after the release branch is created and solicit developer community review of the finished draft before any more work is done.
>>
>> So, please take a few minutes to review the "Attribute Types" reference section and the <set> element section and let me know if you see any problems with them.
>>
>> -Adrian
>>
>
Re: Mini-language Overhaul, Part 2
Posted by Jacopo Cappellato <ja...@hotwaxmedia.com>.
Wouldn't be better to cut the 12.04 branch and then start the refactoring work on trunk?
This will remove some workload for backporting bug fixes in the new branch; then we will have one year to complete the refactoring that will be available in 13.04; users of 12.04 will have to upgrade all their Minilang before moving to 13.04 and this in my opinion is a clear and good way to go.
Jacopo
On Apr 15, 2012, at 10:38 AM, Adrian Crum wrote:
> I am still working on the Mini-language Reference page:
>
> https://cwiki.apache.org/confluence/display/OFBADMIN/Mini-language+Reference
>
> but it is taking longer than I expected due to the enormity of the task. I would like to get some preliminary code changes committed to the project before the next release branch is created, so I am asking the developer community for a preliminary review of the reference and the proposed changes.
>
> Here is what I would like to do before creation of the next release branch (in sequence):
>
> 1. Reformat all Mini-language Java code. This would be a single, separate commit.
> 2. Get developer community approval of the "Attribute Types" reference section, the <set> element section, and the deprecated items marked in red.
> 3. Remove from the Mini-language Java code all deprecated items that are marked in red in the reference.
> 4. Make some small changes to the Java code API in preparation for future work. The API changes will not change Mini-language behavior in any way.
> 5. Update the <set> element Java code and schema to match the reference.
>
> The changes to the <set> element are the most important and they will have the biggest impact on Mini-language code. The updated <set> element will still work with existing Mini-language code, but it will issue warnings about syntax changes. I'm thinking this approach will give users of the new release branch an opportunity to update their Mini-language code.
>
> I will continue working on the reference after the release branch is created and solicit developer community review of the finished draft before any more work is done.
>
> So, please take a few minutes to review the "Attribute Types" reference section and the <set> element section and let me know if you see any problems with them.
>
> -Adrian
>