Housekeeping of jar files

[Pierre Smits]

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.

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.

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.

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 <
[hidden email]> 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

[Jacopo Cappellato-4]

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 <
> [hidden email]> 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

[Pierre Smits]

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 <
[hidden email]> 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 <
> > [hidden email]> 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
>
>

[Jacques Le Roux]

> * 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" <[hidden email]>

>
> 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 <
>> [hidden email]> 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
>
>

[Erwan de FERRIERES]

Le 12/04/2012 17:02, Jacopo Cappellato a écrit :

>
> 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

yep, sorry, I must have read too quickly.

--
Erwan de FERRIERES
www.nereide.biz

[Pierre Smits]

Also without version number:


   - jython-nooro.jar
   - axis-ant.jar
   - org.springframework.core-3.1.0.M2.jar
   - org.springframework.test-3.1.0.M2.jar
   - org.springframework.web-3.1.0.M2.jar
   - selenium-server.jar
   - jpos18-controls.jar

Regards,

Pierre

Op 14 april 2012 13:44 schreef Erwan de FERRIERES <
[hidden email]> het volgende:

> Le 12/04/2012 17:02, Jacopo Cappellato a écrit :
>
>
>> 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
>>
>
> yep, sorry, I must have read too quickly.
>
> --
> Erwan de FERRIERES
> www.nereide.biz
>

[Jacques Le Roux]

Thanks Pierre,

I have added to my list

>    - jython-nooro.jar
>    - axis-ant.jar
>    - selenium-server.jar

>    - org.springframework.core-3.1.0.M2.jar
>    - org.springframework.test-3.1.0.M2.jar
>    - org.springframework.web-3.1.0.M2.jar
Seems more to be in the
>> * 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
category. TO be confirmed

>    - jpos18-controls.jar
has a version number: 18

Jacques



Pierre Smits wrote:

> Also without version number:
>
>
>    - jython-nooro.jar
>    - axis-ant.jar
>    - org.springframework.core-3.1.0.M2.jar
>    - org.springframework.test-3.1.0.M2.jar
>    - org.springframework.web-3.1.0.M2.jar
>    - selenium-server.jar
>    - jpos18-controls.jar
>
> Regards,
>
> Pierre

[Pierre Smits]

Jacques,

According to mvnrepository the org.springframework has a 3.1.1 release
available.
See http://mvnrepository.com/artifact/org.springframework, but also a 3.1.0
release version.

The jars seem to be related to testtools, so I wonder whether these should
be in...



Regards,

Pierre

Op 14 april 2012 15:33 schreef Jacques Le Roux <[hidden email]
> het volgende:

> Thanks Pierre,
>
> I have added to my list
>
>    - jython-nooro.jar
>>   - axis-ant.jar
>>   - selenium-server.jar
>>
>
>    - org.springframework.core-3.1.**0.M2.jar
>>   - org.springframework.test-3.1.**0.M2.jar
>>   - org.springframework.web-3.1.0.**M2.jar
>>
> Seems more to be in the
>
>  * 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
>>>
>> category. TO be confirmed
>
>    - jpos18-controls.jar
>>
> has a version number: 18
>
> Jacques
>
>
>
> Pierre Smits wrote:
>
>> Also without version number:
>>
>>
>>   - jython-nooro.jar
>>   - axis-ant.jar
>>   - org.springframework.core-3.1.**0.M2.jar
>>   - org.springframework.test-3.1.**0.M2.jar
>>   - org.springframework.web-3.1.0.**M2.jar
>>   - selenium-server.jar
>>   - jpos18-controls.jar
>>
>> Regards,
>>
>> Pierre
>>
>

[Jacques Le Roux]

Thanks Pierre,

As you committed the org.springframework* files I'd prefer that you check if using v3.1.1 as suggested Pierre would work (I suppose,
but who knows before testing) while I focus on renaming not versionned libs

Thanks

Jacques

From: "Pierre Smits" <[hidden email]>

> Jacques,
>
> According to mvnrepository the org.springframework has a 3.1.1 release
> available.
> See http://mvnrepository.com/artifact/org.springframework, but also a 3.1.0
> release version.
>
> The jars seem to be related to testtools, so I wonder whether these should
> be in...
>
>
>
> Regards,
>
> Pierre
>
> Op 14 april 2012 15:33 schreef Jacques Le Roux <[hidden email]
>> het volgende:
>
>> Thanks Pierre,
>>
>> I have added to my list
>>
>>    - jython-nooro.jar
>>>   - axis-ant.jar
>>>   - selenium-server.jar
>>>
>>
>>    - org.springframework.core-3.1.**0.M2.jar
>>>   - org.springframework.test-3.1.**0.M2.jar
>>>   - org.springframework.web-3.1.0.**M2.jar
>>>
>> Seems more to be in the
>>
>>  * 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
>>>>
>>> category. TO be confirmed
>>
>>    - jpos18-controls.jar
>>>
>> has a version number: 18
>>
>> Jacques
>>
>>
>>
>> Pierre Smits wrote:
>>
>>> Also without version number:
>>>
>>>
>>>   - jython-nooro.jar
>>>   - axis-ant.jar
>>>   - org.springframework.core-3.1.**0.M2.jar
>>>   - org.springframework.test-3.1.**0.M2.jar
>>>   - org.springframework.web-3.1.0.**M2.jar
>>>   - selenium-server.jar
>>>   - jpos18-controls.jar
>>>
>>> Regards,
>>>
>>> Pierre
>>>
>>
>

[Pierre Smits]

Thanks Jacques,

But you should credit and address Hans Bakker as he committed the
org.springframework jars in
r1163084<http://svn.apache.org/viewvc?view=revision&revision=1163084>.
I am just a contributor.

But I can submit a patch, if you want me to.

Regards,

Pierre

Op 15 april 2012 10:28 schreef Jacques Le Roux <[hidden email]
> het volgende:

> Thanks Pierre,
>
> As you committed the org.springframework* files I'd prefer that you check
> if using v3.1.1 as suggested Pierre would work (I suppose, but who knows
> before testing) while I focus on renaming not versionned libs
>
> Thanks
>
>
> Jacques
>
> From: "Pierre Smits" <[hidden email]>
>
>> Jacques,
>>
>>
>> According to mvnrepository the org.springframework has a 3.1.1 release
>> available.
>> See http://mvnrepository.com/**artifact/org.springframework<http://mvnrepository.com/artifact/org.springframework>,
>> but also a 3.1.0
>> release version.
>>
>> The jars seem to be related to testtools, so I wonder whether these should
>> be in...
>>
>>
>>
>> Regards,
>>
>> Pierre
>>
>> Op 14 april 2012 15:33 schreef Jacques Le Roux <
>> [hidden email]
>>
>>> het volgende:
>>>
>>
>>  Thanks Pierre,
>>>
>>> I have added to my list
>>>
>>>   - jython-nooro.jar
>>>
>>>>  - axis-ant.jar
>>>>  - selenium-server.jar
>>>>
>>>>
>>>   - org.springframework.core-3.1.****0.M2.jar
>>>
>>>>  - org.springframework.test-3.1.****0.M2.jar
>>>>  - org.springframework.web-3.1.0.****M2.jar
>>>>
>>>>  Seems more to be in the
>>>
>>>  * 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
>>>>>
>>>>>  category. TO be confirmed
>>>>
>>>
>>>   - jpos18-controls.jar
>>>
>>>>
>>>>  has a version number: 18
>>>
>>> Jacques
>>>
>>>
>>>
>>> Pierre Smits wrote:
>>>
>>>  Also without version number:
>>>>
>>>>
>>>>  - jython-nooro.jar
>>>>  - axis-ant.jar
>>>>  - org.springframework.core-3.1.****0.M2.jar
>>>>  - org.springframework.test-3.1.****0.M2.jar
>>>>  - org.springframework.web-3.1.0.****M2.jar
>>>>
>>>>  - selenium-server.jar
>>>>  - jpos18-controls.jar
>>>>
>>>> Regards,
>>>>
>>>> Pierre
>>>>
>>>>
>>>
>>

[Jacques Le Roux]

With Pierre's comment, I haved added  in the list:

* jython-nooro.jar : can't find any evidences, somebody an idea? I think we should update to a newer version (scripting). Or even
wonder, since there is no use OOTB, if we should not comment out in service engine and let people download the latest versions
(other script engines too) if they are interested... Less burden, more accurate...
* axis-ant.jar, it's the lastest version included with axis-1.4 so I renamed it axis-ant-1.4.jar (it has no name in Axis bundle)
* selenium-server.jar: was in Pierre's list but I can't find it in trunk...

Some changes I did today
* axis.jar => axis-1.4.jar
* bsh-engine-modified.jar I think it can stay like that. it's the bsh-engine modified by David for the cache issue.
* wsdl4j.jar => wsdl4j-1.5.1.jar found in Manifest

* selenium-java-client-driver.jar came with svn.apache.org/viewvc?view=revision&revision=804074 I have not idea of the version. Do
we want to keep this in OFBiz now?

Enough for today

Jacques


From: "Jacques Le Roux" <[hidden email]>
>> * 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
OK done

> 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

OK done

> wsdl4j.jar
OK done

> 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" <[hidden email]>
>>
>> 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 <
>>> [hidden email]> 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
>>
>>

[Jacques Le Roux]

Hi Pierre,

Oops, indeed forgot to put

Hans,

before

>> As you committed the org.springframework* files I'd prefer that you check
>> if using v3.1.1 as suggested Pierre would work (I suppose, but who knows

Please let's wait Hans's answer

Jacques

From: "Pierre Smits" <[hidden email]>

> Thanks Jacques,
>
> But you should credit and address Hans Bakker as he committed the
> org.springframework jars in
> r1163084<http://svn.apache.org/viewvc?view=revision&revision=1163084>.
> I am just a contributor.
>
> But I can submit a patch, if you want me to.
>
> Regards,
>
> Pierre
>
> Op 15 april 2012 10:28 schreef Jacques Le Roux <[hidden email]
>> het volgende:
>
>> Thanks Pierre,
>>
>> As you committed the org.springframework* files I'd prefer that you check
>> if using v3.1.1 as suggested Pierre would work (I suppose, but who knows
>> before testing) while I focus on renaming not versionned libs
>>
>> Thanks
>>
>>
>> Jacques
>>
>> From: "Pierre Smits" <[hidden email]>
>>
>>> Jacques,
>>>
>>>
>>> According to mvnrepository the org.springframework has a 3.1.1 release
>>> available.
>>> See http://mvnrepository.com/**artifact/org.springframework<http://mvnrepository.com/artifact/org.springframework>,
>>> but also a 3.1.0
>>> release version.
>>>
>>> The jars seem to be related to testtools, so I wonder whether these should
>>> be in...
>>>
>>>
>>>
>>> Regards,
>>>
>>> Pierre
>>>
>>> Op 14 april 2012 15:33 schreef Jacques Le Roux <
>>> [hidden email]
>>>
>>>> het volgende:
>>>>
>>>
>>>  Thanks Pierre,
>>>>
>>>> I have added to my list
>>>>
>>>>   - jython-nooro.jar
>>>>
>>>>>  - axis-ant.jar
>>>>>  - selenium-server.jar
>>>>>
>>>>>
>>>>   - org.springframework.core-3.1.****0.M2.jar
>>>>
>>>>>  - org.springframework.test-3.1.****0.M2.jar
>>>>>  - org.springframework.web-3.1.0.****M2.jar
>>>>>
>>>>>  Seems more to be in the
>>>>
>>>>  * 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
>>>>>>
>>>>>>  category. TO be confirmed
>>>>>
>>>>
>>>>   - jpos18-controls.jar
>>>>
>>>>>
>>>>>  has a version number: 18
>>>>
>>>> Jacques
>>>>
>>>>
>>>>
>>>> Pierre Smits wrote:
>>>>
>>>>  Also without version number:
>>>>>
>>>>>
>>>>>  - jython-nooro.jar
>>>>>  - axis-ant.jar
>>>>>  - org.springframework.core-3.1.****0.M2.jar
>>>>>  - org.springframework.test-3.1.****0.M2.jar
>>>>>  - org.springframework.web-3.1.0.****M2.jar
>>>>>
>>>>>  - selenium-server.jar
>>>>>  - jpos18-controls.jar
>>>>>
>>>>> Regards,
>>>>>
>>>>> Pierre
>>>>>
>>>>>
>>>>
>>>
>

[Pierre Smits]

Grin.

No problem.



Op 15 april 2012 11:45 schreef Jacques Le Roux <[hidden email]
> het volgende:

> Hi Pierre,
>
> Oops, indeed forgot to put
> Hans,
>
> before
>
>
>  As you committed the org.springframework* files I'd prefer that you check
>>> if using v3.1.1 as suggested Pierre would work (I suppose, but who knows
>>>
>>
> Please let's wait Hans's answer
>
>
> Jacques
>
> From: "Pierre Smits" <[hidden email]>
>
>> Thanks Jacques,
>>
>>
>> But you should credit and address Hans Bakker as he committed the
>> org.springframework jars in
>> r1163084<http://svn.apache.**org/viewvc?view=revision&**revision=1163084<http://svn.apache.org/viewvc?view=revision&revision=1163084>
>> >.
>>
>> I am just a contributor.
>>
>> But I can submit a patch, if you want me to.
>>
>> Regards,
>>
>> Pierre
>>
>> Op 15 april 2012 10:28 schreef Jacques Le Roux <
>> [hidden email]
>>
>>> het volgende:
>>>
>>
>>  Thanks Pierre,
>>>
>>> As you committed the org.springframework* files I'd prefer that you check
>>> if using v3.1.1 as suggested Pierre would work (I suppose, but who knows
>>> before testing) while I focus on renaming not versionned libs
>>>
>>> Thanks
>>>
>>>
>>> Jacques
>>>
>>> From: "Pierre Smits" <[hidden email]>
>>>
>>>  Jacques,
>>>>
>>>>
>>>> According to mvnrepository the org.springframework has a 3.1.1 release
>>>> available.
>>>> See http://mvnrepository.com/****artifact/org.springframework<http://mvnrepository.com/**artifact/org.springframework>
>>>> <h**ttp://mvnrepository.com/**artifact/org.springframework<http://mvnrepository.com/artifact/org.springframework>
>>>> >,
>>>>
>>>> but also a 3.1.0
>>>> release version.
>>>>
>>>> The jars seem to be related to testtools, so I wonder whether these
>>>> should
>>>> be in...
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Pierre
>>>>
>>>> Op 14 april 2012 15:33 schreef Jacques Le Roux <
>>>> [hidden email]
>>>>
>>>>  het volgende:
>>>>>
>>>>>
>>>>  Thanks Pierre,
>>>>
>>>>>
>>>>> I have added to my list
>>>>>
>>>>>  - jython-nooro.jar
>>>>>
>>>>>   - axis-ant.jar
>>>>>>  - selenium-server.jar
>>>>>>
>>>>>>
>>>>>>   - org.springframework.core-3.1.******0.M2.jar
>>>>>
>>>>>   - org.springframework.test-3.1.******0.M2.jar
>>>>>>  - org.springframework.web-3.1.0.******M2.jar
>>>>>>
>>>>>>
>>>>>>  Seems more to be in the
>>>>>>
>>>>>
>>>>>  * 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
>>>>>>
>>>>>>>
>>>>>>>  category. TO be confirmed
>>>>>>>
>>>>>>
>>>>>>
>>>>>  - jpos18-controls.jar
>>>>>
>>>>>
>>>>>>  has a version number: 18
>>>>>>
>>>>>
>>>>> Jacques
>>>>>
>>>>>
>>>>>
>>>>> Pierre Smits wrote:
>>>>>
>>>>>  Also without version number:
>>>>>
>>>>>>
>>>>>>
>>>>>>  - jython-nooro.jar
>>>>>>  - axis-ant.jar
>>>>>>  - org.springframework.core-3.1.******0.M2.jar
>>>>>>  - org.springframework.test-3.1.******0.M2.jar
>>>>>>  - org.springframework.web-3.1.0.******M2.jar
>>>>>>
>>>>>>
>>>>>>  - selenium-server.jar
>>>>>>  - jpos18-controls.jar
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Pierre
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>

[Pierre Smits]

Jacques,

I can provide a patch that:

   1. removes the org.springframework related jar from
   framework/testtools/lib
   2. has a target called <download-testtools> in build.xml that downloads
   the jars r3.1.0 by using ivy
   3. has a new config setup in ivy.xml for the download of the applicable
   test tools

I have tested it locally against ./ant run-test and it build successfully.

Is this something we would want in our 'slimdown' branch/version?

Regards,

Pierre

Op 15 april 2012 13:46 schreef Pierre Smits <[hidden email]> het
volgende:

> Grin.
>
> No problem.
>
>
>
> Op 15 april 2012 11:45 schreef Jacques Le Roux <
> [hidden email]> het volgende:
>
> Hi Pierre,
>>
>> Oops, indeed forgot to put
>> Hans,
>>
>> before
>>
>>
>>  As you committed the org.springframework* files I'd prefer that you check
>>>> if using v3.1.1 as suggested Pierre would work (I suppose, but who knows
>>>>
>>>
>> Please let's wait Hans's answer
>>
>>
>> Jacques
>>
>> From: "Pierre Smits" <[hidden email]>
>>
>>> Thanks Jacques,
>>>
>>>
>>> But you should credit and address Hans Bakker as he committed the
>>> org.springframework jars in
>>> r1163084<http://svn.apache.**org/viewvc?view=revision&**revision=1163084<http://svn.apache.org/viewvc?view=revision&revision=1163084>
>>> >.
>>>
>>> I am just a contributor.
>>>
>>> But I can submit a patch, if you want me to.
>>>
>>> Regards,
>>>
>>> Pierre
>>>
>>> Op 15 april 2012 10:28 schreef Jacques Le Roux <
>>> [hidden email]
>>>
>>>> het volgende:
>>>>
>>>
>>>  Thanks Pierre,
>>>>
>>>> As you committed the org.springframework* files I'd prefer that you
>>>> check
>>>> if using v3.1.1 as suggested Pierre would work (I suppose, but who knows
>>>> before testing) while I focus on renaming not versionned libs
>>>>
>>>> Thanks
>>>>
>>>>
>>>> Jacques
>>>>
>>>> From: "Pierre Smits" <[hidden email]>
>>>>
>>>>  Jacques,
>>>>>
>>>>>
>>>>> According to mvnrepository the org.springframework has a 3.1.1 release
>>>>> available.
>>>>> See http://mvnrepository.com/****artifact/org.springframework<http://mvnrepository.com/**artifact/org.springframework>
>>>>> <h**ttp://mvnrepository.com/**artifact/org.springframework<http://mvnrepository.com/artifact/org.springframework>
>>>>> >,
>>>>>
>>>>> but also a 3.1.0
>>>>> release version.
>>>>>
>>>>> The jars seem to be related to testtools, so I wonder whether these
>>>>> should
>>>>> be in...
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Pierre
>>>>>
>>>>> Op 14 april 2012 15:33 schreef Jacques Le Roux <
>>>>> [hidden email]
>>>>>
>>>>>  het volgende:
>>>>>>
>>>>>>
>>>>>  Thanks Pierre,
>>>>>
>>>>>>
>>>>>> I have added to my list
>>>>>>
>>>>>>  - jython-nooro.jar
>>>>>>
>>>>>>   - axis-ant.jar
>>>>>>>  - selenium-server.jar
>>>>>>>
>>>>>>>
>>>>>>>   - org.springframework.core-3.1.******0.M2.jar
>>>>>>
>>>>>>   - org.springframework.test-3.1.******0.M2.jar
>>>>>>>  - org.springframework.web-3.1.0.******M2.jar
>>>>>>>
>>>>>>>
>>>>>>>  Seems more to be in the
>>>>>>>
>>>>>>
>>>>>>  * 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
>>>>>>>
>>>>>>>>
>>>>>>>>  category. TO be confirmed
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>  - jpos18-controls.jar
>>>>>>
>>>>>>
>>>>>>>  has a version number: 18
>>>>>>>
>>>>>>
>>>>>> Jacques
>>>>>>
>>>>>>
>>>>>>
>>>>>> Pierre Smits wrote:
>>>>>>
>>>>>>  Also without version number:
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>  - jython-nooro.jar
>>>>>>>  - axis-ant.jar
>>>>>>>  - org.springframework.core-3.1.******0.M2.jar
>>>>>>>  - org.springframework.test-3.1.******0.M2.jar
>>>>>>>  - org.springframework.web-3.1.0.******M2.jar
>>>>>>>
>>>>>>>
>>>>>>>  - selenium-server.jar
>>>>>>>  - jpos18-controls.jar
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>> Pierre
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>

[Jacopo Cappellato-4]

On Apr 15, 2012, at 3:18 PM, Pierre Smits wrote:

> Is this something we would want in our 'slimdown' branch/version?

If I am not wrong these jars are related to the "Seleniumxml" integration added to testtools and we discussed in the user list about the opportunity to remove it and there was a general consensus for the removal: I think we could simply remove them together with the other seleniumxml related files.

Jacopo

[Pierre Smits]

Then the patch will be even shorter.

Pierre

Op 15 april 2012 15:28 schreef Jacopo Cappellato <
[hidden email]> het volgende:

> On Apr 15, 2012, at 3:18 PM, Pierre Smits wrote:
>
> > Is this something we would want in our 'slimdown' branch/version?
>
> If I am not wrong these jars are related to the "Seleniumxml" integration
> added to testtools and we discussed in the user list about the opportunity
> to remove it and there was a general consensus for the removal: I think we
> could simply remove them together with the other seleniumxml related files.
>
> Jacopo

[Jacques Le Roux]

From: "Jacopo Cappellato" <[hidden email]>
> On Apr 15, 2012, at 3:18 PM, Pierre Smits wrote:
>
>> Is this something we would want in our 'slimdown' branch/version?
>
> If I am not wrong these jars are related to the "Seleniumxml" integration added to testtools and we discussed in the user list
> about the opportunity to remove it and there was a general consensus for the removal: I think we could simply remove them together
> with the other seleniumxml related files.
>
> Jacopo

Actually it's another commit http://svn.apache.org/viewvc?view=revision&revision=1163084

IIRW there was a consensus to remove the "Seleniumxml" integration. I tried to revert 804074 but got a lot of conflicts. Need to be
done either with multiples reverts or by hand...

> * selenium-java-client-driver.jar came with http://svn.apache.org/viewvc?view=revision&revision=804074
>I have not idea of the version. Do we want to keep this in OFBiz now?

Jacques

[Pierre Smits]

Jacopo,

Please keep in mind that there is a GSOC 2012 task running regarding
selenium under the supervision of Erwan. See
OFBIZ-4189<https://issues.apache.org/jira/browse/OFBIZ-4189>

Also, in a reply to your mail with title 'Who is using the seleniumxml and
why?' Hans stated that it is being used in testing setups. And earlier
Jacques replied that we'll have to give Hans a reasonable amount of time to
reply.

The patch that I can provide will bring us further on the track of
'slimdown', while maintaining the possibility to execute extended tests in
both CI integrated testing as manual testing without having the need to
manually download and place jars in correct folders.

Regards,

Pierre


Op 15 april 2012 15:53 schreef Jacques Le Roux <[hidden email]
> het volgende:

> From: "Jacopo Cappellato" <jacopo.cappellato@**hotwaxmedia.com<[hidden email]>
> >
>
>  On Apr 15, 2012, at 3:18 PM, Pierre Smits wrote:
>>
>>  Is this something we would want in our 'slimdown' branch/version?
>>>
>>
>> If I am not wrong these jars are related to the "Seleniumxml" integration
>> added to testtools and we discussed in the user list
>> about the opportunity to remove it and there was a general consensus for
>> the removal: I think we could simply remove them together
>> with the other seleniumxml related files.
>>
>> Jacopo
>>
>
> Actually it's another commit http://svn.apache.org/viewvc?**
> view=revision&revision=1163084<http://svn.apache.org/viewvc?view=revision&revision=1163084>
>
> IIRW there was a consensus to remove the "Seleniumxml" integration. I
> tried to revert 804074 but got a lot of conflicts. Need to be done either
> with multiples reverts or by hand...
>
>  * selenium-java-client-driver.**jar came with
>> http://svn.apache.org/viewvc?**view=revision&revision=804074<http://svn.apache.org/viewvc?view=revision&revision=804074>
>>
>> I have not idea of the version. Do we want to keep this in OFBiz now?
>>
>
> Jacques
>

[Jacopo Cappellato-4]

On Apr 15, 2012, at 4:10 PM, Pierre Smits wrote:

> Jacopo,
>
> Please keep in mind that there is a GSOC 2012 task running regarding
> selenium under the supervision of Erwan. See
> OFBIZ-4189<https://issues.apache.org/jira/browse/OFBIZ-4189>

I would suggest to defer to that task the decision about the jars required.

>
> Also, in a reply to your mail with title 'Who is using the seleniumxml and
> why?' Hans stated that it is being used in testing setups. And earlier
> Jacques replied that we'll have to give Hans a reasonable amount of time to
> reply.

I don't think it is still a problem because they had plenty of time since then.

Jacopo

>
> The patch that I can provide will bring us further on the track of
> 'slimdown', while maintaining the possibility to execute extended tests in
> both CI integrated testing as manual testing without having the need to
> manually download and place jars in correct folders.
>
> Regards,
>
> Pierre
>
>
> Op 15 april 2012 15:53 schreef Jacques Le Roux <[hidden email]
>> het volgende:
>
>> From: "Jacopo Cappellato" <jacopo.cappellato@**hotwaxmedia.com<[hidden email]>
>>>
>>
>> On Apr 15, 2012, at 3:18 PM, Pierre Smits wrote:
>>>
>>> Is this something we would want in our 'slimdown' branch/version?
>>>>
>>>
>>> If I am not wrong these jars are related to the "Seleniumxml" integration
>>> added to testtools and we discussed in the user list
>>> about the opportunity to remove it and there was a general consensus for
>>> the removal: I think we could simply remove them together
>>> with the other seleniumxml related files.
>>>
>>> Jacopo
>>>
>>
>> Actually it's another commit http://svn.apache.org/viewvc?**
>> view=revision&revision=1163084<http://svn.apache.org/viewvc?view=revision&revision=1163084>
>>
>> IIRW there was a consensus to remove the "Seleniumxml" integration. I
>> tried to revert 804074 but got a lot of conflicts. Need to be done either
>> with multiples reverts or by hand...
>>
>> * selenium-java-client-driver.**jar came with
>>> http://svn.apache.org/viewvc?**view=revision&revision=804074<http://svn.apache.org/viewvc?view=revision&revision=804074>
>>>
>>> I have not idea of the version. Do we want to keep this in OFBiz now?
>>>
>>
>> Jacques
>>