Wildcards for CompositeMatcherEditor

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Wildcards for CompositeMatcherEditor

Fabian Zeindl
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

robeden
Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

Fabian Zeindl
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

hbrands
Administrator
I guess that was because for ease of use in the ANT build...

Also, the core impl package is a conglomeration that needs some cleanup...

But I think that's a task for a 2.0 version...

Holger

2016-09-06 12:25 GMT+02:00 Fabian Zeindl <[hidden email]>:
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

Fabian Zeindl
Would a transition to gradle be welcome?

Fabian

On 06.09.2016, at 12:39 , Holger Brands <[hidden email]> wrote:

I guess that was because for ease of use in the ANT build...

Also, the core impl package is a conglomeration that needs some cleanup...

But I think that's a task for a 2.0 version...

Holger

2016-09-06 12:25 GMT+02:00 Fabian Zeindl <[hidden email]>:
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

robeden
I'm personally fine with it. GL is pretty ancient in the way its build environment and source is laid out. I started working on a gradle transition but ran out of time and gumption.

I'd love to see the extensions separated from the core.

On Tue, Sep 6, 2016 at 5:44 AM Fabian Zeindl <[hidden email]> wrote:
Would a transition to gradle be welcome?

Fabian

On 06.09.2016, at 12:39 , Holger Brands <[hidden email]> wrote:

I guess that was because for ease of use in the ANT build...

Also, the core impl package is a conglomeration that needs some cleanup...

But I think that's a task for a 2.0 version...

Holger

2016-09-06 12:25 GMT+02:00 Fabian Zeindl <[hidden email]>:
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

Fabian Zeindl
I will work on that.

I can organise the sources and make everything compile and test,
but I'll probably need help for the maven and OSGI publishing, since I've never done that.

Also: What is BND for?


On 06.09.2016, at 21:12 , Rob Eden <[hidden email]> wrote:

I'm personally fine with it. GL is pretty ancient in the way its build environment and source is laid out. I started working on a gradle transition but ran out of time and gumption.

I'd love to see the extensions separated from the core.

On Tue, Sep 6, 2016 at 5:44 AM Fabian Zeindl <[hidden email]> wrote:
Would a transition to gradle be welcome?

Fabian

On 06.09.2016, at 12:39 , Holger Brands <[hidden email]> wrote:

I guess that was because for ease of use in the ANT build...

Also, the core impl package is a conglomeration that needs some cleanup...

But I think that's a task for a 2.0 version...

Holger

2016-09-06 12:25 GMT+02:00 Fabian Zeindl <[hidden email]>:
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian





Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

hbrands
Administrator
Hi,

I think first we should agree on something ;-)

I'm more a Maven guy while Rob prefers Gradle I think.
What do the other contributors think?

Also, the extensions are basically separated from the core, there is currently a build target for every extension I think.
Of course, the corresponding tests should be placed along their extensions.

I would find it overkill to build a separate jar for each extension. Maybe a core and an extension jar would suffice?
The sample apps I would like to move to a separate project like glazedlist-samples.
The Japex performance tests could perhaps be migrated to JMH benchmark, also in a separate project.
So, a lot of possible changes...

But first, I would like to concentrate on getting 1.10 out, then we can focus on 2.0, where a change of build system could happen...

Just my spontaneous thoughts...

Holger



2016-09-07 11:38 GMT+02:00 Fabian Zeindl <[hidden email]>:
I will work on that.

I can organise the sources and make everything compile and test,
but I'll probably need help for the maven and OSGI publishing, since I've never done that.

Also: What is BND for?


On 06.09.2016, at 21:12 , Rob Eden <[hidden email]> wrote:

I'm personally fine with it. GL is pretty ancient in the way its build environment and source is laid out. I started working on a gradle transition but ran out of time and gumption.

I'd love to see the extensions separated from the core.

On Tue, Sep 6, 2016 at 5:44 AM Fabian Zeindl <[hidden email]> wrote:
Would a transition to gradle be welcome?

Fabian

On 06.09.2016, at 12:39 , Holger Brands <[hidden email]> wrote:

I guess that was because for ease of use in the ANT build...

Also, the core impl package is a conglomeration that needs some cleanup...

But I think that's a task for a 2.0 version...

Holger

2016-09-06 12:25 GMT+02:00 Fabian Zeindl <[hidden email]>:
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian






Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

Fabian Zeindl
I used ant and switched to gradle after a while.

I'm in favour of Gradle because:

* For GL it requires almost no configuration
* IntelliJ IDEA can automatically sync Gradle config to IDEA modules
* it's trivial to define the ways JARs will be packaged (take classes from Subodule A, Subodule B etc.)
* Just released Gradle 3 can use Kotlin instead of Groovy, which means the build scripts will be completely type safe (https://gradle.org/blog/kotlin-meets-gradle/) (wouldn't use that yet though).


I would have organised the code like this:

./
./build.gradle defines the additional jars that one wants to create if not a jar for every module
./settings.gradle just a simple list of submodules

core/
core/src/main/java production source
core/src/main/resources production resources
core/src/test/java test source

extensions/

extensions/calculation/build.gradle (for defining library-dependencies, can be omitted)
extensions/calculation/src/main/java
extensions/calculation/src/main/test

extensions/hibernate/src/main/java
extensions/hibernate/src/main/test


I have started already for myself, because I want better IDEA integration: https://github.com/fab1an/glazedlists/tree/gradlebuild


Fabian



On 07.09.2016, at 12:46 , Holger Brands <[hidden email]> wrote:

Hi,

I think first we should agree on something ;-)

I'm more a Maven guy while Rob prefers Gradle I think.
What do the other contributors think?

Also, the extensions are basically separated from the core, there is currently a build target for every extension I think.
Of course, the corresponding tests should be placed along their extensions.

I would find it overkill to build a separate jar for each extension. Maybe a core and an extension jar would suffice?
The sample apps I would like to move to a separate project like glazedlist-samples.
The Japex performance tests could perhaps be migrated to JMH benchmark, also in a separate project.
So, a lot of possible changes...

But first, I would like to concentrate on getting 1.10 out, then we can focus on 2.0, where a change of build system could happen...

Just my spontaneous thoughts...

Holger



2016-09-07 11:38 GMT+02:00 Fabian Zeindl <[hidden email]>:
I will work on that.

I can organise the sources and make everything compile and test,
but I'll probably need help for the maven and OSGI publishing, since I've never done that.

Also: What is BND for?


On 06.09.2016, at 21:12 , Rob Eden <[hidden email]> wrote:

I'm personally fine with it. GL is pretty ancient in the way its build environment and source is laid out. I started working on a gradle transition but ran out of time and gumption.

I'd love to see the extensions separated from the core.

On Tue, Sep 6, 2016 at 5:44 AM Fabian Zeindl <[hidden email]> wrote:
Would a transition to gradle be welcome?

Fabian

On 06.09.2016, at 12:39 , Holger Brands <[hidden email]> wrote:

I guess that was because for ease of use in the ANT build...

Also, the core impl package is a conglomeration that needs some cleanup...

But I think that's a task for a 2.0 version...

Holger

2016-09-06 12:25 GMT+02:00 Fabian Zeindl <[hidden email]>:
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian







Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

robeden
Sorry, Holger. Didn't mean to speak for you. I was more talking to the breaking out of extensions and wasn't thinking abut gradle vs. maven.

Perhaps we should take this whole thread to the dev list?
On Wed, Sep 7, 2016 at 6:44 AM Fabian Zeindl <[hidden email]> wrote:
I used ant and switched to gradle after a while.

I'm in favour of Gradle because:

* For GL it requires almost no configuration
* IntelliJ IDEA can automatically sync Gradle config to IDEA modules
* it's trivial to define the ways JARs will be packaged (take classes from Subodule A, Subodule B etc.)
* Just released Gradle 3 can use Kotlin instead of Groovy, which means the build scripts will be completely type safe (https://gradle.org/blog/kotlin-meets-gradle/) (wouldn't use that yet though).


I would have organised the code like this:

./
./build.gradle defines the additional jars that one wants to create if not a jar for every module
./settings.gradle just a simple list of submodules

core/
core/src/main/java production source
core/src/main/resources production resources
core/src/test/java test source

extensions/

extensions/calculation/build.gradle (for defining library-dependencies, can be omitted)
extensions/calculation/src/main/java
extensions/calculation/src/main/test

extensions/hibernate/src/main/java
extensions/hibernate/src/main/test


I have started already for myself, because I want better IDEA integration: https://github.com/fab1an/glazedlists/tree/gradlebuild


Fabian



On 07.09.2016, at 12:46 , Holger Brands <[hidden email]> wrote:

Hi,

I think first we should agree on something ;-)

I'm more a Maven guy while Rob prefers Gradle I think.
What do the other contributors think?

Also, the extensions are basically separated from the core, there is currently a build target for every extension I think.
Of course, the corresponding tests should be placed along their extensions.

I would find it overkill to build a separate jar for each extension. Maybe a core and an extension jar would suffice?
The sample apps I would like to move to a separate project like glazedlist-samples.
The Japex performance tests could perhaps be migrated to JMH benchmark, also in a separate project.
So, a lot of possible changes...

But first, I would like to concentrate on getting 1.10 out, then we can focus on 2.0, where a change of build system could happen...

Just my spontaneous thoughts...

Holger



2016-09-07 11:38 GMT+02:00 Fabian Zeindl <[hidden email]>:
I will work on that.

I can organise the sources and make everything compile and test,
but I'll probably need help for the maven and OSGI publishing, since I've never done that.

Also: What is BND for?


On 06.09.2016, at 21:12 , Rob Eden <[hidden email]> wrote:

I'm personally fine with it. GL is pretty ancient in the way its build environment and source is laid out. I started working on a gradle transition but ran out of time and gumption.

I'd love to see the extensions separated from the core.

On Tue, Sep 6, 2016 at 5:44 AM Fabian Zeindl <[hidden email]> wrote:
Would a transition to gradle be welcome?

Fabian

On 06.09.2016, at 12:39 , Holger Brands <[hidden email]> wrote:

I guess that was because for ease of use in the ANT build...

Also, the core impl package is a conglomeration that needs some cleanup...

But I think that's a task for a 2.0 version...

Holger

2016-09-06 12:25 GMT+02:00 Fabian Zeindl <[hidden email]>:
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian







Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

Fabian Zeindl
Just wanted to note that I finished splitting up the tests and converting everything to gradle/submodules, if you want to check it out:


could also be merged into the main build-file: https://github.com/fab1an/glazedlists/blob/gradlebuild/build.gradle

* I added 3 jars that I couldn't find on maven directly to the repo (nachocalendar.jar, ktable.jar and http.jar for the issue browser)

* I upgraded the versions of SWT and japex to the latest version, because the older couldn't be found on maven.

* All tests pass. Check via ./gradlew test (or ./gradlew :extensions:swt:test for just SWT)

* I haven't added the bit creating a unified jar yet, will do that later, if this is going to get used.

Cheers!
Fabian

On 07.09.2016, at 14:21 , Rob Eden <[hidden email]> wrote:

Sorry, Holger. Didn't mean to speak for you. I was more talking to the breaking out of extensions and wasn't thinking abut gradle vs. maven.

Perhaps we should take this whole thread to the dev list?
On Wed, Sep 7, 2016 at 6:44 AM Fabian Zeindl <[hidden email]> wrote:
I used ant and switched to gradle after a while.

I'm in favour of Gradle because:

* For GL it requires almost no configuration
* IntelliJ IDEA can automatically sync Gradle config to IDEA modules
* it's trivial to define the ways JARs will be packaged (take classes from Subodule A, Subodule B etc.)
* Just released Gradle 3 can use Kotlin instead of Groovy, which means the build scripts will be completely type safe (https://gradle.org/blog/kotlin-meets-gradle/) (wouldn't use that yet though).


I would have organised the code like this:

./
./build.gradle defines the additional jars that one wants to create if not a jar for every module
./settings.gradle just a simple list of submodules

core/
core/src/main/java production source
core/src/main/resources production resources
core/src/test/java test source

extensions/

extensions/calculation/build.gradle (for defining library-dependencies, can be omitted)
extensions/calculation/src/main/java
extensions/calculation/src/main/test

extensions/hibernate/src/main/java
extensions/hibernate/src/main/test


I have started already for myself, because I want better IDEA integration: https://github.com/fab1an/glazedlists/tree/gradlebuild


Fabian



On 07.09.2016, at 12:46 , Holger Brands <[hidden email]> wrote:

Hi,

I think first we should agree on something ;-)

I'm more a Maven guy while Rob prefers Gradle I think.
What do the other contributors think?

Also, the extensions are basically separated from the core, there is currently a build target for every extension I think.
Of course, the corresponding tests should be placed along their extensions.

I would find it overkill to build a separate jar for each extension. Maybe a core and an extension jar would suffice?
The sample apps I would like to move to a separate project like glazedlist-samples.
The Japex performance tests could perhaps be migrated to JMH benchmark, also in a separate project.
So, a lot of possible changes...

But first, I would like to concentrate on getting 1.10 out, then we can focus on 2.0, where a change of build system could happen...

Just my spontaneous thoughts...

Holger



2016-09-07 11:38 GMT+02:00 Fabian Zeindl <[hidden email]>:
I will work on that.

I can organise the sources and make everything compile and test,
but I'll probably need help for the maven and OSGI publishing, since I've never done that.

Also: What is BND for?


On 06.09.2016, at 21:12 , Rob Eden <[hidden email]> wrote:

I'm personally fine with it. GL is pretty ancient in the way its build environment and source is laid out. I started working on a gradle transition but ran out of time and gumption.

I'd love to see the extensions separated from the core.

On Tue, Sep 6, 2016 at 5:44 AM Fabian Zeindl <[hidden email]> wrote:
Would a transition to gradle be welcome?

Fabian

On 06.09.2016, at 12:39 , Holger Brands <[hidden email]> wrote:

I guess that was because for ease of use in the ANT build...

Also, the core impl package is a conglomeration that needs some cleanup...

But I think that's a task for a 2.0 version...

Holger

2016-09-06 12:25 GMT+02:00 Fabian Zeindl <[hidden email]>:
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian








Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

robeden
Woah, nice work! Your gradle ninja skills clearly surpass my own.

On Wed, Sep 7, 2016 at 9:17 AM Fabian Zeindl <[hidden email]> wrote:
Just wanted to note that I finished splitting up the tests and converting everything to gradle/submodules, if you want to check it out:


could also be merged into the main build-file: https://github.com/fab1an/glazedlists/blob/gradlebuild/build.gradle

* I added 3 jars that I couldn't find on maven directly to the repo (nachocalendar.jar, ktable.jar and http.jar for the issue browser)

* I upgraded the versions of SWT and japex to the latest version, because the older couldn't be found on maven.

* All tests pass. Check via ./gradlew test (or ./gradlew :extensions:swt:test for just SWT)

* I haven't added the bit creating a unified jar yet, will do that later, if this is going to get used.

Cheers!
Fabian

On 07.09.2016, at 14:21 , Rob Eden <[hidden email]> wrote:

Sorry, Holger. Didn't mean to speak for you. I was more talking to the breaking out of extensions and wasn't thinking abut gradle vs. maven.

Perhaps we should take this whole thread to the dev list?
On Wed, Sep 7, 2016 at 6:44 AM Fabian Zeindl <[hidden email]> wrote:
I used ant and switched to gradle after a while.

I'm in favour of Gradle because:

* For GL it requires almost no configuration
* IntelliJ IDEA can automatically sync Gradle config to IDEA modules
* it's trivial to define the ways JARs will be packaged (take classes from Subodule A, Subodule B etc.)
* Just released Gradle 3 can use Kotlin instead of Groovy, which means the build scripts will be completely type safe (https://gradle.org/blog/kotlin-meets-gradle/) (wouldn't use that yet though).


I would have organised the code like this:

./
./build.gradle defines the additional jars that one wants to create if not a jar for every module
./settings.gradle just a simple list of submodules

core/
core/src/main/java production source
core/src/main/resources production resources
core/src/test/java test source

extensions/

extensions/calculation/build.gradle (for defining library-dependencies, can be omitted)
extensions/calculation/src/main/java
extensions/calculation/src/main/test

extensions/hibernate/src/main/java
extensions/hibernate/src/main/test


I have started already for myself, because I want better IDEA integration: https://github.com/fab1an/glazedlists/tree/gradlebuild


Fabian



On 07.09.2016, at 12:46 , Holger Brands <[hidden email]> wrote:

Hi,

I think first we should agree on something ;-)

I'm more a Maven guy while Rob prefers Gradle I think.
What do the other contributors think?

Also, the extensions are basically separated from the core, there is currently a build target for every extension I think.
Of course, the corresponding tests should be placed along their extensions.

I would find it overkill to build a separate jar for each extension. Maybe a core and an extension jar would suffice?
The sample apps I would like to move to a separate project like glazedlist-samples.
The Japex performance tests could perhaps be migrated to JMH benchmark, also in a separate project.
So, a lot of possible changes...

But first, I would like to concentrate on getting 1.10 out, then we can focus on 2.0, where a change of build system could happen...

Just my spontaneous thoughts...

Holger



2016-09-07 11:38 GMT+02:00 Fabian Zeindl <[hidden email]>:
I will work on that.

I can organise the sources and make everything compile and test,
but I'll probably need help for the maven and OSGI publishing, since I've never done that.

Also: What is BND for?


On 06.09.2016, at 21:12 , Rob Eden <[hidden email]> wrote:

I'm personally fine with it. GL is pretty ancient in the way its build environment and source is laid out. I started working on a gradle transition but ran out of time and gumption.

I'd love to see the extensions separated from the core.

On Tue, Sep 6, 2016 at 5:44 AM Fabian Zeindl <[hidden email]> wrote:
Would a transition to gradle be welcome?

Fabian

On 06.09.2016, at 12:39 , Holger Brands <[hidden email]> wrote:

I guess that was because for ease of use in the ANT build...

Also, the core impl package is a conglomeration that needs some cleanup...

But I think that's a task for a 2.0 version...

Holger

2016-09-06 12:25 GMT+02:00 Fabian Zeindl <[hidden email]>:
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian








Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

Fabian Zeindl
:) Thanks.

I just had a complicated multi-project build a couple of months ago and stepped into every trap that gradle has to offer…

This is only compile/test right now, from what I see in build.xml central parts are still missing:

* generation of unified jars like the demo.jar, issue browser and xmlbrowser
(though i'm not sure if all of that is needed, like a jar with the javadoc, or zip-file containing the sources)
* deploy to maven
* bnd/osgi
* m4 generation


On 07.09.2016, at 16:28 , Rob Eden <[hidden email]> wrote:

Woah, nice work! Your gradle ninja skills clearly surpass my own.

On Wed, Sep 7, 2016 at 9:17 AM Fabian Zeindl <[hidden email]> wrote:
Just wanted to note that I finished splitting up the tests and converting everything to gradle/submodules, if you want to check it out:


could also be merged into the main build-file: https://github.com/fab1an/glazedlists/blob/gradlebuild/build.gradle

* I added 3 jars that I couldn't find on maven directly to the repo (nachocalendar.jar, ktable.jar and http.jar for the issue browser)

* I upgraded the versions of SWT and japex to the latest version, because the older couldn't be found on maven.

* All tests pass. Check via ./gradlew test (or ./gradlew :extensions:swt:test for just SWT)

* I haven't added the bit creating a unified jar yet, will do that later, if this is going to get used.

Cheers!
Fabian

On 07.09.2016, at 14:21 , Rob Eden <[hidden email]> wrote:

Sorry, Holger. Didn't mean to speak for you. I was more talking to the breaking out of extensions and wasn't thinking abut gradle vs. maven.

Perhaps we should take this whole thread to the dev list?
On Wed, Sep 7, 2016 at 6:44 AM Fabian Zeindl <[hidden email]> wrote:
I used ant and switched to gradle after a while.

I'm in favour of Gradle because:

* For GL it requires almost no configuration
* IntelliJ IDEA can automatically sync Gradle config to IDEA modules
* it's trivial to define the ways JARs will be packaged (take classes from Subodule A, Subodule B etc.)
* Just released Gradle 3 can use Kotlin instead of Groovy, which means the build scripts will be completely type safe (https://gradle.org/blog/kotlin-meets-gradle/) (wouldn't use that yet though).


I would have organised the code like this:

./
./build.gradle defines the additional jars that one wants to create if not a jar for every module
./settings.gradle just a simple list of submodules

core/
core/src/main/java production source
core/src/main/resources production resources
core/src/test/java test source

extensions/

extensions/calculation/build.gradle (for defining library-dependencies, can be omitted)
extensions/calculation/src/main/java
extensions/calculation/src/main/test

extensions/hibernate/src/main/java
extensions/hibernate/src/main/test


I have started already for myself, because I want better IDEA integration: https://github.com/fab1an/glazedlists/tree/gradlebuild


Fabian



On 07.09.2016, at 12:46 , Holger Brands <[hidden email]> wrote:

Hi,

I think first we should agree on something ;-)

I'm more a Maven guy while Rob prefers Gradle I think.
What do the other contributors think?

Also, the extensions are basically separated from the core, there is currently a build target for every extension I think.
Of course, the corresponding tests should be placed along their extensions.

I would find it overkill to build a separate jar for each extension. Maybe a core and an extension jar would suffice?
The sample apps I would like to move to a separate project like glazedlist-samples.
The Japex performance tests could perhaps be migrated to JMH benchmark, also in a separate project.
So, a lot of possible changes...

But first, I would like to concentrate on getting 1.10 out, then we can focus on 2.0, where a change of build system could happen...

Just my spontaneous thoughts...

Holger



2016-09-07 11:38 GMT+02:00 Fabian Zeindl <[hidden email]>:
I will work on that.

I can organise the sources and make everything compile and test,
but I'll probably need help for the maven and OSGI publishing, since I've never done that.

Also: What is BND for?


On 06.09.2016, at 21:12 , Rob Eden <[hidden email]> wrote:

I'm personally fine with it. GL is pretty ancient in the way its build environment and source is laid out. I started working on a gradle transition but ran out of time and gumption.

I'd love to see the extensions separated from the core.

On Tue, Sep 6, 2016 at 5:44 AM Fabian Zeindl <[hidden email]> wrote:
Would a transition to gradle be welcome?

Fabian

On 06.09.2016, at 12:39 , Holger Brands <[hidden email]> wrote:

I guess that was because for ease of use in the ANT build...

Also, the core impl package is a conglomeration that needs some cleanup...

But I think that's a task for a 2.0 version...

Holger

2016-09-06 12:25 GMT+02:00 Fabian Zeindl <[hidden email]>:
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian









Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

hbrands
Administrator
In reply to this post by robeden
No problem, don't worry.
It was rather directed to Fabian.
I just wanted to avoid someone working on something that might not be accepted later on.

BTW, I'lll update JIRA this week to reflect what I'd like to finish for 1.10.

Holger

2016-09-07 14:21 GMT+02:00 Rob Eden <[hidden email]>:
Sorry, Holger. Didn't mean to speak for you. I was more talking to the breaking out of extensions and wasn't thinking abut gradle vs. maven.

Perhaps we should take this whole thread to the dev list?

On Wed, Sep 7, 2016 at 6:44 AM Fabian Zeindl <[hidden email]> wrote:
I used ant and switched to gradle after a while.

I'm in favour of Gradle because:

* For GL it requires almost no configuration
* IntelliJ IDEA can automatically sync Gradle config to IDEA modules
* it's trivial to define the ways JARs will be packaged (take classes from Subodule A, Subodule B etc.)
* Just released Gradle 3 can use Kotlin instead of Groovy, which means the build scripts will be completely type safe (https://gradle.org/blog/kotlin-meets-gradle/) (wouldn't use that yet though).


I would have organised the code like this:

./
./build.gradle defines the additional jars that one wants to create if not a jar for every module
./settings.gradle just a simple list of submodules

core/
core/src/main/java production source
core/src/main/resources production resources
core/src/test/java test source

extensions/

extensions/calculation/build.gradle (for defining library-dependencies, can be omitted)
extensions/calculation/src/main/java
extensions/calculation/src/main/test

extensions/hibernate/src/main/java
extensions/hibernate/src/main/test


I have started already for myself, because I want better IDEA integration: https://github.com/fab1an/glazedlists/tree/gradlebuild


Fabian



On 07.09.2016, at 12:46 , Holger Brands <[hidden email]> wrote:

Hi,

I think first we should agree on something ;-)

I'm more a Maven guy while Rob prefers Gradle I think.
What do the other contributors think?

Also, the extensions are basically separated from the core, there is currently a build target for every extension I think.
Of course, the corresponding tests should be placed along their extensions.

I would find it overkill to build a separate jar for each extension. Maybe a core and an extension jar would suffice?
The sample apps I would like to move to a separate project like glazedlist-samples.
The Japex performance tests could perhaps be migrated to JMH benchmark, also in a separate project.
So, a lot of possible changes...

But first, I would like to concentrate on getting 1.10 out, then we can focus on 2.0, where a change of build system could happen...

Just my spontaneous thoughts...

Holger



2016-09-07 11:38 GMT+02:00 Fabian Zeindl <[hidden email]>:
I will work on that.

I can organise the sources and make everything compile and test,
but I'll probably need help for the maven and OSGI publishing, since I've never done that.

Also: What is BND for?


On 06.09.2016, at 21:12 , Rob Eden <[hidden email]> wrote:

I'm personally fine with it. GL is pretty ancient in the way its build environment and source is laid out. I started working on a gradle transition but ran out of time and gumption.

I'd love to see the extensions separated from the core.

On Tue, Sep 6, 2016 at 5:44 AM Fabian Zeindl <[hidden email]> wrote:
Would a transition to gradle be welcome?

Fabian

On 06.09.2016, at 12:39 , Holger Brands <[hidden email]> wrote:

I guess that was because for ease of use in the ANT build...

Also, the core impl package is a conglomeration that needs some cleanup...

But I think that's a task for a 2.0 version...

Holger

2016-09-06 12:25 GMT+02:00 Fabian Zeindl <[hidden email]>:
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian








Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Wildcards for CompositeMatcherEditor

Fabian Zeindl
No problem, it only took me an hour and I half and I needed it anyway to be able to test stuff in core without importing everything.

I'll leave it for now. 

If requested I can implement things like custom jars and generated resources (timestamps, version from git-tag etc), 
because I have the gradle-experience and a lot of snippets to copy/paste.

But, since I don't want to reimplement the old build-system for the sake of it, I'll wait until you've decided what you need or want to do.

Fabian

On 07.09.2016, at 20:34 , Holger Brands <[hidden email]> wrote:

No problem, don't worry.
It was rather directed to Fabian.
I just wanted to avoid someone working on something that might not be accepted later on.

BTW, I'lll update JIRA this week to reflect what I'd like to finish for 1.10.

Holger

2016-09-07 14:21 GMT+02:00 Rob Eden <[hidden email]>:
Sorry, Holger. Didn't mean to speak for you. I was more talking to the breaking out of extensions and wasn't thinking abut gradle vs. maven.

Perhaps we should take this whole thread to the dev list?

On Wed, Sep 7, 2016 at 6:44 AM Fabian Zeindl <[hidden email]> wrote:
I used ant and switched to gradle after a while.

I'm in favour of Gradle because:

* For GL it requires almost no configuration
* IntelliJ IDEA can automatically sync Gradle config to IDEA modules
* it's trivial to define the ways JARs will be packaged (take classes from Subodule A, Subodule B etc.)
* Just released Gradle 3 can use Kotlin instead of Groovy, which means the build scripts will be completely type safe (https://gradle.org/blog/kotlin-meets-gradle/) (wouldn't use that yet though).


I would have organised the code like this:

./
./build.gradle defines the additional jars that one wants to create if not a jar for every module
./settings.gradle just a simple list of submodules

core/
core/src/main/java production source
core/src/main/resources production resources
core/src/test/java test source

extensions/

extensions/calculation/build.gradle (for defining library-dependencies, can be omitted)
extensions/calculation/src/main/java
extensions/calculation/src/main/test

extensions/hibernate/src/main/java
extensions/hibernate/src/main/test


I have started already for myself, because I want better IDEA integration: https://github.com/fab1an/glazedlists/tree/gradlebuild


Fabian



On 07.09.2016, at 12:46 , Holger Brands <[hidden email]> wrote:

Hi,

I think first we should agree on something ;-)

I'm more a Maven guy while Rob prefers Gradle I think.
What do the other contributors think?

Also, the extensions are basically separated from the core, there is currently a build target for every extension I think.
Of course, the corresponding tests should be placed along their extensions.

I would find it overkill to build a separate jar for each extension. Maybe a core and an extension jar would suffice?
The sample apps I would like to move to a separate project like glazedlist-samples.
The Japex performance tests could perhaps be migrated to JMH benchmark, also in a separate project.
So, a lot of possible changes...

But first, I would like to concentrate on getting 1.10 out, then we can focus on 2.0, where a change of build system could happen...

Just my spontaneous thoughts...

Holger



2016-09-07 11:38 GMT+02:00 Fabian Zeindl <[hidden email]>:
I will work on that.

I can organise the sources and make everything compile and test,
but I'll probably need help for the maven and OSGI publishing, since I've never done that.

Also: What is BND for?


On 06.09.2016, at 21:12 , Rob Eden <[hidden email]> wrote:

I'm personally fine with it. GL is pretty ancient in the way its build environment and source is laid out. I started working on a gradle transition but ran out of time and gumption.

I'd love to see the extensions separated from the core.

On Tue, Sep 6, 2016 at 5:44 AM Fabian Zeindl <[hidden email]> wrote:
Would a transition to gradle be welcome?

Fabian

On 06.09.2016, at 12:39 , Holger Brands <[hidden email]> wrote:

I guess that was because for ease of use in the ANT build...

Also, the core impl package is a conglomeration that needs some cleanup...

But I think that's a task for a 2.0 version...

Holger

2016-09-06 12:25 GMT+02:00 Fabian Zeindl <[hidden email]>:
I'll check that out.

Is there a reason all of the Tests for the different extensions are together in a directory?

I'm having a hard time sorting these into different modules in IDEA right now…


On 06.09.2016, at 00:39 , Rob Eden <[hidden email]> wrote:

Want to send along a pull request?
On Mon, Sep 5, 2016 at 8:21 AM Fabian Zeindl <[hidden email]> wrote:
Hi,

    is it possible to modify `CompositeMatcherEditor` to take

EventList<MatcherEditor<? super E>> matcherEditor

in the constructor?


Regards
Fabian









Loading...