Trunk build failed with this error when building a new module *Geronimo Framework, Feature :: DS and Metatype*
[INFO] Internal error in the plugin manager executing goal 'org.apache.karaf.tooling:karaf-maven-plugin:3.0.0-SNAPSHOT:features-generate-descriptor': Unable to find the mojo 'features-generate-descriptor' (or one of its required components) in the plugin 'org.apache.karaf.tooling:karaf-maven-plugin' Component descriptor cannot be found in the component repository: org.sonatype.aether.RepositorySystem. On Tue, Dec 20, 2011 at 2:06 PM, David Jencks <[email protected]>wrote: > BTW, to get the regions/isolation stuff working I think we are going to > need to replace our use of BundleListener/SynchronousBundleListener with > the (updated-for-4.3) aries RecursiveBundleTracker. I think we'll need > also change from ConfigurationActivator to an extender pattern. I'd guess > the ConfigurationActivator functionality could be moved to > DependencyManager rather than having an additional tracker. > > thanks > david jencks > > On Dec 20, 2011, at 10:13 AM, David Jencks wrote: > > OK, I just committed this stuff, with reference to > GERONIMO-6240<https://issues.apache.org/jira/browse/GERONIMO-6240> > . > > Some more hints.... > > I can build all the way through with > MAVEN_OPTS="-XX:MaxPermSize=2048m -Xms2048m -Xmx4096m" > > I can start karaf after setting > > export JAVA_MAX_MEM=2048m > export JAVA_MAX_PERM_MEM=512m > > The car packaging is set up to stop and wait if it gets stuck. In an > earlier version of this you'd get the karaf console and you could use karaf > commands to investigate what was going on. For some reason this isn't > working now. If you get into this situation, you need to kill the maven > java process some way. Usually setting a breakpoint at DependencyManager > line 571 will show you a bundle that has a resolution problem that you can > then fix. > > The problem with the console deploy-type commands I think relates to using > the karaf RMIRegistry. I'm going to modify it so it includes the port as a > service property, then we can look for the osgi service and get its port > instead of the port gbean attribute. > > thanks > david jencks > > On Dec 19, 2011, at 9:10 PM, David Jencks wrote: > > more not-yet-working inline > > On Dec 19, 2011, at 5:08 PM, David Jencks wrote: > > I've been spending a lot of time working to rebase geronimo on karaf 3 so > we can have a maintainable future and get stuff like osgi 4.3, up to date > aries components, and the experimental region support now in karaf. > > > After a lot of work I have everything except clustering building and after > turning off a couple problematic modules the tomcat-javaee6 server starts > and the web admin console appears to work at least a little bit. I'd like > a little vacation this year and would like to commit this work first so > that others can help with the loose ends if they like. I'll probably be > around to answer questions in any case. > > > The modules that don't start are: > > > activemq-broker-blueprint. The ${X + Y} stuff is not getting evaluated at > all. I don't know if this is an xbean-blueprint problem or an aries > blueprint problem or a side effect of running in geronimo. > > As a result activemq-ra and tomcat-console-activemq can't be started. > > > client-deployer. I think this is a pretty simple gbean name problem but I > haven't looked into it. > > > > Here are some of the changes: > > > -- assemble the server using a combination of karaf assembly from features > and kars and geronimo assembly from geronimo plugins. We now use the same > base karaf assembly stuff as the normal default full karaf assembly (except > I might have left out the spring feature repository). > > > -- basic geronimo components such as the kernel, configuration manager, > dependency manager, deployer, and service config builder are set up as osgi > declarative services so they start without any geronimo configuration. > They are generally configured through config admin as appropriate. Most > of these also have gbean wrappers so they can be accessed through gbean > references. > > > -- "geronimo" is started from a DS component, EmbeddedDaemon. > > > -- I think I'm using the karaf remote jmx security rather than ours. The > capabilities are similar but not identical. > > > Some other things that are not working yet: > > > -- The (gogo) geronimo console commands that work through "remote" gbean > proxies don't work AFAIK. Probably one way to fix this would be to expose > some more of the DS components using gbean wrappers, but I haven't looked > into this yet. > > > -- the app client (as well as the client-deployer) is not working yet at > all. We may be able to use command line args to tell the EmbeddedDaemon > it's an app client, or possibly not. We may be able to use a karaf > instance to supply different ConfigAdmin settings to e.g. the local > attribute manager to convince it it's an app client. Similarly the > separate console-like things presumably won't work either. > > > -- the EditableConfigurationManager needs to be replaced by a separate > component that edits the configuration it gets from the normal > configuration manager. I think this affects some part of the admin console. > > > --I couldn't get the xml stream 1.2 and jaxb 2.2 to work with the spec > jars as bundles. According to > http://servicemix.396122.n5.nabble.com/DISCUSS-Enhance-specs-to-work-better-with-JRE-td5001108.htmleven > if you do get them to work (as we seem to have up to now by not > exposing the packages from the framework) that breaks other stuff. I think > we need to investigate the karaf-activator stuff guillaume wrote and adapt > our specs to use it. At the moment I have the framework lying and claiming > later versions for the xmlstream and jaxb packages. I haven't found any > documentation for karaf-activator yet. > > -- the build uses a lot more memory. I typically run out of permgen twice > during the build with MAVEN_OPTS = -XX:MaxPermSize=512m -Xms1024m -Xmx2048m > > -- startup AFAIK only works as ./bin/karaf -l rather than our geronimo > scripts. Again, I have to increase memory settings for the server to fully > start. > > > > I'f there's no strong opposition I'd like to commit this tomorrow. > > > Many thanks > > david jencks > > > > david jencks > > > > -- Thanks! Regards, Forrest
