Google Code skipped issue 59 about flyway HOT 7 CLOSED

From [email protected] on October 27, 2010 16:29:21
Hello Mathias,

Thanks for your suggestion. I certainly agree that the lower the number of dependencies a framework has, the easier it is to integrate in a existing project.

I will have a look this weekend at the impact it would cause, should be duplicate all the Spring classes we depend on in a package hierarchy below let's say com.googlecode.flyway.util.spring or something similar.

I'll keep you posted.

Axel

from flyway.

From [email protected] on October 30, 2010 12:57:30
Hello Mathias,

We basically use 3 spring features: classpath scanning, transaction management and the jdbc abstraction. This means (for Spring 2.5.6) that we are talking about 6 jar files that weigh about 1.73 MB. Is Spring itself as dependency a problem, or is it the size of the jar files?

Axel

from flyway.

From [email protected] on October 30, 2010 22:37:29
Well, I'm planning on using it for the Play! Framework (see http://groups.google.com/group/play-framework/browse_thread/thread/61f8448a58b02042/fc88cbb62ec711ad) and I'd rather stay away from pulling in Spring. Classpath scanning for property files is easy to implement yourself (e.g. take a look at Google Guava's Resources class (http://code.google.com/p/guava-libraries/source/browse/trunk/src/com/google/common/io/Resources.java). Transaction management should IMO be implemented by the container wherein Flyway runs. That leaves us JDBC abstraction. Not too hard to implement, and it could even be abstracted specifically for incremental schema updates. Just my thoughts, feel free to ignore ;-).

from flyway.

From [email protected] on November 02, 2010 19:22:29
Hello Mathias,

I just spoke to Christian about this again this evening. We understand your concerns, and as I already said, we definitely strive to minimize the amount of dependencies we depend on.

By looking at it more closely, we came to the conclusion that offering replacements (or embedding the relevant spring classes under a different package) for the functionality we require (classpath scanning for property files and classes, transaction management, the jdbc abstraction and the collection of small utility classes like StringUtils or ObjectUtils) would both increase the size and the scope of Flyway beyond the razor-sharp focus on DB Migration we strive to maintain.
Also, it would likely lead to lower quality, less well tested code than what spring provides. All this will also significantly increase the size of the Flyway distribution itself.

We therefore decided to keep the dependency on Spring.

Cheers,
Axel

from flyway.

From [email protected] on November 10, 2011 02:27:38
Decided to re-open. The more I think about it, the more I like the idea of Flyway having zero dependencies. Cost (in KB) of repackaging the relevant Spring code should be evaluated for a 2.0 release.

from flyway.

From [email protected] on June 06, 2012 17:12:22
This issue was closed by revision d12366379907.

from flyway.

From [email protected] on October 24, 2012 15:10:14
Great news! The comment nr 4 made me choose mybatis over flyway at that time. I'll consider again flyway for future projects.

from flyway.