[JBoss JIRA] (JBIDE-16303) Maven Pop-up should enable/expose mvn clean package
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16303?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen updated JBIDE-16303:
----------------------------------------
Attachment: mavenclean.png
Maven Clean is available where all the other "run as.. " Maven actions are.
Under Runs As...
Update Project should not do a clean since it would be nuking everything which would just slow things down.
> Maven Pop-up should enable/expose mvn clean package
> ---------------------------------------------------
>
> Key: JBIDE-16303
> URL: https://issues.jboss.org/browse/JBIDE-16303
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven
> Reporter: Jim Tyrrell
> Assignee: Fred Bricon
> Attachments: mavenclean.png, Screen shot 2013-12-13 at 6.16.55 AM.png
>
>
> When building and importing projects, every so often something goes sideways in the import/building of a project. I have to jump to the mvn command line and often I need to run mvn clean package to execute a "build" that re-sets whatever went sideways. Generally if the network goes away the above command will enable it to work.
> If you know of other commands that should be exposed please let me know.
> I wonder if Update Project should execute this command? I don't know enough about maven to know if this makes sense.
--
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, 5 months
[JBoss JIRA] (JBIDE-16303) Maven Pop-up should enable/expose mvn clean package
by Burr Sutter (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16303?page=com.atlassian.jira.plugi... ]
Burr Sutter updated JBIDE-16303:
--------------------------------
Assignee: Fred Bricon
> Maven Pop-up should enable/expose mvn clean package
> ---------------------------------------------------
>
> Key: JBIDE-16303
> URL: https://issues.jboss.org/browse/JBIDE-16303
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: maven
> Reporter: Jim Tyrrell
> Assignee: Fred Bricon
> Attachments: Screen shot 2013-12-13 at 6.16.55 AM.png
>
>
> When building and importing projects, every so often something goes sideways in the import/building of a project. I have to jump to the mvn command line and often I need to run mvn clean package to execute a "build" that re-sets whatever went sideways. Generally if the network goes away the above command will enable it to work.
> If you know of other commands that should be exposed please let me know.
> I wonder if Update Project should execute this command? I don't know enough about maven to know if this makes sense.
--
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, 5 months
[JBoss JIRA] (JBIDE-14744) Allow users to choose from quickstarts/templates when creatingApplication wizard: new application
by Andre Dietisheim (JIRA)
[ https://issues.jboss.org/browse/JBIDE-14744?page=com.atlassian.jira.plugi... ]
Andre Dietisheim updated JBIDE-14744:
-------------------------------------
Fix Version/s: 4.2.0.Beta1
(was: LATER)
> Allow users to choose from quickstarts/templates when creatingApplication wizard: new application
> -------------------------------------------------------------------------------------------------
>
> Key: JBIDE-14744
> URL: https://issues.jboss.org/browse/JBIDE-14744
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: openshift
> Affects Versions: 4.1.0.Beta2
> Reporter: Andre Dietisheim
> Labels: application_wizard
> Fix For: 4.2.0.Beta1
>
> Attachments: 2014-01-22 17.16.bmml, 2014-01-22 17.16.bmml, 2014-01-22 17.16.bmml, 2014-01-22 17.16.bmml, 2014-01-22 17.16.bmml, 2014-01-22 17.16.bmml, 2014-01-22 17.16.png, openshift-quickstart.png
>
>
> The web ui offers a large set of quickstarts/templates:
> !openshift-quickstart.png!
> in a mail from clayton on the 4th of june:
> {quote}
> For QuickStarts, brokers may choose to
> a) enable community quickstarts
> (the URL you saw below, set by COMMUNITY_QUICKSTART_URL being a URL in /etc/openshift/broker.conf)
> b) enable their own list of quickstarts
> (a different url, /broker/rest/quickstarts, configured from /etc/openshift/quickstarts.json)
> c) disable the quickstarts link
> (delete /etc/openshift/quickstarts.json)
> To correctly fetch the quickstarts for a server, retrieve the API document
> /broker/rest/api
> and look for the LIST_QUICKSTARTS link. If it is present, you may retrieve quickstarts. If it is absent, you should assume there are no quickstarts.
> Retrieving the list of quickstarts, unlike other REST API feed calls, is very specific:
> * API versioning is not supported
> * Only JSON is supported
> * The body of the response is slightly different than standard REST API feed results
> * If you encounter a parse error or an unexpected data value you are required to handle it gracefully by omitting the entry - the API may change without warning (although hopefully not)
> The format of the JSON response (in either a) or b) above) is:
> {quote}
> {code}
> {
> data: [
> quickstart: {
> id: "<string id>",
> href: "<absolute URL to a display URL for the quickstart>",
> name: "<name>",
> updated: "<last update date in seconds from the epoch>",
> summary: "<brief HTML body of the item>",
> body: "<full HTML body of the item>",
> cartridges: "<cartridge spec>",
> website: "<URL of metadata about the source of the quickstart or the technology>",
> tags: "<comma delimited list of tags>",
> language: "<display name of the type of quickstart>",
> initial_git_url: "<absolute URL or Git reference to source>",
> provider: "openshift|reviewed|partner|community", # default is community
> },
> ]
> }
> {code}
> {quote}
> You should assume that arbitrary content could be injected into any of these fields and defend yourself against XSS appropriately. You should also assume that the structure could be changed at any time.
> Cartridge spec:
> The cartridge spec is defined as either:
> a) a comma delimited list of cartridge name search conditions
> b) a string containing a JSON array
> If the leading character of the cartridge spec is '[', you must convert the cartridge spec to JSON and submit the value provided to the server on creation as the "cartridges" field.
> Otherwise,
> 1) split the string by "," into "segments"
> 2) trim whitespace from each segment
> 3) split each segment by "|" into "matches" - these represent logical ORs
> 4) strip leading and trailing "*" characters
> 5) For each segment, return all cartridges that have a case-insensitive substring match on any of the "matches" in that segment for the user to select.
> See https://github.com/openshift/origin-server/blob/77e1d3a6476ecb9dad5be6dea...
> and https://github.com/openshift/origin-server/blob/77e1d3a6476ecb9dad5be6dea...
> {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, 5 months
[JBoss JIRA] (JBIDE-16220) create an all-in-one build for JBT projects, using submodules
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16220?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16220:
----------------------------------------
> btw. unit tests cannot catch api issues if they are constantly built against the latest and just updated to work.
They don't catch up API versioning issues, but they do catch up breaking changes. ie if API change in a non-backward compatible way, we can expect a test to fail with a NoSuchMethodError or a NoClassDefFound.
> create an all-in-one build for JBT projects, using submodules
> -------------------------------------------------------------
>
> Key: JBIDE-16220
> URL: https://issues.jboss.org/browse/JBIDE-16220
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.2.x
>
> Attachments: buildlog_maven311.txt
>
>
> Git 1.8.2 includes an option to have submodules track a branch tip, rather than specific commit IDs.
> {code:title=https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186-L188}
> "git submodule" started learning a new mode to integrate with the
> tip of the remote branch (as opposed to integrating with the commit
> recorded in the superproject's gitlink).
> {code}
> Therefore, while the solution [~dgolovin] has for his https://github.com/dgolovin/jbosstools-submodules project is a decent option, it requires updating to stay current with branch tips. It's therefore only really as useful as it stays current.
> If we can get Git 1.8.2 or newer installed on the Jenkins slaves, we could do a submodule build against whatever branch we wanted - master, 4.2.0.Alpha1x, etc.
--
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, 5 months
[JBoss JIRA] (JBIDE-16220) create an all-in-one build for JBT projects, using submodules
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16220?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-16220:
---------------------------------------------
[~mickael_istria] I would still use the modular builds for each project - its just the integration build I would use this repo. It would still build each component independently and then aggregate at the end.
> create an all-in-one build for JBT projects, using submodules
> -------------------------------------------------------------
>
> Key: JBIDE-16220
> URL: https://issues.jboss.org/browse/JBIDE-16220
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.2.x
>
> Attachments: buildlog_maven311.txt
>
>
> Git 1.8.2 includes an option to have submodules track a branch tip, rather than specific commit IDs.
> {code:title=https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186-L188}
> "git submodule" started learning a new mode to integrate with the
> tip of the remote branch (as opposed to integrating with the commit
> recorded in the superproject's gitlink).
> {code}
> Therefore, while the solution [~dgolovin] has for his https://github.com/dgolovin/jbosstools-submodules project is a decent option, it requires updating to stay current with branch tips. It's therefore only really as useful as it stays current.
> If we can get Git 1.8.2 or newer installed on the Jenkins slaves, we could do a submodule build against whatever branch we wanted - master, 4.2.0.Alpha1x, etc.
--
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, 5 months
[JBoss JIRA] (JBIDE-16220) create an all-in-one build for JBT projects, using submodules
by Max Rydahl Andersen (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16220?page=com.atlassian.jira.plugi... ]
Max Rydahl Andersen commented on JBIDE-16220:
---------------------------------------------
btw. unit tests cannot catch api issues if they are constantly built against the latest and just updated to work.
> create an all-in-one build for JBT projects, using submodules
> -------------------------------------------------------------
>
> Key: JBIDE-16220
> URL: https://issues.jboss.org/browse/JBIDE-16220
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.2.x
>
> Attachments: buildlog_maven311.txt
>
>
> Git 1.8.2 includes an option to have submodules track a branch tip, rather than specific commit IDs.
> {code:title=https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186-L188}
> "git submodule" started learning a new mode to integrate with the
> tip of the remote branch (as opposed to integrating with the commit
> recorded in the superproject's gitlink).
> {code}
> Therefore, while the solution [~dgolovin] has for his https://github.com/dgolovin/jbosstools-submodules project is a decent option, it requires updating to stay current with branch tips. It's therefore only really as useful as it stays current.
> If we can get Git 1.8.2 or newer installed on the Jenkins slaves, we could do a submodule build against whatever branch we wanted - master, 4.2.0.Alpha1x, etc.
--
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, 5 months
[JBoss JIRA] (JBIDE-16393) Fix/recover for bad usage of submodules in VPE
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16393?page=com.atlassian.jira.plugi... ]
Ilya Buziuk commented on JBIDE-16393:
-------------------------------------
{quote}
I want to know where these git repos are forked from. Show original repos please
{quote}
ripple-temp is not actually forked. We have build https://github.com/apache/incubator-ripple and made a lot of changes for cordovasim. When I created a PR for ripple I did all changes manually. In terms of inspector-front-end. It's *front_end* folder from https://chromium.googlesource.com/chromium/blink
{quote}
C /D - lets just wait do this before we are sure submodules are proper here
{quote}
Actually, we had original source, licence info in the about.html in the org.jboss.tools.vpe.cordovasim.ripple plugin (the submodule directory)
{quote}
F - with submodules you can't fork easily. Why are these not just done as proper maven projects we can depend on and integrate without using git submodules
{quote}
I didn't know about F. So, I guees maven projects is something that should be done for 4.2.0.Alpha2. Probably for 4.1.2.Final we can make a hot fix - just remove ripple-temp submodule and push appropriate files directly from ripple-temp to org.jboss.tools.vpe.cordovasim.ripple. If that sounds right I can make a PR
> Fix/recover for bad usage of submodules in VPE
> ----------------------------------------------
>
> Key: JBIDE-16393
> URL: https://issues.jboss.org/browse/JBIDE-16393
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: browsersim, visual-page-editor-core
> Affects Versions: 4.1.1.Final, 4.2.0.Alpha1
> Reporter: Max Rydahl Andersen
> Assignee: Ilya Buziuk
> Priority: Critical
> Fix For: 4.1.2.Final, 4.2.0.Alpha2
>
>
> both master and branch of vpe is using submodules
> https://github.com/jbosstools/jbosstools-vpe/blob/master/.gitmodules
> https://github.com/jbosstools/jbosstools-vpe/blob/jbosstools-4.1.x/.gitmo...
> Things wrong:
> A) These are pointing to personal repos
> B) No tags used
> C) readme.adoc not documenting it
> D) not announced anywhere
> E) git clone no longer sufficient
> We need to get this fixed/cleaned up in both branch and master.
> *jbosstools-4.1.1.Final* - e498c091f79c140 ( JBIDE-15814 CordovaSim: Adding navigator.app.backHistory support )
--
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, 5 months
[JBoss JIRA] (JBIDE-16220) create an all-in-one build for JBT projects, using submodules
by Mickael Istria (JIRA)
[ https://issues.jboss.org/browse/JBIDE-16220?page=com.atlassian.jira.plugi... ]
Mickael Istria commented on JBIDE-16220:
----------------------------------------
There are 2 approaches aggregating Eclipse stuff:
* Having such a repo using submodules to build all at once and creating the output repo. This approach is equivalent to the usage of map files, except that the mapping in stored in git metadata instead of explicit files. It's what is done by Platform build and WTP.
** The bad things:
*** developers don't care about the build because they still believe it is monolithic and don't understand it is modular.
*** Build takes ages, feedback loop is quite long, so people skip tests to save hours, so the quality of the output is very low (no test run is not something really acceptable)
** The good things:
*** You know everything build together so you see API issues as compile error
* Building git repos into p2 repos individually, and consume the output p2 repository to make an aggregate site. That's what we do, and it's also what's used by Eclipse Simultaneous Release.
** The good things:
*** We really act as a consumer and it keeps a better separation of concerns
*** it is more explicitly modular and people understand that they are responsible for the build of there stuff
** The bad things
*** There is more risk of inconsistencies in case of issues MANIFEST.MF (not enough constraints) and bad API practices. However, we can hope that unit-tests are a good way to notice such API changes,
If we can have both, it's nice, we might find some API issues a bit faster. But I definitely prefer the current approach for a production and teamwork POV, and I believe it's more important to have tests we can trust to find API issues as fast as a big build.
> create an all-in-one build for JBT projects, using submodules
> -------------------------------------------------------------
>
> Key: JBIDE-16220
> URL: https://issues.jboss.org/browse/JBIDE-16220
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build
> Affects Versions: 4.2.0.Alpha1
> Reporter: Nick Boldt
> Assignee: Nick Boldt
> Fix For: 4.2.x
>
> Attachments: buildlog_maven311.txt
>
>
> Git 1.8.2 includes an option to have submodules track a branch tip, rather than specific commit IDs.
> {code:title=https://github.com/git/git/blob/master/Documentation/RelNotes/1.8.2.txt#L186-L188}
> "git submodule" started learning a new mode to integrate with the
> tip of the remote branch (as opposed to integrating with the commit
> recorded in the superproject's gitlink).
> {code}
> Therefore, while the solution [~dgolovin] has for his https://github.com/dgolovin/jbosstools-submodules project is a decent option, it requires updating to stay current with branch tips. It's therefore only really as useful as it stays current.
> If we can get Git 1.8.2 or newer installed on the Jenkins slaves, we could do a submodule build against whatever branch we wanted - master, 4.2.0.Alpha1x, etc.
--
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, 5 months