Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [jdt-core-dev] Questions on Java 9 Modules API

Hi Fred,

Regarding your previous question: yes: when m2e resolves its
classpath container, it would be good to add the module=true
classpath attribute to each modular entry.
This is the official way for telling JDT that a dependency
should be considered as part of the module path.
Or, would m2e be switched into modular mode entirely and
the module=true attribute should be set on the container entry
in .classpath? This would be your choice, I guess, as typically
that container is added to .classpath by m2e's wizard, right?
Anyway, whatever JDT finds in the resolved container, it will use.

On 05.09.2017 22:27, Fred Bricon wrote:
Hi,

I'm looking into providing support for Java 9 in m2e.

The way the module path is computed in Maven is via reading module-info.class, or module-info.java first, list all required modules, then iterate over all dependencies in the project classpath, check if a dependency is in the list of required modules, then Maven adds it to the module path.

When a project is configured via m2e, we gather all classpath informations from the Maven in-memory model then try to match that into JDT settings (add Java nature, build Maven classpath container entries from Maven dependencies...)

So, what I'm looking for, to try to reproduce Maven's behavior, is a way to:

1 - get all required modules from a module-info.java file (at that point the project is not a Java project yet), so will most likely rely on some AST parsing

Well, if you have a Java project, JDT provides AST for all its elements,
incl. module-info.java. If you don't (yet) have a Java project, invoking
ASTParser as if in standalone mode, might serve your request. I believe
you need to be sure to tell the ASTParser the file name, so it has a chance
to get restricted keywords right ;p

2 - find the module name (either automatic or implicit) of a given jar (from File or Path)

We recently added internal API
   org.eclipse.jdt.internal.compiler.env.AutomaticModuleNaming.determineAutomaticModuleName(String)

If you need this as public API, please file a bug, but obtaining all this
information from a Java project, before it is created sounds weired to me.
I thought all the resolving happens much later, viz. when the configured
classpath container is resolved, no? Do you really need to resolve the
container before you add it to the project??
Shouldn't we be discussing, how to use the Java Model etc. to get this
information, after the Java nature has been added?

best,
Stephan




Back to the top