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 <[email protected]> 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 <[email protected]>: >> >> 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 <[email protected]>: >>> >>> 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 <[email protected]> >>> 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 <[email protected]> >>>> 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 [email protected]. >>>>> 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 >>>> [email protected]. >>>> 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 [email protected]. >>> 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 [email protected]. >> 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 [email protected]. > 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 [email protected]. 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.
