Im updating a sonar plugin for sonar 3.6 but there is an issue:
This plugin includes workflow class but there is no class such as since api 3.6
Is there any alternative class or way to do this?
This is the code I work on:
package org.sonar.plugins.redmine.reviews;
import org.sonar.api.ServerExtension;
import org.sonar.api.workflow.Workflow;
import static org.sonar.api.workflow.condition.Conditions.*;
import org.sonar.api.workflow.screen.CommentScreen;
import org.sonar.plugins.redmine.RedmineConstants;
public class RedmineWorkflowBuilder implements ServerExtension {
private final Workflow workflow;
private final RedmineLinkFunction linkFunction;
public RedmineWorkflowBuilder(Workflow workflow, RedmineLinkFunction linkFunction) {
this.workflow = workflow;
this.linkFunction = linkFunction;
}
public void start() {
workflow.addCommand(RedmineConstants.LINK_TO_REDMINE_ID);
workflow.setScreen(RedmineConstants.LINK_TO_REDMINE_ID, new CommentScreen());
workflow.addFunction(RedmineConstants.LINK_TO_REDMINE_ID, linkFunction);
// conditions for this function
// - on the review ("IDLE" is the non-persisted status of an non-existing review = when a violation does have a review yet)
workflow.addCondition(RedmineConstants.LINK_TO_REDMINE_ID, not(hasReviewProperty(RedmineConstants.ISSUE_ID)));
workflow.addCondition(RedmineConstants.LINK_TO_REDMINE_ID, statuses("IDLE", "OPEN", "REOPENED"));
// - on the project
workflow.addCondition(RedmineConstants.LINK_TO_REDMINE_ID, hasProjectProperty(RedmineConstants.HOST));
workflow.addCondition(RedmineConstants.LINK_TO_REDMINE_ID, hasProjectProperty(RedmineConstants.API_ACCESS_KEY));
workflow.addCondition(RedmineConstants.LINK_TO_REDMINE_ID, hasProjectProperty(RedmineConstants.PROJECT_KEY));
}
}
You can have a look at the SonarQube JIRA plugin - which had the same issue and which have recently been updated to support SonarQube 3.6:
https://github.com/SonarCommunity/sonar-jira
Related
I am using Flyway 5.0.5 and I am unable to create a java (SpringJdbcMigration) with autowired properties... They end up null.
The closest thing I can find is this question: Spring beans are not injected in flyway java based migration
The answer mentions it being fixed in Flyway 5 but the links are dead.
What am I missing?
I struggled with this for a long time due to my JPA dependency. I am going to edit the title of my question slightly to reflect this...
#Autowired beans are instantiated from the ApplicationContext. We can create a different bean that is ApplicationContextAware and use that to "manually wire" our beans for use in migrations.
A quite clean approach can be found here. Unfortunately, this throws an uncaught exception (specifically, ApplicationContext is null) when using JPA. Luckily, we can solve this by using the #DependsOn annotation and force flyway to run after the ApplicationContext has been set.
First we'll need the SpringUtility from avehlies/spring-beans-flyway2 above.
package com.mypackage;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.context.ApplicationContext;
import org.springframework.context.ApplicationContextAware;
import org.springframework.stereotype.Component;
#Component
public class SpringUtility implements ApplicationContextAware {
#Autowired
private static ApplicationContext applicationContext;
public void setApplicationContext(final ApplicationContext applicationContext) {
this.applicationContext = applicationContext;
}
/*
Get a class bean from the application context
*/
public static <T> T getBean(final Class clazz) {
return (T) applicationContext.getBean(clazz);
}
/*
Return the application context if necessary for anything else
*/
public static ApplicationContext getContext() {
return applicationContext;
}
}
Then, configure a flywayInitializer with a #DependsOn for springUtility. I extended the FlywayAutoConfiguration here hoping to keep the autoconfiguration functionality. This mostly seems to have worked for me, except that turning off flyway in my gradle.build file no longer works, so I had to add the #Profile("!integration") to prevent it from running during my tests. Other than that the autoconfiguration seems to work for me but admittedly I've only run one migration. Hopefully someone will correct me if I am wrong.
package com.mypackage;
import org.flywaydb.core.Flyway;
import org.springframework.boot.autoconfigure.flyway.FlywayMigrationInitializer;
import org.springframework.boot.autoconfigure.flyway.FlywayAutoConfiguration.FlywayConfiguration;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.context.annotation.Profile;
import org.springframework.context.annotation.Primary;
import org.springframework.context.annotation.DependsOn;
import com.mypackage.SpringUtility;
#Configuration
#Profile("!integration")
class MyFlywayConfiguration extends FlywayConfiguration {
#Primary
#Bean(name = "flywayInitializer")
#DependsOn("springUtility")
public FlywayMigrationInitializer flywayInitializer(Flyway flyway){
return super.flywayInitializer(flyway);
//return new FlywayMigrationInitializer(flyway, null);
}
}
And just to complete the example, here is a migration:
package db.migration;
import org.flywaydb.core.api.migration.spring.BaseSpringJdbcMigration;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.stereotype.Component;
import com.mypackage.repository.AccountRepository;
import com.mypackage.domain.Account;
import com.mypackage.SpringUtility;
import java.util.List;
public class V2__account_name_ucase_firstname extends BaseSpringJdbcMigration {
private AccountRepository accountRepository = SpringUtility.getBean(AccountRepository.class);
public void migrate(JdbcTemplate jdbcTemplate) throws Exception {
List<Account> accounts = accountRepository.findAll();
for (Account account : accounts) {
String firstName = account.getFirstName();
account.setFirstName(firstName.substring(0, 1).toUpperCase() + firstName.substring(1));
account = accountRepository.save(account);
}
}
}
Thanks to avehlies on github, Andy Wilkinson on stack overflow and OldIMP on github for helping me along the way.
In case you are using more recent versions of Flyway, then extend BaseJavaMigration instead of BaseSpringJdbcMigration as the later is deprecated. Also, take a look at the below two comments by the user Wim Deblauwe.
The functionality hasn't made it into Flyway yet. It's being tracked by this issue. At the time of writing that issue is open and assigned to the 5.1.0 milestone.
Seems the updated answer provided by #mararn1618 is under documented on the official documentation, so I will provide a working setup here. Thanks to #mararn1618 for guiding in that direction.
Disclaimer, it's written in Kotlin :)
First you need a configuration for loading the migration classes, in Spring Boot (and perhaps Spring) you need either an implementation of FlywayConfigurationCustomizer or a setup of FlywayAutoConfiguration.FlywayConfiguration. Only the first is tested, but both should work
Configuration a, tested
import org.flywaydb.core.api.configuration.FluentConfiguration
import org.flywaydb.core.api.migration.JavaMigration
import org.springframework.beans.factory.annotation.Autowired
import org.springframework.boot.autoconfigure.flyway.FlywayConfigurationCustomizer
import org.springframework.context.ApplicationContext
import org.springframework.stereotype.Component
#Component
class MyFlywayConfiguration #Autowired constructor(
val applicationContext: ApplicationContext
) : FlywayConfigurationCustomizer {
override fun customize(configuration: FluentConfiguration?) {
val migrationBeans = applicationContext.getBeansOfType(JavaMigration::class.java)
val migrationBeansAsArray = migrationBeans.values.toTypedArray()
configuration?.javaMigrations(*migrationBeansAsArray)
}
}
Configuration option B, untested, but should also work
import org.flywaydb.core.api.migration.JavaMigration
import org.springframework.boot.autoconfigure.flyway.FlywayAutoConfiguration
import org.springframework.boot.autoconfigure.flyway.FlywayConfigurationCustomizer
import org.springframework.context.ApplicationContext
import org.springframework.context.annotation.Bean
import org.springframework.context.annotation.Configuration
#Configuration
class MyFlywayConfiguration : FlywayAutoConfiguration.FlywayConfiguration() {
#Bean
fun flywayConfigurationCustomizer(applicationContext: ApplicationContext): FlywayConfigurationCustomizer {
return FlywayConfigurationCustomizer { flyway ->
val p = applicationContext.getBeansOfType(JavaMigration::class.java)
val v = p.values.toTypedArray()
flyway.javaMigrations(*v)
}
}
}
And with that you can just write your migrations as almost any other Spring bean:
import org.flywaydb.core.api.migration.BaseJavaMigration
import org.flywaydb.core.api.migration.Context
import org.springframework.beans.factory.annotation.Autowired
import org.springframework.stereotype.Component
#Component
class V7_1__MyMigration #Autowired constructor(
) : BaseJavaMigration() {
override fun migrate(context: Context?) {
TODO("go crazy, mate, now you can import beans, but be aware of circular dependencies")
}
}
Side notes:
Be careful of circular dependencies, your migrations can most likely not depend on repositories (also makes sense, you are preparing them, after all)
Make sure your migrations are located where Spring scans for classes. So if you want to place them in the namespace db/migrations, you need to ensure that Spring scans that location
I haven't tested, but it's likely one should be cautious with mixing the path for these migrations and the locations where Flyway scans for migrations
Current flyway 6.5.5 version is released and back from 6.0.0 I believe support for spring beans is provided.
You can directly autowire spring beans into your Java based migrations (using #autowired), But the hunch is your Migration class also should be managed by Spring to resolve dependency.
There is a cool and simple way for it, by overriding default behavior of Flyway, check out https://reflectoring.io/database-migration-spring-boot-flyway/
the article clearly answers your question with code snippets.
If you are using deltaspike you can use BeanProvider to get a reference to your DAO.
Change your DAO code:
public static UserDao getInstance() {
return BeanProvider.getContextualReference(UserDao.class, false, new DaoLiteral());
}
Then in your migration method:
UserDao userdao = UserDao.getInstance();
And there you've got your reference.
(referenced from: Flyway Migration with java)
I just finished configuring hybris and tried to set up the eclipse project. As per guidelines in the wiki.hybris, I imported all the extensions into the eclipse project. When I try into build and clean, I get more than 3000 compiler errors. One of the errors is the class AbstractTrackingEvent cannot be resolved to a type. I looked for the particular class in the project folder. I could not find the folder events under de.hybris.eventtracking.model, which is the cause of the issue.
Am I missing anything while importing the project? There are many such type of issues in my eclipse project. Please let me know how to fix it. I have attached the screenshot for reference.
Note: I am using hybris-commerce-suite 5.7.0.8
As requested, I am adding the source code.
package de.hybris.eventtracking.services.populators;
import de.hybris.eventtracking.model.events.AbstractTrackingEvent;
import de.hybris.eventtracking.services.constants.TrackingEventJsonFields;
import de.hybris.platform.servicelayer.dto.converter.ConversionException;
import java.io.IOException;
import java.util.Map;
import org.apache.commons.lang.StringUtils;
import com.fasterxml.jackson.databind.ObjectMapper;
/**
* #author stevo.slavic
*
*/
public abstract class AbstractTrackingEventGenericPopulator implements
GenericPopulator<Map<String, Object>, AbstractTrackingEvent>
{
private final ObjectMapper mapper;
public AbstractTrackingEventGenericPopulator(final ObjectMapper mapper)
{
this.mapper = mapper;
}
public ObjectMapper getMapper()
{
return mapper;
}
protected Map<String, Object> getPageScopedCvar(final Map<String, Object> trackingEventData)
{
final String cvar = (String) trackingEventData.get(TrackingEventJsonFields.COMMON_CVAR_PAGE.getKey());
Map<String, Object> customVariablesPageScoped = null;
if (StringUtils.isNotBlank(cvar))
{
try
{
customVariablesPageScoped = getMapper().readValue(cvar, Map.class);
}
catch (final IOException e)
{
throw new ConversionException("Error extracting custom page scoped variables from: " + cvar, e);
}
}
return customVariablesPageScoped;
}
}
"As per guidelines in the wiki.hybris, I imported all the extensions into the eclipse project."
I don't think the guidelines tell you this. Basically, you want the projects loaded to be the same as those defined in your localextensions.xml and their dependencies. The reason you can't see those is they are not built.
Ensure you have run 'ant build' successfully, refresh the platform project, remove any extensions from your workspace that are not needed for your project, and clean and build in eclipse.
Make sure you have provided the project dependencies in each project by checking their individual extensioninfo.xml files as shown in below image.
Also sometimes dependent libraries are not imported properly check for those too.
As per the sonar logs, I see that sonar first runs the sensors, then the decorators and then stores the analysis results to the database. Is is possible to access analysis results in a sonar plugin?
Thanks
The Sonar web application is available at localhost:9000 (or wherever it's installed).
There is also a plugin for Eclipse to view issues:
http://docs.codehaus.org/display/SONAR/SonarQube+in+Eclipse
I finally found a solution to my problem here.
http://sonarqube.15.x6.nabble.com/sonar-dev-Where-can-I-find-new-issue-information-on-sonar-db-td5021022.html
// this annotation is important to be sure that relevant data on issues are up-to-date.
#DependsUpon(DecoratorBarriers.ISSUES_TRACKED)
public final class MyDecorator implements Decorator {
private final ResourcePerspectives perspectives;
public TechnicalDebtDecorator(ResourcePerspectives perspectives) {
this.perspectives = perspectives;
}
public void decorate(Resource resource, DecoratorContext context) {
Issuable issuable = perspectives.as(Issuable.class, resource);
if (issuable != null) {
List<Issue> issues = issuable.issues();
// Issue has method isNew()
}
}
}
i am exercising Mule
i read here
i want to try this sample and i create a project and create a java class in Mule Studio
after that i copied this code:
package org.mule.module.twilio;
import org.mule.api.annotations.Configurable;
import org.mule.api.annotations.Module;
import org.mule.api.annotations.Processor;
import org.mule.api.annotations.lifecycle.Start;
import org.mule.api.annotations.param.Optional;
import org.mule.api.callback.HttpCallback;
#Module(name = "twilio")
public class TwilioConnector {
/**
* The account sid to be used to connect to Twilio.
*/
#Configurable
private String accountSid;
/**
* The authentication token to be used to connect to Twilio
*/
#Configurable
private String authToken;
private TwilioClient twilioClient;
#Start
public void createTwilioClient() {
twilioClient = new TwilioClient(accountSid, authToken);
}
}
but i have a lot of error:
all
The import org.mule.api.annotations.Configurable cannot be resolved
The import org.mule.api.annotations.Module cannot be resolved
The import org.mule.api.annotations.Processor cannot be resolved
The import org.mule.api.annotations.lifecycle cannot be resolved
The import org.mule.api.annotations.param.Optional cannot be resolved
The import org.mule.api.callback cannot be resolved
all clsaa imports are not knew
near all annotation is: Configurable cannot be resolved to a type
Did you add the mule devkit annotation jar to your classpath?
Once you hava built your cloud connector you can add it to studio following the instruction available here
I'm trying to integration test a class that uses the Mail Plugin. When I run my test (grails test-app -integration EmailerIntegration) I get the error:
Could not locate mail body layouts/_email. Is it in a plugin? If so you must pass the plugin name in the [plugin] variable
Is there some initialization code I'm missing from the setUp method of my test case?
Here is the code for the test case:
package company
import grails.test.*
class EmailerIntegrationTests extends GrailsUnitTestCase {
protected void setUp() {
super.setUp()
}
protected void tearDown() {
super.tearDown()
}
void testSomething() {
User owner = new User()
owner.displayName = "Bob"
owner.email = "bob#yahoo.com"
Emailer emailer = new Emailer()
emailer.sendReadyEmail(owner)
}
}
Here is the code for the class being tested:
package company
import org.apache.log4j.Logger;
import org.codehaus.groovy.grails.commons.ApplicationHolder;
import org.springframework.context.ApplicationContext;
class Emailer {
private Logger log = Logger.getLogger(this.getClass());
ApplicationContext ctx = (ApplicationContext)ApplicationHolder.getApplication().getMainContext();
def mailService = ctx.getBean("mailService");
def sendReadyEmail = { owner ->
mailService.sendMail {
to owner.email
subject "Ready to go"
body( view:"layouts/_email", model:[ownerInstance:owner])
}
}
}
Thanks,
Everett
After looking at the plugin author's own tests for the mail plugin at https://github.com/gpc/grails-mail/blob/master/test/integration/org/grails/mail/MailServiceTests.groovy I realized that the paths in the values for the view parameter all begin with a '/'. I changed my method to
def sendReadyEmail = { owner ->
mailService.sendMail {
to owner.email
subject "Ready to go"
body( view:"/layouts/_email", model:[ownerInstance:owner])
}
And now it works in integration tests and normal program execution.
The body parameter in the sendMail(..) method is a map with the keys view, model, and plugin. A value for plugin is required, and points to some other, supporting, plugin, for instance, the name "email-confirmation" for that corresponding plugin.
Your error message is thrown in org.grails.mail.MailMessageBuilder.renderMailView(Object, Object, Object). You can find this class in your Grails project's plugin folder.
Unfortunately, I haven't found too much documentation on the Mail plugin. Thus, at the moment, I cannot easily tell about how to use the aforementioned supporting plugins. If you can't get forward, however, I might try to further investigate. Thanks