That's brilliant news Aled, I'm just catching up with this now, and first of all read the email you sent describing the problem, and it sounded like a real nightmare. Glad to hear you've got it working. Congrats on solving it! What a fix though - `javax.xml.bind*;version=!,` would confuse the life out of me if I came across it in a pom. If you're raising a PR for this can you put comments that explain it a bit, and maybe link to the list archive of your email?
I remember wrestling with `dependency="true"` before now myself. That's a nice explanation. Best, Geoff On Thu, 5 Dec 2019 at 23:14, Aled Sage <[email protected]> wrote: > Hi all, > > Good news - I have it working. I need to do some more testing, and need > to look at releasing winrm4j 0.8.0. > > I got some great pointers from the CXF mailing list (thanks Alexey > Markevich!) [1]. > > The solution is for winrm4j to include: > > <plugin> > <groupId>org.apache.felix</groupId> > <artifactId>maven-bundle-plugin</artifactId> > <configuration> > <instructions> > <Import-Package> > javax.xml.bind*;version=!, > * > </Import-Package> > </instructions> > </configuration> > </plugin> > > This prevents the package-import for javax.xml.bind.annotation to not > define a specific version range. > > --- > > The missing understanding for me was what dependency=true means [2]. > > For example, in cxf-specs: > > <bundle start-level="10" > > dependency="true">mvn:jakarta.xml.bind/jakarta.xml.bind-api/${cxf.jaxb.version}</bundle> > > It means that the bundle will only be installed if it is really needed - > i.e. it provides packages that are not being exported by other bundles. > > Because winrm4j now had: > > javax.xml.bind.annotation;version="[2.3,3)" > > It meant that the javax.xml.bind.annotation from > org.apache.felix.framework didn't match. It needed jakarta.xml.bind-api > to meet the package import dependency. > > By excluding the version range for javax.xml.bind.annotation, it was > happy to just use org.apache.felix.framework. > > Aled > > [1] > > http://mail-archives.apache.org/mod_mbox/cxf-users/201912.mbox/%3C9a1d1ab6-8d00-234d-29b0-c86c31506c87%40gmail.com%3E > > [2] > > http://karaf.922171.n3.nabble.com/features-xml-dependency-quot-true-quot-td3286359.html > > > > On 04/12/2019 20:28, Aled Sage wrote: > > > > *T**_L;DR_* > > > > I was trying to upgrade to CXF 3.3.2 (from 3.2.8) because > > https://karaf.apache.org/news.html announcement about Karaf 4.2.7 > > lists CXF version 3.3.2. > > > > But I've hit a big problem. > > > > winrm4j fails in Karaf with CXF 3.3.2: JAXB service construction fails > > when parsing annotations. > > > > Should we abandon the CXF upgrade and stick with 3.2.8? > > > > I'll report it to the CXF mailing list, so perhaps reserve judgement > > to see what they say. > > > > _*DETAILS OF ERROR*_ > > > > The upgrade involved upgrading winrm4j to use CXF 3.3.2, which seemed > > to go fine (all tests pass outside of Karaf). > > > > However, when I test use of WinRM inside Brooklyn Karaf, it fails with > > the error below: > > > > ``` > > 2019-12-03T11:44:16,468 wmhGA3U2-[ut059oi7tk,ltajipcuun] WARN 103 > > i.c.w.c.WinRmClient [ager-Ak6FHXbO-32] Error creating WinRm service > > with mbean strategy (trying other strategies): > > org.apache.cxf.service.factory.ServiceConstructionException > > org.apache.cxf.service.factory.ServiceConstructionException: null > > at > > org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:355) > > ~[!/:3.3.2] > > at > > > org.apache.cxf.service.factory.AbstractServiceFactoryBean.initializeDataBindings(AbstractServiceFactoryBean.java:86) > > > ~[!/:3.3.2] > > at > > > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.buildServiceFromWSDL(ReflectionServiceFactoryBean.java:426) > > > ~[!/:3.3.2] > > at > > > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.initializeServiceModel(ReflectionServiceFactoryBean.java:528) > > > ~[!/:3.3.2] > > at > > > org.apache.cxf.wsdl.service.factory.ReflectionServiceFactoryBean.create(ReflectionServiceFactoryBean.java:263) > > > ~[!/:3.3.2] > > at > > > org.apache.cxf.jaxws.support.JaxWsServiceFactoryBean.create(JaxWsServiceFactoryBean.java:199) > > > ~[?:?] > > at > > > org.apache.cxf.frontend.AbstractWSDLBasedEndpointFactory.createEndpoint(AbstractWSDLBasedEndpointFactory.java:103) > > > ~[!/:3.3.2] > > at > > > org.apache.cxf.frontend.ClientFactoryBean.create(ClientFactoryBean.java:91) > > ~[!/:3.3.2] > > at > > > org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:159) > > > ~[!/:3.3.2] > > at > > > org.apache.cxf.jaxws.JaxWsProxyFactoryBean.create(JaxWsProxyFactoryBean.java:142) > > > ~[?:?] > > at > > > org.apache.cxf.frontend.ClientProxyFactoryBean.create(ClientProxyFactoryBean.java:95) > > > ~[!/:3.3.2] > > at > > > io.cloudsoft.winrm4j.client.WinRmFactory.doCreateServiceWithBean(WinRmFactory.java:97) > > > ~[!/:?] > > at > > > io.cloudsoft.winrm4j.client.WinRmFactory.createService(WinRmFactory.java:33) > > > [!/:?] > > at > > > io.cloudsoft.winrm4j.client.WinRmFactory.newInstance(WinRmFactory.java:21) > > [!/:?] > > at > > io.cloudsoft.winrm4j.client.WinRmClient.getService(WinRmClient.java:191) > > [!/:?] > > at > > io.cloudsoft.winrm4j.client.WinRmClient.<init>(WinRmClient.java:172) > > [!/:?] > > at > > > io.cloudsoft.winrm4j.client.WinRmClientBuilder.build(WinRmClientBuilder.java:194) > > > [!/:?] > > at > > io.cloudsoft.winrm4j.winrm.WinRmTool.executeCommand(WinRmTool.java:298) > > [!/:?] > > at > > io.cloudsoft.winrm4j.winrm.WinRmTool.executeCommand(WinRmTool.java:216) > > [!/:?] > > at > > > org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool$1.apply(Winrm4jTool.java:119) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool$1.apply(Winrm4jTool.java:117) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool.exec(Winrm4jTool.java:185) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.util.core.internal.winrm.winrm4j.Winrm4jTool.executeCommand(Winrm4jTool.java:117) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.location.winrm.WinRmMachineLocation.executeCommand(WinRmMachineLocation.java:308) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.location.jclouds.JcloudsLocation$5.call(JcloudsLocation.java:2518) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.location.jclouds.JcloudsLocation$5.call(JcloudsLocation.java:2514) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.util.repeat.Repeater.runKeepingError(Repeater.java:399) > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.location.jclouds.JcloudsLocation.waitForReachable(JcloudsLocation.java:2741) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.location.jclouds.JcloudsLocation.waitForWinRmAvailable(JcloudsLocation.java:2567) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.location.jclouds.DefaultConnectivityResolver.checkCredential(DefaultConnectivityResolver.java:404) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.location.jclouds.DefaultConnectivityResolver.resolve(DefaultConnectivityResolver.java:196) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.location.jclouds.JcloudsLocation.obtainOnce(JcloudsLocation.java:807) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.location.jclouds.JcloudsLocation.obtain(JcloudsLocation.java:614) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:448) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ObtainLocationTask.call(MachineLifecycleEffectorTasks.java:437) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.util.core.task.Tasks.withBlockingDetails(Tasks.java:114) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:418) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.entity.software.base.lifecycle.MachineLifecycleEffectorTasks$ProvisionMachineTask.call(MachineLifecycleEffectorTasks.java:393) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.util.core.task.DynamicSequentialTask$DstJob.call(DynamicSequentialTask.java:364) > > > [!/:1.0.0-SNAPSHOT] > > at > > > org.apache.brooklyn.util.core.task.BasicExecutionManager$SubmissionCallable.call(BasicExecutionManager.java:565) > > > [!/:1.0.0-SNAPSHOT] > > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > > [?:1.8.0_201] > > at > > > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > > > [?:1.8.0_201] > > at > > > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) > > > [?:1.8.0_201] > > at java.lang.Thread.run(Thread.java:748) [?:1.8.0_201] > > Caused by: > > com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException: 2 > > counts of IllegalAnnotationExceptions > > at > > > com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException$Builder.check(IllegalAnnotationsException.java:91) > > > ~[?:1.8.0_201] > > at > > > com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:445) > > > ~[?:1.8.0_201] > > at > > > com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:277) > > > ~[?:1.8.0_201] > > at > > > com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl.<init>(JAXBContextImpl.java:124) > > > ~[?:1.8.0_201] > > at > > > com.sun.xml.internal.bind.v2.runtime.JAXBContextImpl$JAXBContextBuilder.build(JAXBContextImpl.java:1123) > > > ~[?:1.8.0_201] > > at > > > com.sun.xml.internal.bind.v2.ContextFactory.createContext(ContextFactory.java:147) > > > ~[?:1.8.0_201] > > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > > ~[?:1.8.0_201] > > at > > > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > > > ~[?:1.8.0_201] > > at > > > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > > > ~[?:1.8.0_201] > > at java.lang.reflect.Method.invoke(Method.java:498) > ~[?:1.8.0_201] > > at > > javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:222) > > ~[?:1.8.0_201] > > at javax.xml.bind.ContextFinder.find(ContextFinder.java:396) > > ~[?:1.8.0_201] > > at > > javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:641) > > ~[?:1.8.0_201] > > at > > > org.apache.cxf.common.jaxb.JAXBContextCache.createContext(JAXBContextCache.java:357) > > > ~[!/:3.3.2] > > at > > > org.apache.cxf.common.jaxb.JAXBContextCache.getCachedContextAndSchemas(JAXBContextCache.java:246) > > > ~[!/:3.3.2] > > at > > > org.apache.cxf.jaxb.JAXBDataBinding.createJAXBContextAndSchemas(JAXBDataBinding.java:498) > > > ~[!/:3.3.2] > > at > > org.apache.cxf.jaxb.JAXBDataBinding.initialize(JAXBDataBinding.java:353) > > ~[!/:3.3.2] > > ... 43 more > > ``` > > > > Looking via a debugger to get the underlying > > IllegalAnnotatoinExceptions, I see: > > ``` > > > ((com.sun.xml.internal.bind.v2.runtime.IllegalAnnotationsException)e.getCause()).getErrors() > > (java.util.Collections$UnmodifiableRandomAccessList<E>) [Two classes > > have the same XML type name > > "{http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd}objectFactory";. Use > > @XmlType.name and @XmlType.namespace to assign different names to them. > > this problem is related to the following location: > > at io.cloudsoft.winrm4j.client.transfer.ObjectFactory > > this problem is related to the following location: > > at io.cloudsoft.winrm4j.client.wsman.ObjectFactory, Two > > classes have the same XML type name > > "{http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd}objectFactory";. Use > > @XmlType.name and @XmlType.namespace to assign different names to them. > > this problem is related to the following location: > > at io.cloudsoft.winrm4j.client.wsman.ObjectFactory > > this problem is related to the following location: > > at io.cloudsoft.winrm4j.client.shell.ObjectFactory] > > ``` > > > > > > _*INVESTIGATION OF ERROR*_ > > > > This thread gives some pointers: > > > https://stackoverflow.com/questions/7361336/two-classes-have-the-same-xml-type-name-objectfactory > > > > It suggests looking at how many javax.xml.bind.annotation.XMLRegistry > > classes you have on your classpath. > > > > Via a debugger, I compared what happens in Karaf with CXF 3.3.2 and > > CXF 3.2.8: > > > > ``` > > > io.cloudsoft.winrm4j.client.wsman.ObjectFactory.class.getAnnotations()[0].annotationType() > > [CXV 3.2.8 output] (java.lang.Class<T>) interface > > javax.xml.bind.annotation.XmlRegistry > > [CXV 3.3.2 output] (java.lang.Class<T>) interface > > javax.xml.bind.annotation.XmlRegistry > > > > > io.cloudsoft.winrm4j.client.wsman.ObjectFactory.class.getAnnotations()[0].annotationType().getClassLoader() > > [CXV 3.2.8 output] null > > [CXV 3.3.2 output] > > (org.apache.felix.framework.BundleWiringImpl$BundleClassLoader) > > jakarta.xml.bind-api [108] > > ``` > > > > I interpret the null classloader as meaning it is from the system > > classloader (e.g. `java.lang.Object.class.getClassLoader()` also > > returns `null`). > > > > Looking in Karaf using `bin/client` (with CXF 3.2.8): > > ``` > > package:exports | grep javax.xml.bind.annotation > > javax.xml.bind.annotation.adapters │ 2.2.8 │ 0 │ > > org.apache.felix.framework > > javax.xml.bind.annotation │ 2.2.8 │ 0 │ > > org.apache.felix.framework > > > > package:imports | grep winrm | grep javax.xml.bind.annotation > > Package │ Version │ Optional │ ID │ > > Bundle Name > > javax.xml.bind.annotation.adapters │ │ │ 103 │ > > io.cloudsoft.windows.winrm4j-client > > javax.xml.bind.annotation │ │ │ 103 │ > > io.cloudsoft.windows.winrm4j-client > > ``` > > > > Compare that with CXF 3.3.2: > > ``` > > package:exports | grep javax.xml.bind.annotation > > javax.xml.bind.annotation.adapters │ 2.2.8 │ 0 │ > > org.apache.felix.framework > > javax.xml.bind.annotation.adapters │ 2.3.2 │ 108 │ > > jakarta.xml.bind-api > > javax.xml.bind.annotation │ 2.2.8 │ 0 │ > > org.apache.felix.framework > > javax.xml.bind.annotation │ 2.3.2 │ 108 │ > > jakarta.xml.bind-api > > > > package:imports | grep winrm | grep javax.xml.bind.annotation > > Package │ Version │ Optional │ ID │ > > Bundle Name > > javax.xml.bind.annotation.adapters │ [2.3.0,3.0.0) │ │ 103 │ > > io.cloudsoft.windows.winrm4j-client > > javax.xml.bind.annotation │ [2.3.0,3.0.0) │ │ 103 │ > > io.cloudsoft.windows.winrm4j-client > > ``` > > > > Looking at where `jakarta.xml.bind-api` comes from in CXF 3.3.2 (it's > > not there when we use CXF 3.2.8): > > ``` > > feature:info cxf-specs > > > > Running feature:info cxf-specs > > Feature cxf-specs 3.3.2 > > ... > > Feature contains followed bundles: > > ... > > mvn:jakarta.xml.bind/jakarta.xml.bind-api/2.3.2 start-level=10 > > ``` > > (The cxf-specs feature is a dependency of the cxf-core feature.) > > > > Looking at the MANIFEST.mf (or the bundle:headers) of `winrm4j-client`: > > With CXF 3.3.2, it has: > > ``` > > javax.xml.bind.annotation;version="[2.3,3)" > > ``` > > With CXF 3.2.8, it has: > > ``` > > javax.xml.bind.annotation > > ``` > > (i.e. no version range is specified). > > > > I don't think there are code changes causing this - I think it is > > inferred from the CXF versions (or perhaps because newer maven plugin > > versions are used?) > > > > But even if it didn't specify a version range with CXF 3.3.2, it would > > prefer the import from the newer version (i.e. from 2.3.2). > > > > > > _*NEXT STEPS*_ > > > > We should report the issue on the CXF / Karaf mailing list - I'll do > that. > > > > I lean towards not fixing it (unless the CXF community come back with > > an easy answer). > > > > If we did try to fix it, possibilities include: > > > > 1. Change winrm4j bundle's package imports to require 2.2.x of > > javax.xml.bind.annotation. > > But would that be compatible with the rest of the CXF package > imports? > > 2. Or some other mechanism to force the annotation parsing to somehow > > use javax.xml.bind.annotation.XmlRegistry version 2.2.8 from > > org.apache.felix.framework?! > > 3. Or try to force use of a particular `JAXBContext` - but winrm4j > > isn't instantiating the JAXBContext. > > (e.g. https://stackoverflow.com/a/7483425/1393883 tries to force a > > particular `META-INF/services/javax.xml.bind.JAXBContext` at the > > classloader level). > > > > > > Option (2) feels really hard and risky - the feature `cxf-specs` is > > pulling in `jakarta.xml.bind-api`, and `cxf-core` pulls in the feature > > `cxf-specs`. That feels very low level! There could be untold > > consequences of messing with the bind-api version at that level. Even > > if our smoke tests pass, I'd be worried about what else we might have > > broken. > > > > Option (1) gives me some of the same worries as for (2) - we'd be > > importing a different javax.xml.bind.annotation compared to the > > bundles that the CXF packages come from. That kind of thing can cause > > weird ClassCastExceptions because things are using different > classloaders. > > > > My gut feel for option (3) is that it's the wrong road to be going > > down - it's fighting CXF rather than working with it! > > > > > > _*MISCELLANEOUS DEBUGGING NOTES*_ > > > > I find the script below useful to get a dump of all the features and > > which bundles they bring in - I normally redirect the output to a file > > and search through that: > > ``` > > #!/bin/bash > > > > for i in `./bin/client "feature:list" | grep -v "Uninstalled" | awk > > '{print $1}'`; do > > echo "Running feature:info ${i}" > > ./bin/client "feature:info ${i}" > > echo > > echo > > done > > ``` > > > > On 02/12/2019 21:21, Geoff Macartney wrote: > >> It's always a bit of a maze, isn't it! > >> > >> Thanks for looking into this Aled. I think it will be great to get > >> things brought up to a consistent level with this latest Karaf. > >> > >> Cheers > >> Geoff > >> > >> > >> > >> On Mon, 2 Dec 2019 at 13:28, Aled Sage <[email protected] > >> <mailto:[email protected]>> wrote: > >> > >> Hi all, > >> > >> TL;DR: I'm looking at upgading CXF from 3.2.8 to 3.3.2. > >> > >> --- > >> > >> For dependency: > >> system//javax/mail/mail: [1.4.7, 1.4.4] > >> > >> Exploring this one shows that v1.4.4 is coming from the old > >> cxf-specs > >> 3.2.8. The Karaf 4.2.7 announcement [1] gives a table of versions > >> - it > >> shows CXF at 3.3.2. We should look up updating CXF from 3.2.8 to > >> 3.3.2. > >> > >> That will also require an upgrade of > >> mvn:io.cloudsoft.windows/winrm4j > >> (as v0.7.0 is built against CXF 3.2.8). > >> > >> I'm looking into this, to see what else breaks when we switch to > >> CXF 3.3.2. > >> > >> --- > >> > >> I suggest we ignore: > >> > system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle: > >> > >> [1.2.2, 1.2] > >> > >> Feature 'jetty' brings in v1.2.2, whereas feature 'pax-jetty' > >> brings in > >> v1.2, so it's out of our control. > >> > >> Aled > >> > >> > >> On 02/12/2019 10:38, Aled Sage wrote: > >> > Hi all, > >> > > >> > I see there was great progress with the karaf version bump last > >> week > >> > and over the weekend, e.g. [1, 2]. > >> > > >> > Looking at brooklyn master karaf dependency versions using `find > >> > ${BROOKLYN_HOME}/system/ -name "*.jar"` and running a little > >> program > >> > to find multiple versions, I see the following concerning > >> duplicates: > >> > > >> > > >> > system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle: > >> > >> > [1.2.2, 1.2] > >> > system//javax/mail/mail: [1.4.7, 1.4.4] > >> > > >> > The full list is: > >> > > >> > system//org/ow2/asm/asm: [5.2, 7.1] > >> > system//org/ow2/asm/asm-util: [5.2, 7.1] > >> > system//org/ow2/asm/asm-tree: [5.2, 7.1] > >> > system//org/ow2/asm/asm-analysis: [5.2, 7.1] > >> > system//org/ow2/asm/asm-commons: [5.2, 7.1] > >> > system//org/yaml/snakeyaml: [1.23, 1.17] > >> > > >> > system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib: > >> > >> > [1.1.3_2, 1.0.7_1] > >> > > >> > system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp: > >> > >> > [3.4.1_1, 2.2.0_1] > >> > > >> > system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio: > >> > >> > [1.9.0_1, 1.2.0_1] > >> > > >> > system//org/apache/aries/spifly/org.apache.aries.spifly.dynamic.bundle: > >> > >> > [1.2.2, 1.2] > >> > system//javax/mail/mail: [1.4.7, 1.4.4] > >> > system//javax/ws/rs/javax.ws <http://javax.ws>.rs-api: [2.0.1, > >> 2.1.1] > >> > > >> > Compare this with Brooklyn version 1.0.0-M1: > >> > > >> > system//org/ow2/asm/asm-all: [5.2, 5.0.2] > >> > system//org/yaml/snakeyaml: [1.17, 1.22] > >> > > >> > > system//org/apache/servicemix/specs/org.apache.servicemix.specs.activation-api-1.1: > >> > >> > [2.5.0, 2.6.0] > >> > > >> > system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.jzlib: > >> > >> > [1.1.3_2, 1.0.7_1] > >> > > >> > system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okhttp: > >> > >> > [3.4.1_1, 2.2.0_1] > >> > > >> > system//org/apache/servicemix/bundles/org.apache.servicemix.bundles.okio: > >> > >> > [1.9.0_1, 1.2.0_1] > >> > system//org/apache/aries/org.apache.aries.util: [1.1.3, 1.1.0] > >> > system//com/google/code/gson/gson: [2.5, 2.3] > >> > > >> > I'll take a look at these and see if they really are a problem > >> or not. > >> > > >> > Aled > >> > > >> > [1] https://github.com/apache/brooklyn-server/pull/1068 > >> > > >> > [2] https://github.com/apache/brooklyn-server/pull/1069 > >> > > >> > > >> > > >> > > >> > On 02/12/2019 09:27, Aled Sage wrote: > >> >> Hi, > >> >> > >> >> Thanks Ludo, all: - great list, and +1 from me. > >> >> > >> >> I think most of those sound fairly small and manageable. > >> >> > >> >> The one that stands out as potentially hard is the "Karaf version > >> >> bump" (which would fix the "Two different versions of > >> jetty-server"). > >> >> We've had problems in the past getting all versions > >> consistent, and > >> >> karaf to start up fast and cleanly (without it restarting a > >> bunch of > >> >> bundles). Changing the version is really easy - getting all > >> versions > >> >> of all bundles to be consistent can be a pain! But it's worth > >> doing. > >> >> > >> >> Aled > >> >> > >> >> > >> >> On 01/12/2019 14:47, Geoff Macartney wrote: > >> >>> We should definitely include > >> >>> https://issues.apache.org/jira/browse/BROOKLYN-597 "Remove > >> MD5 and > >> >>> SHA-1 > >> >>> checksums" as part of 1.0.0. I'd be happy to do this but I > >> see it's > >> >>> got > >> >>> you assigned to it Richard. Do you have work in progress on > >> this, or > >> >>> would > >> >>> you like me to look into it? I have a notion that I might > >> polish up the > >> >>> signing procedure a bit. > >> >>> > >> >>> Cheers > >> >>> Geoff > >> >>> > >> >>> On Sun, 1 Dec 2019 at 14:13, Geoff Macartney > >> >>> <[email protected] <mailto:[email protected]>> > >> >>> wrote: > >> >>> > >> >>>> Hi Ludo, > >> >>>> > >> >>>> I am indeed pleased to see this! I had been thinking of > >> mailing the > >> >>>> community again on the matter after Christmas was out of the > >> way, > >> >>>> let's let > >> >>>> 2020 be the year of Brooklyn 1.0.0! > >> >>>> > >> >>>> That's a great list of things to address. One thing to add > >> would be > >> >>>> removing some deprecated code. Do you think they are all small > >> >>>> changes, or > >> >>>> do any require extensive work or have a wide impact? > >> >>>> > >> >>>> The reason I ask is that I think it would be good to restrict > >> >>>> ourselves to > >> >>>> relatively easy and limited impact changes between now and > >> 1.0.0. > >> >>>> My fear > >> >>>> is that larger changes will take a longer time and push back a > >> >>>> release even > >> >>>> further. It seems to me things are quite stable now; I'd say > >> let's > >> >>>> polish > >> >>>> it up and release it rather than try to make significant > >> improvements. > >> >>>> > >> >>>> What does everyone think? > >> >>>> > >> >>>> Cheers > >> >>>> Geoff > >> >>>> > >> >>>> > >> >>>> > >> >>>> > >> >>>> On Thu, 28 Nov 2019 at 11:04, Ludovic Farine > >> <[email protected] <mailto:[email protected]>> > >> >>>> wrote: > >> >>>> > >> >>>>> Hi everyone, > >> >>>>> > >> >>>>> Hope you are all doing well! > >> >>>>> > >> >>>>> Christmas is fast approaching and well hopefully a gift we > >> would > >> >>>>> all like > >> >>>>> to have: Brooklyn 1.0.0 release :) Geoff would be pleased > >> to hear! > >> >>>>> > >> >>>>> Working towards this goal of first official release, these > >> are a > >> >>>>> few bug > >> >>>>> fixes and improvements that I believe are worth considering > >> >>>>> (non-exhaustive > >> >>>>> and not ordered wishlist!) : > >> >>>>> > >> >>>>> Bug fixes: > >> >>>>> > >> >>>>> - > >> >>>>> > >> >>>>> Broken icon links for ELK and DNS entities > >> >>>>> - > >> >>>>> > >> >>>>> REST API Swagger error > >> >>>>> - > >> >>>>> > >> >>>>> Two different versions of jetty-server > >> >>>>> - > >> >>>>> > >> >>>>> Karaf version bump > >> >>>>> > >> >>>>> > >> >>>>> Improvements: > >> >>>>> > >> >>>>> - > >> >>>>> > >> >>>>> Session Management: introduce expiry settings for > >> inactivity or > >> >>>>> repeated > >> >>>>> background API calls > >> >>>>> - > >> >>>>> > >> >>>>> User Experience: blueprints ordered by date deployed, > >> cookies to > >> >>>>> remember preferred sort criteria and palette preferences > >> >>>>> > >> >>>>> > >> >>>>> Clean-up: > >> >>>>> > >> >>>>> - > >> >>>>> > >> >>>>> Review existing open Pull Requests > >> >>>>> - > >> >>>>> > >> >>>>> Fix most of the Jenkins tests > >> >>>>> > >> >>>>> > >> >>>>> What are your thoughts on this scope? Any other suggestions > >> you > >> >>>>> would like > >> >>>>> to deliver in this next release? > >> >>>>> > >> >>>>> Looking forward to get the community engaging in the next > >> weeks and > >> >>>>> months. > >> >>>>> > >> >>>>> Remember you can participate with others on the official Slack > >> >>>>> channel > >> >>>>> *#brooklyn* on the official Apache group. Sign up here > >> >>>>> https://s.apache.org/slack-invite to join the discussion! > >> >>>>> > >> >>>>> Thanks > >> >>>>> > >> >>>>> Ludo > >> >>>>> > >> >>>>> > >> >>>>> -- > >> >>>>> > >> >>>>> Ludovic Farine > >> >>>>> > >> >>>>> Senior Technical Project Manager > >> >>>>> > >> >>>>> > >> >>>>> Cloudsoft <https://cloudsoft.io/> | Bringing Business to > >> the Cloud > >> >>>>> > >> >>>>> E: [email protected] <mailto:[email protected]> > >> >>>>> > >> >>>>> T: +44 7584 748013 > >> >>>>> > >> >>>>> L: https://www.linkedin.com/in/ludovicfarine/ > >> >>>>> > >> >
