I think this was introduced when we switched JIRA clients.

Currently all Aphrodite methods are exposed by an Aphrodite instance, this is simple for the user, however this has resulted in Aphrodite.java becoming increasingly bloated.

It could be advantageous to split Aphrodite's interface into multiple sub-managers. For example we could have:

Aphrodite aphrodite = Aphrodite.instance()
IssueTrackerManager isManager = aphrodite.getIssueTrackerManager();
isManager.searchIssues(...);

RepositoryManager repoManager = aphrodite.getRepositoryManager();
repoManager.getPatchesAssociatedWith(...);

...
// Apply to Stream Services as well

Utilising Manager classes in this way, would also allow additional features to be added without further polluting Aphrodite.java. For example, each individual 'Manager' class could expose additional options, such as getIssueTrackerByHost() etc which would allow applications to utilise individual instances of IssueTrackers directly.

The problem appears to be with the underlying GitHub client

In order to speed up jira processing, concurrency is needed. At present if you try to use it
concurrently it raises an exception

Currently JSON service iterates over configs, swallows first JSON and ignores rest.
Also, NotFoundException is being overused in config parsing. Which is checked exception. On config failure, there is not much we can do, so there is no reason for it to be checked?

depends on #40

method in repository service isWrittingAllowed or something.
returning if we have permission to set labels.

Not sure if it's possible to check that.
this is the close thing I found:
https://developer.github.com/v3/repos/collaborators/

https://bitbucket.org/atlassian/jira-rest-java-client

Using egit core library:
https://github.com/eclipse/egit-github/tree/master/org.eclipse.egit.github.core

As reported in jboss-set/bug-clerk#32 , when issue.getReleases() is invoked on BZ issue, the returns is [Release{version='$AFFECTED_VERSION', milestone='ER1'}]" rather [Release{version='$TARGET_RELEASE', milestone='ER1'}]"

JIRA needs to execute these requests in parallel.

BZ should make better use of CompletableFuture and streams.

Needed. I'm trying to generate a report and the description is hard to handle.

due date 2016-04-15 (whenever possible)

this new service function will retrieve one or more streams related to the repository + codebase.
will return an empty list otherwise.
PS: a codebase could be shared among streams.

Not working. Cannot get the information about the flags in JIRA. does it exist ?

add two functions in StreamService.

findAllRepositories: will return a List of URL of all repositories configured in the stream (URL cannot be duplicated)

findAllRepositoriesInStream will return a List of URL of all repositories listed for a given Stream.

For example JBEAP issues have the field "customfield_12311242" which is for PM_ACK, however Wildfly issues do not have this field. This means that an update to a WFLY issue will fail with a JiraException if the PM_ACK flag is set; as the required custom field is not in the editmeta JSON object returned by Jira.

Not an issue for core issues, i.e. EAP7, however it may cause issues when trying to interact with components.

Currently operations such as IssueTrackerService::searchIssues are executed sequentially by Aphrodite.class, however as these operations are independent it is possible to execute them in parallel to reduce latency.

https://developer.github.com/v3/repos/statuses/

Need to re-work the JIRA transition mappings to cater for the JIRA state NEW. Currently only OPEN is supported (oversight) as a starting state.

It will return all the patches related to another patch based on the description of the parent patch.
It will find the streams representing PR links inside the description and return Patch instances.

see https://github.com/jboss-set/pull-shared/blob/master/src/main/java/org/jboss/pull/shared/connectors/RedhatPullRequest.java#L187

This used to work ...

May need to rewrite update function so that is a direct REST call

The following warnings are present during build:

[WARNING] stax-api-1.0.1.jar, stax-api-1.0-2.jar define 37 overlappping classes: 
[WARNING]   - javax.xml.stream.XMLEventReader
[WARNING]   - javax.xml.stream.StreamFilter
[WARNING]   - javax.xml.stream.FactoryFinder$ClassLoaderFinderConcrete
[WARNING]   - javax.xml.stream.util.StreamReaderDelegate
[WARNING]   - javax.xml.stream.events.StartDocument
[WARNING]   - javax.xml.stream.EventFilter
[WARNING]   - javax.xml.stream.XMLEventWriter
[WARNING]   - javax.xml.stream.XMLStreamConstants
[WARNING]   - javax.xml.stream.events.EntityDeclaration
[WARNING]   - javax.xml.stream.events.ProcessingInstruction
[WARNING]   - 27 more...
[WARNING] jira-rest-java-client-plugin-3.0.0.jar, jira-rest-java-client-api-3.0.0.jar define 135 overlappping classes: 
[WARNING]   - com.atlassian.jira.rest.client.api.SessionRestClient
[WARNING]   - com.atlassian.jira.rest.client.api.domain.IssuelinksType
[WARNING]   - com.atlassian.jira.rest.client.api.domain.input.ValueTransformerManager
[WARNING]   - com.atlassian.jira.rest.client.api.domain.AddressableNamedEntity
[WARNING]   - com.atlassian.jira.rest.client.api.domain.input.AuditRecordBuilder
[WARNING]   - com.atlassian.jira.rest.client.api.domain.FieldType
[WARNING]   - com.atlassian.jira.rest.client.api.domain.StandardOperation
[WARNING]   - com.atlassian.jira.rest.client.api.NamedEntity
[WARNING]   - com.atlassian.jira.rest.client.api.JiraRestClient
[WARNING]   - com.atlassian.jira.rest.client.api.domain.input.AttachmentInput
[WARNING]   - 125 more...
[WARNING] jira-rest-java-client-plugin-3.0.0.jar, jira-rest-java-client-core-3.0.0.jar define 150 overlappping classes: 
[WARNING]   - com.atlassian.jira.rest.client.internal.json.VersionRelatedIssueCountJsonParser
[WARNING]   - com.atlassian.jira.rest.client.internal.async.AsynchronousIssueRestClient$3
[WARNING]   - com.atlassian.jira.rest.client.internal.json.gen.LinkIssuesInputGenerator
[WARNING]   - com.atlassian.jira.rest.client.internal.json.TimeTrackingJsonParser
[WARNING]   - com.atlassian.jira.rest.client.internal.async.AbstractAsynchronousRestClient$2
[WARNING]   - com.atlassian.jira.rest.client.internal.json.OperationsJsonParser
[WARNING]   - com.atlassian.jira.rest.client.internal.json.AuditRecordsJsonParser
[WARNING]   - com.atlassian.jira.rest.client.internal.json.SearchResultJsonParser
[WARNING]   - com.atlassian.jira.rest.client.internal.json.gen.ComponentInputWithProjectKeyJsonGenerator
[WARNING]   - com.atlassian.jira.rest.client.internal.json.IssueLinkTypeJsonParser
[WARNING]   - 140 more...
[WARNING] httpmime-4.1.2.jar, jira-rest-java-client-plugin-3.0.0.jar define 15 overlappping classes: 
[WARNING]   - org.apache.http.entity.mime.FormBodyPart
[WARNING]   - org.apache.http.entity.mime.MultipartEntity
[WARNING]   - org.apache.http.entity.mime.content.FileBody
[WARNING]   - org.apache.http.entity.mime.HttpMultipart
[WARNING]   - org.apache.http.entity.mime.content.ContentBody
[WARNING]   - org.apache.http.entity.mime.content.AbstractContentBody
[WARNING]   - org.apache.http.entity.mime.content.ByteArrayBody
[WARNING]   - org.apache.http.entity.mime.content.ContentDescriptor
[WARNING]   - org.apache.http.entity.mime.HttpMultipartMode
[WARNING]   - org.apache.http.entity.mime.MIME
[WARNING]   - 5 more...
[WARNING] maven-shade-plugin has detected that some .class files
[WARNING] are present in two or more JARs. When this happens, only
[WARNING] one single version of the class is copied in the uberjar.
[WARNING] Usually this is not harmful and you can skeep these
[WARNING] warnings, otherwise try to manually exclude artifacts
[WARNING] based on mvn dependency:tree -Ddetail=true and the above
[WARNING] output
[WARNING] See http://docs.codehaus.org/display/MAVENUSER/Shade+Plugin

Jira field "Git Pull Request" is needed in order to get pull request from a jira issue.

Doesn't work for the original implementation or the refactor.

Affects Aphrodite-0.4.0

If a user does not specify "streamConfig" array in aphrodite.properties.json when using the properties file.

OR

The new user passes null to a collection when creating a new AphroditeConfig, then a NullPointerException is thrown.

Workaround

When using aphrodite.properties.json make sure you create an empty "streamConfigs" array.
When creating AphroditeConfig programmatically, make sure you pass an empty list instead of null.

Could be achieved by utilising subclasses of Issue

Using mocking?

http://mockito.org/

Bugzilla field "External Trackers" is needed as it allows to obtain upstream issue link.

Aphrodite should be able to take the URL of a saved filter and return the associated issues.

Currently stream data is loaded during the initialisation of a service. There should be a method to reload a stream service's data. This will be useful when an Aphrodite instance is running for a long time (e.g. on thunder)

when i want get issue from the bugzila,it has a error "NullPointerException" .it happened in "issue.setEstimation",because the "estimatedTime" and "hoursWorked" is null,as we konw,we can not assign null to the java basic type. i want add the judgement whether the field is null.

The problem is caused by each IssueTracker service (e.g. JIRA, BZ) responding differently to empty search requests. We need to define how an Aphrodite IssueTracker implementation should handle an empty search Request.

I propose that if SearchCriteria is empty, then we should not return any results as we can ensure this without any calls to an external service and it is applicable to all IssueTrackers.

Now it needs to be instantiated by hand. This needs to be done by Aphrodite

We need functionality to get, set, and remove labels

get -> it will get all the labels for a patch
set -> it will set all the labels for a patch
remove -> a label from a patch

Add the option for methods involving multiple issues/requests to fail-fast or proceed with errors logged.

Alternatively, change the default behaviour to fail-fast

A request is sent to GitHub for each label passed to this method, this can be reduced to a single service call.

Does not currently work, additional logic required.

In both JIRA and Bugzilla, there is a notion of "affected versions". For Bugzilla, the field is simply called "version" and can be set to several values. For instance, in BZ1282660, the affected version is 6.4.4.

In JIRA, the field is appropriatly named "Affected Versions", and, for instance, in JBEAP-783 the affected version is 7.0.0.DR8.

Currently, the API proposed by Aphrodite is exposing this information - which is semantically the same, through two different fields:

• the version - which is buzgilla is the equivalent of JIRA's affected version, and
• the version part of the Release object

So depending on the nature of the bug (JIRA or Bugzilla) you need to access the information differently. Which, IMHO, defeats the point of having Aphrodite providing an abstraction layer.

To solve that, this PR adds an AfffectedVersion (List) to the Issue itself. For a bug coming from Bugzilla, this list will contains the value associated with the 'version' field, and for JIRA the content of the affectedVersion field.

This way, there will be one, same approach to fetch this information, regardless of the nature of the bug.

The below error is output when calling aphrodite.searchIssues(..) and a JIRA issue tracker is present

59035: Occasionally ELDS install crashes with a python (pmw) traceback

XNIO-240: ERROR on shutdown with WF 8.2

current aphrodite.getPatchesAssociatedWith() is general search on whole GitHub, it can get false result for instance:

Issue issue = aphrodite.getIssue(new URL("https://bugzilla.redhat.com/show_bug.cgi?id=1305960"));
List<Patch>  patches = aphrodite.getPatchesAssociatedWith(issue);

centrifugal/centrifugo#84 is in the list because id "1305960" matched one of commit sha code.

It should allow to specify target repositories defined in streams.