[JBoss JIRA] (JBIDE-9356) NLS.bind vs MessageFormat.format
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-9356?page=com.atlassian.jira.plugin... ]
Jeff MAURY closed JBIDE-9356.
-----------------------------
Resolution: Rejected
> NLS.bind vs MessageFormat.format
> --------------------------------
>
> Key: JBIDE-9356
> URL: https://issues.jboss.org/browse/JBIDE-9356
> Project: Tools (JBoss Tools)
> Issue Type: Task
> Components: cleanup
> Affects Versions: 3.3.0.M3
> Reporter: Rob Stryker
> Assignee: Jeff MAURY
> Fix For: 4.5.0.AM1, 4.0.x
>
>
> A substantial number of classes use NLS.bind(Messages.SomeString, name) to bind message strings. Another subset of the classes use MessageFormat.format(etc).
> I believe NLS.bind() is the correct solution which works properly with eclipse osgi and all that jazz. Should this be standardized? Is it confusing to be using two interchangable APIs?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JBIDE-24642) Please include sha256 checksums in announcements
by Jeff MAURY (JIRA)
[ https://issues.jboss.org/browse/JBIDE-24642?page=com.atlassian.jira.plugi... ]
Jeff MAURY reassigned JBIDE-24642:
----------------------------------
Assignee: Nick Boldt
> Please include sha256 checksums in announcements
> ------------------------------------------------
>
> Key: JBIDE-24642
> URL: https://issues.jboss.org/browse/JBIDE-24642
> Project: Tools (JBoss Tools)
> Issue Type: Feature Request
> Components: build
> Reporter: Jesper Skov
> Assignee: Nick Boldt
> Fix For: LATER
>
>
> I would like to be able to verify checksums on downloaded JBoss artifacts - both EAP and eclipse-related binaries.
> Or even better, verify a signature.
> Today, when I want to use a JBossTools release, I would download
> http://download.jboss.org/jbosstools/static/oxygen/development/updates/co...
> And my only opportunity to verify the file is by downloading the sha256 file that lies next to it:
> http://download.jboss.org/jbosstools/static/oxygen/development/updates/co...
> If a hacker manages to replace the updatesite archive with compromised files, I assume they will have the brains to also update the checksum file next to it.
> So the current checksum can really only be used to verify the integrity of the downloaded file.
> Not that its contents is untampered.
> If the jar-files in the archive were signed, it would be less of an issue...
> Signed artifacts would be best. But would probably take some effort to put in place.
> A simpler remedy would be to include the checksums in the announcement. This would give an additional factor of security for those who care about that.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months
[JBoss JIRA] (JBIDE-24644) Maven dependency resolution through "LATEST" and "RELEASE" version labels using "KieServices.newKieContainer(ReleaseId releaseId)" method fails
by Pyit Phyo Aung (JIRA)
Pyit Phyo Aung created JBIDE-24644:
--------------------------------------
Summary: Maven dependency resolution through "LATEST" and "RELEASE" version labels using "KieServices.newKieContainer(ReleaseId releaseId)" method fails
Key: JBIDE-24644
URL: https://issues.jboss.org/browse/JBIDE-24644
Project: Tools (JBoss Tools)
Issue Type: Bug
Components: drools
Affects Versions: LATER
Environment: OS: macOS Sierra (10.12.5)
Hardware: MacBook Pro (13-inch, 2017)
Reporter: Pyit Phyo Aung
Assignee: Kris Verlaenen
Priority: Minor
I tried to use KieScanner for automatic business rule deployment through kjar modules setup in private maven repository. For that, I tried to specify getting latest kjar modules using "LATEST" and "RELEASE" version labels. They failed for three drools versions I tried (6.5.0.Final, 7.0.0.Final and 7.1.0.Beta3). However, when I tried open-ended version label, solution works. So, I believe that there is issue in dependency resolution related to KieContainer through KieServices.newKieContainer(ReleaseId releaseId) method.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 9 months