Closed gesellix closed 12 years ago
Unfortunately merge was almost impossible due to the number of conflicts :( - which I don't have a good explanation for, I thus had to update the fest-assert code use the new version fest-test and fest-util.
I hope I haven't forgotten stuff but in that case it should not be difficult to fix/update.
Thanks! I'll have a look at the current codebase this evening. In case there's missing something, I'll come back to you or create another pull request. I just saw that the travis-ci configuration was included in the pull requests, too. Would you like to keep them or would you prefer me to remove them and create new pull requests?
Thanks for reviewing the codebase, for travis-ci configuration I would prefer it to be removed.
On Mon, Aug 20, 2012 at 3:46 PM, Tobias Gesellchen <notifications@github.com
wrote:
Thanks! I'll have a look at the current codebase this evening. In case there's missing something, I'll come back to you or create another pull request. I just saw that the travis-ci configuration was included in the pull requests, too. Would you like to keep them or would you prefer me to remove them and create new pull requests?
— Reply to this email directly or view it on GitHubhttps://github.com/alexruiz/fest-assert-2.x/pull/99#issuecomment-7869473.
I created another pull request on fest-test and fest-assert-2.x. Some AWT specific classes had to be removed.
Remaining repos to be pulled beside the other modules would be: https://github.com/gesellix/fest-assert-awt-2.x https://github.com/gesellix/fest-assert
Tobias, let's summarize the approach here to see if we fully agree :
fest-assert-2.x
provides only core assertions that is all jdk assertions but awt ones which entails breaking compatibility (and btw, to rename the repo fest-assert-core
to be consistent with artifact name)fest-assert-awt
provides only AWT assertions - reference repo is yoursfest-assert
aggregates assertions from fest-assert-core
and fest-assert-awt
I'm ok with that, I have just troubles with having decided without much discussion (even though one's might argue that it was on the dev mailing list and we had not much feedback) maybe august is not the best moment to take major decisions.
Another point is repository administration, you are admin of two repositories, Alex of three and I have three (examples, generator and eclipse plugin). It's a little bit confusing but I don't really see other viable options (Alex is too busy to manage all repo for the time being). My opinion is to allow all fest developers to contribute to all repositories : that is being really open and trust commiters.
Last thing, we need to add documentation on (yours) fest-assert
explaining how to use different modules, we should also add a test to show how to consume assertions from different modules (to be done also in fest-examples but that is less important).
Real last thing :) is to allow developers to make releases, I'm the only one who can make releases and it's not good.
Joel
ps : we should probably summarize that in the dev list
I'm ok with your suggestions and would also like to discuss polishing of our thoughts on the dev mailing list. The only thing to be discussed here would be the pull requests.
Currently we are in the middle of a refactoring and I personally would like to push all changes into the official codebase, just to make sure that we have a codebase to discuss about. With all modules in a working and clean state, we can let users work on that codebase, especially try to use fest-assert-core on Android, which was one of the main motivations.
I'll add Documentation to fest-assert
(mine) and a little demo/test using both fest-assert-core
and fest-assert-awt
.
See https://groups.google.com/d/topic/easytesting-dev/qVI2n2GGB44/discussion and https://jira.codehaus.org/browse/FEST-485 for details. You will also need to merge changes in fest-test, fest-util and other modules to complete this modularization. Two additional modules have been created at https://github.com/gesellix/fest-assert-awt-2.x and https://github.com/gesellix/fest-assert .