MapStruct should have means to mark getters / setters as going to be ignored

[sjaakd]

Suppose a reusable source dto:

public class MyDate {

    private Date date;

    public Date getDate() {
        return date;
    }

    public void setDate(Date date) {
        this.date = date;
    }

    public boolean isValid() {
        return date != null;
    }
}

Especially with the new nested mapping, I want to have some means that the isValid() is not considered a source accessor if by any chance somewhere in the structure of the target is a property valid.

Something like this:

public class MyDate {

    private Date date;

    public Date getDate() {
        return date;
    }

    public void setDate(Date date) {
        this.date = date;
    }

   @IgnoreAccessor
    public boolean isValid() {
        return date != null;
    }
}

[filiphr]

I think that we can do this and #1151 together. We can do the implementation flexible so that it uses an SPI (maybe even a list of SPIs) that provides a way for the user to give multiple annotations that can be used to ignore getter / setter. This way they can use their own annotations and can for example in one go ignore @Transient getters.

In the end @Deprecated is just another annotation that will be plugged into this SPI.

[agudian]

Especially with the new nested mapping, I want to have some means that the isValid() is not considered a source accessor if by any chance somewhere in the structure of the target is a property valid.

I don't see how this is different from not having the new auto mapping... If I don't want a property valid to be set from outside, I wouldn't create a public setter for it... Or I would use @Mapping annotations on the methods directly or for repeated stuff in @MapperConfig. That's much more in line of what we offered to do in the past.

But I like the idea of providing means to do it with an SPI, if there is really some special need for this.

[gunnarmorling]

Hey @sjaakd any further insights on why @agudian's proposal above isn't good enought (using @Mapping#ignore()?

[sjaakd]

I don't see how this is different from not having the new auto mapping...

Well. when I wrote this I spent half an hour troubleshooting on a mapping that MapStruct tried to make on java.util.date to our own type which was created 4 years ago and used in a lot of other projects. It happened on a nesting level so it was not immediately obvious.

This type is called in a lot of places. So I would like to be able to stick an @Ignore to this type iso having a lot of @Mapping( .. ignore=true). @MappingConfig is not an option. SPI might be. However, I think MapStruct would be enriched by an @Ignore on source - and target DTO's.

[TobLin921]

So is this SPI thing officially the solution if I want to exclude specific setters?

It seems like #1152 and #1151 closed citing each other with no action taken.

[sjaakd]

@TobLin921 : this one is not closed. Implementing this one would also offer a solution for #1151. However, we're not in agreement if marking the target properties is the way forward.. That's why its still open.

[pascalwhoop]

@sjaakd

protected  <R> R  getRepo(R repoType){
        return (R) SpringApplicationContext.getBeanByType(repoType.getClass());
    }

a method like the one above is automatically used in all sorts of tests of mine for various types, because of its generic nature. I believe the @ignore tag on the accessor/mapper is the only way.

[sjaakd]

Hi @pascalwhoop ,

Have a look at the SPI. I think you are able to exclude getRepo. There's an example in our example repository that should help you. You could probably re-use the DefaultAccessorNamingStrategy overriding the isGetterMethod, exclude methods name getRepo (with one arg) and calling the super.isGetterMethod

I'm going to close this issue.

There's a PR pending in 1.3 for supporting annotations on source/target side. Perhaps that could be used to fabric a solution as well (not relying on SPI). Not sure whether the PR will make it eventually.

[pavelhoral]

There's a PR pending in 1.3 for supporting annotations on source/target side.... Not sure whether the PR will make it eventually.

@sjaakd Can you link the PR? I went through 1.3 changelog and didn't find anything on this topic. Thank you.

[sjaakd]

@sjaakd Can you link the PR? I went through 1.3 changelog and didn't find anything on this topic. Thank you.

My answer dated from over a year ago.. We decided against having annotations on the source / target beans. So, I guess its up to implementing the SPI.

[ghost]

@sjaakd Having a separate artefact just to ignore a couple of methods is overkill, don't you agree?