Adopting xUnit plugin

[Nikolas Falco]

I know that the xUnit plugin was already adopted on 15/11/2017 (https://groups.google.com/forum/#!searchin/jenkinsci-dev/xunit%7Csort:date/jenkinsci-dev/RROnSHD36-A/u4DcVHygAQAJ)

Jimilian, one month ago had ask news about movement on the plugin (for example pending PRs already approved by Oleg).
In my society we are using xUnit but recently we had a blocking issue. We already open a PR and a JIRA issue (JENKINS-50658) but from what I can see there are not commits on the plugin since 2016 and no response to any JIRA issue.

Maybe abayer is very busy in develop of other cloudbee plugins so if is not a problem I would be added as co-adopter (at least) of the xUnit plugin to manage and fix (at least) the actual approved PRs, move plugin under pipeline, update parent pom and other minor fixes.

Best Regards
Falco Nikolas

[Andrew Bayer]

That'd be fine by me.

A.

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/72a5095b-cce4-42f0-9192-8733e6da3ba6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Nikolas Falco]

Good news, a pull request has been submitted - https://github.com/jenkins-infra/repository-permissions-updater/pull/668

Il giorno mercoledì 11 aprile 2018 23:48:35 UTC+2, Andrew Bayer ha scritto:

That'd be fine by me.

A.

On Mon, Apr 9, 2018 at 6:35 AM, 'Nikolas Falco' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

I know that the xUnit plugin was already adopted on 15/11/2017 (https://groups.google.com/forum/#!searchin/jenkinsci-dev/xunit%7Csort:date/jenkinsci-dev/RROnSHD36-A/u4DcVHygAQAJ)

Jimilian, one month ago had ask news about movement on the plugin (for example pending PRs already approved by Oleg).
In my society we are using xUnit but recently we had a blocking issue. We already open a PR and a JIRA issue (JENKINS-50658) but from what I can see there are not commits on the plugin since 2016 and no response to any JIRA issue.

Maybe abayer is very busy in develop of other cloudbee plugins so if is not a problem I would be added as co-adopter (at least) of the xUnit plugin to manage and fix (at least) the actual approved PRs, move plugin under pipeline, update parent pom and other minor fixes.

Best Regards
Falco Nikolas

--
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-de...@googlegroups.com.

[Oleg Nenashev]

Thanks for it Nikolas!
Please feel free to ping me or code-reviewers if you need any help with reviews.

Best regards,
Oleg

[Oleg Nenashev]

Today we were reviewing the XUnit implementation together with Chenyu Cheng (context - Code Coverage API Plugin GSoC project). We discovered that the extension points are defined in libdtkit which is a standalone library within Jenkins organization. So this plugin uses same approaches as EnvInject Lib and XTrigger Lib :(

Ideally this library needs to be also adopted and reworked to API plugin so that it becomes maintainable. DTKit Plugin and TUSAR Notifier plugin are the only usages outside XUnit plugin, but the latter one is depublished. DTKit could be made such API plugin, but I do not exactly understand what it does in Jenkins now.

BR, Oleg

[Nikolas Falco]

Hi Oleg,
   I think the DTKit plugin library was done externally to make extension easier.

For example a plugin could extends org.jenkinsci.lib.dtkit.type.TestType other few interfaces to be added as tool type on xUnit plugin regardless of the version of xunit and its dependencies.

• https://github.com/jbehave/jbehave-core/tree/master/jbehave-jenkins-plugin
• https://github.com/jenkinsci/gallio-plugin/tree/master/src/main/java/hudson/plugins/gallio

So you suggest to move code from DTKit into xUnit plugin in some org.jenkins.xunit.lib package?

I could adopt DTKit too in case some changes needed to make xUnit works.

Out of this discussion: in the organisation pom is defined jacoco, it is possible enable sites like coveralls to see code coverage of a plugin to manage better PRs? I permitted for the Jenkisci organisation do this?

<profile>
    <id>enable-jacoco</id>
    <build>
        <pluginManagement>
            <plugins>
                <plugin>
                    <groupId>org.eluder.coveralls</groupId>
                    <artifactId>coveralls-maven-plugin</artifactId>
                    <version>4.3.0</version>
                    <configuration>
                        <repoToken>${env.COVERALLS_REPO_TOKEN}</repoToken>
                    </configuration>
                </plugin>
            </plugins>
        </pluginManagement>
        <plugins>
            <plugin>
                <groupId>org.jacoco</groupId>
                <artifactId>jacoco-maven-plugin</artifactId>
                <version>0.7.9</version>
                <executions>
                    <execution>
                        <goals>
                            <goal>prepare-agent</goal>
                        </goals>
                    </execution>
                    <execution>
                        <id>report</id>
                        <phase>test</phase>
                        <goals>
                            <goal>report</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>
        </plugins>
    </build>
</profile>

[Jesse Glick]

On Wed, May 2, 2018 at 9:29 AM, 'Nikolas Falco' via Jenkins Developers
<jenkin...@googlegroups.com> wrote:
> So you suggest to move code from DTKit into xUnit plugin

IIUC the recommendation was simply to take the existing library and
repackage it as a plugin (with no user-facing features). That allows
it to be independently updated. `jar`-packaging means that every
plugin depending on bundles its own copy of the library, and
library-defined types cannot be shared. Switching to an API plugin
also avoids the need for special tricks to accommodate JEP-200 in
Jenkins 2.102+.

https://jenkins.io/doc/developer/plugin-development/dependencies-and-class-loading/

[Nikolas Falco]

ok, there is already a plugin that include the libdtkit https://github.com/jenkinsci/dtkit-plugin.

Maybe I could move xUnit dependencies from libdtkit to dtkit-plugin

[Oleg Nenashev]

Yes, that's what I meant in "DTKit could be made such API plugin, but I do not exactly understand what it does in Jenkins now."

--
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/o8GtAiXFf7M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/feb3abc7-aebd-4dc2-bdd4-1a3fa9d35dd7%40googlegroups.com.

[Nikolas Falco]

I was confused because I always lookup at the wrong repository (dtkit-plugin).

Should be better change description of that plugin. Actually it appears like DTKit 2.1.3. In my opinion the plugin label should be something "DTKit API Plugin" and a little description.

Il giorno mercoledì 2 maggio 2018 18:13:14 UTC+2, Oleg Nenashev ha scritto:

Yes, that's what I meant in "DTKit could be made such API plugin, but I do not exactly understand what it does in Jenkins now."

On Wed, May 2, 2018 at 6:08 PM, 'Nikolas Falco' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

ok, there is already a plugin that include the libdtkit https://github.com/jenkinsci/dtkit-plugin.

Maybe I could move xUnit dependencies from libdtkit to dtkit-plugin

Il giorno mercoledì 2 maggio 2018 16:33:50 UTC+2, Jesse Glick ha scritto:

On Wed, May 2, 2018 at 9:29 AM, 'Nikolas Falco' via Jenkins Developers
<jenkin...@googlegroups.com> wrote:
> So you suggest to move code from DTKit into xUnit plugin

IIUC the recommendation was simply to take the existing library and
repackage it as a plugin (with no user-facing features). That allows
it to be independently updated. `jar`-packaging means that every
plugin depending on bundles its own copy of the library, and
library-defined types cannot be shared. Switching to an API plugin
also avoids the need for special tricks to accommodate JEP-200 in
Jenkins 2.102+.

https://jenkins.io/doc/developer/plugin-development/dependencies-and-class-loading/

--
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/o8GtAiXFf7M/unsubscribe.

To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.

[Nikolas Falco]

Please also make me the default recipient on JIRA for xUnit component otherwise I'm not advised on new ticket

[Oleg Nenashev]

Hi Nikolas,

Done. You are the default assignee now.

BR, Oleg

On Fri, May 4, 2018 at 7:31 PM, 'Nikolas Falco' via Jenkins Developers <jenkin...@googlegroups.com> wrote:

Please also make me the default recipient on JIRA for xUnit component otherwise I'm not advised on new ticket

--
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/o8GtAiXFf7M/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/ac17fc3f-a1bd-4641-8e65-ad608486433e%40googlegroups.com.