@AutomaticFeature annotation deprecation warning from GraalVM native-image build about graal-build-time HOT 18 CLOSED

Anyway, I'm fine with a 1.0.0 release :)

from graal-build-time.

I like both 3 and 4 as make clear to users what will do as it's what they care that the feature will do

from graal-build-time.

or 3, also fine, agreed :)

from graal-build-time.

Yeah, probably just documentation that users should add that flag to their build?

from graal-build-time.

I think it might be better to add an explicit package to that class as well.

from graal-build-time.

Yup and yes.

This is technically a breaking change.

So might as well go to a v1.x release.

from graal-build-time.

I don't think this is a breaking change since users didn't have to reference the class name before, it was automatic.

from graal-build-time.

But the build interface will have changed, no?

After users bump graal-build-time, builds will break if they don't take action of adding --features=.....
(assuming that we also remove the @AutomaticFeature annotation which is slated for removal by Graal team).

The break is imposed by changes to Graal, but still breaking from a user perspective, I think.

from graal-build-time.

Right, but that's not a breaking change in our library

from graal-build-time.

Also, I think it might be good to move to io.github instead of com.github

from graal-build-time.

@borkdude, for the io.github scheme I see your old question on Slack:

For a library coordinate, do you prefer com.github.foo/lib or io.github.foo/lib or don't care? Tag with ⬅️ for the first, ➡️ for the second or 🤷 with don't care.

And Alex Miller responded with:

I prefer the latter because it maps to the web page you can publish from the project (which maybe is the seed of an ownership verification scheme)

Is that still the primary benefit?

(Totally fine with this btw, just trying to understand what problem we are solving)

from graal-build-time.

The problem is that everyone seems to have shifted to that, but it doesn't really matter that much

from graal-build-time.

I'm making a sweep update to graal-docs, clj-easy/graal-docs#58.

I may as well tackle this one so I can use something not-deprecated in examples.

from graal-build-time.

I think I'll stick with com.github for the artifact so that tools like antq can discover the new version.

The new version won't work for folks without any changes, but at least they'll be more likely to learn about it. And the CHANGELOG/README will explain.

Does that make sense to you too?

from graal-build-time.

Yeah, let's stay with com.github.

from graal-build-time.

Implementation note: now that we aren't using a java annotation, thought it might be nicer to switch our java source to clojure source and use :gen-class. It did not work out (something to do with default interface methods).
Sticking with java source.

from graal-build-time.

Currently our fully qualified Feature class is InitAtBuildTimeFeature (it is package-less).

New name candidates:

1. clj_easy.graal_build_time.InitAtBuildTimeFeature - keeps old name but adds package
2. clj_easy.graal_build_time.InitAtBuildTime - it will be obvious it is a feature, we can drop the suffix
3. clj_easy.graal_build_time.InitClojureClasses - describes specific goal
4. clj_easy.graal_build_time.InitClojurePackages - describes actual work
5. clj_easy.graal_build.time.ClojureTweaks - generic name, allows Feature to take on additional work in some later version if need be.

Because this name will be now specified on the native-image command line it deserves a bit of thought.

I seem to like the package name (as I haven't shown any alternatives!).
My wip is currently using option 3 but am very open to ideas/feeback/suggestions.

from graal-build-time.

4 would be the best I think

from graal-build-time.