Move extras package into its own project

[oxtoacart]

There's no need for this to be part of LittleProxy proper.

[jekh]

Would the extras be hosted in a separat repo, or submodules under littleproxy?

And besides dynamically-generated certs, are there existing features that you'd like to see moved into an extras package?

[oxtoacart]

I think extras should be distributed as a separate jar, so it's probably most straightforward to make it a totally separate repo. Other than maybe some unit tests, I don't think anything in LittleProxy depends on what's in the extras package. If it does, maybe it shouldn't :)

Off the top of my head, I think everything else is tightly enough integrated into the core of LittleProxy that moving it out into extras wouldn't be worth it.

[ganskef]

I've moved the mitm implementation from PR #174 into a separate module. Please consider to integrate the little modifications in #174 now.

I would like to see a release of LittleProxy with this.

[ganskef]

I've built an parent module to build LittleProxy and LittleProxy-mitm in Travis CI: https://github.com/ganskef/LittleProxy-parent. It contains Git submodules to include the unreleased versions. An additionaly update module performs an submodule update to avoid outdating. But, I've no idea how this works with releases.

Please give me a hint, what's about MITM with LittleProxy.

[ganskef]

What's the suggested module structure? The task needs to move directories which are loosing its history, but the single files seems to hold it.

LittleProxy/littleproxy => littleproxy (moved src and pom.xml)
LittleProxy/littleproxy-mitm => littleproxy-mitm
LittleProxy/littleproxy-android => littleproxy-android (for example)
...
LittleProxy => littleproxy-parent (will be built at last)

The dependency management should be moved then into the parent pom then.

It's not easy to move the files from extras, due to the tests inheritance structure.

[jekh]

We did a similar refactoring for browsermob-proxy when we added littleproxy support a few months back. The basic structure we went with was:

• core module
• optional module
• distributable module (creates the distributable jar file with scripts for multiple platforms)

The structure worked pretty well for us. It did mangle the git history a bit, but most tools can track the renames and display the proper history.

I'm not sure we need an android module specifically, unless there is something special about the android build that requires different dependencies or special treatment. We can always add a github wiki page with Android instructions for folks running on that platform.

[ganskef]

Hi Jason,

I've got a similar structure in my application, and I've started a
branch with LittleProxy always, and I've built it successfully. Will
push it, to have a base. You are write enabled in my repositories on GitHub.

An Android module would be nice as an example, and it would create the
opportunity for automated tests with this platforms runtime, I think.
But this isn't the first step, of course.

Regards Frank

Am 17.07.2015 um 04:07 schrieb Jason Hoetger:

We did a similar refactoring for browsermob-proxy when we added
littleproxy support a few months back. The basic structure we went with was:

• core module
• optional module
• distributable module (creates the distributable jar file with
  scripts for multiple platforms)

The structure worked pretty well for us. It did mangle the git history a
bit, but most tools can track the renames and display the proper history.

I'm not sure we need an android module specifically, unless there is
something special about the android build that requires different
dependencies or special treatment. We can always add a github wiki page
with Android instructions for folks running on that platform.

—
Reply to this email directly or view it on GitHub
#173 (comment).

[ganskef]

@jekh I ran into trouble applying your upstream changes to the modularized branch. Such a refactoring has to be planned, I think. How has you done this in BMP?