[JBoss JIRA] (ARQ-1601) adb is not found on Windows
by Karel Piwko (JIRA)
Karel Piwko created ARQ-1601:
--------------------------------
Summary: adb is not found on Windows
Key: ARQ-1601
URL: https://issues.jboss.org/browse/ARQ-1601
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Extension - Droidium
Affects Versions: droidium_1.0.0.Alpha3
Reporter: Karel Piwko
Priority: Critical
Current logic for searching tool location does not work correctly on windows.
For instance, setup is not able to find adb if arquillian.xml file contains androidHome with backslashes.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ARQ-1600) ProcessExecutor might get stuck on Windows
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/ARQ-1600?page=com.atlassian.jira.plugin.s... ]
Karel Piwko updated ARQ-1600:
-----------------------------
Component/s: Extension - Droidium
> ProcessExecutor might get stuck on Windows
> -------------------------------------------
>
> Key: ARQ-1600
> URL: https://issues.jboss.org/browse/ARQ-1600
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: droidium_1.0.0.Alpha3
> Reporter: Karel Piwko
> Priority: Blocker
>
> Current execution of external process on Windows might lead to following issues, causing process deadlock:
> 1/ Process stdin is not closed if no longer needed
> 2/ Process stdout and stderr never reach EOF
> This behavior is observed when a .bat file file is executed on Windows. This behavior is caused by missing file descriptors to underlying process spawned by bat file.
> Implementation note: There are two ways how to resolve the issue.
> * read output stream and consider them finished if specific message is encountered
> * unwrap bat execution and execute directly underlying command
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ARQ-1600) ProcessExecutor might get stuck on Windows
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/ARQ-1600?page=com.atlassian.jira.plugin.s... ]
Karel Piwko updated ARQ-1600:
-----------------------------
Affects Version/s: droidium_1.0.0.Alpha3
> ProcessExecutor might get stuck on Windows
> -------------------------------------------
>
> Key: ARQ-1600
> URL: https://issues.jboss.org/browse/ARQ-1600
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: droidium_1.0.0.Alpha3
> Reporter: Karel Piwko
> Priority: Blocker
>
> Current execution of external process on Windows might lead to following issues, causing process deadlock:
> 1/ Process stdin is not closed if no longer needed
> 2/ Process stdout and stderr never reach EOF
> This behavior is observed when a .bat file file is executed on Windows. This behavior is caused by missing file descriptors to underlying process spawned by bat file.
> Implementation note: There are two ways how to resolve the issue.
> * read output stream and consider them finished if specific message is encountered
> * unwrap bat execution and execute directly underlying command
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ARQ-1600) ProcessExecutor might get stuck on Windows
by Karel Piwko (JIRA)
Karel Piwko created ARQ-1600:
--------------------------------
Summary: ProcessExecutor might get stuck on Windows
Key: ARQ-1600
URL: https://issues.jboss.org/browse/ARQ-1600
Project: Arquillian
Issue Type: Bug
Security Level: Public (Everyone can see)
Reporter: Karel Piwko
Priority: Blocker
Current execution of external process on Windows might lead to following issues, causing process deadlock:
1/ Process stdin is not closed if no longer needed
2/ Process stdout and stderr never reach EOF
This behavior is observed when a .bat file file is executed on Windows. This behavior is caused by missing file descriptors to underlying process spawned by bat file.
Implementation note: There are two ways how to resolve the issue.
* read output stream and consider them finished if specific message is encountered
* unwrap bat execution and execute directly underlying command
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ARQ-1599) Droidium should be able to manage permissions of app for testing purposes
by Karel Piwko (JIRA)
[ https://issues.jboss.org/browse/ARQ-1599?page=com.atlassian.jira.plugin.s... ]
Karel Piwko commented on ARQ-1599:
----------------------------------
I think this is a work for ApkBuilder project, as it was proposed in the past.
> Droidium should be able to manage permissions of app for testing purposes
> -------------------------------------------------------------------------
>
> Key: ARQ-1599
> URL: https://issues.jboss.org/browse/ARQ-1599
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: 1.0.0.Beta1
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
>
> Application under test has to have permissions specified in its AndroidManifest.xml which enable it to be used with Selendroid. If developer does not add them there, he is not able to test it.
> From usability point of view, it is needed that even APK has not some permissions, Droidium will modify application in runtime and dynamically adds them there so developer does not have to touch APK at all.
> This also solves the problem with testing APKs when we do not have sources to Android application so we can not add them there manually - exluding all such apps from testing process.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ARQ-1599) Droidium should be able to manage permissions of app for testing purposes
by Stefan Miklosovic (JIRA)
[ https://issues.jboss.org/browse/ARQ-1599?page=com.atlassian.jira.plugin.s... ]
Stefan Miklosovic reassigned ARQ-1599:
--------------------------------------
Assignee: Stefan Miklosovic
> Droidium should be able to manage permissions of app for testing purposes
> -------------------------------------------------------------------------
>
> Key: ARQ-1599
> URL: https://issues.jboss.org/browse/ARQ-1599
> Project: Arquillian
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: Extension - Droidium
> Affects Versions: 1.0.0.Beta1
> Reporter: Stefan Miklosovic
> Assignee: Stefan Miklosovic
>
> Application under test has to have permissions specified in its AndroidManifest.xml which enable it to be used with Selendroid. If developer does not add them there, he is not able to test it.
> From usability point of view, it is needed that even APK has not some permissions, Droidium will modify application in runtime and dynamically adds them there so developer does not have to touch APK at all.
> This also solves the problem with testing APKs when we do not have sources to Android application so we can not add them there manually - exluding all such apps from testing process.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ARQ-1599) Droidium should be able to manage permissions of app for testing purposes
by Stefan Miklosovic (JIRA)
Stefan Miklosovic created ARQ-1599:
--------------------------------------
Summary: Droidium should be able to manage permissions of app for testing purposes
Key: ARQ-1599
URL: https://issues.jboss.org/browse/ARQ-1599
Project: Arquillian
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: Extension - Droidium
Affects Versions: 1.0.0.Beta1
Reporter: Stefan Miklosovic
Application under test has to have permissions specified in its AndroidManifest.xml which enable it to be used with Selendroid. If developer does not add them there, he is not able to test it.
>From usability point of view, it is needed that even APK has not some permissions, Droidium will modify application in runtime and dynamically adds them there so developer does not have to touch APK at all.
This also solves the problem with testing APKs when we do not have sources to Android application so we can not add them there manually - exluding all such apps from testing process.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ARQ-1598) Warp on WildFly: CDI fails to inject into inspection that is inner static class
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1598?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on ARQ-1598:
---------------------------------
Note: the same issue happens when we use twice the same anonymous class:
{code}
public class MyTest {
@Test
public void test1() {
runWarp();
}
@Test
public void test2() {
runWarp(); // fails
}
private void runWarp() {
Warp....inspect(new Inspection() {
private static final long serialVersionUID = 1L;
});
}
}
{code}
The suggested solution should work here (caching classes), but it came to my mind that we could also take completely another approach:
do deployment-build-time extraction of member classes (that extends Inspection?) from declaring class (which we are avoiding to load by this whole "transformation process").
In such a way, we would not need to load classes during requests, they would be loaded just once per deployment, thus we wouldn't need caching.
> Warp on WildFly: CDI fails to inject into inspection that is inner static class
> -------------------------------------------------------------------------------
>
> Key: ARQ-1598
> URL: https://issues.jboss.org/browse/ARQ-1598
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha5
> Environment: WildFly 8.0.0.Beta2-SNAPSHOT
> Reporter: Lukáš Fryč
> Fix For: warp_1.0.0.Alpha6
>
>
> When class is inner static class:
> {code}
> public class MyTest {
> @Test
> public void test1() {
> Warp....inspect(new MyInspection());
> Warp....inspect(new MyInspection()); // fails
> }
> @Test
> public void test2() {
> Warp....inspect(new MyInspection()); // fails
> }
> public static class MyInspection() {
> }
> }
> {code}
> the first inspection pass, but all subsequent inspections fails in the scope of one deployment.
> ----
> I think that is because the class is already loaded in classloader and its scanning might be cached by Weld.
> ----
> A issue was originally reproduced and reported here:
> https://issues.jboss.org/browse/RF-13417
> ----
> Exception and cause:
> {code}
> java.lang.RuntimeException: Could not inject members
> at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:135)
> at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.enrich(CDIInjectionEnricher.java:78)
> at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.warp.impl.server.test.LifecycleTestEnrichmentWatcher.rememberFieldValue
> {code}
> {code}
> Caused by: java.lang.IllegalArgumentException: Can not set org.richfaces.ui.region.RegionBean field org.richfaces.ui.region.AbstractRegionTest$SetupExecute.region to org.richfaces.ui.region.AbstractRegionTest$SetupExecute
> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
> at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:55)
> at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:75)
> at java.lang.reflect.Field.set(Field.java:741)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:94)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectNonContextualInstance(CDIInjectionEnricher.java:145)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ARQ-1598) Warp on WildFly: CDI fails to inject into inspection that is inner static class
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1598?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on ARQ-1598:
---------------------------------
It works fine for inner classes, probably because their names doesn't clash.
----
I have tried and the fact is that we need to "transform" static inner classes as well,
because they bears a link to declaring class, which prevents classloading.
----
Another suggestion might be loading inner static classes just once on server-side.
> Warp on WildFly: CDI fails to inject into inspection that is inner static class
> -------------------------------------------------------------------------------
>
> Key: ARQ-1598
> URL: https://issues.jboss.org/browse/ARQ-1598
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha5
> Environment: WildFly 8.0.0.Beta2-SNAPSHOT
> Reporter: Lukáš Fryč
> Fix For: warp_1.0.0.Alpha6
>
>
> When class is inner static class:
> {code}
> public class MyTest {
> @Test
> public void test1() {
> Warp....inspect(new MyInspection());
> Warp....inspect(new MyInspection()); // fails
> }
> @Test
> public void test2() {
> Warp....inspect(new MyInspection()); // fails
> }
> public static class MyInspection() {
> }
> }
> {code}
> the first inspection pass, but all subsequent inspections fails in the scope of one deployment.
> ----
> I think that is because the class is already loaded in classloader and its scanning might be cached by Weld.
> ----
> A issue was originally reproduced and reported here:
> https://issues.jboss.org/browse/RF-13417
> ----
> Exception and cause:
> {code}
> java.lang.RuntimeException: Could not inject members
> at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:135)
> at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.enrich(CDIInjectionEnricher.java:78)
> at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.warp.impl.server.test.LifecycleTestEnrichmentWatcher.rememberFieldValue
> {code}
> {code}
> Caused by: java.lang.IllegalArgumentException: Can not set org.richfaces.ui.region.RegionBean field org.richfaces.ui.region.AbstractRegionTest$SetupExecute.region to org.richfaces.ui.region.AbstractRegionTest$SetupExecute
> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
> at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:55)
> at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:75)
> at java.lang.reflect.Field.set(Field.java:741)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:94)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectNonContextualInstance(CDIInjectionEnricher.java:145)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months
[JBoss JIRA] (ARQ-1598) Warp on WildFly: CDI fails to inject into inspection that is inner static class
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/ARQ-1598?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč edited comment on ARQ-1598 at 12/5/13 4:23 AM:
----------------------------------------------------------
It works fine for inner classes, probably because their names doesn't clash.
----
I have tried and the fact is that we need to "transform" static inner classes as well,
because they bears a link to declaring class, which prevents classloading.
----
Another suggestion might be loading inner static classes just once on server-side - keeping a deployment-scoped class store for classes that was already loaded.
was (Author: lfryc):
It works fine for inner classes, probably because their names doesn't clash.
----
I have tried and the fact is that we need to "transform" static inner classes as well,
because they bears a link to declaring class, which prevents classloading.
----
Another suggestion might be loading inner static classes just once on server-side.
> Warp on WildFly: CDI fails to inject into inspection that is inner static class
> -------------------------------------------------------------------------------
>
> Key: ARQ-1598
> URL: https://issues.jboss.org/browse/ARQ-1598
> Project: Arquillian
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Extension - Warp
> Affects Versions: warp_1.0.0.Alpha5
> Environment: WildFly 8.0.0.Beta2-SNAPSHOT
> Reporter: Lukáš Fryč
> Fix For: warp_1.0.0.Alpha6
>
>
> When class is inner static class:
> {code}
> public class MyTest {
> @Test
> public void test1() {
> Warp....inspect(new MyInspection());
> Warp....inspect(new MyInspection()); // fails
> }
> @Test
> public void test2() {
> Warp....inspect(new MyInspection()); // fails
> }
> public static class MyInspection() {
> }
> }
> {code}
> the first inspection pass, but all subsequent inspections fails in the scope of one deployment.
> ----
> I think that is because the class is already loaded in classloader and its scanning might be cached by Weld.
> ----
> A issue was originally reproduced and reported here:
> https://issues.jboss.org/browse/RF-13417
> ----
> Exception and cause:
> {code}
> java.lang.RuntimeException: Could not inject members
> at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectClass(CDIInjectionEnricher.java:135)
> at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.enrich(CDIInjectionEnricher.java:78)
> at org.jboss.arquillian.test.impl.TestInstanceEnricher.enrich(TestInstanceEnricher.java:52)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:94)
> at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:99)
> at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:81)
> at org.jboss.arquillian.warp.impl.server.test.LifecycleTestEnrichmentWatcher.rememberFieldValue
> {code}
> {code}
> Caused by: java.lang.IllegalArgumentException: Can not set org.richfaces.ui.region.RegionBean field org.richfaces.ui.region.AbstractRegionTest$SetupExecute.region to org.richfaces.ui.region.AbstractRegionTest$SetupExecute
> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:164)
> at sun.reflect.UnsafeFieldAccessorImpl.throwSetIllegalArgumentException(UnsafeFieldAccessorImpl.java:168)
> at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:55)
> at sun.reflect.UnsafeObjectFieldAccessorImpl.set(UnsafeObjectFieldAccessorImpl.java:75)
> at java.lang.reflect.Field.set(Field.java:741)
> at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:94)
> at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:358)
> at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:369)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:72)
> at org.jboss.weld.injection.producer.ResourceInjector.inject(ResourceInjector.java:60)
> at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:66)
> at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:64)
> at org.jboss.weld.injection.producer.BasicInjectionTarget.inject(BasicInjectionTarget.java:90)
> at org.jboss.arquillian.testenricher.cdi.CDIInjectionEnricher.injectNonContextualInstance(CDIInjectionEnricher.java:145)
> {code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
10 years, 5 months