Community
Participate
Working Groups
Target definition files can be build with tycho also and it should be possible to use them pomless. As the definition for this task is rather restrictive [1] it should be possible to derive all required information with the following chain: - if there is exactly one target file use that - if there is more than one target use that one that matches <foldername>.target - else fail with a appropriate message [1] https://wiki.eclipse.org/Tycho/Packaging_Types#eclipse-target-definition
New Gerrit change created: https://git.eclipse.org/r/148033
I have provided an implementation, I also like to use this Review to discuss a more powerful approach of parsing and generation of metadata. Currently we have two classes that handle all the stuff, manifest parsing, xml parsing, deciding what kind of metadata to use. The problem is, that this getting more and more complex the more metadata we are able to parse. Second issue is, we have already detected the type in locatePom, and in the ModelParse we again try to find out what it is. So I have investigated a litte bit more about how the Mapping class works and came up with the new structure: - A baseclass that implements the MappingClass-Stuff and Modelparsing implementation (AbstractTychoMapping) - A baseclass that extends this for xml parsing (AbstractXMLTychoMapping) - the actual class to generate pom from target metadata (TychoTargetMapping) that implements a component only for this type of data Using this approach we can have: - One for manifest parsing - One for feature parsing - .. and so on .. Just let me know what you think and if I should do the refactoring in a new change or in this change
I'm fine with the suggested refactoring as it's cleaner code and non API. I'm just unsure we need so many different level of inheritance. At some point, parsing XML could be better in a utils class instead of super-class; composition is usually better than inheritance.
in fact most artifacts are XML so I decided to add a class for that because it can inherit also the text-file encoding as UTF-8 (otherwise each implementation has to take care that it uses UTF-8 and calls the parser on the input). Do you think I should start the refactoring right now in this ticket or open a new one?
(In reply to Christoph Laeubrich from comment #4) > in fact most artifacts are XML so I decided to add a class for that because > it can inherit also the text-file encoding as UTF-8 (otherwise each > implementation has to take care that it uses UTF-8 and calls the parser on > the input). > Do you think I should start the refactoring right now in this ticket or open > a new one? I don't have a preference, as long as the tests still work, so feel free to do this in the way that feels the most productive to you.
Gerrit change https://git.eclipse.org/r/148033 was merged to [master]. Commit: http://git.eclipse.org/c/tycho/org.eclipse.tycho.extras.git/commit/?id=ee19629117c1cc71ace05f403295eadef4c46c00
Thanks Christoph! Please add a note about it in https://wiki.eclipse.org/Tycho/Release_Notes/1.5#New_and_Noteworthy
Done
I'm trying to get this to work but my build fails to resolve the target platform specification artifact. I can see that it creates a .polyglot.....target file. Is there a way to debug the generated poms?
