Comments (11)
IMHO, ReadSideTestDriver
should be in tools
. We know it'll eventually jump into core
.
But I agree with you that scoping had not been necessary in the past and it is now. So we could put ReadSideTestDriver
in tools/src/main/test
and have other projects depend on tools % "test-> test"
(not sure that's the correct syntax).
Actually, I think TopicStub
was in tools
before making it's way into core
and it was in tools/Src/main
. What I'm trying to say is that in the past we already had testkit
code visible from compile scope for few days/weeks. Hmmm, maybe we should get this scoping thing addressed already, it's becoming a habit to ignore this scoping issue.
Long-story short: I would move ReadSideTestDriver
into tools/src/test
, fix the dependencies and prioritize it's promotion into core so that ReadSideTestDriver
stays in tools
the shortest period we can.
from online-auction-java.
@yg-apaza Are you working on it?
from online-auction-java.
@lakhina No, you can work on this :-)
from online-auction-java.
@ignasi35 can correct me if I'm wrong, but I think the "move to core" comments were about moving them into the core Lagom framework to be used by all projects, not just about moving them to the com.example.core
package in this project. That's why the comment also appears in CompletionStageUtils
.
I think there is a discussion we still need to have amongst the Lagom development team about how we should move useful utilities into the framework.
from online-auction-java.
At @TimMoore pointed out, moving features from online-auction
(or other sample apps) into lagom core
is not a very clear process and we don't have a clear decision process to determine what's a good addition and what isn't.
In the past we've only moved one feature and the steps were:
- extract code from all the location in
online-auction
where it's applied/copy-pasted and move it totools/
. This step may require some API tuning and discussing.tools/
is a launch platform into Lagom. Preferably, this step includes adding tests to the extracted feature. - in Lagom, copy/paste code from
online-auction/tools
. If applicable, include integration-tests, scripted tests, other... . Include Javadocs and user documentation.
This process doesn't cover when/how to implement the feature in the other languages. That is, if refactoring code online-auction-java
, it could be necessary that we do the same in online-auction-scala
because when moving the code into Lagom we'll have to keep feature parity.
Sometimes a feature only applies to java (or scala) dues to language-specifics features/limitations and sometimes the online-auction
applications are not up to date with each other in terms of development and providing a feature parity requires updating other areas first (Yak-Shave All TheThings!).
from online-auction-java.
Also:
./item-impl/src/main/java/com/example/auction/item/impl/CassandraReadSideUtils.java:11:
./tools/src/main/java/com/example/core/CompletionStageUtils.java:14:
these two files were originally one file used by several classes. One such class was promoted into Lagom via tools/
and that forced me to move CompletionStageUtils
from its original location into tools/
. Then I realised a method required a dependency to Cassandra and I extracted that out and put it back into a new file CassandraReadSideUtils
.
The process of launching code via tools/
helped me detected there were two different things into a single file and also surfaced the dependencies I would need when moving that bit into Lagom.
from online-auction-java.
See also lagom/lagom#732
from online-auction-java.
Can we start by moving CassandraReadSideUtils
and also com.example.auction.item.impl.testkit.*
to com.example.core
? Then, we can just wait until a decision is made in Lagom.
I think we can use tools
for both reasons: as a common project and as a launch platform to core.
There have been some times when I was in the need of using these utilities in Transaction service (This integration test is repeating Await.result
)
from online-auction-java.
@yg-apaza makes sense to me
Maybe we should keep the testkit
subpackage for the classes there. (So, com.example.core.testkit
.
Also, would it be better to call it com.example.tools
since it's in a project called tools
? @ignasi35 any opinion on this?
from online-auction-java.
Even if the project is named tools
I think packages should be as specific as possible (and preferably avoid the tools
naming altogether). I think an option is to use a packagename as close as possible to what we're aiming when we move the code to core
.
I think we can use tools for both reasons: as a common project and as a launch platform to core.
I chose the name of the project very poorly and now we're getting these confusions. I think there's room in online-auction
for a project with common code, but when I created tools
I only meant it as a launch platform into core
. For example, security
is also a project for common code but it's purpose is very specific. That is a good name.
Final note: this issue originally mentioned ReadSideTestDriver
and CompletionStageUtils
. Both have their own issues in lagom/lagom
already: lagom/lagom#421 for ReadSideTestDriver
and lagom/lagom#732 for CompletionStageUtils
.
from online-auction-java.
@ignasi35 what would you suggest as an immediate solution to the problem of sharing code between multiple Online Auction services?
Maybe it makes sense to introduce a new testkit
subproject... after al, we probably don't want to mix that code into the runtime classpath of the services.
from online-auction-java.
Related Issues (20)
- Logout causes (UI and logs) exception HOT 1
- event store uniqueness , saga ,optimistic ui updates HOT 1
- TransportException on home page HOT 2
- Nav controller initialization failure in Japan locale HOT 1
- InvalidQueryException: Cannot execute this query as it might involve data filtering and thus may have unpredictable performance. HOT 1
- sbt runAll raise errro Unknown CF HOT 1
- logback stacktrace (NPE) when running in devmode HOT 3
- Disable java serialization completely HOT 1
- Add integration tests on Bidding Service
- Add LO4K8s instructions (remove ConductR) HOT 1
- Upgrade Elasticsearch to 6.x
- Replace the deprecated JavaTestKit with current equivalent
- Search service api expects a request body for GET request
- Replace ReadSideTestDriver with testkit-provided
- Cleanup Service descriptor for SearchService
- Upgrade to Lagom 1.5 HOT 1
- Upgrade to JUnit 5
- Fine tune Kafka logger levels
- Setup mergify
- Setup probot-settings
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from online-auction-java.