[JBoss JIRA] (JBIDE-15457) CordovaSim and Hybrid tools interaction/source code sharing
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15457?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-15457:
---------------------------------------------
browersim != cordovasim. this issue is about cordovasim which requires a proxy server to work.
> CordovaSim and Hybrid tools interaction/source code sharing
> -----------------------------------------------------------
>
> Key: JBIDE-15457
> URL: https://issues.jboss.org/browse/JBIDE-15457
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: aerogear-hybrid, browsersim
> Reporter: Yahor Radtsevich
> Assignee: Yahor Radtsevich
> Fix For: 4.2.x
>
>
> Currently CordovaSim application consists of two parts: a Jetty-based server, and a BrowserSim-based client. The server part generates some content on the fly. For instance, the server may response with generated {{cordova_plugins.js}} content when it is requested by the client. Both parts of CordovaSim are executed in their own JVM, which means they do not have access to the Eclipse API.
> Hybrid tools do very similar things, but in static way. For instance, while creating Android executables, they create {{cordova_plugins.js}} file on disk. Hybrid tools is a set of Eclipse plugins, so they have access to the Eclipse API.
> Obviously CordovaSim and Hybrid tools have some code in their sources that could be shared. For the example above, both of them need a method to generate content of {{cordova_plugins.js}}. There are several approaches to implement it:
> 1. Create two different implementations for CordovaSim and Hybrid tools and synchronize them when needed (currently we do this). This approach creates code duplication problems.
> 2. Create an Eclipse API-independent plugin, so both CordovaSim and Hybrid tools could set it as a dependency. This approach imposes some restriction on the independent plugin (useful Eclipse API and libs cannot be used).
> 3. Move the server part of CordovaSim to the Eclipse JVM, so it could use Eclipse API and any Hybrid tools API. With this approach we loose the ability to create standalone CordovaSim in the future.
--
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
12 years, 8 months
[JBoss JIRA] (JBIDE-15388) Compute whether to publish or not based on output signature rather than commits
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15388?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-15388:
---------------------------------------------
reproducible qualifiers won't detect if job configuration changed would it ?
you changing TP version won't change the commit that is used for reproducible qualifiers?
With respect to the new comparison, we would need to remove and date/time stamping happening in the builds since that would trigger a diff on binary level.
> Compute whether to publish or not based on output signature rather than commits
> -------------------------------------------------------------------------------
>
> Key: JBIDE-15388
> URL: https://issues.jboss.org/browse/JBIDE-15388
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: build
> Reporter: Mickael Istria
> Assignee: Mickael Istria
> Fix For: LATER
>
>
> [Assuming we already have reproducible qualifiers...]
> Currently, the CI jobs publish the output of a build if a change was detected in the Git repo since last publication.
> However there are some case not correctly supported:
> * Job configuration changed and caused changes in build output. In that case, we would like build output to be re-published, but it won't happen
> * Job source changed but not build output (eg a change in a pom.xml or any non-included file), then we don't need to republish output whereas current mechanism would republish it.
> instead, it would make sense to compare what's already published and what is to publish in order to decide or not whether this has to be published. Looking at signatures of update site zip would probably be enough.
--
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
12 years, 8 months
[JBoss JIRA] (JBDS-2734) Forge 2 in JBDS
by Lincoln Baxter III (JIRA)
[ https://issues.jboss.org/browse/JBDS-2734?page=com.atlassian.jira.plugin.... ]
Lincoln Baxter III commented on JBDS-2734:
------------------------------------------
Forge does not require Maven 3.1 to run, only to build. Additionally, we bundle our own version of maven internally. I actually don't know why we have any dependency whatsoever on the m2e eclipse bundle. I believe it has to do with project import and automatic updating the project configuration when Forge makes changes to a project. At some point I'd like to talk to you about removing that dependency because there should be a more generic way to trigger project updates that does not require hard-coupling.
> Forge 2 in JBDS
> ---------------
>
> Key: JBDS-2734
> URL: https://issues.jboss.org/browse/JBDS-2734
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: forge, requirements
> Reporter: Burr Sutter
>
> Is Forge 2 ready to be included in JBDS ?
--
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
12 years, 8 months
[JBoss JIRA] (JBIDE-15198) Move away from sonatype aether to eclipse aether
by Fred Bricon (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15198?page=com.atlassian.jira.plugi... ]
Fred Bricon updated JBIDE-15198:
--------------------------------
Description:
With Maven 3.1.0, Sonatype Aether has been replaced with Eclipse Aether. m2e 1.5.0 will soon do the same. Currently, I've found that at least the following plugins have a dependency to the Sonatype version :
- org.jboss.tools.arquillian.core
- org.jboss.tools.maven.project.examples
- org.jboss.tools.maven.ui
Ideally the next m2e version won't embed the jars directly (but this is not guaranteed). Aether is available from this p2 repo : http://download.eclipse.org/aether/aether-core/milestones
was:
With Maven 3.1.0, Sonatype Aether has been replaced with Eclipse Aether. m2e 1.5.0 will soon do the same. Currently, I've found that at least the following plugins have a dependency to the Sonatype version :
- org.jboss.tools.arquillian.core
- org.jboss.tools.maven.project.examples
- org.jboss.tools.maven.ui
Ideally the next m2e version won't embed the jars directly. Aether is available from this p2 repo : http://download.eclipse.org/aether/aether-core/milestones
> Move away from sonatype aether to eclipse aether
> ------------------------------------------------
>
> Key: JBIDE-15198
> URL: https://issues.jboss.org/browse/JBIDE-15198
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: maven, project-examples, testing-tools
> Affects Versions: 4.1.0.CR1
> Reporter: Fred Bricon
> Fix For: 4.2.x
>
>
> With Maven 3.1.0, Sonatype Aether has been replaced with Eclipse Aether. m2e 1.5.0 will soon do the same. Currently, I've found that at least the following plugins have a dependency to the Sonatype version :
> - org.jboss.tools.arquillian.core
> - org.jboss.tools.maven.project.examples
> - org.jboss.tools.maven.ui
> Ideally the next m2e version won't embed the jars directly (but this is not guaranteed). Aether is available from this p2 repo : http://download.eclipse.org/aether/aether-core/milestones
--
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
12 years, 8 months
[JBoss JIRA] (JBIDE-15250) Explode utility jars in EAR/WAR deployments
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15250?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-15250:
---------------------------------------------
Can you show your assembly configuration for this? (screenshot should be enough)
if these are actually utility projects and included as such this should in theory be possible to make it work - but if just included as raw jars then I don't see how.
> Explode utility jars in EAR/WAR deployments
> -------------------------------------------
>
> Key: JBIDE-15250
> URL: https://issues.jboss.org/browse/JBIDE-15250
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: server
> Affects Versions: 4.0.1.Final
> Reporter: Kevin Formsma
>
> For larger projects that utilize utility jars within the EAR, it would be nice to have these deployed exploded as well. This would allow hot code replacement for those utility projects.
> A current work around is to make the utility projects modules so that the tooling treats them as a EJB module and deploys them exploded.
--
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
12 years, 8 months
[JBoss JIRA] (JBDS-2727) Cheatsheets for JBoss Central archetypes
by Snjezana Peco (JIRA)
[ https://issues.jboss.org/browse/JBDS-2727?page=com.atlassian.jira.plugin.... ]
Snjezana Peco commented on JBDS-2727:
-------------------------------------
Seems to be good.
> Cheatsheets for JBoss Central archetypes
> ----------------------------------------
>
> Key: JBDS-2727
> URL: https://issues.jboss.org/browse/JBDS-2727
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: central, requirements
> Reporter: Burr Sutter
> Assignee: Fred Bricon
> Attachments: CHEATSHEET-CONTRIBUTING.html, CHEATSHEET-CONTRIBUTING.md
>
>
> Our archetypes should have cheatsheets when imported/opened into eclipse.
> Priority
> 1) HTML5 - cheatsheet should focus the end-user's attention on index.html, editable in the VPE, with the jQuery Mobile Palette, it should also describe LiveReload setup and BrowserSim
> 2) Java EE Web - cheatsheet should focus the end-user's attention on index.xhtml, editable in the VPE, with the JSF/RichFaces Palette. It should describe the JPA Member.java, the relationship between MemberController.java and index.xhtml, the purpose of MemberResourceRESTService.java and JaxRsActivator.java
> Basically walk the user through the flow of events (from the UI to the backend) in the application
> 3) RichFaces - cheatsheet should focus the end-user's attention on index.xhtml, editable in the VPE, with the JSF/RichFaces Palette. It should also describe resources/components/memberForm.xhtml and its use of <rich:validator/> and that tag's relationship with the JPA beanvalidations
--
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
12 years, 8 months