[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-15482:
---------------------------------------------
no progress and not seeing this happening before GA and we will have to survive until then. thus punting.
> Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15482
> URL: https://issues.jboss.org/browse/JBIDE-15482
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build, updatesite
> Affects Versions: 4.2.0.Beta2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Labels: f2f2014
> Fix For: 4.2.x, 4.3.0.Alpha1
>
>
> Be it proposed:
> {quote}
> that instead of an in-place move which reuses
> generic folder names like "staging" and "staging.previous", we
> composite build output using unique names like
> 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255
> {quote}
> We therefore need:
> a) to regenerate the composite site each time there's a new build
> published, in order to remove the oldest and add the newest (keeping
> only the Nth and N-1rst builds)
> (I have a script that might already work for this, or would need
> tweaking.)
> b) heuristics to determine when an older (N-2, N-3, ... N-z) build is
> no longer needed, perhaps simply by assuming no one needs it after
> 24hrs?
> 24 hours should be more that enough.
> c) a cleanup script which can purge all but the builds which are no
> more than 1 day old, keeping at all times at least two builds (N and
> N-1)
> (I have a script that already does this for folders like
> http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but
> might need to be tweaked to work for a new pattern of
> staging/\$\{JOB_NAME}/<BUILD_ID>/ .)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-15482:
----------------------------------------
Fix Version/s: 4.2.x
4.3.0.Alpha1
(was: 4.2.0.CR1)
> Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15482
> URL: https://issues.jboss.org/browse/JBIDE-15482
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build, updatesite
> Affects Versions: 4.2.0.Beta2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Labels: f2f2014
> Fix For: 4.2.x, 4.3.0.Alpha1
>
>
> Be it proposed:
> {quote}
> that instead of an in-place move which reuses
> generic folder names like "staging" and "staging.previous", we
> composite build output using unique names like
> 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255
> {quote}
> We therefore need:
> a) to regenerate the composite site each time there's a new build
> published, in order to remove the oldest and add the newest (keeping
> only the Nth and N-1rst builds)
> (I have a script that might already work for this, or would need
> tweaking.)
> b) heuristics to determine when an older (N-2, N-3, ... N-z) build is
> no longer needed, perhaps simply by assuming no one needs it after
> 24hrs?
> 24 hours should be more that enough.
> c) a cleanup script which can purge all but the builds which are no
> more than 1 day old, keeping at all times at least two builds (N and
> N-1)
> (I have a script that already does this for folders like
> http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but
> might need to be tweaked to work for a new pattern of
> staging/\$\{JOB_NAME}/<BUILD_ID>/ .)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (JBIDE-15482) Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-15482:
----------------------------------------
Labels: f2f2014 (was: )
> Replace staging & staging.previous (two builds w/ reused URLs) with uniquely timestamped build URLs and auto-regenerated composite*.xml files
> ---------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-15482
> URL: https://issues.jboss.org/browse/JBIDE-15482
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: build, updatesite
> Affects Versions: 4.2.0.Beta2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Labels: f2f2014
> Fix For: 4.2.x, 4.3.0.Alpha1
>
>
> Be it proposed:
> {quote}
> that instead of an in-place move which reuses
> generic folder names like "staging" and "staging.previous", we
> composite build output using unique names like
> 2013-08-09_05-05-26-B7222/ or 2013-08-13_10-05-28-B7255
> {quote}
> We therefore need:
> a) to regenerate the composite site each time there's a new build
> published, in order to remove the oldest and add the newest (keeping
> only the Nth and N-1rst builds)
> (I have a script that might already work for this, or would need
> tweaking.)
> b) heuristics to determine when an older (N-2, N-3, ... N-z) build is
> no longer needed, perhaps simply by assuming no one needs it after
> 24hrs?
> 24 hours should be more that enough.
> c) a cleanup script which can purge all but the builds which are no
> more than 1 day old, keeping at all times at least two builds (N and
> N-1)
> (I have a script that already does this for folders like
> http://download.jboss.org/jbosstools/builds/nightly/core/trunk/ but
> might need to be tweaked to work for a new pattern of
> staging/\$\{JOB_NAME}/<BUILD_ID>/ .)
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months
[JBoss JIRA] (JBIDE-18265) NullPointerException in ArquillianBuilder when creating test class with the name Test
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18265?page=com.atlassian.jira.plugi... ]
Snjezana Peco reassigned JBIDE-18265:
-------------------------------------
Assignee: Snjezana Peco
> NullPointerException in ArquillianBuilder when creating test class with the name Test
> -------------------------------------------------------------------------------------
>
> Key: JBIDE-18265
> URL: https://issues.jboss.org/browse/JBIDE-18265
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: testing-tools
> Affects Versions: 4.2.0.CR1
> Reporter: Lucia Jelinkova
> Assignee: Snjezana Peco
> Priority: Critical
> Fix For: 4.2.0.CR2
>
>
> When I try to create an Arquillan test class with the name Test, it is created, however, the Arquillian builder fails with NP.
> {code}
> java.lang.NullPointerException
> at org.eclipse.jdt.core.dom.MethodBinding.filterTypeAnnotations(MethodBinding.java:205)
> at org.eclipse.jdt.core.dom.MethodBinding.getAnnotations(MethodBinding.java:104)
> at org.jboss.tools.arquillian.core.internal.util.ArquillianSearchEngine.isDeploymentMethod(ArquillianSearchEngine.java:862)
> at org.jboss.tools.arquillian.core.internal.util.ArquillianSearchEngine.getDeploymentMethods(ArquillianSearchEngine.java:849)
> at org.jboss.tools.arquillian.core.internal.util.ArquillianSearchEngine.hasDeploymentMethod(ArquillianSearchEngine.java:599)
> at org.jboss.tools.arquillian.core.internal.builder.ArquillianBuilder.build(ArquillianBuilder.java:255)
> at org.jboss.tools.arquillian.core.internal.builder.ArquillianBuilder.buildDelta(ArquillianBuilder.java:210)
> at org.jboss.tools.arquillian.core.internal.builder.ArquillianBuilder.build(ArquillianBuilder.java:109)
> at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:206)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:246)
> at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:299)
> at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
> at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:302)
> at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:358)
> at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:381)
> at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
> at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
> at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
> {code}
> This is because the test method is generated with the @Test annotation without fully qualified name.
> {code}
> @Test
> public void test() {
> fail("Not yet implemented");
> }
> {code}
> In JUnit, when I tried to create test class with the name Test, the @Test annotation was generated with fullly qualified name
> {code}
> @Test
> @org.junit.Test
> public void test() {
> fail("Not yet implemented");
> }
> {code}
> However, when I checked that I want do generate tearDown method, JUnit created the annotation withou fully qualified name too.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 7 months