+1 (non binding)
Regards
JB
On 09/15/2014 06:02 PM, Guillaume Nodet wrote:
I've staged a number of bundles into
https://repository.apache.org/content/repositories/orgapachearies-1008
Bundles and fixes:
* blueprint-parser 1.3.0 : ARIES-1227
* blueprint-core 1.4.2 : ARIES-1215,
By the way, I think we have an issue in JNDI URL (I will take a look),
but no impact for this release.
Regards
JB
On 09/15/2014 06:02 PM, Guillaume Nodet wrote:
I've staged a number of bundles into
https://repository.apache.org/content/repositories/orgapachearies-1008
Bundles and fixes:
+1
David
On 15 September 2014 17:02, Guillaume Nodet gno...@apache.org wrote:
I've staged a number of bundles into
https://repository.apache.org/content/repositories/orgapachearies-1008
Bundles and fixes:
* blueprint-parser 1.3.0 : ARIES-1227
* blueprint-core 1.4.2 : ARIES-1215,
[
https://issues.apache.org/jira/browse/ARIES-1234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14135153#comment-14135153
]
Christian Schneider commented on ARIES-1234:
I also propose to first roll back
Hi all,
we have the issue https://issues.apache.org/jira/browse/ARIES-1234 in
aries jpa container.
The current release of jpa container fixes some quite critical bugs but
is now incompatible to aries jpa 2.0.
I propose we revert back to the code before the jpa 2.1 upgrade, then do
a new
Hi Christian,
I agree, and I would propose to align version with JPA versions.
Let say:
1/ Aries jpa 1.0.x is JPA 2.0
2/ Aries jpa 1.1.x is JPA 2.1
and use corresponding branches.
Like this, in Karaf, the features will align the Aries JPA version with
the JPA level expected by the
By the way, it's weird that JPA 2.1 is not backward compatible with JPA
2.0: the interfaces contains the same methods (plus some addition).
Do you have an use case to test ?
Regards
JB
On 09/16/2014 10:57 AM, Christian Schneider wrote:
Hi all,
we have the issue
Does the bundle export those packages in both versions? 2.0 and 2.1 or just
2.1.
In that case I'd make sure those packages which are valid for 2.0 and 2.1
are exported for both and only the new ones exported as 2.1. It's the same
workaround that I've needed to do for Pax Web Jetty bundle to export
AFAIR, I did the export for both 2.0 and 2.1.
Let me check.
Regards
JB
On 09/16/2014 01:12 PM, Achim Nierbeck wrote:
Does the bundle export those packages in both versions? 2.0 and 2.1 or just
2.1.
In that case I'd make sure those packages which are valid for 2.0 and 2.1
are exported for both
I am fine with you tackling this.
I think the reason why we have a problem here is that we implement the
interface. Adding methods is compatible as long as you use an interface.
If you implement it then it is the other way round.
Then e.g. removing a method is compatible. So in our case we
I agree Christian, good point.
As we import javax.persistence* but implement the interface, we should
provide one impl per version.
Regards
JB
On 09/16/2014 01:49 PM, Christian Schneider wrote:
I am fine with you tackling this.
I think the reason why we have a problem here is that we
We can't do that because we use semantic versioning.
So we can't reserve a version range.
2014-09-16 13:08 GMT+02:00 Jean-Baptiste Onofré j...@nanthrax.net:
Hi Christian,
I agree, and I would propose to align version with JPA versions.
Let say:
1/ Aries jpa 1.0.x is JPA 2.0
2/ Aries jpa
Good point.
On trunk, we have jpa20 module. Let me check if all groupId/artifactId
are OK there.
Regards
JB
On 09/16/2014 02:10 PM, Guillaume Nodet wrote:
We can't do that because we use semantic versioning.
So we can't reserve a version range.
2014-09-16 13:08 GMT+02:00 Jean-Baptiste
13 matches
Mail list logo
