Fabrizio Giudici

Lieven, you started right, but ended wrong... :-) Overall, you're right: nobody should feel forced to use the release maven plugin if it doesn't fit the release process he wants. In fact, first you define a release process, then you use/adapt the best tool to run it. We agree. I don't have remarks about the release process you describe - I woulnd't use it as is, but in this area there is room for variants, above all it depends on the context (a single developer, a small agile team, a medium sized team or a large team of course would choose different processes).

But:

Releases are not something done on a whim. They are carefully planned and orchestrated actions, preceded by countless rules and followed by more rules.

Sure. This doesn't mean that they shouldn't be automated as much as possible. This doesn't mean that at a certain point one might have performed all the homework and approved a release, and then the decision of making a release could just turn into pressing a button (e.g. launch a job in Hudson which in turn runs Maven). The Maven release plugin might support or not this automated process, but this is another matter. Small projects, such as libraries, that have adequate test coverage can be released as frequently as one wants, for instance.

Releasing software is a process, not a single command on the command line.

What kind of logics does infer that "a process" cannot be automated, partially or totally? Manual processes are error-prone and the last thing that I'd like to see is a release failed for a trivial manual error (I've seen a lot).

Then you wrote some Maven facts that are very incorrect.

Even Maven’s most fierce supporters agree on this. The Maven release plugin just tries to do too much stuff at once: build your software, tag it, build it again, deploy it, build the site (triggering yet another build in the process) and deploy the site. And whilst doing that, running the tests x times. Most of the time, you’re making candidate releases, so building the complete documentation is a complete waste of time.

False. The release maven plugin can be customized in very flexible ways. You can disable running tests, generating the javadoc, or the source jars, and the site, and eventually design profiles to have variants on these choices. Have you ever read about the preparationGoals, goals, completionGoals properties of the plugin? To give concrete examples: I don't need the Maven generated site, so site generation is always disabled for me. I also disabled tests, because before releasing I run tests separately. The core of the release cycle can just be: check that everything is compilable, tag and prepare the next version, and then run a forked Maven that checks out from the tag and performs the build.

The release plugin is just a combination of the versions, scm, deploy and site plugin that seriously violates the single responsibility principle.

Apart from the fact that this comment on internal software quality need not to have to do with usability (there are famous counter-examples: many say that Wordpress and JIRA are poorly designed, still they work well and are very popular), your statement is erroneous... Anyway composing stuff, as you correctly say, does not violate the SRP. The important thing is that the single components have a single responsibility, and in this is true with the mentioned plugins. If your sentence was true, we should only have software apps that do a single, simple thing.

The release plugin is one of the reasons Maven has gotten a bad reputation with some people.

Maven could have a bad reputation with some people because they legitimately don't like the way it works or because people just don't read the f***ing manual, and then blog incorrect things. :-)

I set up a number of industrial products where releases are managed with the release-plugin and in most cases no problems. Yes, we do Releases Candidates too. In a case where the customer is not totally satisfied with the release plugin, he is not really satisfied with the way dependencies are managed (e.g. because you have a dependency graph among subprojects with many levels and there are "ripples" when dependencies are updated. I verified that some people have similar problems with different tools, such as Gradle, so it has more to do with the process, the project structure, the dependency management, and not the release plugin.

Lieven, you started right, but ended wrong... :-) Overall, you're right: nobody should feel forced to use the release maven plugin if it doesn't fit the release process he wants. In fact, first you define a release process, then you use/adapt the best tool to run it. We agree. I don't have remarks about the release process you describe - I woulnd't use it as is, but in this area there is room for variants, above all it depends on the context (a single developer, a small agile team, a medium sized team or a large team of course would choose different processes).

But:

Releases are not something done on a whim. They are carefully planned and orchestrated actions, preceded by countless rules and followed by more rules.

Sure. This doesn't mean that they shouldn't be automated as much as possible. This doesn't mean that at a certain point one might have performed all the homework and approved a release, and then the decision of making a release could just turn into pressing a button (e.g. launch a job in Hudson which in turn runs Maven). The Maven release plugin might support or not this automated process, but this is another matter. Small projects, such as libraries, that have adequate test coverage can be released as frequently as one wants, for instance.

Releasing software is a process, not a single command on the command line.

What kind of logics does infer that "a process" cannot be automated, partially or totally? Manual processes are error-prone and the last thing that I'd like to see is a release failed for a trivial manual error (I've seen a lot).

Then you wrote some Maven facts that are very incorrect.

Even Maven’s most fierce supporters agree on this. The Maven release plugin just tries to do too much stuff at once: build your software, tag it, build it again, deploy it, build the site (triggering yet another build in the process) and deploy the site. And whilst doing that, running the tests x times. Most of the time, you’re making candidate releases, so building the complete documentation is a complete waste of time.

False. The release maven plugin can be customized in very flexible ways. You can disable running tests, generating the javadoc, or the source jars, and the site, and eventually design profiles to have variants on these choices. Have you ever read about the preparationGoals, goals, completionGoals properties of the plugin? To give concrete examples: I don't need the Maven generated site, so site generation is always disabled for me. I also disabled tests, because before releasing I run tests separately. The core of the release cycle can just be: check that everything is compilable, tag and prepare the next version, and then run a forked Maven that checks out from the tag and performs the build.

The release plugin is just a combination of the versions, scm, deploy and site plugin that seriously violates the single responsibility principle.

Apart from the fact that this comment on internal software quality need not to have to do with usability (there are famous counter-examples: many say that Wordpress and JIRA are poorly designed, still they work well and are very popular), your statement is erroneous... Anyway composing stuff, as you correctly say, does not violate the SRP. The important thing is that the single components have a single responsibility, and in this is true with the mentioned plugins. If your sentence was true, we should only have software apps that do a single, simple thing.

The release plugin is one of the reasons Maven has gotten a bad reputation with some people.

Maven could have a bad reputation with some people because they legitimately don't like the way it works or because people just don't read the f***ing manual, and then blog incorrect things. :-)

I set up a number of industrial products where releases are managed with the release-plugin and in most cases no problems. Yes, we do Releases Candidates too. In a case where the customer is not totally satisfied with the release plugin, he is not really satisfied with the way dependencies are managed (e.g. because you have a dependency graph among subprojects with many levels and there are "ripples" when dependencies are updated. I verified that some people have similar problems with different tools, such as Gradle, so it has more to do with the process, the project structure, the dependency management, and not the release plugin.

Given that we're commenting regex maps, I've been using another home-made since a few time. It works for my specific projects that needs it, but I never validated it against the Map contract. I'd like to get some feedback just while you're still hot about the topic ;-). It is not optimized with pattern compilation, but it does super.put() and has a shortcut for gets whose arg is not a regexp (which in my use cases happens 80% of the time). My impression is that designing an implementation that is optimized for a lot of generic cases *and* it complies with Map contract is a hard task.

public class RegexTreeMap<Type> extends TreeMap<String, Type> { @Nonnull public static String escape (final @Nonnull String string) { final StringBuilder builder = new StringBuilder(); for (int i = 0; i < string.length(); i++) { final char c = string.charAt(i); if ("[\\^$.|?*+()".contains("" + c)) { builder.append('\\'); } builder.append(c); } return builder.toString(); } @Override public Type put (final @Nonnull String string, final Type value) { return super.put(Pattern.quote(string), value); } public Type putRegex (final @Nonnull String regex, final Type value) { return super.put(regex, value); } @Override public Type get (final @Nonnull Object value) { final String stringValue = (String)value; Type result = super.get(Pattern.quote(stringValue)); // first try a direct match that is fast int matchLength = 0; if (result == null) // otherwise returns the longest match { for (final Entry<String, Type> entry : super.entrySet()) { final String regex = entry.getKey(); if (stringValue.matches(regex) && (regex.length() > matchLength)) { result = entry.getValue(); matchLength = regex.length(); } } } return result; } } 

I could be wrong, but I don't think that in order to activate @PostConstruct you need Spring MVC, thus the dependencies you mentioned on Spring Web and Servlet. AFAIK,<mvc:annotation-driven> isn't the only way to go, as <context:annotation-config> is enough, and only requires depending on Spring Context.

Before saying that I mostly disagree, I think it's necessary to make a preamble. "Evil" and "good" are often misused in our world. I think they are good for a brief title or for telling things with some humour, but "appropriate" and "unappropriate" are better terms. In other words, there's no black and white, but a scale of greys. There's no "true OOP" in practice, you can do things in many ways, paying some costs and getting benefits. The important thing is that you are aware of your choice, I mean, you are aware of what you are going to pay and what are you going to get, and you are consistent.

The basic point is not related to the danger of exposing the internal state. It's to depend on a public thing. For instance, if I have a Person with firstName, lastName and age properties, and I use them by means of getters, my whole application potentially depends on these three properties. If any of these properties change (let me say it disappears), you have broken code potentially everywhere. Of course, it's unlikely that a firstName, lastName disappears from a Person. So in this very example, one might assume that the risks of going with getter / setters are low. Let's just think of a more complex domain where properties are more likely to change.

In this case, the risks might be higher. What I'd do is not to expose those properties as public, but as package friends. If I have to render Person e.g. on a web page, I'd write a PersonRenderer which has a method render(Person, WebPage) [with WebPage I mean any infrastructure related to a give web technology to render something] which does the job. Should I send an email to that person, I'd use a similar friend class PersonEmailer, etc. With this approach, I know that the dependencies on the structure of Person are well known in advance and I can predict what impact will have any change in the structure of Person (of course, I can say the impact is very small).

Is it better or not? Sure, it's more complex, because I have more classes (even though they are very small and simple). I've written and Android application using this approach and, once you've understood it, it's not that difficult. But I agree, it's not necessarily always the best solution. See my preamble.

For what concerns DTO in DDD, there's a way to fix the anemic object thing which make it also possible to work without getter/setters: DCI. Google for DCI and read the Artima's article for quickly learning on it. In short, your entities get decomposed in an anemic object (what would be he DTO, called Datum) and a number of active classes (Roles) doing operations on it. Roles are not services, since there's an instance of Role per each Datum. Without getter/setters the Datum basically has no methods. I'd have person.getRenderer().renderTo(renderable) for rendering it, or person.getEmailer().sendEmailTo(recipient) in a simple fashion. If I am concerned about decoupling dependencies, I can have a dynamic approach as person.getRole(Renderer).renderTo(renderable) [or a better syntax that I prefer, person.as(Renderer).renderTo(renderable)], and roles can be dynamically injected in a number of ways.To deal with frameworks that absolutely want getters/setters as JPA, I can have person.as(Persistable).persist(), where the specific implementation of Persistable would copy the internal state of Person into a JPAPersonBean and do the job trasparently. You get that I have another advantage here, that I can replace the persistence mechanism as I want.

This is very powerful, very extensible, very robust. It costs a bit more than a plain design with getters/setters. In a way, I think it's a very appropriate way to use OOP, since the Single Responsibility Principle is respected to a very fine grain. In some cases, though, it can cost too much for the purpose.

Actually we don't know if this comes out of a listening to the community. It could be that Oracle acted on its own, and possibly the Apple public news of "deprecation" were a part of a negotiating strategy (that could have been started much earlier than we know). In fact, we don't know the detail of the deal.

For what concerns the sanity of our teeth, the solution is obvious: we of course start commenting about news just after five minutes, but we don't get too worried about consequences for some time, not thinking that the lack of an immediate communication from any corporate means a complete lack of strategy / interest / whatever.

Of course, these are good news and the closing of a very old problem in the community. This demontrates that having a strong steward is better than having a weak steward... at least for some things. Of course, we pay the strenght of Oracle in other ways (see Apache etc...).

rarely uses more than two formal type parameters, three or four being the absolute maximum.

Agreed - we're discussing what happens in the minority of cases. Re: javadoc, is not an option. javadoc is needed and good for readers and understanding what's going on; for pure code readability, javadoc/comments must be the last chance.

I've posted here a screencast of the application running with about 1.000 elements. The screencast is neither cut nor accelerated, you can see the real speed on a MacBook Pro.

For what concerns my original demo, the only problem I see on JavaFX 1.2 is some parts of the layout screwed up.

Krzysztof, no, I didn't see problems with that handful of names. BTW, I have another application where a similar trick is used and it works with about 1.000 items, with only some slightly noticeable delay in some cases. Of course, with such a big number of items you probably have to do some smarter filtering rather than using subsequences.

The fact that you do things in JavaFX "better" than Java is subjective, at this time, and related to a number of things. For me, I don't see compelling reasons for turning my Java desktop stuff into JavaFX _now_. If I had some compelling graphics requirements, at the point to throw a graphic designer into the team, JavaFX would make the difference. I expect the two different perspectives to get closer and closer in the next years.

Objectively, JavaFX is more coincise and binding is the key trick. Try to write the same example I'm talking of in Java. Of course, the same functional binding could be introduced in Java (thinking of it...) thus even Java programs could be much shorter. But with Java binding can't be as natural as is with JavaFX.

I wonder if the model classes could be written is regular Java, instead.

It's one of the things I'll try in future. For now, the only thing I've done is to run javap on a compiled JavaFX value object, and - as expected - I saw it's very different from a regular JavaBean. Basically every attribute its an independent object, I presume with its own get()/set() and binding support. But there are also lots of other stuff that I don't understand at a glance.

[Mistral:src/ContactList/dist] fritz% javap -classpath ContactList.jar it.tidalwave.javafxstuff.contactlist.model.Contact
Compiled from "Contact.fx"
public class it.tidalwave.javafxstuff.contactlist.model.Contact extends java.lang.Object implements it.tidalwave.javafxstuff.contactlist.model.Contact$Intf,com.sun.javafx.runtime.FXObject{
 public final com.sun.javafx.runtime.location.ObjectVariable $id;
 public final com.sun.javafx.runtime.location.ObjectVariable $firstName;
 public final com.sun.javafx.runtime.location.ObjectVariable $lastName;
 public final com.sun.javafx.runtime.location.ObjectVariable $phone;
 public final com.sun.javafx.runtime.location.ObjectVariable $email;
 public final com.sun.javafx.runtime.location.ObjectVariable $photo;
 public static java.lang.String toString$impl(it.tidalwave.javafxstuff.contactlist.model.Contact$Intf);
 public com.sun.javafx.runtime.location.ObjectVariable get$id();
 public com.sun.javafx.runtime.location.ObjectVariable get$firstName();
 public com.sun.javafx.runtime.location.ObjectVariable get$lastName();
 public com.sun.javafx.runtime.location.ObjectVariable get$phone();
 public com.sun.javafx.runtime.location.ObjectVariable get$email();
 public com.sun.javafx.runtime.location.ObjectVariable get$photo();
 public static void applyDefaults$id(it.tidalwave.javafxstuff.contactlist.model.Contact$Intf);
 public static void applyDefaults$firstName(it.tidalwave.javafxstuff.contactlist.model.Contact$Intf);
 public static void applyDefaults$lastName(it.tidalwave.javafxstuff.contactlist.model.Contact$Intf);
 public static void applyDefaults$phone(it.tidalwave.javafxstuff.contactlist.model.Contact$Intf);
 public static void applyDefaults$email(it.tidalwave.javafxstuff.contactlist.model.Contact$Intf);
 public static void applyDefaults$photo(it.tidalwave.javafxstuff.contactlist.model.Contact$Intf);
 public void initialize$();
 public static void addTriggers$(it.tidalwave.javafxstuff.contactlist.model.Contact$Intf);
 public java.lang.String toString();
 public it.tidalwave.javafxstuff.contactlist.model.Contact();
 public it.tidalwave.javafxstuff.contactlist.model.Contact(boolean);
 public static void userInit$(it.tidalwave.javafxstuff.contactlist.model.Contact$Intf);
 public static void postInit$(it.tidalwave.javafxstuff.contactlist.model.Contact$Intf);
 public static void main(java.lang.String[]) throws java.lang.Throwable;
 static {};
}

--Fabrizio Giudici