Antonio, and what do you think about my approach of solve the problem inside Openbravo, ensuring that export.database output is the same independently of the existance or not of these .jars?
I ask you because you know the tech aspects of the problem better than me. Thanks. David El 09/12/2009 17:29, Antonio Moreno escribió: > 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 > > > ------------------------------------------------------------------------------ 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
