[jira] [Created] (JEXL-133) String matching Operator short-hand inspired by CSS3
Alfred Reibenschuh created JEXL-133: --- Summary: String matching Operator short-hand inspired by CSS3 Key: JEXL-133 URL: https://issues.apache.org/jira/browse/JEXL-133 Project: Commons JEXL Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Alfred Reibenschuh Priority: Trivial like the perl inspired shorthand =~, css3 also has some nice shorthands http://www.w3.org/TR/2011/REC-css3-selectors-20110929/#attribute-selectors for startsWith the shorthand could be expr1 ^= expr2 for endsWith the shorthand could be expr1 $= expr2 it could be that the ^= operator already collides with xor and assign which i haven't looked at as of now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (NET-471) Provide NIO SocketFactory Support
[ https://issues.apache.org/jira/browse/NET-471?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403049#comment-13403049 ] Sebb commented on NET-471: -- I'm not sure using NIO will help here. Provide NIO SocketFactory Support - Key: NET-471 URL: https://issues.apache.org/jira/browse/NET-471 Project: Commons Net Issue Type: New Feature Components: FTP Affects Versions: 3.2 Environment: WLan , poor network Reporter: yankay Labels: NIO, SocketManager Fix For: 3.2 When I use ftpclient to push a huge file(1GB) from one city to another. The Thread will block forever.Then I know the default setting use default socketfactory. And the socket.setSoTimeout only works on read but write. The commons-net not provide a NIO SocketFactory. So it's a hard work for me to write one. Can we provide a NIO SocketFactory? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (IMAGING-85) Rename src/test/data directory to src/test/resources to comply with maven conventions
[
https://issues.apache.org/jira/browse/IMAGING-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403075#comment-13403075
]
Farrukh Najmi commented on IMAGING-85:
--
Loading test resources from classpath is not uncommon. Consider the simplicity
of the following code junit test that uses spring framework.
{code}
@Test
public void testGetImageMetadataCommonsImaging() {
InputStream is = null;
try {
PathMatchingResourcePatternResolver resolver = new
PathMatchingResourcePatternResolver();
Resource[] resources =
resolver.getResources(classpath:images/iptc/1/Oregon Scientific DS6639 -
DSC_0307 - iptc added with irfanview.jpg);
Resource res = resources[0];
URL url = res.getURL();
is = url.openStream();
Map params = new HashMap();
JpegImageMetadata metadata = (JpegImageMetadata)
Imaging.getMetadata(is, Oregon Scientific DS6639 - DSC_0307 - iptc added with
irfanview.jpg);
JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
List oldRecords = psMetadata.photoshopApp13Data.getRecords();
for (int j = 0; j oldRecords.size(); j++) {
IptcRecord record = (IptcRecord) oldRecords.get(j);
System.err.println(Key: + record.iptcType.getName() + (0x
+ Integer.toHexString(record.iptcType.getType())
+ ), value: + record.value);
}
} catch (ImageReadException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} finally {
if (null != is) {
try {
is.close();
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
}
}
}
}
{code}
Rename src/test/data directory to src/test/resources to comply with maven
conventions
-
Key: IMAGING-85
URL: https://issues.apache.org/jira/browse/IMAGING-85
Project: Commons Imaging
Issue Type: Improvement
Reporter: Farrukh Najmi
Attachments: SANSELAN-83-patch.txt
Currently established maven convention is not being following because test
resources being placed under src/test/data instead of src/test/resources
directory. This causes problems is maven-jar-plugin and possibly other
situations. Proposed patch for SANSELAN-82 will not work until the proposed
fix for this issues is addressed.
The proposed fix is to rename src/test/data to src/test/resources and apply
the following patch to fix test code that setsup path for test data files:
{code}
Index: src/test/java/org/apache/commons/imaging/ImagingTestConstants.java
===
--- src/test/java/org/apache/commons/imaging/ImagingTestConstants.java
(revision 1354112)
+++ src/test/java/org/apache/commons/imaging/ImagingTestConstants.java
(working copy)
@@ -24,12 +24,12 @@
static final File PHIL_HARVEY_TEST_IMAGE_FOLDER = new File(
FilenameUtils
-
.separatorsToSystem(src\\test\\data\\images\\exif\\philHarvey\\));
+
.separatorsToSystem(src\\test\\resources\\images\\exif\\philHarvey\\));
static final File SOURCE_FOLDER = new File(src);
static final File TEST_SOURCE_FOLDER = new File(SOURCE_FOLDER, test);
static final File TEST_DATA_SOURCE_FOLDER = new File(TEST_SOURCE_FOLDER,
-data);
+resources);
static final File TEST_IMAGE_FOLDER = new File(TEST_DATA_SOURCE_FOLDER,
images);
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (IMAGING-85) Rename src/test/data directory to src/test/resources to comply with maven conventions
[
https://issues.apache.org/jira/browse/IMAGING-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403075#comment-13403075
]
Farrukh Najmi edited comment on IMAGING-85 at 6/28/12 1:02 PM:
---
Loading test resources from classpath is not uncommon. Consider the simplicity
of the following code junit test that uses spring framework.
{code}
@Test
public void testGetImageMetadataCommonsImaging() {
InputStream is = null;
try {
PathMatchingResourcePatternResolver resolver = new
PathMatchingResourcePatternResolver();
Resource[] resources =
resolver.getResources(classpath:images/iptc/1/Oregon Scientific DS6639 -
DSC_0307 - iptc added with irfanview.jpg);
Resource res = resources[0];
URL url = res.getURL();
is = url.openStream();
Map params = new HashMap();
JpegImageMetadata metadata = (JpegImageMetadata)
Imaging.getMetadata(is, Oregon Scientific DS6639 - DSC_0307 - iptc added with
irfanview.jpg);
JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
List oldRecords = psMetadata.photoshopApp13Data.getRecords();
for (int j = 0; j oldRecords.size(); j++) {
IptcRecord record = (IptcRecord) oldRecords.get(j);
System.err.println(Key: + record.iptcType.getName() + (0x
+ Integer.toHexString(record.iptcType.getType())
+ ), value: + record.value);
}
} catch (ImageReadException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} finally {
if (null != is) {
try {
is.close();
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
}
}
}
}
{code}
was (Author: farrukhnajmi):
Loading test resources from classpath is not uncommon. Consider the
simplicity of the following code junit test that uses spring framework.
{code}
@Test
public void testGetImageMetadataCommonsImaging() {
InputStream is = null;
try {
PathMatchingResourcePatternResolver resolver = new
PathMatchingResourcePatternResolver();
Resource[] resources =
resolver.getResources(classpath:images/iptc/1/Oregon Scientific DS6639 -
DSC_0307 - iptc added with irfanview.jpg);
Resource res = resources[0];
URL url = res.getURL();
is = url.openStream();
Map params = new HashMap();
JpegImageMetadata metadata = (JpegImageMetadata)
Imaging.getMetadata(is, Oregon Scientific DS6639 - DSC_0307 - iptc added with
irfanview.jpg);
JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
List oldRecords = psMetadata.photoshopApp13Data.getRecords();
for (int j = 0; j oldRecords.size(); j++) {
IptcRecord record = (IptcRecord) oldRecords.get(j);
System.err.println(Key: + record.iptcType.getName() + (0x
+ Integer.toHexString(record.iptcType.getType())
+ ), value: + record.value);
}
} catch (ImageReadException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} finally {
if (null != is) {
try {
is.close();
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
}
}
}
}
{code}
Rename src/test/data directory to src/test/resources to comply with maven
conventions
-
Key: IMAGING-85
URL: https://issues.apache.org/jira/browse/IMAGING-85
Project: Commons Imaging
Issue Type: Improvement
Reporter: Farrukh Najmi
Attachments: SANSELAN-83-patch.txt
Currently established maven convention is not being following because test
resources being placed under src/test/data instead of src/test/resources
directory. This causes problems is maven-jar-plugin and possibly other
situations. Proposed patch for SANSELAN-82 will not work until the
[jira] [Commented] (IMAGING-84) Generate tests.jar so client projects can leverage test image data easily
[
https://issues.apache.org/jira/browse/IMAGING-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403077#comment-13403077
]
Farrukh Najmi commented on IMAGING-84:
--
Using test data is not always the only reason to have a tests.jar artifact from
a project. Another reason is when a project extends another project then it may
want to also the base project's test classes as part of its own test suite. Do
you see a downside to the project producing a tests.jar artifact?
Also, please see my comment on IMAGING-83 on why I think it is not unusual to
load test data from the classpath in junit tests.
Generate tests.jar so client projects can leverage test image data easily
-
Key: IMAGING-84
URL: https://issues.apache.org/jira/browse/IMAGING-84
Project: Commons Imaging
Issue Type: Improvement
Components: Build
Affects Versions: 0.97
Reporter: Farrukh Najmi
Priority: Minor
Attachments: SANSELAN-82-patch.txt
Client projects of commons-imaging need test image data and commons-imaging
already has a pretty good set.
The simple patch below can be applied to pom.xml to generate
commons-imaging-xxx-tests.jar in addition to commons-imaging-xxx.jar to allow
client projects to leverage the test data.
{code}
Index: pom.xml
===
--- pom.xml (revision 1354112)
+++ pom.xml (working copy)
@@ -89,6 +89,14 @@
/plugin
plugin
artifactIdmaven-jar-plugin/artifactId
+executions
+ execution
+goals
+ goaltest-jar/goal
+/goals
+ /execution
+/executions
+
configuration
archive
manifestEntries
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Comment Edited] (IMAGING-85) Rename src/test/data directory to src/test/resources to comply with maven conventions
[
https://issues.apache.org/jira/browse/IMAGING-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403075#comment-13403075
]
Farrukh Najmi edited comment on IMAGING-85 at 6/28/12 1:27 PM:
---
Loading test resources from classpath is not uncommon. Consider the simplicity
of the following code junit test that uses spring framework.
Feel free to close the issue if you and other dev team members are still -1 on
this.
{code}
@Test
public void testGetImageMetadataCommonsImaging() {
InputStream is = null;
try {
PathMatchingResourcePatternResolver resolver = new
PathMatchingResourcePatternResolver();
Resource[] resources =
resolver.getResources(classpath:images/iptc/1/Oregon Scientific DS6639 -
DSC_0307 - iptc added with irfanview.jpg);
Resource res = resources[0];
URL url = res.getURL();
is = url.openStream();
Map params = new HashMap();
JpegImageMetadata metadata = (JpegImageMetadata)
Imaging.getMetadata(is, Oregon Scientific DS6639 - DSC_0307 - iptc added with
irfanview.jpg);
JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
List oldRecords = psMetadata.photoshopApp13Data.getRecords();
for (int j = 0; j oldRecords.size(); j++) {
IptcRecord record = (IptcRecord) oldRecords.get(j);
System.err.println(Key: + record.iptcType.getName() + (0x
+ Integer.toHexString(record.iptcType.getType())
+ ), value: + record.value);
}
} catch (ImageReadException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} finally {
if (null != is) {
try {
is.close();
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
}
}
}
}
{code}
was (Author: farrukhnajmi):
Loading test resources from classpath is not uncommon. Consider the
simplicity of the following code junit test that uses spring framework.
{code}
@Test
public void testGetImageMetadataCommonsImaging() {
InputStream is = null;
try {
PathMatchingResourcePatternResolver resolver = new
PathMatchingResourcePatternResolver();
Resource[] resources =
resolver.getResources(classpath:images/iptc/1/Oregon Scientific DS6639 -
DSC_0307 - iptc added with irfanview.jpg);
Resource res = resources[0];
URL url = res.getURL();
is = url.openStream();
Map params = new HashMap();
JpegImageMetadata metadata = (JpegImageMetadata)
Imaging.getMetadata(is, Oregon Scientific DS6639 - DSC_0307 - iptc added with
irfanview.jpg);
JpegPhotoshopMetadata psMetadata = metadata.getPhotoshop();
List oldRecords = psMetadata.photoshopApp13Data.getRecords();
for (int j = 0; j oldRecords.size(); j++) {
IptcRecord record = (IptcRecord) oldRecords.get(j);
System.err.println(Key: + record.iptcType.getName() + (0x
+ Integer.toHexString(record.iptcType.getType())
+ ), value: + record.value);
}
} catch (ImageReadException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
} finally {
if (null != is) {
try {
is.close();
} catch (IOException ex) {
Logger.getLogger(ImageCatalogerTest.class.getName()).log(Level.SEVERE, null,
ex);
}
}
}
}
{code}
Rename src/test/data directory to src/test/resources to comply with maven
conventions
-
Key: IMAGING-85
URL: https://issues.apache.org/jira/browse/IMAGING-85
Project: Commons Imaging
Issue Type: Improvement
Reporter: Farrukh Najmi
Attachments: SANSELAN-83-patch.txt
Currently established maven convention is not being following because test
resources being placed under src/test/data instead of src/test/resources
directory. This causes problems is maven-jar-plugin and
[jira] [Comment Edited] (IMAGING-84) Generate tests.jar so client projects can leverage test image data easily
[
https://issues.apache.org/jira/browse/IMAGING-84?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403077#comment-13403077
]
Farrukh Najmi edited comment on IMAGING-84 at 6/28/12 1:27 PM:
---
Using test data is not always the only reason to have a tests.jar artifact from
a project. Another reason is when a project extends another project then it may
want to also the base project's test classes as part of its own test suite. Do
you see a downside to the project producing a tests.jar artifact?
Also, please see my comment on IMAGING-85 on why I think it is not unusual to
load test data from the classpath in junit tests.
Feel free to close the issue if you and other dev team members are still -1 on
this.
was (Author: farrukhnajmi):
Using test data is not always the only reason to have a tests.jar artifact
from a project. Another reason is when a project extends another project then
it may want to also the base project's test classes as part of its own test
suite. Do you see a downside to the project producing a tests.jar artifact?
Also, please see my comment on IMAGING-83 on why I think it is not unusual to
load test data from the classpath in junit tests.
Generate tests.jar so client projects can leverage test image data easily
-
Key: IMAGING-84
URL: https://issues.apache.org/jira/browse/IMAGING-84
Project: Commons Imaging
Issue Type: Improvement
Components: Build
Affects Versions: 0.97
Reporter: Farrukh Najmi
Priority: Minor
Attachments: SANSELAN-82-patch.txt
Client projects of commons-imaging need test image data and commons-imaging
already has a pretty good set.
The simple patch below can be applied to pom.xml to generate
commons-imaging-xxx-tests.jar in addition to commons-imaging-xxx.jar to allow
client projects to leverage the test data.
{code}
Index: pom.xml
===
--- pom.xml (revision 1354112)
+++ pom.xml (working copy)
@@ -89,6 +89,14 @@
/plugin
plugin
artifactIdmaven-jar-plugin/artifactId
+executions
+ execution
+goals
+ goaltest-jar/goal
+/goals
+ /execution
+/executions
+
configuration
archive
manifestEntries
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (JEXL-133) String matching Operator short-hand inspired by CSS3
[
https://issues.apache.org/jira/browse/JEXL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403133#comment-13403133
]
Henri Biestro commented on JEXL-133:
Good idea.
For coherence, it might be better to name them '=^' and '=$' (since the
matching operator is '=~').
And generalize the 'start with' and 'ends with' for any ordered sequence
(Object[], List?...).
The following test (in Jexl3) exhibits the intended behavior on String.
{code}
public void test133() throws Exception {
JexlEngine jexl = new Engine();
JexlScript script;
Object result;
script = jexl.createScript(x =^ 'foo', x);
result = script.execute(null, foobar);
assertEquals(Boolean.TRUE, result);
result = script.execute(null, barfoo);
assertEquals(Boolean.FALSE, result);
script = jexl.createScript(x =$ 'foo', x);
result = script.execute(null, foobar);
assertEquals(Boolean.FALSE, result);
result = script.execute(null, barfoo);
assertEquals(Boolean.TRUE, result);
}
{code}
String matching Operator short-hand inspired by CSS3
Key: JEXL-133
URL: https://issues.apache.org/jira/browse/JEXL-133
Project: Commons JEXL
Issue Type: Improvement
Affects Versions: 2.1.1
Reporter: Alfred Reibenschuh
Assignee: Henri Biestro
Priority: Trivial
Fix For: 3.0
like the perl inspired shorthand =~, css3 also has some nice shorthands
http://www.w3.org/TR/2011/REC-css3-selectors-20110929/#attribute-selectors
for startsWith the shorthand could be expr1 ^= expr2
for endsWith the shorthand could be expr1 $= expr2
it could be that the ^= operator already collides with xor and assign
which i haven't looked at as of now.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (JEXL-133) String matching Operator short-hand inspired by CSS3
[ https://issues.apache.org/jira/browse/JEXL-133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated JEXL-133: --- Fix Version/s: 3.0 String matching Operator short-hand inspired by CSS3 Key: JEXL-133 URL: https://issues.apache.org/jira/browse/JEXL-133 Project: Commons JEXL Issue Type: Improvement Affects Versions: 2.1.1 Reporter: Alfred Reibenschuh Assignee: Henri Biestro Priority: Trivial Fix For: 3.0 like the perl inspired shorthand =~, css3 also has some nice shorthands http://www.w3.org/TR/2011/REC-css3-selectors-20110929/#attribute-selectors for startsWith the shorthand could be expr1 ^= expr2 for endsWith the shorthand could be expr1 $= expr2 it could be that the ^= operator already collides with xor and assign which i haven't looked at as of now. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (MATH-797) Single step integrators
[
https://issues.apache.org/jira/browse/MATH-797?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13403231#comment-13403231
]
Gilles commented on MATH-797:
-
I'd rather include the algorithm for computing the points and weights. So, if
you don't mind (and the paperwork is all done), could you please post the code
which you wanted to donate?
Single step integrators
---
Key: MATH-797
URL: https://issues.apache.org/jira/browse/MATH-797
Project: Commons Math
Issue Type: Wish
Affects Versions: 3.0
Reporter: Gilles
Assignee: Gilles
Priority: Trivial
Fix For: 3.1
CM assumes that the user wants to integrate a complex function on a large
interval, so the large interval has to be subdivided into many subintervals.
CM does the partition, and performs convergence checks, using an iterative
approach.
However, if the function is smooth enough, no subdivision of the integration
interval is required. Those use-cases could benefit from the efficiency gain
of not performing a convergence check.
The proposal is to provide a new interface UnivariateSingleStepIntegrator:
{code}
interface SingleIntervalIntegrator {
/**
* Method for implementing a single interval integration.
* There is no convergence checks because it is not iterative.
*
* @param f Function to integrate.
* @param lower Lower bound of the interval over which to integrate.
* @param upper Upper bound of the interval over which to integrate.
* @return the integrated value.
*/
double integrate(UnivariateFunction f,
double lower,
double upper);
}
{code}
In effect, the implementation of the above integrate method of a new
LegendreGaussIntegratorSingleStepIntegrator would the equivalent of
stage(1) in the current LegendreGaussIntegrator.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (CHAIN-69) Fixed Checkstyle / PMD Warnings
Elijah Zupancic created CHAIN-69: Summary: Fixed Checkstyle / PMD Warnings Key: CHAIN-69 URL: https://issues.apache.org/jira/browse/CHAIN-69 Project: Commons Chain Issue Type: Improvement Affects Versions: 2.0 Reporter: Elijah Zupancic Fix For: 2.0 In this issue, we fix many PMD and checkstyle violations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CHAIN-69) Fixed Checkstyle / PMD Warnings
[ https://issues.apache.org/jira/browse/CHAIN-69?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Elijah Zupancic updated CHAIN-69: - Attachment: chain-69.diff Checkstyle / PMD violations fixes. Fixed Checkstyle / PMD Warnings --- Key: CHAIN-69 URL: https://issues.apache.org/jira/browse/CHAIN-69 Project: Commons Chain Issue Type: Improvement Affects Versions: 2.0 Reporter: Elijah Zupancic Fix For: 2.0 Attachments: chain-69.diff In this issue, we fix many PMD and checkstyle violations. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
