- repose
- documentation
- repose-aggregator
- commons
- classloader
- configuration
- jetty
- utilities
- components
- cli-utils
- datastores
- api
- distributed
- ehcache
- filters
- all the filters
- filter-bundle of all the filters
- core
- core-lib
- valve
- web-application
- experimental
- exception-filter
- experimental-filter-bundle
- servlet-contract-filter
- tightly-coupled-filter
- extensions
- api-validator
- extensions-filter-bundle
- external
- jee6-schemas
- os-auth-schemas
- pjl-compressingFilter
- service-clients
- auth
- functional-tests
- container-support
- glassfish-support
- mocks-servlet
- mocks-util
- spock-functional-test
- test-support
- tomcat-support
- installation
- some random non-project folders :(
- deb
- repose-extension-filters
- repose-filter-bundle
- repose-valve
- repose-war
- rpm
- repose-extension-filters
- repose-filters
- repose-valve
- repose-war
- services
- datastore
- api
- impl
- health-check
- api
- impl
- httpclient
- api
- impl
- rate-limiting-service
- service-client
- api
- impl
- datastore
- commons
- repose
- documentation
- artifact-aggregator
- common
- classloader (NOTE: I think this is only used in core)
- configuration (NOTE: this should go into a configuration service API/IMPL package)
- jetty
- utilities
- jee6-schemas (NOTE: could be pulled out of repose entirely)
- os-auth-schemas (NOTE: could be pulled out of repose entirely)
- pjl-compressingFilter (NOTE: if we supported a filter contract, we could just use this filter properly)
- auth-classes (a collapse of external/service-clients/auth) (This is shared with two filters...)
- core
- api (new, part of the spring stuff, all the stuff the filters depend on, not implementations)
- impl (new,implementations of that core stuff)
- web-application (the war file)
- services (Eventually services can be external, but they're very much not right now)
- datastore-api
- datastore-impl
- health-check-api
- health-check-impl
- httpclient-api
- httpclient-impl
- rate-limiting-service (TODO: this is odd to sit here, it should probably be broken up into api/impl)
- service-client-api
- service-client-impl
- NOTE: can probably pull some of the stuff in "common" into here, like classloader, and jetty perhaps
- filter-bundles (TODO: i'm not sure this is the best way to do it, but it feels okay)
- standard-filter-bundle (currently named filter-bundle)
- extensions-filter-bundle
- experimental-filter-bundle
- filters
- all the filters, including ones from experimental, and external
- valve-launcher (SERVO)
- common
- functional-tests (TODO: these need to be examined heavily and see if we can't reorganize them, I didn't do anything here)
- container-support
- glassfish-support
- mocks-servlet
- mocks-util
- spock-functional-test (NOTE: this is the only one that actually has tests, that I'm aware)
- test-support
- tomcat-support
- installation (NOTE: these guys would each produce a deb and an rpm, instead of having separate projects)
- repose-extension-filters
- repose-standard-filters (replaces repose-filter-bundle)
- repose-valve
- repose-war
The existing project structure is very difficult to understand well. I'm hoping that as part of this reorganization, we can keep most of the artifactIDs the same, just move the directory tree and build order around a bit. Eventually I would like to see some of the artifacts go away, or become part of something else. Eventually the services should not be part of core, but as it stands right now, they are, so I'm not going to pretend any differently. Most of the stuff in common is also part of core, but some of them are used by some of the repose standard filters.
I pulled the filters all into the same location, as that just gives us a list of all the filters. The filter bundles are pulled out of that long folder list, so they can be easily found. They will depend on the projects they need to depend on and that should ensure the reactor build order is proper. I also want to rename the filter-bundle to standard-filter-bundle to more closely match the naming convention of the others.
I pulled the installation artifacts out of the repose-aggregator (called artifact-aggregator) because it uses the items the artifact aggregator will aggregate. I did the same with the functional tests, as they use the built items, and aren't part of the building of those items. I'm hopeful this will make it clearer to understand, and should help us treat the functional tests as a separate project.
I want the artifact-aggregator project to create an assembly of the artifacts it depeneds on, so that it's easy for the functional tests
to reference the output of that resultant build. Right now in jenkins it requires 4 or 5 regexps to grab all the artifacts. I want
this to be documented in the pom, so more logic is stored in the pom, rather in the jenkins jobs. Easy to add one artifact grabbing line:
target/artifacts and use all the jars/wars/ears put in there. It's also easier to reference from the functional tests, if we still do
it that way.
The functional tests still need some analysis, the code is largely undocumented, and I don't know how it works :(. Some work needs to be done to figure out how best to structure that, so it's quick to run the valve integration tests without building the container support logic. Specifically the glassfish-support project takes a LONG time to construct it's artifact. With the introduction of SERVO, and running everything as a war file, there's possibly some logic that can be duplicated to run across all the containers, thus substantially improving our testing, but we need to be able to do this in parallel, so we do not triple our test execution time (which is already absurdly long :()
The installation poms should combine the deb and the rpm, so each one provides a DEB and an RPM. The projects need to have tests to verify the output of the RPM and the DEB, and that they behave the same. There might be a bit of differences here, possibly some reusable test libraries that could be another project within this structure.
The functional-tests project should depend properly on the repose-aggregator project. The goal is to have maven automatically rebuild the snapshots, if told to do so within the functional-tests maven project. The installation projects should also depend on the repose-aggregator project so that they can build the RPM and DEB artifacts from the same files, without having to rebuild them. It should probably run before the functional-tests because I think some of the functional tests might use those packages (they probably should somewhere in there.)
The final artifacts should not be shipped unless all the other projects pass. It's possible we will need to, at the repose level, aggregate the RPMs, and all the java artifacts and only deploy them if the functional tests pass.
Ideally, at one point in the future, we should be able to ship each filter independently of core. In theory, we could add some basic logic to the filters pom, so that we can, in each filter, build a shippable artifact from there. We can't quite do this with the installation RPM/DEBs. It's possible that we can pull some of those resultants up into the projects they're tied to, but not trivially. It's probably best to keep those separate, but we'll have to figure out how to make sure they don't deploy unless the functional tests build.
Things in common should probably be pulled into core, or perhaps into a libraries directory, or perhaps a separate project, versioned independently of repose. Currently we bump the versions of all of this regardless of if anything changes, because they're all part of the same project. If we're going to independently version things, we need to figure out how we're going to independently release things. This maybe gets us a step in that direction, but doesn't solve it completely.