Re: Oracle Mobile application framework
Hi Peter: I’m not sure if supporting MAF is critical to River’s success, but even so I am in favour of removing the examples from the JTSK build. Anyone else have an opinion? I’m curious though, why it’s the browser specifically that doesn’t build - what did you find? Cheers, Greg. On Feb 13, 2015, at 6:59 PM, Peter wrote: > Maf 2.1.0 supports java 8 compact profile 2. > > If I remove the browser example from qa-refactor it builds on this profile. > > Greg, if your including the browser in the river examples project, I can > delete it? > > If so, we can support iphone and android. > > Regards, > > Peter.
Oracle Mobile application framework
Maf 2.1.0 supports java 8 compact profile 2. If I remove the browser example from qa-refactor it builds on this profile. Greg, if your including the browser in the river examples project, I can delete it? If so, we can support iphone and android. Regards, Peter.
Re: Build troubles
Hi Mike, Which build & platform? Regards, Peter. - Original message - > Following along in https://river.apache.org/building-river.html, I > > $ cd $RIVER_HOME > $ ant > > ... > > jsk-dl.jar: > [java] Exception in thread "main" > java.lang.ArrayIndexOutOfBoundsException: 5735 > [java] at org.objectweb.asm.ClassReader.readClass(Unknown > Source) [java] at > org.objectweb.asm.ClassReader.accept(Unknown > Source) [java] at > org.objectweb.asm.ClassReader.accept(Unknown > Source) [java] at > com.sun.jini.tool.classdepend.ReferencedClasses.compute(ReferencedClasses.java:56) > [java] at > com.sun.jini.tool.classdepend.ClassDepend.getDependencyRelationshipMap(ClassDepend.java:283) > [java] at >com.sun.jini.tool.ClassDep.compute(ClassDep.java:885) > [java] at >com.sun.jini.tool.ClassDep.main(ClassDep.java:1329) > > BUILD FAILED > > Anyone else seen this? Workarounds? Or is Maven the preferred way to > build now? > > -- > Mike Morris > http://mikro2nd.net/ > EarthStuff: http://blog.mikro2nd.net/ > TechStuff : http://onemikro2nd.blogspot.com/
Re: Build troubles
Hi Mike: What you’re running into is the fact that part of River’s build system (classdep, in fact) uses the ASM library, and that library changed significantly between Java 7 and Java 8. The net result is that the 2.2.2 release does not build under JDK8. If you have a JDK7 installation around, it should work under that. Patches have been contributed to fix the build system for JDK8, but personally, I’ve been concentrating on the river-examples project rather than patching and releasing the JTSK. I’m not sure if anyone else has plans to do it immediately. If not, I’ll probably get to it once the river-examples project is released. I also started down the path of pulling the tools packages out of the JTSK (similar to your suggestions in another thread), but the package relationships are convoluted enough that I decided to work on the examples project first. You asked “Is Maven the preferred way to build now?” That’s an interesting question - I’d say no, but Maven Central is the preferred way to get the binaries. In other words, I would tend to discourage you from actually building the distribution from source. Not discourage you really, but I’d point out that if you can use the jars from Maven Central, then you don’t need to deal with the somewhat complex and non-JDK8-compatible build system in River. And really, unless you’re hacking on the core, why do you need to build River itself? The various artifacts are listed at http://river.apache.org/maven-artifacts.html So in building a project that “uses” River, I’d suggest using Maven, Gradle, or Apache Ivy with Ant, each of which can retrieve artifacts from Maven Central. There is also the binary distribution that has the jars already compiled, if you’re dead set against going to Maven Central. Cheers, Greg Trasuk On Feb 13, 2015, at 9:47 AM, Mike wrote: > Following along in https://river.apache.org/building-river.html, I > > $ cd $RIVER_HOME > $ ant > > ... > > jsk-dl.jar: > [java] Exception in thread "main" > java.lang.ArrayIndexOutOfBoundsException: 5735 > [java] at org.objectweb.asm.ClassReader.readClass(Unknown Source) > [java] at org.objectweb.asm.ClassReader.accept(Unknown Source) > [java] at org.objectweb.asm.ClassReader.accept(Unknown Source) > [java] at > com.sun.jini.tool.classdepend.ReferencedClasses.compute(ReferencedClasses.java:56) > [java] at > com.sun.jini.tool.classdepend.ClassDepend.getDependencyRelationshipMap(ClassDepend.java:283) > [java] at com.sun.jini.tool.ClassDep.compute(ClassDep.java:885) > [java] at com.sun.jini.tool.ClassDep.main(ClassDep.java:1329) > > BUILD FAILED > > Anyone else seen this? Workarounds? Or is Maven the preferred way to build > now? > > -- > Mike Morris > http://mikro2nd.net/ > EarthStuff: http://blog.mikro2nd.net/ > TechStuff : http://onemikro2nd.blogspot.com/
Build troubles
Following along in https://river.apache.org/building-river.html, I $ cd $RIVER_HOME $ ant ... jsk-dl.jar: [java] Exception in thread "main" java.lang.ArrayIndexOutOfBoundsException: 5735 [java] at org.objectweb.asm.ClassReader.readClass(Unknown Source) [java] at org.objectweb.asm.ClassReader.accept(Unknown Source) [java] at org.objectweb.asm.ClassReader.accept(Unknown Source) [java] at com.sun.jini.tool.classdepend.ReferencedClasses.compute(ReferencedClasses.java:56) [java] at com.sun.jini.tool.classdepend.ClassDepend.getDependencyRelationshipMap(ClassDepend.java:283) [java] at com.sun.jini.tool.ClassDep.compute(ClassDep.java:885) [java] at com.sun.jini.tool.ClassDep.main(ClassDep.java:1329) BUILD FAILED Anyone else seen this? Workarounds? Or is Maven the preferred way to build now? -- Mike Morris http://mikro2nd.net/ EarthStuff: http://blog.mikro2nd.net/ TechStuff : http://onemikro2nd.blogspot.com/
Re: Chopping the codebase into bite-size pieces.
On 13/02/15 15:26, Patricia Shanahan wrote: Have you looked at the "River-examples project" thread? The objective is to create a better "getting started" experience LOL - just started trawling through it. I did kick Jini around a decade and a half ago, so didn't need to go through the "getting started" pains so much as I could remember quite a bit of what I needed to do, up to writing a silly little test service (RandomNumberSupplier with - so far - 2 different proxy implementations.) It should be tested by as many different people in different environments as possible. I fear that I may not have sufficient time to contribute much on that front, but will certainly keep it in mind should time permit. I'm in a Linux-only world, here, if that's a useful testbed. -- Mike Morris http://mikro2nd.net/ EarthStuff: http://blog.mikro2nd.net/ TechStuff : http://onemikro2nd.blogspot.com/
Re: Chopping the codebase into bite-size pieces.
Regardless of whether we actually reorganize the code base, I think something like this would be useful high level documentation for giving an idea of how things fit together. Have you looked at the "River-examples project" thread? The objective is to create a better "getting started" experience, centered on a simple worked example. It should be tested by as many different people in different environments as possible. Thanks, Patricia On 2/13/2015 5:13 AM, Mike wrote: As part of shaking the rust from my aging memory, and with my minds-eye looking towards a more modular code experience for Jini/River, I drew up a small diagram of how things look to me/how I think the codebase could be chopped up into smaller sub-projects (with dependencies). https://drive.google.com/file/d/0B_JitrvGE8NMWnhRSWhFVW9MSWM/view?usp=sharing It might also be a little help to people confronting the rather daunting codebase for the first time, or even just for understanding more about the various pieces in there. Please let me know where I've missed things or got stuff egregiously wrong. Random comments: I would like to chop up the "lib" box into smaller pieces - perhaps sub-boxes for Jeri, Security, Activation, ServiceUI and General? "Utils" could probably also use more chopping open. In both cases I just haven't delved deep enough yet (and might never, depending where my wanderings take me.) I'm not sure that lumping Phoenix and Start in with the reference services was a great idea; I just didn't want to multiply entities needlessly. I'd suggest that something along these lines serves as a basis for modularising the codebase into smaller mind-sized sub-projects. How much interest is there in doing such a thing? Anyway,... hope it may be of some use to someone. PS/FWIW: I note that the ServiceUI APIDocs seem to have escaped the build/dist process somehow; at any rate they're not available via the online apidocs at https://river.apache.org/doc/api/
Chopping the codebase into bite-size pieces.
As part of shaking the rust from my aging memory, and with my minds-eye looking towards a more modular code experience for Jini/River, I drew up a small diagram of how things look to me/how I think the codebase could be chopped up into smaller sub-projects (with dependencies). https://drive.google.com/file/d/0B_JitrvGE8NMWnhRSWhFVW9MSWM/view?usp=sharing It might also be a little help to people confronting the rather daunting codebase for the first time, or even just for understanding more about the various pieces in there. Please let me know where I've missed things or got stuff egregiously wrong. Random comments: I would like to chop up the "lib" box into smaller pieces - perhaps sub-boxes for Jeri, Security, Activation, ServiceUI and General? (What else is big enough to warrant a box of its own?) "Utils" could probably also use more chopping open. In both cases I just haven't delved deep enough yet (and might never, depending where my wanderings take me.) I'm not sure that lumping Phoenix and Start in with the reference services was a great idea; I just didn't want to multiply entities needlessly. I'd suggest that something along these lines serves as a basis for modularising the codebase into smaller mind-sized sub-projects. How much interest is there in doing such a thing? Anyway,... hope it may be of some use to someone. PS/FWIW: I note that the ServiceUI APIDocs seem to have escaped the build/dist process somehow; at any rate they're not available via the online apidocs at https://river.apache.org/doc/api/ -- Mike Morris http://mikro2nd.net/ EarthStuff: http://blog.mikro2nd.net/ TechStuff: http://onemikro2nd.blogspot.com/
Chopping the codebase into bite-size pieces.
As part of shaking the rust from my aging memory, and with my minds-eye looking towards a more modular code experience for Jini/River, I drew up a small diagram of how things look to me/how I think the codebase could be chopped up into smaller sub-projects (with dependencies). https://drive.google.com/file/d/0B_JitrvGE8NMWnhRSWhFVW9MSWM/view?usp=sharing It might also be a little help to people confronting the rather daunting codebase for the first time, or even just for understanding more about the various pieces in there. Please let me know where I've missed things or got stuff egregiously wrong. Random comments: I would like to chop up the "lib" box into smaller pieces - perhaps sub-boxes for Jeri, Security, Activation, ServiceUI and General? "Utils" could probably also use more chopping open. In both cases I just haven't delved deep enough yet (and might never, depending where my wanderings take me.) I'm not sure that lumping Phoenix and Start in with the reference services was a great idea; I just didn't want to multiply entities needlessly. I'd suggest that something along these lines serves as a basis for modularising the codebase into smaller mind-sized sub-projects. How much interest is there in doing such a thing? Anyway,... hope it may be of some use to someone. PS/FWIW: I note that the ServiceUI APIDocs seem to have escaped the build/dist process somehow; at any rate they're not available via the online apidocs at https://river.apache.org/doc/api/ -- Mike Morris http://mikro2nd.net/ EarthStuff: http://blog.mikro2nd.net/ TechStuff: http://onemikro2nd.blogspot.com/
