IIRC Jigsaw has been reduced in scope to just within the JRE... but that may have changed again since
On 28 September 2015 at 13:46, Baptiste Mathus <m...@batmat.net> wrote: > Didn't have a in-depth look into it yet, but isn't that kind of isolation > what's Java9's Jigsaw supposed to bring to the game btw? > > 2015-09-28 14:41 GMT+02:00 nicolas de loof <nicolas.del...@gmail.com>: >> >> if you consider 10 years of jenkins development, I don't think the issue >> is for dependencies to become old "too quickly", but the fact we hardly can >> change them without potential risk to break some plugin. >> >> I'd like we find some technical way to isolate core classes implementation >> so they aren't accessible by plugins, then could exclude core dependencies >> from plugin classpath, and ensure those one explicitly declare dependencies >> they rely one. >> >> >> >> >> 2015-09-28 13:59 GMT+02:00 Michael Neale <michael.ne...@gmail.com>: >>> >>> Is the real problem that core dependencies get too old too quickly? (As >>> opposed to some tech that allows multiple versions of things to get loaded?) >>> >>> On Mon, 28 Sep 2015 at 8:36 PM, Nigel Magnay <nigel.mag...@gmail.com> >>> wrote: >>>> >>>> Would 2.0 be an appropriate juncture to revisit the plugin architecture? >>>> >>>> I've often gotten bitten by classloader issues in 2nd/3rd party >>>> dependencies (e.g: plugin wants newer version of guava than jenkins-core). >>>> Shading is a reasonably complicated thing to do for a plugin, and I wonder >>>> if something cleverer could be done - without disappearing down a (say) >>>> complicated solution like OSGi. >>>> >>>> On Fri, Sep 25, 2015 at 5:53 AM, Kohsuke Kawaguchi <k...@kohsuke.org> >>>> wrote: >>>>> >>>>> Jenkins is over 10 years old, and it came quite a long way. I still >>>>> remember the first few plugins that I wrote by myself, and now we have >>>>> close >>>>> to 1100 plugins. What's started as a hobby project that had run under my >>>>> desk today boasts more than 100K installations driving half a million-ish >>>>> build machines. >>>>> >>>>> We collectively came quite a long way. When I started Jenkins, having a >>>>> server building & testing on every commit was a cutting-edge practice. So >>>>> are automatically capturing changelogs and analysing test reports. But >>>>> now, >>>>> those are tablestakes, and the frontier of automation has moved further. >>>>> Now >>>>> we are talking about building pipelines & workflows, continuously >>>>> deploying >>>>> to servers, leveraging containers, and/or testing pull requests before >>>>> they >>>>> get merged. I'm going to call this much bigger entangled automation >>>>> "Continuous Delivery", to contrast this with more classical automated >>>>> build >>>>> & test executions (aka "Continuous Integration") that we set out to do. >>>>> >>>>> The other thing I'd like to point out is that the adoption of Jenkins >>>>> continues to grow at the incredible pace of 30% year over year. That is, a >>>>> lot of people are starting new with Jenkins, and they are looking for us >>>>> to >>>>> help them get Continuous Delivery done. Therefore, this is a good time to >>>>> step back and think about whether we are addressing those current user >>>>> demands. >>>>> >>>>> >>>>> For example, despite this advance during the last 10 years and 1000+ >>>>> plugins we've created, messaging in our website hasn't changed much since >>>>> the first version I wrote on java.net. It spends more space talking about >>>>> JNLP and zero mention of Git, pipeline, or Docker. >>>>> >>>>> The fresh installation of Jenkins is not much better. The CVS support >>>>> is available out of the box, but Git isn't. All the cool stuff that the >>>>> community has done and its collective best practices still need be learned >>>>> by each and every new user. It's bit like we are making everyone assemble >>>>> LEGO blocks. That's not doing enough justice to the 30K+ users that will >>>>> be >>>>> joining us in this year. >>>>> >>>>> So I propose we do Jenkins 2.0 to fix this. >>>>> >>>>> There are three important goals that I see in Jenkins 2.0. >>>>> >>>>> We need to claim our rightful place in Continuous Delivery. We have >>>>> lots of pieces that address these modern needs, but we are not >>>>> communicating >>>>> this very well. >>>>> >>>>> We need to revisit out of the box experience, so that Jenkins itself >>>>> speaks that story and makes it clear what we are aiming for. Our software >>>>> needs to speak for itself and tell people where we are going, so that the >>>>> community can better focus efforts on the important parts. >>>>> >>>>> And we need to do this while keeping what makes Jenkins great in the >>>>> first place, which are the ecosystem, the community, and the extensibility >>>>> that recognizes that one size does not fit all and let people do what they >>>>> want to do. >>>>> >>>>> >>>>> Incrementing the major version sends a clear message to people that we >>>>> are moving forward. That's why I think 2.0 is appropriate for this effort. >>>>> >>>>> >>>>> >>>>> Now, 2.0 can mean a lot of different things to a lot of people, so let >>>>> me outline what I think we should do and we shouldn't do. >>>>> >>>>> It's very important for me to make sure that my fellow Jenkins >>>>> developers understand the motivation and the goal of this proposal, >>>>> because >>>>> that drives much of what we should and shouldn't do. So instead of >>>>> deep-diving into technical parts, please take time to try to understand >>>>> why >>>>> I am proposing this. >>>>> >>>>> We need to contain the scope. 2.0 has to have enough in it to justify >>>>> the major version number increase, but it creates a period of pause and >>>>> uncertainty, so it cannot keep dragging on for too long. 2.0 cannot be >>>>> everything everyone ever wanted. >>>>> >>>>> We cannot do massively disruptive 2.0, because it ends up splitting the >>>>> community. If users perceive that the upgrade to 2.0 is risky, enough of >>>>> them will stay behind with 1.x, plugin authors would want to continue >>>>> supporting them, which makes 1.x more liveable, which makes the transition >>>>> slower. I do not want to end up in Python2/3 situation, and nobody wins. >>>>> >>>>> That means we cannot be really breaking plugins. We cannot do >>>>> s/hudson/jenkins/g in the package names because doing that will break all >>>>> the plugins. 2.0 does come with the expectation that it is more disruptive >>>>> than usual 1.630 to 1.631 upgrade, so we have some "disruption budget", >>>>> but >>>>> we have to use it really wisely. >>>>> >>>>> Simiarly, for me it is an absolute requirement that we keep people's >>>>> $JENKINS_HOME functioning. A lot of sweat, tear, and blood went into those >>>>> right set of plugins and elaborate job configurations. When users upgrade >>>>> to >>>>> 2.0, they need to continue to work, or else Jenkins 2.0 will be Jenkins in >>>>> just the name only. >>>>> >>>>> Therefore, we cannot make massive internal changes. In many ways, it >>>>> has to be evolutionary instead of revolutionary, when it comes to the >>>>> code. >>>>> This is not a "let's redo everything from scratch" kind of 2.0. In any >>>>> case, >>>>> I think it's a pitfall to focus too much on internals. We all have a long >>>>> list of things we want to fix and the technical debt that we want to pay >>>>> down. My cautionary tale here is that of Maven 2 to Maven 3 upgrade. The >>>>> developers of the project spent a lot of efforts redoing all the >>>>> plumbings. >>>>> Plexus gave way to Guice, and the dependency resolution engine got >>>>> completely rewritten. Then to keep plugins working, more efforts were >>>>> spent >>>>> on building the backward compatibility layer. After something like 18 >>>>> months, Maven 3 came out, which did more or less the same thing as far as >>>>> users are concerned. I'm sure I'm over-simplifying this, but you get the >>>>> point. >>>>> >>>>> >>>>> >>>>> So given all that constraints, I think 2.0 should have the following 3 >>>>> major pillars: >>>>> >>>>> Messaging changes, to make sure people coming into the Continuous >>>>> Delivery space will get that Jenkins does what they want. >>>>> Software that backs up our messages. Out of the box experience that >>>>> caters to Continuous Delivery needs. >>>>> Targeted internal plumbing changes that enable those goals >>>>> >>>>> I have some concrete ideas in each of these pillars, and I'll describe >>>>> them below. But I also need help from everyone to come up with, discuss, >>>>> and >>>>> decide what other things will advance those pillars. >>>>> >>>>> Messaging: >>>>> >>>>> Domain name. It's kind of a problem that we have "ci" baked into our >>>>> domain name jenkins-ci.org. We have acquired http://jenkins.cd/ How about >>>>> we >>>>> change the domain name? I think it sends another clear signal. >>>>> >>>>> We need more up-to-date feature list page (like >>>>> http://arquillian.org/features/) that talks about things that matter to >>>>> the >>>>> modern users. >>>>> >>>>> We need authoritative and curated getting started guide that expands on >>>>> the things listed in the features page and help people understand those >>>>> features, so that we have clearly marked trails. >>>>> >>>>> This is probably out of scope for the initial 2.0 launch, but in the >>>>> future we want to redo the plugin listing page as well. This is a >>>>> persistent >>>>> feedback that we hear from users. >>>>> >>>>> All the above things call for better infra that can handle this. Right >>>>> now we have our web assets are split into Drupal and Wiki, but the former >>>>> can be only touched by a few people and the latter is slow and klunky. I >>>>> think this is the time to switch to some static site generator, so that >>>>> everyone can contribute content through Git and pull requests, just like >>>>> how >>>>> we collaborate on plugins. >>>>> >>>>> Out of the Box Experience: >>>>> >>>>> This work is already in progress, but we really need some initial setup >>>>> wizard. We can use it to install plugins so that new instances come up >>>>> more >>>>> useful from get-go --- things like git, workflow, pipeline as code, >>>>> folders, >>>>> and so on. These plugins together tell the story of how we want users to >>>>> use >>>>> Jenkins. >>>>> >>>>> Another work that's already under way is the UX improvement, >>>>> specifically the config form re-layout. This is the kind of change that >>>>> helps people (literally) see that 2.0 is different. UX in general is >>>>> clearly >>>>> one of the places we should spend our precious disruption budget for. >>>>> >>>>> To reinforce the message that workflow is the future, CloudBees is >>>>> going to open-source our workflow stage view plugin that was previously a >>>>> part of CloudBees Jenkins Enterprise. >>>>> >>>>> >>>>> Internals: >>>>> >>>>> Let's define a policy to remove APIs after they are deprecated. We have >>>>> talked about this in FOSDEM, and this could be as easy as "N releases >>>>> after >>>>> deprecation". Feedbacks from users at the San Jose JAM was that things >>>>> like >>>>> this is OK, but we need to help people identify plugins that will be >>>>> impacted to give them earlier warnings. >>>>> >>>>> As a part of the UX rebump effort, Tom et al has been working on a >>>>> brand-new way of doing frontend in Jenkins plugins. His JUC talk has some >>>>> materials. Given that user experience is a major theme in 2.0, I think >>>>> this >>>>> internal plumbing change makes sense. >>>>> >>>>> Let's use the opportunity to update some of the libraries. I'm thinking >>>>> about things like Groovy, which according to the testing done during >>>>> Copenhagen Hackathon, should be compatible. This shouldn't include updates >>>>> that are known to be compatibility breaking, such as Acegi Security to >>>>> Spring Security (which involves package name changes.) >>>>> >>>>> Time to bump up the system requirement to Java 8 and Servlet 3.0. Let's >>>>> think about what this would enable to users. Again, we talked about this a >>>>> bit in FOSDEM. >>>>> >>>>> Finally, timeline-wise, my aspirational timeline is as follows, though >>>>> obviously this is largely dependent on feedback to the proposal: >>>>> >>>>> Announce the proposal publicly and have discussions to nail the details >>>>> (Sep-Oct) >>>>> Execution (Oct-Dec) >>>>> >>>>> Periodic alpha/beta releases to solicit feedbacks from users >>>>> PR activities >>>>> This phase concludes with the release candidate >>>>> >>>>> Plugin sweep to ensure key plugins are "2.0 ready". This is the >>>>> opportunity to find issues (Jan 2016) >>>>> Release (end Jan?) >>>>> Drop 1.x development as soon as possible to focus on 2.x. >>>>> >>>>> >>>>> There are a lot of things I haven't captured, but this email is aleady >>>>> getting too long. Looking forward to having more conversations about this >>>>> with everyone. >>>>> >>>>> -- >>>>> Kohsuke Kawaguchi >>>>> >>>>> -- >>>>> >>>>> 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/CAN4CQ4zMNF-BJnZ%3DwSxYJiXBkExPvNUnaNU4S5Ru6p-PgJmUbw%40mail.gmail.com. >>>>> >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> -- >>>> 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/vbXK7JJekFw/unsubscribe. >>>> To unsubscribe from this group and all its topics, 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/CAPYP83Rx3Nt2ecARsqez1D%2BQ_wQbTfneSHq5cm9UQhfQ9Am3kA%40mail.gmail.com. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> -- >>> 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/CAKVMTi6Ehmqd-Vc4JFJqi9idiutzNK_n9Xc5a6u2-zc5QhMdgw%40mail.gmail.com. >>> >>> For more options, visit https://groups.google.com/d/optout. >> >> >> -- >> 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/CANMVJzmeJNsHi9XCPUfDirmcc7fKREG5Ljw_y1UbOCMf6-Y%2Beg%40mail.gmail.com. >> >> For more options, visit https://groups.google.com/d/optout. > > > > > -- > Baptiste <Batmat> MATHUS - http://batmat.net > Sauvez un arbre, > Mangez un castor ! > > -- > 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/CANWgJS74qrB_DK81JthYdhXsOoc%3Dq4se7CcuJk6yB2%2Bf5STOyw%40mail.gmail.com. > > For more options, visit https://groups.google.com/d/optout. -- 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/CA%2BnPnMx0h3zr5-4%3DGBPn49Qb9rcAq%3D6-Y81XiQ%3DiWgL4_hcxyA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
