Hi David,
Thank you for contacting us.
First, regarding having the Pom/Ivy files as part of the Yum repo, it does
look like in most cases there is no need for that (it is not part of the rpm
convention). As part of our Gradle-Artifactory documentation, appears two
default values for publishing Pom and Ivy files. These values default to ‘True’
but can be changed. Please search for “publishPom” and “publishIvy” in this
section of the wiki. Please let us know if we misunderstood this part of your
inquiry. Also, we completely understand your desire to have the BuildInfo; its
merits are self evident from our point of view.
About this question: “Q) Is there any value at all in having the IVY/POM
files in a pure YUM Repostitory (which otherwise contains ONLY .rpm’s no
jars,wars etc) ?”
Well, in cases that the RPM was built using the appropriate Maven plugin then
there might be a value keeping the pom which produced the RPM.
About This question: “Q) Is there any real harm having the ‘cruft’ of
unneeded and unwanted files (ivy/pom) in a pure YUM repository ? It seems
‘really wrong’ to me to have them, and particularly annoying that its so
difficult or unobvious how to avoid them – but perhaps the pragmatic solution
is to ignore them and just let the plugin do its thing ? - OR if there is harm
– I need to figure out how to configure the plugin differently, or bypass it
with lower level scripts..”
[A] As mentioned at the beginning, there are two “switches” for the Pom/Ivy
production as part of the plugin.
Now, regarding the repository layout question, from Artifactory’s perspective,
layouts are used for features such as “Delete Versions” ,“Snapshot Cleanup”,
some searches, and other options. As you have noticed a. the layouts are not
enforced with respect to deployment and b. in most cases even a customised
layout will not fit a “regular” Yum repository. Of course you are also correct
about Yum using only its own metadata and not the Maven/Ivy ones.
That being said, If you feel that our documentation is lacking, please sign up
for our Jira system (publicly open) and open improvement issues for our
documentation (or any other aspect which you may find lacking from your point
of view). Please try to be as detailed as possible with respect to the issue
and how you think it can be improved. Once you open these Jira issues, please
provide us with the relevant links so we can associate them with this thread.
We hope that we have addressed your enquiry as intended. Please feel free to
contact us for any further clarification or assistance.
Respectfully Sent, Eran JFrog Support
On Mon, 22 Jun at 4:08 AM
, artifactory-users <[email protected]> wrote:
I am using Gradle and the ospackage plugin to build RPM’s I want to
deploy these to Artifactory Pro (online version) I have gotten the Artifactory
Gradle Publishing plugin to work – but no matter what I do it insists on
publishing the .ivy or .pom files. As far as I can tell these have no use at
all on a pure YUM Artifactory repository – and clutter up the the directory
structure. I can do publishing directly via REST (I have a working script that
does this) but I like the build info features and there is value in using the
gradle plugin as part of the build process. Any suggestions on this ? Q) Any
way to disable the publishing of the ivy.xml or .pom files ? ( I have tried a
LOT of things but Im sure there are a million ways) Q) Is there any value at
all in having the IVY/POM files in a pure YUM Repostitory (which otherwise
contains ONLY .rpm’s no jars,wars etc) ? Q) Is there any real harm having
the ‘cruft’ of unneeded and unwanted files (ivy/pom) in a pure YUM repository ?
It seems ‘really wrong’ to me to have them, and particularly annoying that its
so difficult or unobvious how to avoid them – but perhaps the pragmatic
solution is to ignore them and just let the plugin do its thing ? - OR if there
is harm – I need to figure out how to configure the plugin differently, or
bypass it with lower level scripts.. Related Question) I have found no
effect (good or bad) of the “Layout” in a YUM repository – Is the Layout used
at all for YUM repositories ? This is completely neglected in the docs, and
in the Admin GUI there is no indication if layouts have any use, harm, or
otherwise different for YUM repositories – you can set the same options,
nothing is disabled or documented differently – yet they seem to have no
affect. I think this is that YUM queries do not use the same metadata as
Maven or IVY queries – instead only use the generated YUM metadata. So
layouts are never actually used. Anyone with any insight into this
appreciated. If I can figure out the current behaviour vs desired behavior then
I can write it up to JFrog as a enhancement/bug request – but as of now I cant
tell whats going on. — View this message in context:
http://forums.jfrog.org/Suggestion-for-publishing-pure-RPM-s-to-Artifactory-Pro-YUM-repository-us…
Sent from the Artifactory – Users mailing list archive at Nabble.com.
——————————————————————————————————————— Monitor 25 network devices or servers
for free with OpManager! OpManager is web-based network management software
that monitors network devices and physical & virtual servers, alerts via email
& sms for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________ Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical & virtual servers, alerts via email & sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users
