Jenkins build is back to normal : Zest(JavaEdition)-develop-java8-check #237

[Apache Jenkins Server]

See 

Re: org.apache.zest.io an org.apache.zest.functional

[Niclas Hedhman]

No feedback should be interpreted as either; "Yeah, that is all good,
nothing to add" or "Community has fallen asleep"

You know that I typically don't sleep... :-)  It is all good.

On Thu, Dec 8, 2016 at 9:47 PM, Paul Merlin  wrote:

> Paul Merlin a écrit :
> > Gang,
> >
> > I pushed a commit on the replace-io-by-stream branch that replace usage
> > of core/io with Java 8 Streams:
> > https://github.com/apache/zest-java/commit/
> eb4e31a97a92609feb2e7bb18d135de432d511db
> >
> > After this commit, core/io is completely unused across the whole SDK.
> >
> > The code is much simpler even if in some cases it's still quite
> > convoluted to map the underlying stores APIs to Streams.
> >
> > Please review and comment so I can move forward, address your comments
> > and merge into develop soon.
> >
> > Cheers
> >
> > /Paul
>
> Any feedback on this?
>
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: SPI or @Structure

[Niclas Hedhman]

That is why I have replace "Module" with the injection of the factories,
which I think is the appropriate pattern.

Otherwise, we should then say, why doesn't Module implement the TypeLookup
and EntityStore methods and "delegate all the nifty details to the
corresponding services/factories". I prefer consistency.

Cheers
Niclas


On Thu, Dec 8, 2016 at 10:35 PM, Paul Merlin  wrote:

> Niclas Hedhman a écrit :
> > Ok,
> > should we then stop having Module extends XyzFactory, and they are
> obtained
> > likewise? Just in case we in future want some other mechanism for the
> > XyzFactory types, and not depend on the entire Module.
> >
> > I think so, as it then becomes more symmetrical and it is not relevant
> that
> > ModuleInstance implements ValueBuilderFactory at the moment.
>
> This would mean that we won't anymore be able to:
>
>   module.newTransient(..)
>
> and that we would have to:
>
>   module.transientBuilderFactory().newTransient(..)
>
> These shortcuts are pretty convenient IMO.
>
> But, yes, ModuleInstance should delegate all the nifty details to the
> corresponding services/factories. Right now it contains way too much
> implementation details of each of these factories.
>
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: SPI or @Structure

[Paul Merlin]

Niclas Hedhman a écrit :
> Ok,
> should we then stop having Module extends XyzFactory, and they are obtained
> likewise? Just in case we in future want some other mechanism for the
> XyzFactory types, and not depend on the entire Module.
>
> I think so, as it then becomes more symmetrical and it is not relevant that
> ModuleInstance implements ValueBuilderFactory at the moment.

This would mean that we won't anymore be able to:

  module.newTransient(..)

and that we would have to:

  module.transientBuilderFactory().newTransient(..)

These shortcuts are pretty convenient IMO.

But, yes, ModuleInstance should delegate all the nifty details to the
corresponding services/factories. Right now it contains way too much
implementation details of each of these factories.

Re: SPI or @Structure

[Niclas Hedhman]

Ok,
should we then stop having Module extends XyzFactory, and they are obtained
likewise? Just in case we in future want some other mechanism for the
XyzFactory types, and not depend on the entire Module.

I think so, as it then becomes more symmetrical and it is not relevant that
ModuleInstance implements ValueBuilderFactory at the moment.


Niclas

On Thu, Dec 8, 2016 at 7:00 PM, Paul Merlin  wrote:

> Niclas Hedhman a écrit :
> > The org.apache.zest.spi.module.ModuleSpi contains access methods to a
> bunch
> > of useful SPI internals, such as EntityStore, TypeLookup and more.
> >
> > Should we not just kill this class and provide that via @Structure
> > injection, since that is what we do with factories (and ServiceFinder?)
> >
> > If not, shouldn't then everything be moved to the Module or ModuleSpi as
> > methods, instead of injectable types?
> >
> > WDYT?
>
> Everything in ModuleSpi but TypeLookup is a service and is already
> injectable using @Service. And in fact, TypeLookup is already accessible
> from Module.
>
> So, +1 from me to ditch ModuleSpi.
>
> I'm not sure about moving them all to Module or only providing them
> through @Service injection.I find it pretty convenient to be able to
> access these base services from a Module, without having a dozen of
> injections.
>
>
>


-- 
Niclas Hedhman, Software Developer
http://zest.apache.org - New Energy for Java

Re: SPI or @Structure

[Paul Merlin]

Niclas Hedhman a écrit :
> The org.apache.zest.spi.module.ModuleSpi contains access methods to a bunch
> of useful SPI internals, such as EntityStore, TypeLookup and more.
>
> Should we not just kill this class and provide that via @Structure
> injection, since that is what we do with factories (and ServiceFinder?)
>
> If not, shouldn't then everything be moved to the Module or ModuleSpi as
> methods, instead of injectable types?
>
> WDYT?

Everything in ModuleSpi but TypeLookup is a service and is already
injectable using @Service. And in fact, TypeLookup is already accessible
from Module.

So, +1 from me to ditch ModuleSpi.

I'm not sure about moving them all to Module or only providing them
through @Service injection.I find it pretty convenient to be able to
access these base services from a Module, without having a dozen of
injections.

Re: Gradle Build support

[Paul Merlin]

So, yes we should provide users a Gradle plugin to easily build a
Polygene library/extension/application.

About the changes I made to the SDK build. For now I just moved all
build logic to buildSrc so it's more manageable and easy to refactor.
>From a gigantic root build.gradle file we moved to gigantic plugins in
buildSrc. I added the minimal set of niceties so that build scripts
spread over the modules are concise. Eating our own dog food. I'll
refactor this slowly and progressively and at some point we'll be able
to extract a Gradle plugin to make things easy for users. It may be on
time for 3.0, it may not.

The main goal of such a Polygene Gradle plugin will mostly be about easy
dependencies declaration. We don't need much more than that I think, as
a first step at least.


Niclas Hedhman a écrit :
> Actually, more like;
>
> apply plugin: 'polygene' // also sets the repositories needed.
>> dependencies {
>> polygene.core()  // sets up compile, runtime, testCompile
>>
>> if possible...
>
>
> On Wed, Dec 7, 2016 at 6:58 PM, Niclas Hedhman  wrote:
>
>> I didn't really notice all the nice things that Paul has done in the build
>> system.
>>
>> I particularly like the
>>
>> compile zest.extension( 'entitystore-jdbm' )
>>
>> Would it be possible to create and distribute a "Polygene plugin", which
>> does this for downstream users?
>>
>>
>> apply plugin: 'polygene' // also sets the repositories needed.
>> dependencies {
>> compile polygene.core()  // maybe test-support should be added to 
>> testCompile
>> compile polygene.library.http()
>> compile polygene.extension.entitystore_jdbm()
>> }
>>
>> or similar, with a 'global' polygene.version defining the version for all
>> of the components.
>>
>> Just an idea...
>>
>>
>> Cheers
>> --
>> Niclas Hedhman, Software Developer
>> http://zest.apache.org - New Energy for Java
>>
>
>
>

Re: IntelliJ Ultimate Edition

[Toni Menzel]

For Apache committers, there is an automated process in place at
https://www.jetbrains.com/shop/eform/apache?product=ALL.
All you need is the @apache.org email address.

*Toni Menzel*


*www.rebaze.de  | www.rebaze.com
 | @rebazeio *

On Thu, Dec 8, 2016 at 5:16 AM, Niclas Hedhman  wrote:

> Gang,
>
> JetBrains used to, and probably still do, provide Ultimate Edition to
> Apache committers. I personally don't use that anymore, as the "full suite
> of apps" are now (to me) reasonably priced compared to a few years ago.
>
> I think opensou...@jetbrains.com should be used to request. State that it
> is for Apache Software Foundation, and the Apache Zest project with link to
> http://zest.apache.org
>
>
> Cheers
> --
> Niclas Hedhman, Software Developer
> http://zest.apache.org - New Energy for Java
>