Can I ask what version of atlassian-plugins this will ship with? We need version 8.0.15+ for our app to run as we utilise new APIs @AndrzejKotas
the way we understand it, weāve been in it since March, when we published the first EAP build
The EAPs for Jira up to this point in time havenāt really been useful enough for app vendors to work on proactively. I praise early EAPs in general, Iād rather see a live direction of travel than have one dropped right before GA.
However, the EAPs are not representative of the substantial changes app vendors are impacted by, because none of them so far have contained platform 7.
It is not correct to say Jiraās platform 7 EAP has been running since March, if you provide no EAP containing platform 7 to vendors til early July, with an expectation to go GA shortly after.
- one more EAP build ~ first half of July - focused on polishing the Platform integration
- RC towards the end of July
So app vendors have less than a month to validate this substantial platform upgrade?
How can the Jira team in good consience make that decision? Itās visible to all app vendors how much of a struggle the Jira product team have been having internally. Where is the sympathy for app vendors?
Those of us with cross product apps have an advantage as we have already made the bulk of required changes earlier in the year. There are many (majority?) Jira apps that are not cross product, so the majority of app vendors will only seriously begin testing Jira 10/Platform 7 imminently.
Take a look at the ~340 reply thread for Confluence 9, should we not expect a larger scale of vendor pain for Jira, given it has a larger app footprint?
When Jira 10 adopts platform 7 properly, does this also mean all the platform grey API changes will actively be enforced?
I was just chatting with @mkemp about grey API in the WRM, weād be expecting those changes to be consistently enforced for apps in Jira 10.
9 Likes
I disagree with this way of viewing the EAP period. From our perspective, platform 7 is the first piece of the puzzle (and also the most critical one by far). Since Jira 10 hasnāt been compatible with platform 7, we have not had the capacity to test towards Jira 10 with our platform 7 code base (we are building cross-product apps with a single codebase). It wouldnāt really feel like time well spent anyways, testing towards a Jira that may change substantially as soon as platform 7 is adopted.
From our (the vendorās) perspective, this is introducing the Platform integration. I echo the points raised by @rlander. Given experience from other DC products, such as Confluence with its never-ending thread of comments, you can expect the community to run into a lot of surprising side-effects that need to be addressed. On top of this weāre now also in summer vacation times, so a lot of vendors have a reduced capacity for testing.
I sincerely hope that the Jira team will consider a timeline with more room for community feedback on platform 7.
5 Likes
atlassian-plugins will be version 8.0.15 in the new EAP.
3 Likes
The last time I requested EAP source code from Jira in February I got this in response:
On ours, since Iām from Jira support, Iāll be getting the:
Jira 9.14 EAP: jira-software:9.14.0-EAP02
However, we have a period limitation of at least 30 days from the release date to share the sources.
So youāll need to ask it again on March, 1st.
Does the Jira team still enforce this policy? If so, when testing platform 7 changes, will we not be able to get our hands on the EAP source code until after the Release Candidate is published?
2 Likes
Hi
currently testing the jira 10
the AITs arquillian didnt work with jdk17
any ideia?
All the test work with jdk8 or jdk9, when I change to jdk17 the tests do not start.
The error
`
java.io.StreamCorruptedException: invalid stream header: 0A0A0A0A
at java.base/java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:958)
at java.base/java.io.ObjectInputStream.<init>(ObjectInputStream.java:392)
at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.execute(ServletMethodExecutor.java:173)
at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor$1.run(ServletMethodExecutor.java:221)
at java.base/java.util.TimerThread.mainLoop(Timer.java:566)
at java.base/java.util.TimerThread.run(Timer.java:516)
`
and
java.lang.IllegalStateException: Error launching test
at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.invoke(ServletMethodExecutor.java:100)
at org.jboss.arquillian.container.test.impl.execution.RemoteTestExecuter.execute(RemoteTestExecuter.java:103)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:105)
at org.jboss.arquillian.core.impl.EventImpl.fire(EventImpl.java:62)
at org.jboss.arquillian.container.test.impl.execution.ClientTestExecuter.execute(ClientTestExecuter.java:52)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.invokeObservers(EventContextImpl.java:103)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:90)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createContext(ContainerEventController.java:128)
at org.jboss.arquillian.container.test.impl.client.ContainerEventController.createTestContext(ContainerEventController.java:118)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createTestContext(TestContextHandler.java:116)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createClassContext(TestContextHandler.java:83)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.test.impl.TestContextHandler.createSuiteContext(TestContextHandler.java:69)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at org.jboss.arquillian.core.impl.ObserverImpl.invoke(ObserverImpl.java:86)
at org.jboss.arquillian.core.impl.EventContextImpl.proceed(EventContextImpl.java:95)
at org.jboss.arquillian.core.impl.ManagerImpl.fire(ManagerImpl.java:133)
at org.jboss.arquillian.test.impl.EventTestRunnerAdaptor.test(EventTestRunnerAdaptor.java:139)
at org.jboss.arquillian.testng.Arquillian.run(Arquillian.java:138)
at org.testng.internal.MethodInvocationHelper.invokeHookable(MethodInvocationHelper.java:253)
at org.testng.internal.TestInvoker.invokeMethod(TestInvoker.java:594)
at org.testng.internal.TestInvoker.invokeTestMethod(TestInvoker.java:173)
at org.testng.internal.MethodRunner.runInSequence(MethodRunner.java:46)
at org.testng.internal.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:824)
at org.testng.internal.TestInvoker.invokeTestMethods(TestInvoker.java:146)
at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146)
at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:128)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
at org.testng.TestRunner.privateRun(TestRunner.java:794)
at org.testng.TestRunner.run(TestRunner.java:596)
at org.testng.SuiteRunner.runTest(SuiteRunner.java:377)
at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:371)
at org.testng.SuiteRunner.privateRun(SuiteRunner.java:332)
at org.testng.SuiteRunner.run(SuiteRunner.java:276)
at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:53)
at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:96)
at org.testng.TestNG.runSuitesSequentially(TestNG.java:1212)
at org.testng.TestNG.runSuitesLocally(TestNG.java:1134)
at org.testng.TestNG.runSuites(TestNG.java:1063)
at org.testng.TestNG.run(TestNG.java:1031)
at com.intellij.rt.testng.IDEARemoteTestNG.run(IDEARemoteTestNG.java:65)
at com.intellij.rt.testng.RemoteTestNGStarter.main(RemoteTestNGStarter.java:105)
Caused by: java.io.StreamCorruptedException: invalid stream header: 0A0A0A0A
at java.base/java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:958)
at java.base/java.io.ObjectInputStream.<init>(ObjectInputStream.java:392)
at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.execute(ServletMethodExecutor.java:173)
at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.executeWithRetry(ServletMethodExecutor.java:119)
at org.jboss.arquillian.protocol.servlet.ServletMethodExecutor.invoke(ServletMethodExecutor.java:97)
... 74 more
I think this library is effectively unmaintained, as it is not really used internally at Adaptavist anymore.
There is a suggested workaround here: https://bitbucket.org/adaptavistlabs/atlassian-arquillian-containers/issues/19/javaiostreamcorruptedexception-invalid
1 Like
Iād suggest to check jira logs, invalid stream header is usually an indicator that test āpluginā has failed to install.
1 Like
The deprecated com.atlassian.plugin.webresource.WebResourceManager class still appears to be referenced in jira-api on current milestone:
com.atlassian.jira.component.ComponentAccessor#getWebResourceManager uses the old type, or at least it appears to.
This presents a problem because the old class is no longer on our classpath, blowing up our test suite.
I know why this is the case, there isnāt a platform 7 EAP for Jira 10 yet, despite being close to releaseā¦
This inconsistency makes it a nightmare to develop cross product apps.
1 Like
Thanks, Iāve reported this to the Jira team.
Have thrown in some stubs for the old FQCNs whilst we wait for Jira to catch up on platform 7
Hello,
I am receiving the error Package org.supercsv.io is internal and is not available for export to plugin trying to import
<dependency>
<groupId>net.sf.supercsv</groupId>
<artifactId>super-csv</artifactId>
<version>2.1.0</version>
<scope>provided</scope>
</dependency>
is it intentional? how can I keep using this dependency that comes with jira-core and jira importers plugin?
Iām sorry if itās not the right place but i have this problem on jira10 only
Hey folks, weāre brewing the EAP build with P7 integrated. The last sanity checks are in motion, and we hope to get it to you in a matter of days or sooner even and work with you closely on the feedback and issues you might face. Appreciate your patience so far, cheers
3 Likes
Given that this will be the first EAP with Platform 7, can you please tell us what impact this will have on your GA planning?
2 Likes
Hello team, as mentioned yesterday weāre now ready to expose Platform 7 as part of the early access program. Please review the changelog with the updates introduced. The next EAP release of Jira Software 10.0 and Jira Service Management 10.0 wonāt bring any further functional or technical changes as Platform 7 integration closed the planned scope. Weāll focus on quality aspects and ensuring further system stability instead.
As a non-technical change, weāve also decided to update the versioning behind Jira Service Management. The differing numbers for our Jira product releases were causing unnecessary confusion. To help streamline these releases, weāll introduce Jira Software 10.0 and Jira Service Management 10.0 in the Q3 2024 release.
With this change, no major compatibility issues are expected; itās simply a name change. For more information, please review: Jira Service Management 6.0 will now be named Jira... - Atlassian Community
Looking forward to your feedback
The Jira Team
3 Likes
Can you be more specific than just Q3? Because Q3 is already 4 days underway. Saying āQ3 releaseā could also mean tomorrow 
3 Likes
Thank you for the new version of EAP.
Caused by: com.atlassian.plugin.PluginParseException:
Unable to load the module's display conditions:
Cannot load condition class: com.company.plugins.appname.condition.UrlCondition.
Only classes extended com.atlassian.webresource.spi.condition.UrlReadingCondition are supported.
Please migrate your conditions to the com.atlassian.webresource.spi.condition.UrlReadingCondition class.
https://developer.atlassian.com/server/framework/atlassian-sdk/stateless-web-resource-transforms-and-conditions
Huh, I have a feeling that in version 10 the batch.js and batch.css files will be much larger - unfortunately we have to change the implementation of our resources and they will be filtered on the client side, not on the server side 
Cheers
Adam
@AndrzejKotas great 
.
Is the Platform 7 Velocity Allowlist fully active and enforced in 10.0.0-m0007 aka EAP05?
I am seeing my app working with method calls to (not only getters) to various classes in my velocity template. All working fine without the allowlist configured.
Hi @clouless , right now method allowlist is enabled in debug mode (because we need to make sure that list is completed on our side). So no method will be blocked, just log will be thrown to add the method to allowlist. You can look for log like DEBUG MODE: Method needs allowlisting: <method>
1 Like
Great, thanks for the quick response. I will implement the allowlist accordingly 
Another thing I saw is the new app usage page which does not show Active Objects Tables and REST API Calls for my app. But my app performs REST API calls to its own API Endpoints on very page view and user interaction. The app also has four AO tables.
It says:
- ā0 REST API calls made by 0 usersā
- ā0 database tablesā
Is this an early preview feature and it is not working because of that, or is something wrong with the app?