Re: [VOTE] Release Aries Util 1.1.1
+1 Christian On 06.08.2015 13:57, dav...@apache.org wrote: Hi, I'm calling a vote on Aries Util 1.1.1 The following bugs were fixed: ARIES-958 - BundleManifest.fromBundle(IFile) fails to parse OSGI headers when bundle manifest contains Name header. ARIES-1005 - BundleHookBundleTracker throws Exception when close()-method is called twice ARIES-1024 - SingleServiceTracker fails to track services properly when using a filter Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1035 Please votePlease vote: +1 Approve the release -1 Do not approve the release (please explain why) This vote will be open for at least 72 hours. Best regards, David Bosschaert -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[VOTE] Release Aries Asynchronous OSGi Services 1.0.1
Hi all, I'm calling a vote on the first release of the Aries Asynchronous OSGi Services implementation. The release has number 1.0.1 as the previous vote was cancelled. This implements the OSGi Asynchronous Services specification (chapter 138) and the OSGi Promises specification (chapter 705) of the OSGi Enterprise R6 specifications, which were released yesterday [1] Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1034 For details on getting started see http://aries.apache.org/modules/async-svcs.html Please vote: +1 Approve the release -1 Do not approve the release (please explain why) This vote will be open for at least 72 hours. Best regards, David Bosschaert [1] http://www.osgi.org/Download/Release6
[VOTE] Release Aries Util 1.1.1
Hi, I'm calling a vote on Aries Util 1.1.1 The following bugs were fixed: ARIES-958 - BundleManifest.fromBundle(IFile) fails to parse OSGI headers when bundle manifest contains Name header. ARIES-1005 - BundleHookBundleTracker throws Exception when close()-method is called twice ARIES-1024 - SingleServiceTracker fails to track services properly when using a filter Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1035 Please votePlease vote: +1 Approve the release -1 Do not approve the release (please explain why) This vote will be open for at least 72 hours. Best regards, David Bosschaert
Re: [VOTE] Release Aries Asynchronous OSGi Services 1.0.1
+1 Christian On 06.08.2015 13:46, dav...@apache.org wrote: Hi all, I'm calling a vote on the first release of the Aries Asynchronous OSGi Services implementation. The release has number 1.0.1 as the previous vote was cancelled. This implements the OSGi Asynchronous Services specification (chapter 138) and the OSGi Promises specification (chapter 705) of the OSGi Enterprise R6 specifications, which were released yesterday [1] Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1034 For details on getting started see http://aries.apache.org/modules/async-svcs.html Please vote: +1 Approve the release -1 Do not approve the release (please explain why) This vote will be open for at least 72 hours. Best regards, David Bosschaert [1] http://www.osgi.org/Download/Release6 -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
Re: [VOTE] Release Aries Asynchronous OSGi Services 1.0.1
+1 Sergey On 06/08/15 13:35, Christian Schneider wrote: +1 Christian On 06.08.2015 13:46, dav...@apache.org wrote: Hi all, I'm calling a vote on the first release of the Aries Asynchronous OSGi Services implementation. The release has number 1.0.1 as the previous vote was cancelled. This implements the OSGi Asynchronous Services specification (chapter 138) and the OSGi Promises specification (chapter 705) of the OSGi Enterprise R6 specifications, which were released yesterday [1] Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1034 For details on getting started see http://aries.apache.org/modules/async-svcs.html Please vote: +1 Approve the release -1 Do not approve the release (please explain why) This vote will be open for at least 72 hours. Best regards, David Bosschaert [1] http://www.osgi.org/Download/Release6
Re: [VOTE] Transaction manager 1.3.0, transaction blueprint 1.1.0, jpa 2.1.0
+1 David On 6 August 2015 at 02:49, Christian Schneider ch...@die-schneider.net wrote: I've staged a release for vote at: https://repository.apache.org/content/repositories/orgapachearies-1033 In transaction manager there is just a bug fix. I removed the jta API from the bundle. So it has to be installed separately now. The advantage is that we do not have refreshs of bundles depending on jta anymore. For transaction blueprint and jpa the biggest change is that we now use the Coordinator service to manage the lifecycle of the EnityManager. So there is no need anymore for the preCall and postCall methods of EmSupplier which did this job before. I deprecated the methods and they only have empty methods as impl now (This is an incompatibility for people who used these methods directly). The big advantage is that non blueprint code can now define the lifecycle using a standard API that does not depend on Aries. For transaction blueprint we now also support the JTA 1.2 @Transactional annotation. Together with @PersistenceContext this now allows a purely standard annotation based configuration of jpa beans. So the user code does not need to depend on Aries. Additionally @Transaction(TxType.SUPPORTS) now starts a coordination even if there is no transaction. So this can be used to extend the lifecycle of the EntityManager to any code even outside the persistence layer without managing a coordination by hand. *Release Notes - Aries - Version transaction-manager-1.3.0* ** Bug * [ARIES-1364] - transaction.manager causes cascading refreshs in karaf 4 https://issues.apache.org/jira/browse/ARIES/fixforversion/12333144 *Release Notes - Aries - Version transaction-blueprint-1.1.0* ** Bug * [ARIES-1361] - EntityManager does not participate in transaction if transactional interceptor is called after jpa interceptor ** Dependency upgrade * [ARIES-1296] - Upgrade to transaction api 1.2 ** Improvement * [ARIES-1347] - Working example of @Transaction annotation ** New Feature * [ARIES-628] - Support JTA attributes by annotations * [ARIES-1362] - Support coordinations triggered by transaction markers https://issues.apache.org/jira/browse/ARIES/fixforversion/12333049 *Release Notes - Aries - Version jpa-2.1.0* ** Bug * [ARIES-736] - Aries does not take into account the concept of complete/incomplete Persistence Units * [ARIES-1349] - EmfProxy.close should close tracker instead of EMF * [ARIES-1351] - TCK tests not working ** Improvement * [ARIES-1343] - Also scan parent classes for jpa annotations * [ARIES-1344] - Support multiple EntityManager injections per class * [ARIES-1345] - Support jpa annotations on method and class * [ARIES-1346] - EntityManager should be reused for series of coordinated calls https://issues.apache.org/jira/browse/ARIES/fixforversion/12332801 Please review and vote: [ ] +1 Release the above artifacts [ ] -1 Do not Here is my +1 Cheers, Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
RE: [VOTE] Release Aries Util 1.1.1
+1Regards JB Original message From: dav...@apache.org Date: 06/08/2015 13:57 (GMT+01:00) To: dev@aries.apache.org Subject: [VOTE] Release Aries Util 1.1.1 Hi, I'm calling a vote on Aries Util 1.1.1 The following bugs were fixed: ARIES-958 - BundleManifest.fromBundle(IFile) fails to parse OSGI headers when bundle manifest contains Name header. ARIES-1005 - BundleHookBundleTracker throws Exception when close()-method is called twice ARIES-1024 - SingleServiceTracker fails to track services properly when using a filter Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1035 Please votePlease vote: +1 Approve the release -1 Do not approve the release (please explain why) This vote will be open for at least 72 hours. Best regards, David Bosschaert
RE: [VOTE] Release Aries Asynchronous OSGi Services 1.0.1
+1Regards JB Original message From: dav...@apache.org Date: 06/08/2015 13:46 (GMT+01:00) To: dev@aries.apache.org Subject: [VOTE] Release Aries Asynchronous OSGi Services 1.0.1 Hi all, I'm calling a vote on the first release of the Aries Asynchronous OSGi Services implementation. The release has number 1.0.1 as the previous vote was cancelled. This implements the OSGi Asynchronous Services specification (chapter 138) and the OSGi Promises specification (chapter 705) of the OSGi Enterprise R6 specifications, which were released yesterday [1] Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1034 For details on getting started see http://aries.apache.org/modules/async-svcs.html Please vote: +1 Approve the release -1 Do not approve the release (please explain why) This vote will be open for at least 72 hours. Best regards, David Bosschaert [1] http://www.osgi.org/Download/Release6
RE: [VOTE] Transaction manager 1.3.0, transaction blueprint 1.1.0, jpa 2.1.0
+1Regards JB Original message From: Christian Schneider ch...@die-schneider.net Date: 06/08/2015 09:49 (GMT+01:00) To: dev@aries.apache.org Subject: [VOTE] Transaction manager 1.3.0, transaction blueprint 1.1.0, jpa 2.1.0 I've staged a release for vote at: https://repository.apache.org/content/repositories/orgapachearies-1033 In transaction manager there is just a bug fix. I removed the jta API from the bundle. So it has to be installed separately now. The advantage is that we do not have refreshs of bundles depending on jta anymore. For transaction blueprint and jpa the biggest change is that we now use the Coordinator service to manage the lifecycle of the EnityManager. So there is no need anymore for the preCall and postCall methods of EmSupplier which did this job before. I deprecated the methods and they only have empty methods as impl now (This is an incompatibility for people who used these methods directly). The big advantage is that non blueprint code can now define the lifecycle using a standard API that does not depend on Aries. For transaction blueprint we now also support the JTA 1.2 @Transactional annotation. Together with @PersistenceContext this now allows a purely standard annotation based configuration of jpa beans. So the user code does not need to depend on Aries. Additionally @Transaction(TxType.SUPPORTS) now starts a coordination even if there is no transaction. So this can be used to extend the lifecycle of the EntityManager to any code even outside the persistence layer without managing a coordination by hand. *Release Notes - Aries - Version transaction-manager-1.3.0* ** Bug * [ARIES-1364] - transaction.manager causes cascading refreshs in karaf 4 https://issues.apache.org/jira/browse/ARIES/fixforversion/12333144 *Release Notes - Aries - Version transaction-blueprint-1.1.0* ** Bug * [ARIES-1361] - EntityManager does not participate in transaction if transactional interceptor is called after jpa interceptor ** Dependency upgrade * [ARIES-1296] - Upgrade to transaction api 1.2 ** Improvement * [ARIES-1347] - Working example of @Transaction annotation ** New Feature * [ARIES-628] - Support JTA attributes by annotations * [ARIES-1362] - Support coordinations triggered by transaction markers https://issues.apache.org/jira/browse/ARIES/fixforversion/12333049 *Release Notes - Aries - Version jpa-2.1.0* ** Bug * [ARIES-736] - Aries does not take into account the concept of complete/incomplete Persistence Units * [ARIES-1349] - EmfProxy.close should close tracker instead of EMF * [ARIES-1351] - TCK tests not working ** Improvement * [ARIES-1343] - Also scan parent classes for jpa annotations * [ARIES-1344] - Support multiple EntityManager injections per class * [ARIES-1345] - Support jpa annotations on method and class * [ARIES-1346] - EntityManager should be reused for series of coordinated calls https://issues.apache.org/jira/browse/ARIES/fixforversion/12332801 Please review and vote: [ ] +1 Release the above artifacts [ ] -1 Do not Here is my +1 Cheers, Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[jira] [Created] (ARIES-1368) BundleResource is not able to compute capabilities for fragments
Wouter Bancken created ARIES-1368: - Summary: BundleResource is not able to compute capabilities for fragments Key: ARIES-1368 URL: https://issues.apache.org/jira/browse/ARIES-1368 Project: Aries Issue Type: Bug Components: Subsystem Affects Versions: subsystem-core-1.2.0 Reporter: Wouter Bancken The computeOsgiIdentityCapability method of the BundleResource is not able to compute capabilities for fragments (only for bundles). This is caused by the fact that the BundleResource is hardcoded to always assume a type of osgi.bundle without inspecting the manifest. Link to mailinglist thread: http://mail-archives.apache.org/mod_mbox/aries-user/201508.mbox/%3CCAL5nZgTOVhdAPYYFOmuV%3DPquAz1a4n_D1Rd3RBrTfu2znCSjKA%40mail.gmail.com%3E -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: [VOTE] Release Aries Util 1.1.1
Here's my +1 David On 6 August 2015 at 06:57, dav...@apache.org wrote: Hi, I'm calling a vote on Aries Util 1.1.1 The following bugs were fixed: ARIES-958 - BundleManifest.fromBundle(IFile) fails to parse OSGI headers when bundle manifest contains Name header. ARIES-1005 - BundleHookBundleTracker throws Exception when close()-method is called twice ARIES-1024 - SingleServiceTracker fails to track services properly when using a filter Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1035 Please votePlease vote: +1 Approve the release -1 Do not approve the release (please explain why) This vote will be open for at least 72 hours. Best regards, David Bosschaert
Re: [VOTE] Release Aries Asynchronous OSGi Services 1.0.1
Here's my +1 David On 6 August 2015 at 06:46, dav...@apache.org wrote: Hi all, I'm calling a vote on the first release of the Aries Asynchronous OSGi Services implementation. The release has number 1.0.1 as the previous vote was cancelled. This implements the OSGi Asynchronous Services specification (chapter 138) and the OSGi Promises specification (chapter 705) of the OSGi Enterprise R6 specifications, which were released yesterday [1] Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1034 For details on getting started see http://aries.apache.org/modules/async-svcs.html Please vote: +1 Approve the release -1 Do not approve the release (please explain why) This vote will be open for at least 72 hours. Best regards, David Bosschaert [1] http://www.osgi.org/Download/Release6
Re: [VOTE] Release Aries Util 1.1.1
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
Re: [VOTE] Release Aries Asynchronous OSGi Services 1.0.1
+1 -- Carsten Ziegeler Adobe Research Switzerland cziege...@apache.org
[VOTE] Transaction manager 1.3.0, transaction blueprint 1.1.0, jpa 2.1.0
I've staged a release for vote at: https://repository.apache.org/content/repositories/orgapachearies-1033 In transaction manager there is just a bug fix. I removed the jta API from the bundle. So it has to be installed separately now. The advantage is that we do not have refreshs of bundles depending on jta anymore. For transaction blueprint and jpa the biggest change is that we now use the Coordinator service to manage the lifecycle of the EnityManager. So there is no need anymore for the preCall and postCall methods of EmSupplier which did this job before. I deprecated the methods and they only have empty methods as impl now (This is an incompatibility for people who used these methods directly). The big advantage is that non blueprint code can now define the lifecycle using a standard API that does not depend on Aries. For transaction blueprint we now also support the JTA 1.2 @Transactional annotation. Together with @PersistenceContext this now allows a purely standard annotation based configuration of jpa beans. So the user code does not need to depend on Aries. Additionally @Transaction(TxType.SUPPORTS) now starts a coordination even if there is no transaction. So this can be used to extend the lifecycle of the EntityManager to any code even outside the persistence layer without managing a coordination by hand. *Release Notes - Aries - Version transaction-manager-1.3.0* ** Bug * [ARIES-1364] - transaction.manager causes cascading refreshs in karaf 4 https://issues.apache.org/jira/browse/ARIES/fixforversion/12333144 *Release Notes - Aries - Version transaction-blueprint-1.1.0* ** Bug * [ARIES-1361] - EntityManager does not participate in transaction if transactional interceptor is called after jpa interceptor ** Dependency upgrade * [ARIES-1296] - Upgrade to transaction api 1.2 ** Improvement * [ARIES-1347] - Working example of @Transaction annotation ** New Feature * [ARIES-628] - Support JTA attributes by annotations * [ARIES-1362] - Support coordinations triggered by transaction markers https://issues.apache.org/jira/browse/ARIES/fixforversion/12333049 *Release Notes - Aries - Version jpa-2.1.0* ** Bug * [ARIES-736] - Aries does not take into account the concept of complete/incomplete Persistence Units * [ARIES-1349] - EmfProxy.close should close tracker instead of EMF * [ARIES-1351] - TCK tests not working ** Improvement * [ARIES-1343] - Also scan parent classes for jpa annotations * [ARIES-1344] - Support multiple EntityManager injections per class * [ARIES-1345] - Support jpa annotations on method and class * [ARIES-1346] - EntityManager should be reused for series of coordinated calls https://issues.apache.org/jira/browse/ARIES/fixforversion/12332801 Please review and vote: [ ] +1 Release the above artifacts [ ] -1 Do not Here is my +1 Cheers, Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com
[jira] [Created] (ARIES-1367) eba-maven-plugin writes wrong version in manifest file
Eli Aidam created ARIES-1367: Summary: eba-maven-plugin writes wrong version in manifest file Key: ARIES-1367 URL: https://issues.apache.org/jira/browse/ARIES-1367 Project: Aries Issue Type: Bug Reporter: Eli Aidam Using eba-maven-plugin 1.0.0. If the application version has 2 leading zeros as part of the 4th tuple, 1 leading zero is removed when writing it to the application.mf file. For example: if application version is 3.1.1.008028, then the eba plugin writes 3.1.1.08028 in the Application-Content: section of the manifest file. It looks like the code Analyzer.cleanupVersion(artifact.getVersion()) is the one removing the leading zero. I see that https://issues.apache.org/jira/browse/ARIES-1103 is reporting a similar issue with the esa-maven-plugin. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
