Pierre, All,
There are 3 aspects here:
1. Repositories, you can do almost what you want, the ASF does not care if you
put jar, exe, dll, youNameIt... there (kidding with dll ;))
2. Source releases (required by ASF and must not contain external jar)
3. Binaries releases (required by ASF and can contain external jar, this is what you call
"convenience downloads projects make available" There are
usually provided by a 3rd party and can be hosted on ASF servers. But are
not, in any ways, official ASF releases.
At least we should all use the same vocabulary (I used the one ASF uses), if we
want to understand each other. What is the problem?
Thanks
Jacques
Le 11/07/2016 à 10:55, Pierre Smits a écrit :
Hi Taher,
It seems you did not read the entire posting.
The ASF doesn't object from having external libraries (3rd party jar files)
in the convenience downloads projects make available. This is what OFBiz
does also.
If there is a problem within the release process, regarding the external
libraries, then there are more ways around that than to fix something that
is not broken.
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Mon, Jul 11, 2016 at 10:51 AM, Taher Alkhateeb <
slidingfilame...@gmail.com> wrote:
Hi Pierre,
It seems you did not read the entire sentence, so I will write here again
from the JIRA you mentioned.
From Jacques: "There is no problems having an external jar (and even more)
in the repo. The pb is only when we release"
This is exactly what Sharan is saying above. You can keep Jars in branches,
"Releases" are where you are not supposed to keep binaries.
HTH
Taher Alkhateeb
On Mon, Jul 11, 2016 at 11:48 AM, Pierre Smits <pierre.sm...@gmail.com>
wrote:
Jacques posted this recently in a JIRA issue:
https://issues.apache.org/jira/browse/OFBIZ-7768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15369886#comment-15369886
Stating that there is no issue with having 3rd party libraries (jar
files)
in the repo.
Also the ASF does not object to have 3rd party libraries in the
convenience
downloads that the project makes available.
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
On Mon, Jul 11, 2016 at 10:33 AM, Sharan Foga <sharan.f...@gmail.com>
wrote:
Hi Pierre
Thanks for starting the discussion. I had expected to start it this
week,
giving us time to continue stabilising and consolidating the gradle
work
in
the trunk from last week. (Also a minor correction – I 'suggested' not
'promised').
Anyway my suggestion was to take the discussion to this list to talk
about
the next steps. So just as a recap from the user mailing list, my
summary
of the discussion there included the following points that are relevant
to
the 14.12 and 15.12 unreleased branches.
1) - We would not backport any of the gradle changes into the 14.12. or
15.12
branches because it would cause instability
2) - We would leave 14.12 and 15.12 as unreleased branches as they are
now
(and not
make them into releases as to do that we would need to remove all the
jar
files
and this would create instability).
3) - The benefits for our community are that developers and service
providers will
still have access to the complete codebase for 14.12 and 15.12
including
the
special purpose components to be able to support their client base.
My understanding was that the community did reach a consensus on these
points. No-one responded to correct, update nor oppose any of these
points.
Both of your questions are answered by the second point. So based on
this
the responses to your questions are:
- No, we are not going to delete the external libraries from the
unreleased branches 14.12 and 15.12 (if they remain as unreleased
branches
the there is no need to remove the external jars)
- No, we are not going to delete the entire unreleased branches 14.12
and
15.12 (we are leaving these available so that our community will still
have
access to the complete codebase including the special purpose
components)
In fact the main discussion that I wanted to start here was more
related
to support for 14.12 and 15.12. As we are in transition to gradle, we
need
to define a time period for backporting bug fixes into these unreleased
branches.
As an initial suggestion – would 12 months be a good timeframe to work
with. What do other people think?
Thanks
Sharan
On 2016-07-10 10:48 (+0200), Pierre Smits <pierre.sm...@gmail.com>
wrote:
Hi all,
Sharan promised the greater community in the '[*[DISCUSSION]*
*Anticipate*
the *end* of *life* of the *13.07* branch and backport some non-bug
related changes to the 14.12 and 15.12 branches
<http://markmail.org/message/nqo5xacngpspytvf>' starting via
http://ofbiz.markmail.org/message/nqo5xacngpspytvf ) that the
discussion
would continue in the dev ml.
As I haven't seen her start that discussion, I will:
Given that Sharan made clear that external libraries as per ASF
guidelines
and rulings, we need to decide what to do with the r14.x and the
r15.x
branches, as these hold all the external libraries required to build,
test
and/or run a copy from that branch in a separate environment.
So the questions are:
- are we going to delete the external libraries from the branches,
or
- are we going to delete the entire branches?
I believe we should have this addressed in order to provide the
greater
community with a clear answer as what to expect regarding future
adoptions
and/or upgrades.
Best regards,
Pierre Smits
ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services
OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/
