Re: Adoption of dtkit-plugin
OK, it should be fixed now. It seems I messed up the original ChatOps requests On Wednesday, April 10, 2019 at 6:10:59 PM UTC+3, Nikolas Falco wrote: > > No write access yet > > Il giorno lunedì 8 aprile 2019 16:10:58 UTC+2, Oleg Nenashev ha scritto: >> >> Hi, >> >> It should be fixed now. Merging a PR is not enough nowadays, a manual >> ChatOps command is required >> >> Best regards, >> Oleg >> >> On Monday, April 8, 2019 at 11:22:27 AM UTC+3, Nikolas Falco wrote: >> >> The PR to manage permissions for Artifactory has been merged but I do not >>> have yet permissions to push to github repository jenkinsci/dtkit-plugin >>> >>> Anyone can help? >>> >>> Il giorno domenica 10 marzo 2019 10:49:24 UTC+1, Oleg Nenashev ha >>> scritto: The ownership transfer looks good to me. I am also fine with dkit as API plugin, the current approach is definitely a subject for improvement BR, Oleg On Saturday, March 9, 2019 at 3:29:25 PM UTC+1, Nikolas Falco wrote: > > Any comments? Any news? Any doubts? > -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/3c03e685-bede-4839-a02b-bb501c43301c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Third party dependencies, APIs, and Jenkins: Proposals
On Wed, Apr 10, 2019 at 6:44 PM Stephen Connolly wrote: > If the “classboxed” dependencies have scope=provided then they shouldn’t be > transitive and you could leave them unshaded. True. `war/pom.xml` would need to be massaged to bundle them. > The JenkinsRule would just need to setup the classloaders from the war and > all would be fine That “just” is JENKINS-41827. I believe writing such a harness is feasible—I have done so in the past (see link in JIRA)—but migrating existing functional tests to run in a new harness may not be straightforward. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3QdyFTegLWWYxuuro6GFhim9QFk1D3_GuAAK61p1Rwbg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Third party dependencies, APIs, and Jenkins: Proposals
On Thu, Apr 11, 2019 at 4:10 AM Ullrich Hafner wrote: > [shading does not] prevent developers to use the shaded classes, they are > still there, just with another package name True, but the Jenkins plugin class loader can refuse to serve such classes, so any such mistake would immediately fail at runtime. > We can add an architecture test or check style rule to prevent those imports > though. Yes, you can use the Enforcer plugin to check this sort of thing at build time. > Maybe we can use an enforcer rule […] that checks that no transitive > dependencies are used at all? Then developers need to provide explicit > dependencies. We may want to do this anyway. (The Maven plugin for NetBeans modules enforces such a rule.) > The only problem I see here is if classes of the dependency are part of the > plugin API. You can use explicit dependencies when an API includes other APIs in its signatures. It just means that clients need to declare dependencies on both, or they will not be able to compile. -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0bxVjsVgN5dt7cH7Ohdi%2Bg0VZ79VKTte%3DnssT6MocdUA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Calling Java from jenkinsfile to parse XML
I am trying to call some Java code in our plugin from the jenkinsfile to parse XML (I have been able to parse it in the jenkinsfile but would like to abstract the implementation from the pipeline). I am passing an XML file to a method that works fine when this file is passed from within the plugin code but fails when I pass the very same file from the pipeline: Exception: Content is not allowed in prolog. There is no content in the prolog: ... I have checked that the file is encoded in UTF-8 and several other suggestions but this error persists. Is this a known issue when trying to invoke Java from the pipeline? I can't figure out why the same code is behaving differently when invoked this way. -Matt -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/279d5d75-cad5-4abe-82d0-ab438b82c056%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
