I understand your concerns and it looks like the project gets not enough love today, lets hope that the projects will merge after a while.
I understand your concerns and it looks like the project gets not enough love today, lets hope that the projects will merge after a while.
Hi Nathan,
I am very glad for your reply and at the same time, super-excited 
As I wrote before, we share the same thought that having two separate projects is a waste of time and energy, so I would be very happy if we can merge the trees again.
Currently, my primary concern is that I have an urgent (or, more frankly, critical) need for a new, stable version of the 3.x.x tree that includes as many bug fixes and low-risk new features as possible (esp. in the Oracle department). I will take a look at LB4 when I get the time, but from my “gut feeling”, I do not think that the 3.x architecture is a dead end; the only thing that could get problematic is that Database and Connection classes are very closely coupled and that it might be difficult to get multi-connection support working with their current structure, but that really is the only architectural road blocker I have encountered so far. I really like the code base, you have done tremendous work!
So, this is what I will try to do:
If you agree, may I ask you to monitor my copy of the the schema and contact me ASAP if you see something that you cannot / don’t want to merge?
To keep everything as neutral as possible, I will make a constant somewhere so that as few “DB-Manul” strings as possible as present. That should make merging easier. The problem is that I already have put in a lot of hours, so it is next to impossible to extract everything I have done so far into “neat” PRs.
Due to the urgency of a new version in the commercial software project I am working in, I will need to keep my fork alive until we find a way to merge it. However, feel free to cherry-pick anything from my tree that you find interesting.
For your convenience, you will find three files in the root directory of my tree:
A few ideas:
Last thing, may I ask if you have an estimate on when you can spent time on Liquibase again? At the moment, I am sort of a “lonely warrior” and working together on something is just more fun
All the best from Germany,
Andreas
Hi Nathan,
With regards to Java 7, luckily, my Java 8-dependent changes are limited so far (LoadDataChange is the most prominent place IIRC, and I will rework them to be compatible with Java 7). I am more worried about the availability of bug-fixed JDBC drivers for Oracle DB in combination with Java 7: Oracle Corp. has the nasty habit of maintaining JDBC drivers for everything but the most recent release poorly. In most cases, upgrading to the newest version (12.2.0.1 currently) is the only solution for bug-plagued users. IIRC, the 12.2.0.1 JDBC driver is JDK8-only, but I will need to confirm that. I fear that this problem might apply to other DBMS as well.
(Edit: Confirmed: “JDK6 and JDK7 are no longer supported. You must use JDK8 in order to use the 12R2 JDBC Driver.” from the 12cR2 JDBC README.txt file)
Yes, Sonar is integrated in my CircleCI build. The circle.yml activates the “sonar” Maven profile. To get it working, you need to set up an access token (replacement for username and password) in your Sonar installation and store that as a private variable in CircleCI ($SONARQUBE_TOKEN). Due to the use of PowerMockito in some existing integration tests, I could not use the regular JaCoCo agent, but instead had to use the “instrument” Maven target, which modifies the class files on disk. As a consequence of this, binaries / artifacts built with the “sonar” Maven profile active are tainted with instrumenting bytecode and should never be used as release artifacts. However, this can easily be mitigated by building release artifacts without the “sonar” Maven profile, so it should not be a problem.
Is there anything else I can do to help to integrate my changes into the 3.x.x tree?
Cheers,
Andreas
Great I will need to depart for my day job now, but I will start on with Java 8 -> Java 7 changes tonight, from the first look I should not need more than a day or two.
Cheers,
Andreas
Hello Nathan and all,
First, let me say that I am incredibly grateful for the Liquibase software. It has helped me tremendously in my work as a developer-supporting DBA and enabled me to smoothen our software release process. However, I noticed that recently, development activity seems to have ceased; the last commit in https://github.com/liquibase/liquibase is now older than half a year. I tried to find out why that is so, but my forum post (http://forum.liquibase.org/#Topic/49382000001633001) and my mail to Nathan did not seem to have made it through.
As the software project I am working for depends on the continuous availability and development of open-source Liquibase, I feel the need to take the initiative. I set up a repository at https://github.com/dbmanul/dbmanul and started work on the following topics:
Please understand that the motivation for this is not to create rivalry to Liquibase, and the continued use of the Apache 2.0 license will ensure that everyone who wishes to merge parts of my tree into their software will always be able to do so. In fact, I would be glad if we could merge our trees again in the future. Naturally, Datical is invited to use the code if they see fit.
If you have any questions or comments, please feel free to drop me a line at andreas.buschka@dbmanul.org.
Again, thanks for Liquibase,
Andreas Buschka
Very sorry to hear you’re looking to start a separate project. I understand your frustration with the lack of movement in the project for the last couple months, but it’s certainly not from a lack of activity or future but just a temporary situation.
Managing the project is definitely time consuming, but I’d much rather find a way for us all to work together rather than duplicating effort and ending with competing and incompatible products that are not as good for anyone.
Part of what has made progress on Liquibase look so slow lately is because I have many different issues within Liquibase that interrelate to each other and it is difficult to make progress on them all and so they all suffer.
You mention improved I18N work, working integration tests, Java 8 support, and merging pull requests.
I have no excuse for the pull request backlog. They are great to get and I’m thankful for all that come, but they take time to look through and vet for unexpected side effects–especially when the integration test suite is lacking and so I can’t trust it. Then the backlog keeps growing and it becomes overwhelming. I’m sorry to all the people who have taken the time to contribute pull requests and I have not yet gotten to them.
Testing, modernizing the code, and I18N have ended up fitting into Liquibase 4 which started out as a fork but ended up being so different it is now a completely separate codebase https://github.com/liquibase/liquibase4. I’ve always been very careful about changelog and API compatibility and so there is a lot in the existing Liquibase codebase I can’t easily change without breaking that and so work is being done in a separate, clean implementation. Besides the use of Java 8, there is a lot of work done around testing to hopefully avoid a lot of the integration testing issues with have in Liquibase 3.
Unfortunately, with separation of Liquibase 4 and 3 it puts me in a cycle of trying to keep 3 moving along enough while knowing that the time I spend on 3 is just pushing 4 further out. The balance has not been great and 4 is also taking far longer than I’d like, but it’s another example of where I would much rather have someone to help with all the work than working as separate projects.
The other reason for a lack of visible progress the last few months is because I’m working on a lot of very exciting Liquibase-related work within Datical that is just yet ready for the public yet. It’s all great stuff for Liquibase, but has unfortunately been eating up all my time. Luckily, that should be leveling off soon so I can get back to more standard Liquibase.
If you are wanting to run DB Manul as a separate project I understand and respect that, but if we can find a way to not have a fork I think it will be best for everyone.
Nathan
Yes, it is definitively nicer to have others to work with–I’ve had a lot of lone wolf years on Liquibase, so all the more reason to work together.
LB4 has some significant changes and a much nicer codebase, but it is definitely still pre-alpha. Pieces are getting to be in place, but I’m stuck in the middle of the massive work of refactoring and testing all the Change (called Action) implementations. If you are looking for something useful now, LB4 is not the place to look…
That being said, I can watch your changes with an eye to the plans for LB4. You are right that 3.x is not a dead-end. My plan has been to to keep 3.x maintained for the foreseeable future but limit the changes to bugfixes and feature improvements that do not require extensive changes to the codebase. Changes in the 4.0 codebase will be backported back as it makes sense as well, but I would like to keep at Java 7.x support in the 3.x codebase which can limit some of the code sharing. You’d be surprised how many people are still on Java 7 and I don’t want to cut them out of the maintained codebase.
I understand your need for to get something out right away for use and an independent project makes sense for that, but from an end-user-confusion standpoint, I think it would be nice to see if we could fold your changes into the main Liquibase codeline as soon as we can. If you have done the hard work of integrating and testing a large number of the pull requests that is hugely helpful and I’d definitely like to take advantage of that.
I’ll take a look at your fork tomorrow and the changes you have made. Perhaps the majority of it can be brought in directly? I’ll see what they look like. It is hard to break existing work into separate pull requests, but I can probably just look at the branch diffs as a whole.
Great to see you have working integration tests for the OSS databases. I’ll definitely look at that. Sonar would also be helpful to use, is that set up within your CircleCI config currently?
My pressing deadlines actually ended a week or so ago and I had already started to return to Liquibase proper, but on the 4.0 side initially. However, if there is a pressing need and offers to help on the 3.x side I will gladly look at that instead.
Nathan
You should be able to use Liquibase just fine on JDK 8 no matter how it’s built. We just need to make sure it’s compiled with JDK 7 so it can be used by people on that version still. It’s actually currently actually built with JDK 6 but I’d be OK with increasing to 7 at this point. Java 7 is not supported in general even, but there are still a good number of people still using it. The main problem for us is not being able to use nice JDK 8 syntax that we’d like, but better to keep it available to more people.
I’ll take a look at the Sonar setup, thanks.
Don’t need anything else on the integrate side right now. I’m sure I’ll have more questions once I look at it.
Nathan
I looked through your changes, and you have definitely put in a good amount of work. Lots of good general cleanup in there along with the pull requests and bug fixes from you.
I didn’t see anything that that stood out to me as anything that couldn’t go into a 3.6 branch beyond the switch in Java support (and the name change, obviously ).
It’s a huge pain to have to try to cherry pick in the pieces that you merged and that would also lose the pull request connection and original author attribution which I like to preserve.
Therefore, I’m thinking the easiest route would be for me to create a new branch in liquibase where I can just merge in your changes directly as well as the 30ish outstanding commits from me not in your repo yet.
We won’t be able to switch to Java 8, but I think Java 7 would be fine for a 3.6.0 release since you’ve done a lot of work around removing the generic parameters where they would not be needed in 7. I didn’t see anything that would require 8 off hand, but the first step would be making sure it still compiles under Java7.
Once it compiles, I’ll have to go through and undo the naming changes using search/replace which should be easy, then do a full check of the remaining changes to make sure none of them are introducing significantly breaking changes. Intellij’s diff makes that not too terrible of a job, but it will take some time.
Once that is all done, I can merge back into master and we’ll be good to go and can talk about what makes sense next.
What do you think?
Nathan
I merged your repo into a branch and reverted naming in the pom’s and set it to Java 7. Definitely some Java 8 code we’d need to downgrade, but doesn’t seem to be anything too major so far. Maybe about 15 problem classes.
Nathan
I pushed by branch up as dbmanul-merge if you wanted to help work in there.
Nathan
Hi Nathan,
I just sent you a PR (via GitHub) with my first round of JDK7 compatibility patches. liquibase-core unit test work already, but there seems to be some JDK8 reference stuck in the maven-plugin which I cannot find ATM (one test fails with unsupported class version). I will take a look at it tomorrow.
Hope you like it,
Andreas
Thanks, it is merged in. I was seeing the same odd unsupportedClassVersion exception, it looks like Derby 10.13 requires Java 8. I downgraded to 10.12 and the tests pass. That change has been pushed to the branch.
I also finished going through all the changes in dbmanul vs. liquibase. Lots of great work you’ve done, especially around testing. I have a few notes and comments I’ll write up tomorrow but nothing major.
Thanks again,
Nathan
I merged in the pull request, thanks.
This thread thread is getting a bit long and off topic… I created http://forum.liquibase.org/#Topic/49382000001706009 with what I found going through your commits.
Nathan
Hi Nathan,
Bingo, that was the cause. I also verified the other JDBC drivers and changed the pom.xml so that compatible versions are used now. On my test VM, all embedded OSS RDBMS + MariaDB + PostgreSQL are working I will verify the rest (including commercial RDBMS) later when I get access to my primary machine again.
The results are available as a new PR in your repo now.
Cheers,
Andreas
P.S. This thread is getting a little lengthy, shall we move to the Developer’s subforum and create topics for new sub-tasks?