[JBoss JIRA] (JBIDE-13263) Workspace metadata deployment does not work for AS 6
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13263?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-13263:
----------------------------------------
Attachment: (was: astools api.gliffy)
> Workspace metadata deployment does not work for AS 6
> ----------------------------------------------------
>
> Key: JBIDE-13263
> URL: https://issues.jboss.org/browse/JBIDE-13263
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: JBossAS/Servers
> Affects Versions: 4.0.0.Final
> Environment: JBoss AS 6.1.0
> Reporter: Martin Malina
> Assignee: Max Rydahl Andersen
> Priority: Critical
> Fix For: 4.0.1.Final
>
> Attachments: astools api.png, launch a server.png, New Server Workflow.gliffy, New Server Workflow.png, runtime workflow.gliffy, runtime workflow.png
>
>
> When you deploy a module to JBoss AS 6 and deployment is set to Workspace Metadata, the module doesn't get deployed.
--
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
13 years, 2 months
[JBoss JIRA] (JBIDE-13263) Workspace metadata deployment does not work for AS 6
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13263?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-13263:
----------------------------------------
Attachment: (was: New Server Workflow.gliffy)
> Workspace metadata deployment does not work for AS 6
> ----------------------------------------------------
>
> Key: JBIDE-13263
> URL: https://issues.jboss.org/browse/JBIDE-13263
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: JBossAS/Servers
> Affects Versions: 4.0.0.Final
> Environment: JBoss AS 6.1.0
> Reporter: Martin Malina
> Assignee: Max Rydahl Andersen
> Priority: Critical
> Fix For: 4.0.1.Final
>
> Attachments: astools api.png, launch a server.png, New Server Workflow.png, runtime workflow.gliffy, runtime workflow.png
>
>
> When you deploy a module to JBoss AS 6 and deployment is set to Workspace Metadata, the module doesn't get deployed.
--
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
13 years, 2 months
[JBoss JIRA] (JBIDE-13232) refactor target platforms' GAVs, names, labels (was target platforms has the same name)
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13232?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-13232:
----------------------------------------
[~rcernich]
{quote}I know I'm late to the party and I didn't read the whole history of comments, but it seems like this would be more useful if the tp projects were versioned along with JBT. Obviously, you could add min/max as necessary. This would allow me to say something akin to: use the target platform that goes with JBT 4.0, e.g. (maven management key) org.jboss.tools:target-platform:target:unified-min:4.0
As a downstream consumer, I don't really care what version of the Eclipse platform the TP is tied to, since I will be targeting some version of JBT (e.g. 4.0, 4.1, 5.0, etc.). The current approach leaves me having to map a JBT version to a TP version (unnecessarily so, in my opinion).{quote}
The approach you're suggesting doesn't scale because there is not a 1-1 mapping that would allow to bind a version of JBT to a (min/max) target platforms couple. We change TPs more often that we release milestone of JBT at the beginning of a release stream; and less than there are JBT milestones at the end of the stream.
Also some TPs are used in different stream (eg for now, JBT 4.1.0.Alpha1 shares the same minimal TP as JBT 4.0.0), and it's pretty difficult to maintain this mapping from target-platforms. That's why TPs now follow there versioning scheme and JBT parent is updated to select on of the available TPs.
I understand that, as a downstream consumer, it's not the easiest why to guess which TP is used for JBT x. For that, you'll have to either check the parent pom of the JBT version you're targetting, the TP version is written in it; or simply come to mailing-list/IRC/whatever and ask.
> refactor target platforms' GAVs, names, labels (was target platforms has the same name)
> ---------------------------------------------------------------------------------------
>
> Key: JBIDE-13232
> URL: https://issues.jboss.org/browse/JBIDE-13232
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Affects Versions: 4.1.0.Alpha1
> Environment:
> Reporter: Max Rydahl Andersen
> Assignee: Nick Boldt
> Fix For: 4.1.0.Alpha1
>
> Attachments: JBIDE13232.parent.pom.tweaks.txt
>
>
> .target files are all called "e42-wtp34-jbds6" even though they are for jbosstools and not specific to jbds6 either.
> Makes it hard to actually see which target platform to choose
--
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
13 years, 2 months
[JBoss JIRA] (JBIDE-13411) JavaEE component job can take over 8hrs to run w/ tests - move out integration tests and rewrite them to avoid UI blocking
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13411?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-13411:
----------------------------------------
> WDYT about running parallel processes during a Tycho build
Actually I never tried it. That could be a solution if we can ensure tests are really independent and can actually run in parallel. I'm not sure it's really possible when it come to UI tests
> running a different job to bootstrap all the runtimes needed by these long-running i-tests?
That sounds better. Continuous Integration us requires a fast feedback loop to be efficient, the test run in continuous build should be a compromise between acceptance and fast execution. Several hours are way to much, and it seems to me that most of those tests are redundant, on version of Seam runtime changes.
I would suggest we run only 1 test suite (for let's say, the latest version of Seam runtime) as part of the continuous build, and we create a new job for the other tests.
> JavaEE component job can take over 8hrs to run w/ tests - move out integration tests and rewrite them to avoid UI blocking
> --------------------------------------------------------------------------------------------------------------------------
>
> Key: JBIDE-13411
> URL: https://issues.jboss.org/browse/JBIDE-13411
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Visual Page Editor Templates
> Affects Versions: 4.0.1.Final, 4.1.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Yahor Radtsevich
> Priority: Blocker
>
> On a good day, tests will run and all pass in under 4hrs.
> On a grey day, tests will have failures but complete in under 6hrs.
> On a bad day, tests will stall out and the job will fail when it hits its duration upper limit of 8hrs.
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
> https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS...
> Surely some of these tests are:
> a) integration, not unit test, and should be relocated to https://github.com/jbosstools/jbosstools-integration-tests/ and run as part of a new job like https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-4.1_trunk... ?
> b) reliant on UI which is blocking, and should therefore be rewritten so as to not block test execution?
--
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
13 years, 2 months
[JBoss JIRA] (JBDS-2448) New ESB wizard - version mismatch errors - and a warning message that is not erased
by Len DiMaggio (JIRA)
[ https://issues.jboss.org/browse/JBDS-2448?page=com.atlassian.jira.plugin.... ]
Len DiMaggio commented on JBDS-2448:
------------------------------------
Hey Brian, Thanks for sorting this out. I vote for:
1) ...getting rid of the auto-selection dance and pop up an error saying something like "ESB Version X.Y is not supported by the specified runtime." and prevent them from saving it as a new runtime until they correct it.
And
2) As for the error not being reset, I can also fix that here
And - as for the wording of the error message - I'm not crazy about the wording that you propose - but I also cannot think of anything better! ;-)
3) "Selected runtime supports ESB runtime version 4.11. Assuming compatible with selected version: 4.12
> New ESB wizard - version mismatch errors - and a warning message that is not erased
> -----------------------------------------------------------------------------------
>
> Key: JBDS-2448
> URL: https://issues.jboss.org/browse/JBDS-2448
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: SOA Tooling / Platform
> Affects Versions: 5.0.3.GA-SOA
> Environment: Version: 5.0.2.GA
> Build id: v20130119-0035-H249-GA
> Build date: 20130119-0035
> md5sum esb.site.zip
> 4c149c52a6058edabe0ad84747443877 esb.site.zip
> Reporter: Len DiMaggio
> Assignee: Brian Fitzpatrick
> Fix For: 5.0.3.GA-SOA
>
>
> Steps:
> 1) Create new ESB runtime, select the SOA Platform dir path
> 2) Accept default version, specify a name for the new run-time
> 3) Then - before saving the new ESB runtime change the version number - the results are:
> With an SOA-P 5.2 server (ESB 4.10):
> * The default ESB version displayed is 4.10
> * If this is changed to 4.11, this warning is displayed:
> No exact match found for ESB runtime version 4.10. Assuming compatible with latest version: 4.7.
> * If the version is changed back to 4.10, the error is still displayed in the wizard
> With an SOA-P 5.3 server (ESB 4.11):
> * The default ESB version displayed is 4.11
> * If this is changed to 4.12, this warning is displayed:
> No exact match found for ESB runtime version 4.11. Assuming compatible with latest version: 4.12.
> * If the version is changed back to 4.11, the error is still displayed in the wizard
> With an SOA-P 5.3.1.ER3 server (ESB 4.11.1):
> * The default ESB version displayed is 4.11
> * If this is changed to 4.12, this warning is displayed:
> No exact match found for ESB runtime version 4.11. Assuming compatible with latest version: 4.12.
> * If the version is changed back to 4.11, the error is still displayed in the wizard
> With an SOA-P 5.3.1.ER4 server (edited VERSION file in rosetta.jar to be ESB 4.12):
> * The default ESB version displayed is 4.12
> * If this is changed to 4.11, this warning is displayed:
> No exact match found for ESB runtime version 4.12. Assuming compatible with latest version: 4.11.
> * If the version is changed back to 4.12, the error is still displayed in the wizard
--
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
13 years, 2 months
[JBoss JIRA] (JBIDE-13232) refactor target platforms' GAVs, names, labels (was target platforms has the same name)
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-13232?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-13232:
------------------------------------
We considered that approach but decided it was better to build TPs versioned independently from the JBT version because we may some day hit a point where WTP (specifically, Dali) stops breaking API every year and so we could build JBT against BOTH Juno and Kepler, rather than being tied to a specific version every year we release
For the JBITS case, you can version your TPs based on Eclipse (4.2, 4.3) or based on JBT (4.0, 4.1) as you'd prefer. Since currently we are forced to release each subsequent version of JBT/JBDS against a new version of Eclipse/WTP without being 100% backward compatible, and are therefore a ratio of 1:1 (JBDS/JBT:EclipseReleaseTrain), it doesn't really matter which you select. However, in future, we would like to get to the point where we're 1:2, so maybe at that point it makes more sense to use the Eclipse version... otherwise you'd need two TPs versioned the same way.
Thus, assuming you need 2 target platforms for JBT 4.0 (Eclipse Juno 4.2), JBT 4.1 (Eclipse Kepler 4.3), and that next year's JBT 4.2 works with both Kepler (Eclipse 4.3) and Luna (Eclipse 4.4), you might get this:
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (Dec 2012)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (after 4.0.1 maintenance release in Mar 2013)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (Jul 2013)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (after 4.0.1 maintenance release in Sep 2013)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (Jul 2014?)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (Jul 2014?)
etc.
Which, IMHO, is less sexy than this:
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (after Jun 2012)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (after Sep 2012)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (after Dec 2012)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (after Mar 2013
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (currently contains M4 bits)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (will contains M5 bits)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (after Sep 2013, Luna M3 bits?)
So basically, you'd define a TP aligned to an Eclipse version, and every time you have to change it to adjust the contents, the service digit would increment.
I suppose you could also use the "service + 100" convention to define branches and align w/ JBT versions... thus:
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (Dec 2012)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (after 4.0.1 maintenance release in Mar 2013)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (Jul 2013)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (after 4.0.1 maintenance release in Sep 2013)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (Jul 2014, Kepler bits)
https://repository.jboss.org/nexus/content/repositories/snapshots/org/jbo... (Jul 2014, Luna bits)
etc.
But I think I still prefer to version based on the Eclipse baseline version, regardless of the other stuff in there... since that's the base on which you'll be installing, testing, running, etc.
> refactor target platforms' GAVs, names, labels (was target platforms has the same name)
> ---------------------------------------------------------------------------------------
>
> Key: JBIDE-13232
> URL: https://issues.jboss.org/browse/JBIDE-13232
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: Build/Releng
> Affects Versions: 4.1.0.Alpha1
> Environment:
> Reporter: Max Rydahl Andersen
> Assignee: Nick Boldt
> Fix For: 4.1.0.Alpha1
>
> Attachments: JBIDE13232.parent.pom.tweaks.txt
>
>
> .target files are all called "e42-wtp34-jbds6" even though they are for jbosstools and not specific to jbds6 either.
> Makes it hard to actually see which target platform to choose
--
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
13 years, 2 months
[JBoss JIRA] (JBDS-2448) New ESB wizard - version mismatch errors - and a warning message that is not erased
by Brian Fitzpatrick (JIRA)
[ https://issues.jboss.org/browse/JBDS-2448?page=com.atlassian.jira.plugin.... ]
Brian Fitzpatrick commented on JBDS-2448:
-----------------------------------------
As for the error not being reset, I can also fix that here.
> New ESB wizard - version mismatch errors - and a warning message that is not erased
> -----------------------------------------------------------------------------------
>
> Key: JBDS-2448
> URL: https://issues.jboss.org/browse/JBDS-2448
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: SOA Tooling / Platform
> Affects Versions: 5.0.3.GA-SOA
> Environment: Version: 5.0.2.GA
> Build id: v20130119-0035-H249-GA
> Build date: 20130119-0035
> md5sum esb.site.zip
> 4c149c52a6058edabe0ad84747443877 esb.site.zip
> Reporter: Len DiMaggio
> Assignee: Brian Fitzpatrick
> Fix For: 5.0.3.GA-SOA
>
>
> Steps:
> 1) Create new ESB runtime, select the SOA Platform dir path
> 2) Accept default version, specify a name for the new run-time
> 3) Then - before saving the new ESB runtime change the version number - the results are:
> With an SOA-P 5.2 server (ESB 4.10):
> * The default ESB version displayed is 4.10
> * If this is changed to 4.11, this warning is displayed:
> No exact match found for ESB runtime version 4.10. Assuming compatible with latest version: 4.7.
> * If the version is changed back to 4.10, the error is still displayed in the wizard
> With an SOA-P 5.3 server (ESB 4.11):
> * The default ESB version displayed is 4.11
> * If this is changed to 4.12, this warning is displayed:
> No exact match found for ESB runtime version 4.11. Assuming compatible with latest version: 4.12.
> * If the version is changed back to 4.11, the error is still displayed in the wizard
> With an SOA-P 5.3.1.ER3 server (ESB 4.11.1):
> * The default ESB version displayed is 4.11
> * If this is changed to 4.12, this warning is displayed:
> No exact match found for ESB runtime version 4.11. Assuming compatible with latest version: 4.12.
> * If the version is changed back to 4.11, the error is still displayed in the wizard
> With an SOA-P 5.3.1.ER4 server (edited VERSION file in rosetta.jar to be ESB 4.12):
> * The default ESB version displayed is 4.12
> * If this is changed to 4.11, this warning is displayed:
> No exact match found for ESB runtime version 4.12. Assuming compatible with latest version: 4.11.
> * If the version is changed back to 4.12, the error is still displayed in the wizard
--
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
13 years, 2 months