Split funcito into functional api specific jars

[GoogleCodeExporter]

Currently (version 1.0.0) funcito is packaged as 1 jar for all supported 
functional apis (guava, fj, jedi core). Because of this fact the jar has a 
runtime dependency on all supported apis. It don't want to bloat the projects 
where I'm using funcito with unused libraries. I think it would be better to 
split funcito into a core jar for common functionality and multiple functional 
api specific jars (funcito-guava, funcito-fj, ...).

Original issue reported on code.google.com by hammersc...@gmail.com on 21 Mar 2012 at 11:09

[GoogleCodeExporter]

Thanks for your input.  I understand your concern, but the multiple runtime 
dependency is only a problem if you reference more than one "sub-API" in your 
using code.  The company I currently work at is using Funcito 1.0.0 with only 
Guava and there is no runtime issue with that.  I invite you to try it for 
yourself.

Leaving them in the common jar ensures that if you *do* want to interoperate 
between multiple FP libraries you have them all in one place.  Otherwise there 
would need to be not only 3 packagings, but rather also a 4th that did exactly 
what this one does too.

But if there are further considerations I have not addressed, please let me 
know.  Otherwise I will close this issue in a few days.

Original comment by kandpwel...@gmail.com on 21 Mar 2012 at 2:22

• Changed title: Split funcito into functional api specific jars

[GoogleCodeExporter]

I should probably add some more explicit Wiki documentation that describes this 
more publicly.

Original comment by kandpwel...@gmail.com on 21 Mar 2012 at 2:27

[GoogleCodeExporter]

Well there is at least a runtime dependency on guava (see StubFactory) even if 
you are not using guava as your functional api. I think this should be 
mentioned somewhere. 

I think multiple jars would be better for dependency management. Consider the 
current funcito.jar and n projects where you are using guava + funcito. You 
have to declare 2 * n (2 jars for each project) dependencies. In the multiple 
jar scenario you would end up with n dependencies to a funcito-guava.jar (which 
itself depends on guava). Of course you could still have a fat jar which 
depends on all funcito-*.jars for the multiple FP library case.

Original comment by hammersc...@gmail.com on 21 Mar 2012 at 3:19

[GoogleCodeExporter]

Oops! Didn't notice the StubFactory use of Guava's Maps class.  Thanks for 
finding that.  That can easily be removed.  Can you please create a separate 
issue for that?  But that is an issue apart from your main point.

Your main point was weighed in the initial design of Funcito.  I understand, 
but still consider the dependency management trivial.  Funcito is really an 
add-on for those who are already using an FP-library, and hence already 
managing a dependency on the particular FP library.

So I will leave this issue open indefinitely, but lower the priority for now.  
Those who really want this can star this issue and I will reconsider if there 
is enough attention to it.

Original comment by kandpwel...@gmail.com on 21 Mar 2012 at 4:56

• Changed state: Deferred
• Added labels: Type-Enhancement, Priority-Low
• Removed labels: Type-Defect, Priority-Medium

[GoogleCodeExporter]

I was also just considering that in the upcoming release to Maven Central that 
I did not show any dependencies on the FP libs (because I considered each one 
of them to be optional).  What I wasn't aware of was the definition of Maven 
"optional dependencies" (see 
http://maven.apache.org/guides/introduction/introduction-to-optional-and-exclude
s-dependencies.html).  I should probably also include these in the POM as a 
matter of good form, and minimally to make sure the compile dependencies are 
properly reflected there.

Original comment by kandpwel...@gmail.com on 21 Mar 2012 at 5:47

[GoogleCodeExporter]

I like the first sentence in the explanation of optional dependencies: 
"Optional dependencies are used when it's not really possible (for whatever 
reason) to split a project up into sub-modules." ;-) But delivering functito as 
a single jar is not a showstopper for me.

Original comment by hammersc...@gmail.com on 22 Mar 2012 at 5:00

[GoogleCodeExporter]

That's good to know.  But I'll leave this open anyway for users to star.

As for the optional dependencies, the POM fix may not be immediate.  My build 
is actually not Maven but Gradle, and there is currently no *direct* way to get 
the optional flags in the generated POM, though the Gradle team is working on 
it.  There are some POM post-processing solutions I have seen that I don't know 
if I want to mess with.  I'll probably open another issue for that.

Original comment by kandpwel...@gmail.com on 22 Mar 2012 at 3:45

[GoogleCodeExporter]

I forgot to mention in this issue, that I got added the POM dependencies, 
marking them as optional.  I will close this issue now.

Original comment by kandpwel...@gmail.com on 19 Jul 2012 at 8:29

• Changed state: WontFix