[JBoss JIRA] (JBIDE-18678) Make dependencies to org.jboss.tools.usage optional
by Ilya Buziuk (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18678?page=com.atlassian.jira.plugi... ]
Ilya Buziuk commented on JBIDE-18678:
-------------------------------------
BrowserSim / CordovaSim work fine against this PR
+ 1 to apply
> Make dependencies to org.jboss.tools.usage optional
> ---------------------------------------------------
>
> Key: JBIDE-18678
> URL: https://issues.jboss.org/browse/JBIDE-18678
> Project: Tools (JBoss Tools)
> Issue Type: Enhancement
> Components: browsersim, usage
> Affects Versions: 4.2.0.CR1
> Reporter: Kaloyan Raev
> Assignee: Alexey Kazakov
> Fix For: 4.3.x
>
>
> I am interested in adopting the CordovaSim feature in our product. However, most of the browsersim bundles have a strong dependency to org.jboss.tools.usage bundle, which force a Usage Reporting popup on startup. I want to avoid this and have the org.jboss.tools.usage excluded from my build.
> Is it possible to make the dependencies to org.jboss.tools.usage optional?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (JBIDE-18985) provide tool to audit BUILD_ALIAS in aggregate builds
by Nick Boldt (JIRA)
Nick Boldt created JBIDE-18985:
----------------------------------
Summary: provide tool to audit BUILD_ALIAS in aggregate builds
Key: JBIDE-18985
URL: https://issues.jboss.org/browse/JBIDE-18985
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: build, updatesite
Affects Versions: 4.3.0.Alpha1
Reporter: Nick Boldt
Based on discussion {quote}Do you have a test for "expected BUILD_ALIAS value in feature qualifiers" ?{quote}
Some tests we can run (forgive this pseudocode):
{code}
// for builds up to a x.y.0 release
if ((BUILD_ALIAS in (Alpha*, Beta*, CR*) and jbosstools.version endsWith(".0")) {
// make sure all features end in the same BUILD_ALIAS, or Final
// if anything doesn't match WARN (want a build to be yellow, not red)
}
{code}
{code}
// for GA builds and followup maintenance
if ((BUILD_ALIAS in (Final, GA)) {
// make sure all com.* features end in GA, and all others end in Final
// if anything doesn't match FAIL (want a build to be red)
}
{code}
Once we have that coded, perhaps into a maven enforcer plugin?, we can fine tune it for cases like where Freemarker does an update in Alpha and then does nothing for 4 months, waiting for CR/GA.
Should they have to keep updating their root pom just so the BUILD_ALIAS matches and they're building against the correct target platform?
Or, should their code remain dormant, but their job's config.xml be updated to override the BUILD_ALIAS & TARGET_PLATFORM values to the correct versions?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months
[JBoss JIRA] (JBIDE-18985) provide tool to audit BUILD_ALIAS in feature qualifiers when aggregated
by Nick Boldt (JIRA)
[ https://issues.jboss.org/browse/JBIDE-18985?page=com.atlassian.jira.plugi... ]
Nick Boldt updated JBIDE-18985:
-------------------------------
Summary: provide tool to audit BUILD_ALIAS in feature qualifiers when aggregated (was: provide tool to audit BUILD_ALIAS in aggregate builds)
> provide tool to audit BUILD_ALIAS in feature qualifiers when aggregated
> -----------------------------------------------------------------------
>
> Key: JBIDE-18985
> URL: https://issues.jboss.org/browse/JBIDE-18985
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: build, updatesite
> Affects Versions: 4.3.0.Alpha1
> Reporter: Nick Boldt
>
> Based on discussion {quote}Do you have a test for "expected BUILD_ALIAS value in feature qualifiers" ?{quote}
> Some tests we can run (forgive this pseudocode):
> {code}
> // for builds up to a x.y.0 release
> if ((BUILD_ALIAS in (Alpha*, Beta*, CR*) and jbosstools.version endsWith(".0")) {
> // make sure all features end in the same BUILD_ALIAS, or Final
> // if anything doesn't match WARN (want a build to be yellow, not red)
> }
> {code}
> {code}
> // for GA builds and followup maintenance
> if ((BUILD_ALIAS in (Final, GA)) {
> // make sure all com.* features end in GA, and all others end in Final
> // if anything doesn't match FAIL (want a build to be red)
> }
> {code}
> Once we have that coded, perhaps into a maven enforcer plugin?, we can fine tune it for cases like where Freemarker does an update in Alpha and then does nothing for 4 months, waiting for CR/GA.
> Should they have to keep updating their root pom just so the BUILD_ALIAS matches and they're building against the correct target platform?
> Or, should their code remain dormant, but their job's config.xml be updated to override the BUILD_ALIAS & TARGET_PLATFORM values to the correct versions?
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years, 10 months