Thanks, I experimented a bit and found some interesting things. >From my view ... The 'State of the art' of packaging is 'struggling' with multiple technologies evolving independently then trying to be reconciled. I've been a developer for 30+ years heavily in unix and java (and a lot in between) but avoided the maven/packaging world until recently - skipped a generation and went from ant to gradle and now having to learn the last decade of a whole area I've been very happy to avoid. But no longer ! Automated distributed packaging and deployment is no new thing to the *nix world ( rpms, yum etc ... tracing back to usenet and self buildable script packages) -- Interesting the proliferation of languages into core OS applications, particularly Java, is fairly recent and the Java packaging and build ecosystem evolved independently and largely incompatibly with otherwise equivalent technology. Similar with repositories and document management. Now I'm seeing a attempt to merge .. the JPackge formats/utilits http://www.jpackage.org/ and now the Fedorah :Packaging specification https://fedoraproject.org/wiki/Packaging:Java are finding their (also incompatible) ways into OS distributions.
In this case (tomcat installed via yum on AWS Linux - a derivitave of CentOS and RHEL) Its some agglomerate of these I havent fully deduced. The RPM tomcat package has RPM dependencies to other RPM's some being pure Java RPM packages commons-io' .. which in turn have RPM dependancies - but not all the jar's in each package are actual dependants of tomcat. The extracted RPM's for these 'Java RPMS' put pom files in /usr/share/java/maven-poms These pom files are interesting in that they have a good deal of metatdata including inter-modules (Maven coordinates) dependencies --- *but no references to the RPMs or the jar files that came with them* Similarly the jar files dont have embedded poms and there is no semantic metadata in the RPM indicating which pom (if any) went with which jar. I tried copying all the jars and poms into a directory and importing to Artifactory in various ways to little success. There simply was no parsable metadata that linked the physical jar file to the POM or a way I could find to tell artifactory they were related. For a final surprising but fun experience I found Artifactory made quite good POM files automatically *about the POM Files* ... The POM files were self describing so the POM of POM had accurate information ... totally useless information but accurate. But the JAR files were not so successful as they didnt have embedded POMs and the filenames were not maven standard so the generated POMs were totally bogus ( commons-common:commons-common:commons-common etc) and using the bitray integration only 2 of the 30+ jars were recognized .. Its an interesting problem I hope someday will be solved (by someone other than me). For now I think I will have hard code the dependants at a file level and add exclusion rules to the gradle builds so it doesn't pull external versions of the same package. I *think* there is enough information in the combined data of the RPMs' the extracted file locations and the jar + pom files to reconstruct a useful artifactory layout but its not my day to figure it out :) -- View this message in context: http://forums.jfrog.org/POM-files-for-WAR-and-RPM-s-tp7580431p7580451.html Sent from the Artifactory - Users mailing list archive at Nabble.com. ------------------------------------------------------------------------------ _______________________________________________ Artifactory-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/artifactory-users
