One possible approach could be a very similar one to the one we use currently for the Java versions.
In 2.40, Java 5 needs to be used. In 2.50, Java 6 needs to be used. So, if we need to commit compiled objects to both branches, usually we use scripts that automatically choose the correct Java JVM when we compile. We could develop a very similar script to do the job for this case (select the correct version of ant for each branch). This way, we would need to change nothing in 2.40. In 2.50, it would be just a matter of removing the two .jar files in our environments, removing them from the installation instructions, and making a big commit with the new format (with double quotes instead of single ones in the xml files). An then, if we need to sometimes work in 2.40, we can develop and use the script that automatically does the work for us. What do you think about this? Regards, Antonio. David Baz Fayos wrote: > I am going to go further... > > Why not do via ant or via java (after export) a parsing that ensure that > " or ' (whatever we want) are always used and if not change them (via > RegExp or simple replace)?? (This texts are always in the first rows of > the xml code, so we can attach them directly instead of a full file parse) > > It would not penalize export times (since this could be done in less > than a second... I think) and with this we are able to control what we > want and we will guarantee a 100% control of our database xmls > independently of if somebody has third party libraries added to its ant > or whatever. (Remember that some people works with several projects, not > just Openbravo, in parallel using the same ant, the same jdk, etc. and > external and unmanaged changes should be avoided) > > David. > > Juan Pablo Aroztegi escribió: > >>> 2.35 had end of maintenance a week ago so no longer an issue.. but the >>> 2.40 case still prevails. >>> >>> >> Yes, important point. I missed it when thinking about the 2.50 problem. >> >> There could be different possibilities: >> >> 1) Find a way to make 2.40 use the jars stored in src-db/database/lib. >> 2) Force developers to copy/remove the files whenever they change from >> 2.40 to 2.50 or vice versa. And put a check in 2.40's build.xml that >> fails to export in these jars are not found. >> >> We'll agree that 1) is preferable. >> >> >> Juan Pablo >> >> >> ------------------------------------------------------------------------------ >> Join us December 9, 2009 for the Red Hat Virtual Experience, >> a free event focused on virtualization and cloud computing. >> Attend in-depth sessions from your desk. Your couch. Anywhere. >> http://p.sf.net/sfu/redhat-sfdev2dev >> _______________________________________________ >> Openbravo-development mailing list >> Openbravo-development@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/openbravo-development >> >> >> >> > > > ------------------------------------------------------------------------------ > Join us December 9, 2009 for the Red Hat Virtual Experience, > a free event focused on virtualization and cloud computing. > Attend in-depth sessions from your desk. Your couch. Anywhere. > http://p.sf.net/sfu/redhat-sfdev2dev > _______________________________________________ > Openbravo-development mailing list > Openbravo-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/openbravo-development > > ------------------------------------------------------------------------------ Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev _______________________________________________ Openbravo-development mailing list Openbravo-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/openbravo-development
