Housekeeping of jar files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Housekeeping of jar files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

Thanks Adrian,

I can confirm that Commons VFS was used by Webslinger... can someone confirm that it is now required by Jackrabbit? And if yes, what is the version required by Jackrabbit? Can we at least use a stable version of it rather than a snapshot?

Jacopo

On Apr 12, 2012, at 9:23 AM, Adrian Crum wrote:

> I believe Tidy is used by some of the HTTP client libraries, and Commons VFS was used by Webslinger (it might be used currently by Jackrabbit).
> 
> -Adrian
> 
> On 4/11/2012 5:49 PM, Jacopo Cappellato wrote:
>> 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
>> 

Re: Housekeeping of jar files

[Adrian Crum <ad...@sandglass-software.com>]

I believe Tidy is used by some of the HTTP client libraries, and Commons 
VFS was used by Webslinger (it might be used currently by Jackrabbit).

-Adrian

On 4/11/2012 5:49 PM, Jacopo Cappellato wrote:
> 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
>

Re: Housekeeping of jar files

[Jacques Le Roux <ja...@les7arts.com>]

Thanks Erwan,

That was not clear to me.

So then maybe we could discuss Pierre's proposition. But to have a real idea of the time added (not an estimate) if we use Ivy 
instead of having the libs in the repo, we need to have all done already...

Jacques

From: "Erwan de FERRIERES" <er...@gmail.com>
> 2012/4/12 Jacques Le Roux <ja...@les7arts.com>:
>> 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?
>
> wrong, it checks in the .ivy folder.
> If you look at the log, and the jar is already downloaded, it will
> tell you downloaded 0 / copied 1 (or something like that).
>
> -- 
> Erwan de FERRIERES 

Re: Housekeeping of jar files

[Erwan de FERRIERES <er...@gmail.com>]

2012/4/12 Jacques Le Roux <ja...@les7arts.com>:
> 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?

wrong, it checks in the .ivy folder.
If you look at the log, and the jar is already downloaded, it will
tell you downloaded 0 / copied 1 (or something like that).

-- 
Erwan de FERRIERES

Re: Housekeeping of jar files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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 <jacques.le.roux@les7arts.com
>> het volgende:
> 
>> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
>>> 
>> 
>> 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
>> 

Re: Housekeeping of jar files

[Pierre Smits <pi...@gmail.com>]

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 <jacques.le.roux@les7arts.com
> het volgende:

> From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> >
>
>  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
>

Re: Housekeeping of jar files

[Jacques Le Roux <ja...@les7arts.com>]

From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> 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

Re: Housekeeping of jar files

[Pierre Smits <pi...@gmail.com>]

Then the patch will be even shorter.

Pierre

Op 15 april 2012 15:28 schreef Jacopo Cappellato <
jacopo.cappellato@hotwaxmedia.com> 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

Re: Housekeeping of jar files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Housekeeping of jar files

[Pierre Smits <pi...@gmail.com>]

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 <pi...@gmail.com> het
volgende:

> Grin.
>
> No problem.
>
>
>
> Op 15 april 2012 11:45 schreef Jacques Le Roux <
> jacques.le.roux@les7arts.com> 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" <pi...@gmail.com>
>>
>>> 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 <
>>> jacques.le.roux@les7arts.com
>>>
>>>> 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" <pi...@gmail.com>
>>>>
>>>>  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 <
>>>>> jacques.le.roux@les7arts.com
>>>>>
>>>>>  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
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>
>

Re: Housekeeping of jar files

[Pierre Smits <pi...@gmail.com>]

Grin.

No problem.



Op 15 april 2012 11:45 schreef Jacques Le Roux <jacques.le.roux@les7arts.com
> 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" <pi...@gmail.com>
>
>> 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 <
>> jacques.le.roux@les7arts.com
>>
>>> 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" <pi...@gmail.com>
>>>
>>>  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 <
>>>> jacques.le.roux@les7arts.com
>>>>
>>>>  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
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>

Re: Housekeeping of jar files

[Jacques Le Roux <ja...@les7arts.com>]

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" <pi...@gmail.com>
> 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 <jacques.le.roux@les7arts.com
>> 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" <pi...@gmail.com>
>>
>>> 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 <
>>> jacques.le.roux@les7arts.com
>>>
>>>> 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
>>>>>
>>>>>
>>>>
>>>
>

Re: Housekeeping of jar files

[Pierre Smits <pi...@gmail.com>]

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 <jacques.le.roux@les7arts.com
> 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" <pi...@gmail.com>
>
>> 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 <
>> jacques.le.roux@les7arts.com
>>
>>> 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
>>>>
>>>>
>>>
>>

Re: Housekeeping of jar files

[Jacques Le Roux <ja...@les7arts.com>]

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" <pi...@gmail.com>
> 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 <jacques.le.roux@les7arts.com
>> 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
>>>
>>
> 

Re: Housekeeping of jar files

[Pierre Smits <pi...@gmail.com>]

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 <jacques.le.roux@les7arts.com
> 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
>>
>

Re: Housekeeping of jar files

[Jacques Le Roux <ja...@les7arts.com>]

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

Re: Housekeeping of jar files

[Pierre Smits <pi...@gmail.com>]

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 <
erwan.de-ferrieres@nereide.fr> 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
>

Re: Housekeeping of jar files

[Erwan de FERRIERES <er...@nereide.fr>]

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

Re: Housekeeping of jar files

[Jacques Le Roux <ja...@les7arts.com>]

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" <ja...@les7arts.com>
>> * 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" <ja...@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 <
>>> jacopo.cappellato@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
>>
>> 

Re: Housekeeping of jar files

[Jacques Le Roux <ja...@les7arts.com>]

> * 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" <ja...@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 <
>> jacopo.cappellato@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
>
> 

Re: Housekeeping of jar files

[Pierre Smits <pi...@gmail.com>]

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.cappellato@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.cappellato@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
>
>

Re: Housekeeping of jar files

[Jacopo Cappellato <ja...@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 <
> jacopo.cappellato@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

Re: Housekeeping of jar files

[Pierre Smits <pi...@gmail.com>]

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 <
jacopo.cappellato@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

Re: Housekeeping of jar files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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

Re: Housekeeping of jar files

[Erwan de FERRIERES <er...@gmail.com>]

../..

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

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.


../..
-- 
Erwan de FERRIERES

Re: Housekeeping of jar files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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"<ra...@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"<ra...@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"<pi...@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.cappellato@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
>>>>>>>>> 
>>>>>>>>> 
>> 
> 

Re: Housekeeping of jar files

[Rajbir Saini <ra...@yahoo.com>]

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"<ra...@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"<ra...@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"<pi...@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.cappellato@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
>>>>>>>>
>>>>>>>>
>

Re: Housekeeping of jar files

[Jacques Le Roux <ja...@les7arts.com>]

Yes, I was only dicussing about trunk checkout. As proposed Raj a specific ant task could be used to prepare the releases.
Anyway more a brainstorming than anything else at this stage

Jacques

From: "Jacopo Cappellato" <ja...@hotwaxmedia.com>
> 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" <ra...@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" <ra...@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" <pi...@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.cappellato@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
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
> 

Re: Housekeeping of jar files

[Jacopo Cappellato <ja...@hotwaxmedia.com>]

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" <ra...@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" <ra...@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" <pi...@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.cappellato@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
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 

Re: Housekeeping of jar files

[Jacques Le Roux <ja...@les7arts.com>]

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" <ra...@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" <ra...@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" <pi...@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.cappellato@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
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Housekeeping of jar files

[Rajbir Saini <ra...@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.

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" <ra...@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" <pi...@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.cappellato@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
>>>>>
>>>>>
>>>>
>>>
>>
>

Re: Housekeeping of jar files

[Jacques Le Roux <ja...@les7arts.com>]

Hi Raj,

From: "Rajbir Saini" <ra...@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" <pi...@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.cappellato@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
>>>>
>>>>
>>>
>>
>

Re: Housekeeping of jar files

[Rajbir Saini <ra...@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. 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.

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" <pi...@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.cappellato@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
>>>
>>>
>>
>

Re: Housekeeping of jar files

[Pierre Smits <pi...@gmail.com>]

Sometims my privileges get in the way of reason. ;-)

Op 11 april 2012 22:58 schreef Jacques Le Roux <jl...@les7arts.com> het
volgende:

> There are situations where you are able to download and then deploy where
> you don't have a connection. If then things change it can turn in a
> nightmare
> Also there are situations where, etc... Think about it, not only your
> way...
>
> It's ok for secondary libs, and most often used for those we can't upload
> to ASF repo because they don't have the right license. Else it does not
> worth the trouble.
>
> This said it was a good idea ;o)
>
>
> Jacques
>
> From: "Pierre Smits" <pi...@gmail.com>
>
>> If you don't have an internet connection, you wouldn't be able to download
>> OFBiz.
>>
>> Op 11 april 2012 22:44 schreef Jacques Le Roux <
>> jacques.le.roux@les7arts.com
>>
>>> het volgende:
>>>
>>
>>  The problem with this approach: it does not work if you don't have an
>>> Internet connection: blocking
>>>
>>> -1
>>>
>>> Jacques
>>>
>>> From: "Pierre Smits" <pi...@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.cappellato@hotwaxmedia.****com <jacopo.cappellato@**
>>>> hotwaxmedia.com <ja...@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/**<https://cwiki.apache.org/**confluence/display/OFBADMIN/**>
>>>>> Libraries+Included+in+OFBiz<ht**tps://cwiki.apache.org/**
>>>>> confluence/display/OFBADMIN/**Libraries+Included+in+OFBiz<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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>

Re: Housekeeping of jar files

[Jacques Le Roux <jl...@les7arts.com>]

There are situations where you are able to download and then deploy where you don't have a connection. If then things change it can 
turn in a nightmare
Also there are situations where, etc... Think about it, not only your way...

It's ok for secondary libs, and most often used for those we can't upload to ASF repo because they don't have the right license. 
Else it does not worth the trouble.

This said it was a good idea ;o)

Jacques

From: "Pierre Smits" <pi...@gmail.com>
> If you don't have an internet connection, you wouldn't be able to download
> OFBiz.
>
> Op 11 april 2012 22:44 schreef Jacques Le Roux <jacques.le.roux@les7arts.com
>> het volgende:
>
>> The problem with this approach: it does not work if you don't have an
>> Internet connection: blocking
>>
>> -1
>>
>> Jacques
>>
>> From: "Pierre Smits" <pi...@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.cappellato@hotwaxmedia.**com <ja...@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<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
>>>>
>>>>
>>>>
>>>
> 

Re: Housekeeping of jar files

[Pierre Smits <pi...@gmail.com>]

If you don't have an internet connection, you wouldn't be able to download
OFBiz.

Op 11 april 2012 22:44 schreef Jacques Le Roux <jacques.le.roux@les7arts.com
> het volgende:

> The problem with this approach: it does not work if you don't have an
> Internet connection: blocking
>
> -1
>
> Jacques
>
> From: "Pierre Smits" <pi...@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.cappellato@hotwaxmedia.**com <ja...@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<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
>>>
>>>
>>>
>>

Re: Housekeeping of jar files

[Jacques Le Roux <ja...@les7arts.com>]

The problem with this approach: it does not work if you don't have an Internet connection: blocking

-1

Jacques

From: "Pierre Smits" <pi...@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.cappellato@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
>>
>>
>

Re: Housekeeping of jar files

[Pierre Smits <pi...@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.cappellato@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
>
>