Decide same repo/separate repo for Android Tracker #17

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

Comments

Projects
None yet
2 participants
@alexanderdean
Member

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

This comment has been minimized.

Show comment
Hide comment
@alexanderdean

alexanderdean Jun 19, 2014

Member

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.

Member

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

This comment has been minimized.

Show comment
Hide comment
@jonalmeida

jonalmeida Jul 8, 2014

Contributor

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

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@alexanderdean

alexanderdean Jul 8, 2014

Member

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

Member

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

This comment has been minimized.

Show comment
Hide comment
@jonalmeida

jonalmeida Jul 8, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@jonalmeida

jonalmeida Jul 8, 2014

Contributor

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.

Contributor

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

This comment has been minimized.

Show comment
Hide comment
@alexanderdean

alexanderdean Jul 8, 2014

Member

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

Member

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