Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.polyglot.pom.yaml #238

Open
hajdamak opened this issue Jan 31, 2022 · 11 comments
Open

.polyglot.pom.yaml #238

hajdamak opened this issue Jan 31, 2022 · 11 comments

Comments

@hajdamak
Copy link

When using polyglot yaml during build .polyglot.pom.yaml file is created in root directory and deleted.
Can this be avoided? Or configured so the file is created in target?
Additionally after importing this project in IDEA this file remains.

@jvanzyl
Copy link
Contributor

jvanzyl commented Feb 7, 2022

Any particular reason?

@hajdamak
Copy link
Author

hajdamak commented Feb 15, 2022

In general I believe creating and deleting files during build in main project directory does not seem to be elegant solution and it might be confusing for users. In ideal world Polyglot would create Maven project model in memory from YAML using Maven API but as I understand this would require some major changes to Maven itself. Right?
And therefore Polyglot just translates YAML file to XML file. This is less elegant but if Polyglot cannot be implemented in any other way in feasible time then IMHO at least this temporary file should be created in directory target which seems to be standard place for generated files in Maven. This will be less confusing IMHO.

@jvanzyl
Copy link
Contributor

jvanzyl commented Feb 16, 2022

Polyglot works by translating the model in memory. The XML files are produced so that any tool expecting an XML-based POM file, like Maven itself, still work correctly. Polyglot is an optional extension, and so if 10% of Maven users started using the Kotlin dialect and published Kotlin POMs to Maven Central it would break many things. The emitted XML files are there for compatibility, not because Polyglot Maven needs to operate on XML files.

@hajdamak
Copy link
Author

By generating in memory I meant that Polyglot would generate model in Maven's memory so that Maven wouldn't need to read XML at all. Basically Polyglot would replace POM loading in Maven itself so no XML is needed at all by Maven. That would be ideal solution. But as I understand this is not the case and XML needs to be generated. But if so at lease it should be generated in directory where all other generated files are generated.

@jvanzyl
Copy link
Contributor

jvanzyl commented Feb 16, 2022

It does not need to read XML at all, and it doesn't.

@hajdamak
Copy link
Author

But you wrote "The XML files are produced so that any tool expecting an XML-based POM file, like Maven itself, still work correctly." If Maven does not read XML at all why it needs it to work correctly? Or you meant something different?
Still generated file should be created in directory for generated files, or at least location should be configurable. Moreover if Maven does not need this file at all it should be possible to disable generation of this file at all.

@jvanzyl
Copy link
Contributor

jvanzyl commented Feb 16, 2022

Maven with the polyglot extension enabled can read the various non-XML formats natively. Most people don't use the polyglot extension so in that mode normal Maven falls into the same bucket as all the other tools that only process XML. If you're on a team that uses polygot and the projects using polyglot are not consumed by other projects then it would be safe to turn off the XML generation.

@hajdamak
Copy link
Author

Exactly. So coming back to my original question is it possible to avoid generation of this file?

@jvanzyl
Copy link
Contributor

jvanzyl commented Feb 16, 2022

Optionally turning it off I think would be fine.

@hajdamak
Copy link
Author

But is it possible with current implementation or change is needed?

@jvanzyl
Copy link
Contributor

jvanzyl commented Feb 18, 2022

It's something we'd need a PR for.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants