It's probably obvious at this point that my bias is in favor of the latter approach. I found JENKINS-26192 which was closed as "Won't Do" but even given the discussion about obstacles and alternative approaches for the specific use case described there, I think it is worth considering this for the use case of sharing pipeline abstractions between projects and organizations. Let me know if there is anything I can clarify about my use case. I'm also willing to write up a new JIRA ticket describing my use case, but it seems like JENKINS-26192 could just be reopened.
The use case is well known and a top priority for me to solve. Whether Grape is a viable solution is another matter entirely. Pipeline Groovy has significant technical oddities which make it impossible to simply adopt non-Pipeline-specific dependencies you might find in the repository, and Grape itself might prove impossible to run.
The use case is well known and a top priority for me to solve. Whether Grape is a viable solution is another matter entirely.
Pipeline Groovy has significant technical oddities which make it impossible to simply adopt non-Pipeline-specific dependencies you might find in the repository, and Grape itself might prove impossible to run.
--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/yxMj7QMdLN0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr0VyKm8CcJRbPNGkrZZDL8d4-wkY%3D7i7X8Ng%3DpzbnfGvA%40mail.gmail.com.