[release] Upgrading to yangtools-2.0.0/odlparent-3.0.1


Ryan Goulding <ryandgoulding@...>
 

I pulled mdsal and controller upstream changes, built, then and attempted "mvn clean install" with the AAA patch [0].  This hung SFT.  So I did a "mvn -Pq clean install" and ran karaf.  Upon trying to "feature:install odl-aaa-shiro" I got huge MultiException stacktrace ultimately caused by this:

Error executing command: Error:
Error downloading mvn:org.apache.karaf.webconsole/org.apache.karaf.webconsole.http/4.1.3

I then attempted bundle installation manually and also came up with some errors:

karaf@root()> bundle:install mvn:org.apache.karaf.webconsole/org.apache.karaf.webconsole.http/4.1.3
Bundle IDs: 
11:48:32.895 [Karaf local console user karaf] ERROR org.apache.karaf.shell.support.ShellUtil - Exception caught while executing command
org.apache.karaf.shell.support.MultiException: Error installing bundles:
Unable to install bundle mvn:org.apache.karaf.webconsole/org.apache.karaf.webconsole.http/4.1.3: org.osgi.framework.BundleException: Error reading bundle content.


Is this where you got?  I have no clue what is causing this at the moment.  Want to make sure we are at the same point though...

On Wed, Nov 29, 2017 at 12:28 PM, Robert Varga <nite@...> wrote:
On 27/11/17 19:50, Robert Varga wrote:
> - aaa needs to fixup its IT (which is a failure related to odlparent's
> upgrade of h2, as far as I can tell)

This is not accurate, as the shiro feature is broken. This requires
someone from AAA to drive it home.

Bye,
Robert


_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release



Ryan Goulding <ryandgoulding@...>
 

Opened this thread [0].  webconsole appears to be broken in opendaylight-karaf-empty.  For reference, it is not broken in upstream 4.1.3 which odlparent v3.0.1 is based off.

Thanks,
Ryan


On Thu, Nov 30, 2017 at 11:52 AM, Ryan Goulding <ryandgoulding@...> wrote:
I pulled mdsal and controller upstream changes, built, then and attempted "mvn clean install" with the AAA patch [0].  This hung SFT.  So I did a "mvn -Pq clean install" and ran karaf.  Upon trying to "feature:install odl-aaa-shiro" I got huge MultiException stacktrace ultimately caused by this:

Error executing command: Error:
Error downloading mvn:org.apache.karaf.webconsole/org.apache.karaf.webconsole.http/4.1.3

I then attempted bundle installation manually and also came up with some errors:

karaf@root()> bundle:install mvn:org.apache.karaf.webconsole/org.apache.karaf.webconsole.http/4.1.3
Bundle IDs: 
11:48:32.895 [Karaf local console user karaf] ERROR org.apache.karaf.shell.support.ShellUtil - Exception caught while executing command
org.apache.karaf.shell.support.MultiException: Error installing bundles:
Unable to install bundle mvn:org.apache.karaf.webconsole/org.apache.karaf.webconsole.http/4.1.3: org.osgi.framework.BundleException: Error reading bundle content.


Is this where you got?  I have no clue what is causing this at the moment.  Want to make sure we are at the same point though...

Regards,

Ryan Goulding


On Wed, Nov 29, 2017 at 12:28 PM, Robert Varga <nite@...> wrote:
On 27/11/17 19:50, Robert Varga wrote:
> - aaa needs to fixup its IT (which is a failure related to odlparent's
> upgrade of h2, as far as I can tell)

This is not accurate, as the shiro feature is broken. This requires
someone from AAA to drive it home.

Bye,
Robert


_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release




Robert Varga
 

On 30/11/17 17:52, Ryan Goulding wrote:
Is this where you got?  I have no clue what is causing this at the
moment.  Want to make sure we are at the same point though...
Yes. I think this is two separate issues, though. The SFT failure
initially was just about javax.ws.rs not being present and being
required by jackson. Once I added that, I saw that hang.

The distro seems to be ... interesting, as the basic structure in
system/ is present, but the directories are not populated with
corresponding jars...

Regards,
Robert


Ryan Goulding <ryandgoulding@...>
 

I see the same thing.

Stephen, has this happened with any other testing w/ odlparent 2.0.5?  When I copy jars locally, I slowly get rid of error messages.  That obviously isn't desirable.  I also tried to take the default org.ops4j.pax.url.mvn.cfg and starting (in order to download the missing artifacts from remote repos) but that ran into many issues as well.

Thanks!

Regards,

Ryan Goulding

On Sun, Dec 3, 2017 at 8:02 AM, Robert Varga <nite@...> wrote:
On 30/11/17 17:52, Ryan Goulding wrote:
> Is this where you got?  I have no clue what is causing this at the
> moment.  Want to make sure we are at the same point though...

Yes. I think this is two separate issues, though. The SFT failure
initially was just about javax.ws.rs not being present and being
required by jackson. Once I added that, I saw that hang.

The distro seems to be ... interesting, as the basic structure in
system/ is present, but the directories are not populated with
corresponding jars...

Regards,
Robert



Stephen Kitt <skitt@...>
 

On Mon, 4 Dec 2017 12:54:53 -0500
Ryan Goulding <ryandgoulding@...> wrote:
I see the same thing.

Stephen, has this happened with any other testing w/ odlparent
2.0.5? When I copy jars locally, I slowly get rid of error
messages. That obviously isn't desirable. I also tried to take the
default org.ops4j.pax.url.mvn.cfg and starting (in order to download
the missing artifacts from remote repos) but that ran into many
issues as well.
Not with 2.0.5 AFAICT.

With 3.0.1, there’s something messed up in the feature dependency
chain, or perhaps a mixture of the build and feature dependency chain.
I get the impression kar just gives up when it can’t converge
something, instead of failing the build, resulting in the empty
directories you’re seeing. Sticking to facts, if I add explicit
dependencies to aaa-karaf, I can progressively add more dependencies in
the distribution, and get further when building and/or loading
(building, because kar does resolve the OSGi dependencies, so
non-optional dependencies need to be fulfilled correctly).

So far, I’ve got webconsole.http, webconsole, servlet-api, pax-web-spi,
pax-web-api, commons-io, xbean-finder, asm-all, xbean-bundleutils,
commons-fileupload, and I’m at karaf.scr.management which is where
everything blows up because one part of the tree needs felix.scr >= 2
and another needs felix.scr < 2.

Since Karaf 4.1.3 itself can build a fully-populated distribution
correctly, I’m guessing this is related to one of the odlparent
patches, or perhaps an invalid version in our dependency (invalid as in
conflicting with Karaf).

I’m still digging...

Regards,

Spelunky


Ryan Goulding <ryandgoulding@...>
 

Stephen,

Yeah, I did the more rudimentary version of downloading jars manually and sticking them in system.  I started to unravel that and ran into similar results.

We identified two issues during yesterday's Kernel Project's call.
1) system/ is not populated properly, which Stephen is working as stated in the above email. [0]

2) AAA SFT hangs.  [1] addresses the switch off jackson (fails dist-check due to the fact RESTCONF in NETCONF depended on import of some dependencies by AAA, so it will likely need a similar transition to GSON too ).  With [1] layered on the upgrade patch [2] I am still running into a terrible bundle refresh during SFT... surefire log snippet here:

Refreshing bundles:
    org.apache.aries.blueprint.cm/1.1.0 (Wired to org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
    org.apache.aries.blueprint.core/1.8.3 (Attached fragments changed: [org.apache.aries.blueprint.core.compatibility/1.0.0])
    org.apache.karaf.bundle.blueprintstate/4.1.3 (Wired to org.apache.karaf.bundle.core/4.1.3 which is being refreshed)
    org.apache.karaf.bundle.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.config.core/4.1.3 (Should be wired to: org.apache.felix.metatype/1.1.6 (through [org.apache.karaf.config.core/4.1.3] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.metatype)(version>=1.2.0)(!(version>=2.0.0)))"; resolution:=optional))
    org.apache.karaf.deployer.kar/4.1.3 (Wired to org.apache.karaf.kar.core/4.1.3 which is being refreshed)
    org.apache.karaf.diagnostic.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.features.command/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.instance.core/4.1.3 (Wired to org.apache.karaf.features.command/4.1.3 which is being refreshed)
    org.apache.karaf.jaas.blueprint.config/4.1.3 (Wired to org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
    org.apache.karaf.jaas.command/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.kar.core/4.1.3 (Wired to org.apache.karaf.features.command/4.1.3 which is being refreshed)
    org.apache.karaf.log.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.package.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.service.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.shell.commands/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.shell.console/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.shell.core/4.1.3 (Wired to org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
    org.apache.karaf.shell.ssh/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.system.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.servicemix.bundles.jasypt/1.9.2.1 (Should be wired to: javax.servlet-api/3.1.0 (through [org.apache.servicemix.bundles.jasypt/1.9.2.1] osgi.wiring.package; filter:="(osgi.wiring.package=javax.servlet)"; resolution:=optional))
    org.ops4j.pax.jdbc.config/1.1.0 (Wired to org.apache.servicemix.bundles.jasypt/1.9.2.1 which is being refreshed)
    org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 (Should be wired to: javax.mail/1.4.4 (through [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1] osgi.wiring.package; filter:="(osgi.wiring.package=javax.mail)"; resolution:=optional), com.lmax.disruptor/3.3.7 (through [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1] osgi.wiring.package; filter:="(osgi.wiring.package=com.lmax.disruptor)"; resolution:=optional), stax2-api/3.1.4 (through [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1] osgi.wiring.package; filter:="(osgi.wiring.package=org.codehaus.stax2)"; resolution:=optional))

 
I do not believe AAA even brings in servicemix bundles, since "servicemix" doesn't appear in the dependency tree.

dev@dev:/code/ar2/autorelease/aaa$ mvn dependency:tree | grep -i servicemix
dev@dev:/code/ar2/autorelease/aaa$


Any thoughts on why this may be happening/possible steps forward?  Anything is appreciated as I am frankly stumped.

On Wed, Dec 6, 2017 at 4:57 AM, Stephen Kitt <skitt@...> wrote:
On Mon, 4 Dec 2017 12:54:53 -0500
Ryan Goulding <ryandgoulding@...> wrote:
> I see the same thing.
>
> Stephen, has this happened with any other testing w/ odlparent
> 2.0.5?  When I copy jars locally, I slowly get rid of error
> messages.  That obviously isn't desirable.  I also tried to take the
> default org.ops4j.pax.url.mvn.cfg and starting (in order to download
> the missing artifacts from remote repos) but that ran into many
> issues as well.

Not with 2.0.5 AFAICT.

With 3.0.1, there’s something messed up in the feature dependency
chain, or perhaps a mixture of the build and feature dependency chain.
I get the impression kar just gives up when it can’t converge
something, instead of failing the build, resulting in the empty
directories you’re seeing. Sticking to facts, if I add explicit
dependencies to aaa-karaf, I can progressively add more dependencies in
the distribution, and get further when building and/or loading
(building, because kar does resolve the OSGi dependencies, so
non-optional dependencies need to be fulfilled correctly).

So far, I’ve got webconsole.http, webconsole, servlet-api, pax-web-spi,
pax-web-api, commons-io, xbean-finder, asm-all, xbean-bundleutils,
commons-fileupload, and I’m at karaf.scr.management which is where
everything blows up because one part of the tree needs felix.scr >= 2
and another needs felix.scr < 2.

Since Karaf 4.1.3 itself can build a fully-populated distribution
correctly, I’m guessing this is related to one of the odlparent
patches, or perhaps an invalid version in our dependency (invalid as in
conflicting with Karaf).

I’m still digging...

Regards,

Spelunky


Ryan Goulding <ryandgoulding@...>
 

Hi Stephen,

Did you happen to get a chance to look at this bundle refresh?  I am asking since it seems to be referring to a jasypt refresh, which AAA doesn't install AFAICT.  Admittedly, it is strange if SFT works with controller and not AAA due to this issue, especially since AAA involves security (jasypt is security related).  I found the jasypt-encryption [0] feature in upstream karaf, but it is not installed as a part of "standard".  Do you have any knowledge as to why this bundle is even installed in our distribution?  From my understanding, we are using bouncycastle, not jasypt, for JCE Provider.  No worries if you don't have any idea, I will keep digging.

On Wed, Dec 6, 2017 at 11:28 AM, Ryan Goulding <ryandgoulding@...> wrote:
Stephen,

Yeah, I did the more rudimentary version of downloading jars manually and sticking them in system.  I started to unravel that and ran into similar results.

We identified two issues during yesterday's Kernel Project's call.
1) system/ is not populated properly, which Stephen is working as stated in the above email. [0]

2) AAA SFT hangs.  [1] addresses the switch off jackson (fails dist-check due to the fact RESTCONF in NETCONF depended on import of some dependencies by AAA, so it will likely need a similar transition to GSON too ).  With [1] layered on the upgrade patch [2] I am still running into a terrible bundle refresh during SFT... surefire log snippet here:

Refreshing bundles:
    org.apache.aries.blueprint.cm/1.1.0 (Wired to org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
    org.apache.aries.blueprint.core/1.8.3 (Attached fragments changed: [org.apache.aries.blueprint.core.compatibility/1.0.0])
    org.apache.karaf.bundle.blueprintstate/4.1.3 (Wired to org.apache.karaf.bundle.core/4.1.3 which is being refreshed)
    org.apache.karaf.bundle.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.config.core/4.1.3 (Should be wired to: org.apache.felix.metatype/1.1.6 (through [org.apache.karaf.config.core/4.1.3] osgi.wiring.package; filter:="(&(osgi.wiring.package=org.osgi.service.metatype)(version>=1.2.0)(!(version>=2.0.0)))"; resolution:=optional))
    org.apache.karaf.deployer.kar/4.1.3 (Wired to org.apache.karaf.kar.core/4.1.3 which is being refreshed)
    org.apache.karaf.diagnostic.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.features.command/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.instance.core/4.1.3 (Wired to org.apache.karaf.features.command/4.1.3 which is being refreshed)
    org.apache.karaf.jaas.blueprint.config/4.1.3 (Wired to org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
    org.apache.karaf.jaas.command/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.kar.core/4.1.3 (Wired to org.apache.karaf.features.command/4.1.3 which is being refreshed)
    org.apache.karaf.log.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.package.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.service.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.shell.commands/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.shell.console/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.shell.core/4.1.3 (Wired to org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
    org.apache.karaf.shell.ssh/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.karaf.system.core/4.1.3 (Wired to org.apache.karaf.shell.core/4.1.3 which is being refreshed)
    org.apache.servicemix.bundles.jasypt/1.9.2.1 (Should be wired to: javax.servlet-api/3.1.0 (through [org.apache.servicemix.bundles.jasypt/1.9.2.1] osgi.wiring.package; filter:="(osgi.wiring.package=javax.servlet)"; resolution:=optional))
    org.ops4j.pax.jdbc.config/1.1.0 (Wired to org.apache.servicemix.bundles.jasypt/1.9.2.1 which is being refreshed)
    org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 (Should be wired to: javax.mail/1.4.4 (through [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1] osgi.wiring.package; filter:="(osgi.wiring.package=javax.mail)"; resolution:=optional), com.lmax.disruptor/3.3.7 (through [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1] osgi.wiring.package; filter:="(osgi.wiring.package=com.lmax.disruptor)"; resolution:=optional), stax2-api/3.1.4 (through [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1] osgi.wiring.package; filter:="(osgi.wiring.package=org.codehaus.stax2)"; resolution:=optional))

 
I do not believe AAA even brings in servicemix bundles, since "servicemix" doesn't appear in the dependency tree.

dev@dev:/code/ar2/autorelease/aaa$ mvn dependency:tree | grep -i servicemix
dev@dev:/code/ar2/autorelease/aaa$


Any thoughts on why this may be happening/possible steps forward?  Anything is appreciated as I am frankly stumped.

Regards,

Ryan Goulding


On Wed, Dec 6, 2017 at 4:57 AM, Stephen Kitt <skitt@...> wrote:
On Mon, 4 Dec 2017 12:54:53 -0500
Ryan Goulding <ryandgoulding@...> wrote:
> I see the same thing.
>
> Stephen, has this happened with any other testing w/ odlparent
> 2.0.5?  When I copy jars locally, I slowly get rid of error
> messages.  That obviously isn't desirable.  I also tried to take the
> default org.ops4j.pax.url.mvn.cfg and starting (in order to download
> the missing artifacts from remote repos) but that ran into many
> issues as well.

Not with 2.0.5 AFAICT.

With 3.0.1, there’s something messed up in the feature dependency
chain, or perhaps a mixture of the build and feature dependency chain.
I get the impression kar just gives up when it can’t converge
something, instead of failing the build, resulting in the empty
directories you’re seeing. Sticking to facts, if I add explicit
dependencies to aaa-karaf, I can progressively add more dependencies in
the distribution, and get further when building and/or loading
(building, because kar does resolve the OSGi dependencies, so
non-optional dependencies need to be fulfilled correctly).

So far, I’ve got webconsole.http, webconsole, servlet-api, pax-web-spi,
pax-web-api, commons-io, xbean-finder, asm-all, xbean-bundleutils,
commons-fileupload, and I’m at karaf.scr.management which is where
everything blows up because one part of the tree needs felix.scr >= 2
and another needs felix.scr < 2.

Since Karaf 4.1.3 itself can build a fully-populated distribution
correctly, I’m guessing this is related to one of the odlparent
patches, or perhaps an invalid version in our dependency (invalid as in
conflicting with Karaf).

I’m still digging...

Regards,

Spelunky



Stephen Kitt <skitt@...>
 

Hi Ryan,

I have no idea unfortunately, I’m as stymied as you by jasypt. I’m
still trying to figure out why we lose
org.apache.karaf.webconsole.http... (I’m also running into refresh
issues with jline, which has the nice side-effect of killing the
console and stopping Karaf. Ho hum.)

One interesting tid-bit is that the empty directories appear in system
when Karaf tries to resolve a bundle at runtime, not at build time, so
it’s worth looking for empty directories just after a build and again
after running.

Regards,

Stephen


On Thu, 7 Dec 2017 09:23:16 -0500
Ryan Goulding <ryandgoulding@...> wrote:

Hi Stephen,

Did you happen to get a chance to look at this bundle refresh? I am
asking since it seems to be referring to a *jasypt* refresh, which
AAA doesn't install AFAICT. Admittedly, it is strange if SFT works
with controller and not AAA due to this issue, especially since AAA
involves security (jasypt is security related). I found the
jasypt-encryption [0] feature in upstream karaf, but it is not
installed as a part of "standard". Do you have any knowledge as to
why this bundle is even installed in our distribution? From my
understanding, we are using bouncycastle, not jasypt, for JCE
Provider. No worries if you don't have any idea, I will keep digging.

Thanks,

Ryan Goulding

[0]
https://github.com/apache/karaf/blob/karaf-4.1.3/assemblies/features/standard/src/main/feature/feature.xml#L923

On Wed, Dec 6, 2017 at 11:28 AM, Ryan Goulding
<ryandgoulding@...> wrote:

Stephen,

Yeah, I did the more rudimentary version of downloading jars
manually and sticking them in system. I started to unravel that
and ran into similar results.

We identified two issues during yesterday's Kernel Project's call.
1) system/ is not populated properly, which Stephen is working as
stated in the above email. [0]

2) AAA SFT hangs. [1] addresses the switch off jackson (fails
dist-check due to the fact RESTCONF in NETCONF depended on import
of some dependencies by AAA, so it will likely need a similar
transition to GSON too ). With [1] layered on the upgrade patch
[2] I am still running into a terrible bundle refresh during SFT...
surefire log snippet here:

Refreshing bundles:
org.apache.aries.blueprint.cm/1.1.0 (Wired to
org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
org.apache.aries.blueprint.core/1.8.3 (Attached fragments
changed: [org.apache.aries.blueprint.core.compatibility/1.0.0])
org.apache.karaf.bundle.blueprintstate/4.1.3 (Wired to
org.apache.karaf.bundle.core/4.1.3 which is being refreshed)
org.apache.karaf.bundle.core/4.1.3 (Wired to
org.apache.karaf.shell.core/4.1.3 which is being refreshed)
org.apache.karaf.config.core/4.1.3 (Should be wired to:
org.apache.felix.metatype/1.1.6 (through
[org.apache.karaf.config.core/4.1.3] osgi.wiring.package;
filter:="(&(osgi.wiring.package=org.osgi.service.
metatype)(version>=1.2.0)(!(version>=2.0.0)))";
resolution:=optional)) org.apache.karaf.deployer.kar/4.1.3 (Wired
to org.apache.karaf.kar.core/4.1.3 which is being refreshed)
org.apache.karaf.diagnostic.core/4.1.3 (Wired to
org.apache.karaf.shell.core/4.1.3 which is being refreshed)
org.apache.karaf.features.command/4.1.3 (Wired to
org.apache.karaf.shell.core/4.1.3 which is being refreshed)
org.apache.karaf.instance.core/4.1.3 (Wired to
org.apache.karaf.features.command/4.1.3 which is being refreshed)
org.apache.karaf.jaas.blueprint.config/4.1.3 (Wired to
org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
org.apache.karaf.jaas.command/4.1.3 (Wired to
org.apache.karaf.shell.core/4.1.3 which is being refreshed)
org.apache.karaf.kar.core/4.1.3 (Wired to
org.apache.karaf.features. command/4.1.3 which is being refreshed)
org.apache.karaf.log.core/4.1.3 (Wired to
org.apache.karaf.shell.core/4.1.3 which is being refreshed)
org.apache.karaf.package.core/4.1.3 (Wired to
org.apache.karaf.shell.core/4.1.3 which is being refreshed)
org.apache.karaf.service.core/4.1.3 (Wired to
org.apache.karaf.shell.core/4.1.3 which is being refreshed)
org.apache.karaf.shell.commands/4.1.3 (Wired to
org.apache.karaf.shell.core/4.1.3 which is being refreshed)
org.apache.karaf.shell.console/4.1.3 (Wired to
org.apache.karaf.shell.core/4.1.3 which is being refreshed)
org.apache.karaf.shell.core/4.1.3 (Wired to
org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
org.apache.karaf.shell.ssh/4.1.3 (Wired to
org.apache.karaf.shell.core/4.1.3 which is being refreshed)
org.apache.karaf.system.core/4.1.3 (Wired to
org.apache.karaf.shell.core/4.1.3 which is being refreshed)
org.apache.servicemix.bundles.jasypt/1.9.2.1 (Should be wired to:
javax.servlet-api/3.1.0 (through
[org.apache.servicemix.bundles.jasypt/ 1.9.2.1]
osgi.wiring.package; filter:="(osgi.wiring.package=javax.servlet)";
resolution:=optional)) org.ops4j.pax.jdbc.config/1.1.0 (Wired to
org.apache.servicemix.bundles.jasypt/1.9.2.1 which is being
refreshed) org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 (Should
be wired to: javax.mail/1.4.4 (through
[org.ops4j.pax.logging.pax-logging-log4j2/1.10.1]
osgi.wiring.package; filter:="(osgi.wiring.package=javax.mail)";
resolution:=optional), com.lmax.disruptor/3.3.7 (through
[org.ops4j.pax.logging.pax-logging-log4j2/1.10.1]
osgi.wiring.package;
filter:="(osgi.wiring.package=com.lmax.disruptor)";
resolution:=optional), stax2-api/3.1.4 (through
[org.ops4j.pax.logging.pax- logging-log4j2/1.10.1]
osgi.wiring.package;
filter:="(osgi.wiring.package=org.codehaus.stax2)";
resolution:=optional))

I do not believe AAA even brings in servicemix bundles, since
"servicemix" doesn't appear in the dependency tree.

dev@dev:/code/ar2/autorelease/aaa$ mvn dependency:tree | grep -i
servicemix
dev@dev:/code/ar2/autorelease/aaa$

Any thoughts on why this may be happening/possible steps forward?
Anything is appreciated as I am frankly stumped.

Regards,

Ryan Goulding

[0] https://jira.opendaylight.org/browse/ODLPARENT-133
[1] https://git.opendaylight.org/gerrit/#/c/66056/
[2] https://git.opendaylight.org/gerrit/#/c/64196/

On Wed, Dec 6, 2017 at 4:57 AM, Stephen Kitt <skitt@...>
wrote:
On Mon, 4 Dec 2017 12:54:53 -0500
Ryan Goulding <ryandgoulding@...> wrote:
I see the same thing.

Stephen, has this happened with any other testing w/ odlparent
2.0.5? When I copy jars locally, I slowly get rid of error
messages. That obviously isn't desirable. I also tried to take
the default org.ops4j.pax.url.mvn.cfg and starting (in order to
download the missing artifacts from remote repos) but that ran
into many issues as well.
Not with 2.0.5 AFAICT.

With 3.0.1, there’s something messed up in the feature dependency
chain, or perhaps a mixture of the build and feature dependency
chain. I get the impression kar just gives up when it can’t
converge something, instead of failing the build, resulting in the
empty directories you’re seeing. Sticking to facts, if I add
explicit dependencies to aaa-karaf, I can progressively add more
dependencies in the distribution, and get further when building
and/or loading (building, because kar does resolve the OSGi
dependencies, so non-optional dependencies need to be fulfilled
correctly).

So far, I’ve got webconsole.http, webconsole, servlet-api,
pax-web-spi, pax-web-api, commons-io, xbean-finder, asm-all,
xbean-bundleutils, commons-fileupload, and I’m at
karaf.scr.management which is where everything blows up because
one part of the tree needs felix.scr >= 2 and another needs
felix.scr < 2.

Since Karaf 4.1.3 itself can build a fully-populated distribution
correctly, I’m guessing this is related to one of the odlparent
patches, or perhaps an invalid version in our dependency (invalid
as in conflicting with Karaf).

I’m still digging...

Regards,

Spelunky


Ryan Goulding <ryandgoulding@...>
 

it’s worth looking for empty directories just after a build and again
after running.

Is there a reason we still have "4.0.9" version references for "patches" in "opendaylight-karaf-resources".  For example, here is karaf-javax-mail-4.1.3.patch that refers to karaf version 4.0.9 in the patch file [0]?

Regards,

Ryan Goulding


On Thu, Dec 7, 2017 at 9:38 AM, Stephen Kitt <skitt@...> wrote:
Hi Ryan,

I have no idea unfortunately, I’m as stymied as you by jasypt. I’m
still trying to figure out why we lose
org.apache.karaf.webconsole.http... (I’m also running into refresh
issues with jline, which has the nice side-effect of killing the
console and stopping Karaf. Ho hum.)

One interesting tid-bit is that the empty directories appear in system
when Karaf tries to resolve a bundle at runtime, not at build time, so
it’s worth looking for empty directories just after a build and again
after running.

Regards,

Stephen


On Thu, 7 Dec 2017 09:23:16 -0500
Ryan Goulding <ryandgoulding@...> wrote:

> Hi Stephen,
>
> Did you happen to get a chance to look at this bundle refresh?  I am
> asking since it seems to be referring to a *jasypt* refresh, which
> AAA doesn't install AFAICT.  Admittedly, it is strange if SFT works
> with controller and not AAA due to this issue, especially since AAA
> involves security (jasypt is security related).  I found the
> jasypt-encryption [0] feature in upstream karaf, but it is not
> installed as a part of "standard".  Do you have any knowledge as to
> why this bundle is even installed in our distribution?  From my
> understanding, we are using bouncycastle, not jasypt, for JCE
> Provider.  No worries if you don't have any idea, I will keep digging.
>
> Thanks,
>
> Ryan Goulding
>
> [0]
> https://github.com/apache/karaf/blob/karaf-4.1.3/assemblies/features/standard/src/main/feature/feature.xml#L923
>
> On Wed, Dec 6, 2017 at 11:28 AM, Ryan Goulding
> <ryandgoulding@...> wrote:
>
> > Stephen,
> >
> > Yeah, I did the more rudimentary version of downloading jars
> > manually and sticking them in system.  I started to unravel that
> > and ran into similar results.
> >
> > We identified two issues during yesterday's Kernel Project's call.
> > 1) system/ is not populated properly, which Stephen is working as
> > stated in the above email. [0]
> >
> > 2) AAA SFT hangs.  [1] addresses the switch off jackson (fails
> > dist-check due to the fact RESTCONF in NETCONF depended on import
> > of some dependencies by AAA, so it will likely need a similar
> > transition to GSON too ).  With [1] layered on the upgrade patch
> > [2] I am still running into a terrible bundle refresh during SFT...
> > surefire log snippet here:
> >
> > Refreshing bundles:
> >     org.apache.aries.blueprint.cm/1.1.0 (Wired to
> > org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
> >     org.apache.aries.blueprint.core/1.8.3 (Attached fragments
> > changed: [org.apache.aries.blueprint.core.compatibility/1.0.0])
> >     org.apache.karaf.bundle.blueprintstate/4.1.3 (Wired to
> > org.apache.karaf.bundle.core/4.1.3 which is being refreshed)
> >     org.apache.karaf.bundle.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> >     org.apache.karaf.config.core/4.1.3 (Should be wired to:
> > org.apache.felix.metatype/1.1.6 (through
> > [org.apache.karaf.config.core/4.1.3] osgi.wiring.package;
> > filter:="(&(osgi.wiring.package=org.osgi.service.
> > metatype)(version>=1.2.0)(!(version>=2.0.0)))";
> > resolution:=optional)) org.apache.karaf.deployer.kar/4.1.3 (Wired
> > to org.apache.karaf.kar.core/4.1.3 which is being refreshed)
> > org.apache.karaf.diagnostic.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.features.command/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.instance.core/4.1.3 (Wired to
> > org.apache.karaf.features.command/4.1.3 which is being refreshed)
> > org.apache.karaf.jaas.blueprint.config/4.1.3 (Wired to
> > org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
> > org.apache.karaf.jaas.command/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.kar.core/4.1.3 (Wired to
> > org.apache.karaf.features. command/4.1.3 which is being refreshed)
> > org.apache.karaf.log.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.package.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.service.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.shell.commands/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.shell.console/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.shell.core/4.1.3 (Wired to
> > org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
> > org.apache.karaf.shell.ssh/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.system.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.servicemix.bundles.jasypt/1.9.2.1 (Should be wired to:
> > javax.servlet-api/3.1.0 (through
> > [org.apache.servicemix.bundles.jasypt/ 1.9.2.1]
> > osgi.wiring.package; filter:="(osgi.wiring.package=javax.servlet)";
> > resolution:=optional)) org.ops4j.pax.jdbc.config/1.1.0 (Wired to
> > org.apache.servicemix.bundles.jasypt/1.9.2.1 which is being
> > refreshed) org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 (Should
> > be wired to: javax.mail/1.4.4 (through
> > [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1]
> > osgi.wiring.package; filter:="(osgi.wiring.package=javax.mail)";
> > resolution:=optional), com.lmax.disruptor/3.3.7 (through
> > [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1]
> > osgi.wiring.package;
> > filter:="(osgi.wiring.package=com.lmax.disruptor)";
> > resolution:=optional), stax2-api/3.1.4 (through
> > [org.ops4j.pax.logging.pax- logging-log4j2/1.10.1]
> > osgi.wiring.package;
> > filter:="(osgi.wiring.package=org.codehaus.stax2)";
> > resolution:=optional))
> >
> > I do not believe AAA even brings in servicemix bundles, since
> > "servicemix" doesn't appear in the dependency tree.
> >
> > dev@dev:/code/ar2/autorelease/aaa$ mvn dependency:tree | grep -i
> > servicemix
> > dev@dev:/code/ar2/autorelease/aaa$
> >
> > Any thoughts on why this may be happening/possible steps forward?
> > Anything is appreciated as I am frankly stumped.
> >
> > Regards,
> >
> > Ryan Goulding
> >
> > [0] https://jira.opendaylight.org/browse/ODLPARENT-133
> > [1] https://git.opendaylight.org/gerrit/#/c/66056/
> > [2] https://git.opendaylight.org/gerrit/#/c/64196/
> >
> > On Wed, Dec 6, 2017 at 4:57 AM, Stephen Kitt <skitt@...>
> > wrote:
> >> On Mon, 4 Dec 2017 12:54:53 -0500
> >> Ryan Goulding <ryandgoulding@...> wrote:
> >> > I see the same thing.
> >> >
> >> > Stephen, has this happened with any other testing w/ odlparent
> >> > 2.0.5?  When I copy jars locally, I slowly get rid of error
> >> > messages.  That obviously isn't desirable.  I also tried to take
> >> > the default org.ops4j.pax.url.mvn.cfg and starting (in order to
> >> > download the missing artifacts from remote repos) but that ran
> >> > into many issues as well.
> >>
> >> Not with 2.0.5 AFAICT.
> >>
> >> With 3.0.1, there’s something messed up in the feature dependency
> >> chain, or perhaps a mixture of the build and feature dependency
> >> chain. I get the impression kar just gives up when it can’t
> >> converge something, instead of failing the build, resulting in the
> >> empty directories you’re seeing. Sticking to facts, if I add
> >> explicit dependencies to aaa-karaf, I can progressively add more
> >> dependencies in the distribution, and get further when building
> >> and/or loading (building, because kar does resolve the OSGi
> >> dependencies, so non-optional dependencies need to be fulfilled
> >> correctly).
> >>
> >> So far, I’ve got webconsole.http, webconsole, servlet-api,
> >> pax-web-spi, pax-web-api, commons-io, xbean-finder, asm-all,
> >> xbean-bundleutils, commons-fileupload, and I’m at
> >> karaf.scr.management which is where everything blows up because
> >> one part of the tree needs felix.scr >= 2 and another needs
> >> felix.scr < 2.
> >>
> >> Since Karaf 4.1.3 itself can build a fully-populated distribution
> >> correctly, I’m guessing this is related to one of the odlparent
> >> patches, or perhaps an invalid version in our dependency (invalid
> >> as in conflicting with Karaf).
> >>
> >> I’m still digging...
> >>
> >> Regards,
> >>
> >> Spelunky
> >>
> >
> >



Ryan Goulding <ryandgoulding@...>
 

For this example, I looked in compiled aaa/karaf/target/assembly/system/org/apache/karaf/features/standard/4.1.3/standard-4.1.3-features.xml and see:

        <bundle dependency="true" start-level="30">mvn:javax.mail/mail/1.4.5</bundle>

So if the intention was to maintain the downgrade of javax.mail in our 4.1.3 odl-karaf-empty distribution, that patch is not actually applied.  Could be totally unrelated but I saw that javax.mail was in the refresh wiring, so figured I'd point it out.

Regards,

Ryan Goulding

On Thu, Dec 7, 2017 at 10:01 AM, Ryan Goulding <ryandgoulding@...> wrote:
it’s worth looking for empty directories just after a build and again
after running.

Is there a reason we still have "4.0.9" version references for "patches" in "opendaylight-karaf-resources".  For example, here is karaf-javax-mail-4.1.3.patch that refers to karaf version 4.0.9 in the patch file [0]?

Regards,

Ryan Goulding


On Thu, Dec 7, 2017 at 9:38 AM, Stephen Kitt <skitt@...> wrote:
Hi Ryan,

I have no idea unfortunately, I’m as stymied as you by jasypt. I’m
still trying to figure out why we lose
org.apache.karaf.webconsole.http... (I’m also running into refresh
issues with jline, which has the nice side-effect of killing the
console and stopping Karaf. Ho hum.)

One interesting tid-bit is that the empty directories appear in system
when Karaf tries to resolve a bundle at runtime, not at build time, so
it’s worth looking for empty directories just after a build and again
after running.

Regards,

Stephen


On Thu, 7 Dec 2017 09:23:16 -0500
Ryan Goulding <ryandgoulding@...> wrote:

> Hi Stephen,
>
> Did you happen to get a chance to look at this bundle refresh?  I am
> asking since it seems to be referring to a *jasypt* refresh, which
> AAA doesn't install AFAICT.  Admittedly, it is strange if SFT works
> with controller and not AAA due to this issue, especially since AAA
> involves security (jasypt is security related).  I found the
> jasypt-encryption [0] feature in upstream karaf, but it is not
> installed as a part of "standard".  Do you have any knowledge as to
> why this bundle is even installed in our distribution?  From my
> understanding, we are using bouncycastle, not jasypt, for JCE
> Provider.  No worries if you don't have any idea, I will keep digging.
>
> Thanks,
>
> Ryan Goulding
>
> [0]
> https://github.com/apache/karaf/blob/karaf-4.1.3/assemblies/features/standard/src/main/feature/feature.xml#L923
>
> On Wed, Dec 6, 2017 at 11:28 AM, Ryan Goulding
> <ryandgoulding@...> wrote:
>
> > Stephen,
> >
> > Yeah, I did the more rudimentary version of downloading jars
> > manually and sticking them in system.  I started to unravel that
> > and ran into similar results.
> >
> > We identified two issues during yesterday's Kernel Project's call.
> > 1) system/ is not populated properly, which Stephen is working as
> > stated in the above email. [0]
> >
> > 2) AAA SFT hangs.  [1] addresses the switch off jackson (fails
> > dist-check due to the fact RESTCONF in NETCONF depended on import
> > of some dependencies by AAA, so it will likely need a similar
> > transition to GSON too ).  With [1] layered on the upgrade patch
> > [2] I am still running into a terrible bundle refresh during SFT...
> > surefire log snippet here:
> >
> > Refreshing bundles:
> >     org.apache.aries.blueprint.cm/1.1.0 (Wired to
> > org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
> >     org.apache.aries.blueprint.core/1.8.3 (Attached fragments
> > changed: [org.apache.aries.blueprint.core.compatibility/1.0.0])
> >     org.apache.karaf.bundle.blueprintstate/4.1.3 (Wired to
> > org.apache.karaf.bundle.core/4.1.3 which is being refreshed)
> >     org.apache.karaf.bundle.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> >     org.apache.karaf.config.core/4.1.3 (Should be wired to:
> > org.apache.felix.metatype/1.1.6 (through
> > [org.apache.karaf.config.core/4.1.3] osgi.wiring.package;
> > filter:="(&(osgi.wiring.package=org.osgi.service.
> > metatype)(version>=1.2.0)(!(version>=2.0.0)))";
> > resolution:=optional)) org.apache.karaf.deployer.kar/4.1.3 (Wired
> > to org.apache.karaf.kar.core/4.1.3 which is being refreshed)
> > org.apache.karaf.diagnostic.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.features.command/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.instance.core/4.1.3 (Wired to
> > org.apache.karaf.features.command/4.1.3 which is being refreshed)
> > org.apache.karaf.jaas.blueprint.config/4.1.3 (Wired to
> > org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
> > org.apache.karaf.jaas.command/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.kar.core/4.1.3 (Wired to
> > org.apache.karaf.features. command/4.1.3 which is being refreshed)
> > org.apache.karaf.log.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.package.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.service.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.shell.commands/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.shell.console/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.shell.core/4.1.3 (Wired to
> > org.apache.aries.blueprint.core/1.8.3 which is being refreshed)
> > org.apache.karaf.shell.ssh/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.karaf.system.core/4.1.3 (Wired to
> > org.apache.karaf.shell.core/4.1.3 which is being refreshed)
> > org.apache.servicemix.bundles.jasypt/1.9.2.1 (Should be wired to:
> > javax.servlet-api/3.1.0 (through
> > [org.apache.servicemix.bundles.jasypt/ 1.9.2.1]
> > osgi.wiring.package; filter:="(osgi.wiring.package=javax.servlet)";
> > resolution:=optional)) org.ops4j.pax.jdbc.config/1.1.0 (Wired to
> > org.apache.servicemix.bundles.jasypt/1.9.2.1 which is being
> > refreshed) org.ops4j.pax.logging.pax-logging-log4j2/1.10.1 (Should
> > be wired to: javax.mail/1.4.4 (through
> > [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1]
> > osgi.wiring.package; filter:="(osgi.wiring.package=javax.mail)";
> > resolution:=optional), com.lmax.disruptor/3.3.7 (through
> > [org.ops4j.pax.logging.pax-logging-log4j2/1.10.1]
> > osgi.wiring.package;
> > filter:="(osgi.wiring.package=com.lmax.disruptor)";
> > resolution:=optional), stax2-api/3.1.4 (through
> > [org.ops4j.pax.logging.pax- logging-log4j2/1.10.1]
> > osgi.wiring.package;
> > filter:="(osgi.wiring.package=org.codehaus.stax2)";
> > resolution:=optional))
> >
> > I do not believe AAA even brings in servicemix bundles, since
> > "servicemix" doesn't appear in the dependency tree.
> >
> > dev@dev:/code/ar2/autorelease/aaa$ mvn dependency:tree | grep -i
> > servicemix
> > dev@dev:/code/ar2/autorelease/aaa$
> >
> > Any thoughts on why this may be happening/possible steps forward?
> > Anything is appreciated as I am frankly stumped.
> >
> > Regards,
> >
> > Ryan Goulding
> >
> > [0] https://jira.opendaylight.org/browse/ODLPARENT-133
> > [1] https://git.opendaylight.org/gerrit/#/c/66056/
> > [2] https://git.opendaylight.org/gerrit/#/c/64196/
> >
> > On Wed, Dec 6, 2017 at 4:57 AM, Stephen Kitt <skitt@...>
> > wrote:
> >> On Mon, 4 Dec 2017 12:54:53 -0500
> >> Ryan Goulding <ryandgoulding@...> wrote:
> >> > I see the same thing.
> >> >
> >> > Stephen, has this happened with any other testing w/ odlparent
> >> > 2.0.5?  When I copy jars locally, I slowly get rid of error
> >> > messages.  That obviously isn't desirable.  I also tried to take
> >> > the default org.ops4j.pax.url.mvn.cfg and starting (in order to
> >> > download the missing artifacts from remote repos) but that ran
> >> > into many issues as well.
> >>
> >> Not with 2.0.5 AFAICT.
> >>
> >> With 3.0.1, there’s something messed up in the feature dependency
> >> chain, or perhaps a mixture of the build and feature dependency
> >> chain. I get the impression kar just gives up when it can’t
> >> converge something, instead of failing the build, resulting in the
> >> empty directories you’re seeing. Sticking to facts, if I add
> >> explicit dependencies to aaa-karaf, I can progressively add more
> >> dependencies in the distribution, and get further when building
> >> and/or loading (building, because kar does resolve the OSGi
> >> dependencies, so non-optional dependencies need to be fulfilled
> >> correctly).
> >>
> >> So far, I’ve got webconsole.http, webconsole, servlet-api,
> >> pax-web-spi, pax-web-api, commons-io, xbean-finder, asm-all,
> >> xbean-bundleutils, commons-fileupload, and I’m at
> >> karaf.scr.management which is where everything blows up because
> >> one part of the tree needs felix.scr >= 2 and another needs
> >> felix.scr < 2.
> >>
> >> Since Karaf 4.1.3 itself can build a fully-populated distribution
> >> correctly, I’m guessing this is related to one of the odlparent
> >> patches, or perhaps an invalid version in our dependency (invalid
> >> as in conflicting with Karaf).
> >>
> >> I’m still digging...
> >>
> >> Regards,
> >>
> >> Spelunky
> >>
> >
> >




Stephen Kitt <skitt@...>
 

On Thu, 7 Dec 2017 10:01:13 -0500
Ryan Goulding <ryandgoulding@...> wrote:
it’s worth looking for empty directories just after a build and
again after running.
Is there a reason we still have "4.0.9" version references for
"patches" in "opendaylight-karaf-resources". For example, here is
karaf-javax-mail-4.1.3.patch that refers to karaf version 4.0.9 in the
patch file [0]?
Yes, that’s fine, we explicitly specify the file to patch in the POM.

BTW I’ve fixed ODLPARENT-133, so we get webconsole.http in the
distribution (and everything else we need). There are still issues
loading odl-aaa-shiro though (the generated feature.xml is a mess).

Regards,

Stephen


Stephen Kitt <skitt@...>
 

On Thu, 7 Dec 2017 10:10:33 -0500
Ryan Goulding <ryandgoulding@...> wrote:
For this example, I looked in compiled
aaa/karaf/target/assembly/system/org/apache/karaf/features/standard/4.1.3/standard-4.1.3-features.xml
and see:

<bundle dependency="true"
start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>

So if the intention was to maintain the downgrade of javax.mail in our
4.1.3 odl-karaf-empty distribution, that patch is not actually
applied. Could be totally unrelated but I saw that javax.mail was in
the refresh wiring, so figured I'd point it out.
Good catch, we’re patching the jetty 8 feature but using the jetty 9
feature now AFAICT. So we need to patch that instead (or as well).

Regards,

Stephen


Robert Varga
 

Around javax.mail, I think we were downgrading it to keep things consistent -- not sure with what. It may be the time to revisit / upgrade it...


  Original Message  
From: skitt@...
Sent: December 7, 2017 6:57 PM
To: ryandgoulding@...
Cc: nite@...; aaa-dev@...; release@...
Subject: Re: [release] Upgrading to yangtools-2.0.0/odlparent-3.0.1

On Thu, 7 Dec 2017 10:10:33 -0500
Ryan Goulding <ryandgoulding@...> wrote:
For this example, I looked in compiled
aaa/karaf/target/assembly/system/org/apache/karaf/features/standard/4.1.3/standard-4.1.3-features.xml
and see:

         <bundle dependency="true"
start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>

So if the intention was to maintain the downgrade of javax.mail in our
4.1.3 odl-karaf-empty distribution, that patch is not actually
applied. Could be totally unrelated but I saw that javax.mail was in
the refresh wiring, so figured I'd point it out.
Good catch, we’re patching the jetty 8 feature but using the jetty 9
feature now AFAICT. So we need to patch that instead (or as well).

Regards,

Stephen


Stephen Kitt <skitt@...>
 

Exactly, I was going to check the situation without the patch, and if
we’re consistent, drop it entirely.


On Thu, 07 Dec 2017 19:25:14 +0100
Robert Varga <nite@...> wrote:

Around javax.mail, I think we were downgrading it to keep things
consistent -- not sure with what. It may be the time to revisit /
upgrade it...


  Original Message  
From: skitt@...
Sent: December 7, 2017 6:57 PM
To: ryandgoulding@...
Cc: nite@...; aaa-dev@...;
release@... Subject: Re: [release] Upgrading to
yangtools-2.0.0/odlparent-3.0.1

On Thu, 7 Dec 2017 10:10:33 -0500
Ryan Goulding <ryandgoulding@...> wrote:
For this example, I looked in compiled
aaa/karaf/target/assembly/system/org/apache/karaf/features/standard/4.1.3/standard-4.1.3-features.xml
and see:

         <bundle dependency="true"
start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>

So if the intention was to maintain the downgrade of javax.mail in
our 4.1.3 odl-karaf-empty distribution, that patch is not actually
applied. Could be totally unrelated but I saw that javax.mail was in
the refresh wiring, so figured I'd point it out.
Good catch, we’re patching the jetty 8 feature but using the jetty 9
feature now AFAICT. So we need to patch that instead (or as well).

Regards,

Stephen


Ryan Goulding <ryandgoulding@...>
 

Are there plans to release new odlparent and yangtools artifacts with these changes?  It is getting a bit cumbersome to compile and set up a local build reactor for these changes.

Regards,

Ryan Goulding

On Thu, Dec 7, 2017 at 2:06 PM, Stephen Kitt <skitt@...> wrote:
Exactly, I was going to check the situation without the patch, and if
we’re consistent, drop it entirely.


On Thu, 07 Dec 2017 19:25:14 +0100
Robert Varga <nite@...> wrote:

> Around javax.mail, I think we were downgrading  it to keep things
> consistent -- not sure with what. It may be the time to revisit /
> upgrade it...
>
>
>   Original Message  
> From: skitt@...
> Sent: December 7, 2017 6:57 PM
> To: ryandgoulding@...
> Cc: nite@...; aaa-dev@...;
> release@... Subject: Re: [release] Upgrading to
> yangtools-2.0.0/odlparent-3.0.1
>
> On Thu, 7 Dec 2017 10:10:33 -0500
> Ryan Goulding <ryandgoulding@...> wrote:
> > For this example, I looked in compiled
> > aaa/karaf/target/assembly/system/org/apache/karaf/features/standard/4.1.3/standard-4.1.3-features.xml
> > and see:
> >
> >         <bundle dependency="true"
> > start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>
> >
> > So if the intention was to maintain the downgrade of javax.mail in
> > our 4.1.3 odl-karaf-empty distribution, that patch is not actually
> > applied. Could be totally unrelated but I saw that javax.mail was in
> > the refresh wiring, so figured I'd point it out.
>
> Good catch, we’re patching the jetty 8 feature but using the jetty 9
> feature now AFAICT. So we need to patch that instead (or as well).
>
> Regards,
>
> Stephen



Stephen Kitt <skitt@...>
 

Yes, once I’ve figured out what all the changes are.

Regards,

Stephen


On Mon, 11 Dec 2017 09:38:51 -0500
Ryan Goulding <ryandgoulding@...> wrote:

Are there plans to release new odlparent and yangtools artifacts with
these changes? It is getting a bit cumbersome to compile and set up
a local build reactor for these changes.

Regards,

Ryan Goulding

On Thu, Dec 7, 2017 at 2:06 PM, Stephen Kitt <skitt@...> wrote:

Exactly, I was going to check the situation without the patch, and
if we’re consistent, drop it entirely.


On Thu, 07 Dec 2017 19:25:14 +0100
Robert Varga <nite@...> wrote:

Around javax.mail, I think we were downgrading it to keep things
consistent -- not sure with what. It may be the time to revisit /
upgrade it...


Original Message
From: skitt@...
Sent: December 7, 2017 6:57 PM
To: ryandgoulding@...
Cc: nite@...; aaa-dev@...;
release@... Subject: Re: [release] Upgrading to
yangtools-2.0.0/odlparent-3.0.1

On Thu, 7 Dec 2017 10:10:33 -0500
Ryan Goulding <ryandgoulding@...> wrote:
For this example, I looked in compiled
aaa/karaf/target/assembly/system/org/apache/karaf/
features/standard/4.1.3/standard-4.1.3-features.xml
and see:

<bundle dependency="true"
start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>

So if the intention was to maintain the downgrade of javax.mail
in our 4.1.3 odl-karaf-empty distribution, that patch is not
actually applied. Could be totally unrelated but I saw that
javax.mail was in the refresh wiring, so figured I'd point it
out.
Good catch, we’re patching the jetty 8 feature but using the
jetty 9 feature now AFAICT. So we need to patch that instead (or
as well).

Regards,

Stephen


Ryan Goulding <ryandgoulding@...>
 

AAA issues have been fixed by making a few changes to bouncycastle loading according to [0], and SFT now passes.

As discussed during the kernel projects call, we are going to start investigating the other critical projects identified here [1].  Unfortunately, I didn't realize our strategy didn't consider that doing the "critical priority" list projects like SFC involves doing it for all the various upstreams [2], so I am going to start on those first.


On Mon, Dec 11, 2017 at 9:53 AM, Stephen Kitt <skitt@...> wrote:
Yes, once I’ve figured out what all the changes are.

Regards,

Stephen


On Mon, 11 Dec 2017 09:38:51 -0500
Ryan Goulding <ryandgoulding@...> wrote:

> Are there plans to release new odlparent and yangtools artifacts with
> these changes?  It is getting a bit cumbersome to compile and set up
> a local build reactor for these changes.
>
> Regards,
>
> Ryan Goulding
>
> On Thu, Dec 7, 2017 at 2:06 PM, Stephen Kitt <skitt@...> wrote:
>
> > Exactly, I was going to check the situation without the patch, and
> > if we’re consistent, drop it entirely.
> >
> >
> > On Thu, 07 Dec 2017 19:25:14 +0100
> > Robert Varga <nite@...> wrote:
> >
> > > Around javax.mail, I think we were downgrading  it to keep things
> > > consistent -- not sure with what. It may be the time to revisit /
> > > upgrade it...
> > >
> > >
> > >   Original Message
> > > From: skitt@...
> > > Sent: December 7, 2017 6:57 PM
> > > To: ryandgoulding@...
> > > Cc: nite@...; aaa-dev@...;
> > > release@... Subject: Re: [release] Upgrading to
> > > yangtools-2.0.0/odlparent-3.0.1
> > >
> > > On Thu, 7 Dec 2017 10:10:33 -0500
> > > Ryan Goulding <ryandgoulding@...> wrote:
> > > > For this example, I looked in compiled
> > > > aaa/karaf/target/assembly/system/org/apache/karaf/
> > features/standard/4.1.3/standard-4.1.3-features.xml
> > > > and see:
> > > >
> > > >         <bundle dependency="true"
> > > > start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>
> > > >
> > > > So if the intention was to maintain the downgrade of javax.mail
> > > > in our 4.1.3 odl-karaf-empty distribution, that patch is not
> > > > actually applied. Could be totally unrelated but I saw that
> > > > javax.mail was in the refresh wiring, so figured I'd point it
> > > > out.
> > >
> > > Good catch, we’re patching the jetty 8 feature but using the
> > > jetty 9 feature now AFAICT. So we need to patch that instead (or
> > > as well).
> > >
> > > Regards,
> > >
> > > Stephen
> >
> >


Ryan Goulding <ryandgoulding@...>
 

Following instructions on [0] and running into this today:

dev@dev:/code/ar-odlparent3/controller$ mciq
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[WARNING] 'build.plugins.plugin.version' for org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 27, column 17
[WARNING] 'build.plugins.plugin.version' for org.codehaus.mojo:build-helper-maven-plugin is missing. @ org.opendaylight.controller.samples:clustering-it-config:[unknown-version], /code/ar-odlparent3/controller/opendaylight/md-sal/samples/clustering-test-app/configuration/pom.xml, line 21, column 17
[ERROR] 'dependencies.dependency.artifactId' for com.typesafe.akka:akka-actor_${scala.version}:jar with value 'akka-actor_${scala.version}' does not match a valid id pattern. @ line 57, column 19
[ERROR] 'dependencies.dependency.version' for com.typesafe.akka:akka-actor_${scala.version}:jar is missing. @ line 55, column 17
[ERROR] 'dependencies.dependency.artifactId' for com.typesafe.akka:akka-cluster_${scala.version}:jar with value 'akka-cluster_${scala.version}' does not match a valid id pattern. @ line 61, column 19
[ERROR] 'dependencies.dependency.version' for com.typesafe.akka:akka-cluster_${scala.version}:jar is missing. @ line 59, column 17
[ERROR] 'dependencies.dependency.artifactId' for com.typesafe.akka:akka-osgi_${scala.version}:jar with value 'akka-osgi_${scala.version}' does not match a valid id pattern. 

Can someone confirm if the controller patch needs updates?

Best Regards,

On Tue, Dec 12, 2017 at 2:19 PM, Ryan Goulding <ryandgoulding@...> wrote:
AAA issues have been fixed by making a few changes to bouncycastle loading according to [0], and SFT now passes.

As discussed during the kernel projects call, we are going to start investigating the other critical projects identified here [1].  Unfortunately, I didn't realize our strategy didn't consider that doing the "critical priority" list projects like SFC involves doing it for all the various upstreams [2], so I am going to start on those first.


Regards,

Ryan Goulding


On Mon, Dec 11, 2017 at 9:53 AM, Stephen Kitt <skitt@...> wrote:
Yes, once I’ve figured out what all the changes are.

Regards,

Stephen


On Mon, 11 Dec 2017 09:38:51 -0500
Ryan Goulding <ryandgoulding@...> wrote:

> Are there plans to release new odlparent and yangtools artifacts with
> these changes?  It is getting a bit cumbersome to compile and set up
> a local build reactor for these changes.
>
> Regards,
>
> Ryan Goulding
>
> On Thu, Dec 7, 2017 at 2:06 PM, Stephen Kitt <skitt@...> wrote:
>
> > Exactly, I was going to check the situation without the patch, and
> > if we’re consistent, drop it entirely.
> >
> >
> > On Thu, 07 Dec 2017 19:25:14 +0100
> > Robert Varga <nite@...> wrote:
> >
> > > Around javax.mail, I think we were downgrading  it to keep things
> > > consistent -- not sure with what. It may be the time to revisit /
> > > upgrade it...
> > >
> > >
> > >   Original Message
> > > From: skitt@...
> > > Sent: December 7, 2017 6:57 PM
> > > To: ryandgoulding@...
> > > Cc: nite@...; aaa-dev@...;
> > > release@... Subject: Re: [release] Upgrading to
> > > yangtools-2.0.0/odlparent-3.0.1
> > >
> > > On Thu, 7 Dec 2017 10:10:33 -0500
> > > Ryan Goulding <ryandgoulding@...> wrote:
> > > > For this example, I looked in compiled
> > > > aaa/karaf/target/assembly/system/org/apache/karaf/
> > features/standard/4.1.3/standard-4.1.3-features.xml
> > > > and see:
> > > >
> > > >         <bundle dependency="true"
> > > > start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>
> > > >
> > > > So if the intention was to maintain the downgrade of javax.mail
> > > > in our 4.1.3 odl-karaf-empty distribution, that patch is not
> > > > actually applied. Could be totally unrelated but I saw that
> > > > javax.mail was in the refresh wiring, so figured I'd point it
> > > > out.
> > >
> > > Good catch, we’re patching the jetty 8 feature but using the
> > > jetty 9 feature now AFAICT. So we need to patch that instead (or
> > > as well).
> > >
> > > Regards,
> > >
> > > Stephen
> >
> >



Ryan Goulding <ryandgoulding@...>
 

Would love a response from odlparent if those devs know something I am missing. I am more than happy to dig in Saturday also. On a plane almost all of tomorrow but have most of the weekend/ next week to explore. I “Reset” my local build reactor and still ran into the same issues in the previous mail... but admittedly didn’t deeply explore these failures due to competing time slots today with ONAP DDF.

Also a bit confused as to why in the current instructions we don’t have to version bump all projects’ odlparent dependencies to 3.0.2-SNAPSHOT. I may be missing something but AAA (and restconf) literally won’t work without these changes applied in step 1 of the instructions in [0] of the previous email... and the current patches listed assume 3.0.1. which was why we initially had issues with AAA. Please keep me honest if I am missing something completely here... or if I misunderstood the build instructions.

Very on board for getting us up and working on the new changes in odlparent and yangtools as soon as possible. Let’s keep this release on track! I’ll help whatever way possible, and will be on all next week to help us get there.

Thanks much in advance,
Ryan


On Dec 13, 2017, at 10:44 AM, Ryan Goulding <ryandgoulding@...> wrote:

Following instructions on [0] and running into this today:

dev@dev:/code/ar-odlparent3/controller$ mciq
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[WARNING] 'build.plugins.plugin.version' for org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 27, column 17
[WARNING] 'build.plugins.plugin.version' for org.codehaus.mojo:build-helper-maven-plugin is missing. @ org.opendaylight.controller.samples:clustering-it-config:[unknown-version], /code/ar-odlparent3/controller/opendaylight/md-sal/samples/clustering-test-app/configuration/pom.xml, line 21, column 17
[ERROR] 'dependencies.dependency.artifactId' for com.typesafe.akka:akka-actor_${scala.version}:jar with value 'akka-actor_${scala.version}' does not match a valid id pattern. @ line 57, column 19
[ERROR] 'dependencies.dependency.version' for com.typesafe.akka:akka-actor_${scala.version}:jar is missing. @ line 55, column 17
[ERROR] 'dependencies.dependency.artifactId' for com.typesafe.akka:akka-cluster_${scala.version}:jar with value 'akka-cluster_${scala.version}' does not match a valid id pattern. @ line 61, column 19
[ERROR] 'dependencies.dependency.version' for com.typesafe.akka:akka-cluster_${scala.version}:jar is missing. @ line 59, column 17
[ERROR] 'dependencies.dependency.artifactId' for com.typesafe.akka:akka-osgi_${scala.version}:jar with value 'akka-osgi_${scala.version}' does not match a valid id pattern. 

Can someone confirm if the controller patch needs updates?

Best Regards,

Ryan Goulding


On Tue, Dec 12, 2017 at 2:19 PM, Ryan Goulding <ryandgoulding@...> wrote:
AAA issues have been fixed by making a few changes to bouncycastle loading according to [0], and SFT now passes.

As discussed during the kernel projects call, we are going to start investigating the other critical projects identified here [1].  Unfortunately, I didn't realize our strategy didn't consider that doing the "critical priority" list projects like SFC involves doing it for all the various upstreams [2], so I am going to start on those first.


Regards,

Ryan Goulding


On Mon, Dec 11, 2017 at 9:53 AM, Stephen Kitt <skitt@...> wrote:
Yes, once I’ve figured out what all the changes are.

Regards,

Stephen


On Mon, 11 Dec 2017 09:38:51 -0500
Ryan Goulding <ryandgoulding@...> wrote:

> Are there plans to release new odlparent and yangtools artifacts with
> these changes?  It is getting a bit cumbersome to compile and set up
> a local build reactor for these changes.
>
> Regards,
>
> Ryan Goulding
>
> On Thu, Dec 7, 2017 at 2:06 PM, Stephen Kitt <skitt@...> wrote:
>
> > Exactly, I was going to check the situation without the patch, and
> > if we’re consistent, drop it entirely.
> >
> >
> > On Thu, 07 Dec 2017 19:25:14 +0100
> > Robert Varga <nite@...> wrote:
> >
> > > Around javax.mail, I think we were downgrading  it to keep things
> > > consistent -- not sure with what. It may be the time to revisit /
> > > upgrade it...
> > >
> > >
> > >   Original Message
> > > From: skitt@...
> > > Sent: December 7, 2017 6:57 PM
> > > To: ryandgoulding@...
> > > Cc: nite@...; aaa-dev@...;
> > > release@... Subject: Re: [release] Upgrading to
> > > yangtools-2.0.0/odlparent-3.0.1
> > >
> > > On Thu, 7 Dec 2017 10:10:33 -0500
> > > Ryan Goulding <ryandgoulding@...> wrote:
> > > > For this example, I looked in compiled
> > > > aaa/karaf/target/assembly/system/org/apache/karaf/
> > features/standard/4.1.3/standard-4.1.3-features.xml
> > > > and see:
> > > >
> > > >         <bundle dependency="true"
> > > > start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>
> > > >
> > > > So if the intention was to maintain the downgrade of javax.mail
> > > > in our 4.1.3 odl-karaf-empty distribution, that patch is not
> > > > actually applied. Could be totally unrelated but I saw that
> > > > javax.mail was in the refresh wiring, so figured I'd point it
> > > > out.
> > >
> > > Good catch, we’re patching the jetty 8 feature but using the
> > > jetty 9 feature now AFAICT. So we need to patch that instead (or
> > > as well).
> > >
> > > Regards,
> > >
> > > Stephen
> >
> >



Tom Pantelis
 

On Thu, Dec 14, 2017 at 12:49 AM, Ryan Goulding <ryandgoulding@...> wrote:
Would love a response from odlparent if those devs know something I am missing. I am more than happy to dig in Saturday also. On a plane almost all of tomorrow but have most of the weekend/ next week to explore. I “Reset” my local build reactor and still ran into the same issues in the previous mail... but admittedly didn’t deeply explore these failures due to competing time slots today with ONAP DDF.

Also a bit confused as to why in the current instructions we don’t have to version bump all projects’ odlparent dependencies to 3.0.2-SNAPSHOT. I may be missing something but AAA (and restconf) literally won’t work without these changes applied in step 1 of the instructions in [0] of the previous email... and the current patches listed assume 3.0.1. which was why we initially had issues with AAA. Please keep me honest if I am missing something completely here... or if I misunderstood the build instructions.

Very on board for getting us up and working on the new changes in odlparent and yangtools as soon as possible. Let’s keep this release on track! I’ll help whatever way possible, and will be on all next week to help us get there.

Thanks much in advance,
Ryan


On Dec 13, 2017, at 10:44 AM, Ryan Goulding <ryandgoulding@...> wrote:

Following instructions on [0] and running into this today:

dev@dev:/code/ar-odlparent3/controller$ mciq
[INFO] Scanning for projects...
[ERROR] [ERROR] Some problems were encountered while processing the POMs:
[WARNING] 'build.plugins.plugin.version' for org.codehaus.mojo:build-helper-maven-plugin is missing. @ line 27, column 17
[WARNING] 'build.plugins.plugin.version' for org.codehaus.mojo:build-helper-maven-plugin is missing. @ org.opendaylight.controller.samples:clustering-it-config:[unknown-version], /code/ar-odlparent3/controller/opendaylight/md-sal/samples/clustering-test-app/configuration/pom.xml, line 21, column 17
[ERROR] 'dependencies.dependency.artifactId' for com.typesafe.akka:akka-actor_${scala.version}:jar with value 'akka-actor_${scala.version}' does not match a valid id pattern. @ line 57, column 19
[ERROR] 'dependencies.dependency.version' for com.typesafe.akka:akka-actor_${scala.version}:jar is missing. @ line 55, column 17
[ERROR] 'dependencies.dependency.artifactId' for com.typesafe.akka:akka-cluster_${scala.version}:jar with value 'akka-cluster_${scala.version}' does not match a valid id pattern. @ line 61, column 19
[ERROR] 'dependencies.dependency.version' for com.typesafe.akka:akka-cluster_${scala.version}:jar is missing. @ line 59, column 17
[ERROR] 'dependencies.dependency.artifactId' for com.typesafe.akka:akka-osgi_${scala.version}:jar with value 'akka-osgi_${scala.version}' does not match a valid id pattern. 

Can someone confirm if the controller patch needs updates?

Best Regards,

Ryan Goulding


On Tue, Dec 12, 2017 at 2:19 PM, Ryan Goulding <ryandgoulding@...> wrote:
AAA issues have been fixed by making a few changes to bouncycastle loading according to [0], and SFT now passes.

As discussed during the kernel projects call, we are going to start investigating the other critical projects identified here [1].  Unfortunately, I didn't realize our strategy didn't consider that doing the "critical priority" list projects like SFC involves doing it for all the various upstreams [2], so I am going to start on those first.


Regards,

Ryan Goulding


On Mon, Dec 11, 2017 at 9:53 AM, Stephen Kitt <skitt@...> wrote:
Yes, once I’ve figured out what all the changes are.

Regards,

Stephen


On Mon, 11 Dec 2017 09:38:51 -0500
Ryan Goulding <ryandgoulding@...> wrote:

> Are there plans to release new odlparent and yangtools artifacts with
> these changes?  It is getting a bit cumbersome to compile and set up
> a local build reactor for these changes.
>
> Regards,
>
> Ryan Goulding
>
> On Thu, Dec 7, 2017 at 2:06 PM, Stephen Kitt <skitt@...> wrote:
>
> > Exactly, I was going to check the situation without the patch, and
> > if we’re consistent, drop it entirely.
> >
> >
> > On Thu, 07 Dec 2017 19:25:14 +0100
> > Robert Varga <nite@...> wrote:
> >
> > > Around javax.mail, I think we were downgrading  it to keep things
> > > consistent -- not sure with what. It may be the time to revisit /
> > > upgrade it...
> > >
> > >
> > >   Original Message
> > > From: skitt@...
> > > Sent: December 7, 2017 6:57 PM
> > > To: ryandgoulding@...
> > > Cc: nite@...; aaa-dev@...;
> > > release@... Subject: Re: [release] Upgrading to
> > > yangtools-2.0.0/odlparent-3.0.1
> > >
> > > On Thu, 7 Dec 2017 10:10:33 -0500
> > > Ryan Goulding <ryandgoulding@...> wrote:
> > > > For this example, I looked in compiled
> > > > aaa/karaf/target/assembly/system/org/apache/karaf/
> > features/standard/4.1.3/standard-4.1.3-features.xml
> > > > and see:
> > > >
> > > >         <bundle dependency="true"
> > > > start-level="30">mvn:javax.mail/mail/ *1.4.5*</bundle>
> > > >
> > > > So if the intention was to maintain the downgrade of javax.mail
> > > > in our 4.1.3 odl-karaf-empty distribution, that patch is not
> > > > actually applied. Could be totally unrelated but I saw that
> > > > javax.mail was in the refresh wiring, so figured I'd point it
> > > > out.
> > >
> > > Good catch, we’re patching the jetty 8 feature but using the
> > > jetty 9 feature now AFAICT. So we need to patch that instead (or
> > > as well).
> > >
> > > Regards,
> > >
> > > Stephen
> >
> >



_______________________________________________
release mailing list
release@...
https://lists.opendaylight.org/mailman/listinfo/release