Re: [VOTE] Apache Aries Proxy Impl 1.1.6 release
+1 Dan > On Sep 16, 2019, at 9:30 AM, Jean-Baptiste Onofré wrote: > > Hi everyone, > > I submit Aries Proxy Impl 1.1.6 release to your vote. > > We fixed one issue in this release: > > * [ARIES-1923] - aries-proxy fails when presented with Java 11 classes > with nested classes > > Here's the detailed Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310981=12345678 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachearies-1167 > > Git tag: > org.apache.aries.proxy-1.1.6 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: [VOTE] Apache Aries Proxy 1.1.5 release
+1 Dan > On Jun 17, 2019, at 4:56 PM, Dominik Przybysz wrote: > > +1 > > pon., 17 cze 2019 o 21:34 Jean-Baptiste Onofré napisał(a): > >> Hi guys, >> >> I submit Apache Aries Proxy 1.1.5 release to your vote. >> >> This proxy release updates to ASM 7.1 in order to support JDK 12. >> >> Release Notes: >> >> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310981=12344850 >> >> Staging Repository: >> https://repository.apache.org/content/repositories/orgapachearies-1164 >> >> Git Tag: >> org.apache.aries.proxy-1.1.5 >> >> Please vote to approve this release: >> >> [ ] +1 Approve the release >> [ ] -1 Don't approve the release (please provide specific comments) >> >> This vote will be open for at least 72 hours. >> >> Thanks ! >> >> Regards >> JB >> > > > -- > Pozdrawiam / Regards, > Dominik Przybysz -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: [VOTE] Apache Aries SPI Fly 1.2.2 release
+1 Dan > On Jun 18, 2019, at 9:13 AM, Jean-Baptiste Onofré wrote: > > Hi guys, > > I submit Apache Aries SPI Fly 1.2.2 release to your vote. > > This release updates to ASM 7.1 in order to support JDK 12. > > Release Notes: > https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310981=12345680 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachearies-1165 > > Git Tags: > org.apache.aries.spifly.core-internal-1.2.2 > org.apache.aries.spifly.weaver-internal-1.2.2 > org.apache.aries.spifly.dynamic.bundle-1.2.2 > org.apache.aries.spifly.dynamic.framework.extension-1.2.2 > org.apache.aries.spifly.static.bundle-1.2.2 > org.apache.aries.spifly.static.tool-1.2.2 > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks ! > > Regards > JB -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
[jira] [Commented] (ARIES-1848) jaxrs whiteboard jar contains SseEventSource.Builder but not the impl
[ https://issues.apache.org/jira/browse/ARIES-1848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16655444#comment-16655444 ] Daniel Kulp commented on ARIES-1848: whiteboard really should be split into two versions: 1) What we have today - fully self contained. Easy to install/use. 2) Version that properly uses CXF's packaging and JAX-RS runtime and features. Right now, installing whiteboard can completely break other CXF/JAX-RS applications running in a container. You have to completely move everything over to whiteboard or not use whiteboard. That's kind of a sucky option. (and part of the issue is with the JAX-RS spec itself keeping an implementation in a static in the spec api jar so two implementation cannot co-exist nicely together) > jaxrs whiteboard jar contains SseEventSource.Builder but not the impl > - > > Key: ARIES-1848 > URL: https://issues.apache.org/jira/browse/ARIES-1848 > Project: Aries > Issue Type: Bug >Reporter: Romain Manni-Bucau >Priority: Major > > org.apache.aries.jax.rs.whiteboard-1.0.1.jar!/META-INF/services/javax.ws.rs.sse.SseEventSource.Builder > shouldn't be part of aries jaxrs whiteboard packaging since the impl is not > provided and is optional for cxf -- This message was sent by Atlassian JIRA (v7.6.3#76005)
Re: [HEADS UP] Move current git repos to gitbox
Big +1 Dan > On Jul 27, 2018, at 8:18 AM, Christian Schneider > wrote: > > It seems that our git repos are still on git-wip. I would like to move them > to gitbox. > This allows us to directly work with the github UI like reviewing, merging > and closing PRs. > > The current repos we have are: > https://github.com/apache/aries-rsa > https://github.com/apache/aries-jpa > https://github.com/apache/aries-jax-rs-whiteboard > https://github.com/apache/aries-containers > > This is already on gitbox: > https://github.com/apache/aries-tx-control > > If no one objects during the next days I will ask infra to move the repos. > > Christian > > -- > -- > Christian Schneider > http://www.liquid-reality.de > > Computer Scientist > http://www.adobe.com -- Daniel Kulp dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog <http://dankulp.com/blog> Talend Community Coder - http://talend.com <http://coders.talend.com/>
Re: Aries Spec Jars
> On Dec 22, 2017, at 10:30 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > >> Do those spec bundles also exist over in SMX or Geronimo? Is there a >> “significant” number of major Apache projects that are currently using >> either the ones in Aries or the ones in ServiceMix/Geronimo? If so, then >> yea, we should remove them. Stop duplicating stuff and, instead, get >> issues fixed. >> > > I don't think this is feasible. > > The reason being that those projects are using those API jars coming from a > different perspective. > > Their perspective is: > > - Make the API usable in OSGi when there is no OSGi specification which > specifies it's use. I disagree..It’s just “Make the API usable in OSGi”, period. If there is a spec, great. If there isn’t still make it work. Almost as importantly: make it work in cases where the spec is available (new runtime) as well as not available (old runtimes). > From that perspective they are free to make implementation choices which is > totally fine for that case. However those choices are proprietary. … and, for the most part, hidden. >> >>> That’s fine as a proposal, but there are a *lot* of fixes needed in >> ServiceMix before the bundles are usable. None of the bundles offer (as far >> as I can tell) offer the correct contract capability (or even any contract >> at all), and they all seem to include a custom locator which isn’t part of >> the original specification jar. This locator will have unknown effects on >> specification implementations and may need to be removed. Are the >> ServiceMix team really going to be ok with changes that radical, >> particularly when they affect existing released artifacts? >> >> Removing the Locator stuff is likely not going to fly, adding additional >> bundle headers is likely OK. >> > > Here you've now made it impossible by first saying that all changes should > be made in servicemix BUT that you won't accept the changes in servicemix! I didn’t say that at all…. I said changes can be be made in ServiceMix, but keeping the locator (or some similar mechanism) to make sure the API’s continue to work correctly is important. If updating the FactoryFinders to use the locator if the “standard osgi mechanism” fails is necessary, that SHOULD be fine. > You're not leaving us with many options. > > The locator stuff is a proprietary detail that is not part of the OSGi > specification for how these APIs should be used. And is a completely hidden, private package and thus nearly irrelevant. > > CXF does NOT implement the upcoming OSGi JAX-RS specification which is what > we're talking about here. And therefore CXF can't be placed in the same > category with the Aries JAX-RS and Aries in general which is about > implementing specifications. > > Don't get me wrong, CXF and ServiceMix are fine projects. However they are > not implementing specifications. They are purely industry implementations > and those implementations have made design choices which are more or less > incompatible with the upcoming OSGi specification. CXF implements a ton of specs… a future OSGi JAX-RS spec may or may not become one of them.In particular, I can definitely see CXF registering the various builders and such as OSGi services. > I sincerely hope you re-consider your position and offer some real help > otherwise we're stuck not being able to deliver RIs for OSGi R7. I *AM* offering help…. I’m more than willing to do some work and apply patches or whatever in the ServiceMix specs to get it updated and usable. For now, as a test, I added the Provide-Capability stuff into the smx bundle, updated the maven-bundle-plugin to understand it, and updated all of the aries-jax-rs-whiteboard poms/bndrun files to use it instead of the local thing and all the tests pass. Thus, I’m back to “why add another one” and "why can it not work for the RI?" Dan > > - Ray > > >> >> Dan >> >> >> >> >>> >>> Regards, >>> >>> Tim >>> >>> On 21 Dec 2017, at 18:16, Daniel Kulp <dk...@apache.org<mailto:dkulp >> @apache.org>> wrote: >>> >>> >>> >>> On Dec 21, 2017, at 1:00 PM, Raymond Auge <raymond.a...@liferay.com< >> mailto:raymond.a...@liferay.com>> wrote: >>> >>> On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp <dk...@apache.org> dk...@apache.org>> wrote: >>> >>> Can I ask why the spec/api bundles that are provided by ServiceMix are >> not >>> usable? Could the ServiceMix api bundles be updated to make them >> usable? >>
Re: Aries Spec Jars
> On Dec 22, 2017, at 4:14 AM, Timothy Ward <timothyjw...@apache.org> wrote: > > I’m completely against having yet another bundle here when the other bundles > are the ones that will be be used by all the other projects. > > Well we already do have working spec bundles here at Aries (and have had for > quite some time), so is your proposal to remove them? Do those spec bundles also exist over in SMX or Geronimo? Is there a “significant” number of major Apache projects that are currently using either the ones in Aries or the ones in ServiceMix/Geronimo? If so, then yea, we should remove them. Stop duplicating stuff and, instead, get issues fixed. > That’s fine as a proposal, but there are a *lot* of fixes needed in > ServiceMix before the bundles are usable. None of the bundles offer (as far > as I can tell) offer the correct contract capability (or even any contract at > all), and they all seem to include a custom locator which isn’t part of the > original specification jar. This locator will have unknown effects on > specification implementations and may need to be removed. Are the ServiceMix > team really going to be ok with changes that radical, particularly when they > affect existing released artifacts? Removing the Locator stuff is likely not going to fly, adding additional bundle headers is likely OK. > As Ray points out the licensing also needs to be fixed before any of the > bundles can be used in an OSGi reference implementation (which affects at > least Aries JAX-RS, Aries CDI, Aries Transaction Control and Aries JPA). The > reference implementations also need to be ready for the R7 release in the > next month or so. My original suggestion was a simple movement of the > existing bundles, do we have a different solution that’s workable in that > time-frame? Let me be clear: I intent to vote -1 on any release that contains the api bundle as it currently stands in Aries, PARTICULARLY if there has been no attempt a all to fix any problems in the other locations. This particular situation is even worse… 95% (or more) of the testing of CXF/JAX-RS in OSGi is done using the ServiceMix spec bundles. I have little to no confidence in any other option at this point. Dan > > Regards, > > Tim > > On 21 Dec 2017, at 18:16, Daniel Kulp > <dk...@apache.org<mailto:dk...@apache.org>> wrote: > > > > On Dec 21, 2017, at 1:00 PM, Raymond Auge > <raymond.a...@liferay.com<mailto:raymond.a...@liferay.com>> wrote: > > On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp > <dk...@apache.org<mailto:dk...@apache.org>> wrote: > > Can I ask why the spec/api bundles that are provided by ServiceMix are not > usable? Could the ServiceMix api bundles be updated to make them usable? > > > Most of the ServiceMix jars violate the terms of the original license of > the specification artifacts they touch. They also violate the Apache > guidelines for repackaging such artifacts. > > I personally didn't have the stomach to repair the ones we needed in that > project so opted to fix them in Aries. > > If we could get them fixed then that might be a solution. > > > Submit a patch! I can get them applied there easily enough.I’m > completely against having yet another bundle here when the other bundles are > the ones that will be be used by all the other projects. > > Dan > > > > > > > - Ray > > > > I really would prefer not getting into a situation where we have a bunch > of project that are commonly used together starting to pull in multiple > versions or implementations of the same bundles. For example: CXF uses > and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle > which would obviously result in multiple bundles exporting the same > package/versions. > > Dan > > > > On Dec 21, 2017, at 9:28 AM, Raymond Auge > <raymond.a...@liferay.com<mailto:raymond.a...@liferay.com>> > wrote: > > Hi Tim, > > I was thinking of proposing this very thing over the last few weeks. > > I had already deliberately pushed the CDI related spec jars and also the > spec jar for JAX-RS into an aries sub-group in maven in order to better > accommodate and reflect this very thing. > > So, I would be a big +1 for having these in a specific sub-project. > > - Ray > > On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward > <timothyjw...@apache.org<mailto:timothyjw...@apache.org>> > wrote: > > Hi all, > > I’ve noticed that an increasing number of Aries projects are producing > wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this > is a > good thing, as few other Open So
Re: Aries Spec Jars
> On Dec 21, 2017, at 1:00 PM, Raymond Auge <raymond.a...@liferay.com> wrote: > > On Thu, Dec 21, 2017 at 12:43 PM, Daniel Kulp <dk...@apache.org> wrote: > >> Can I ask why the spec/api bundles that are provided by ServiceMix are not >> usable? Could the ServiceMix api bundles be updated to make them usable? >> > > Most of the ServiceMix jars violate the terms of the original license of > the specification artifacts they touch. They also violate the Apache > guidelines for repackaging such artifacts. > > I personally didn't have the stomach to repair the ones we needed in that > project so opted to fix them in Aries. > > If we could get them fixed then that might be a solution. Submit a patch! I can get them applied there easily enough.I’m completely against having yet another bundle here when the other bundles are the ones that will be be used by all the other projects. Dan > > - Ray > > >> >> I really would prefer not getting into a situation where we have a bunch >> of project that are commonly used together starting to pull in multiple >> versions or implementations of the same bundles. For example: CXF uses >> and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle >> which would obviously result in multiple bundles exporting the same >> package/versions. >> >> Dan >> >> >> >>> On Dec 21, 2017, at 9:28 AM, Raymond Auge <raymond.a...@liferay.com> >> wrote: >>> >>> Hi Tim, >>> >>> I was thinking of proposing this very thing over the last few weeks. >>> >>> I had already deliberately pushed the CDI related spec jars and also the >>> spec jar for JAX-RS into an aries sub-group in maven in order to better >>> accommodate and reflect this very thing. >>> >>> So, I would be a big +1 for having these in a specific sub-project. >>> >>> - Ray >>> >>> On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <timothyjw...@apache.org> >>> wrote: >>> >>>> Hi all, >>>> >>>> I’ve noticed that an increasing number of Aries projects are producing >>>> wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this >> is a >>>> good thing, as few other Open Source projects package the jars with OSGi >>>> contract metadata. >>>> >>>> I do wonder, however, if these spec jars should be provided by a >> separate >>>> Aries project, rather than scattered across multiple other projects. I >> have >>>> two main reasons for this. >>>> >>>> 1. It makes the code for packaging the spec jars harder to find in >> source >>>> control >>>> >>>> 2. It creates some non-obvious links between projects. It’s clear why >>>> tx-control depends on JPA, but not why JAX-RS depends on CDI! >>>> >>>> The spec jars are mostly being put into a separate Maven group already. >> I >>>> would simply see this as a formalisation of that earlier decision. >>>> >>>> Thoughts? >>>> >>>> Tim >>>> >>>> Sent from my iPhone >>> >>> >>> >>> >>> -- >>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>> (@rotty3000) >>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>> (@Liferay) >>> Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> >> (@OSGiAlliance) >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance) -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Aries Spec Jars
Can I ask why the spec/api bundles that are provided by ServiceMix are not usable? Could the ServiceMix api bundles be updated to make them usable? I really would prefer not getting into a situation where we have a bunch of project that are commonly used together starting to pull in multiple versions or implementations of the same bundles. For example: CXF uses and would pull in the org.apache.servicemix.specs.jaxrs-api-2.1 bundle which would obviously result in multiple bundles exporting the same package/versions. Dan > On Dec 21, 2017, at 9:28 AM, Raymond Auge <raymond.a...@liferay.com> wrote: > > Hi Tim, > > I was thinking of proposing this very thing over the last few weeks. > > I had already deliberately pushed the CDI related spec jars and also the > spec jar for JAX-RS into an aries sub-group in maven in order to better > accommodate and reflect this very thing. > > So, I would be a big +1 for having these in a specific sub-project. > > - Ray > > On Thu, Dec 21, 2017 at 6:25 AM, Timothy Ward <timothyjw...@apache.org> > wrote: > >> Hi all, >> >> I’ve noticed that an increasing number of Aries projects are producing >> wrapped spec jars (JPA, JAX-RS, CDI...). In general I think that this is a >> good thing, as few other Open Source projects package the jars with OSGi >> contract metadata. >> >> I do wonder, however, if these spec jars should be provided by a separate >> Aries project, rather than scattered across multiple other projects. I have >> two main reasons for this. >> >> 1. It makes the code for packaging the spec jars harder to find in source >> control >> >> 2. It creates some non-obvious links between projects. It’s clear why >> tx-control depends on JPA, but not why JAX-RS depends on CDI! >> >> The spec jars are mostly being put into a separate Maven group already. I >> would simply see this as a formalisation of that earlier decision. >> >> Thoughts? >> >> Tim >> >> Sent from my iPhone > > > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> > (@Liferay) > Board Member & EEG Co-Chair, OSGi Alliance <http://osgi.org> (@OSGiAlliance) -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Apache Aries Spi-fly 1.0.10
+1 Dan > On Nov 22, 2017, at 5:43 AM, Guillaume Nodet <gno...@apache.org> wrote: > > I've staged a release candidate for spi-fly 1.0.10 which includes the > following changes: > [ARIES-1584] Do not spam messages for each considered and skipped bundle > [ARIES-1646] Improve upward compatibility of SPI Fly to ASM Version 6.x > > The staging repository is available at: > https://repository.apache.org/content/repositories/orgapachearies-1119 > > Please review and vote ! > > Cheers, > Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Aries Subsystem Release Candidate 2.0.10
+1 Dan > On Aug 2, 2017, at 4:40 AM, David Bosschaert <david.bosscha...@gmail.com> > wrote: > > Hi all, > > Release candidates have been staged for the following modules: > > subsystem-api 2.0.10 > subsystem-core 2.0.10 > subsystem 2.0.10 (i.e. the uber bundle) > > The following issues were resolved: > ARIES-1338 Bundle manifest parser does not allow multiple packages on > Import-Package clause > ARIES-1383 Provide option to disable the provisioning of dependencies at > install time. > ARIES-1417 Aries Subsystems implementation bundle must provide official > capabilities > ARIES-1441 Subsystem core tries to shutdown the framework when it has a > framework dependency like org.osgi.util.tracker > ARIES-1442 Subsystem impersonates bundles that are a constituent through > sharing the osgi.identity capability > ARIES-1444 Subsystem does not install because feature subsystem exports all > constituents > ARIES-1445 Bundles that are not direct dependencies of a subsystem can be > removed while still in use > ARIES-1446 ResolveContext should stop searching for capabilities once it > found a match > ARIES-1449 Multiple subsystem instances with the same location can be > concurrently installed. > ARIES-1452 Subsystem throws exception when bundle imports osgi framework > ARIES-1459 Installing subsystem with large number of constituents takes > forever or gives out of memory > ARIES-1465 Stopping the Subsystem-Core bundle does not remove synthesized > bundles > ARIES-1485 java.lang.UnsupportedOperationException when a hosted capability > is being inserted by the resolver. > ARIES-1522 NullPointerException (NPE) when creating a RequireBundleHeader > using the filter provided by FelixRequirementAdapter. > ARIES-1523 Application with fragment in archive and host in OBR will fail > to resolve. > ARIES-1538 Never fail a subsystem resolution because an already resolved > resource has a missing dependency. > ARIES-1588 Installation of subsystems fails due to uses constraint > violation after exposing feature capabilities. > ARIES-1590 Subsystem install fails due to unexpected resolve conflict > ARIES-1591 Subsystem install fails due to ArrayIndexOutofBoundsException > ARIES-1720 java.lang.NullPointerException while processing OSGI-INF as a > directory > > Note that this release was previously marked as 2.1.0 in JIRA but since > there were no API changes I changed this to 2.0.10. The API release is > identical to the 2.0.8 release and is included just for convience of being > able to use the same version number for both API and Core. > > The staging repository is located at > https://repository.apache.org/content/repositories/orgapachearies-1114 > > You can use this UNIX script to download the release and verify the > signatures: > https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh > > Usage: > sh verify_staged_release.sh 1114 tmpdir 2>&1 | tee verifyresults.txt > > More details on verifying the release here: > http://aries.apache.org/development/verifyingrelease.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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Apache Aries Remote Service Admin 1.11.0 ... take 3
+1 Dan > On Jul 1, 2017, at 8:32 AM, Christian Schneider <ch...@die-schneider.net> > wrote: > > I had to redo the release as the source zip was missing ... > > This release now contains the source zip at > https://repository.apache.org/content/repositories/orgapachearies-1113/org/apache/aries/rsa/org.apache.aries.rsa.main/1.11.0/org.apache.aries.rsa.main-1.11.0-source-release.zip > > I've staged the release at > > https://repository.apache.org/content/repositories/orgapachearies-1113/ > > For a list of issues resolved see: > > https://issues.apache.org/jira/projects/ARIES/versions/12339614 > > > Release Notes - Aries - Version rsa-1.11.0 > > ** Bug >* [ARIES-1713] - TopologyManagerExport fails for multiple interfaces >* [ARIES-1714] - fastbin long running (future) calls sometimes fail > > ** Improvement >* [ARIES-1684] - Upgrade ZooKeeper to 3.4.10 > > Please review and vote > > Here is my > +1 > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release blueprint-core 1.8.1, transaction-manager 1.3.3 and proxy-impl 1.1.1
+1 Dan > On May 9, 2017, at 8:57 AM, Guillaume Nodet <gno...@apache.org> wrote: > > Changelog > > > *blueprint-core* > > [ARIES-1559] Support injection of static values to bean properties or > constructor's args > > > *transaction-manager* > > [ARIES-1722] Refer to proper message bundle > > [ARIES-1719] Adjust HOWL log on configuration change > > > *proxy-impl* > > [ARIES-1618][ARIES-1342] Better sorting of separate interface hierarchies > > Staging repository: > https://repository.apache.org/content/repositories/orgapachearies-1108 > > Please review and vote > > -- > > Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Aries JPA 2.6.1
+1 Dan > On Mar 28, 2017, at 6:09 AM, Christian Schneider <ch...@die-schneider.net> > wrote: > > I've staged a release for vote at: > https://repository.apache.org/content/repositories/orgapachearies-1105 > > This release only fixes a single but critical bug as it can lead to errors > that are difficult to pin down for users. > > > Release Notes - Aries - Version jpa-2.6.1 > > ** Bug >* [ARIES-1689] - JpaInterceptor is not thread safe > > > https://issues.apache.org/jira/browse/ARIES/fixforversion/12340283 > 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 > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Aries JPA 2.6.0
+1 Dan > On Feb 24, 2017, at 1:54 PM, Christian Schneider <ch...@die-schneider.net> > wrote: > > I've staged a release for vote at: > https://repository.apache.org/content/repositories/orgapachearies-1100 > > > Release Notes - Aries - Version jpa-2.6.0 > > ** Bug >* [ARIES-1631] - Aries JPA does not honour the > javax.persistence.dataSource property >* [ARIES-1648] - Aries JPA does not advertise EntityManagerFactoryBuilder > or EntityManagerFactory services >* [ARIES-1649] - Aries EclipseLink Adapter packaging issues >* [ARIES-1689] - JpaInterceptor is not thread safe >* [ARIES-1695] - Aries JPA does not work in karaf because of spec problem > > ** Test >* [ARIES-1645] - Update JPA itests to current dependency versions > > https://issues.apache.org/jira/browse/ARIES/fixforversion/12338632 > > 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 > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Aries blueprint-maven-plugin-annotation 1.1.0 & blueprint-maven-plugin 1.6.0 (second approach)
+1 Dan -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release transaction-manager 1.3.2
+1 Dan > On Dec 19, 2016, at 4:14 AM, Guillaume Nodet <gno...@apache.org> wrote: > > I've staged a release of transaction manager 1.3.2. > The release contains the following fix: > ARIES-1640: Upgrade to geronimo transaction manager 3.1.4 > <https://issues.apache.org/jira/browse/ARIES-1640> > The geronimo release includes the following fix: > GERONIMO-4576: Make persistence exceptions more visible to client > <https://issues.apache.org/jira/browse/GERONIMO-4576> > The staging repo is available at: > https://repository.apache.org/content/repositories/orgapachearies-1091 > > Please review and vote! > > Cheers, > Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Proxy Impl 1.0.6
+1 Dan > On Dec 19, 2016, at 4:39 AM, Guillaume Nodet <gno...@apache.org> wrote: > > I've staged a release of Proxy Impl 1.0.6. > It contains the following fixes: > >[ARIES-1546] Add JDK9 support to proxy-impl > <http://issues.apache.org/jira/browse/ARIES-1546> > Staging repository: >https://repository.apache.org/content/repositories/orgapachearies-1092 > > Please review and vote! > > Cheers, > Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Aries JPA 2.5.0
+1 Dan > On Oct 28, 2016, at 5:23 AM, Christian Schneider <ch...@die-schneider.net> > wrote: > > I've staged a release for vote at: > https://repository.apache.org/content/repositories/orgapachearies-1089 > > Release Notes - Aries jpa-2.5.0 > > ** Bug >* [ARIES-1494] - Exception when calling a transactional method twice from > a non transaction method >* [ARIES-1575] - Aries JPA should use the persistence bundle's context to > obtain the Persistence Provider service >* [ARIES-1615] - Calling the method createAndCloseDummyEMF() causes > NullPointerException > > ** Improvement >* [ARIES-1629] - Remove persistence-api feature from aries jpa feature repo > > https://issues.apache.org/jira/browse/ARIES/fixforversion/12335940 > > > 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 > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: svn commit: r1754090 - in /aries/trunk/proxy/proxy-impl: ./ src/main/java/org/apache/aries/proxy/impl/ src/main/java/org/apache/aries/proxy/impl/common/ src/main/java/org/apache/aries/proxy/impl/g
Guillaume,
Does this change still allow running with ASM 5?The OpCodes class in 5.0.3
doesn’t have the V1_9 code. Thus, I’m not sure if this will work when this
method is hit when using ASM5.
Dan
> On Jul 26, 2016, at 5:15 AM, gno...@apache.org wrote:
>
> ---
> aries/trunk/proxy/proxy-impl/src/main/java/org/apache/aries/proxy/impl/ProxyUtils.java
> (original)
> +++
> aries/trunk/proxy/proxy-impl/src/main/java/org/apache/aries/proxy/impl/ProxyUtils.java
> Tue Jul 26 09:15:13 2016
> @@ -39,6 +39,10 @@ public class ProxyUtils
> //In order to avoid an inconsistent stack error the version of the
> woven byte code needs to match
> //the level of byte codes in the original class
> switch(JAVA_CLASS_VERSION) {
> + case Opcodes.V1_9:
> + LOGGER.debug("Weaving to Java 9");
> + weavingJavaVersion = Opcodes.V1_9;
> + break;
> case Opcodes.V1_8:
> LOGGER.debug("Weaving to Java 8");
> weavingJavaVersion = Opcodes.V1_8;
--
Daniel Kulp
dk...@apache.org <mailto:dk...@apache.org> - http://dankulp.com/blog
<http://dankulp.com/blog>
Talend Community Coder - http://coders.talend.com <http://coders.talend.com/>
Re: [VOTE] Release Apache Aries Transaction JDBC 2.1.2
+1 Dan > On May 23, 2016, at 12:05 PM, Guillaume Nodet <gno...@apache.org> wrote: > > This is a vote to release transaction-jdbc 2.1.2 > > We have one issue fixed > https://issues.apache.org/jira/browse/ARIES-1542 > > Staging repository: > https://repository.apache.org/content/repositories/orgapachearies-1070 > > Please vote to approve the release. This vote will be open for at least 72 > hours. > > Cheers, > Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] blueprint-maven-plugin 1.4.0
+1 Dan > On May 2, 2016, at 6:03 AM, Christian Schneider <ch...@die-schneider.net> > wrote: > > This is a vote to release blueprint-maven-plugin 1.4.0. > > We now have 11 issues fixed. See > https://issues.apache.org/jira/issues/?jql=fixVersion%20%3D%20blueprint-maven-plugin-1.4.0%20AND%20project%20%3D%20ARIES > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachearies-1069 > > One thing I would like to emphasize is that 8 of these issues and > improvements were reported and fixed by people who are not yet committers. > A big thanks to Sam Wright and Dominik Przybysz. > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Aries Blueprint Core 1.6.2
+1 Dan > On Apr 29, 2016, at 12:32 PM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Hi all, > > in order to fix ARIES-1540 (critical issue), I submit blueprint-core 1.6.2 > release to your vote. > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachearies-1068/ > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Aries Blueprint Parser 1.5.0, Blueprint Core 1.6.1, Blueprint CM 1.0.9 (take 2)
+1 Dan > On Apr 11, 2016, at 4:42 AM, Jean-Baptiste Onofré <j...@nanthrax.net> wrote: > > Hi all, > > in order to fix ARIES-1503 (severe issue), I staged the following artifacts: > > * blueprint-parser 1.5.0 > * blueprint-core 1.6.1 > * blueprint-cm 1.0.9 > > Staging Repository: > https://repository.apache.org/content/repositories/orgapachearies-1066/ > > Please vote to approve this release: > > [ ] +1 Approve the release > [ ] -1 Don't approve the release (please provide specific comments) > > This vote will be open for at least 72 hours. > > Thanks, > Regards > JB > -- > Jean-Baptiste Onofré > jbono...@apache.org > http://blog.nanthrax.net > Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Apache Aries Remote Service Admin 1.8.0
+1 Dan > On Mar 30, 2016, at 9:02 AM, Christian Schneider <ch...@die-schneider.net> > wrote: > > This is the first release of Aries RSA after the migration from CXF-DOSGi. > I used the same version as the upcoming CXF DOSGi. > > I've staged the release at > https://repository.apache.org/content/repositories/orgapachearies-1064/ > > For a list of issues resolved see: > > https://issues.apache.org/jira/browse/ARIES/fixforversion/12335491 > > Release Notes - Aries - Version rsa-1.8.0 > > ** New Feature >* [ARIES-1509] - Add obr repository >* [ARIES-1513] - Migrate CXF DOSGi to Aries RSA >* [ARIES-1514] - Add TCP transport provider > > Please review and vote > > Here is my > +1 > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [Discuss] Chronicle Queue transport for Aries rsa (licensing)
Looks like on master they have completely switched to the Apache License. Once they get a release with that, it would be usable. :) Dan > On Mar 24, 2016, at 9:42 AM, Christian Schneider <ch...@die-schneider.net> > wrote: > > I just did a POC Aries rsa transport using Chronicle Queue. It is indeed very > fast. I get about 500 000 msg/s for one way calls. > So from a performance perspective I think it would be very interesting to > have this as a transport. > > I am not sure if their licensing works for us though. They have switched to > lgpl mid last year. > > The good news is that I was able to get Peter Lawrey to add a special > licensing for open source projects like Aries. > See: https://github.com/OpenHFT/Chronicle-Queue/issues/250 > and: > https://github.com/OpenHFT/Chronicle-Queue/blob/master/LICENSE%20for%20Open%20Source%20product%20usage.txt > > So we are allowed to use the software under the apache license. Is that good > enough for us to include Chronicle queues into Aries rsa? > > Christian > > -- > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > http://www.talend.com > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Apache Aries Blueprint CM 1.0.8
+1 Dan > On Mar 18, 2016, at 1:03 PM, Guillaume Nodet <gno...@apache.org> wrote: > > I've staged a release of Blueprint CM at > https://repository.apache.org/content/repositories/orgapachearies-1062 > > I forgot to release it with the other bundles and is required to fix > [ARIES-1290][ARIES-1503] Better handling of XSD imports between namespace > handlers (e.g. cm->ext) > > Please review and vote ! > > Cheers, > Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release 6 bug fix bundles
+1 Dan > On Mar 15, 2016, at 12:24 PM, Guillaume Nodet <gno...@apache.org> wrote: > > I've staged a vote for the following bundles: > * proxy-impl 1.0.5 > * jmx-core 1.1.6 > * blueprint-core 1.6.0 > * blueprint-spring 0.2.0 > * blueprint-spring-extender 0.2.0 > * blueprint-noosgi 1.1.2 > > Staging repository > https://repository.apache.org/content/repositories/orgapachearies-1061 > > Proxy-Impl 1.0.5 > ** Bug >* [ARIES-1161] - ProxyGenerator uses ProxyCLassLoaded with wrong > classloader >* [ARIES-1342] - Aries Proxy Impl fails to proxy a service with > covariant type hierarchy in Java 8 >* [ARIES-1486] - can't create proxy on java 8 vm for interfaces > containing lambda >* [ARIES-1492] - Exception creating a subclass proxy of class with > package-private access modifer. > > Jmx-Core 1.1.6 > ** Bug >* [ARIES-1468] - Aries Transaction Blueprint bundle fails to start > sometimes > > Blueprint Core 1.6.0 > ** Bug >* [ARIES-1498] - NullPointerException NPE Blueprint Container > AbstractServiceReferenceRecipe setSatisfied >* [ARIES-1500] - Fix wildcard types support >* [ARIES-1503] - Timing issue when cm blueprint references ext > namespaces > ** New Feature >* [ARIES-1482] - Support programmatic creation of blueprint container > with specific additional namespaces > > Blueprint Spring 0.2.0 / Blueprint Spring Extender 0.2.0 > ** New Feature >* [ARIES-1480] - Complete spring extender support > > Blueprint Noosgi 1.1.2 > ** Improvement >* [ARIES-1460] - Using blueprint-noosgi, unable to resolve absolute > schemas to their local resources > > > Please review and vote ! > > Cheers > > -- > > Guillaume Nodet > > Red Hat, Open Source Integration > > Email: gno...@redhat.com > Web: http://fusesource.com > Blog: http://gnodet.blogspot.com/ -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Aries SPI-Fly 1.0.8
+1 Dan > On Dec 9, 2015, at 4:56 AM, dav...@apache.org wrote: > > Hi all, > > I'm calling a vote on SPI-Fly 1.0.8. > > The following bug has been fixed: > ARIES-1461 Support SPI-Consumer/Provider headers for fragment bundles > > This release includes the following modules: > > spi-fly-core > spi-fly-dynamic-bundle > spi-fly-static-bundle > spi-fly-static-tool > spi-fly-weaver > > Staging repository: > https://repository.apache.org/content/repositories/orgapachearies-1050 > > You can use this UNIX script to download the release and verify the > signatures: > https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh > > Usage: > sh verify_staged_release.sh 1050 tmpdir 2>&1 | tee verifyresults.txt > > More details on verifying the release here: > http://aries.apache.org/development/verifyingrelease.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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [DISCUSS] Spring support in Blueprint
Guillaume, Question: CXF uses the same namespace in some cases for both Blueprint and Spring. Any idea on how this would handle that? Would it invoke the Spring parser or the Blueprint parser? Dan > On Nov 23, 2015, at 9:13 AM, Guillaume Nodet <gno...@apache.org> wrote: > > Yeah, it's not really needed. > That's just what fileinstall does in karaf when dropping a single blueprint > xml in the deploy folder, and that's what I used during initial testing. > For a real bundle, that's definitely not needed. > I've committed a real integration test which demonstrates a better scenario > (which does not include the dynamic imports). > > Guillaume > > 2015-11-23 15:02 GMT+01:00 David Bosschaert <david.bosscha...@gmail.com>: > >> Hi Guillaume, >> >> On 23 November 2015 at 04:03, Guillaume Nodet <gno...@apache.org> wrote: >>> Good point, I haven't really tested this part specifically. >>> I've used the spring deployer to deploy my test xml in karaf, so afaik, >> it >>> uses a dynamicimport-package=*, so I'm not sure about the exact behaviour >>> yet. >> >> Can we avoid dynamicimport-package=* somehow? Using that you really >> throw all of the OSGi modularity out of the window. >> dynamicimport-package=* should be avoided at all times IMHO... >> >> David >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Apache Aries Subsystems release 2.0.6
+1 Dan > On Oct 28, 2015, at 1:24 PM, dav...@apache.org wrote: > > Hi all, > > I'd like to call a vote on Aries Subsystems 2.0.6. This release contains: > subsystem-api 2.0.6 > subsystem-core 2.0.6 > subsystem 2.0.6 (the uber bundle including api and core) > > The following issues were resolved: > > ARIES-1434 org.osgi.framework.BundleException: Region > 'application.a.esa;0.0.0;osgi.subsystem.application;1' is already > connected to region 'composite.a.esa;0.0.0;osgi.subsystem.composite;2 > ARIES-1425 Support both osgi.bundle and osgi.fragment resource types > when given a Subsystem-Content header clause with an unspecified type > attribute. > ARIES-1426 Implementation specific subsystem header > Application-ImportService should not affect the sharing policy. > ARIES-1427 org.osgi.service.subsystem.SubsystemException: > java.lang.IllegalArgumentException: Invalid filter: (version=*) > ARIES-1428 org.osgi.framework.BundleException: Could not resolve > module: Bundle was filtered by a resolver hook. > ARIES-1429 NullPointerException at > org.apache.aries.subsystem.core.internal.WovenClassListener.modified > at org.apache.aries.subsystem.core.internal.RegionUpdater.addRequirements > ARIES-1435 Sharing policy updates for dynamic imports, if necessary, > should proceed up the subsystem region tree. > ARIES-1439 Aries ResolveContext.insertHostedCapability() calls > unsupported add() method on capabilies > > The staging repository is Staging repository: > https://repository.apache.org/content/repositories/orgapachearies-1047 > > You can use this UNIX script to download the release and verify the > signatures: > https://svn.apache.org/repos/asf/aries/scripts/verify_staged_release.sh > > Usage: > sh verify_staged_release.sh 1047 tmpdir 2>&1 | tee verifyresults.txt > grep FAIL verifyresults.txt > grep ERROR verifyresults.txt > > More details on verifying the release here: > http://aries.apache.org/development/verifyingrelease.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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [Vote] Release Aries blueprint parser 1.3.2 and blueprint core 1.4.5
> On Oct 21, 2015, at 12:17 PM, John Ross <jwross.apa...@gmail.com> wrote: > > I'm receiving the following RAT failures when running the verify > script against 1045. The last simply means that Namespaces.java needs > a license header. I'm more concerned about the bad MD5s and SHA1s. Am > I doing something wrong on my end? I have the latest KEYS file > imported. With the latest releases of the various maven plugins, the “asc” files aren’t deployed with MD5 and SHA1 files. Your script is checking for them but not finding them. Dan > > *FAILURE - BAD MD5 for > mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2.pom.asc > * (compared add4b1422a75fb0f9a9b7a5d2d519742 and ) > *FAILURE - BAD MD5 for > mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-javadoc.jar.asc > * (compared abd8d09533f9ba7697cd34d76466f3b7 and ) > *FAILURE - BAD MD5 for > mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2.jar.asc > * (compared c70c2dd47a3db618772075d012b9b28f and ) > *FAILURE - BAD MD5 for > mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-sources.jar.asc > * (compared 0bfe742b7dfa7deb8e94df1695d7c70b and ) > *FAILURE - BAD MD5 for > mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-source-release.zip.asc > * (compared ae62356bdeca0da94e6a617de88d8ac3 and > ) > *FAILURE - BAD SHA1 for > mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2.pom.asc > * (compared 3e4ea60c489c0e1ca49df6ef9fc2970e4a3eef17 and ) > *FAILURE - BAD SHA1 for > mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-javadoc.jar.asc > * (compared 9c714c7e028045b267b2911611827b3bf0ddc782 an > d ) > *FAILURE - BAD SHA1 for > mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2.jar.asc > * (compared ca3a343aabe2d823f87d4af74864db26364cf9fc and ) > *FAILURE - BAD SHA1 for > mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-sources.jar.asc > * (compared e52950a2088bd2b101d316eeea702bb50b154fd9 an > d ) > *FAILURE - BAD SHA1 for > mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-source-release.zip.asc > * (compared ae37301b71706f19b00ec4bdc5f1a86749ad > a3ec and ) > RAT FAILURE:? src/main/java/org/apache/aries/blueprint/Namespaces.java > > On Wed, Oct 21, 2015 at 9:21 AM, Christian Schneider > <ch...@die-schneider.net> wrote: >> This release vote is mainly because of the issue ARIES-1430 which will >> always shutdown JPA bundles >> after 5 minutes. I also needed to release parser 1.3.2 as it was used by >> blueprint core. >> >> Release Notes - Aries - Version blueprint-parser-1.3.2 >> >> ** Improvement >>* [ARIES-1322] - Introduce Namespaces annotation >> >> https://issues.apache.org/jira/browse/ARIES/fixforversion/12332956 >> >> Staging repo: >> https://repository.apache.org/content/repositories/orgapachearies-1045 >> >> >> >> Release Notes - Aries - Version blueprint-core-1.4.5 >> >> ** Bug >>* [ARIES-1353] - NullpointerException when trying to log an exception >>* [ARIES-1430] - Blueprint bundle shut down after timeout even if all >> dependencies are present at that time >> >> https://issues.apache.org/jira/browse/ARIES/fixforversion/12333050 >> >> Staging repo: >> https://repository.apache.org/content/repositories/orgapachearies-1046/ >> >> 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 >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [Vote] Release Aries blueprint parser 1.3.2 and blueprint core 1.4.5
> On Oct 21, 2015, at 1:53 PM, John Ross <jwross.apa...@gmail.com> wrote: > > Sorry, I'm still not sure I understand. Are you saying our current > verification script is no longer applicable when using "the latest > releases of the various maven plugins"? Or is it still useful but we > should simply ignore the MD5 and SHA1 failures? What, if anything, > replaces the original point of the MD5 and SHA1 checks? No… there should be checks of MD5 and SHA1 files for everything except ASC files. Those are no longer applicable. .jar and .pom files should have associated MD5 and SHA1 files (and .asc files), but .asc files will no longer have md5 or sha1 files. Thus, the verification script would need to be updated to not have it check the MD5/SHA1 of .asc files, but maintain the check for everything else. Dan > > On Wed, Oct 21, 2015 at 12:46 PM, Daniel Kulp <dk...@apache.org> wrote: >> >>> On Oct 21, 2015, at 1:36 PM, John Ross <jwross.apa...@gmail.com> wrote: >>> >>> What would be the appropriate way to verify the integrity of the files >>> without them? >> >> The asc files are there to verify the integrity of the jar files and pom >> file. They also have built in integrity things as part of the gpg >> signature. There isn’t a point in having md5’s for them. That would be >> like saying we need an MD5 for the sha1 files. >> >> Dan >> >> >> >>> >>> On Wed, Oct 21, 2015 at 11:24 AM, Daniel Kulp <dk...@apache.org> wrote: >>>> >>>>> On Oct 21, 2015, at 12:17 PM, John Ross <jwross.apa...@gmail.com> wrote: >>>>> >>>>> I'm receiving the following RAT failures when running the verify >>>>> script against 1045. The last simply means that Namespaces.java needs >>>>> a license header. I'm more concerned about the bad MD5s and SHA1s. Am >>>>> I doing something wrong on my end? I have the latest KEYS file >>>>> imported. >>>> >>>> With the latest releases of the various maven plugins, the “asc” files >>>> aren’t deployed with MD5 and SHA1 files. Your script is checking for >>>> them but not finding them. >>>> >>>> Dan >>>> >>>> >>>> >>>>> >>>>> *FAILURE - BAD MD5 for >>>>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2.pom.asc >>>>> * (compared add4b1422a75fb0f9a9b7a5d2d519742 and ) >>>>> *FAILURE - BAD MD5 for >>>>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-javadoc.jar.asc >>>>> * (compared abd8d09533f9ba7697cd34d76466f3b7 and ) >>>>> *FAILURE - BAD MD5 for >>>>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2.jar.asc >>>>> * (compared c70c2dd47a3db618772075d012b9b28f and ) >>>>> *FAILURE - BAD MD5 for >>>>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-sources.jar.asc >>>>> * (compared 0bfe742b7dfa7deb8e94df1695d7c70b and ) >>>>> *FAILURE - BAD MD5 for >>>>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-source-release.zip.asc >>>>> * (compared ae62356bdeca0da94e6a617de88d8ac3 and >>>>> ) >>>>> *FAILURE - BAD SHA1 for >>>>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2.pom.asc >>>>> * (compared 3e4ea60c489c0e1ca49df6ef9fc2970e4a3eef17 and ) >>>>> *FAILURE - BAD SHA1 for >>>>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-javadoc.jar.asc >>>>> * (compared 9c714c7e028045b267b2911611827b3bf0ddc782 an >>>>> d ) >>>>> *FAILURE - BAD SHA1 for >>>>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2.jar.asc >>>>> * (compared ca3a343aabe2d823f87d4af74864db26364cf9fc and ) >>>>> *FAILURE - BAD SHA1 for >>>>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-sources.jar.asc >>>>> * (compared e52950a2088bd2b101d316eeea702bb50b154fd9 an >>>>> d ) >>>>> *FAILURE - BAD SHA1 for >>>>> mytempdirectory/1045/org/apache/ar
Re: [Vote] Release Aries blueprint parser 1.3.2 and blueprint core 1.4.5
> On Oct 21, 2015, at 1:36 PM, John Ross <jwross.apa...@gmail.com> wrote: > > What would be the appropriate way to verify the integrity of the files > without them? The asc files are there to verify the integrity of the jar files and pom file. They also have built in integrity things as part of the gpg signature. There isn’t a point in having md5’s for them. That would be like saying we need an MD5 for the sha1 files. Dan > > On Wed, Oct 21, 2015 at 11:24 AM, Daniel Kulp <dk...@apache.org> wrote: >> >>> On Oct 21, 2015, at 12:17 PM, John Ross <jwross.apa...@gmail.com> wrote: >>> >>> I'm receiving the following RAT failures when running the verify >>> script against 1045. The last simply means that Namespaces.java needs >>> a license header. I'm more concerned about the bad MD5s and SHA1s. Am >>> I doing something wrong on my end? I have the latest KEYS file >>> imported. >> >> With the latest releases of the various maven plugins, the “asc” files >> aren’t deployed with MD5 and SHA1 files. Your script is checking for them >> but not finding them. >> >> Dan >> >> >> >>> >>> *FAILURE - BAD MD5 for >>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2.pom.asc >>> * (compared add4b1422a75fb0f9a9b7a5d2d519742 and ) >>> *FAILURE - BAD MD5 for >>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-javadoc.jar.asc >>> * (compared abd8d09533f9ba7697cd34d76466f3b7 and ) >>> *FAILURE - BAD MD5 for >>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2.jar.asc >>> * (compared c70c2dd47a3db618772075d012b9b28f and ) >>> *FAILURE - BAD MD5 for >>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-sources.jar.asc >>> * (compared 0bfe742b7dfa7deb8e94df1695d7c70b and ) >>> *FAILURE - BAD MD5 for >>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-source-release.zip.asc >>> * (compared ae62356bdeca0da94e6a617de88d8ac3 and >>> ) >>> *FAILURE - BAD SHA1 for >>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2.pom.asc >>> * (compared 3e4ea60c489c0e1ca49df6ef9fc2970e4a3eef17 and ) >>> *FAILURE - BAD SHA1 for >>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-javadoc.jar.asc >>> * (compared 9c714c7e028045b267b2911611827b3bf0ddc782 an >>> d ) >>> *FAILURE - BAD SHA1 for >>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2.jar.asc >>> * (compared ca3a343aabe2d823f87d4af74864db26364cf9fc and ) >>> *FAILURE - BAD SHA1 for >>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-sources.jar.asc >>> * (compared e52950a2088bd2b101d316eeea702bb50b154fd9 an >>> d ) >>> *FAILURE - BAD SHA1 for >>> mytempdirectory/1045/org/apache/aries/blueprint/blueprint-parser/1.3.2/blueprint-parser-1.3.2-source-release.zip.asc >>> * (compared ae37301b71706f19b00ec4bdc5f1a86749ad >>> a3ec and ) >>> RAT FAILURE:? src/main/java/org/apache/aries/blueprint/Namespaces.java >>> >>> On Wed, Oct 21, 2015 at 9:21 AM, Christian Schneider >>> <ch...@die-schneider.net> wrote: >>>> This release vote is mainly because of the issue ARIES-1430 which will >>>> always shutdown JPA bundles >>>> after 5 minutes. I also needed to release parser 1.3.2 as it was used by >>>> blueprint core. >>>> >>>> Release Notes - Aries - Version blueprint-parser-1.3.2 >>>> >>>> ** Improvement >>>> * [ARIES-1322] - Introduce Namespaces annotation >>>> >>>> https://issues.apache.org/jira/browse/ARIES/fixforversion/12332956 >>>> >>>> Staging repo: >>>> https://repository.apache.org/content/repositories/orgapachearies-1045 >>>> >>>> >>>> >>>> Release Notes - Aries - Version blueprint-core-1.4.5 >>>> >>>> ** Bug >>>> * [ARIES-1353] - NullpointerException when trying to log an exception >>>> * [ARIES-1430] - Blueprint bundle shut down after timeout even if all >>>> dependencies are present at that time >>>> >>>> https://issues.apache.org/jira/browse/ARIES/fixforversion/12333050 >>>> >>>> Staging repo: >>>> https://repository.apache.org/content/repositories/orgapachearies-1046/ >>>> >>>> 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 >>>> >> >> -- >> Daniel Kulp >> dk...@apache.org - http://dankulp.com/blog >> Talend Community Coder - http://coders.talend.com >> -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Aries blueprint-maven-plugin 1.2.0
+1 Dan > On Sep 22, 2015, at 8:02 AM, Christian Schneider <ch...@die-schneider.net> > wrote: > > I've staged a release for vote at: > https://repository.apache.org/content/repositories/orgapachearies-1040 > > Highlights > > Namespace support in the maven bundle plugin. You can now give it a list of > namespace URIs to support. It will then create xml that is compatible to the > listed namespaces. > It will default to the jpa 2 and transaction 2 namespaces but you can also > set it to the old ones. > > The currently supported namespaces are: > "http://aries.apache.org/xmlns/jpa/v1.1.0; -> jpa support exported as xml > "http://aries.apache.org/xmlns/jpa/v2.0.0; -> jpa support based on annotations > "http://aries.apache.org/xmlns/transactions/v1.2.0; -> transactions exported > as xml > "http://aries.apache.org/xmlns/transactions/v2.0.0; -> transactions based on > annotations > > Release Notes - Aries - Version blueprint-maven-plugin-1.2.0 > > ** Bug >* [ARIES-1411] - Blueprint Annotations: Missing service when two services > with the same type are annotated > > ** Improvement >* [ARIES-1306] - Support @Produces annotation in blueprint-maven-plugin >* [ARIES-1308] - Support special blueprint beans like > blueprintBundleContext >* [ARIES-1326] - Allow to define bean id for service ref >* [ARIES-1373] - Add switch to generator for the annotation based style of > jpa 2.1.0 >* [ARIES-1414] - Allow to configure code generation based on namespaces > > > https://issues.apache.org/jira/browse/ARIES/fixforversion/12329703 > > 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 > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Aries transaction blueprint 2.0.0
+1 Dan > On Sep 22, 2015, at 7:58 AM, Christian Schneider <ch...@die-schneider.net> > wrote: > > I've staged a release for vote at: > https://repository.apache.org/content/repositories/orgapachearies-1039 > > Highlights: > The new release only provides JTA 1.2 Annoations (@Transactional) to > configure transactions. The new namespace has only one element tx:enable that > is used to activate the scanning of all defined blueprint beans for > transaction anntotations. > > The outermost @Transactional in a call stack also defines the life of a JTA > EntityManager provided by Aries JPA. So you can annotate a service method and > so make sure the same EM is available throughout the calls on the same thread. > > By using @Transactional(TxType.Supports) transaction.blueprint only creates a > coordination. Still the EntityManager will remain open inside the call stack. > > The 2.0.0 version of transaction.blueprint bundle can be used together with > the 1.1.1 version to support the new and old behaviour in parallel. > > Release Notes - Aries - Version transaction-blueprint-2.0.0 > > ** Improvement >* [ARIES-1382] - Only allow jta annotations to configure transactions >* [ARIES-1413] - Switch to 2.0.0 namespace > > https://issues.apache.org/jira/browse/ARIES/fixforversion/12333578 > > 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 > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Aries JPA 2.2.0 RC2
+1 Dan > On Sep 23, 2015, at 5:25 AM, Christian Schneider <ch...@die-schneider.net> > wrote: > > I have done a new build to include issue > https://issues.apache.org/jira/browse/ARIES-1415 . > > I've staged a release for vote at: > https://repository.apache.org/content/repositories/orgapachearies-1041 > > Release Notes - Aries - Version jpa-2.2.0 > > ** Bug >* [ARIES-1372] - Avoid NPE in case of exception in preCall >* [ARIES-1374] - EmSupplier is not unpublished when EntityManagerFactory > is unpublished >* [ARIES-1385] - Create karaf feature for aries jpa >* [ARIES-1386] - Use bnd file to describe OSGi config and use bnd > baselining >* [ARIES-1393] - XAJpaTemplate calls EntityManager#joinTransaction > regardless of desired TransactionType >* [ARIES-1401] - Damping Timeout for access to EntityManager in blueprint > too short >* [ARIES-1402] - We are unable to build jpa for a 1.6 JVM due to changes > in the jpa-parent/pom >* [ARIES-1403] - Namespace for jpa blueprint should be jpa/2.0.0 >* [ARIES-1409] - JPA compilation error when compiling against 1.6 jre/lib > jars. >* [ARIES-1412] - EmProxy needs to unwrap InvocationTargetException >* [ARIES-1415] - Exception laundering in JpaTemplate impls > > ** Improvement >* [ARIES-1405] - Make sure bundle goes into graceperiod if services needed > for JPA are not present >* [ARIES-1406] - Add karaf itests to test the examples > > https://issues.apache.org/jira/browse/ARIES/fixforversion/12333252 > > The tag is here: > https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.jpa-2.2.0/ > > > 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 > -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Versioning Policy
On Aug 18, 2015, at 12:35 PM, John W Ross jwr...@us.ibm.com wrote: Previously, you could count on a minor bundle version increment to correspond to at least one package in that bundle also having a minor version increment. I guess what it would tell me now is that at least one of the packages in one of the bundles within the same project received a minor version increment, although not necessarily this particular bundle? Correct. Dan From: Christian Schneider ch...@die-schneider.net To: dev@aries.apache.org Date: 08/18/2015 11:10 AM Subject: Re: Fw: Versioning Policy Sent by: Christian Schneider cschneider...@gmail.com As long as the bundle exports the packages with the same version as before it should not have any influence. The only major problem would be if people use require bundle instead of import package. Christian On 18.08.2015 17:56, John W Ross wrote: There are no concerns with a bundle version changing even though the content of the bundle did not change? -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] transaction blueprint 1.1.1
+1 Dan On Aug 8, 2015, at 2:23 PM, Christian Schneider ch...@die-schneider.net wrote: Because of a critical error I had to do another bugfix release. I've staged a release for vote at: https://repository.apache.org/content/repositories/orgapachearies-1036 *Release Notes - Aries - Version transaction-blueprint-1.1.1* ** Bug * [ARIES-1369] - Transaction is not rolled back if coordination has failed https://issues.apache.org/jira/browse/ARIES/fixforversion/12333243 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Aries Asynchronous OSGi Services 1.0.1
+1 Dan On Aug 6, 2015, at 7:46 AM, 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 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Resolved] (ARIES-791) Blueprint 0.4 is not backwords compatible in ways that break CXF
[ https://issues.apache.org/jira/browse/ARIES-791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-791. --- Resolution: Fixed Enough was fixed to allow CXF to work. CXF uses some reflection to work around the rest, although that is likely irrelevant now as CXF no longer supports the old versions of Karaf that would use the old blueprint versions. Blueprint 0.4 is not backwords compatible in ways that break CXF Key: ARIES-791 URL: https://issues.apache.org/jira/browse/ARIES-791 Project: Aries Issue Type: Bug Components: Blueprint Reporter: Daniel Kulp Assignee: Daniel Kulp Some of the changes in 0.4 of blueprint cause CXF to break. These include: 1) Marking container, di, and util as private. CXF needs these to configure objects. (see ARIES-790) 2) Removal of BundleDelegatingClassLoader 3) Moving of ExtendedBlueprintContainer into services subpackage We really need a version of blueprint that tries to be as backwords compatible as possible (to allow existing users to upgrade without breaking applications), but also provide the new API's (deprecate the old ones) so that projects like CXF can update to new API's. When 0.4.1 is out for a while and most users/dependencies have updated, THEN remove the breaking changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
Re: Releasing at the top level only (was: Re: [VOTE] blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web-1.1.1 releases)
Well, there is also the issue of selecting the “version” to use.For example, for this blueprint release, we have numbers like 1.3.1 and 1.1.1 and 1.4.4. Do we just up everything in blueprint to something like 1.5? Or do we bite the bullet and just say that since we are flipping version schemes, start at 2.0? (obviously, just talking about the bundle version, not the package versions) JPA was a bit easer since the entire tree was going to a 2.0. It was a good time to do it. Dan On Jul 13, 2015, at 9:24 AM, Jeremy Hughes jpjhug...@gmail.com wrote: It would also seem, that we are going to have top level modules doing either one of the release processes for some time. I think it would be best, if we can get to a single release process - but that may take some time. I think there are two things we should vote on to make this concrete: a) each top-level-module MUST use either the old 'release by bundle' approach OR the new 'release by top-level-module' approach. b) we favour projects moving the 'release by top-level-module' approach i.e. saying what we prefer as a community, without putting the onus on a release manager to do the conversion the next time a release is needed. I'll leave this thread going for a while for more discussion before opening a vote thread. Thanks, Jeremy On 13 July 2015 at 14:05, Jeremy Hughes jpjhug...@gmail.com wrote: Ok, that sounds fair. Subsystem is another one. Would you have a chance to document how you approached converting the JPA module (ok so I know you reimplemented at the same time :-) ... so that others can use the same approach for other modules? Jeremy On 13 July 2015 at 14:04, Christian Schneider ch...@die-schneider.net wrote: Hi Jeremy, yes it was the intent. It is quite some work to convert a submodule to the new release process though. So I think the best approach is to convert each module at a certain point and do submodule releases from then on. As long as a submodule is not converted I propose we continue doing releases in the per bundle style. So we have a smooth transition and do not hold off releases. Christian On 13.07.2015 14:37, Jeremy Hughes wrote: Hi, We had a discussion at the end of May about changing out release process to release at the top level module only. I've just realised this release vote was for sub-modules and that really we should have done a full Blueprint release. Christian, that was the intent wasn't it? I guess next time :-) Cheers, Jeremy On 2 July 2015 at 21:46, Sergey Beryozkin sberyoz...@gmail.com wrote: This vote passes with 4 binding +1s. I'll promote the artifacts Thanks all Sergey On 29/06/15 16:56, Sergey Beryozkin wrote: Hi All This is a vote to support the release of blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web 1.1.1. The staging repository for blueprint-parser-1.3.1 is at https://repository.apache.org/content/repositories/orgapachearies-1027 The staging repository for blueprint-noosgi-1.1.1 and blueprint-web-1.1.1 is at https://repository.apache.org/content/repositories/orgapachearies-1028 The following issues have been addressed: https://issues.apache.org/jira/browse/ARIES-1322 https://issues.apache.org/jira/browse/ARIES-1323 https://issues.apache.org/jira/browse/ARIES-1334 A servlet-based deployment of Blueprint contexts with custom namespace handlers will work better in non OSGI environments after the release. The vote is open for the next 72 hours, here is my +1, Thanks, Sergey -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release versioning plugin 0.3.1, blueprint-core 1.4.4 and blueprint-cm 1.0.7
+1 It’s a shame blueprint core wasn’t updated to grab the latest blueprint-parser, but not a big deal for this as it’s just an additional class change that isn’t used in core yet anyway. Dan On Jul 13, 2015, at 5:31 AM, Guillaume Nodet gno...@apache.org wrote: I've stage some releases at https://repository.apache.org/content/repositories/orgapachearies-1032 Versioning plugin = [ARIES-1303] Allow exceptions on the blueprint plugin Blueprint-Core ** Bug * [ARIES-1288] - ClassCastException with proxy set in bean of generic class * [ARIES-1303] - Return type for public API getRespository() is not exported * [ARIES-1333] - Cannot instantiate singleton collections in blueprint * [ARIES-1350] - Namespace handler can't be found even if it's registered correctly ** Improvement * [ARIES-1292] - Improve log output when destroying a BlueprintContainer * [ARIES-1319] - Reduce memory allocation in org.apache.aries.blueprint.proxy.Collaborator class * [ARIES-1324] - Allow to use Blueprint annotations and configuration files simultaneously Blueprint-CM == ** Bug * [ARIES-1290] - Reflect cm.CmPropertyPlaceholder - ext.PropertyPlaceholder relationship in XSD Please review and vote [ ] +1 Release those artefacts [ ] -1 Do not Cheers Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web-1.1.1 releases
+1 Dan On 29.06.2015 17:56, Sergey Beryozkin wrote: Hi All This is a vote to support the release of blueprint-parser-1.3.1, blueprint-noosgi-1.1.1, blueprint-web 1.1.1. The staging repository for blueprint-parser-1.3.1 is at https://repository.apache.org/content/repositories/orgapachearies-1027 The staging repository for blueprint-noosgi-1.1.1 and blueprint-web-1.1.1 is at https://repository.apache.org/content/repositories/orgapachearies-1028 The following issues have been addressed: https://issues.apache.org/jira/browse/ARIES-1322 https://issues.apache.org/jira/browse/ARIES-1323 https://issues.apache.org/jira/browse/ARIES-1334 A servlet-based deployment of Blueprint contexts with custom namespace handlers will work better in non OSGI environments after the release. The vote is open for the next 72 hours, here is my +1, Thanks, Sergey -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Aries JPA 2.0.0
+1 Dan On Jun 16, 2015, at 9:16 AM, Christian Schneider ch...@die-schneider.net wrote: I've staged a release for vote at: https://repository.apache.org/content/repositorie/orgapachearies-1024/ This is the first release of Aries JPA on a sub project basis. So all modules have the same version. Still the package versions are managed separately using semantic versioning. This version is a major redesign of the jpa modules. Some of highlights: 1. Persistence Unit bundles can now be updated 2. DataSource and DataSourceFactory are now tracked as services. While we still use the jndi syntax we are now fully dynamic. An EMF is only created if the PersistenceProvider and DataSource are present 3. We now support a JPATemplate style that works nicely with Java 8 closures and makes it easy to use JPA with Declarative Services. See examples 4. We now pass the OSGi TCK for jpa. The source contains a tck test module that can be easily run by everyone with tck access 5. Support for @PersistenceContext and @PersistenceUnit annotations For a detailed list of changes see: https://issues.apache.org/jira/browse/ARIES/fixforversion/12332388 Release Notes - Aries - Version jpa-2.0.0 ** Bug * [ARIES-1023] - Construct a persistence unit with parameters * [ARIES-1079] - The jpa.xsd incorrectly specifies bp:map for context, or namespace handler looking for wrong namespace * [ARIES-1162] - Persistence Units neet to be destroyed when bundle becomes unresolved * [ARIES-1270] - ClasscastException or incompatible type when persistence unit bundle is refreshed * [ARIES-1271] - EntityManager throws InvocationtargetException instead of original cause * [ARIES-1273] - Persistence unit with hibernate does not start if datasource is not present * [ARIES-1325] - Redesign of jpa component * [ARIES-1337] - Avoid exception when closing an already closed EMF ** Improvement * [ARIES-1294] - Refactor blueprint NSHandler * [ARIES-1332] - Update to parent 2.0.1 * [ARIES-1335] - Avoid using aries util in eclipselink adapter Please review and vote: [ ] +1 Release Aries JPA 2.0.0 [ ] -1 Do not Here is my +1 Cheers, Christian -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Aries parent 2.0.1
+1 Dan On Jun 4, 2015, at 6:05 AM, Christian Schneider cschnei...@talend.com wrote: I've staged a release for vote at: https://repository.apache.org/content/repositories/orgapachearies-1023 For changes see: https://issues.apache.org/jira/browse/ARIES/fixforversion/12332645 T Key Summary AssigneeReporterP Status Resolution Fix Version/s Created Updated Patch Info improvement.png ARIES-1330 Remove codehause repo, add ops4j snapshot repo Christian Schneider Christian Schneider major.png Resolved Fixed parent-2.0.104/Jun/15 04/Jun/15 improvement.png ARIES-1331 Upgrade maven release plugin to 2.5.2 Christian Schneider Christian Schneider major.png Resolved Fixed parent-2.0.104/Jun/15 04/Jun/15 Please review and vote: [ ] +1 Release Aries parent 2.0.1 [ ] -1 Do not Cheers, Christian Schneider -- Christian Schneider Open Source Architect http://www.liquid-reality.de Talend Germany GmbH | Servatiusstrasse 53 - 53175 Bonn - Germany www.talend.com Connecting the Data-Driven Enterprise -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [Discuss] Release whole sub projects instead of individual bundles
On May 21, 2015, at 11:44 AM, Jeremy Hughes jpjhug...@gmail.com wrote: Hi, Simplifying the release process would definitely be good. I'd like to know the detail of what you're suggesting. I think you're saying that a release of (say) Aries JPA would contain all the artifacts the child modules release today... plus tests plus samples. The release would be a src and a bin tgz/zip file and would go up on www.apache.org/dist/aries. Correct. What would be published to maven central? Yes. That wouldn’t change. It would be easier as things would pretty much be in a single staging area in Nexus. I think we need to keep the semantic versioning of our packages consistent going forward - for people doing import-package imports (hopefully most users). Package level exports would remain as is and be completely semantic versioned. Ideally we would keep semantic versioning of the bundles consistent going forward too - for people doing require-bundle. This would change. All the bundles for the release would have identical version numbers. We could introduce a new 'top-level-module' version which wouldn't be used at runtime, but would help in aggregating together a set of bundles that are consistent with each other well tested etc. So, if we * always release at the top-level-module level and * keep the way we do package and bundle versioning going forward, and * publish the individual bundles from the release into maven central with their existing well known co-ordinates would this work for you? I'm slightly concerned in writing this, that this might not provide enough simplification in the build process, although it would mean a single artifact (well src and bin) to vote on even though that results in multiple artifacts being published to maven central. All the jars/bundles in the “module” would have identical version number. The exports in the bundles would be semantically versioned correctly. There would be a single “src.tar.gz” and “bin.tar.gz” for dist.apache.org, but each bundle would also be put in central individually with their “sources.jar” and javadoc jars (for IDE integration). A release of all of a “module” can be done with a single “mvn release:prepare; mvn release:perform” which would pretty much handle everything. Dan Thanks, Jeremy On 20 May 2015 at 16:12, Christian Schneider ch...@die-schneider.net wrote: Currently we release each bundle separately and we do not release tests and examples at all. This approach is very fine grained and tedious if several bundles need to be released. Probably Holly can tell some stories about the fun of releasing aries 1.0.0. So I would like to discuss changing to a more coarse grained model. The idea is to release per sub project like e.g. Aries JPA. This would mean that we always release all bundles of a sub project even if nothing has changed. Of course we would still version exported packages according to semantic versioning rules. So apart from having some additional bundle I do not see a big disadvantage in the coarse grained model. Users could still depend on the old api and still work with newer releases if the API did not change. On the other side there are a lot of advantages for releasing per sub project: - Easier to understand for users. They could say I am using Aries JPA 2.0.0 instead of saying I use org.apache.aries.jpa.api 1.0.2, org.apache.aries.jpa.blueprint.aries 1.0.4, org.apache.aries.jpa.container 1.0.2, org.apache.aries.jpa.container.context 1.0.4 - The jira structure would be simpler as we would only need one version per sub project - We could migrate to git at last as we could then have one git repo per subproject that could be nicely branched and tagged on the repo / sub project level. One other nice thing would be that we could move to git gradually one sub project at a time without disturbing the others. - We would tag the tests and examples together with the production bundles. This makes it much easier to run tests against a specific release version. This should also make it much easier to maintain bugfix branches and make sure they are properly tested. - Per apache policy we have to store all releases at www.apache.org/dist/aries. With the current fine grained model almost no one seems to do this. This should also be easier with more coarse grained releases. What do you think? Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [Discuss] Release whole sub projects instead of individual bundles
I have to agree with this. One of our goals really needs to be to “release” software that we’re working on. The current setup really makes things much much harder than it needs to be to do the releases. I’ve done several blueprint releases and collecting the various things that “need” releasing is a pain. In addition, it makes it much harder for users to consume the releases. Knowing which bundles were built and tested together is nearly impossible. Upgrading to the latest releases is a pain as you have to check versions for all kinds of things. The migration to git is another good reason. :-) The only thing to be aware of is to avoid the use of “sub project”. That tends to raise flags. “Per technology module” release or something. Dan On May 20, 2015, at 11:12 AM, Christian Schneider ch...@die-schneider.net wrote: Currently we release each bundle separately and we do not release tests and examples at all. This approach is very fine grained and tedious if several bundles need to be released. Probably Holly can tell some stories about the fun of releasing aries 1.0.0. So I would like to discuss changing to a more coarse grained model. The idea is to release per sub project like e.g. Aries JPA. This would mean that we always release all bundles of a sub project even if nothing has changed. Of course we would still version exported packages according to semantic versioning rules. So apart from having some additional bundle I do not see a big disadvantage in the coarse grained model. Users could still depend on the old api and still work with newer releases if the API did not change. On the other side there are a lot of advantages for releasing per sub project: - Easier to understand for users. They could say I am using Aries JPA 2.0.0 instead of saying I use org.apache.aries.jpa.api 1.0.2, org.apache.aries.jpa.blueprint.aries 1.0.4, org.apache.aries.jpa.container 1.0.2, org.apache.aries.jpa.container.context 1.0.4 - The jira structure would be simpler as we would only need one version per sub project - We could migrate to git at last as we could then have one git repo per subproject that could be nicely branched and tagged on the repo / sub project level. One other nice thing would be that we could move to git gradually one sub project at a time without disturbing the others. - We would tag the tests and examples together with the production bundles. This makes it much easier to run tests against a specific release version. This should also make it much easier to maintain bugfix branches and make sure they are properly tested. - Per apache policy we have to store all releases at www.apache.org/dist/aries. With the current fine grained model almost no one seems to do this. This should also be easier with more coarse grained releases. What do you think? Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Aries Transaction Manager 1.2.0
+1 Dan On Apr 28, 2015, at 4:50 AM, Guillaume Nodet gno...@apache.org wrote: I've staged a release for vote at: https://repository.apache.org/content/repositories/orgapachearies-1022 The only real change is to include the new transaction manager 3.1.2 release from geronimo (ARIES-1313 https://issues.apache.org/jira/browse/ARIES-1313) which brings a few fixes. Fwiw, the bundle version change is required by the versioning plugin, so ... I used it. Please review and vote: [ ] +1 Release Aries Transaction Manager 1.2.0 [ ] -1 Do not Cheers, Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Resolved] (ARIES-1293) Help custom namespace handlers that would like bean references..
[
https://issues.apache.org/jira/browse/ARIES-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved ARIES-1293.
Resolution: Fixed
Fix Version/s: blueprint-core-1.4.2
Assignee: Daniel Kulp
Help custom namespace handlers that would like bean references..
Key: ARIES-1293
URL: https://issues.apache.org/jira/browse/ARIES-1293
Project: Aries
Issue Type: Bug
Components: Blueprint
Reporter: Daniel Kulp
Assignee: Daniel Kulp
Fix For: blueprint-core-1.4.2
In some cases, custom namespace handlers may have a schema element like:
{code:xml}
xsd:element name=plugin
xsd:complexType
xsd:sequence
xsd:any namespace=##other/
/xsd:complexType
/xsd:element
{code}
where they intend to allow the user to define some sort of bean or other
object to be defined by the user. This works well in Spring/Spring-DM as
you can define an object there via the normal Spring bean element.
However, blueprint.xsd does NOT have a top level bean element that can be
referenced.Thus, with the above schema, you can only use objects that can
be created via custom namespaces.
The proposal would be to add two elements to the blueprint-ext namespace:
{code:xml}
xsd:element name=bean type=bp:Tbean/
xsd:element name=reference type=bp:Treference/
{code}
to fill the gap that Spring-DM provides that we cannot do with Blueprint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release aries-jmx-core 1.1.3
+1 Dan On Mar 4, 2015, at 2:39 AM, Guillaume Nodet gno...@apache.org wrote: I've uploaded a release candidate for aries-jmx-core-1.1.3 at https://repository.apache.org/content/repositories/orgapachearies-1019 It only contains a fix for ARIES-1304, but given the JMX code is very stable, I thought I did not really make sense to wait before cutting a release. Tag: http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.jmx.core-1.1.3/ Please review and vote Cheers, Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[RESULT][VOTE] Release Aries blueprint-maven-plugin, blueprint-noosgi, and blueprint-web
We have 3 binding votes and 2 additional votes. This vote passes. Dan On Feb 24, 2015, at 3:36 PM, Daniel Kulp dk...@apache.org wrote: This is a vote to release the blueprint-maven-plugin 1.1, blueprint-noosgi 1.1.0, and blueprint-web 1.1.0.Blueprint-noosgi is needed to be able to fix some issues in geronimo-xbean. (well, to write some tests for the fix to a problem in geronimo-xbean). Blueprint-web uses the new blueprint-noosgi to provide some functionality to allow namespace handlers. Staging area: https://repository.apache.org/content/repositories/orgapachearies-1017/ Tags: http://svn.apache.org/repos/asf/aries/tags/blueprint-maven-plugin-1.1.0/ http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.noosgi-1.1.0/ http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.web-1.1.0/ Here is my +1 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[VOTE] Release Aries blueprint-maven-plugin, blueprint-noosgi, and blueprint-web
This is a vote to release the blueprint-maven-plugin 1.1, blueprint-noosgi 1.1.0, and blueprint-web 1.1.0.Blueprint-noosgi is needed to be able to fix some issues in geronimo-xbean. (well, to write some tests for the fix to a problem in geronimo-xbean). Blueprint-web uses the new blueprint-noosgi to provide some functionality to allow namespace handlers. Staging area: https://repository.apache.org/content/repositories/orgapachearies-1017/ Tags: http://svn.apache.org/repos/asf/aries/tags/blueprint-maven-plugin-1.1.0/ http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.noosgi-1.1.0/ http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.web-1.1.0/ Here is my +1 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[RESULT] [VOTE] Release some blueprint updates
We have 3 binding +1 votes and 2 non-binding +1 votes for the blueprint-core and blueprint-cm. I’ll get those released. There is an objection to the maven-plugin due to an additional bug and a behavior change that should require a non-patch version number bump. I’ll drop that. Thanks! Dan On Feb 19, 2015, at 11:56 AM, Daniel Kulp dk...@apache.org wrote: This is a vote to release: blueprint-core-1.4.3 blueprint-cm-1.0.6 blueprint-maven-plugin 1.0.1 This is mostly just to release some of the bug fixes and updates we’ve been working on instead of letting them languish in the repo. Release early/often/etc… :-) Staging areas: https://repository.apache.org/content/repositories/orgapachearies-1015/ https://repository.apache.org/content/repositories/orgapachearies-1016/ Tags: http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.core-1.4.3/ http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.cm-1.0.6/ Here is my +1. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Release blueprint-nosgi....
I’m planning to do a release of blueprint-noosgi tomorrow. It contains some fixes and enhancements that will allow it to be more usable for some unit tests I’ve written for Geronimo-xbean. Any additions/objections/etc… please let me know ASAP! Thanks! -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
blueprint releases....
We have a few bugs fixed in blueprint that I’d like to get some releases for. Unless there are any major objections, tomorrow I plan to build: blueprint-core blueprint-cm blueprint-maven-plugin Let me know asap if there is anything else that needs to be there. Thanks! -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Updated] (ARIES-1293) Help custom namespace handlers that would like bean references..
[
https://issues.apache.org/jira/browse/ARIES-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated ARIES-1293:
---
Description:
In some cases, custom namespace handlers may have a schema element like:
{code:xml}
xsd:element name=plugin
xsd:complexType
xsd:sequence
xsd:any namespace=##other/
/xsd:complexType
/xsd:element
{code}
where they intend to allow the user to define some sort of bean or other object
to be defined by the user. This works well in Spring/Spring-DM as you can
define an object there via the normal Spring bean element. However,
blueprint.xsd does NOT have a top level bean element that can be referenced.
Thus, with the above schema, you can only use objects that can be created via
custom namespaces.
The proposal would be to add two elements to the blueprint-ext namespace:
{code:xml}
xsd:element name=bean type=bp:Tbean/
xsd:element name=reference type=bp:Treference/
{code}
to fill the gap that Spring-DM provides that we cannot do with Blueprint.
was:
In some cases, custom namespace handlers may have a schema element like:
{code:xml}
xsd:element name=plugin
xsd:complexType
xsd:sequence
xsd:any namespace=##other/
/xsd:complexType
/xsd:element
{code}
where they intend to allow the user to define some sort of bean or other object
to be defined by the user. This works well in Spring/Spring-DM as you can
define an object there via the normal Spring bean element. However,
blueprint.xsd does NOT have a top level bean element that can be referenced.
Thus, with the above schema, you can only use objects that can be created via
custom namespaces.
The proposal would be to add two elements to the blueprint-ext namespace:
{code:xml}
xsd:element name=bean type=bp:Tbean/
xsd:element name=reference type=bp:Treference/
{code}
to fill the gap that Spring-DM provides that we cannot do with Blueprint.
Help custom namespace handlers that would like bean references..
Key: ARIES-1293
URL: https://issues.apache.org/jira/browse/ARIES-1293
Project: Aries
Issue Type: Bug
Components: Blueprint
Reporter: Daniel Kulp
In some cases, custom namespace handlers may have a schema element like:
{code:xml}
xsd:element name=plugin
xsd:complexType
xsd:sequence
xsd:any namespace=##other/
/xsd:complexType
/xsd:element
{code}
where they intend to allow the user to define some sort of bean or other
object to be defined by the user. This works well in Spring/Spring-DM as
you can define an object there via the normal Spring bean element.
However, blueprint.xsd does NOT have a top level bean element that can be
referenced.Thus, with the above schema, you can only use objects that can
be created via custom namespaces.
The proposal would be to add two elements to the blueprint-ext namespace:
{code:xml}
xsd:element name=bean type=bp:Tbean/
xsd:element name=reference type=bp:Treference/
{code}
to fill the gap that Spring-DM provides that we cannot do with Blueprint.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Re: [VOTE] Release aries blueprint-authz 1.0.0 and blueprint-maven-plugin 1.0.0
+1 Dan On Dec 5, 2014, at 8:22 AM, Christian Schneider ch...@die-schneider.net wrote: I need one more binding vote before I can do the release. Please help getting these changes out. Christian On 10.11.2014 17:44, Christian Schneider wrote: As discussed previously, I staged releases for two new blueprint modules: Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1014 Content: blueprint-maven-plugin 1.0.0 org.apache.aries.blueprint-authz 1.0.0 https://issues.apache.org/jira/issues/?jql=project%20%3D%20ARIES%20AND%20fixVersion%20%3D%20%22blueprint-authz-1.0.0 https://issues.apache.org/jira/browse/ARIES/fixforversion/12328945 In sum there are only these two issues: https://issues.apache.org/jira/browse/ARIES-1269 Add blueprint maven plugin https://issues.apache.org/jira/browse/ARIES-1226 JAAS and JEE annotation based authorization maven-blueprint-plugin -- For the blueprint maven plugin there is an example project at: https://github.com/cschneider/Karaf-Tutorial/tree/master/tasklist-cdi The issue above also contains some more details. The plugin creates blueprint.xml from JEE as well as from spring annotations. The number of supported annotations is limited but enough to create even mid size projects. I plan to add documentation about the plugin to the aries website. blueprint-authz Is a blueprint extension that can be enabled using a simple authz:enabled/ element in blueprint. The namespace is http://aries.apache.org/xmlns/authorization/v1.0.0 When authorization is enabled then beans are scanned for @RolesAllowed and @DenyAll annotations. If any are found then an interceptor is installed that checks access to the beans using a JAAS context. There is a test in blueprint itests that shows the usage: http://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-itests/src/test/java/org/apache/aries/blueprint/itests/authz/testbundle/impl/SecuredServiceImpl.java http://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-itests/src/test/java/org/apache/aries/blueprint/itests/authz/AuthorizationTest.java http://svn.apache.org/repos/asf/aries/trunk/blueprint/blueprint-itests/src/test/resources/authz.xml Please review and vote [ ] +1 Release those bundles [ ] -1 Do not Here is my +1 (non binding) Cheers, Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[VOTE] blueprint-cm 1.0.5
There is a bug in blueprint-cm that is a critical blocker to getting a Karaf release out: https://issues.apache.org/jira/browse/KARAF-3151 https://issues.apache.org/jira/browse/ARIES-1257 JB fixed it yesterday and I’d like to get the release done so they aren’t blocked by us. The only change is that fix. Staging repo: https://repository.apache.org/content/repositories/orgapachearies-1011/ Tag: http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.cm-1.0.5/ Here is my +1 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release a few bug fix bundles
+1 Dan On Sep 15, 2014, at 12:02 PM, 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, ARIES-1227, ARIES-1229, ARIES-1063, ARIES-1065, ARIES-1201 * jndi-api 1.1.0 : ARIES-1117 * jndi-core 1.0.1 : ARIES-1068, ARIES-1117, ARIES-1242, ARIES-1243 * proxy-impl 1.0.4 : ARIES-1238 * jpa-api 1.0.2 : ARIES-885 * jpa-container-context 1.0.3 : ARIES-885 * jpa-blueprint-aries 1.0.3 : ARIES-885 Please review and vote ! Cheers, Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Spi-Fly 1.0.1
+1 Dan On Jul 9, 2014, at 4:31 AM, Guillaume Nodet gno...@apache.org wrote: I'm starting a vote to release the spi-fly 1.0.1 bundles: org.apache.aries.spifly.core-internal org.apache.aries.spifly.dynamic.bundle org.apache.aries.spifly.static.bundle org.apache.aries.spifly.static.tool org.apache.aries.spifly.weaver-internal Staging repository: https://repository.apache.org/content/repositories/orgapachearies-1006/org/apache/aries/spifly/ Change log: Upgrade all modules to the released parent Change parent version to 2.0.0-SNAPSHOT [ARIES-1192] Upgrade to maven-bundle-plugin 2.4.1-SNAPSHOT [ARIES-1185] SPI Fly does not work with Java 8 Define the versioning plugin as an execution in the parent pom. It can thus be removed from ALL the other poms. Fix spi-fly tests spy fly build with java6, maven 3.2.1 [ARIES-1006] Upgrade to the new parent pom and OSGi 4.3.1 Convert file to use unix line delimiters. [ARIES-1156] SPI-Fly static tool does not work with Require-Capability bundles [ARIES-1156] SPI Fly fix syntax errors with static tool Manifest generation [SPI Fly] Fix for NPE. Additional example that shows a single bundle being a provider and consumer at the same time. Add Aries Versioning Plugin for the bundles in this project. Please review and vote, Cheers, Guillaume -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Apache Aries Parent 2.0.0
On Jul 3, 2014, at 7:51 AM, David Bosschaert david.bosscha...@gmail.com wrote: Again, as with the other batches I would only feel comfortable voting on this if there was some indication around what has changed. Would you be able to provide this please? Well, the new parent is a huge change. We previously had separate java5 and java6 parents. Much of the configuration for things like the versioning plugin were NOT in the parent and forced to be in every pom, etc… This release pretty much collapses the old “parent” hierarchy down to a single pom and configures as much as we can in there so that the other modules poms can be smaller have less cruft. Dan Thanks, David On 30 June 2014 19:10, Guillaume Nodet gno...@apache.org wrote: This is the first release of a set. It contains the parent pom in version 2.0.0 Staging repository available at https://repository.apache.org/content/repositories/orgapachearies-1002 [ ] +1 Release parent 2.0.0 [ ] -1 Do not Cheers, Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Blueprint
+1 Dan On Jun 30, 2014, at 2:13 PM, Guillaume Nodet gno...@apache.org wrote: Third set for Blueprint ... This release contains: * Blueprint API 1.0.1 * Parser 1.2.1 * Annotation API 1.0.1 * Annotation Impl 1.0.1 * CM 1.0.4 * Core 1.4.1 Staging repository at https://repository.apache.org/content/repositories/orgapachearies-1004 Cheers, Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release JMX Api 1.1.1 and Core 1.1.2
+1 Dan On Jun 30, 2014, at 2:14 PM, Guillaume Nodet gno...@apache.org wrote: 4th set ... This release contains: * JMX Api 1.1.1 * JMX Core 1.1.2 [ ] +1 Release those 2 bundles [ ] -1 Do not Cheers, Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Apache Aries Parent 2.0.0
+1 Dan On Jun 30, 2014, at 2:10 PM, Guillaume Nodet gno...@apache.org wrote: This is the first release of a set. It contains the parent pom in version 2.0.0 Staging repository available at https://repository.apache.org/content/repositories/orgapachearies-1002 [ ] +1 Release parent 2.0.0 [ ] -1 Do not Cheers, Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Aries Proxy Api 1.0.1 and Impl 1.0.3
+1 Dan On Jun 30, 2014, at 2:11 PM, Guillaume Nodet gno...@apache.org wrote: Second release vote ... This one contains the proxy api and impl. Staging repo at https://repository.apache.org/content/repositories/orgapachearies-1003 [ ] +1 Release Aries Proxy 1.0.1 and Impl 1.0.3 [ ] -1 Do not Cheers, Guillaume Nodet -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Release Apache Aries Parent 2.0.0
On Jul 1, 2014, at 2:47 AM, Holly Cummins holly.k.cumm...@googlemail.com wrote: (In this particular case the build failures are caused not because of interdependent bundles, but because nothing can find the 2.0.0-SNAPSHOT parent pom - I'd expect that to be available in the snapshots repository. Did we forget a deploy step?) The parent pom is kind of a catch 22. To find the SNAPSHOT version of the parent pom, you would need to add a repository entry to EVERY SINGLE pom that uses that parent. We don’t normally do that as we have that repository entry in the parent pom itself. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[RESULT][VOTE] Versioning plugin 0.3.0
We have 7 +1 votes. I’ll release the artifacts. Dan On Jun 11, 2014, at 1:00 PM, Daniel Kulp dk...@apache.org wrote: This is a vote to release 0.3.0 of the versioning plugin. The two major changes for this version are: 1) Update to support Java 8 2) Update to provide “skip” functionality/option and only to compare bundle package types so the plugin can be easily added to the parent pom. Staging are: https://repository.apache.org/content/repositories/orgapachearies-1001/ Tags: https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.versioning.checker-0.3.0/ https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.versioning.plugin-0.3.0/ Here is my +1 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Status of the build
On Jun 15, 2014, at 1:37 PM, Jean-Baptiste Onofré j...@nanthrax.net wrote: Hi, just an quick update: - I updated all modules to asm5 except ejb (I have to check the openejb version supporting asm5/java8 for the itests). - we have a full build (including itests) running with java6 and java7 - java8 just fails for ejb* itests (due to asm4/xbean usage) - I will add JPA 2.1 support tonight I would propose to prepare a set of releases for ASM5/Java8 support, in the following order: 1/ new parent pom 1.0.1 This new parent pom is a huge change over the way the previous parent poms were setup. I’m going to suggest calling it 2.0.0. Yes, it’s just a parent pom and pretty much irrelevant from a “version” standpoint, but it really is a big change. 2/ proxy-impl 1.0.3 3/ proxy-bundle 1.0.2 Here’s a question……. The proxy bundles (and a bunch of others), now have their ASM import range updated to [5,6) whereas the old versions were [4,5). This does mean they are not a “drop in” replacements for the older bundles. Does that have any impact on what the version number should be for these? Technically, the exported packages are completely compatible, but the imports are not. 4/ followed by in any order: application-converters application-tooling-repository-generator web-urlhandler blueprint-core blueprint-bundle blueprint-annotation-impl spi-fly* If there is no objection, I would like to start the releases as soon as the JPA 2.1 support is completed (so I propose Tuesday). Sure. The versioning plugin is “released”, just waiting for it to sync to central. Dan WDYT ? Regards JB On 06/13/2014 10:39 AM, Christian Schneider wrote: The normal aries build as well as the deploy build seem to be stable again. See https://builds.apache.org/view/A-D/view/Aries2/job/Aries/ The build with snapshot dependencies seems to continually fail. https://builds.apache.org/view/A-D/view/Aries2/job/AriesWithSnapshotDependencies/ The build fails during the application integration tests with a compile error. Unfortunately I do not fully understand what the failing build does exactly. Can someone explain how this build works and perhaps give some advice what is going wrong at the moment? I would like to do a build on my own system that replicates the same errors but have no idea how to do this. Maybe this build simply does not work anymore with the new integration tests as I now use .versionAsInProject in pax exam while I think the old tests used a different mechanism to determine the version of dependencies. Christian -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Status of the build
On Jun 13, 2014, at 4:39 AM, Christian Schneider ch...@die-schneider.net wrote: The normal aries build as well as the deploy build seem to be stable again. See https://builds.apache.org/view/A-D/view/Aries2/job/Aries/ The build with snapshot dependencies seems to continually fail. https://builds.apache.org/view/A-D/view/Aries2/job/AriesWithSnapshotDependencies/ The build fails during the application integration tests with a compile error. Unfortunately I do not fully understand what the failing build does exactly. Can someone explain how this build works and perhaps give some advice what is going wrong at the moment? I would like to do a build on my own system that replicates the same errors but have no idea how to do this. This is due to your changes for ARIES-1188. Those changes removed the ExtraOptions stuff (see your JIRA comment for why), but the builds for some of the modules are still relying on it. Once the scripts updated the poms to grab the latest snapshot of testutils (which has your changes), they fail to compile. Are the failing modules ones that have not yet been updated to pax-exam 3? Dan Maybe this build simply does not work anymore with the new integration tests as I now use .versionAsInProject in pax exam while I think the old tests used a different mechanism to determine the version of dependencies. Christian -- Christian Schneider http://www.liquid-reality.de Open Source Architect http://www.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[VOTE] Versioning plugin 0.3.0
This is a vote to release 0.3.0 of the versioning plugin. The two major changes for this version are: 1) Update to support Java 8 2) Update to provide “skip” functionality/option and only to compare bundle package types so the plugin can be easily added to the parent pom. Staging are: https://repository.apache.org/content/repositories/orgapachearies-1001/ Tags: https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.versioning.checker-0.3.0/ https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.versioning.plugin-0.3.0/ Here is my +1 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Version plugin and parent pom releases....
With the updates to the versioning stuff to support the newer ASM version and the updates to the plugin to allow it to be fully defined in the parent, do we think we’re ready to get the versioning plugin 0.3 release done? To start getting the fixes for the various modules released, we need to first get the versioning plugin released, then we need to get the parent released. Since that will take some time for votes and such, I’d like to get the ball rolling. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: current aries build issues
Everything should now compile with Java6 and Maven 3.2.1. Tests are another story…….. Haven’t re-checked with Java 7 and Java 8. Dan On Jun 5, 2014, at 1:14 PM, Daniel Kulp dk...@apache.org wrote: On Jun 5, 2014, at 12:22 PM, Samuel E Bratton sbrat...@us.ibm.com wrote: Hi, The Aries builds have been red for about the last 5 days. It looks like a couple of different people have been working on fixing it. Is this a coordinated effort? Are there a particular set of JIRAs where this is going on and can be followed? From what I can tell, there are (at least) three efforts around the builds: 1) Update to support Maven 3.1/3.2 - I’m primarily working on this. Mostly just trying to get things to compile/build with the newer Maven versions. Haven’t really targeted any tests yet. 2) Update to support Java 8 - this is kind of two parts: (a) build with java 8, and (b) tests run with java8. I believe JB is working on this. 3) Update to newer versions of Pax-exam - the version we were using is very ancient. We’re trying to get up to a more modern version. Christian has been working on this a bit. Some of the instability right now I *think* is related to #2. Getting everything updated to use the new ASM and not have various conflicts and such is taking bit of time. Any help getting tests to pass again would be great. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: current aries build issues
Well, good news is the Jenkins build is no longer red. :-) Dan On Jun 5, 2014, at 3:08 PM, j...@nanthrax.net wrote: Thanks Dan. I will work on the tests and pending issue as soon as I will back home (I'm in the train). I will keep you posted. Regards JB -- Jean-Baptiste Onofré jbono...@apache.org http://blog.nanthrax.net Talend - http://wwx.talend.com - Reply message - From: Daniel Kulp dk...@apache.org To: dev@aries.apache.org Subject: current aries build issues Date: Thu, Jun 5, 2014 8:06 pm Everything should now compile with Java6 and Maven 3.2.1. Tests are another story…….. Haven’t re-checked with Java 7 and Java 8. Dan On Jun 5, 2014, at 1:14 PM, Daniel Kulp dk...@apache.org wrote: On Jun 5, 2014, at 12:22 PM, Samuel E Bratton sbrat...@us.ibm.com wrote: Hi, The Aries builds have been red for about the last 5 days. It looks like a couple of different people have been working on fixing it. Is this a coordinated effort? Are there a particular set of JIRAs where this is going on and can be followed? From what I can tell, there are (at least) three efforts around the builds: 1) Update to support Maven 3.1/3.2 - I’m primarily working on this. Mostly just trying to get things to compile/build with the newer Maven versions. Haven’t really targeted any tests yet. 2) Update to support Java 8 - this is kind of two parts: (a) build with java 8, and (b) tests run with java8. I believe JB is working on this. 3) Update to newer versions of Pax-exam - the version we were using is very ancient. We’re trying to get up to a more modern version. Christian has been working on this a bit. Some of the instability right now I *think* is related to #2. Getting everything updated to use the new ASM and not have various conflicts and such is taking bit of time. Any help getting tests to pass again would be great. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Current build and org.eclipse.osgi version 3.8.2.v20130124-134944
On Jun 4, 2014, at 10:54 AM, Thomas Watson tjwat...@us.ibm.com wrote: Daniel Kulp has fixed the pom to point back to the 3.8.0 version so the build seems to work for me again. Thanks! I think the tests are failing, but at least we can build. One step at a time….. Dan Tom Thomas Watson---06/04/2014 08:06:44 AM---Hi David, I don't think that is the case here. This is blueprint and the pom was From: Thomas Watson/Austin/IBM@IBMUS To: dev@aries.apache.org Date: 06/04/2014 08:06 AM Subject: Re: Current build and org.eclipse.osgi version 3.8.2.v20130124-134944 Hi David, I don't think that is the case here. This is blueprint and the pom was updated to simply refer to a new version of equinox. I suspect it built locally because the developers local m2 cache likely has the version configured manually. But shouldn't the aries build be setup to work without manual configuration of the local m2 cache? Is there not an aries maven repo we can use to place the dependencies we need such as equinox? Tom David Bosschaert ---06/04/2014 01:49:04 AM---It might be downloading it from somewhere (using something like a http get task) and then using a sy From: David Bosschaert david.bosscha...@gmail.com To: dev@aries.apache.org dev@aries.apache.org Date: 06/04/2014 01:49 AM Subject: Re: Current build and org.eclipse.osgi version 3.8.2.v20130124-134944 It might be downloading it from somewhere (using something like a http get task) and then using a system dependency to use it in Maven. Not sure this is the way its used in this particular place, but I think the subsystems subproject had certain Eclipse dependencies set up this way. John Ross might be able to give more details... Cheers, David On 3 June 2014 20:37, Thomas Watson tjwat...@us.ibm.com wrote: With the latest from trunk I am no longer able to build because of a reference to org.eclipse:org.eclipse.osgi:jar:3.8.2.v20130124-134944 Which repo is this supposed to exist? Here is the error. Failed to execute goal on project org.apache.aries.blueprint.itests: Could not resolve dependencies for project org.apache.aries.blueprint:org.apache.aries.blueprint.itests:jar:1.0.2-SNAPSHOT: Could not find artifact org.eclipse:org.eclipse.osgi:jar:3.8.2.v20130124-134944 in EclipseLink Repo (http://download.eclipse.org/rt/eclipselink/maven.repo/) Tom -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Resolved] (ARIES-1203) Build error specifying old snapshot version for versioning.plugin
[ https://issues.apache.org/jira/browse/ARIES-1203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Kulp resolved ARIES-1203. Resolution: Fixed Assignee: Daniel Kulp Moved to the 0.2.0 release Build error specifying old snapshot version for versioning.plugin - Key: ARIES-1203 URL: https://issues.apache.org/jira/browse/ARIES-1203 Project: Aries Issue Type: Bug Components: Blueprint Reporter: Neil Richards Assignee: Daniel Kulp Attachments: ARIES-1203-blueprint-plugin-version-fix.patch I've been trying to compile the latest code from: https://svn.apache.org/repos/asf/aries/trunk (revision 1599264) following the Just build it - no Eclipse instructions: http://aries.apache.org/development/buildingaries.html The last step (mvn -Dmaven.test.skip=true install) is failing with the following error: [ERROR] Plugin org.apache.aries.versioning:org.apache.aries.versioning.plugin:0.2.0-SNAPSHOT or one of its dependencies could not be resolved: Failed to read artifact descriptor for org.apache.aries.versioning:org.apache.aries.versioning.plugin:jar:0.2.0-SNAPSHOT: Could not find artifact org.apache.aries.versioning:org.apache.aries.versioning.plugin:pom:0.2.0-SNAPSHOT in apache.snapshots (https://repository.apache.org/content/groups/snapshots-group) - [Help 1] -- This message was sent by Atlassian JIRA (v6.2#6252)
[RESULT][VOTE] Versioning plugin 0.2.0
For the record, my +1 (I seemed to have forgotten that). We have 3 binding votes and 1 non-binding vote. This vote passes. I’ll promote the artifact and then start updating poms once it’s synced to central. Dan On May 25, 2014, at 8:44 AM, Daniel Kulp dk...@apache.org wrote: With my own vote, I only have two votes. Can I get another PMC member to look at this? Thanks! Dan On May 19, 2014, at 1:15 PM, Daniel Kulp dk...@apache.org wrote: This is a vote to release 0.2.0 of the versioning plugin. The main change for this plugin is to support both Maven 3.0.x and 3.1.x/3.2.x by flipping from using Aether directly to using the Maven provided API’s. When released and rolled out throughout the rest of the build, we should hopefully be able to build Aries with a more modern version of Maven. Tag: https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.versioning-0.2.0/ Staging repo: https://repository.apache.org/content/repositories/orgapachearies-1000/org/apache/aries/versioning/ -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Versioning plugin 0.2.0
With my own vote, I only have two votes. Can I get another PMC member to look at this? Thanks! Dan On May 19, 2014, at 1:15 PM, Daniel Kulp dk...@apache.org wrote: This is a vote to release 0.2.0 of the versioning plugin. The main change for this plugin is to support both Maven 3.0.x and 3.1.x/3.2.x by flipping from using Aether directly to using the Maven provided API’s. When released and rolled out throughout the rest of the build, we should hopefully be able to build Aries with a more modern version of Maven. Tag: https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.versioning-0.2.0/ Staging repo: https://repository.apache.org/content/repositories/orgapachearies-1000/org/apache/aries/versioning/ -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Welcome our newest committers....
The Aries PMC has voted in two new committers: Jean-Baptiste Onofré Christian Schneider Congratulations to them and many thanks for the contributions! -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[VOTE] Versioning plugin 0.2.0
This is a vote to release 0.2.0 of the versioning plugin. The main change for this plugin is to support both Maven 3.0.x and 3.1.x/3.2.x by flipping from using Aether directly to using the Maven provided API’s. When released and rolled out throughout the rest of the build, we should hopefully be able to build Aries with a more modern version of Maven. Tag: https://svn.apache.org/repos/asf/aries/tags/org.apache.aries.versioning-0.2.0/ Staging repo: https://repository.apache.org/content/repositories/orgapachearies-1000/org/apache/aries/versioning/ -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Resolved] (ARIES-1186) Upgrade proxy-impl to ASM 5 for Java 8 support
[
https://issues.apache.org/jira/browse/ARIES-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved ARIES-1186.
Resolution: Fixed
Fix Version/s: proxy-impl-1.0.3
Assignee: Daniel Kulp
Pull request pulled
Upgrade proxy-impl to ASM 5 for Java 8 support
--
Key: ARIES-1186
URL: https://issues.apache.org/jira/browse/ARIES-1186
Project: Aries
Issue Type: Improvement
Components: Proxy
Affects Versions: proxy-impl-1.0.2
Reporter: Harald Wellmann
Assignee: Daniel Kulp
Priority: Critical
Fix For: proxy-impl-1.0.3
Aries Proxy does not work under Java 8, since it depends on ASM 4 which does
not support Java 8.
This is currently a blocker for working with Karaf 3.0.1 under Java 8. (Karaf
contains Aries Proxy Impl 1.0.2).
Upgrading to ASM 5.0.2 requires changing a few {{super()}} calls in Aries
subclasses of ASM classes.
I tried a local build of Aries Proxy Impl 1.0.3-SNAPSHOT with these changes,
and the result seems to be ok for Karaf.
The larger part of the issue on Aries side is the dependency on a prehistoric
version of Pax Exam which depends on Pax Runner (with additional
configuration tweaks from Aries) which does not support Java 8 either, so I
haven't been able to run the Proxy integration tests.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (ARIES-1186) Upgrade proxy-impl to ASM 5 for Java 8 support
[
https://issues.apache.org/jira/browse/ARIES-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp updated ARIES-1186:
---
Summary: Upgrade proxy-impl to ASM 5 for Java 8 support (was: Upgrade to
ASM 5 for Java 8 support)
Upgrade proxy-impl to ASM 5 for Java 8 support
--
Key: ARIES-1186
URL: https://issues.apache.org/jira/browse/ARIES-1186
Project: Aries
Issue Type: Improvement
Components: Proxy
Affects Versions: proxy-impl-1.0.2
Reporter: Harald Wellmann
Priority: Critical
Fix For: proxy-impl-1.0.3
Aries Proxy does not work under Java 8, since it depends on ASM 4 which does
not support Java 8.
This is currently a blocker for working with Karaf 3.0.1 under Java 8. (Karaf
contains Aries Proxy Impl 1.0.2).
Upgrading to ASM 5.0.2 requires changing a few {{super()}} calls in Aries
subclasses of ASM classes.
I tried a local build of Aries Proxy Impl 1.0.3-SNAPSHOT with these changes,
and the result seems to be ok for Karaf.
The larger part of the issue on Aries side is the dependency on a prehistoric
version of Pax Exam which depends on Pax Runner (with additional
configuration tweaks from Aries) which does not support Java 8 either, so I
haven't been able to run the Proxy integration tests.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (ARIES-915) The CM module for managed-service-factory does not perform the update correct with embedded managed-properties
[
https://issues.apache.org/jira/browse/ARIES-915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Kulp resolved ARIES-915.
---
Resolution: Fixed
Fix Version/s: blueprint-cm-1.0.4
Assignee: Daniel Kulp
Pull request applied.
Note: in future, please make sure all non-aries snapshots are eliminated before
making a pull request.
The CM module for managed-service-factory does not perform the update correct
with embedded managed-properties
--
Key: ARIES-915
URL: https://issues.apache.org/jira/browse/ARIES-915
Project: Aries
Issue Type: Bug
Components: Blueprint
Affects Versions: 0.3
Reporter: Christoph Läubrich
Assignee: Daniel Kulp
Fix For: blueprint-cm-1.0.4
Attachments: ManagedServiceFactoryTest.java
I'm using the following test case:
{code:xml}?xml version=1.0 encoding=UTF-8?
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:cm=http://aries.apache.org/blueprint/xmlns/blueprint-cm/v1.1.0;
cm:managed-service-factory id=testfactory
factory-pid=testfactory interface=test.FactoryTest
auto-export=all-classes
cm:managed-component
class=test.FactoryTest
init-method=init
cm:managed-properties persistent-id=
update-strategy=component-managed update-method=update/
/cm:managed-component
/cm:managed-service-factory
/blueprint{code}
The testclass just print out to the log:{code:java}public class FactoryTest {
private static final Logger LOG =
LoggerFactory.getLogger(FactoryTest.class);
public FactoryTest() {
LOG.info({}: FactoryTest.FactoryTest(),
System.identityHashCode(this));
}
public void init() {
// LOG.info({}: FactoryTest.init(), System.identityHashCode(this));
}
public void update(MapString, ? props) {
LOG.info({}: FactoryTest.update() props = {},
System.identityHashCode(this), props);
}
}{code}
The logfile looks like this, I have reodereded the log output so each
instance is one block:{code}karaf@root log:display
2012-09-04 09:36:30,660 | INFO | rint Extender: 2 | FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.FactoryTest()
2012-09-04 09:36:30,675 | INFO | Thread-91| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo4,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-4.cfg,
service.pid=testfactory.8e97399a-940e-49c3-ae75-3e720951774a}
2012-09-04 09:36:30,677 | INFO | Thread-92| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo3,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-3.cfg,
service.pid=testfactory.3c44fb7d-6aa2-48e6-8050-1fac3c56f9b1}
2012-09-04 09:36:30,688 | INFO | Thread-93| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo2,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-2.cfg,
service.pid=testfactory.139e87cd-7f73-4dab-8289-af5e6be91ba5}
2012-09-04 09:36:30,697 | INFO | Thread-94| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo2,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-2.cfg,
service.pid=testfactory.139e87cd-7f73-4dab-8289-af5e6be91ba5}
2012-09-04 09:36:30,699 | INFO | Thread-96| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo1,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-1.cfg,
service.pid=testfactory.c5b988ec-8747-4354-84b4-5613a60b6ab1}
2012-09-04 09:36:30,703 | INFO | Thread-95| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 30590872: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo3,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-3.cfg,
service.pid=testfactory.3c44fb7d-6aa2-48e6-8050-1fac3c56f9b1}
2012-09-04 09:36:30,703 | INFO | Thread-95| FactoryTest
| 139 - test - 0.0.4.SNAPSHOT | 7131715: FactoryTest.update() props =
{service.factoryPid=testfactory, hallo=hallo3,
felix.fileinstall.filename=file:/tmp/apache-karaf-2.2.8/etc/testfactory-3.cfg,
service.pid=testfactory.3c44fb7d-6aa2-48e6-8050-1fac3c56f9b1}
2012-09-04 09:36:30,668 | INFO | rint Extender: 2
Re: versioning plugin release for Maven 3.1+
Ok. I’ve update the plugin to work with 3.0.x as well as 3.1 and 3.2 by just using the Maven API’s instead of using Aether directly. I also flipped it to using the Maven plugin annotations instead of the javadoc type things. Possibly a bit cleaner. Anyway, any objections now to getting it released? If not, I’ll start the 0.2 release on Monday. (actually, should we just call it 1.0?) Dan On May 12, 2014, at 3:14 PM, David Bosschaert david.bosscha...@gmail.com wrote: FWIW - I still do most of my work on Maven 3.0.5 as some of the projects I work on don't work with 3.1. They might work with 3.2 but I haven't tried that yet. One other thing to mention is that an extension is being proposed to the maven-bundle-plugin that supports semantic versioning. That implementation is using the bnd baselining under the hood, which supports semantic versioning a little better than the Aries versioning plugin AFAIK... See here: https://issues.apache.org/jira/browse/FELIX-4512 Best regards, David On 12 May 2014 20:59, Daniel Kulp dk...@apache.org wrote: I just updated the versioning plugin to use the org.eclipse version of Aether. This allows it to work with Maven 3.1+, but means it won’t work with Maven 3.0.x. We could do a lot more work to get it working for both, but I’m not sure it’s worth it. Would folks be OK with me doing a release of the plugin for Maven 3.1+ and start updating the various poms to use that version? I hate having to drop to the older Maven just for Aries. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
versioning plugin release for Maven 3.1+
I just updated the versioning plugin to use the org.eclipse version of Aether. This allows it to work with Maven 3.1+, but means it won’t work with Maven 3.0.x. We could do a lot more work to get it working for both, but I’m not sure it’s worth it. Would folks be OK with me doing a release of the plugin for Maven 3.1+ and start updating the various poms to use that version? I hate having to drop to the older Maven just for Aries. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Accepting pull requests for Aries from Github
On Mar 28, 2014, at 4:35 AM, dav...@apache.org wrote: That's great - but I'm wondering how this works from an IP-flow point of view. I guess that by attaching a patch to a JIRA issue one formally donates the code to Apache. But by merging a github pull request you take a few commits from someone's own fork and add this to the main repo. I guess you could view the creation of the pull request itself as a statement by the committer that (s)he wants to donate this code? Yea….. pretty much that’s it.They’ve had to specifically click on a few things to have github initiate the pull request which is enough for us to say they intended to contribute their changes to Apache. That said, somethings still would apply. If the change is “huge”, we’d still want an ICLA and likely a code grant on file. But for the simple patches and updates and such, a pull request is adequate, especially now that the pull requests are ending up on our JIRA and on the dev lists so there is a good record. Note: I had INFRA update the github mirror so the trunk branch is the default instead of whatever ancient branch it had been using. Should make forking and such from github easier. Dan Anyway - do you know of a formal document somewhere where interaction with github (or other code repos) is defined? Cheers, David On 27 March 2014 19:31, Daniel Kulp dk...@apache.org wrote: On Mar 27, 2014, at 8:05 AM, dav...@apache.org wrote: Hi all, I noticed that there are a few pull requests on Aries at github [1]. I was wondering, can we just apply these, or must they be physically attached to JIRA issues to correctly follow IP rules? I noticed that e.g. [2] does mention the pull request in the comments... Just wondering what the process should be... Pulling the pull requests directly is fine. Many projects have started preferring that. When you do, it's sometimes best to amend/edit the commit log to include something like This closes #2 so the pull request will close automatically when you commit. Dan Cheers, David [1] https://github.com/apache/aries/pulls [2] https://issues.apache.org/jira/browse/ARIES-1164 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Accepting pull requests for Aries from Github
On Mar 28, 2014, at 12:09 PM, dav...@apache.org wrote: Cool - thanks for the explanation. In terms of Aries, since we're still using SVN, can I actually push commits to git directly? FWIW I tried pushing to git://git.apache.org/aries.git and https://git-wip-us.apache.org/repos/asf/aries.git but they don't seem to work... Or, should I, since Aries uses SVN, commit these pull requests via diff patches in SVN directly? Well, they have to go in via SVN one way or another. If you use SVN for development, then you would need to grab the “diff patch” and apply it and commit it. That certainly works. If you use the git-svn integration for your development, then you can do a direct git pull and then git svn dcommit to get it into SVN. Dan Cheers, David On 28 March 2014 13:42, Daniel Kulp dk...@apache.org wrote: On Mar 28, 2014, at 4:35 AM, dav...@apache.org wrote: That's great - but I'm wondering how this works from an IP-flow point of view. I guess that by attaching a patch to a JIRA issue one formally donates the code to Apache. But by merging a github pull request you take a few commits from someone's own fork and add this to the main repo. I guess you could view the creation of the pull request itself as a statement by the committer that (s)he wants to donate this code? Yea. pretty much that's it.They've had to specifically click on a few things to have github initiate the pull request which is enough for us to say they intended to contribute their changes to Apache. That said, somethings still would apply. If the change is huge, we'd still want an ICLA and likely a code grant on file. But for the simple patches and updates and such, a pull request is adequate, especially now that the pull requests are ending up on our JIRA and on the dev lists so there is a good record. Note: I had INFRA update the github mirror so the trunk branch is the default instead of whatever ancient branch it had been using. Should make forking and such from github easier. Dan Anyway - do you know of a formal document somewhere where interaction with github (or other code repos) is defined? Cheers, David On 27 March 2014 19:31, Daniel Kulp dk...@apache.org wrote: On Mar 27, 2014, at 8:05 AM, dav...@apache.org wrote: Hi all, I noticed that there are a few pull requests on Aries at github [1]. I was wondering, can we just apply these, or must they be physically attached to JIRA issues to correctly follow IP rules? I noticed that e.g. [2] does mention the pull request in the comments... Just wondering what the process should be... Pulling the pull requests directly is fine. Many projects have started preferring that. When you do, it's sometimes best to amend/edit the commit log to include something like This closes #2 so the pull request will close automatically when you commit. Dan Cheers, David [1] https://github.com/apache/aries/pulls [2] https://issues.apache.org/jira/browse/ARIES-1164 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: Accepting pull requests for Aries from Github
On Mar 27, 2014, at 8:05 AM, dav...@apache.org wrote: Hi all, I noticed that there are a few pull requests on Aries at github [1]. I was wondering, can we just apply these, or must they be physically attached to JIRA issues to correctly follow IP rules? I noticed that e.g. [2] does mention the pull request in the comments... Just wondering what the process should be… Pulling the pull requests directly is fine. Many projects have started preferring that. When you do, it’s sometimes best to amend/edit the commit log to include something like “This closes #2” so the pull request will close automatically when you commit. Dan Cheers, David [1] https://github.com/apache/aries/pulls [2] https://issues.apache.org/jira/browse/ARIES-1164 -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Blueprint 1.4.0
We have 6 +1 votes (4 binding). This vote passes. Dan On Dec 17, 2013, at 4:27 PM, Daniel Kulp dk...@apache.org wrote: This is a vote to release blueprint-parser 1.2.0 and blueprint-core 1.4.0. There are two major things in this release: 1) ARIES-1141 - custom namespace extensions to allow a service reference to implement multiple interfaces 2) A couple of fixes to blueprint-core to get our itests passing again. These include memory leak fixes and service reference fixes. Basically, the most recent releases of blueprint-core have been broken and one purpose of this release is to get a release out that fixes these regressions. Staging area: https://repository.apache.org/content/repositories/orgapachearies-055/ Tags: http://svn.apache.org/repos/asf/aries/tags/blueprint-parser-1.2.0/ http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.core-1.4.0/ Here’s my +1. Vote will be open for 72 hours. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[RESULT] [VOTE] Transaction manager 1.1 and jdbc 2.0
We have 5 +1 votes (4 binding). This vote passes. Dan On Dec 17, 2013, at 4:30 PM, Daniel Kulp dk...@apache.org wrote: This is a vote to release updates for the transaction manager and jdbc bundle. There were several fixes made many months ago that have never been released. We should get the release out to the users. The current jdbc release is actually unusable for many use cases so this update should provide a bundle that is much more widely usable. Staging area: https://repository.apache.org/content/repositories/orgapachearies-057/ Tags: http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.transaction.manager-1.1.0/ http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.transaction.jdbc-2.0.0/ Here is my +1. Vote open for 72h. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: [VOTE] Transaction manager 1.1 and jdbc 2.0
On Dec 18, 2013, at 3:09 AM, Felix Meschberger fmesc...@adobe.com wrote: Hi Daniel Do you have references to the issues fixed, actually ? According to svn log: [ARIES-1070] Provide a correct JDBC wrapping for XA data sources [ARIES-1069] Provide a single interface for better integration of the TransactionManager with other low-level components Dan I cannot find the transaction-manager-1.1.0 or transaction-jdbc-2.0.0 version labels in JIRA. Thanks. Felix Am 17.12.2013 um 22:30 schrieb Daniel Kulp dk...@apache.org: This is a vote to release updates for the transaction manager and jdbc bundle. There were several fixes made many months ago that have never been released. We should get the release out to the users. The current jdbc release is actually unusable for many use cases so this update should provide a bundle that is much more widely usable. Staging area: https://repository.apache.org/content/repositories/orgapachearies-057/ Tags: http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.transaction.manager-1.1.0/ http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.transaction.jdbc-2.0.0/ Here is my +1. Vote open for 72h. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[VOTE] Blueprint 1.4.0
This is a vote to release blueprint-parser 1.2.0 and blueprint-core 1.4.0. There are two major things in this release: 1) ARIES-1141 - custom namespace extensions to allow a service reference to implement multiple interfaces 2) A couple of fixes to blueprint-core to get our itests passing again. These include memory leak fixes and service reference fixes. Basically, the most recent releases of blueprint-core have been broken and one purpose of this release is to get a release out that fixes these regressions. Staging area: https://repository.apache.org/content/repositories/orgapachearies-055/ Tags: http://svn.apache.org/repos/asf/aries/tags/blueprint-parser-1.2.0/ http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.blueprint.core-1.4.0/ Here’s my +1. Vote will be open for 72 hours. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[VOTE] Transaction manager 1.1 and jdbc 2.0
This is a vote to release updates for the transaction manager and jdbc bundle. There were several fixes made many months ago that have never been released. We should get the release out to the users. The current jdbc release is actually unusable for many use cases so this update should provide a bundle that is much more widely usable. Staging area: https://repository.apache.org/content/repositories/orgapachearies-057/ Tags: http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.transaction.manager-1.1.0/ http://svn.apache.org/repos/asf/aries/tags/org.apache.aries.transaction.jdbc-2.0.0/ Here is my +1. Vote open for 72h. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Couple of builds tomorrow
Guillaume seems to have fixed the last blueprint itest failure with the latest snapshot. I’d like to go ahead and push out a blueprint-core release that includes the fixes. The last two releases (1.2/1.3) seem to be “broken” in that they have some memory leaks and bugs that were not properly caught by the itests. Basically, I’d like to make sure the current release can at least pass our own tests. Guillaume also mentioned that transaction-manager and transaction-jdbc have had some big changes (back in May) but haven’t yet been released. I’ll likely go ahead and release those as well. Any thoughts or objections, please speak now. :-) -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
Re: blueprint itest failures...
On Dec 13, 2013, at 7:48 PM, Holly Cummins holly.k.cumm...@googlemail.com wrote: Another thing that concerns me about this is that it's exactly the sort of problem which the 'withlatestanapshot' build is supposed to catch. It clearly hasn't caught it, so either it's not working as I hoped, or something about the uber bundle makes things pass even if we're running all the latest code. I had all kinds of issues trying to get the snapshot versions tested. I think some of them were Maven bugs, but we also cannot move to Maven 3.1 yet due to the version plugin. It should be that the main build tests the released versions, so über-1.0 and its back-level constituents. Then the snapshot build tests the latest code, which is uber-snapshot and snapshots of each included bundle - ie, the latest code of everything. Personally, I don’t think the itests should ever be testing the released versions. That doesn’t make a whole lot of sense. As soon as I add a new test, that would cause the build to break. The purpose of the itests is to make sure the stuff we’re working on doesn’t break anything. If the snapshot build is actually getting that coverage I think it is, and things are failing anyway with individual bundles, I wonder if we need to run tests with both uber and individual bundles? Or get rid of the uber bundles. That’s the direction I’d prefer going. I’d certainly prefer not having to do double the amount of release and test work. Dan Holly On 13 Dec 2013, at 20:36, Daniel Kulp dk...@apache.org wrote: While writing a test for ARIES-1141, I discovered that the blueprint-itests were pulling in “org.apache.aries.blueprint/1.0.0” which is the older “big blueprint bundle” instead of the individual “core”, “cm”, etc… bundles. There are several issues: 1) Since karaf and everything has been updated to using the littler bundles, this means we aren’t testing what people are using 2) We haven’t done a “release” of the big bundle since 1.0.0, but there have been releases of the littler things. This means the littler things haven’t had the itests run with them. 3) I flipped the itests to use the little bundles and now we have couple of test failures. Running org.apache.aries.blueprint.itests.TestRegistrationListener Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.968 sec FAILURE! Running org.apache.aries.blueprint.itests.BlueprintContainerTest Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 48.701 sec FAILURE! org.apache.aries.blueprint.itests.ASMMultiBundleTest also fails semi-randomly. That may be the sync vs non-sync startup issues. Need to double check that. If you have some time, please try taking a look. It looks like we may have broken a bunch of things through the various releases and that obviously concerns me. The BlueprintContainerTest is in testScheduledExecMemoryLeak which kind of scares me. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
[jira] [Commented] (ARIES-1140) Injected java.lang.reflect.Proxy implements only single interface
[
https://issues.apache.org/jira/browse/ARIES-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13847598#comment-13847598
]
Daniel Kulp commented on ARIES-1140:
Actually, I *THINK* this might be doable if we allow the
ext:proxy-method=greedy on the reference element as well as just the
reference-list. Right now, it's only allowed on the reference-list. If the
service is registered with multiple interfaces, if you use a reference-list
and set the proxy-method to greedy, I believe it would create proxies that
implement all the interfaces. I need to double check that, but it looks that
way in the code. I'm not sure why the greedy is not allowed for reference.
Injected java.lang.reflect.Proxy implements only single interface
-
Key: ARIES-1140
URL: https://issues.apache.org/jira/browse/ARIES-1140
Project: Aries
Issue Type: Improvement
Components: Proxy
Affects Versions: proxy-impl-1.0.1
Reporter: Andrei Shakirin
Hi,
I have a problem in using Blueprint together with CXF and Karaf projects. The
use case is quite trivial: I inject OSGi service into java class source. This
OSGi service is exposed by declared jax-ws client.
1. Blueprint configuration exporting service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cxf=http://cxf.apache.org/blueprint/core;
xmlns:jaxws=http://cxf.apache.org/blueprint/jaxws;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://cxf.apache.org/blueprint/jaxws
http://cxf.apache.org/schemas/blueprint/jaxws.xsd
http://cxf.apache.org/blueprint/core
http://cxf.apache.org/schemas/blueprint/core.xsd
jaxws:client id=crmClient
xmlns:serviceNamespace=http://services.talend.org/CRMService;
serviceClass=org.talend.services.crmservice.CRMService
serviceName=serviceNamespace:CRMServiceProvider
endpointName=serviceNamespace:CRMServicePort
address=http://localhost:8080/service/CRMService/
service ref=crmClient
interface=org.talend.services.crmservice.CRMService /
/blueprint
{code}
Where org.talend.services.crmservice.CRMService is generated jax-ws interface
2. Blueprint configuration importing service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd;
reference id=CRMServiceClient
interface=org.talend.services.crmservice.CRMService /
bean id=TestClass
class=org.talend..demo.TestClass
property name=crms ref=CRMServiceClient /
/bean
/blueprint
{code}
3. Code in TestClass:
{code:java}
...
private CRMService crms;
public void setCrms(CRMService crms) {
this.crms = crms;
System.out.println(crms.getClass());
System.out.println(crms.toString());
System.out.println(crms instanceof BindingProvider);
}
...
{code}
Problem:
The problem is that crms proxy, injected into TestClass, implements only
org.talend.services.crmservice.CRMService.
The proxy calls methods of org.apache.cxf.jaxws.JaxWsClientProxy which
implements javax.xml.ws.BindingProvider interface. I expect that crms proxy
also implements javax.xml.ws.BindingProvider, but it is not the case. I have
the following output from setCrms:
class com.sun.proxy.$Proxy151
org.apache.cxf.jaxws.JaxWsClientProxy@c3f8b42
false
The proxy calls toString() method of JaxWsClientProxy, but it is not instance
of BindingProvider interface. The problem is that this proxy is not jax-ws
compatible, because spec requires that all proxies implementing
BindingProvider interface.
Interesting that Spring DM proxy hasn't such problem: it implements
BindingProvider interface in this scenario.
Is it Blueprint problem? (seems to be true for me)
Is there way to fix this in Blueprint?
Regards,
Andrei.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Commented] (ARIES-1140) Injected java.lang.reflect.Proxy implements only single interface
[
https://issues.apache.org/jira/browse/ARIES-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13847604#comment-13847604
]
Daniel Kulp commented on ARIES-1140:
Oh, right. reference-list allows it cause the list only represents the actual
live services so we can get that information. For reference, the service
might not be there yet. That makes sense.
Yea, I'm thinking adding an element to the ext namespace for adding
additional interfaces onto the reference proxy may be the best/simplest way to
go.
Injected java.lang.reflect.Proxy implements only single interface
-
Key: ARIES-1140
URL: https://issues.apache.org/jira/browse/ARIES-1140
Project: Aries
Issue Type: Improvement
Components: Proxy
Affects Versions: proxy-impl-1.0.1
Reporter: Andrei Shakirin
Hi,
I have a problem in using Blueprint together with CXF and Karaf projects. The
use case is quite trivial: I inject OSGi service into java class source. This
OSGi service is exposed by declared jax-ws client.
1. Blueprint configuration exporting service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cxf=http://cxf.apache.org/blueprint/core;
xmlns:jaxws=http://cxf.apache.org/blueprint/jaxws;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://cxf.apache.org/blueprint/jaxws
http://cxf.apache.org/schemas/blueprint/jaxws.xsd
http://cxf.apache.org/blueprint/core
http://cxf.apache.org/schemas/blueprint/core.xsd
jaxws:client id=crmClient
xmlns:serviceNamespace=http://services.talend.org/CRMService;
serviceClass=org.talend.services.crmservice.CRMService
serviceName=serviceNamespace:CRMServiceProvider
endpointName=serviceNamespace:CRMServicePort
address=http://localhost:8080/service/CRMService/
service ref=crmClient
interface=org.talend.services.crmservice.CRMService /
/blueprint
{code}
Where org.talend.services.crmservice.CRMService is generated jax-ws interface
2. Blueprint configuration importing service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd;
reference id=CRMServiceClient
interface=org.talend.services.crmservice.CRMService /
bean id=TestClass
class=org.talend..demo.TestClass
property name=crms ref=CRMServiceClient /
/bean
/blueprint
{code}
3. Code in TestClass:
{code:java}
...
private CRMService crms;
public void setCrms(CRMService crms) {
this.crms = crms;
System.out.println(crms.getClass());
System.out.println(crms.toString());
System.out.println(crms instanceof BindingProvider);
}
...
{code}
Problem:
The problem is that crms proxy, injected into TestClass, implements only
org.talend.services.crmservice.CRMService.
The proxy calls methods of org.apache.cxf.jaxws.JaxWsClientProxy which
implements javax.xml.ws.BindingProvider interface. I expect that crms proxy
also implements javax.xml.ws.BindingProvider, but it is not the case. I have
the following output from setCrms:
class com.sun.proxy.$Proxy151
org.apache.cxf.jaxws.JaxWsClientProxy@c3f8b42
false
The proxy calls toString() method of JaxWsClientProxy, but it is not instance
of BindingProvider interface. The problem is that this proxy is not jax-ws
compatible, because spec requires that all proxies implementing
BindingProvider interface.
Interesting that Spring DM proxy hasn't such problem: it implements
BindingProvider interface in this scenario.
Is it Blueprint problem? (seems to be true for me)
Is there way to fix this in Blueprint?
Regards,
Andrei.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
[jira] [Created] (ARIES-1141) Allow reference to reference (and filter) services with multiple interfaces
Daniel Kulp created ARIES-1141: -- Summary: Allow reference to reference (and filter) services with multiple interfaces Key: ARIES-1141 URL: https://issues.apache.org/jira/browse/ARIES-1141 Project: Aries Issue Type: Improvement Components: Blueprint Reporter: Daniel Kulp Assignee: Daniel Kulp Related to ARIES-1140. A service can be registered with multiple classes/interfaces. However, a reference can only use a single interface for the lookup. In some cases, it would be good to provide (via the ext namespace) a way for a reference to no only implement those additional interfaces, but also restrict the reference to services that implement all of the extra interfaces. -- This message was sent by Atlassian JIRA (v6.1.4#6159)
[jira] [Commented] (ARIES-1140) Injected java.lang.reflect.Proxy implements only single interface
[
https://issues.apache.org/jira/browse/ARIES-1140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13847702#comment-13847702
]
Daniel Kulp commented on ARIES-1140:
I've pulled the enhancement request out of this into a new JIRA that can be
tracked as part of the blueprint component since that part is blueprint and not
proxy.
Injected java.lang.reflect.Proxy implements only single interface
-
Key: ARIES-1140
URL: https://issues.apache.org/jira/browse/ARIES-1140
Project: Aries
Issue Type: Improvement
Components: Proxy
Affects Versions: proxy-impl-1.0.1
Reporter: Andrei Shakirin
Hi,
I have a problem in using Blueprint together with CXF and Karaf projects. The
use case is quite trivial: I inject OSGi service into java class source. This
OSGi service is exposed by declared jax-ws client.
1. Blueprint configuration exporting service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:cxf=http://cxf.apache.org/blueprint/core;
xmlns:jaxws=http://cxf.apache.org/blueprint/jaxws;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd
http://cxf.apache.org/blueprint/jaxws
http://cxf.apache.org/schemas/blueprint/jaxws.xsd
http://cxf.apache.org/blueprint/core
http://cxf.apache.org/schemas/blueprint/core.xsd
jaxws:client id=crmClient
xmlns:serviceNamespace=http://services.talend.org/CRMService;
serviceClass=org.talend.services.crmservice.CRMService
serviceName=serviceNamespace:CRMServiceProvider
endpointName=serviceNamespace:CRMServicePort
address=http://localhost:8080/service/CRMService/
service ref=crmClient
interface=org.talend.services.crmservice.CRMService /
/blueprint
{code}
Where org.talend.services.crmservice.CRMService is generated jax-ws interface
2. Blueprint configuration importing service:
{code:xml}
blueprint xmlns=http://www.osgi.org/xmlns/blueprint/v1.0.0;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation=http://www.osgi.org/xmlns/blueprint/v1.0.0
http://www.osgi.org/xmlns/blueprint/v1.0.0/blueprint.xsd;
reference id=CRMServiceClient
interface=org.talend.services.crmservice.CRMService /
bean id=TestClass
class=org.talend..demo.TestClass
property name=crms ref=CRMServiceClient /
/bean
/blueprint
{code}
3. Code in TestClass:
{code:java}
...
private CRMService crms;
public void setCrms(CRMService crms) {
this.crms = crms;
System.out.println(crms.getClass());
System.out.println(crms.toString());
System.out.println(crms instanceof BindingProvider);
}
...
{code}
Problem:
The problem is that crms proxy, injected into TestClass, implements only
org.talend.services.crmservice.CRMService.
The proxy calls methods of org.apache.cxf.jaxws.JaxWsClientProxy which
implements javax.xml.ws.BindingProvider interface. I expect that crms proxy
also implements javax.xml.ws.BindingProvider, but it is not the case. I have
the following output from setCrms:
class com.sun.proxy.$Proxy151
org.apache.cxf.jaxws.JaxWsClientProxy@c3f8b42
false
The proxy calls toString() method of JaxWsClientProxy, but it is not instance
of BindingProvider interface. The problem is that this proxy is not jax-ws
compatible, because spec requires that all proxies implementing
BindingProvider interface.
Interesting that Spring DM proxy hasn't such problem: it implements
BindingProvider interface in this scenario.
Is it Blueprint problem? (seems to be true for me)
Is there way to fix this in Blueprint?
Regards,
Andrei.
--
This message was sent by Atlassian JIRA
(v6.1.4#6159)
blueprint itest failures...
While writing a test for ARIES-1141, I discovered that the blueprint-itests were pulling in “org.apache.aries.blueprint/1.0.0” which is the older “big blueprint bundle” instead of the individual “core”, “cm”, etc… bundles. There are several issues: 1) Since karaf and everything has been updated to using the littler bundles, this means we aren’t testing what people are using 2) We haven’t done a “release” of the big bundle since 1.0.0, but there have been releases of the littler things. This means the littler things haven’t had the itests run with them. 3) I flipped the itests to use the little bundles and now we have couple of test failures. Running org.apache.aries.blueprint.itests.TestRegistrationListener Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.968 sec FAILURE! Running org.apache.aries.blueprint.itests.BlueprintContainerTest Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 48.701 sec FAILURE! org.apache.aries.blueprint.itests.ASMMultiBundleTest also fails semi-randomly. That may be the sync vs non-sync startup issues. Need to double check that. If you have some time, please try taking a look. It looks like we may have broken a bunch of things through the various releases and that obviously concerns me. The BlueprintContainerTest is in testScheduledExecMemoryLeak which kind of scares me. -- Daniel Kulp dk...@apache.org - http://dankulp.com/blog Talend Community Coder - http://coders.talend.com
