| From | Sent On | Attachments |
|---|---|---|
| Jacopo Cappellato | Apr 11, 2012 9:49 am | |
| Pierre Smits | Apr 11, 2012 11:34 am | |
| Jacques Le Roux | Apr 11, 2012 1:43 pm | |
| Pierre Smits | Apr 11, 2012 1:51 pm | |
| Jacques Le Roux | Apr 11, 2012 1:57 pm | |
| Pierre Smits | Apr 11, 2012 2:38 pm | |
| Adrian Crum | Apr 12, 2012 12:23 am | |
| Rajbir Saini | Apr 12, 2012 12:29 am | |
| Jacopo Cappellato | Apr 12, 2012 12:31 am | |
| Jacques Le Roux | Apr 12, 2012 4:15 am | |
| Rajbir Saini | Apr 12, 2012 4:30 am | |
| Jacques Le Roux | Apr 12, 2012 6:52 am | |
| Erwan de FERRIERES | Apr 12, 2012 6:55 am | |
| Jacopo Cappellato | Apr 12, 2012 7:07 am | |
| Jacques Le Roux | Apr 12, 2012 7:08 am | |
| Rajbir Saini | Apr 12, 2012 7:20 am | |
| Jacopo Cappellato | Apr 12, 2012 7:32 am | |
| Erwan de FERRIERES | Apr 12, 2012 7:37 am | |
| Jacques Le Roux | Apr 12, 2012 7:45 am | |
| Jacopo Cappellato | Apr 12, 2012 8:02 am | |
| Pierre Smits | Apr 12, 2012 8:39 am | |
| Jacopo Cappellato | Apr 12, 2012 11:26 pm | |
| Pierre Smits | Apr 13, 2012 12:59 am | |
| Jacques Le Roux | Apr 14, 2012 2:48 am | |
| Erwan de FERRIERES | Apr 14, 2012 4:43 am | |
| Pierre Smits | Apr 14, 2012 4:52 am | |
| Jacques Le Roux | Apr 14, 2012 6:33 am | |
| Pierre Smits | Apr 14, 2012 6:58 am | |
| Jacques Le Roux | Apr 15, 2012 1:28 am | |
| Pierre Smits | Apr 15, 2012 2:19 am | |
| Jacques Le Roux | Apr 15, 2012 2:36 am | |
| Jacques Le Roux | Apr 15, 2012 2:44 am | |
| Pierre Smits | Apr 15, 2012 4:45 am | |
| Pierre Smits | Apr 15, 2012 6:17 am | |
| Jacopo Cappellato | Apr 15, 2012 6:28 am | |
| Pierre Smits | Apr 15, 2012 6:46 am | |
| Jacques Le Roux | Apr 15, 2012 6:52 am | |
| Pierre Smits | Apr 15, 2012 7:10 am | |
| Jacopo Cappellato | Apr 15, 2012 7:48 am |
| Subject: | Re: Housekeeping of jar files | |
|---|---|---|
| From: | Jacques Le Roux (jacq...@les7arts.com) | |
| Date: | Apr 14, 2012 2:48:57 am | |
| List: | org.apache.ofbiz.dev | |
* 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)
I can take care of that
I found
bsh-engine-modified.jar httpunit.jar mail.jar nekohtml.jar Tidy.jar flute.jar jaxrpc.jar js.jar saaj.jar
In Birt: Tidy.jar (duplicated, also in main lib, I guess remove from Birt) viewservlets.jar
ofbiz-minerva.jar (should we really keep it and related now? We know it's an
OFBiz specific version, ie patched)
axis.jar
wsdl4j.jar
selenium-java-client-driver.jar
javacc.jar (found a note from Marco: Upgrade javacc to 5.0 version, the
javacc.jar must having only this name:
http://svn.apache.org/viewvc?rev=1076756&view=rev)
\specialpurpose\ebaystore\lib attributes.jar ebaycalls.jar ebaysdkcore.jar helper.jar
jcl.jar
ofbiz-tools.jar (should stay as is, I guess)
Also I wonder if we should take care about the parts which will be mode out of
OFBiz repo...?
Jacques
From: "Jacopo Cappellato" <jaco...@hotwaxmedia.com>
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 < jaco...@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





