Discussion: Summarize Proposed Trunk Changes

[Adrian Crum]

To summarize the replies in this thread:

#1 Require Java 6: Should be voted on. We voted on it and it was agreed
to make the change to Java 6.

#2 Remove Cloudscape support: No disagreement on that issue, so no vote
is necessary. I will work on making that change in the near future.

#3 Remove the Shark component: Should be voted on. Voting thread not
started yet.

#4 Include Birt: The only issue is licensing, so no voting is necessary.

Many thanks to David for getting the Java 6 voting thread started!

-Adrian


Adrian Crum wrote:

> Lately there there have been some discussions about making big changes to the trunk. I would like to suggest that we summarize those proposed changes, create a voting thread for each change, and then send a friendly announcement to the user mailing list about the proposed changes that won the vote.
>
> In the USA we are in the midst of a major holiday, so we need to give others plenty of time to respond. So, how about this: let's list our proposed changes in this thread and wait a few days for responses. Sometime next week we can start the voting threads. About a week after that, summarize the voting results and send an announcement to the user mailing list. What do you think?
>
> To get things started, here are the proposed changes I am aware of:
>
> 1. Require Java 6
>
> 2. Remove Cloudscape support
>
> 3. Remove the Shark component
>
> Feel free to add others to the list.
>
> -Adrian

[Jacques Le Roux]

From: "Adrian Crum" <[hidden email]>
> #3 Remove the Shark component: Should be voted on. Voting thread not started yet.

I have suggested to create a deprecated directories instead than simply removing.

There OOTB,
no compilations,
nor Javadoc ,
directions to use  (they already exists but should be extracted from OPTIONAL_LIBRARIES),
no problems for us,
visibility for users.

Jacques

[Scott Gray-2]

On 3/12/2009, at 7:44 PM, Jacques Le Roux wrote:

> From: "Adrian Crum" <[hidden email]>
>> #3 Remove the Shark component: Should be voted on. Voting thread  
>> not started yet.
>
> I have suggested to create a deprecated directories instead than  
> simply removing.
> There OOTB, no compilations, nor Javadoc , directions to use  (they  
> already exists but should be extracted from OPTIONAL_LIBRARIES), no  
> problems for us, visibility for users.

I've also suggested that I don't think we should remove the component  
and if people are concerned about having to make sure it compiles then  
I will do this regularly.

Regards
Scott

[Bilgin Ibryam-2]

Inline

David E Jones wrote:

> On Nov 27, 2009, at 2:14 AM, Scott Gray wrote:
>
>  
>>> 5. Is there a specific reason for keeping Old entities in trunk? Trunk users should be already using the migration services and new entities?
>>>
>>> Bilgin
>>>      
>> Hi Bilgin,
>>
>> I've never written a migration service, but aren't they dependent upon the old entity definitions being present?  I do agree though that we need to come up with a timeframe for their removal at some point

You are right Scott, the migration service needs the old entity data. I
forgot about that. So it makes the removing of deprecated entities a bit
tricky.

> We can move Old* entity to other files, but IMO they need to stay basically forever in order to maintain an upgrade path. Without them upgrading becomes very difficult.
>
> If there was a case where and Old* entity was replaced by another Old* entity (which was then in turn replaced by an entity currently in use) then maybe we could consider getting rid of one of them, but IMO we still shouldn't because it would mean that regardless of which one we get rid of a certain range of revisions will not be upgradeable to the latest revision.
>
> We could go down the path of requiring upgrades to go through a series of changes, like to 4.0 to then to 09.04 then to trunk (or whatever other release branches have been done). However, is it really that tough to keep this stuff around? IMO it is really not at all a big deal.
>
> If anyone is really bothered by messy stuff in the project then start cleaning up and modernizing older code, but please let's not get so aggressive about getting rid of stuff that is likely to be used.
>
> -David
>  

Thanks for the insight David !

[Adrian Crum]

Jacques and Scott,

Thank you for the clarification. I know I read through all of the
replies, but I don't know how I missed that.

-Adrian

Scott Gray wrote:

> On 3/12/2009, at 7:44 PM, Jacques Le Roux wrote:
>
>> From: "Adrian Crum" <[hidden email]>
>>> #3 Remove the Shark component: Should be voted on. Voting thread not
>>> started yet.
>>
>> I have suggested to create a deprecated directories instead than
>> simply removing.
>> There OOTB, no compilations, nor Javadoc , directions to use  (they
>> already exists but should be extracted from OPTIONAL_LIBRARIES), no
>> problems for us, visibility for users.
>
> I've also suggested that I don't think we should remove the component
> and if people are concerned about having to make sure it compiles then I
> will do this regularly.
>
> Regards
> Scott

[Adam Heath-2]

Bilgin Ibryam wrote:
> Inline
>
> David E Jones wrote:
>> On Nov 27, 2009, at 2:14 AM, Scott Gray wrote:

>> We can move Old* entity to other files, but IMO they need to stay
>> basically forever in order to maintain an upgrade path. Without them
>> upgrading becomes very difficult.
>>
>> If there was a case where and Old* entity was replaced by another Old*
>> entity (which was then in turn replaced by an entity currently in use)
>> then maybe we could consider getting rid of one of them, but IMO we
>> still shouldn't because it would mean that regardless of which one we
>> get rid of a certain range of revisions will not be upgradeable to the
>> latest revision.
>>
>> We could go down the path of requiring upgrades to go through a series
>> of changes, like to 4.0 to then to 09.04 then to trunk (or whatever
>> other release branches have been done). However, is it really that
>> tough to keep this stuff around? IMO it is really not at all a big deal.
>>
>> If anyone is really bothered by messy stuff in the project then start
>> cleaning up and modernizing older code, but please let's not get so
>> aggressive about getting rid of stuff that is likely to be used.
>>
>> -David

Upgrades from A to B to C to D to E:

Don't try to be smart, and have an upgrade script to go to one of each
of A to B, A to C, A to D, and A to E.

Ofbiz should store the version at install time into the database.
Then, during an upgrade, it would see the new version, and check for
upgrade scripts by version.  This might be an iterative kind of
upgrade, or could be done with the dpkg compare-versions algorithm(I
have a port of that to java code lying around here somewhere).

Said upgrade scripts(services/entities) don't need to be available for
general purpose use at runtime.  They could be in alternative files
that are only made available during the upgrade process.

When a new item(entity or service) is installed, it should list an
UpgradeArtifact for the MostRecent working version.  Each
UpgradeArtifact can then list another MostRecent UpgradeArtifact.
During upgrade, ofbiz would scan all Artificates for any registered
UpgradeArtifact, then follow the MostRecent UpgradeArtifact links,
until it finds a MostRecent that is earlier than the currently
installed version.  Then, with this list of all UpgradeArtifacts, it
would order then by version, and run them in series.

[Jacques Le Roux]

If nobody see a problem with this approach I will do... some day...

Jacques
()  ascii ribbon campaign against HTML e-mail
/\  www.asciiribbon.org


From: "Jacques Le Roux" <[hidden email]>

> From: "Adrian Crum" <[hidden email]>
>> #3 Remove the Shark component: Should be voted on. Voting thread not started yet.
>
> I have suggested to create a deprecated directories instead than simply removing.
>
> There OOTB,
> no compilations,
> nor Javadoc ,
> directions to use  (they already exists but should be extracted from OPTIONAL_LIBRARIES),
> no problems for us,
> visibility for users.
>
> Jacques
>
>

[Scott Gray-2]

I do see a problem, please reread the emails I've sent.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com

On 10/12/2009, at 11:06 AM, Jacques Le Roux wrote:

> If nobody see a problem with this approach I will do... some day...
>
> Jacques
> ()  ascii ribbon campaign against HTML e-mail
> /\  www.asciiribbon.org
>
>
> From: "Jacques Le Roux" <[hidden email]>
>> From: "Adrian Crum" <[hidden email]>
>>> #3 Remove the Shark component: Should be voted on. Voting thread  
>>> not started yet.
>> I have suggested to create a deprecated directories instead than  
>> simply removing. There OOTB, no compilations, nor Javadoc ,  
>> directions to use  (they already exists but should be extracted  
>> from OPTIONAL_LIBRARIES), no problems for us, visibility for users.
>> Jacques
>

[Jacques Le Roux]

Please Scott,

Could you be more explicit, what is the problem of creating a deprecated directory where no longer used applications will be freezed
(without compilation nor JavaDOc update)

Thanks

Jacques
()  ascii ribbon campaign against HTML e-mail
/\  www.asciiribbon.org


From: "Scott Gray" <[hidden email]>

>I do see a problem, please reread the emails I've sent.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
> On 10/12/2009, at 11:06 AM, Jacques Le Roux wrote:
>
>> If nobody see a problem with this approach I will do... some day...
>>
>> Jacques
>> ()  ascii ribbon campaign against HTML e-mail
>> /\  www.asciiribbon.org
>>
>>
>> From: "Jacques Le Roux" <[hidden email]>
>>> From: "Adrian Crum" <[hidden email]>
>>>> #3 Remove the Shark component: Should be voted on. Voting thread  not started yet.
>>> I have suggested to create a deprecated directories instead than  simply removing. There OOTB, no compilations, nor Javadoc ,
>>> directions to use  (they already exists but should be extracted  from OPTIONAL_LIBRARIES), no problems for us, visibility for
>>> users.
>>> Jacques
>>
>
>

[Scott Gray-2]

To be honest I don't really feel like rewriting all the opinions I've  
already expressed on this subject but here are the main points:
1. I don't think shark should be deprecated/removed
2. Shark is already excluded from compilation so I don't see why we  
need to move it achieve something we already have and it would just  
make the component more difficult to reactivate.
3. In general I don't like the idea of a deprecated directory, either  
remove something or leave it, I don't think we need an intermediate  
step.

Regards
Scott

HotWax Media
http://www.hotwaxmedia.com


On 10/12/2009, at 11:42 AM, Jacques Le Roux wrote:

> Please Scott,
>
> Could you be more explicit, what is the problem of creating a  
> deprecated directory where no longer used applications will be  
> freezed (without compilation nor JavaDOc update)
>
> Thanks
>
> Jacques
> ()  ascii ribbon campaign against HTML e-mail
> /\  www.asciiribbon.org
>
>
> From: "Scott Gray" <[hidden email]>
>> I do see a problem, please reread the emails I've sent.
>>
>> Regards
>> Scott
>>
>> HotWax Media
>> http://www.hotwaxmedia.com
>>
>> On 10/12/2009, at 11:06 AM, Jacques Le Roux wrote:
>>
>>> If nobody see a problem with this approach I will do... some day...
>>>
>>> Jacques
>>> ()  ascii ribbon campaign against HTML e-mail
>>> /\  www.asciiribbon.org
>>>
>>>
>>> From: "Jacques Le Roux" <[hidden email]>
>>>> From: "Adrian Crum" <[hidden email]>
>>>>> #3 Remove the Shark component: Should be voted on. Voting  
>>>>> thread  not started yet.
>>>> I have suggested to create a deprecated directories instead than  
>>>> simply removing. There OOTB, no compilations, nor Javadoc ,  
>>>> directions to use  (they already exists but should be extracted  
>>>> from OPTIONAL_LIBRARIES), no problems for us, visibility for users.
>>>> Jacques
>>>
>>
>
>

[Jacques Le Roux]

Thanks Scott,

It's fine with me (I have already prevented also Shark JavaDoc to build, which was my real concern, as I got trapped)

Jacques
()  ascii ribbon campaign against HTML e-mail
/\  www.asciiribbon.org


From: "Scott Gray" <[hidden email]>

> To be honest I don't really feel like rewriting all the opinions I've  
> already expressed on this subject but here are the main points:
> 1. I don't think shark should be deprecated/removed
> 2. Shark is already excluded from compilation so I don't see why we  
> need to move it achieve something we already have and it would just  
> make the component more difficult to reactivate.
> 3. In general I don't like the idea of a deprecated directory, either  
> remove something or leave it, I don't think we need an intermediate  
> step.
>
> Regards
> Scott
>
> HotWax Media
> http://www.hotwaxmedia.com
>
>
> On 10/12/2009, at 11:42 AM, Jacques Le Roux wrote:
>
>> Please Scott,
>>
>> Could you be more explicit, what is the problem of creating a  
>> deprecated directory where no longer used applications will be  
>> freezed (without compilation nor JavaDOc update)
>>
>> Thanks
>>
>> Jacques
>> ()  ascii ribbon campaign against HTML e-mail
>> /\  www.asciiribbon.org
>>
>>
>> From: "Scott Gray" <[hidden email]>
>>> I do see a problem, please reread the emails I've sent.
>>>
>>> Regards
>>> Scott
>>>
>>> HotWax Media
>>> http://www.hotwaxmedia.com
>>>
>>> On 10/12/2009, at 11:06 AM, Jacques Le Roux wrote:
>>>
>>>> If nobody see a problem with this approach I will do... some day...
>>>>
>>>> Jacques
>>>> ()  ascii ribbon campaign against HTML e-mail
>>>> /\  www.asciiribbon.org
>>>>
>>>>
>>>> From: "Jacques Le Roux" <[hidden email]>
>>>>> From: "Adrian Crum" <[hidden email]>
>>>>>> #3 Remove the Shark component: Should be voted on. Voting  
>>>>>> thread  not started yet.
>>>>> I have suggested to create a deprecated directories instead than  
>>>>> simply removing. There OOTB, no compilations, nor Javadoc ,  
>>>>> directions to use  (they already exists but should be extracted  
>>>>> from OPTIONAL_LIBRARIES), no problems for us, visibility for users.
>>>>> Jacques
>>>>
>>>
>>
>>
>
>