Modularization of fest-assert

[Tobias Gesellchen]

Hi all,

fest-assert currently cannot be used in environments like Android or GWT. You can find dedicated tickets at FEST-485 and FEST-466.

As proposed in FEST-485, splitting the current fest-assert-core to several modules could help using the library in Android. Modularization would also help separating concerns and keeping a core library focused on the most commonly used assertions while still enabling the use of special assertions by using specialized libraries.

One special library could be AWT specific, as this is a part of the JDK which isn't intensively used in modern web applications. Removing AWT specific code from the core library would minimize dependencies on quite specific parts of the JDK or other libraries. Android doesn't support that specific AWT part, so we could help e.g. Android developers by offering a core module without depending on AWT classes.

Other aspects of modularization aim at keeping the code DRY. Test factories currently being maintained in fest-assert-core/fest-assert-2.x should be moved to the already existing module fest-test, so that all fest modules could use commonly available test code.
With specialized fest-modules, one could also focus on special assertion classes for other libraries like Guava or Joda. You can find some thoughts about the advantages in the comments of FEST-485, especially at Joel's comment.

Joel already put some emphasis on keeping the API clear to make its usage as easy as possible for users. From my point of view a big help for the user would be a good naming pattern. The user doesn't want to search for the right module, so they want to find at least the core module as fast possible: I would suggest calling the public API "fest-assert". "fest-assert-core" is already too specific IMHO and would also be a candidate for some kind of internal API or a module containing abstract classes to ease the creation of specialized modules. Special modules could be called with a naming pattern like "fest-assert-awt", "fest-assert-gwt", "fest-assert-io", etc. Independently on the time when the actual modularization would be started, I suggest already calling the current 2.0 "main" module "fest-assert" instead of "fest-assert-core", just to be safe for the future.

You can already have a try with modularized fest-assertion libraries. All forked projects can be found on GitHub, most importantly the following ones:

• https://github.com/gesellix/fest-test
• https://github.com/gesellix/fest-assert-2.x
• https://github.com/gesellix/fest-assert-awt-2.x

The changes mainly address the compatibility issue with Android and they currently won't help with GWT. But I guess making fest-assert compatible with GWT would also force us to create specialized modules, because the core module should be kept clean from GWT dependencies.

What do you think about this proposal?

Regards,
Tobias

[Joel Costigliola]

On modularization, my preference would be to have a fest-assert module including all standard JDK assertions (it is basically the actual fest-assert-core), it would provide/include all assertions modules relying only on JDK.

Let's say we have split JDK assertions in 3 modules :

• fest-assert-awt
• fest-assert-io
• fest-assert-minimal (all remaining assertions not in previous modules)

fest-assert would only be a facade on those modules.

At this point, we can safely decide to split again fest-assert-minimal, for example with a collection assertion module.
We would only have to add this collection module in fest-assert facade.

We can create additional projects, like a fest-assert-android module that would include :

• fest-assert-minimal
• fest-assert-io
• fest-assert-collection

@Tobias : It would be nice to have a POC validating the facade concept.
One way to do that would be to :

• create a fest-assert project to be the facade of your fest-assert-core and fest-assert-awt
• fork my fest-examples project, create a "modularization" branch to show how to use fest-assert (fest-examples aims to be a real world fest client, I'm using it to have a user point of view on our assertions).
  

If the POC works fine, all we will have to do it to agree on modularization split.

Alex, WDYT ?

Cheers,

Joel

[Tobias Gesellchen]

Joel,

I'm ok with creating a POC showing a fest-assert facade. I'll come back here, when it's ready.

[Tobias Gesellchen]

You can find an example at a fork of Joel's examples with a dedicated test class at https://github.com/gesellix/fest-examples/blob/master/src/main/java/org/fest/assertions/examples/MixedAssertionFactoriesTest.java
The test class uses both modules (fest-assert-core and fest-assert-awt), which are included through transient dependencies. The only explicitly declared fest dependency is a new artifact called "fest-assert", which can be found at https://github.com/gesellix/fest-assert along with the other modified modules.
Most changes affect the fest-test artifact and fest-assert-2.x and a new module fest-assert-awt has been created.
A summary of the idea to modularize fest-assert can be found at http://www.gesellix.de/9-java-development/8-fest-assert-modularization.html

As you can see, using the facade approach, we are able to continue modularization without breaking all users' code, while enabling many other clients using fest-assert on restricted platform or in combination with less compatible frameworks. The only breaking change would be the need to introduce new Assertion factories for each module, in this case "AwtAssertions".

There's a minor flaw in the current proposal: You'll find a plain copy of the new BaseTestTemplate class in fest-assert-awt (https://github.com/gesellix/fest-assert-awt-2.x/blob/master/src/test/java/org/fest/assertions/api/BaseTestTemplate.java). I suggest cleaning up the core module to provide such test template and helper classes through a dedicated module like fest-test. In this case, moving the template class to fest-test wouldn't work, due to other dependencies, so I guess there's some cleanup necessary.

Nevertheless, I would like to accelerate the pull request provided at https://github.com/alexruiz/fest-test/pull/3, because merging changes made in fest-assert-2.x to the modularized forks is quite intensive and would make sense regardless on the modularization ;-) The pull request wouldn't contain any change in fest-assert-2.x, so accepting the pull request would only be half the way, but I still hope, we can find a quick solution with the proposed modularization and the mentioned design deficit with the BaseTestTemplate.

Thanks!

[Tobias Gesellchen]

Joel has merged the pull requests for fest-util and fest-test. The pull requests for fest-assert-2.x still have to be merged, but we would like to get some feedback from all fest developers (you!) before integrating such a huge change.

Other questions, slightly related to modularization, have come to our minds and we would like to discuss them here, too. I'd like to address them here, but we could probably create dedicated threads when the discussion becomes too big.

1. Naming: fest-assert-2.x should be renamed to fest-assert-core, so that it fits to a naming pattern like: "fest-assert-SUBJECT", where SUBJECT could be one of "core", "awt", "gwt", etc.
2. Administration: Some fest-assert modules are being hosted at https://github.com/alexruiz, some at https://github.com/joel-costigliola and some at https://github.com/gesellix. GitHub supports organizations, where teams can be managed along with several repositories. Creating an organization is free for open source projects.
3. Releases: Joel currently is the only one allowed to make releases. I won't list all the downsides here... ;)
4. Did I forget anything you have in mind regarding modularization and optimized workflow?

[Tobias Gesellchen]

Now all changes are available in the fest-assert-2.x codebase.

On Monday, August 20, 2012 10:21:35 PM UTC+2, Tobias Gesellchen wrote:

The pull requests for fest-assert-2.x still have to be merged, ...

 

[Joel Costigliola]

Github for FOSS organization is worth a try, I'm gonna ask for a Fest organization.
I will also look with Sonatype how to allow other people to make releases.

Joel

[Joel Costigliola]

I have created easytesting organization on github (sorry fest was not available), check here : https://github.com/organizations/easytesting

It has 4 owners : Alex, Ansgar, Tobias and me and two teams : fest-assert and fest-reflect (which still need to be populated with fest commiters and fest repos).

For the time being, I have cloned our dispatched repo (Alex's, Tobias's and mine's) unless fest-examples which has been transferred to easytesting organization, it means it's not a clone, it's the original fest-examples that I had created and we are all owners of this repo (not only me anymore).

I will check if everything works fine on fest-examples before transferring my other repos.
One advantage of transferring repos is to keep issues (open and closed) and, I hope the wiki (if not, it won't be hard to move).

With easytesting organization, we will have a better view of fest repos and ease contributions by allowing team member to contribute directly to the team's repos. It will also make fest more durable as it will have many owners so if one of us is not interested anymore of too busy, other can step up and continue fest development.

I hope you guys don't see any problem to transfer ownership of your repos to easytesting, I think this is a good move if we believe in open source, collaboration and trust.

Stay tuned,

Joel

--
You received this message because you are subscribed to the Google Groups "easytesting-dev" group.
To post to this group, send email to easytes...@googlegroups.com.
To unsubscribe from this group, send email to easytesting-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/easytesting-dev/-/NZveg0AgIBwJ.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alex Ruiz]

Hey guys,

I don't like the idea of modularization. I think it is an overkill, especially since extending FEST is so hard thanks to the lack of extension methods in Java. Like Joel said, we can remove the dependencies on AWT, and move them to FEST-Swing (a more natural place for them.)

About GWT, I don't think we should spend time on it. Is there a considerable number of users asking for it?

Regarding organizations: not for now. I'd like to keep the current repos, at least till I'm fully aware of the state of the code base. Let's revisit this in a couple of months from now.

Thanks,

-Alex

[Tobias Gesellchen]

Joel,

thanks for creating the organization so quickly.

For me it's not only ok, but mandatory that all FEST developers can push to my fest-repos and to the other fest-repos as well. Moving them to a central place is a huge step in the right direction so that we can focus on a central point and don't have to find all the scattered places of the FEST ecosystem. Being an open source library, FEST should be open and easy to reach for other people.

Tobias

[Joel Costigliola]

Tobias,

As Alex is Fest creator and natural leader, I will respect his choice of not moving now to a github organization even if my preference would be to use one.
Let's wait and discuss it again later on.

Joel

To view this discussion on the web visit https://groups.google.com/d/msg/easytesting-dev/-/Z8YkNbwziPQJ.

[Alex Ruiz]

Tobias,

Why is it mandatory for all FEST developers to push to your fest-repos? Sounds a little dogmatic, a la Richard Stallman. Also, the code is already in an central place: github.

All the committers have commit access to the repos. External contributions are welcome but we cannot guarantee they will be accepted. Commit access is granted based on merits. Joel and I were discussing this topic not long ago. We are revising the contribution guidelines.

Having said that, I really appreciate your interest in contributing to FEST. I'm looking forward to reviewing your contributions and getting to know you better.

Cheers,

-Alex

[Tobias Gesellchen]

Alex,

I hope you didn't understand me wrong. I didn't want to say that everyone must push to my repos. Instead, I wanted to express that I don't want to be the only person that pushes to a part of the fest-assert library (in this case fest-assert-awt and fest-assert). That's the reason, why I prefer a central place (e.g. an organization on GitHub) where all repos can be found and where a *team* is the owner of all repos. I wouldn't prefer to have commit access to your repos and I wouldn't prefer other people having commit access to my repos. For me a central team/organization would be an improvement of the current situation, where fest-assert is scattered over three places. GitHub is not central enough: what about other people creating modules which extend fest-assert and who also maintain their repos on GitHub? I don't want them all to move their repos to a easytesting-organization, but I would prefer a clear view on the "main" modules of the "main" fest developers - thinking of a reference implementation for fest-assert, but open for extensions. How would you like to express which repos are part of the minimal or reference implementation? I really beg you to allow us moving FEST to a central place, I have the feeling that it would life much easier for all contributors. At least, please don't let us wait for "months" ;-)

You told us a quite clear statement against modularization, but would you like to explain your reasons? You mentioned "overkill", but did you already have a look at the current changes? There wasn't too much change from a conceptional point of view, I would even say that modularization makes the codebase even cleaner and more maintainable. The current separation of awt dependent classes showed us that it made sense to extract many factory classes to another module. Moving code to the right place is one aspect of making the whole codebase more stable. Modularization is one way of separating concerns, which can be overkill when modules are cut too small or cut at the wrong borders. But creating modules helps keeping the focus of each module small enough, thinking of its responsibilty and it also helps in administrative tasks, e.g. when creating new releases of only a small set of modules.

It sounds like you don't see Java as a language to support extensions. I have to admit, that you are right in a general point of view.  But for cases like "statically" separating dependencies like moving awt dependent classes to another place, there's no need of an extension mechanism. We only need to add or remove libraries from the classpath to add or remove functionality.

Talking about GWT, I'm currently completely with you, but mainly because I don't know GWT well enough and I'm quite sure that making FEST compatible to GWT won't be as easy as making FEST compatible to Android.

Regards,

Tobias

[Alex Ruiz]

Tobias,

In response to "what about other people creating modules which extend fest-assert and who also maintain their repos on GitHub?":

People are free to fork the current repos and do whatever they want with their clones. I don't have any intention to consolidate work from people outside the team just for the sake of consolidation. I need to be convinced that any contribution adds value to the user.

Let's talk about organizations after we release FEST-Assert 2.0. I'm using my spare time, which is in part my family's spare time to clean up the code base before we have the final release. BTW, I don't see the need of FEST-Assert-AWT. It should be part of FEST-Swing.

The problem with modularization is user experience. Since we are using "assertThat" as a static methods, we cannot add extensions to that. Java does not allow it. (Other languages like Xtend do though. BTW, I don't have any plans to support other languages, specially Groovy.) So with extensions, users have to two assertThat (e.g. one from the main Assert project and another from a module). Things get messy if you want to use static imports. Again, we can revisit this after the 2.0 release. The 2.0 release won't have any AWT-related assertions, BTW. Joel make the case for Guava Assertions, which I really like, but again, that will come later.

Tobias, I'm sorry if my answers are a little too short. Right now the main thing is to get Assert 2.0 out. It would be nice for our users including myself, I really want to update FEST inside Google.

Cheers,

-Alex

--
You received this message because you are subscribed to the Google Groups "easytesting-dev" group.
To post to this group, send email to easytes...@googlegroups.com.
To unsubscribe from this group, send email to easytesting-d...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/easytesting-dev/-/JA8e_T5j0PcJ.