Re: FW: [DISCUSSION] How to deal with runtime dependencies

[Stian Soiland-Reyes]

Both JDBC drivers and JPA implementations are pluggable by design.

With "huge effort" I guess you mean changing configuration files, setup and
deployment methods, rather than code changes?

If your code could still work using alternatives to Hibernate and MySQL
connector (e.g. Apache Derby and Apache OpenJPA) and you are not replying
on implementation-specific extensions, queries/stored procedures, then I
don't see a problem with using them in integration tests.

You should have a goal towards graduation to not have to rely on them by
default (e.g. switch to Derby and , but keeping the integration tests
("check it also works with Hibernate and MySQL) makes perfect sense.
Downstream consumers don't have to run (all) your integration tests.

It's OK if you don't get the most brilliant performance with the ASF
compatible libraries (that's outside your control!), as long as you don't
say "Apache Foo recommends configuring db as  MySQL and Hibernate for best
performance" - but rather document it like "Some users report improved
performance configuring db as MySQL and Hibernate"

One issue is with binary convenience distributions. If you are planning any
(or likely to do so), then you can't include Hibernate or MySQL (e.g. in
the archived lib/ folder) - at least not in binaries distributed from (or
promoted by) Apache.

Downstream consumers of AFS software also should not get licensing
surprises - so your runtime script can't simply do "Downloading Hibernate"
at first startup. Say a "Connect to database wizard" with MySQL as one of
the options (that then does download), should however be legit, as long as
ASF compatible options are available.


On 10 Feb 2016 08:56, "Markus Geiß"  wrote:

> Hey all,
>
> We've started a thread at our dev list and forgot to send it to the
> general incubator list too.
> Any opinion is appreciated, you can find the original message below.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
> > From: markus.ge...@live.de
> > To: d...@fineract.incubator.apache.org
> > Subject: [DISCUSSION] How to deal with runtime dependencies
> > Date: Mon, 8 Feb 2016 14:12:04 +0100
> >
> > Hey all,
> >
> > hope this finds you well.
> >
> > I thought instead of discussing this on top of pull request, because it
> is more
> > than just the JDBC driver, it is the right time to create a new thread.
> >
> > We are currently using MySQL's Connector/J and Hibernate's EntityManager
> at
> > runtime as the JDBC driver and JPA implementation. Our source code is not
> > depending on both.
> >
> > It would create a huge effort to replace both for test and production
> environments.
> >
> > The questions is:
> >
> > Would it be compliant with the license policies if we omit them for our
> source
> > release, but keeping them for our own integration tests.
> >
> > If somebody is creating a deployable distribution, the expectation is
> that whomever
> > is creating the distribution can decide what he wants to use.
> >
> > Best,
> >
> > Markus
> >
> > .::YAGNI likes a DRY KISS::.
>

Re: FW: [DISCUSSION] How to deal with runtime dependencies

[Jacques Nadeau]

I've used this as reference previously:

http://www.apache.org/legal/resolved.html#prohibited

Specifically this sentence:

"...For example, using a GPL'ed tool during the build is OK."

That would suggest that using GPL tools for build and test should be okay.

I'll let others address the distribution of optional components question in
great detail. My sense is this is primarily focused on how "optional" the
undistributable component is.

On Wed, Feb 10, 2016 at 12:56 AM, Markus Geiß  wrote:

> Hey all,
>
> We've started a thread at our dev list and forgot to send it to the
> general incubator list too.
> Any opinion is appreciated, you can find the original message below.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
> > From: markus.ge...@live.de
> > To: d...@fineract.incubator.apache.org
> > Subject: [DISCUSSION] How to deal with runtime dependencies
> > Date: Mon, 8 Feb 2016 14:12:04 +0100
> >
> > Hey all,
> >
> > hope this finds you well.
> >
> > I thought instead of discussing this on top of pull request, because it
> is more
> > than just the JDBC driver, it is the right time to create a new thread.
> >
> > We are currently using MySQL's Connector/J and Hibernate's EntityManager
> at
> > runtime as the JDBC driver and JPA implementation. Our source code is not
> > depending on both.
> >
> > It would create a huge effort to replace both for test and production
> environments.
> >
> > The questions is:
> >
> > Would it be compliant with the license policies if we omit them for our
> source
> > release, but keeping them for our own integration tests.
> >
> > If somebody is creating a deployable distribution, the expectation is
> that whomever
> > is creating the distribution can decide what he wants to use.
> >
> > Best,
> >
> > Markus
> >
> > .::YAGNI likes a DRY KISS::.
>

Re: FW: [DISCUSSION] How to deal with runtime dependencies

[Roman Shaposhnik]

On Wed, Feb 10, 2016 at 12:56 AM, Markus Geiß  wrote:
> Hey all,
>
> We've started a thread at our dev list and forgot to send it to the
> general incubator list too.
> Any opinion is appreciated, you can find the original message below.
>
> Best,
>
> Markus
>
> .::YAGNI likes a DRY KISS::.
>
>> From: markus.ge...@live.de
>> To: d...@fineract.incubator.apache.org
>> Subject: [DISCUSSION] How to deal with runtime dependencies
>> Date: Mon, 8 Feb 2016 14:12:04 +0100
>>
>> Hey all,
>>
>> hope this finds you well.
>>
>> I thought instead of discussing this on top of pull request, because it is 
>> more
>> than just the JDBC driver, it is the right time to create a new thread.
>>
>> We are currently using MySQL's Connector/J and Hibernate's EntityManager at
>> runtime as the JDBC driver and JPA implementation. Our source code is not
>> depending on both.
>>
>> It would create a huge effort to replace both for test and production 
>> environments.
>>
>> The questions is:
>>
>> Would it be compliant with the license policies if we omit them for our 
>> source
>> release, but keeping them for our own integration tests.
>>
>> If somebody is creating a deployable distribution, the expectation is that 
>> whomever
>> is creating the distribution can decide what he wants to use.

The devil is in the details. Can you show a branch with this solution to the
problem prototyped?

Thanks,
Roman.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org