On Mon, Mar 13, 2017 at 6:00 PM, Frank Sandoval <francisrsando...@gmail.com> wrote:
> Mac OS > I am doing the build from the top dir, in this case <local>/eman/ > > when I execute >mvn install, the > eman/karaf/target/assembly/etc/custom.properties > contains the following 104 lines > it looks like, for some reason I can't explain, you manage to get this much shortened custom.propertie, and when you do "mvn install", without clean, then karaf/target/assembly/etc/custom.properties does not get overwritten... .. the best is to always use clean - but read on below, first. ——————————————————————— > ############################################################ > #################### > # > # Licensed to the Apache Software Foundation (ASF) under one or more > # contributor license agreements. See the NOTICE file distributed with > # this work for additional information regarding copyright ownership. > # The ASF licenses this file to You under the Apache License, Version > 2.0 > # (the "License"); you may not use this file except in compliance with > # the License. You may obtain a copy of the License at > # > # http://www.apache.org/licenses/LICENSE-2.0 > # > # Unless required by applicable law or agreed to in writing, software > # distributed under the License is distributed on an "AS IS" BASIS, > # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > implied. > # See the License for the specific language governing permissions and > # limitations under the License. > # > ############################################################ > #################### > > # > # All the values specified here will override the default values given > # in config.properties. > # > > karaf.systemBundlesStartLevel=50 > > # > # You can place any customized configuration here. > # > that's a lot less than 104 lines, but that was probably just a typo? when I execute >mvn clean install the eman/karaf/target/assembly/etc/custom.properties > contains the following 104 lines > that looks like the full correct one! So, initially, just do "mvn -Pq clean install" on the top-level eman directory, e.g. after a pull from master when you'd like to develop something. But I think your real question between the lines here is what an efficient workflow is if you've made local changes to 1 bundle, say eman/impl, is it? In that case, there is no need to do a full "mvn -Pq clean install" on the top-level eman directory anymore... What you can do in that scenario, is you stop your Karaf, you "cd impl" and just "mvn -o -Pq -DaddInstallRepositoryPath=../karaf/target/assembly/system clean install" that single bundle, and restart your Karaf. I'm not sure how many people know about this (probably not enough) and use this regularly, but I had documented it e.g. on https://wiki.opendaylight.org/view/CrossProject:Integration_Group:karaf#Getting_your_code_into_Karaf_.28for_developers.3B_-DaddInstallRepositoryPath_.2F_addInstallRepositoryPath.29 and in the ODL Summit presentation https://docs.google.com/presentation/d/1bnwj8CrFGo5KekONYSeIHySdkoXZiewJxkHcZjXnzkQ/edit#slide=id.g1136ac16d2_1_13 NB that "hot reloading" (bundle:watch *) is known not work well in general, due to various possible issues (although you're welcome to try if it does work for your particular bundle). But even stopping and restarting Karaf, as above, but not having to do a full rebuild from root of everything incl. complete fresh karaf/ dist for every small change, is very helpful I guess. HTH. > ------------------------------------------------- > > # Extra packages to import from the boot class loader > org.osgi.framework.system.packages.extra=org.apache. > karaf.branding,sun.reflect,sun.reflect.misc,sun.misc,sun.nio.ch > ,com.sun.media.sound > > # https://bugs.eclipse.org/bugs/show_bug.cgi?id=325578 > # Extend the framework to avoid the resources to be presented with > # a URL of type bundleresource: but to be presented as file: > osgi.hook.configurators.include=org.eclipse.virgo. > kernel.equinox.extensions.hooks.ExtensionsHookConfigurator > > # Embedded Tomcat configuration File > org.eclipse.gemini.web.tomcat.config.path=configuration/tomcat-server.xml > org.apache.tomcat.util.buf.UDecoder.ALLOW_ENCODED_SLASH=true > > # Use Equinox as default OSGi Framework Implementation > karaf.framework=equinox > > # Show a progress bar on startup and start the console when all bundles > are up and running. > # (If you are in a hurry you can still type enter to start the shell > faster.) > karaf.delay.console=true > > # Set security provider to BouncyCastle > org.apache.karaf.security.providers = org.bouncycastle.jce.provider. > BouncyCastleProvider > > # We set this to false to disable the Aries BlueprintExtender from doing > its orderly container > # shutdown so we can do it after the CSS has shut down all its modules. > Otherwise Aries will > # shutdown blueprint containers when the karaf framework starts shutdown > (ie when bundle 0 is > # stopped) which can cause failures on CSS module shutdown due to the core > blueprint containers > # and services already being shut down. This setting can be removed > when/if CSS is removed > # completely from ODL. > org.apache.aries.blueprint.preemptiveShutdown=false > > netconf.config.persister.active=1 > > netconf.config.persister.1.storageAdapterClass=org. > opendaylight.controller.config.persist.storage.file. > xml.XmlFileStorageAdapter > netconf.config.persister.1.properties.fileStorage=etc/ > opendaylight/current/controller.currentconfig.xml > netconf.config.persister.1.properties.numberOfBackups=1 > > # logback configuration > logback.configurationFile=configuration/logback.xml > > # Container configuration > container.profile = Container > > # Connection manager configuration > connection.scheme = ANY_CONTROLLER_ONE_MASTER > > # OVSDB configuration > # ovsdb plugin supports both active and passive connections. It listens on > port 6640 by default for Active connections. > ovsdb.listenPort=6640 > > # ovsdb creates Openflow nodes/bridges. This configuration configures the > bridge's Openflow version. > # default Openflow version = 1.0, we also support 1.3. > # ovsdb.of.version=1.3 > > # ovsdb can be configured with ml2 to perform l3 forwarding. The config > below enables that functionality, which is > # disabled by default. > # ovsdb.l3.fwd.enabled=yes > > # ovsdb can be configured with ml2 to perform arp responder, enabled by > default. > ovsdb.l3.arp.responder.disabled=no > > # ovsdb can be configured with ml2 to perform l3 forwarding. When used in > that scenario, the mac address of the default > # gateway --on the external subnet-- is expected to be resolved from its > inet address. The config below overrides that > # specific arp/neighDiscovery lookup. > # ovsdb.l3gateway.mac=00:00:5E:00:02:01 > > # TLS configuration > # To enable TLS, set secureChannelEnabled=true and specify the location of > controller Java KeyStore and TrustStore files. > # The Java KeyStore contains controller's private key and certificate. The > Java TrustStore contains the trusted certificate > # entries, including switches' Certification Authority (CA) certificates. > For example, > # secureChannelEnabled=true > # controllerKeyStore=./configuration/ctlKeyStore > # controllerKeyStorePassword=xxxxxxxx (this password should match the > password used for KeyStore generation and at least 6 characters) > # controllerTrustStore=./configuration/ctlTrustStore > # controllerTrustStorePassword=xxxxxxxx (this password should match the > password used for TrustStore generation and at least 6 characters) > > secureChannelEnabled=false > controllerKeyStore= > controllerKeyStorePassword= > controllerTrustStore= > controllerTrustStorePassword= > > # User Manager configurations > enableStrongPasswordCheck = false > > #Jolokia configurations > #org.jolokia.listenForHttpService=false > > # Logging configuration for Tomcat-JUL logging > java.util.logging.config.file=configuration/tomcat-logging.properties > > #Hosttracker hostsdb key scheme setting > hosttracker.keyscheme=IP > > # LISP Flow Mapping configuration > # Enable merging RLOC sets received from different xTR-IDs for the same > EID (default: false) > lisp.mappingMerge = false > # Enable the Solicit-Map-Request (SMR) mechanism (default: true) > lisp.smr = true > # Choose policy for Explicit Locator Path (ELP) handling > # There are three options: > # default: don't add or remove locator records, return mapping as-is > # both: keep the ELP, but add the next hop as a standalone non-LCAF > locator with a lower priority > # replace: remove the ELP, add the next hop as a standalone non-LCAF > locator > lisp.elpPolicy = default > > > > *Frank Sandoval* > Principal - Pajarito Technologies LLC > email: francisrsando...@gmail.com > mobile: 720 338-1988 <%28720%29%20338-1988> > > > > > On Mar 13, 2017, at 10:48 AM, Michael Vorburger <vorbur...@redhat.com> > wrote: > > On Mon, Mar 13, 2017 at 5:37 PM, Frank Sandoval < > francisrsando...@gmail.com> wrote: > > It appears that when I simply execute > mvn install >> then the attached custom.properties file is the result >> > > just FTR, because attachments get lsot in threads, what you attached has > an ASL header and comment "All the values specified here will override the > default values given in config.properties." and > karaf.systemBundlesStartLevel=50 and comment "You can place any > customized configuration here." and nothing else. > > So let's try to narrow this down a bit... exactly WHERE do you do "mvn > install", of what? And maybe also detail on what "environment" you run this > on.. e.g. Linux or Windows? > > As I said, when I (and I'm guessing everyone else) do a "mvn install" e.g. > in "netvirt/vpnservice/distribution/karaf" of current git master, then > "wc -l target/assembly/etc/config.properties" is 270 lines. We need to > narrow down that's different for you. > > >> I can simply overwrite this with an original version, but of course would >> prefer to fix the issue >> Any ideas of what is happening and how to prevent it? >> > > Now this seems to be a slightly different issue: > > I’d like to avoid a time consuming ‘clean install’ every time I change a >> line of code >> If I make a change to my code, shouldn’t I be able to build with > mvn >> install -DskipTests -nsu ? >> > > could it be that we are confusing the discussion between a) building a > Karaf distribution, b) building a bundle JAR? > > you can use mvn -Pq install to activate the "quick" build profile, for > both a) and b) which skips a number of things. > > There are also ways to install just 1 bundle you're working on into an > existing Karaf. But I think you have a more fundamental problem (the > strange etc/config.properties), before we get to anything like that. > > >> >> *Frank Sandoval* >> Principal - Pajarito Technologies LLC >> email: francisrsando...@gmail.com >> mobile: 720 338-1988 <%28720%29%20338-1988> >> >> >> >> >> On Mar 13, 2017, at 9:42 AM, Robert Varga <n...@hq.sk> wrote: >> >> On 03/13/2017 04:37 PM, Michael Vorburger wrote: >> >> You would need to find out what truncates etc/custom.properties like >> that... Out of curiosity, I did try to start, check, Ctrl-D a Karaf I've >> just built today (from netvirt/vpnservice/distribution/karaf), and >> feature:install odl-netvirt-openstack into, and can't repro this. >> (Obviously.. otherwise everything would be broken.) >> >> It's possible there is some.. rogue (?) code somewhere in some feature >> you install which is causing this... you should try to find some >> reliable way to reproduce it, if you can at all. >> >> >> Definitely rogue, custom.properties is logically owned by odlparent. It >> contains critical platform setup and we cannot have anyone (aside from >> operator, who knows what she's doing) mucking with it -- otherwise this >> sort of thing is bound to happen. >> >> Regards, >> Robert >> >> >> >> > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
