I want to make some phases optional say if compile fails or test fails and complete other phases like checkstyle, findbugs. Can i do that in maven, i have done it in ant not sure how to go about in maven
Maven has no means to dynamically add or remove goals or lifecycle phases. Yes, you could probably achieve functionality like that by writing a plugin and using the <extension> mechanism, but you would be breaking standard conventions.
But all plugins you talk about have parameters you can set to not fail the build:
compiler:compile has the failOnError parameter
surefire:test has the testFailureIgnore parameter
findbugs:check has the failOnError parameter
checkstyle:check has the failsOnError parameter
My suggestion would be to have a profile where you add configurations with all of these parameters, so you can toggle all of them with a single command.
You will probably need to write your own small plugin for Maven in order to handle this. You may want to see this thread:
http://www.mail-archive.com/users#maven.apache.org/msg95552.html
Maven encourage you to play with "goal-to-phase assignments", instead of explicit instructions about when to run what. Maven lifecycle is your roadmap, which you can't change. And on every milestone (phase) in this roadmap you can do certain operations (goals). In other words, you have to forget Ant and start using Maven :)
Related
I'm using Intellij Idea 2022.2.3, while I wanna use jetty runner, the lastest jetty version is 1.4.20, and I got an error as below:
com.intellij.diagnostic.PluginException: The default implementation of method 'getId' is deprecated, you need to override it in 'class com.github.guikeller.jettyrunner.conf.JettyRunnerConfigurationFactory'. The default implementation delegates to 'getName' which may be localized, but return value of this method must not depend on current localization. [Plugin: JettyRunner-GK]
at com.intellij.diagnostic.PluginProblemReporterImpl.createPluginExceptionByClass(PluginProblemReporterImpl.java:23)
at com.intellij.diagnostic.PluginException.createByClass(PluginException.java:83)
at com.intellij.diagnostic.PluginException.reportDeprecatedDefault(PluginException.java:110)
at com.intellij.execution.configurations.ConfigurationFactory.getId(ConfigurationFactory.java:75)
at com.intellij.execution.impl.RunnerAndConfigurationSettingsImpl.writeExternal(RunnerAndConfigurationSettingsImpl.kt:265)
at com.intellij.execution.impl.RunnerAndConfigurationSettingsImpl.writeScheme(RunnerAndConfigurationSettingsImpl.kt:321)
at com.intellij.configurationStore.LazySchemeProcessor.writeScheme(scheme-impl.kt:65)
at com.intellij.execution.impl.RunConfigurationSchemeManager.writeScheme(RunConfigurationSchemeManager.kt:121)
at com.intellij.execution.impl.RunConfigurationSchemeManager.writeScheme(RunConfigurationSchemeManager.kt:21)
at com.intellij.configurationStore.schemeManager.SchemeManagerImpl.saveScheme(SchemeManagerImpl.kt:393)
at com.intellij.configurationStore.schemeManager.SchemeManagerImpl.save(SchemeManagerImpl.kt:333)
at com.intellij.configurationStore.Scheme_implKt.save(scheme-impl.kt:164)
at com.intellij.execution.impl.RunManagerImpl.getState(RunManagerImpl.kt:643)
at com.intellij.execution.impl.RunManagerImpl.getState(RunManagerImpl.kt:78)
at com.intellij.configurationStore.ComponentStoreImpl.commitComponent(ComponentStoreImpl.kt:334)
at com.intellij.configurationStore.ComponentStoreImpl.commitComponents$intellij_platform_configurationStore_impl(ComponentStoreImpl.kt:240)
at com.intellij.configurationStore.ComponentStoreWithExtraComponents.commitComponents$intellij_platform_configurationStore_impl(ComponentStoreWithExtraComponents.kt:94)
at com.intellij.configurationStore.ComponentStoreImpl$commitComponentsOnEdt$$inlined$withEdtContext$intellij_platform_configurationStore_impl$1.invokeSuspend(ComponentStoreImpl.kt:723)
at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33)
at kotlinx.coroutines.DispatchedTask.run(DispatchedTask.kt:106)
at com.intellij.openapi.application.constraints.BaseConstrainedExecution$Companion$scheduleWithinConstraints$1.invoke(BaseConstrainedExecution.kt:68)
at com.intellij.openapi.application.constraints.BaseConstrainedExecution$Companion.scheduleWithinConstraints(BaseConstrainedExecution.kt:71)
at com.intellij.openapi.application.constraints.BaseConstrainedExecution.scheduleWithinConstraints(BaseConstrainedExecution.kt:38)
at com.intellij.openapi.application.impl.BaseExpirableExecutorMixinImpl.access$scheduleWithinConstraints$s1153900543(BaseExpirableExecutorMixinImpl.kt:12)
at com.intellij.openapi.application.impl.BaseExpirableExecutorMixinImpl$scheduleWithinConstraints$$inlined$Runnable$1.run(Runnable.kt:19)
at com.intellij.openapi.application.TransactionGuardImpl.runWithWritingAllowed(TransactionGuardImpl.java:209)
at com.intellij.openapi.application.TransactionGuardImpl.access$100(TransactionGuardImpl.java:21)
at com.intellij.openapi.application.TransactionGuardImpl$1.run(TransactionGuardImpl.java:191)
at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:881)
at com.intellij.openapi.application.impl.ApplicationImpl$3.run(ApplicationImpl.java:513)
at com.intellij.openapi.application.impl.FlushQueue.doRun(FlushQueue.java:75)
at com.intellij.openapi.application.impl.FlushQueue.runNextEvent(FlushQueue.java:118)
at com.intellij.openapi.application.impl.FlushQueue.flushNow(FlushQueue.java:42)
at java.desktop/java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:318)
at java.desktop/java.awt.EventQueue.dispatchEventImpl(EventQueue.java:779)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:730)
at java.desktop/java.awt.EventQueue$4.run(EventQueue.java:724)
at java.base/java.security.AccessController.doPrivileged(AccessController.java:399)
at java.base/java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:86)
at java.desktop/java.awt.EventQueue.dispatchEvent(EventQueue.java:749)
at com.intellij.ide.IdeEventQueue.defaultDispatchEvent(IdeEventQueue.java:918)
at com.intellij.ide.IdeEventQueue._dispatchEvent(IdeEventQueue.java:766)
at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$6(IdeEventQueue.java:450)
at com.intellij.openapi.progress.impl.CoreProgressManager.computePrioritized(CoreProgressManager.java:791)
at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$7(IdeEventQueue.java:449)
at com.intellij.openapi.application.TransactionGuardImpl.performActivity(TransactionGuardImpl.java:105)
at com.intellij.ide.IdeEventQueue.performActivity(IdeEventQueue.java:624)
at com.intellij.ide.IdeEventQueue.lambda$dispatchEvent$8(IdeEventQueue.java:447)
at com.intellij.openapi.application.impl.ApplicationImpl.runIntendedWriteActionOnCurrentThread(ApplicationImpl.java:881)
at com.intellij.ide.IdeEventQueue.dispatchEvent(IdeEventQueue.java:493)
at java.desktop/java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:207)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:128)
at java.desktop/java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:117)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:113)
at java.desktop/java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:105)
at java.desktop/java.awt.EventDispatchThread.run(EventDispatchThread.java:92)
It looks like that plugin is out of date with your version of Intellij. It seems like the plugin has not been updated recently and is looking for a new maintainer.
You could
fork it and make the changes suggested in the error message (it doesn't seem like it would be too complicated)
Downgrade your intellij - probably a bad idea, but if you are really in a pinch might be the fastest way to get past this
Find an alternate solution; perhaps use the jetty maven plugin which appears to be still supported and has easy commands to run jetty (which can be put into an intellij run configuration)
I would recommend the last way. If you are already using maven, it will be pretty easy. If you are not using maven then it is a good opportunity to learn how to use it as it is very helpful for managing java projects
Although I am looking for a new maintainer I still am maintaining the plugin.
Please raise an issue on GitHub so this can be fixed, cheers!
Project link: https://github.com/guikeller/jetty-runner
PS: raised an issue on your behalf:
https://github.com/guikeller/jetty-runner/issues/81
The problem is that we are an IntelliJ shop and this issue has been a thorn in our sides. It basically means that everything has to be in ./test/ in order to work. ./it/ isn't acceptable because IntelliJ picks it up as the wrong kind of source every time you try to do anything. So.... how do I separate integration tests from unit tests so that they can be run separately in Gradle if they are in the same source set? Anyone have an example?
We use the *Test*.java and *ITCase*.java naming conventions, if that helps. Anothing thing we were thinking of is some kind of use of JUnit's #Category annotation.
P.S. Please vote for this issue. It will be a thorn in the side of any IntelliJ shop considering Gradle that has integration tests in a different directory from unit tests.
I can't speak to IntelliJ configuration, but in build.gradle, if you have:
test {
if (! project.hasProperty("ITCASE")) {
exclude "**/*ITCase*"
}
}
then the following command-line would include the integration tests:
gradle test -PITCASE=true
then and the standard would exclude them:
gradle test
In Bamboo, I want so take a build-release and deploy it on a target host. The target host should be variable.
As far as I know, it is not possible to run deployment-projects with customized deployment-variables (as it is possible to override plan-variables on custom-builds). My question is: is that true and if yes, what is the best way to achieve what I want?
Here are some thoughts I had during research regarding this issue:
I could use a plan-variable "host" in my build job and always customize it as needed. Then I write this variable into a file that will be declared as a build-artifact. In my deployment-tasks I use the "Inject Bamboo variables configuration" task to get the variable. This solution has the disadvantage, that I always have to run a build, even if the artifacts do not change.
Global variables are not feasible because they are not build-dependent. Therefore I can not use them for my task. The reason is that it could happen that they get overwritten by another build.
Are there any better solutions/thoughts on this task?
target host should be variable
No, each host is a separate environment. Otherwise the notion of "promoting an environment" breaks apart. This may be a lot of work to implement and therefore I strongly advise using bamboo specs (in Java).
it is not possible to run deployment-projects with customized deployment-variables
I confirm: it's not possible. And again, it would break the notion of environment promotion. Rule of thumb: your environment setup should be immutable: no variable variance. The only difference b/n runs is the artifacts that are to be deployed.
You can set variables in 'Other environment settings' in deployment project while configuring Environment. This way you will not have to run build when artifacts don't change. Just change variable value before deploying the artifact.
Note: this thread is about writing a custom Mojo, not using a plugin.
I maintain a testing plugin for Maven. Unfortunately, for almost a year now, I've let this particular unknown linger and I'd really like to know how to deal with it so that its users can have a simpler configuration.
Let's say we have two goals in our plugin:
prepare (phase: generate-sources)
do (phase: compile)
I want to configure the do Mojo to require prepare to have been executed in the earlier phase of the build. However, nothing in the descriptor documentation suggests I can.
The user probably doesn't care or understand the point of the prepare goal, so I don't want to force them to specify it in their POM. Of course, I could execute the Mojo directly from do, but then the prepare goal will have run at a later phase than is intended.
(I looked into custom lifecycles, but that makes it appear that everyone who already has the prepare goal in their POMs will have it executed twice upon running do.)
You could have something like the below (taken from the CompilerMojo):
/**
* #author Jason van Zyl
* #version $Id: CompilerMojo.java 941498 2010-05-05 21:24:11Z krosenvold $
* #since 2.0
* #goal compile
* #phase compile
* #threadSafe
* #requiresDependencyResolution compile
*/
By setting this over your class, it will execute during the compile phase (in this example). The compile phase requires all the previous phases to have executed first (validate, generate-sources, process-sources, generate-resources, process-resources...).
Basically, pick a phase after the one you need (or even the same one) and it should work.
I have created an extra builder for Java projects.
I'm trying to test it automatically via JUnit test that changes and refreshes a project file and expects automatic builder to kick in. Unfortunately this doesn't happen.
I can access and modify Workspace from that test but I don't know how to deal with builders (or GUI elements). I also tried to check "Run in UI thread" in junit test's debug configuration but no success.
What's the proper way to do this kind of testing? (I'd like to avoid learning TPTP, if possible -- looks too heavy).
How to initiate "Project -> Clean" command from my tests? Or how to execute any UI command? I suppose there are some threading issues to take care of.
I think you are looking for the command:
ResourcesPlugin.getWorkspace().build(IncrementalProjectBuilder.FULL_BUILD, null);
and
ResourcesPlugin.getWorkspace().build(IncrementalProjectBuilder.CLEAN_BUILD, null);
The first will initiate a clean, and then a build on the entire workspace. The second will initiate only a clean.
Alternatively, if you have access to an IProject object, you can call build on that.