[jira] [Assigned] (DELTASPIKE-1036) Repositories should support java.util.Optional as return type

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reassigned DELTASPIKE-1036:
-

Assignee: John D. Ament  (was: Thomas Hug)

> Repositories should support java.util.Optional as return type
> -
>
> Key: DELTASPIKE-1036
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1036
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Reporter: Xavier Dury
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.6.2
>
>
> I don't know what is deltaspike's strategy regarding support of java 8 
> features but it would be nice if repositories could use Optional as return 
> type.
> When using @Query, there would be no need to specify singleResult = OPTIONAL.
> It would be nice if deltaspike could gradually support java 8 features a bit 
> like how spring does (if java.util.Optional is present on the classpath, then 
> it can be used in various places, otherwise features relying on it are not 
> usable).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1036) Repositories should support java.util.Optional as return type

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1036:
--
Fix Version/s: 1.6.2

> Repositories should support java.util.Optional as return type
> -
>
> Key: DELTASPIKE-1036
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1036
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Reporter: Xavier Dury
>Assignee: John D. Ament
>Priority: Minor
> Fix For: 1.6.2
>
>
> I don't know what is deltaspike's strategy regarding support of java 8 
> features but it would be nice if repositories could use Optional as return 
> type.
> When using @Query, there would be no need to specify singleResult = OPTIONAL.
> It would be nice if deltaspike could gradually support java 8 features a bit 
> like how spring does (if java.util.Optional is present on the classpath, then 
> it can be used in various places, otherwise features relying on it are not 
> usable).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1164) [perf] QueryBuilder can be ApplicationScoped

[Thomas Andraschko (JIRA)]

Thomas Andraschko created DELTASPIKE-1164:
-

 Summary: [perf] QueryBuilder can be ApplicationScoped
 Key: DELTASPIKE-1164
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1164
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: Thomas Andraschko
Assignee: Thomas Andraschko
 Fix For: 1.6.2


Improves the execution time of 100.000 repository#save calls up to further 
10-20%



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1163) [perf] avoid duplicate RepositoryComponent lookup

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko closed DELTASPIKE-1163.
-
Resolution: Duplicate

duplicate...

> [perf] avoid duplicate RepositoryComponent lookup
> -
>
> Key: DELTASPIKE-1163
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1163
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 1.6.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1163) [perf] avoid duplicate RepositoryComponent lookup

[Thomas Andraschko (JIRA)]

Thomas Andraschko created DELTASPIKE-1163:
-

 Summary: [perf] avoid duplicate RepositoryComponent lookup
 Key: DELTASPIKE-1163
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1163
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: Thomas Andraschko
Assignee: Thomas Andraschko
 Fix For: 1.6.2






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1162) [perf] avoid duplicate RepositoryComponent lookup

[Thomas Andraschko (JIRA)]

Thomas Andraschko created DELTASPIKE-1162:
-

 Summary: [perf] avoid duplicate RepositoryComponent lookup
 Key: DELTASPIKE-1162
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1162
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: Thomas Andraschko
Assignee: Thomas Andraschko
 Fix For: 1.6.2






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1161) [perf] avoid Instance#Select

[Romain Manni-Bucau (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312936#comment-15312936
 ] 

Romain Manni-Bucau commented on DELTASPIKE-1161:


[~tandraschko] not so sure about the context but select can be cached (the new 
Instance until it gets unambiguous) and @Inject can be used with @Dependent 
relying on Provider. It will require runtime resolution and instantiation but 
we can ensure we do it cleverly I guess.

> [perf] avoid Instance#Select
> 
>
> Key: DELTASPIKE-1161
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1161
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 1.6.2
>
>
> average execution time of 100.000 save calls
> - Instance#select: 46119ms
> - BeanProvider: 42231ms
> - @Inject: 37771ms
> @Inject will break dependent-scoped but there is currently not real-world 
> usecase 
> We could however introduce a config in the future



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1161) [perf] avoid Instance#Select

[Thomas Andraschko (JIRA)]

Thomas Andraschko created DELTASPIKE-1161:
-

 Summary: [perf] avoid Instance#Select
 Key: DELTASPIKE-1161
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1161
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Data-Module
Reporter: Thomas Andraschko
Assignee: Thomas Andraschko
 Fix For: 1.6.2


average execution time of 100.000 save calls
- Instance#select: 46119ms
- BeanProvider: 42231ms
- @Inject: 37771ms


@Inject will break dependent-scoped but there is currently not real-world 
usecase 
We could however introduce a config in the future



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1088) Provide a BOM for deltaspike with no transitive dependencies

[JIRA]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312321#comment-15312321
 ] 

Jörg Sesterhenn commented on DELTASPIKE-1088:
-

Thanks!

> Provide a BOM for deltaspike with no transitive dependencies
> 
>
> Key: DELTASPIKE-1088
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1088
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.5.4
>Reporter: Jörg Sesterhenn
>Assignee: John D. Ament
> Fix For: 1.6.2
>
>
> We have an enterprise parent POM that defines versions of maven artifacts for 
> all products that are built in our enterprise.
> We want to define the version of all deltaspike artifacts in that parent pom. 
> Idealy we would just import your BOM.
> Currently your BOM inherits a bloat of dependencies from the deltaspike 
> parent POM. We don't want all of these transitive dependencymanagement 
> entries in our parent POM. 
> So instead of importing your BOM we copy the entries for all deltaspike 
> modules into our parent POM. This is a violation of DRY / cumbersome / error 
> prone...
> Please provide a BOM that does not inherit any other dependencymanagement.
> One example of a great BOM is [the log4j 
> BOM|http://central.maven.org/maven2/org/apache/logging/log4j/log4j-bom/2.5/log4j-bom-2.5.pom].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1160) Not possible to select non Entity or other Entity object via Native query

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1160:
--
Assignee: Daniel Heinrich

> Not possible to select non Entity or other Entity object via Native query
> -
>
> Key: DELTASPIKE-1160
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1160
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 0.6, 0.7, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.2.0, 
> 1.2.1, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.6.0, 
> 1.6.1
>Reporter: Daniel Heinrich
>Assignee: Daniel Heinrich
>Priority: Minor
> Fix For: 1.6.2
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> [DELTASPIKE-1089|https://issues.apache.org/jira/browse/DELTASPIKE-1089] 
> enabled to return none mapped types from a native query from a Repository.
> This was done with an extra flag on the Query annotation.
> The default for native Queries in Repositories is to return the entity type 
> fo the repository.
> It should be possible to return other entity types from queries of the same 
> repository.
> e.g.
> {code:java}
> interface FooRepository extends EntityRepository
> {
>   @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON 
> Foo.bar_fk = Bar.pk WHERE Foo.pk = ?1")
>   Bar getBarFromFooByPk(long fooPk);
>   @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON 
> Foo.bar_fk = Bar.pk WHERE Foo.age = ?1")
>   List getBarFromFooWithAge(int age);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1160) Not possible to select non Entity or other Entity object via Native query

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1160:
--
Fix Version/s: 1.6.2

> Not possible to select non Entity or other Entity object via Native query
> -
>
> Key: DELTASPIKE-1160
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1160
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 0.6, 0.7, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.2.0, 
> 1.2.1, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.6.0, 
> 1.6.1
>Reporter: Daniel Heinrich
>Priority: Minor
> Fix For: 1.6.2
>
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> [DELTASPIKE-1089|https://issues.apache.org/jira/browse/DELTASPIKE-1089] 
> enabled to return none mapped types from a native query from a Repository.
> This was done with an extra flag on the Query annotation.
> The default for native Queries in Repositories is to return the entity type 
> fo the repository.
> It should be possible to return other entity types from queries of the same 
> repository.
> e.g.
> {code:java}
> interface FooRepository extends EntityRepository
> {
>   @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON 
> Foo.bar_fk = Bar.pk WHERE Foo.pk = ?1")
>   Bar getBarFromFooByPk(long fooPk);
>   @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON 
> Foo.bar_fk = Bar.pk WHERE Foo.age = ?1")
>   List getBarFromFooWithAge(int age);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] deltaspike pull request #52: [DELTASPIKE-1160] Enable other Entity types as ...

[Danny02]

Github user Danny02 commented on a diff in the pull request:

https://github.com/apache/deltaspike/pull/52#discussion_r65539505
  
--- Diff: 
deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/AnnotatedQueryBuilder.java
 ---
@@ -88,4 +83,12 @@ else if (query.isNative())
 return context.applyRestrictions(result);
 }
 
+private Class getMethodResultEntityClass(Method m){
--- End diff --

done


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (DELTASPIKE-1160) Not possible to select non Entity or other Entity object via Native query

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312305#comment-15312305
 ] 

ASF GitHub Bot commented on DELTASPIKE-1160:


Github user Danny02 commented on a diff in the pull request:

https://github.com/apache/deltaspike/pull/52#discussion_r65539505
  
--- Diff: 
deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/AnnotatedQueryBuilder.java
 ---
@@ -88,4 +83,12 @@ else if (query.isNative())
 return context.applyRestrictions(result);
 }
 
+private Class getMethodResultEntityClass(Method m){
--- End diff --

done


> Not possible to select non Entity or other Entity object via Native query
> -
>
> Key: DELTASPIKE-1160
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1160
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 0.6, 0.7, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.2.0, 
> 1.2.1, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.6.0, 
> 1.6.1
>Reporter: Daniel Heinrich
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> [DELTASPIKE-1089|https://issues.apache.org/jira/browse/DELTASPIKE-1089] 
> enabled to return none mapped types from a native query from a Repository.
> This was done with an extra flag on the Query annotation.
> The default for native Queries in Repositories is to return the entity type 
> fo the repository.
> It should be possible to return other entity types from queries of the same 
> repository.
> e.g.
> {code:java}
> interface FooRepository extends EntityRepository
> {
>   @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON 
> Foo.bar_fk = Bar.pk WHERE Foo.pk = ?1")
>   Bar getBarFromFooByPk(long fooPk);
>   @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON 
> Foo.bar_fk = Bar.pk WHERE Foo.age = ?1")
>   List getBarFromFooWithAge(int age);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1160) Not possible to select non Entity or other Entity object via Native query

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312294#comment-15312294
 ] 

ASF GitHub Bot commented on DELTASPIKE-1160:


Github user johnament commented on a diff in the pull request:

https://github.com/apache/deltaspike/pull/52#discussion_r65538667
  
--- Diff: 
deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/AnnotatedQueryBuilder.java
 ---
@@ -88,4 +83,12 @@ else if (query.isNative())
 return context.applyRestrictions(result);
 }
 
+private Class getMethodResultEntityClass(Method m){
--- End diff --

Either is fine, your commit message doesn't include a JIRA ticket.


> Not possible to select non Entity or other Entity object via Native query
> -
>
> Key: DELTASPIKE-1160
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1160
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 0.6, 0.7, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.2.0, 
> 1.2.1, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.6.0, 
> 1.6.1
>Reporter: Daniel Heinrich
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> [DELTASPIKE-1089|https://issues.apache.org/jira/browse/DELTASPIKE-1089] 
> enabled to return none mapped types from a native query from a Repository.
> This was done with an extra flag on the Query annotation.
> The default for native Queries in Repositories is to return the entity type 
> fo the repository.
> It should be possible to return other entity types from queries of the same 
> repository.
> e.g.
> {code:java}
> interface FooRepository extends EntityRepository
> {
>   @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON 
> Foo.bar_fk = Bar.pk WHERE Foo.pk = ?1")
>   Bar getBarFromFooByPk(long fooPk);
>   @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON 
> Foo.bar_fk = Bar.pk WHERE Foo.age = ?1")
>   List getBarFromFooWithAge(int age);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] deltaspike pull request #52: [DELTASPIKE-1160] Enable other Entity types as ...

[johnament]

Github user johnament commented on a diff in the pull request:

https://github.com/apache/deltaspike/pull/52#discussion_r65538667
  
--- Diff: 
deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/AnnotatedQueryBuilder.java
 ---
@@ -88,4 +83,12 @@ else if (query.isNative())
 return context.applyRestrictions(result);
 }
 
+private Class getMethodResultEntityClass(Method m){
--- End diff --

Either is fine, your commit message doesn't include a JIRA ticket.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] deltaspike pull request #52: [DELTASPIKE-1160] Enable other Entity types as ...

[Danny02]

Github user Danny02 commented on a diff in the pull request:

https://github.com/apache/deltaspike/pull/52#discussion_r65525461
  
--- Diff: 
deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/AnnotatedQueryBuilder.java
 ---
@@ -88,4 +83,12 @@ else if (query.isNative())
 return context.applyRestrictions(result);
 }
 
+private Class getMethodResultEntityClass(Method m){
--- End diff --


[QueryBuilder](https://github.com/apache/deltaspike/blob/master/deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/QueryBuilder.java#L64)
 also only checks for java.util.List


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (DELTASPIKE-1160) Not possible to select non Entity or other Entity object via Native query

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312172#comment-15312172
 ] 

ASF GitHub Bot commented on DELTASPIKE-1160:


Github user Danny02 commented on a diff in the pull request:

https://github.com/apache/deltaspike/pull/52#discussion_r65524755
  
--- Diff: 
deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/AnnotatedQueryBuilder.java
 ---
@@ -88,4 +83,12 @@ else if (query.isNative())
 return context.applyRestrictions(result);
 }
 
+private Class getMethodResultEntityClass(Method m){
--- End diff --

sry, but which original ticket do you mean? 
[DELTASPIKE-1089](https://issues.apache.org/jira/browse/DELTASPIKE-1089)?


> Not possible to select non Entity or other Entity object via Native query
> -
>
> Key: DELTASPIKE-1160
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1160
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 0.6, 0.7, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.2.0, 
> 1.2.1, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.6.0, 
> 1.6.1
>Reporter: Daniel Heinrich
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> [DELTASPIKE-1089|https://issues.apache.org/jira/browse/DELTASPIKE-1089] 
> enabled to return none mapped types from a native query from a Repository.
> This was done with an extra flag on the Query annotation.
> The default for native Queries in Repositories is to return the entity type 
> fo the repository.
> It should be possible to return other entity types from queries of the same 
> repository.
> e.g.
> {code:java}
> interface FooRepository extends EntityRepository
> {
>   @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON 
> Foo.bar_fk = Bar.pk WHERE Foo.pk = ?1")
>   Bar getBarFromFooByPk(long fooPk);
>   @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON 
> Foo.bar_fk = Bar.pk WHERE Foo.age = ?1")
>   List getBarFromFooWithAge(int age);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1111) Upgrade to Java 7

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament closed DELTASPIKE-.
-
Resolution: Won't Fix

> Upgrade to Java 7
> -
>
> Key: DELTASPIKE-
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Build, Core
>Affects Versions: 1.7.0
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> Upgrade the build to require min Java 7.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Reopened] (DELTASPIKE-1111) Upgrade to Java 7

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament reopened DELTASPIKE-:
---

> Upgrade to Java 7
> -
>
> Key: DELTASPIKE-
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Build, Core
>Affects Versions: 1.7.0
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> Upgrade the build to require min Java 7.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (DELTASPIKE-1160) Not possible to select non Entity or other Entity object via Native query

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312162#comment-15312162
 ] 

ASF GitHub Bot commented on DELTASPIKE-1160:


Github user johnament commented on a diff in the pull request:

https://github.com/apache/deltaspike/pull/52#discussion_r65524383
  
--- Diff: 
deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/AnnotatedQueryBuilder.java
 ---
@@ -88,4 +83,12 @@ else if (query.isNative())
 return context.applyRestrictions(result);
 }
 
+private Class getMethodResultEntityClass(Method m){
--- End diff --

HI Danny, good catch, thats what happens when I'm looking at this too late 
in the evening.

Can you please commit this all under the original ticket?  and can you 
expand this method to check for collection types?


> Not possible to select non Entity or other Entity object via Native query
> -
>
> Key: DELTASPIKE-1160
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1160
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 0.6, 0.7, 1.0.0, 1.0.1, 1.0.2, 1.0.3, 1.1.0, 1.2.0, 
> 1.2.1, 1.3.0, 1.4.0, 1.4.1, 1.4.2, 1.5.0, 1.5.1, 1.5.2, 1.5.3, 1.5.4, 1.6.0, 
> 1.6.1
>Reporter: Daniel Heinrich
>Priority: Minor
>   Original Estimate: 1h
>  Remaining Estimate: 1h
>
> [DELTASPIKE-1089|https://issues.apache.org/jira/browse/DELTASPIKE-1089] 
> enabled to return none mapped types from a native query from a Repository.
> This was done with an extra flag on the Query annotation.
> The default for native Queries in Repositories is to return the entity type 
> fo the repository.
> It should be possible to return other entity types from queries of the same 
> repository.
> e.g.
> {code:java}
> interface FooRepository extends EntityRepository
> {
>   @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON 
> Foo.bar_fk = Bar.pk WHERE Foo.pk = ?1")
>   Bar getBarFromFooByPk(long fooPk);
>   @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON 
> Foo.bar_fk = Bar.pk WHERE Foo.age = ?1")
>   List getBarFromFooWithAge(int age);
> }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] deltaspike pull request #52: [DELTASPIKE-1160] Enable other Entity types as ...

[johnament]

Github user johnament commented on a diff in the pull request:

https://github.com/apache/deltaspike/pull/52#discussion_r65524383
  
--- Diff: 
deltaspike/modules/data/impl/src/main/java/org/apache/deltaspike/data/impl/builder/AnnotatedQueryBuilder.java
 ---
@@ -88,4 +83,12 @@ else if (query.isNative())
 return context.applyRestrictions(result);
 }
 
+private Class getMethodResultEntityClass(Method m){
--- End diff --

HI Danny, good catch, thats what happens when I'm looking at this too late 
in the evening.

Can you please commit this all under the original ticket?  and can you 
expand this method to check for collection types?


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (DELTASPIKE-1155) tableName fallback to Metamodel only when not defined on @Table

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1155:
--
Component/s: Data-Module

> tableName fallback to Metamodel only when not defined on @Table
> ---
>
> Key: DELTASPIKE-1155
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1155
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
> Fix For: 1.6.2
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1158) It is not possible to override generic methods defined within delegates

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1158:
--
Component/s: Data-Module

> It is not possible to override generic methods defined within delegates
> ---
>
> Key: DELTASPIKE-1158
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1158
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.6.1
>Reporter: John D. Ament
>Assignee: John D. Ament
> Fix For: 1.6.2
>
>
> While looking at DELTASPIKE-1157, I found that its not actually possible to 
> define a custom findBy method directly in a repository.  It probably works if 
> you have a generic layer between your repositories and DeltaSpike, e.g.
> {code}
> public abstract class CustomRepo extends AbstractEntityRepository
> {code}
> The delegate method doesn't work properly due to bad match on the return 
> types.  Attached is a test case that proves it (ignore the query hints part)



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1089) No possible to select non Entity object via Native query

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1089:
--
Component/s: Data-Module

> No possible to select non Entity object via Native query
> 
>
> Key: DELTASPIKE-1089
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1089
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.5.4
>Reporter: VITALIY SAVCHENKO
>Assignee: John D. Ament
> Fix For: 1.6.2
>
>
> After DELTASPIKE-978 in repository no possible to select non Entity object 
> via Native query.
> For example(very simple):
> {code:java}
> @Query(
> isNative = true,
> value = "  SELECT  name  FROM actions ")
> @Override
> public abstract Collection listActions();
> {code}
> Reason:
> Changes in AnnotatedQueryBuilder.java
> -result = 
> params.applyTo(entityManager.createNativeQuery(jpqlQuery));
> +result = 
> params.applyTo(entityManager.createNativeQuery(jpqlQuery, 
> context.getEntityClass()));
> Now native query can return only Entity of this repository.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1160) Not possible to select non Entity or other Entity object via Native query

[Daniel Heinrich (JIRA)]

Daniel Heinrich created DELTASPIKE-1160:
---

 Summary: Not possible to select non Entity or other Entity object 
via Native query
 Key: DELTASPIKE-1160
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1160
 Project: DeltaSpike
  Issue Type: Bug
  Components: Data-Module
Affects Versions: 1.6.1, 1.6.0, 1.5.4, 1.5.3, 1.5.2, 1.5.1, 1.5.0, 1.4.2, 
1.4.1, 1.4.0, 1.3.0, 1.2.1, 1.2.0, 1.1.0, 1.0.3, 1.0.2, 1.0.1, 1.0.0, 0.7, 0.6
Reporter: Daniel Heinrich
Priority: Minor


[DELTASPIKE-1089|https://issues.apache.org/jira/browse/DELTASPIKE-1089] enabled 
to return none mapped types from a native query from a Repository.

This was done with an extra flag on the Query annotation.

The default for native Queries in Repositories is to return the entity type fo 
the repository.

It should be possible to return other entity types from queries of the same 
repository.

e.g.

{code:java}
interface FooRepository extends EntityRepository
{
  @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON Foo.bar_fk 
= Bar.pk WHERE Foo.pk = ?1")
  Bar getBarFromFooByPk(long fooPk);

  @Query(isNative = true,value = "SELECT  Bar.* FROM Foo JOIN Bar ON Foo.bar_fk 
= Bar.pk WHERE Foo.age = ?1")
  List getBarFromFooWithAge(int age);
}
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1104) Import Microscoped scopes into DeltaSpike

[John D. Ament (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1104?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

John D. Ament updated DELTASPIKE-1104:
--
Fix Version/s: (was: 1.7.0)

> Import Microscoped scopes into DeltaSpike
> -
>
> Key: DELTASPIKE-1104
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1104
> Project: DeltaSpike
>  Issue Type: New Feature
>  Components: Core, Servlet-Module, Timer-Module
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> Import the newly created microscoped scopes into DeltaSpike.
> Some high level mappings
> MethodScoped -> Core
> DomainScoped -> Servlet
> HeaderScoped -> Servlet
> TimerScoped -> New module?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] deltaspike pull request #52: Enable other Entity types as return from native...

[Danny02]

GitHub user Danny02 opened a pull request:

https://github.com/apache/deltaspike/pull/52

Enable other Entity types as return from native repository queries

At the moment native queries can only return the same entity type as of the 
repository.

A special flag exist on the @Query annotation to disable mapping, this 
enables the possibility to return unmapped types as String, Date or Integer.

This change uses the return type of the method with the @Query annotation. 
If the type is java.util.List, it uses the generic type.

It should be checked if this behaviour is correct for all JPA providers and 
if some special logging is needed.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Danny02/deltaspike 
native_query_generic_return_fix

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/deltaspike/pull/52.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #52


commit 69cbb4fba458d090124d4262c388fbc3df4a4a3f
Author: mmain\heda151 
Date:   2016-06-02T11:03:40Z

use return type of query method in native queries to build correct entity 
type




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (DELTASPIKE-1088) Provide a BOM for deltaspike with no transitive dependencies

[John D. Ament (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15312148#comment-15312148
 ] 

John D. Ament commented on DELTASPIKE-1088:
---

Created DELTASPIKE-1159 to address the dependency management section being 
missing.

> Provide a BOM for deltaspike with no transitive dependencies
> 
>
> Key: DELTASPIKE-1088
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1088
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Build
>Affects Versions: 1.5.4
>Reporter: Jörg Sesterhenn
>Assignee: John D. Ament
> Fix For: 1.6.2
>
>
> We have an enterprise parent POM that defines versions of maven artifacts for 
> all products that are built in our enterprise.
> We want to define the version of all deltaspike artifacts in that parent pom. 
> Idealy we would just import your BOM.
> Currently your BOM inherits a bloat of dependencies from the deltaspike 
> parent POM. We don't want all of these transitive dependencymanagement 
> entries in our parent POM. 
> So instead of importing your BOM we copy the entries for all deltaspike 
> modules into our parent POM. This is a violation of DRY / cumbersome / error 
> prone...
> Please provide a BOM that does not inherit any other dependencymanagement.
> One example of a great BOM is [the log4j 
> BOM|http://central.maven.org/maven2/org/apache/logging/log4j/log4j-bom/2.5/log4j-bom-2.5.pom].



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DELTASPIKE-1159) BOM Needs a dependency management section

[John D. Ament (JIRA)]

John D. Ament created DELTASPIKE-1159:
-

 Summary: BOM Needs a dependency management section
 Key: DELTASPIKE-1159
 URL: https://issues.apache.org/jira/browse/DELTASPIKE-1159
 Project: DeltaSpike
  Issue Type: Improvement
  Components: Build
Affects Versions: 1.6.1
Reporter: John D. Ament
Assignee: John D. Ament
 Fix For: 1.6.2


The BOM includes dependencies, but those should be in the dependency management 
section instead.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Why is log level overridden in cdi test runner?

[Gerhard Petracek]

@john:
please check if it's still an issue for you - see DELTASPIKE-1151

regards,
gerhard



2016-06-02 3:19 GMT+02:00 John D. Ament :

> Gerhard,
>
> I still don't quite see the issue with letting the log level dictate what
> gets shown.  Do you consider the log level to be a valid config option
> here, assuming we document how to override (e.g. with logging.properties)?
>
> John
>
> On Tue, Apr 26, 2016 at 6:53 AM Gerhard Petracek 
> wrote:
>
> > @john:
> >
> > we just force the level of one logger (used by us) to avoid that
> important
> > information (start/stop/failed messages) get skipped (due to a global
> > config).
> > e.g. some jpa-issues (esp. in combination with in-memory-dbs) can lead to
> > strange side-effects in @Before/@After logic (-> e.g. the >next< test
> > fails).
> > -> this information can help a lot!
> >
> > before this part was moved to ds, it was possible to disable those
> > log-entries. people did that ~frequently until they hit such an issue.
> > once they spent hours in analyzing random side-effects across
> test-methods,
> > they usually enabled it again (because they realized that it would have
> > taken way less time to analyze the issue).
> > some argued that they could enable it just on their ci-server or in case
> > there are issues, however, it turned out that people forget about it...
> > -> the config-option was dropped (esp. because 2 log-entries per
> > test-method isn't a big deal).
> > -> if we provide a config-option to disable such log-entries, you can do
> it
> > - but on your own risk (to miss essential information)...
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2016-04-25 12:49 GMT+02:00 John D. Ament :
> >
> > > Could you explain what you consider to be a config option and why the
> > > native logging API doesn't cover it?
> > >
> > > If someone wants an info message, they'll have it by default.  If they
> > want
> > > it off they can turn it off.
> > >
> > > The code right now forces you to see these info messages.
> > >
> > > John
> > >
> > > On Mon, Apr 25, 2016 at 5:18 AM Gerhard Petracek  >
> > > wrote:
> > >
> > > > @john:
> > > > -1 for disabling it per default (such information is essential if you
> > > have
> > > > to analyze e.g. random side-effects on ci-servers quickly)
> > > > +1 for adding a config-option (which allows to disable it locally)
> > > >
> > > > regards,
> > > > gerhard
> > > >
> > > >
> > > >
> > > > 2016-04-25 1:36 GMT+02:00 John D. Ament :
> > > >
> > > > > All,
> > > > >
> > > > > I was wondering, why is the log level overridden here?
> > > > >
> > > > >
> > > >
> > >
> >
> https://github.com/apache/deltaspike/blob/master/deltaspike/modules/test-control/api/src/main/java/org/apache/deltaspike/testcontrol/api/junit/CdiTestSuiteRunner.java#L155
> > > > >
> > > > > I'd like to disable it since most people prefer silent logging when
> > > > > nothings going on.
> > > > >
> > > > > John
> > > > >
> > > >
> > >
> >
>

Re: Next release -> 1.7?

[Thomas Andraschko]

As we added some new (minor) features, it's ok for me to change the version.

2016-06-02 10:30 GMT+02:00 Gerhard Petracek :

> @thomas:
> you are right - (given previous discussions) i thought john is going to
> change the jdk version as well...
> i'm not sure that the other changes require more than a patch release.
> (e.g. for users the client window handling wasn't changed significantly.)
>
> regards,
> gerhard
>
>
>
> 2016-06-02 10:10 GMT+02:00 Thomas Andraschko  >:
>
> > As far as i understand, we just set our DS version to 1.7 but Java
> remains
> > 1.6?
> >
> > 2016-06-02 10:07 GMT+02:00 Gerhard Petracek :
> >
> > > please check if you break our ci-jobs with that.
> > > there are still a lot using 1.6 to check the compatibility.
> > >
> > > regards,
> > > gerhard
> > >
> > >
> > >
> > > 2016-06-02 1:09 GMT+02:00 John D. Ament :
> > >
> > > > Hey guys, not a lot of input here, but unless I hear a -1 I'll make
> the
> > > pom
> > > > files 1.7 sometime on Friday.
> > > >
> > > > On Tue, May 24, 2016 at 2:42 PM Thomas Andraschko <
> > > > andraschko.tho...@gmail.com> wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Am Dienstag, 24. Mai 2016 schrieb Romain Manni-Bucau :
> > > > >
> > > > > > Ok makes sense then
> > > > > >
> > > > > >
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau  |  Blog
> > > > > >  | Github <
> > > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn  | Tomitriber
> > > > > >  | JavaEE Factory
> > > > > > 
> > > > > >
> > > > > > 2016-05-24 18:51 GMT+02:00 John D. Ament  > > > > > >:
> > > > > >
> > > > > > > Hi Romain,
> > > > > > >
> > > > > > > Basically it looks like client window behavior is much
> different
> > > than
> > > > > in
> > > > > > > the past releases.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > > > On Mon, May 23, 2016 at 2:43 AM Romain Manni-Bucau <
> > > > > > rmannibu...@gmail.com >
> > > > > > > wrote:
> > > > > > >
> > > > > > > > Hi John,
> > > > > > > >
> > > > > > > > what would be the highlights justifying it for you?
> > > > > > > >
> > > > > > > >
> > > > > > > > Romain Manni-Bucau
> > > > > > > > @rmannibucau  |  Blog
> > > > > > > >  | Github <
> > > > > > > > https://github.com/rmannibucau> |
> > > > > > > > LinkedIn  |
> > Tomitriber
> > > > > > > >  | JavaEE Factory
> > > > > > > > 
> > > > > > > >
> > > > > > > > 2016-05-23 4:16 GMT+02:00 John D. Ament <
> johndam...@apache.org
> > > > > > >:
> > > > > > > >
> > > > > > > > > All,
> > > > > > > > >
> > > > > > > > > I was wondering the thoughts about calling the next release
> > 1.7
> > > > > > instead
> > > > > > > > of
> > > > > > > > > 1.6.1?
> > > > > > > > > There's a pretty large set of changes in there, probably
> > bigger
> > > > > than
> > > > > > I
> > > > > > > > > would call a patch release.
> > > > > > > > >
> > > > > > > > > So, I'd propose that we call the next release 1.7.0 instead
> > of
> > > > > 1.6.2.
> > > > > > > > >
> > > > > > > > > John
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

[jira] [Updated] (DELTASPIKE-1070) Refactor RepositoryComponent/s

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko updated DELTASPIKE-1070:
--
Fix Version/s: (was: 1.7.0)

> Refactor RepositoryComponent/s
> --
>
> Key: DELTASPIKE-1070
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1070
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Data-Module
>Reporter: Thomas Andraschko
>Assignee: Thomas Andraschko
>
> Currently a RepositoryComponent is initialized during PAT. Therefore 
> RepositoryComponent requires a lazyInit.
> If we move the actual creation of the RepositoryComponent's to 
> AfterBeanDiscovery, we don't need such lazy init "hacks".
> IMO we should also split the RepositoryComponent into a data object and a 
> initializer as it currently feels very unstructured.
> Same applies for the RepositoryMethod and RepositoryEntity.
> We could also allign the naming a little bit:
> RepositoryComponents -> something MetadataStore or MetadataManager
> RepositoryComponent -> RepositoryMetadata
> RepositoryMethod -> RepositoryMethodMetadata
> RepositoryEntity -> EntityMetadata



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (DELTASPIKE-1111) Upgrade to Java 7

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko updated DELTASPIKE-:
--
Fix Version/s: (was: 1.7.0)

> Upgrade to Java 7
> -
>
> Key: DELTASPIKE-
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Build, Core
>Affects Versions: 1.7.0
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> Upgrade the build to require min Java 7.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (DELTASPIKE-1111) Upgrade to Java 7

[Thomas Andraschko (JIRA)]

 [ 
https://issues.apache.org/jira/browse/DELTASPIKE-?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Thomas Andraschko closed DELTASPIKE-.
-
Resolution: Fixed

As discussed, we will not upgrade the Java version until DS 2.0

> Upgrade to Java 7
> -
>
> Key: DELTASPIKE-
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-
> Project: DeltaSpike
>  Issue Type: Improvement
>  Components: Build, Core
>Affects Versions: 1.7.0
>Reporter: John D. Ament
>Assignee: John D. Ament
>
> Upgrade the build to require min Java 7.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: Next release -> 1.7?

[Gerhard Petracek]

@thomas:
you are right - (given previous discussions) i thought john is going to
change the jdk version as well...
i'm not sure that the other changes require more than a patch release.
(e.g. for users the client window handling wasn't changed significantly.)

regards,
gerhard



2016-06-02 10:10 GMT+02:00 Thomas Andraschko :

> As far as i understand, we just set our DS version to 1.7 but Java remains
> 1.6?
>
> 2016-06-02 10:07 GMT+02:00 Gerhard Petracek :
>
> > please check if you break our ci-jobs with that.
> > there are still a lot using 1.6 to check the compatibility.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2016-06-02 1:09 GMT+02:00 John D. Ament :
> >
> > > Hey guys, not a lot of input here, but unless I hear a -1 I'll make the
> > pom
> > > files 1.7 sometime on Friday.
> > >
> > > On Tue, May 24, 2016 at 2:42 PM Thomas Andraschko <
> > > andraschko.tho...@gmail.com> wrote:
> > >
> > > > +1
> > > >
> > > > Am Dienstag, 24. Mai 2016 schrieb Romain Manni-Bucau :
> > > >
> > > > > Ok makes sense then
> > > > >
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Tomitriber
> > > > >  | JavaEE Factory
> > > > > 
> > > > >
> > > > > 2016-05-24 18:51 GMT+02:00 John D. Ament  > > > > >:
> > > > >
> > > > > > Hi Romain,
> > > > > >
> > > > > > Basically it looks like client window behavior is much different
> > than
> > > > in
> > > > > > the past releases.
> > > > > >
> > > > > > John
> > > > > >
> > > > > > On Mon, May 23, 2016 at 2:43 AM Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi John,
> > > > > > >
> > > > > > > what would be the highlights justifying it for you?
> > > > > > >
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau  |  Blog
> > > > > > >  | Github <
> > > > > > > https://github.com/rmannibucau> |
> > > > > > > LinkedIn  |
> Tomitriber
> > > > > > >  | JavaEE Factory
> > > > > > > 
> > > > > > >
> > > > > > > 2016-05-23 4:16 GMT+02:00 John D. Ament  > > > > >:
> > > > > > >
> > > > > > > > All,
> > > > > > > >
> > > > > > > > I was wondering the thoughts about calling the next release
> 1.7
> > > > > instead
> > > > > > > of
> > > > > > > > 1.6.1?
> > > > > > > > There's a pretty large set of changes in there, probably
> bigger
> > > > than
> > > > > I
> > > > > > > > would call a patch release.
> > > > > > > >
> > > > > > > > So, I'd propose that we call the next release 1.7.0 instead
> of
> > > > 1.6.2.
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Next release -> 1.7?

[John D. Ament]

That's my understanding, we are not changing Java version until Ds 2.

Not sure what Gerhard means.
On Jun 2, 2016 04:10, "Thomas Andraschko" 
wrote:

> As far as i understand, we just set our DS version to 1.7 but Java remains
> 1.6?
>
> 2016-06-02 10:07 GMT+02:00 Gerhard Petracek :
>
> > please check if you break our ci-jobs with that.
> > there are still a lot using 1.6 to check the compatibility.
> >
> > regards,
> > gerhard
> >
> >
> >
> > 2016-06-02 1:09 GMT+02:00 John D. Ament :
> >
> > > Hey guys, not a lot of input here, but unless I hear a -1 I'll make the
> > pom
> > > files 1.7 sometime on Friday.
> > >
> > > On Tue, May 24, 2016 at 2:42 PM Thomas Andraschko <
> > > andraschko.tho...@gmail.com> wrote:
> > >
> > > > +1
> > > >
> > > > Am Dienstag, 24. Mai 2016 schrieb Romain Manni-Bucau :
> > > >
> > > > > Ok makes sense then
> > > > >
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Tomitriber
> > > > >  | JavaEE Factory
> > > > > 
> > > > >
> > > > > 2016-05-24 18:51 GMT+02:00 John D. Ament  > > > > >:
> > > > >
> > > > > > Hi Romain,
> > > > > >
> > > > > > Basically it looks like client window behavior is much different
> > than
> > > > in
> > > > > > the past releases.
> > > > > >
> > > > > > John
> > > > > >
> > > > > > On Mon, May 23, 2016 at 2:43 AM Romain Manni-Bucau <
> > > > > rmannibu...@gmail.com >
> > > > > > wrote:
> > > > > >
> > > > > > > Hi John,
> > > > > > >
> > > > > > > what would be the highlights justifying it for you?
> > > > > > >
> > > > > > >
> > > > > > > Romain Manni-Bucau
> > > > > > > @rmannibucau  |  Blog
> > > > > > >  | Github <
> > > > > > > https://github.com/rmannibucau> |
> > > > > > > LinkedIn  |
> Tomitriber
> > > > > > >  | JavaEE Factory
> > > > > > > 
> > > > > > >
> > > > > > > 2016-05-23 4:16 GMT+02:00 John D. Ament  > > > > >:
> > > > > > >
> > > > > > > > All,
> > > > > > > >
> > > > > > > > I was wondering the thoughts about calling the next release
> 1.7
> > > > > instead
> > > > > > > of
> > > > > > > > 1.6.1?
> > > > > > > > There's a pretty large set of changes in there, probably
> bigger
> > > > than
> > > > > I
> > > > > > > > would call a patch release.
> > > > > > > >
> > > > > > > > So, I'd propose that we call the next release 1.7.0 instead
> of
> > > > 1.6.2.
> > > > > > > >
> > > > > > > > John
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Next release -> 1.7?

[Thomas Andraschko]

As far as i understand, we just set our DS version to 1.7 but Java remains
1.6?

2016-06-02 10:07 GMT+02:00 Gerhard Petracek :

> please check if you break our ci-jobs with that.
> there are still a lot using 1.6 to check the compatibility.
>
> regards,
> gerhard
>
>
>
> 2016-06-02 1:09 GMT+02:00 John D. Ament :
>
> > Hey guys, not a lot of input here, but unless I hear a -1 I'll make the
> pom
> > files 1.7 sometime on Friday.
> >
> > On Tue, May 24, 2016 at 2:42 PM Thomas Andraschko <
> > andraschko.tho...@gmail.com> wrote:
> >
> > > +1
> > >
> > > Am Dienstag, 24. Mai 2016 schrieb Romain Manni-Bucau :
> > >
> > > > Ok makes sense then
> > > >
> > > >
> > > >
> > > > Romain Manni-Bucau
> > > > @rmannibucau  |  Blog
> > > >  | Github <
> > > > https://github.com/rmannibucau> |
> > > > LinkedIn  | Tomitriber
> > > >  | JavaEE Factory
> > > > 
> > > >
> > > > 2016-05-24 18:51 GMT+02:00 John D. Ament  > > > >:
> > > >
> > > > > Hi Romain,
> > > > >
> > > > > Basically it looks like client window behavior is much different
> than
> > > in
> > > > > the past releases.
> > > > >
> > > > > John
> > > > >
> > > > > On Mon, May 23, 2016 at 2:43 AM Romain Manni-Bucau <
> > > > rmannibu...@gmail.com >
> > > > > wrote:
> > > > >
> > > > > > Hi John,
> > > > > >
> > > > > > what would be the highlights justifying it for you?
> > > > > >
> > > > > >
> > > > > > Romain Manni-Bucau
> > > > > > @rmannibucau  |  Blog
> > > > > >  | Github <
> > > > > > https://github.com/rmannibucau> |
> > > > > > LinkedIn  | Tomitriber
> > > > > >  | JavaEE Factory
> > > > > > 
> > > > > >
> > > > > > 2016-05-23 4:16 GMT+02:00 John D. Ament  > > > >:
> > > > > >
> > > > > > > All,
> > > > > > >
> > > > > > > I was wondering the thoughts about calling the next release 1.7
> > > > instead
> > > > > > of
> > > > > > > 1.6.1?
> > > > > > > There's a pretty large set of changes in there, probably bigger
> > > than
> > > > I
> > > > > > > would call a patch release.
> > > > > > >
> > > > > > > So, I'd propose that we call the next release 1.7.0 instead of
> > > 1.6.2.
> > > > > > >
> > > > > > > John
> > > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: Next release -> 1.7?

[Gerhard Petracek]

please check if you break our ci-jobs with that.
there are still a lot using 1.6 to check the compatibility.

regards,
gerhard



2016-06-02 1:09 GMT+02:00 John D. Ament :

> Hey guys, not a lot of input here, but unless I hear a -1 I'll make the pom
> files 1.7 sometime on Friday.
>
> On Tue, May 24, 2016 at 2:42 PM Thomas Andraschko <
> andraschko.tho...@gmail.com> wrote:
>
> > +1
> >
> > Am Dienstag, 24. Mai 2016 schrieb Romain Manni-Bucau :
> >
> > > Ok makes sense then
> > >
> > >
> > >
> > > Romain Manni-Bucau
> > > @rmannibucau  |  Blog
> > >  | Github <
> > > https://github.com/rmannibucau> |
> > > LinkedIn  | Tomitriber
> > >  | JavaEE Factory
> > > 
> > >
> > > 2016-05-24 18:51 GMT+02:00 John D. Ament  > > >:
> > >
> > > > Hi Romain,
> > > >
> > > > Basically it looks like client window behavior is much different than
> > in
> > > > the past releases.
> > > >
> > > > John
> > > >
> > > > On Mon, May 23, 2016 at 2:43 AM Romain Manni-Bucau <
> > > rmannibu...@gmail.com >
> > > > wrote:
> > > >
> > > > > Hi John,
> > > > >
> > > > > what would be the highlights justifying it for you?
> > > > >
> > > > >
> > > > > Romain Manni-Bucau
> > > > > @rmannibucau  |  Blog
> > > > >  | Github <
> > > > > https://github.com/rmannibucau> |
> > > > > LinkedIn  | Tomitriber
> > > > >  | JavaEE Factory
> > > > > 
> > > > >
> > > > > 2016-05-23 4:16 GMT+02:00 John D. Ament  > > >:
> > > > >
> > > > > > All,
> > > > > >
> > > > > > I was wondering the thoughts about calling the next release 1.7
> > > instead
> > > > > of
> > > > > > 1.6.1?
> > > > > > There's a pretty large set of changes in there, probably bigger
> > than
> > > I
> > > > > > would call a patch release.
> > > > > >
> > > > > > So, I'd propose that we call the next release 1.7.0 instead of
> > 1.6.2.
> > > > > >
> > > > > > John
> > > > > >
> > > > >
> > > >
> > >
> >
>

[jira] [Commented] (DELTASPIKE-1098) CriteriaTest#should_create_count_criteria fails on OpenJPA / TomEE7

[Thomas Andraschko (JIRA)]

[ 
https://issues.apache.org/jira/browse/DELTASPIKE-1098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15311872#comment-15311872
 ] 

Thomas Andraschko commented on DELTASPIKE-1098:
---

Thanks John!

> CriteriaTest#should_create_count_criteria fails on OpenJPA / TomEE7
> ---
>
> Key: DELTASPIKE-1098
> URL: https://issues.apache.org/jira/browse/DELTASPIKE-1098
> Project: DeltaSpike
>  Issue Type: Bug
>  Components: Data-Module
>Affects Versions: 1.6.0
> Environment: data-impl: mvn clean package -P tomee7-build-managed -D 
> tomee.version=7.0.0-M3
>Reporter: Thomas Andraschko
>Assignee: Thomas Hug
>
> It fails currently only in OpenJPA TomEE7.
> [~thomashug]
> could you please have a look at it? maybe it's just a OpenJPA bug.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)