= How to setup Dev Environment

:Notice: Licensed to the Apache Software Foundation (ASF) under one or more contributor license agreements. See the NOTICE file distributed with this work for additional information regarding copyright ownership. The ASF licenses this file to you under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at. http://www.apache.org/licenses/LICENSE-2.0 . Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR  CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

To speed up development it makes sense to only have the IDE build the stuff that's needed.
The approach I use is to have Maven perform a full build of everything, more or less (including the example/demo app), so that the local cache in `~/.m2/repository` is up-to-date.
Then, in the IDE, exclude the parts that won't change and include in the relevant parts of the example/demo app (which we can use to iterate on).

== Maven Build

Perform a full mvn build, but exclude all of the incubator modules (vaadin in particular has some prereqs that aren't important to us here), and explicitly bring in this module.
Also include the 'wicket' variant of the demo app, as this also includes the graphql viewer (as well as the RO viewer).

[source,bash]
----
mvn install \
  -D module-examples-demo-wicket \
  -D module-incubator-graphql \
  -D skipTests
----


== IntelliJ

In IntelliJ, ignore most of the projects except the ones to be changed or will want to read (eg core).
Also, explicit _include_ the relevant parts of the demo app (chances are that this will be excluded initially due to the default profiles.

Thus:

* exclude `api` (`applib` and `schema`)
+
I find that IntelliJ can mess up with compiling applib as it depends on DTO classes in schema generated by the mvn maven-jaxb2-plugin plugin; since they change very infrequently, easier to simply pick them up as prebuilt libraries from `~/.m2/repository`.

* include `causeway-parent`

* include `mavendeps/webapp`

* include `commons`

* include all of `core`
+
for the `metamodel`, `interaction` and `runtime`/`runtimeservices`.
Since that is the bulk of core, it's easiest to include everything.

* include `viewers/common`
+
as it makes sense for this to be a dependency

* include `incubator/viewers/graphql` (of course!)
+
image::devnotes/graphql-included-modules.png[width=300px]

* optionally include `viewers/restfulobjects`
+
for a bit of "monkey see, monkey do"

* exclude everything else

Then, add in parts of the demo app:

image::devnotes/example-demo-app-included-modules.png[width=300px]

That is:

* include `examples/demo/domain`
* include `examples/demo/web`
* include `examples/demo/wicket/demo-wicket-common`
* include `examples/demo/wicket/demo-wicket-jpa`
+
this is where the SpringApplication -- `DemoAppWicketJpa` -- resides.
It's faster to use the jpa variant rather than the jdo variant; no need to wait for the DN enhancer.
+
[TIP]
====
you'll notice that examples/demo/domain has both Jdo and Jpa entities.
These are both compiled, however at runtime the Jdo variants are ignored because the `DemoAppWicketJpa` explicitly sets the "demo-jpa" Spring profile:

[source,java]
----
System.setProperty("spring.profiles.active", "demo-jpa");
----
====


TODO's

* use interfaces
** the beansort ABSTRACT could be implemented as gql interface
** for input types for interfaces (like PaperClip) we could create a mutator for each implementation (f.e. addClipA, addClipB,..)




