[JBoss JIRA] (TOOLSDOC-540) typos: "ever" and "though"
by Supriya Bharadwaj (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-540?page=com.atlassian.jira.plug... ]
Supriya Bharadwaj updated TOOLSDOC-540:
---------------------------------------
Summary: typos: "ever" and "though" (was: typo: "ever"; instaed must read "every" in introductory paragraph of the Install JBoss Developer Studio by Script section.)
Description:
Title: Install JBoss Developer Studio by Script and Build the Universal Installer from Source
Describe the issue:
1) typo: "ever"; instead must read "every" in introductory paragraph of the Install JBoss Developer Studio by Script section.
2) Type: "though"; instead must read "through" in introductory paragraph of the Build the Universal Installer from Source section
Suggestions for improvement:
Additional information:
was:
Title: Install JBoss Developer Studio by Script
Describe the issue:
Suggestions for improvement:
Additional information:
Priority: Minor (was: Blocker)
> typos: "ever" and "though"
> --------------------------
>
> Key: TOOLSDOC-540
> URL: https://issues.jboss.org/browse/TOOLSDOC-540
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Bug
> Components: Installation Guide
> Environment: Build Name: 22435, Installation Guide-7.1
> Build Date: 13-03-2014 22:18:13
> Topic ID: 22679-567796 [Specified]
> Reporter: Supriya Bharadwaj
> Assignee: Michelle Murray
> Priority: Minor
>
> Title: Install JBoss Developer Studio by Script and Build the Universal Installer from Source
> Describe the issue:
> 1) typo: "ever"; instead must read "every" in introductory paragraph of the Install JBoss Developer Studio by Script section.
> 2) Type: "though"; instead must read "through" in introductory paragraph of the Build the Universal Installer from Source section
> Suggestions for improvement:
> Additional information:
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JBTIS-318) Generate source bundles for IS component features.
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/JBTIS-318?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated JBTIS-318:
------------------------------------------
Bugzilla Update: Perform
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1150805
> Generate source bundles for IS component features.
> --------------------------------------------------
>
> Key: JBTIS-318
> URL: https://issues.jboss.org/browse/JBTIS-318
> Project: JBoss Tools Integration Stack
> Issue Type: Sub-task
> Components: drools/ jBPM
> Affects Versions: 8.0.0.Alpha1, 4.2.0.Alpha1
> Reporter: Paul Leacu
> Assignee: Kris Verlaenen
>
> jBPM/ Drools must generate source bundles for features that will be aggregated (uncategorized) by JBDSIS.
> Courtesy [~nickboldt]:
> How to make maven/tycho build source bundles and features:
> In the upstream projects:
> http://wiki.eclipse.org/Minerva#Source
> Then in the aggregator for JBTIS/JBSIS update site:
> https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat...
> As a result, users can install sources from within JBDS rather than
> needing a separate source zip with .java files. Way more useful, if
> you're a java developer using JBDS/Eclipse.
> If you also want to produce a zip of *actual source files* as pulled
> from github, I have a script for that, too.
> See:
> 1. https://github.com/jbdevstudio/jbdevstudio-product/tree/master/sources
> Produces a zip of the contents of the JBDS product build, so people can
> build it offline. Does NOT include upstream sources.
> Result:
> http://www.qa.jboss.com/binaries/RHDS/builds/staging/devstudio.product_ma...
> (2.4M)
> 2.
> https://github.com/jbosstools/jbosstools-build-ci/blob/master/publish/pub...
> Produces a zip of upstream sources based on upstream project zips. This
> is the old approach, since pulling a previously-built zip doesn't 100%
> guarantee you're getting the correct version AND it requires that the
> upstream project produce a source zip.
> -OR-
> https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat...
> Fetches sources directly from github based on the source-reference in
> the specified plugins' manifest.mf files, then collates those sources
> into a single zip.
> Results:
> http://download.jboss.org/jbosstools/builds/nightly/core/master/latest/al...
> (35M)
> Ref:
> (10:02:47 AM) maxandersen: pleacu: for core we've just been providing source bundles for the plugins we provide.
> (10:03:55 AM) pleacu: maxandersen, nboldt: sure - and they use tycho to generate them, correct?
> (10:04:21 AM) maxandersen: pleacu: yes - jboss tools parent pom somewhat "enforces" it.
> (10:05:04 AM) pleacu: maxandersen: ok - I'll look at fuse tooling first since I'm most familiar with that
> (10:05:12 AM) maxandersen: pleacu: and nboldt / mistria explicltily aggregates it in uncategorized so it wont show up in default experience.
> (10:06:43 AM) nboldt: pleacu: fuse tooling doesn't do source bundles
> (10:07:07 AM) nboldt: pleacu: see my email in re: "Where can our customer download source code for jbdevstudio-integration-stack-updatesite-7.0.2.GA.zip?" with details about who does and does not yet produce sources
> (10:08:20 AM) nboldt: maxandersen: actually, we don't "aggregate it in uncategorized" because that implies we're specifically putting into a category called "uncategorized"
> (10:08:43 AM) nboldt: maxandersen: rather, it's just added to the category.xml w/o setting <category>: https://github.com/jbosstools/jbosstools-build-sites/blob/master/aggregat... (cc: pleacu )
> Components that generate source bundles:
> http://download.jboss.org/jbosstools/updates/integration/kepler/integrati...
> http://download.jboss.org/jbosstools/updates/stable/kepler/integration-st...
> http://download.jboss.org/jbosstools/updates/stable/kepler/integration-st...
> http://download.jboss.org/jbosstools/updates/stable/kepler/integration-st...
> Some that don't:
> http://download.jboss.org/jbosstools/updates/integration/kepler/integrati...
> http://download.jboss.org/jbosstools/updates/integration/kepler/integrati...
> http://download.jboss.org/jbosstools/updates/stable/kepler/integration-st...
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (TOOLSDOC-521) Review JIRA queries in Release Notes
by Michelle Murray (JIRA)
[ https://issues.jboss.org/browse/TOOLSDOC-521?page=com.atlassian.jira.plug... ]
Michelle Murray commented on TOOLSDOC-521:
------------------------------------------
[~ldimaggio] - I don't think so
[~mmalina]:
* affectedVersion - so we only pick up bugs from the last official release and before, users don't need to know about all the bugs we found and fixed during alpha, beta and cr1 development, they need to know about the bugs that existed in the previous 'official' releases and are now fixed; also listing all the bugs we've found and resolved that are labelled 4.2.0.Beta3 doesn't provide the user with info that the bug was also in 4.1 - we would be better thinking about how we fix our jira tagging
* fixVersion not - this is because some bugs have 2 fixed versions, the bugs were fixed for a version already released (like 7.1.1) so the user doesn't need to know about these as in their mind they've already seen the fix in an earlier release - i've looked through the list and cherry-picked the fixversions to exclude
> Review JIRA queries in Release Notes
> ------------------------------------
>
> Key: TOOLSDOC-521
> URL: https://issues.jboss.org/browse/TOOLSDOC-521
> Project: Documentation for JBoss Tools and Developer Studio
> Issue Type: Task
> Components: Release Notes
> Affects Versions: 4.2.0.CR1
> Reporter: Martin Malina
> Assignee: Michelle Murray
> Fix For: 4.2.0.Final
>
>
> When reviewing RNs for JBDS 8.0.0.CR1, we came to the conclusion that the JIRA queries may need updating.
> For reference, here's is discussion between me and Michelle on the subject:
> {quote}
> 01:23 mmalina: mmurray: I have a question about RN - resolved issues: (project in (JBDS) AND affectedVersion < "8.0.0.CR1" AND fixVersion in ("8.0.0.CR1") OR project in (JBIDE) AND affectedVersion < "4.2.0.CR1" AND fixVersion in ("4.2.0.CR1")) AND type in (Bug) AND resolution in (Done)
> 01:24 mmalina: mmurray: why have the fixVersion there? any special reason?
> 01:24 mmalina: mmurray: because it's 130 issues vs. 200 without it
> 01:24 maxandersen: don't use the < > comparisons. they unforatunely dont work reliably ;/
> 01:26 mmalina: maxandersen: the problem here is there are many jiras without affectedVersion
> 01:26 mmalina: *the main problem
> 01:26 mmalina: + what you say
> 01:27 maxandersen: mmalina: ah yeah. historically affectedVersion is only rarely used.
> 01:27 maxandersen: mmalina: only when we got very scifci issues where its important.
> 01:30 mmalina: mmurray: my only guess why you have it there is that you wanted to avoid jiras found in CR1 and fixed in CR1 - the thinking being that these would be new in CR1 and not present previously, thus you shouldn't list them in "what's fixed since the previous release". but that reasoning doesn't really work - 90 % bugs found in CR1 were already there before previously ;) any other reason to have it there?
> {quote}
> Michelle wrote:
> {quote}
> The search query is a best effort.
> The affects version is as you said, to avoid picking up internally identified bugs from QE/team testing CR1respinA that were fixed in CR1respinB, say. The customer doesn't need to know or care about these.
> The fixed version is a bit more complicated. The problem is that this query goes into the doc and the search results effectively have to remain static for all time - the doc could be hosted for years to come. This CR1 RNs doc should only list the bugs fixed in the CR1 release. If I leave the fixversion out then when bugs identified in <8.0.0.CR1 get resolved for CR2 or GA or even 9.1.0 they will show up in this query and that screws up the doc. The CR1 RNs doc we get replaced with a GA version so it isn't so important for this one but it is for the GA copy and it's easier to keep basically the same query as I iterate the doc towards GA.
> Regards using < and >, they are working effectively from what I can see. To make the comparisons work it just needs the versions to be listed in chronological order on the JBIDE and JBDS jira project pages.
> {quote}
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JBIDE-18547) Generate index.html in default Dynamic Web Project
by Arun Gupta (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18547?page=com.atlassian.jira.plugi... ]
Arun Gupta commented on JBIDE-18547:
------------------------------------
This is a classic catch 22 :)
I see JBoss Tools hiding complexities/redundancies introduced by Eclipse until they are solved in the base IDE.
> Generate index.html in default Dynamic Web Project
> --------------------------------------------------
>
> Key: JBIDE-18547
> URL: https://issues.jboss.org/browse/JBIDE-18547
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: upstream
> Reporter: Arun Gupta
> Assignee: Alexey Kazakov
> Fix For: 4.3.x
>
> Attachments: screenshot-1.png
>
>
> Default Dynamic Web Project does not contain index.html and so running it on a server always require to generate this file first. That's a very typical scenario and should be fixed for a more seamless experience.
> Accessing the application at http://localhost:8080/helloworld/ shows "Forbidden" as shown in the attachment.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months
[JBoss JIRA] (JBIDE-18547) Generate index.html in default Dynamic Web Project
by Alexey Kazakov (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18547?page=com.atlassian.jira.plugi... ]
Alexey Kazakov edited comment on JBIDE-18547 at 10/8/14 7:25 PM:
-----------------------------------------------------------------
We could register a facet listener for the Web facet and generate an index.html file when the project is being created. But I'm not sure that's a good solution to generate index.html silently. It's would be better if the web facet page of the wizard contains a checkbox which will tell the facet to generate this index.html file. We can't add such a page into Web facet page but we can create a patch for Eclipse Web Tools if we want to have it fixed in the foreseeable future ;)
But it also will affect our own wizards (New CDI, JSF, Seam projects) which extend the Dynamic Web Project wizard because they generate index.html too.
was (Author: akazakov):
We could register a facet listener for the Web facet and generate an index.html file when the project is being created. But I'm not sure that's a good solution to generate index.html silently. It's would be better if the web facet page of the wizard should contain a checkbox which will tell the facet to generate this index.html file. We can't add such a page into Web facet page but we can create a patch for Eclipse Web Tools if we want to have it fixed in the foreseeable future ;)
But it also will affect our own Wizards (New CDI, JSF, Seam projects) which extends the Dynamic Web Project wizard because they generate index.html.
> Generate index.html in default Dynamic Web Project
> --------------------------------------------------
>
> Key: JBIDE-18547
> URL: https://issues.jboss.org/browse/JBIDE-18547
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: upstream
> Reporter: Arun Gupta
> Fix For: 4.3.x
>
> Attachments: screenshot-1.png
>
>
> Default Dynamic Web Project does not contain index.html and so running it on a server always require to generate this file first. That's a very typical scenario and should be fixed for a more seamless experience.
> Accessing the application at http://localhost:8080/helloworld/ shows "Forbidden" as shown in the attachment.
--
This message was sent by Atlassian JIRA
(v6.3.1#6329)
11 years, 8 months