.tesla.xxx.pom issues

[huntc]

As of commit bfc16c7, the creation of a .tesla.xxx.pom poses some new issues:

• developers will be expected to have their scm ignore .tesla* files;
• the encoding of a model to xml consumes more time vs using an xml directly; and most importantly
• the encoded .tesla.xxx.pom must conform to any restrictions imposed on the pom it was produced from.

I'm particularly concerned about the restriction conformance. For example on the tesla modules, the poms must have license headers. Generated poms do have such headers of course.

The approach of generating a .tesla.xxx.pom is concerning. According to commit bfc16c7 it is because the install plugin requires a pom.xml to deploy. Perhaps there's another way to approach this e.g. have a translate occur as part of the install plugin and reference the updated install plugin as part of the tesla build. The pom.xxx file should also be installed alongside any pom.xml. This approach would also require pom.xxx files to have a higher priority than pom.xml (which I think is a good thing anyhow).

[mkristian]

it is a hack and I agree with you that a better solution is needed. but let's see your points first - it should be possible to put that .tesla.pom* into the 'target' directory which should eliminate point 1 and 3 though it might impose another problem that 'target' needs to be hardcoded (or not - let's see)

yes, the install plugin would be the right place to "translate" the internal used model into xml and then make sure the deploy does use it as well. but the install plugin is outside the immediate scope of tesla-polyglot and with 'install' working (via that hack) tesla can be used on "real" projects.

I totally agree with pom.xxx having higher priority than pom.xml which I did so with the ruby part, i.e. the reactor and the parent resolution will pick the pom.rb as well. but when I start pom.scala I would expect the parent and reactor to use pom.scala files for that as well (not sure if that is ONLY my expectation)

[huntc]

Hi @mkristian - thanks for the response. Generating the .tesla.pom.* in the target folder would be a big improvement. Relating to point 2, could the generation of this file somehow be deferred to a later phase in the build cycle? It seems like an unnecessary overhead for many goals.

[mkristian]

I will ask Jason on how to it get into install-plugin which is probably the right place for ensuring the pom.XML

[huntc]

Awesome. Thanks.

[mkristian]

the target thingy did not work as hoped but I now mark that .tesla.* files
as deleteOnExit so the jvm will delete them after it is done. so we do not
pollute the filesystem with temporary files.

let's keep the issue open since we still need to find a way to move those
pom xml generation into the install plugin.

[huntc]

I was wondering how the target/ approach would work - the pom files are expected in the project root right?

deleteOnExit will be an improvement, but we are left with the third issue i.e. conforming to restrictions such as license files.

[mkristian]

yes, the problem is the project.basedir which is the directory in which the
pom files is located.

the license check - well for tesla itself we could add to the excludes list
as on unix based OS that is a hidden file anyways. in general that issue
remains for now.

about the install thing - in order to proceed without hopin on maven itself
to fix the issue for us, it would be possible to provide a small plugin
which can be executed on 'pre-integration-test' phase (i.e. some phase
before install or maybe install itself) to generate the pom.xml. the only
drawback is that model generator for each language needs to add that plugin
somehow - maybe that is 'too' much hidden magic. maybe that is possible to
hide it the same way the dynamic execution plugin gets added on the fly.

[huntc]

the license check - well for tesla itself we could add to the excludes list
as on unix based OS that is a hidden file anyways. in general that issue
remains for now.

Yeah, not just a tesla issue though perhaps... I can see this kind or problem occurring elsewhere.

[huntc]

@mkristian Is this still a problem?

[mkristian]

the files are still generated otherwise mvn install does not work but they
will be deleted on jvm exit. so they are not an issue for source control
frameworks.

if maven proper would serialize the current model and use that - then we
can get rid of those temporary files.

would say keep the issue open for now.

[jvanzyl]

I will take a look shortly to find a general solution.

[mkristian]

this is still needed to the extend that the generated .polyglot.pom.* is at least needed to have mvn install install the xml version of the POM. otherwise you end up with ruby or yaml or scala POMs in your local repo. for mvn deploy this is probably needed as well for the same reason. other maven plugins might need this as well. for other plugins an early execution of polyglot-translate-plugin would help as workaround.

the 'polyglot.dump.pom' property to permanently dump the temporary pom and pom.xml can be safely removed as the polyglot-translate-plugin can be used instead. maybe an extra config which allows to add this to generated pom.xml: https://github.com/takari/polyglot-maven/blob/master/polyglot-common/src/main/java/org/sonatype/maven/polyglot/TeslaModelProcessor.java#L45

[lefou]

What is the current state? I'm working with polyglot-scala in many projects, and there are no issue at all when installing or deploying. An update to this issue would be very appreciated. If the interop issues are solved for all dialects, please note this here, so that I can send a PR for the main README, to reflect the more stable nature of polyglot.

[mosabua]

Good question...