Nice work. Answers in-line.
One general point however: I strongly suggest we do the restructuring
and maven tweaking in the incubator-brooklyn repo. This will mean the
cut-over to the new repos is only a matter of separating history for
subdirs. This allows us to have confidence that everything is working
-- esp maven -- when we cut across, it splits the problem up into two
simpler problems, and it makes the cut-over transparent -- e.g. even if
there is WIP in someone's incubator, when they rebase on latest
incubator they will have the right structure to apply a diff patch to
the new repo-set filesystem. (I've tested this and confirmed it works
for moved files; although it will leave out new files, so you'll have to
eyeball them if you apply this method.)
This means we can open a PR with the restructuring quite soon.
It would be great if we could do that this week, and then move to the
new brooklyn repos over the weekend. And then maybe even get a 090
non-incubating out before Christmas!
We've got some great new stuff to include, including the CLI and the
test framework, and hopefully Salt/Ansible support and OSGi and YAML
context highlighting.
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]
Agree. Wrote last Wed suggesting this should be in brooklyn-server/
software/base (as well as software/winrm ) .
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])
I think move QA to brooklyn-library.
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)
I think we should:
* copy these tests to the appropriate software-XXX bundle; I think it's
fine if they have test dependencies on the CAMP module
* (or move to the QA bundle)
* with answer to (1) above we can still use software-base
* for others I think comment out the offending tests in the camp module,
with a TODO saying that we'd like to create variants of those tests
which do not depend on specific software blueprints (or if easy, write
them now)
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)
should be fixed
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)
i think it's fine for ui to have a *test* dependency on server. ideally
the ui project have two different test modes, one of which uses JSON
files (selenium/jasmine style -- there is code in here for that), and
another which uses a real REST server.
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?
i think we move usage/cli ("brooklyn-cli") to be
brooklyn-server/server-cli-base/ "brooklyn-server-cli-base" and not run
a UI by default, but with the ability to be subclassed.
and we create brooklyn-dist/server-cli "brooklyn-server-cli" which
only specifies that it should use the brooklyn.war (for which it will
have visibility of course).
7. do we want to create equivalents to brooklyn-all/brooklyn-parent for
each repo (brooklyn-server-all, brooklyn-library-all etc)
i don't think there's a need for this
8. pulling it all together... any suggestions/ideas on the proposed
brooklyn repo?
as suggested above, let's do it in a PR on incubator-brooklyn
Best
Alex
On 14/12/2015 12:40, John McCabe 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
