Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Decide same repo/separate repo for Android Tracker #17

Closed
alexanderdean opened this issue Jun 19, 2014 · 6 comments
Closed

Decide same repo/separate repo for Android Tracker #17

alexanderdean opened this issue Jun 19, 2014 · 6 comments
Assignees
Labels
Milestone

Comments

@alexanderdean
Copy link
Member

@alexanderdean alexanderdean commented Jun 19, 2014

By end of 0.3.0, we need a decision on whether to build Android support into this tracker, or create a separate repo and share logic between both repos, maybe with a java-tracker-core lib or similar.

@alexanderdean
Copy link
Member Author

@alexanderdean alexanderdean commented Jun 19, 2014

The more I think about it, the more I think we are going to end up with a core-lib and separate projects.

For example: the Kinesis support (#8) doesn't make sense on Android.

@jonalmeida
Copy link
Contributor

@jonalmeida jonalmeida commented Jul 8, 2014

So after this sprint, it seems almost entirely clear that we should keep the java tracker as simple as possible, have that put up on maven and then have the Android tracker add it as a dependency in the Android gradle project, then override whatever needs to be Android specific.

What say you?

EDIT: Close if all seems okay

@alexanderdean
Copy link
Member Author

@alexanderdean alexanderdean commented Jul 8, 2014

I think that's fine. This statement won't be long-sustainable: "keep the java tracker as simple as possible" - but that's okay, at that point, we can break this project into two sub-projects (still one repo), where we have java-tracker-core and java-tracker, where java-tracker-core is the lib that both java-tracker and android-tracker then import.

Makes sense? Close if okay

@jonalmeida
Copy link
Contributor

@jonalmeida jonalmeida commented Jul 8, 2014

So I guess the question is, do we want to do the split now and deal with it in it's adolescence instead of later? Doing this now makes sense to me, but I'm worried about wasting time that I can't afford to spare.

@jonalmeida
Copy link
Contributor

@jonalmeida jonalmeida commented Jul 8, 2014

Okay scratch that - we'll leave it the way it is for now. java-tracker-core can be mainly a payload class, and some interfaces to implement for android and java. This should be simple enough to do later on as well without much time wasting.

@alexanderdean
Copy link
Member Author

@alexanderdean alexanderdean commented Jul 8, 2014

Sounds good to me - I will create a ticket for this - #47

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.