[JBoss JIRA] (JBDS-2792) Support Multiple Cordova Runtime versions
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBDS-2792?page=com.atlassian.jira.plugin.... ]
Max Rydahl Andersen updated JBDS-2792:
--------------------------------------
Fix Version/s: (was: 7.1.0.Alpha2)
> Support Multiple Cordova Runtime versions
> -----------------------------------------
>
> Key: JBDS-2792
> URL: https://issues.jboss.org/browse/JBDS-2792
> Project: Developer Studio (JBoss Developer Studio)
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: aerogear-hybrid
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
>
> Since cordova releases every month it is unreasonable for one tool to "force" a specific runtime version.
> Currently aerogear-hybrid tooling bundles one specific version of Cordova and there is no option for users to change that.
> Meaning:
> A) They can only export projects with the runtime we bundle
> B) They cannot try out using another version with our tools.
--
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, 6 months
[JBoss JIRA] (JBDS-2792) Support Multiple Cordova Runtime versions
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBDS-2792:
-----------------------------------------
Summary: Support Multiple Cordova Runtime versions
Key: JBDS-2792
URL: https://issues.jboss.org/browse/JBDS-2792
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: aerogear-hybrid
Reporter: Max Rydahl Andersen
Assignee: Max Rydahl Andersen
Since cordova releases every month it is unreasonable for one tool to "force" a specific runtime version.
Currently aerogear-hybrid tooling bundles one specific version of Cordova and there is no option for users to change that.
Meaning:
A) They can only export projects with the runtime we bundle
B) They cannot try out using another version with our tools.
--
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, 6 months
[JBoss JIRA] (JBDS-2791) Support Cordova plugins
by Max Rydahl Andersen (JIRA)
Max Rydahl Andersen created JBDS-2791:
-----------------------------------------
Summary: Support Cordova plugins
Key: JBDS-2791
URL: https://issues.jboss.org/browse/JBDS-2791
Project: Developer Studio (JBoss Developer Studio)
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: aerogear-hybrid
Reporter: Max Rydahl Andersen
Assignee: Max Rydahl Andersen
Fix For: 7.1.0.Beta1
To support Cordova 3.0 our tools need to understand cordova plugins.
JBIDE-13647 implements support for Cordova Plugins.
--
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, 6 months
[JBoss JIRA] (JBIDE-15606) build tool to regenerate component update sites from published JBT aggregate
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15606?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15606:
------------------------------------
[~maxandersen], please read the README:
https://github.com/jbosstools/jbosstools-build-sites/tree/jbosstools-4.1....
Then, look at the usage example here:
https://github.com/jbosstools/jbosstools-build-sites/blob/jbosstools-4.1....
Then, look at the job configuration here:
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/jbosstools-component...
Due to a limitation in the way Maven works, the job is actually more efficient than the offline pom.xml by itself as it can wget the correct category.xml file BEFORE starting the maven job, rather than using the maven job to fetch the file. So, this isn't a very clean solution for offline use (you have to run the maven build twice locally, or once in Jenkins), but for the temporary fix we need to collect the individual component sites, it's sufficient.
After we release 4.1.1, *we should release ALL the component sites* - I agree with you that that's better, though it's potentially more work than is needed. By doing so, we can cherry-pick which released components to include in the composite site (and therefore the aggregate site), vs. including new CI builds for components that have changed or will change for the JBT 4.2.0 release.
(We already do this in part for JBT 4.1.1 for XulRunner, GWT, and Freemarker - http://download.jboss.org/jbosstools/builds/staging/_composite_/core/4.1.... - I'll be adding BIRT, Hibernate Tools, and Portlet soon.)
> build tool to regenerate component update sites from published JBT aggregate
> ----------------------------------------------------------------------------
>
> Key: JBIDE-15606
> URL: https://issues.jboss.org/browse/JBIDE-15606
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.1.1.Alpha2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Beta1
>
>
> When we released JBT 4.1.0.Final, we didn't publish the individual projects as sites themselves, so now when we're trying to aggregate JBT 4.1.1.Alpha2 using a combination of unchanged older projects + changed newer projects, we're unable to do so.
> We could rebuild the projects from source, but it would be better to simply re-aggregate the binaries in order to produce subset sites which match the content of the released JBT site, but only for those individual projects.
> This would allow us to swap in/out projects like GWT, Freemarker, Birt, Hibernate and Portal, which haven't changed yet since JBT 4.1.0.Final was released.
--
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, 6 months
[JBoss JIRA] (JBIDE-15606) build tool to regenerate component update sites from published JBT aggregate
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15606?page=com.atlassian.jira.plugi... ]
Nick Boldt edited comment on JBIDE-15606 at 10/8/13 12:15 PM:
--------------------------------------------------------------
About knowing which features will change/stay - that is impossible to know.
Base stayed stable in this lastest -4.1.1.1- 4.1.0.1 release.
In a next update Base might be the only thing that needs an update - and the rest on top does not/should not need rebuilding just because it has an update/bugfix.
Thus I'm not following why you would not want to simply keep each released site.
was (Author: maxandersen):
About knowing which features will change/stay - that is impossible to know.
Base stayed stable in this lastest 4.1.1.1 release.
In a next update Base might be the only thing that needs an update - and the rest on top does not/should not need rebuilding just because it has an update/bugfix.
Thus I'm not following why you would not want to simply keep each released site.
> build tool to regenerate component update sites from published JBT aggregate
> ----------------------------------------------------------------------------
>
> Key: JBIDE-15606
> URL: https://issues.jboss.org/browse/JBIDE-15606
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.1.1.Alpha2
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Beta1
>
>
> When we released JBT 4.1.0.Final, we didn't publish the individual projects as sites themselves, so now when we're trying to aggregate JBT 4.1.1.Alpha2 using a combination of unchanged older projects + changed newer projects, we're unable to do so.
> We could rebuild the projects from source, but it would be better to simply re-aggregate the binaries in order to produce subset sites which match the content of the released JBT site, but only for those individual projects.
> This would allow us to swap in/out projects like GWT, Freemarker, Birt, Hibernate and Portal, which haven't changed yet since JBT 4.1.0.Final was released.
--
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, 6 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 Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-15482?page=com.atlassian.jira.plugi... ]
Nick Boldt commented on JBIDE-15482:
------------------------------------
No, because the staging.previous stuff gets purged periodically.
> 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
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.1.1.Alpha2
>
>
> 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 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, 6 months