Group items tagged

migrate4j is a database migration tool. Suppose you determine that you need a new database table for your project. If you develop alone, you could write an SQL script that adds a table and manually apply this to your development system. But if you work with other developers, or need to keep a test system in synch with your development system, this become tedious and error prone. Migration tools make it possible to add your new table (or make any other schema changes) in an automated fashion, ensuring all your systems are always in synch. Migration tools also make it possible to quickly and easily roll back previous changes. Unlike typing commands into an interactive SQL window or storing SQL scripts, migration tools keep a detailed history of how your database schema evolved (just in case you need to go back to a previous version). Finally, migration tools minimize or eliminate the problem of having to use vendor specific syntax - you may never switch database products, but if you do, using a migration tool will make your life much easier. The initial intent of migrate4j was to make a Java version of Ruby's db:migrate. If you've used db:migrate, you probably fell in love with it's simple syntax, easy configuration and ability to roll changes up and back effortlessly. The intent (and the challenge) of migrate4j is to bring the power and simplicity of db:migrate to Java programmers, using familiar type safety and syntax. Along the way, we're adding additional functionality that makes migrate4j more than just another Ruby tool rewritten for Java - it is a Java project intended to make other Java projects even better.

The Simple Logging Facade for Java or (SLF4J) serves as a simple facade or abstraction for various logging frameworks, e.g. java.util.logging, log4j and logback, allowing the end user to plug in the desired logging framework at deployment time. Before you start using SLF4J, we highly recommend that you read the two-page SLF4J user manual. In case you wish to migrate your Java source files to SLF4J, consider our migrator tool which can migrate your project into SLF4J in minutes. In case an externally-maintained component you depend on uses a logging API other than SLF4J, such as commons logging, log4j or j.u.l, have a look at SLF4J's binary-support for legacy APIs.

Does it all make sense now? Do you know how to solve every problem? Probably not, but when it comes right down to it, using Java EE can be even simpler than using Spring, and take much less time. You just have to find the right guides and the right documentation (which is admittedly a severe sore-spot of Java EE; the documentation is still a work in progress, but is getting much better, save blogs like this one.) You have to turn to a vendor like JBoss, or IBM in order to get the use-case driven documentation you need, and they do have documentation, it's just a matter of finding it. Seam 3 in particular strives to give extensive user-documentation, hopefully making things much simpler to adopt, and easier to extend. The main purpose of this article was not to bash Spring, although I may have taken that tone on occasion just for contrast and a little bit of fun. Both Spring and Java EE are strongly engineered and have strong foundations in practical use, but if you want a clean programming experience right out of the box - use Java EE 6 on JBoss Application Server 6 - JBoss Tools - and Eclipse. I will say, though, that the feeling I've gotten from the Spring forums vs the Java EE forums, is that there are far many more people willing to help you work through Java EE issues, and more available developers of the frameworks themselves to actually help you than there are on the Spring side. The community for Java EE is much larger, and much more supportive (from my personal experience.) In the end, I did get my application migrated successfully, and despite these issues (from which I learned a great deal,) I am still happy with Java EE, and would not go back to Spring! But I do look forward to further enhancements from the JBoss Seam project, which continue to make developing for Java EE simpler and more fun. Don't believe me? Try it out. Find something wrong? Tell me. Want more? Let me know what you want to hear.

"This page contains a catalog of migration notes and recommendations when moving from Seam 2 to Seam 3. "

With AutoPatch, an agile development process that requires a database change looks like this: Developer alters the model, which requires a change to the database Developer possibly consults a DBA, and develops a SQL patch against their personal database that implements the alteration Developer commits the patch to source control at the same time as they commit their dependent code Other developers' and environments' databases are automatically updated by AutoPatch the next time the new source is run This represents streamlined environment maintenance, allowing developers to cheaply have their own databases and all databases to stay in synch with massively lower costs and no environment skew. That's what AutoPatch does. Clusters with one database? Multiple schemas? Logical migrations, instead of just DDL changes? Need to do something special/custom? Need to distribute your changes commercially? All without paying anything? No problem.

2007 entscheidet sich Oracle, die Quellcodes seines erfolgreichen Persistenz-Projektes TopLink an die Eclipse Foundation zu übergeben. Seither wird das Projekt unter dem Namen EclipseLink weiterentwickelt und wurde jüngst als Referenzimplementierung für die Java Persistence API 2.0 ausgewählt. EclipseLink-Lead Doug Clarke spricht im Interview mit dem Eclipse Magazin über die Hintergründe der Migration zur Eclipse Foundation und über die Vorzüge von EclipseLink gegenüber anderen Persistenz-Frameworks wie Hibernate.