OK, I under your scenario. The way that is typically handled would be to create a artifact repo visible to your partner containing both artifacts. The same repo could also be used by internal builds.
The alternative (what you are after): if your artifact (let's call it B) that consumes internal artifact A is the artifact that needs to be shared, then package up A inside B's build, is not supported by Gradle nor the Android-Maven-Plugin at this point. But if you submit a PR to AMP then I'll review. ᐧ On Fri, Feb 6, 2015 at 11:12 AM, Jeffrey Decker <deckerjeffr...@gmail.com> wrote: > Hi William, > > I appreciate the input and understand the problems that can arise here, > those concerns vanish though if no 3rd party library is being included that > the consumer of our library could include in their project. The main thing > I'm trying to do is include a separate internal library in the library I > want to distribute to a partner. > > Example: > > Lets say I have a library that I use strictly for handling api calls. I > also have another library that will consume the original one and add an > implementation layer to access the apis plus some code that conforms to a > specific protocol for communication with the partners application. Our > partners application will ultimately consume the full library containing > the code from both the api library and implementation of non generic code. > The api library is internal and used across many applications so it needs > to be shared and not specific to this one implementation and including the > source code in every consumer of this library isn't scalable. > > Because there is 0 risk involved in a scenario like this, it seems a > little strange that it isn't something that's easily doable. This is a > pretty standard use case in my opinion and a pretty major miss from a user > perspective. > > Anyways, Pavel's solution of including the resulting jar from the other > library build works as long as I do some more work to make sure it all gets > packaged nicely. I understand that we could distribute both libraries > separately but we originally used ant for our build and even minor changes > for or partner like asking them to include 2 libraries instead of 1 is > often a pain point. > > As an engineer I'd prefer to have all options available instead of being > pigeonholed into doing something a certain way because it's been decided by > someone else who Isn't in my shoes that it's the right way. People should > be able to make their own mistakes and learn from them. Training wheels are > only helpful for so long before they become a detrimentJust my two cents. I > appreciate the words of caution though because I've run into and understand > the issues that arise if someone isn't smart about what libraries they > include with their own. > > Thanks again, > Jeffrey > > On Thursday, February 5, 2015 at 4:22:44 PM UTC-8, William Ferguson wrote: >> >> ᐧ >> >> On Fri, Feb 6, 2015 at 10:03 AM, Jeffrey Decker <deckerj...@gmail.com> >> wrote: >> >>> Either way it seems to me that this is a pretty common requirement, it >>> seems a little silly how difficult it is to accomplish. >>> >>> >> Packaging up external dependencies into your own component that is >> designed for consumption within another component or application is >> generally a *really* bad idea as it leads to unresolvable conflicts between >> included libraries. >> >> Hence the rise of dependency management solutions such as that used by >> Maven over the last 15 years. >> >> By all means do it, just do it knowing full well the pain that you may be >> causing your clients. >> >> William >> >> > -- > You received this message because you are subscribed to a topic in the > Google Groups "adt-dev" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/adt-dev/Zh_2NOUQevo/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > adt-dev+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "adt-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to adt-dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
