I see what you mean but... source code releases are required by the ASF. Quoting http://www.apache.org/dev/release.html :
"All releases are in the form of the source materials needed to make changes to the software being released. In some cases, binary/bytecode packages are also produced as a convenience to users that might not have the appropriate tools to build a compiled version of the source. In all such cases, the binary/bytecode package must have the same version number as the source release and may only add binary/bytecode files that are the result of compiling that version of the source code release." For simplicity, the OFBiz community releases only "source code" releases; in addition (not in substitution) to them,we could also vote/approve/distribute "binary releases" but this would add a lot of work (and the packages would be rather big) and for now I don't see the need for this. Of course, and maybe it is what you are suggesting, we could remove all jars from the svn repository and then create a release package bundling the source code with all the jars required (and this could be automated with Maven or Ivy): all this without changing our release strategy. My main questions are: what is the real advantage of doing this? How this would solve the problems I posted at the beginning of this thread (that has been ignored to discuss about tools)? Jacopo On Apr 12, 2012, at 4:20 PM, Rajbir Saini wrote: > I agree with you Jacopo regarding bundling the jars in release. But source > code is not release. Apache projects using Maven do not keep jars in the > repository but they do bundle the jars in release. > > Thanks, > > Raj > > On Thursday 12 April 2012 07:38 PM, Jacopo Cappellato wrote: >> Well, I think it is important to bundle all the jars required to build, run >> and test the system in the OFBiz package; and they have to be properly >> listed in LICENSE/NOTICE files. >> See in particular: >> >> http://www.apache.org/dev/release.html#what-must-every-release-contain >> >> Jacopo >> >> On Apr 12, 2012, at 3:52 PM, Jacques Le Roux wrote: >> >>> To be frank, when I 1st read Pierre's proposition I thought it was a good >>> idea and just wanted to ask him for patches :p >>> >>> Then I put my black hat (played the devil's advocate if you prefer) and >>> began to think about drawbacks and possibles issues. No Internet connection >>> poped to my mind and then those minor issues. >>> >>> I now think that the no internet connection is indeed not a deep problem. >>> Because, like you said, you need initially to checkout >>> anyway. >>> >>> But for the slownesss I'm less sure. I just checked and I see that Ivy does >>> not see that it has already downloaded a lib and does it again. Can we >>> prevent that? >>> >>> From: "Rajbir Saini"<rajbsa...@yahoo.com> >>>> Hi Jacques, >>>> >>>> I agree there are minor problems when libraries are downloaded form >>>> different repositories. I had been in similar situation couple >>>> of time in the past. But again, source repository is not really to store >>>> the binary contents. We cant main any versioning >>>> information of the jars in the source repository. >>> You mean "we can maintain any versioning info..." ?. How do you envision >>> that exactly? >>> >>> Jacques >>> >>>> Regarding binary release, almost every project in open source I came >>>> across have an Ant target or Maven goal some thing like dist >>>> to create the binary distribution. Generally, the structure of the >>>> distribution is not same as source tree. Binary releases, >>>> re-organise the code with a directory structure like bin, conf, lib etc. I >>>> feel this is one of the reason we had the problem with >>>> the bin folder colliding with the Eclipse bin folder. Bin folder suppose >>>> to exist only in the binary release and not in the source >>>> tree. >>>> >>>> Thanks, >>>> >>>> Raj >>>> >>>> On Thursday 12 April 2012 04:46 PM, Jacques Le Roux wrote: >>>>> Hi Raj, >>>>> >>>>> From: "Rajbir Saini"<rajbsa...@yahoo.com> >>>>>> BTW, how to you checkout OFBiz or download the source if there is no >>>>>> Internet connection. I know we can build with Maven without >>>>>> Internect connection once you have downloaded the dependencies when you >>>>>> build first time. >>>>> A real important issue with Ivy: it would be much slower to check out the >>>>> whole (I do that often, not always from ASF repo, but >>>>> clients's, etc.). And we will still need to do it for each release to >>>>> package (minor). >>>>> >>>>> There are other minor problems like sometimes you need to extract a >>>>> temporary snapshoots from an attachment somewhere (ie you >>>>> can't >>>>> find it in a repo). I have been in such a situation in the past, notably >>>>> with Geronimo (actually it was WASCE 2.0.0.1 >>>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=7045153). >>>>> Ivy would get stuck in such cases. OK, this is is out >>>>> of >>>>> OFBiz, but we have also snapshots or modifed version of libs (I did, or >>>>> used, one for DBCP years ago). >>>>> >>>>> If we find good solutions for these issues (and some others we may come >>>>> with) then we should discuss it. But the slowness is a >>>>> bummer IMO. >>>>> >>>>>> Also, OFBiz similar to other should have a different binary release and >>>>>> generally binary releases have all the dependencies >>>>>> bundled. Binary releases are for the end users and not developers. >>>>> You mean we don't have binary relases right and users still need to >>>>> build? But all our dependencies are bundled, what's the >>>>> problem? >>>>> I think we already discussed about binary relases. Users would still have >>>>> to load data. We could also package them. But is it not >>>>> easy to simply follow the Quick start here >>>>> http://ofbiz.apache.org/download.html? >>>>> >>>>> Jacques >>>>> >>>>> >>>>>> Thanks, >>>>>> >>>>>> Raj >>>>>> >>>>>> On Thursday 12 April 2012 02:14 AM, Jacques Le Roux wrote: >>>>>>> The problem with this approach: it does not work if you don't have an >>>>>>> Internet connection: blocking >>>>>>> >>>>>>> -1 >>>>>>> >>>>>>> Jacques >>>>>>> >>>>>>> From: "Pierre Smits"<pierre.sm...@gmail.com> >>>>>>>> Hi Jacopo, >>>>>>>> >>>>>>>> How about using Apache Ivy more to manage dependencies. That way OFBiz >>>>>>>> should reduce in size dramatically and the modifications of the >>>>>>>> licence and >>>>>>>> notice file are trimmed down considerably. >>>>>>>> >>>>>>>> Regards, >>>>>>>> >>>>>>>> Pierre >>>>>>>> >>>>>>>> Op 11 april 2012 18:49 schreef Jacopo Cappellato< >>>>>>>> jacopo.cappell...@hotwaxmedia.com> het volgende: >>>>>>>> >>>>>>>>> Hi all, >>>>>>>>> >>>>>>>>> the following are housekeeping tasks that could be part of the >>>>>>>>> "SlimDown" >>>>>>>>> roadmap we could do (help from the community would be highly >>>>>>>>> appreciated) >>>>>>>>> related to the big number of jar files bundled with OFBiz: >>>>>>>>> >>>>>>>>> * making sure all jar files are marked as binary >>>>>>>>> * making sure they are listed properly in LICENSE (and if required >>>>>>>>> NOTICE) >>>>>>>>> file >>>>>>>>> * making sure we are running stable versions and not snapshots >>>>>>>>> (whenever >>>>>>>>> possible) >>>>>>>>> * upgrade jars to use latest versions (whenever possible) >>>>>>>>> * remove jars no more needed >>>>>>>>> * rename old jars to add release numbers in the file name >>>>>>>>> >>>>>>>>> Any ideas on how to document compilation and runtime dependencies, >>>>>>>>> purpose >>>>>>>>> and versions of each jars bundled in OFBiz? >>>>>>>>> A useful (but outdated/incomplete) source of information is this page: >>>>>>>>> >>>>>>>>> >>>>>>>>> https://cwiki.apache.org/confluence/display/OFBADMIN/Libraries+Included+in+OFBiz >>>>>>>>> >>>>>>>>> You may have noticed that in the last few days I already started the >>>>>>>>> work >>>>>>>>> of upgrading some jars, setting the file properties to binary etc.. >>>>>>>>> >>>>>>>>> I have also identified a few jars that may not be needed anymore, but >>>>>>>>> I >>>>>>>>> would like your help/input in figuring out if we can actually remove >>>>>>>>> them; >>>>>>>>> in fact, even if I was able to compile and run successfully all tests >>>>>>>>> it is >>>>>>>>> still not guaranteed that some of them may be used under special >>>>>>>>> conditions >>>>>>>>> at runtime (this is true for all jars): >>>>>>>>> >>>>>>>>> framework/base/lib/ant/ant-nodeps-1.8.1.jar >>>>>>>>> framework/base/lib/Tidy.jar >>>>>>>>> framework/base/lib/ant-trax-1.8.0.jar >>>>>>>>> framework/base/lib/commons/commons-vfs-20070730.jar >>>>>>>>> >>>>>>>>> There may be other files in the same condition. >>>>>>>>> >>>>>>>>> Kind regards, >>>>>>>>> >>>>>>>>> Jacopo >>>>>>>>> >>>>>>>>> >> >
