Jacopo, I agree. The long term solution is nice to have. But for now, there has work to be done.
I'll see what I can do, and create the JIRA if it not already exists. Regards, Pierre Op 13 april 2012 08:27 schreef Jacopo Cappellato < jacopo.cappell...@hotwaxmedia.com> het volgende: > > On Apr 12, 2012, at 5:39 PM, Pierre Smits wrote: > > > First of all I believe that (packaged) releases are intended for > > non-developers (end users) and not for developers. That in mind, releases > > should have everything that is needed to run generic production systems. > > And nothing more, not test code, not demo data. > > Pierre, I could agree with you in general but please consider that OFBiz > is a small community and no one is really investing a lot of effort and > helping much in release management (apart from backporting issues); in the > history of OFBiz the community has been mostly focused on new development > on trunk and I don't see a reason now for changing this: we should minimize > the time required to manage releases and the current layout, where we have > *one* project layout that is rather good for both development and packaging > releases, helps in achieving this. > > > > > When developers want to look at what is underneath for testing and/or > > modification they can use svn to have access to everything they might > need. > > > > As is per ASF policy. > > > > We do however facilitate the end user with additional code that helps > them > > to run OFBiz against other underlying Db's and systems (amongst other > > reasons, due to licence-issues) , e.g. the ant targets to download > drivers > > for PostgreSQL and mySQL. I also believe that having source code in > place, > > that downloads every external jar required to run OFBiz as it should, > > adheres to ASF policies. > > If the jars are ASF compliant and not required to run the system. > > > > > I also believe that tooling can help building the releases (no matter > what > > must go in there) as per requirements of the ASF. This would lessen the > > burden on committers. Instead of removing old versions of external jars > and > > uploading new ones manually, doing configuration management (as IVY- and > > Maven-integration deliver) will ensure that the right (external) > > components/jars are incorporated. > > Can we step back a little and focus on my original questions? Instead of > selecting the tool (ivy) and then trying to solve the problem with it > rather than manually please focus on the problem first, then we will select > the right tool if we don't want to manually maintain the jars. > So the main points are: > * we have jars in OFBiz (some of them very old) with no release number in > their file name: we have to research and find the release number and then > document it (manually renaming the file OR editing a tool config file like > Ivy... I don't care at the moment) > * we have jar files that we don't know if they are used or not: we have to > figure out and then remove them (manually removing the file OR removing the > line from the tool config file like Ivy... I don't care at the moment) or > document their purpose > * we have jar files that are snaphots: can we upgrade them to a stable > release or not? (manually or with a tool I don't care at the moment) > * we have jar files that are rather old versions: can/should we update > them or the new versions are backward compatible? and if they are, do we > want to update our code to use the latest versions? > > When we will take a decision/solution for each of the above questions then > we will be ready to evaluate a tool to implement them. > > Jacopo > > > > > Maybe we should setup discussions with Xavier > > Hanin<https://issues.apache.org/jira/secure/ViewProfile.jspa?name=xavier > > > > from > > the IVY project to explain a bit more what it can do for OFBiz, before we > > jump to conclusions or start heading in wrong directions. > > > > I also believe that when applied correct (build, dependency management > and > > CI) tooling will help us in evaluate external jars better to include in > > releases or not, and let us focus on what is more important. > > > > If we decide that the approach is sound, then we should set up a > different > > branch to explore possibilities and not merge back into trunk unless all > > issues are addressed. > > > > Regards, > > > > Pierre > > > > > > > > > > > > Op 12 april 2012 17:02 schreef Jacopo Cappellato < > > jacopo.cappell...@hotwaxmedia.com> het volgende: > > > >> > >> On Apr 12, 2012, at 4:37 PM, Erwan de FERRIERES wrote: > >> > >>> ivy would rename the jars the way we want (eg package-version.jar), > >>> and using ivy, we would then reduce the LICENSE file, as less jars > >>> would be released with OFBiz. From an extremist POV, we could only > >>> whip ant + ivy, and one of the first task would be to download > >>> everything. > >> > >> No no, this is not possible: please ready my previous message carefully; > >> the release package will have to contain required jars (while the svn > may > >> not) and most of all the LICENSE file must contain all jars that are > >> required to run/test/use the software. > >> > >> Jacopo > >
