Commit
- Loading branch information
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -54,8 +54,6 @@ | |
import hudson.tasks.Builder; | ||
import hudson.tasks.Fingerprinter.FingerprintAction; | ||
import hudson.tasks.Publisher; | ||
import hudson.tasks.test.AbstractTestResultAction; | ||
import hudson.tasks.test.AggregatedTestResultAction; | ||
import hudson.util.*; | ||
import jenkins.model.Jenkins; | ||
import org.kohsuke.stapler.HttpResponse; | ||
|
@@ -1041,15 +1039,23 @@ public final VariableResolver<String> getBuildVariableResolver() { | |
/** | ||
* @deprecated Use {@link #getAction(Class)} on {@link AbstractTestResultAction}. | ||
*/ | ||
public AbstractTestResultAction getTestResultAction() { | ||
return getAction(AbstractTestResultAction.class); | ||
public Action getTestResultAction() { | ||
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
This comment has been minimized.
Sorry, something went wrong.
slide
Member
|
||
try { | ||
return getAction(Jenkins.getInstance().getPluginManager().uberClassLoader.loadClass("hudson.tasks.test.AbstractTestResultAction").asSubclass(Action.class)); | ||
} catch (ClassNotFoundException x) { | ||
return null; | ||
} | ||
} | ||
|
||
/** | ||
* @deprecated Use {@link #getAction(Class)} on {@link AggregatedTestResultAction}. | ||
*/ | ||
public AggregatedTestResultAction getAggregatedTestResultAction() { | ||
return getAction(AggregatedTestResultAction.class); | ||
public Action getAggregatedTestResultAction() { | ||
try { | ||
return getAction(Jenkins.getInstance().getPluginManager().uberClassLoader.loadClass("hudson.tasks.test.AggregatedTestResultAction").asSubclass(Action.class)); | ||
} catch (ClassNotFoundException x) { | ||
return null; | ||
} | ||
} | ||
|
||
/** | ||
|
11 comments
on commit 16197ea
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Great!
Thanks a lot for your efforts
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why has the hudson.tasks.tests been moved as well as the hudson.tasks.junit?
Surely the tests is the base classes that concrete implementations need to extend -
Moving the to a separate plugin is like omving abstractBuild from the core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why has the
hudson.tasks.tests
been moved as well as thehudson.tasks.junit
?
Because they could be. Plugins defining other publishers, or accessing test results, need merely depend on the new plugin.
As to why these are not in two plugins, well really they should be, but I could not find a way to disentangle them compatibly, so I think we are stuck with them together.
like moving
AbstractBuild
from the core
That has in fact been proposed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need merely depend on the new plugin
"Want to use XUnit? Just install and enable JUnit!"
This really seems weird...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
beacuse they could be
lots of things can be - it does not mean they should be.
hudson.tasks.tests should be decoupled form hudson.tasks.junit - see https://issues.jenkins-ci.org/browse/JENKINS-19898
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"Want to use XUnit? Just install and enable JUnit!"
Actually, XUnit just converts the data to the JUnit format and then uses the functionality of JUnit publisher.
I'd say such dependency is valid even if it is non-obvious for users
IMHO, the decoupling of test reporting facilities (and their bugs) from the core is worth efforts in any case. 2 plugins would be better, but seems there's no way till Jenkins 2.0.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@daniel-beck well xunit-plugin
already depended on hudson.tasks.junit
. Probably it ought to be modified to use only hudson.tasks.test
, which ought to be all it needs to render test results, but that is not my business. At any rate since junit
becomes a bundled plugin, you would not explicitly install it. (Nor would you even if it were not bundled, since the plugin manager handles that automatically.)
@jtnord w.r.t. JENKINS-19898 yes that helped, but not enough to physically separate them.
lots of things can be
How I wish that were true. Some functionality is just so deeply tangled into the signatures of lower-level classes that it seems impossible to move without introducing serious compatibility problems.
does not mean they should be
We are striving to split everything into an independent plugin that possibly can be. There are many reasons for this, but the foremost is that it allows critical bug fixes to be put in users’ hands far more quickly and safely. For example, if junit-plugin
had been split before, people could pick up the fix for JENKINS-23945 (a critical bug for some CloudBees customers) by just updating that plugin, rather than running a custom version of core.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, XUnit just converts the data to the JUnit format and then uses the functionality of JUnit publisher.
Just a badly chosen example. Still doesn't make sense for plugins building on top of the JUnit independent types.
Nor would you even if it were not bundled, since the plugin manager handles that automatically
But I cannot disable it when I don't want to use it, because it provides infrastructure for other plugins.
There are many reasons for this, but the foremost is that it allows critical bug fixes to be put in users’ hands far more quickly and safely
Making LTS stability irrelevant as everything that could possibly break is in a plugin that has no LTS concept.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But I cannot disable it when I don't want to use it, because it provides infrastructure for other plugins.
We could create junit-api-plugin and junit-publisher-plugin (just for UI components)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you can use cucumber as the example instead of xUnit - it requires h.t.tests but not not h.t.junit.
I'm sure there are other instances out there.
Making LTS stability irrelevant as everything that could possibly break is in a plugin that has no LTS concept.
I also worry about the possible future this invents that is "plugin hell" akin to jar hell / dll hell....
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
everything that could possibly break is in a plugin
Well, we are a long way from that of course.
that has no LTS concept
Quite true. It would be very useful to create one.
Hi,
this causes the following bug in Email-Ext plugin (I am running the RC build to fix some other bugs). Now the results are no longer sent by email because of changed signature: