I've got server/library/ui/dist building but with quite a few caveats/problems.
1. multiple dependencies on brooklyn-software-base (CAMP/REST Server/Launcher etc) - I suspect this belongs in the brooklyn-server repo rather than brooklyn-libraries (I'd added it back into my test repo [1] 2. qa module heavily dependant on brooklyn-software-* from the brooklyn-library repo - move to the brooklyn-library repo or introduce a new repo? (I'd disabled it in [1]) 3. tests in brooklyn-camp module depending on brooklyn-software-* from brooklyn-libraries repos (EnrichersSlightlySimplerYamlTest, EntitiesYamlIntegrationTest, JavaWebAppsIntegrationTest, MapReferenceYamlTest, ObjectsYamlTest) - refactor (?) or move (I just commented these out for the moment) 4. unable to build brooklyn-server with -Dmaven.test.skip=true as there were dependencies on generated test jars (didn't dig into this, commented out problem tests - see #3) 5. tests in brooklyn-ui depend on brooklyn-rest-server, brooklyn-test-support, brooklyn-api, brooklyn-core etc (built with -Dmaven.test.skip=true for the moment) 6. both brooklyn-launcher and karaf apache-brooklyn (Distro) currently depends on brooklyn-jsgui war from brooklyn-ui repo for build, both will build without it present but launching brooklyn throws 'java.io.IOException: brooklyn.war not found on classpath', supplying '--startupContinueOnWebErrors' allows start to proceed but the REST API isn't accessible. What is the desire here, to start without a UI by default - ie just the REST API? Start the UI automatically if detected on the classpath or require the user to explicitly request a UI be started? 7. do we want to create equivalents to brooklyn-all/brooklyn-parent for each repo (brooklyn-server-all, brooklyn-library-all etc) 8. pulling it all together... any suggestions/ideas on the proposed brooklyn repo? I've used the build_wip branch on the following repos (generated using [2]) to investigate (I set the version to 0.9.1-SNAPSHOT to avoid clashing with the current 0.9.0-SNAPSHOT artifacts): - https://github.com/johnmccabe/TEMP-brooklyn-server/commits/build_wip - https://github.com/johnmccabe/TEMP-brooklyn-library/commits/build_wip - https://github.com/johnmccabe/TEMP-brooklyn-ui/commits/build_wip - https://github.com/johnmccabe/TEMP-brooklyn-dist/commits/build_wip You can currently build a dist in the following order (TODO the poms need some serious tidying): *TEMP-brooklyn-ui* mvn clean install -Dmaven.test.skip=true *TEMP-brooklyn-server* mvn clean install *TEMP-brooklyn-library* mvn clean install *TEMP-brooklyn-dist* cd usage/all mvn clean install cd ../../usage/dist mvn clean install [1] https://github.com/johnmccabe/TEMP-brooklyn-server/commits/build_wip [2] On Wed, Dec 9, 2015 at 10:48 PM, Alex Heneveld < [email protected]> wrote: > i think leave it `brooklyn/software/winrm` in the old hierarchy, and in the > new hierarchy `brooklyn-server/software/winrm` alongside > `brooklyn/software/base` > > `locations/*` is intended for implementations of `Location` > > --a > > > On 9 December 2015 at 22:36, John McCabe <[email protected]> wrote: > > > Does locations/winrm sound reasonable? (rather than reverting back to > > /core) > > > > On Wed, Dec 9, 2015 at 5:19 PM, Aled Sage <[email protected]> wrote: > > > > > +1 > > > > > > Let's move winrm to brooklyn-server. > > > > > > > > > > > > On 09/12/2015 16:56, Hadrian Zbarcea wrote: > > > > > >> That should be (or at least become) a soft dependency, not a hard one. > > >> That aside, the winrm piece probably belongs in server. > > >> > > >> Hadrian > > >> > > >> On 12/09/2015 11:27 AM, John McCabe wrote: > > >> > > >>> Alex, all, (fyi Hadrian/Ciprian), > > >>> > > >>> > > >>> * fix pom files on result of `rearrange-incubator.sh` script so it > > builds > > >>>> > > >>>>> (make this a diff / git cherry-pick we can just apply once all PRs > > are > > >>>>>> merged?) > > >>>>>> > > >>>>>> John also said to me that he would take a look at this problem. He > > was > > >>>>> temporarily prevented from doing so by a bug in the split script > > which > > >>>>> broke TEMP-brooklyn-server, but that dodgy repo should now be > fixed. > > >>>>> > > >>>>> John - any update? > > >>>> > > >>>> > > >>>>> > > >>>>>> Just after having a chat with Richard about this, and am in the > > >>> process of > > >>> working through it. > > >>> > > >>> Have hit one problem so far, a circular dependency between > > >>> brooklyn-server > > >>> and brooklyn-library from some of the OSGI-ification changes. > > >>> > > >>> The 'Brooklyn Jclouds Location Targets' module in brooklyn-server > has a > > >>> dependency on the 'brooklyn-software-winrm' artifact from > > >>> brooklyn-library, > > >>> but brooklyn-library itself depends on brooklyn-server. > > >>> > > >>> Any suggestions on what we should do with it? There's mention of > > >>> additional > > >>> cleanup required later in the commit (see pull#957 [1] (JIRA > > BROOKLYN-182 > > >>> [2])) > > >>> > > >>> /John > > >>> > > >>> [1] https://github.com/apache/incubator-brooklyn/pull/957 > > >>> [2] https://issues.apache.org/jira/browse/BROOKLYN-182 > > >>> > > >>> > > > > > >
