Thanks William, Hopefully at some point I'll be afforded the time to add this in.
Thanks Jeffrey On Thursday, February 5, 2015 at 5:44:24 PM UTC-8, William Ferguson wrote: > > 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 <[email protected] > <javascript:>> 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 <[email protected]> >>> 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 >> [email protected] <javascript:>. >> 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
