omitted this reference from the end of the last message [2] - https://github.com/rdowner/brooklyn-repo-split
On Mon, Dec 14, 2015 at 12:40 PM, John McCabe <[email protected]> wrote: > 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 >> > >>> >> > >>> >> > > >> > >> > >
