Note we might want to wait for HSEARCH-3291 Open to be solved first, to avoid conflicts when merging PRs.

Of course we'll keep the old @Field annotation in the compatibility layer ( HSEARCH-3282 Open ).

Main motivations:

• avoid exposing options that don't make sense, such as an analyzer on a numeric field.
• make it very obvious to users that, for each full-text field they configure, they need to pick an analyzer.

Rename @Field to @GenericField, but remove options that are not relevant for most types (mostly full-text ones: analyzer, normalizer, …).

Introduce additional @XXXField annotations when type-specific parameters make sense. Note that in @XXXField annotations, XXX refers to the index field type, not to the mapped property type.

In particular introduce @FullTextField, the only one accepting a (mandatory) "analyzer" parameter, and @KeywordField, the only one accepting an (optional) "normalizer" parameter.

Let's not rush it for the other annotations: we can always add them later, when we actually have type-specific parameters to pass to the annotation.

Examples:

	@FullTextField(analyzer="standard")
	String bigContent;

	@KeywordField(bridge = "titleBridge", name = "title_keyword")
	@FullTextField(bridge = "titleBridge", name = "title_fulltext", analyzer = "standard") // analyzer is mandatory here
	String title;

	@KeywordField(name = "ISBN")
	// OR @GenericField(name = "ISBN")
	ISBN isbn;

	@NumericField(name = "id", numericOnlyOption = ...)
	// OR @GenericField(name = "id", numericOnlyOption = ...)
	Long id;

	@TemporalField(name = …, resolution = …)
	LocalDate date;

	@GenericField(name = “ip”, bridge = “ipAddressBridge”)
	IPAdress ip;

	@GenericField(name = “ip”, bridge = “ipAddressBridge”)
	IPAdress ip;