brooklyn-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John McCabe <j...@johnmccabe.net>
Subject Re: Repository splitting script
Date Mon, 14 Dec 2015 12:40:22 GMT
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 <
alex.heneveld@cloudsoftcorp.com> 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 <john@johnmccabe.net> wrote:
>
> > Does locations/winrm sound reasonable? (rather than reverting back to
> > /core)
> >
> > On Wed, Dec 9, 2015 at 5:19 PM, Aled Sage <aled.sage@gmail.com> 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
> > >>>
> > >>>
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message