Thanks Dennis, The test harness presently includes a number of classes from the the main build, so it'll depend on them, but not include them.
Jsk-policy also needs investigating. Cheers, Peter. ----- Original message ----- > You can certainly use the approach in qa_refactor. I did make 2 changes > to the code to make the approach work: > > 1. Moved com.sun.jini.landlord.LeasedResource into jsk-dl.jar. This was > done to accomodate outrigger-dl.jar's > reliance on com.sun.jini.landlord.LeasedResource from > com.sun.jini.outrigger.StorableResource. > In the ant based build, LeasedResource was included using classdepandjar. > Using a Maven build, > outrigger-dl depends on river-dl (new name for jsk-dl). Adding > LeasedResource to river-dl > made sense. The approach taken to populate the source tree in the > maven-zed structure is to > load exiting jars, and for each entry in the loaded jar, copy the source > files into each respective > module's src directory, taking care not to duplicate any classes between > modules. Making he > change to jsk-dl.jar's build allows the river-dl module to be created > correctly. > > 2. Removed import of net.jini.discovery.LookupLocatorDiscoveryfrom > net.jini.core.discovery.LookupLocator. The > net.jini.discovery.LookupLocatorDiscovery class is not in the > jsk-platform module, and causes a compile error when included as an > import. > > The import is only required since it is used in the @see javadoc > directive. Including the > fully qualified net.jini.discovery.LookupLocatorDiscovery class in the > @see directive resolves > the issue. > > If those get done, then you should be able to run the script and create > the mavenized project that should build and assemble. > > HTH > > Dennis > > > On Wed, Apr 30, 2014 at 2:57 PM, Simon IJskes - QCG <si...@qcg.nl> wrote: > > > On 30-04-14 02:02, Dennis Reedy wrote: > > > > A this point I'm soliciting opinions and thoughts. Note that using > > Gradle > > > is certainly an option here, the breakout into multi-modules is not > > > tied to > > > Maven, it's based on accepted conventions. I chose Maven because it > > > was the > > > quickest (for me) to get going. > > > > > > > Good thing! Just to show support! I applaud a separation into multiple > > source trees, as a starting point for modularization. > > > > Any change we can re-apply your effort on trunk while maintaining > > subversion history? i.e. 'svn mv' commands? > > > > Gr. Simon > > > > > >
