[GitHub] commons-text issue #52: Test: Improved testcase coverage for StrBuilder

[ameyjadiye]

Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/52
  
@PascalSchumacher This seems nice trick , but somehow didn't worked for me 
and ended up just pushing latest commit, can you try this once ? I have given 
you write access for exact this repository.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #52: Test: Improved testcase coverage for StrBuilder

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/52
  

[![Coverage 
Status](https://:/builds/12061474/badge)](https://:/builds/12061474)

Changes Unknown when pulling **242ad5e6cda2cc62be4e1b8fccedd7922ecdc44e on 
ameyjadiye:test-StrBuilder** into ** on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Gary Gregory]

On Jun 20, 2017 3:08 PM, "Simon Spero"  wrote:

On Tue, Jun 20, 2017 at 10:18 AM, Stefan Bodewig  wrote:

>
> Interesting. This means OSGi only provides a way for consumers to say
> which version of an API they want, but not which implementation. This
means
> as a consumer you can't say "I want version 1.19 of Compress because I
know
> it contains an important fix". This feels more limited in expressiveness
> than I had expected.
>

Bundles can specify all sorts of Requirements, including implementations,
and bugfix version ranges  (by default, the bugfix component is not
specified in the lower bound, but that is just a default).   It can be a
little too expressive :-)

If a new version becomes available, it can often be swapped in dynamically
(e.g. when using Declarative Services (née Felix SCR)  with Greedy dynamic
reference, an inject  service will be replaced whenever a newer version is
available).

For more on updating and refreshing bundles see:
https://stackoverflow.com/questions/4330927/how-does-osgi-bundle-update-work


I do feel that it ought to be possible to have  more aggressive updates for
critical (security) release, though  that's a little orthogonal to the
version range issue.


One day, in a galaxy far far away, we will just be able to push a button to
release...

Gary

Re: OSGi Version at Package Level

[Simon Spero]

On Tue, Jun 20, 2017 at 10:18 AM, Stefan Bodewig  wrote:

>
> Interesting. This means OSGi only provides a way for consumers to say
> which version of an API they want, but not which implementation. This means
> as a consumer you can't say "I want version 1.19 of Compress because I know
> it contains an important fix". This feels more limited in expressiveness
> than I had expected.
>

Bundles can specify all sorts of Requirements, including implementations,
and bugfix version ranges  (by default, the bugfix component is not
specified in the lower bound, but that is just a default).   It can be a
little too expressive :-)

If a new version becomes available, it can often be swapped in dynamically
(e.g. when using Declarative Services (née Felix SCR)  with Greedy dynamic
reference, an inject  service will be replaced whenever a newer version is
available).

For more on updating and refreshing bundles see:
https://stackoverflow.com/questions/4330927/how-does-osgi-bundle-update-work


I do feel that it ought to be possible to have  more aggressive updates for
critical (security) release, though  that's a little orthogonal to the
version range issue.

[GitHub] commons-text issue #52: Test: Improved testcase coverage for StrBuilder

[PascalSchumacher]

Github user PascalSchumacher commented on the issue:

https://github.com/apache/commons-text/pull/52
  
Thanks for splitting the changes. :+1: 

But please also address the second part:

>Please stick to the existing code style for the new tests (no new line at 
the beginning and at the end of a test method; single new line between test 
methods).

Furthermore it would be very nice if you would clean up the history of the 
pull request by using `git rebase` once it is ready to merge.

After you commit the style fixes for the new tests you should be able to 
clean-up the history like this:

Use `git rebase -i head~5`. Choose to drop the first two commits 
(06e8b3dd06ee2f86490b2e94359d29d2fe04786c and 
27e110b37f8f1e1cceee18ab614424f8a807a747). Squash 
d23bd1db8c0f21f62006b8cf0f41eb0588997a1e and the last commit. Afterwards use 
`push -f` to update the pull request.

After this there will be only two commits (one with the style changes and 
one with the new tests) and the commit history of commons-text will be 
pristine. :smile: 


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #52: Test: Improved testcase coverage for StrBuilder

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-text/pull/52
  

[![Coverage 
Status](https://:/builds/12055561/badge)](https://:/builds/12055561)

Changes Unknown when pulling **31a5cd173d118148b2a2d2dfac8c99f2d90a8a06 on 
ameyjadiye:test-StrBuilder** into ** on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-text issue #52: Test: Improved testcase coverage for StrBuilder

[ameyjadiye]

Github user ameyjadiye commented on the issue:

https://github.com/apache/commons-text/pull/52
  
Fixed all the code as suggested, Thanks.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

[sesuncedu]

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/38
  
Hudkins is happy. Happy happy Hudkins.

So I will close this.  Though I think some of the changes might actually be 
useful. 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-compress pull request #38: Testing hudson/jenkins (added contributor...

[sesuncedu]

Github user sesuncedu closed the pull request at:

https://github.com/apache/commons-compress/pull/38


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-compress pull request #36: COMPRESS-410 Remove Non-NIO character set...

[sesuncedu]

Github user sesuncedu closed the pull request at:

https://github.com/apache/commons-compress/pull/36


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-compress pull request #36: COMPRESS-410 Remove Non-NIO character set...

[sesuncedu]

GitHub user sesuncedu reopened a pull request:

https://github.com/apache/commons-compress/pull/36

COMPRESS-410 Remove Non-NIO character set encoders.

As a special case, the UTF-8 encoder will replace malformed / unmappable 
input with '?'.
This behavior is required for compatibility with existing behavior.

Signed-off-by: Simon Spero 

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-410

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-compress/pull/36.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #36


commit 1c9e1d8218ccd102567273eebdfba187ca545fc8
Author: Simon Spero 
Date:   2017-06-17T00:17:13Z

COMPRESS-410 Remove Non-NIO character set encoders.
As a special case, the UTF-8 encoder will replace malformed / unmappable 
input with '?'.
This behavior is required for compatibility with existing behavior.

Signed-off-by: Simon Spero 

commit 7fdfde85a8ab19c1f47efe4d3a9d0bad653182b2
Author: Simon Spero 
Date:   2017-06-17T16:45:44Z

javadoc for HasCharset

Signed-off-by: Simon Spero 

commit 651eae5399ba5b980257703b0ff98d7f7d89aee3
Author: Simon Spero 
Date:   2017-06-18T22:55:38Z

Do better estimating of required buffer size for character encoding.  If an 
unencodable character is found that requires output buffer expansion,  scan 
buffer for all such characters, and attempt to expand buffer only once.

Signed-off-by: Simon Spero 

commit c9dfc31dbbbe099927a843197936b19e41f64d5c
Author: Simon Spero 
Date:   2017-06-11T22:48:42Z

COMPRESS-407 Validate Block and Record Sizes

Require block size >=0 that is multiple of 512 bytes.
Use block size of 512 if one is not given.
Require record size of 512 bytes. Deprecate constructors taking recordSize 
as parameter

Modify tests to check for enforcement of record size == 512
Modify tests to check for correct overall length  for
different block sizes including PAX default, USTAR default, and unspecified.

Signed-off-by: Simon Spero 

commit 15764594371bd8792b28d6cb415b9fcf1a9a60c2
Author: Michael Hausegger 
Date:   2017-06-13T21:47:50Z

add-some-Unit-Tests Added some Unit Tests to increase code coverage.

commit 9d81c8fcad4cbedcbe0cfd81a7af492800d1f726
Author: Simon Spero 
Date:   2017-06-15T18:27:48Z

Redoing more buffer stuff

Signed-off-by: Simon Spero 

commit 40736df64b5360f3ea3ad481ed81b47bd6650b30
Author: Simon Spero 
Date:   2017-06-15T18:27:48Z

Redoing more buffer stuff

Signed-off-by: Simon Spero 

commit ead6bc6db225d8da124e37d67ecd081e3167d0ca
Author: Simon Spero 
Date:   2017-06-15T23:26:12Z

More ByteBuffer methods for TarUtils

Signed-off-by: Simon Spero 

commit ab95c59eabdd283ec993bab7559b14864c1bcc57
Author: Simon Spero 
Date:   2017-06-16T20:24:12Z

More ByteBuffer methods for TarUtils

Signed-off-by: Simon Spero 

commit a5db19a7ff84114033d3e8411e1a02497e0c1bd8
Author: Michael Hausegger 
Date:   2017-06-16T18:12:20Z

add-some-Unit-Tests Removed @author tags in comments.

commit 028b81cf85547edc7c54b6ab8c4395ac8c931c20
Author: Michael Hausegger 
Date:   2017-06-16T18:22:10Z

add-some-Unit-Tests Removed test testGetValueThrowsNullPointerException in 
class ChecksumCalculatingInputStreamTest. Test represented a bug/defect which 
is going to be fixed in a different branch.

commit 3908b334156c8f5a44ac3777d73adb80f0f973d2
Author: Michael Hausegger 
Date:   2017-06-16T18:38:00Z

add-some-Unit-Tests Minor variable renaming.

commit e5c2cce4f9b7f3aca848b3c608c77f5c7911a662
Author: Michael Hausegger 
Date:   2017-06-16T18:44:40Z

add-some-Unit-Tests Added myself as contributor to pom.xml as "requested" 
by Stefan Bodewig.

commit 04109a4d0924b7a79319e2ce382bc9fedea51a65
Author: Michael Hausegger 
Date:   2017-06-16T20:16:06Z

add-some-Unit-Tests Added additional Unit Tests.

commit d7195a8bc61d151227540521b723ca580bd26dab
Author: Simon Spero 
Date:   2017-06-17T15:54:15Z

Initial support for ByteBuffer header output

Signed-off-by: Simon Spero 

commit e0af41ce1ddb38f6dd1cb8fbe979f737827a685e
Author: Simon Spero 
Date:   

[GitHub] commons-compress issue #36: COMPRESS-410 Remove Non-NIO character set encode...

[sesuncedu]

Github user sesuncedu commented on the issue:

https://github.com/apache/commons-compress/pull/36
  
reopening just to see if I didn't need to create a new branch and cherry 
pick


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [compress][all]Fwd: Build failed in Jenkins: Commons-Compress PullRequest Builder #56

[Simon Spero]

Hudkins is alive!

On Tue, Jun 20, 2017 at 12:49 AM, Dave Fisher  wrote:

> Check with Infra weird errors are happening.
>
> Regards,
> Dave
>
> Sent from my iPhone
>
> > On Jun 19, 2017, at 8:53 PM, Stefan Bodewig  wrote:
> >
> >> On 2017-06-19, Gary Gregory wrote:
> >>
> >> Is it just me or have there been Jenkins failures left and right for the
> >> last week or so?
> >
> > That's the Jenkins job I've created for github pull requests and it
> > fails whenever there are merge conflicts, for example.
> >
> > Right now it looks as if the workspace was caught in an unhealthy state,
> > I'll wipe it and reconfigure the job to perform clean checkouts.
> >
> > Stefan
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

[GitHub] commons-compress issue #37: COMPRESS-410 - cherry picked to fix merging issu...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/37
  

[![Coverage 
Status](https://:/builds/12055314/badge)](https://:/builds/12055314)

Coverage increased (+0.04%) to 84.77% when pulling 
**922051d1f2250256697a1b042f1f319b2950fc45 on sesuncedu:COMPRESS-410-REDUX** 
into **4be9979b45ceadc50dc24607884d34613fead1f5 on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-compress pull request #37: COMPRESS-410 - cherry picked to fix mergi...

[sesuncedu]

Github user sesuncedu closed the pull request at:

https://github.com/apache/commons-compress/pull/37


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-compress pull request #37: COMPRESS-410 - cherry picked to fix mergi...

[sesuncedu]

GitHub user sesuncedu reopened a pull request:

https://github.com/apache/commons-compress/pull/37

COMPRESS-410 - cherry picked  to fix merging issues

Remove non-NIO character set encoders. 

Fixes rebasing related issues in previous PR 


You can merge this pull request into a Git repository by running:

$ git pull https://github.com/sesuncedu/commons-compress COMPRESS-410-REDUX

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/commons-compress/pull/37.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #37


commit 5a7ecf1a52d078cf005082c22d302ee9dcc2faf0
Author: Simon Spero 
Date:   2017-06-17T00:17:13Z

COMPRESS-410 Remove Non-NIO character set encoders.
As a special case, the UTF-8 encoder will replace malformed / unmappable 
input with '?'.
This behavior is required for compatibility with existing behavior.

Signed-off-by: Simon Spero 

(cherry picked from commit 0d41ac4)
Signed-off-by: Simon Spero 

commit 8125dccb36792fdcc83c7359d13ecade39852562
Author: Simon Spero 
Date:   2017-06-17T16:45:44Z

javadoc for HasCharset

Signed-off-by: Simon Spero 

(cherry picked from commit b70c7c2)
Signed-off-by: Simon Spero 

commit cf3fa1ecd677b0d405e6018b91aa13f90ecb3b7c
Author: Simon Spero 
Date:   2017-06-17T00:17:13Z

COMPRESS-410 Remove Non-NIO character set encoders.
As a special case, the UTF-8 encoder will replace malformed / unmappable 
input with '?'.
This behavior is required for compatibility with existing behavior.

Signed-off-by: Simon Spero 

(cherry picked from commit 1987719)
Signed-off-by: Simon Spero 

commit fb52100291ed3f69581f6a6dc5062a07e6d52ae8
Author: Simon Spero 
Date:   2017-06-18T22:55:38Z

Do better estimating of required buffer size for character encoding.  If an 
unencodable character is found that requires output buffer expansion,  scan 
buffer for all such characters, and attempt to expand buffer only once.

Signed-off-by: Simon Spero 

(cherry picked from commit aa30e21)
Signed-off-by: Simon Spero 

commit 9f76e86f71d36897895e1e5f49b522d12602f3cc
Author: Simon Spero 
Date:   2017-06-15T18:27:48Z

Redoing more buffer stuff

Signed-off-by: Simon Spero 

(cherry picked from commit 330c8b3)
Signed-off-by: Simon Spero 

commit b92044a5fe95a8b6901040ee8b4c698c0a650e7d
Author: Simon Spero 
Date:   2017-06-18T23:27:42Z

Test that ebcidic encoding is supported (making sure "%U" replacement 
strings don't use ascii encodings)

Signed-off-by: Simon Spero 

(cherry picked from commit f1ec715)
Signed-off-by: Simon Spero 

commit ae1e7b07f0e9483c07d33cf49862660cca3da81e
Author: Simon Spero 
Date:   2017-06-19T00:04:35Z

Add licence comment to HasCharset

Signed-off-by: Simon Spero 

commit 7e01241512f3f4059fa8d909bf7f98379ef4f373
Author: Simon Spero 
Date:   2017-06-19T00:10:46Z

Resurrected HasCharset in the wrong place (not beyond the grave).

Signed-off-by: Simon Spero 

commit 922051d1f2250256697a1b042f1f319b2950fc45
Author: Simon Spero 
Date:   2017-06-19T10:07:02Z

Remove methods and change test + throw to assert to please the coveralls

Signed-off-by: Simon Spero 




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

[GitHub] commons-compress issue #38: Testing hudson/jenkins (added contributor line t...

[coveralls]

Github user coveralls commented on the issue:

https://github.com/apache/commons-compress/pull/38
  

[![Coverage 
Status](https://:/builds/12055144/badge)](https://:/builds/12055144)

Coverage increased (+0.2%) to 84.885% when pulling 
**4a4ac39e9a95b9b7f36fef464569c2af5273da30 on sesuncedu:UPSTREAM-MASTER** into 
**4be9979b45ceadc50dc24607884d34613fead1f5 on apache:master**.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Code formatting for COMMONS (was Re: [GitHub] commons-text issue #52: Test: Improved testcase coverage for StrBuilder)

[sebb]

On 20 June 2017 at 15:07, Stefan Bodewig  wrote:
> On 2017-06-19, Simon Spero wrote:
>
>> Is there a set of commons code formatting conventions? More particularly,
>> is there a machine readable file of same? I use intellij, so native,
>> checkstyle, or Eclipse is fine.
>
> This probably would be something that was decided at the component level
> and may be different between components. Some components may not have
> any conventions at all - Compress is one such component for example:
> http://commons.apache.org/proper/commons-compress/conventions.html
>
> I don't see any conventions documented for Text either.

AFAIK the only agreed upon Commons convention is NO TABS!

There are some other conventions here (not just formatting):

https://wiki.apache.org/commons/CodeStyle

If there is no documented convention, use the same convention as the
code you are changing.

Whilst this is not very 'tidy', it's better than multiple changes to
files just to change format.
Such changes make it hard to review commit emails and mess up historic
comparisons as well.

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Stefan Bodewig]

On 2017-06-20, Bertrand Delacretaz wrote:

> On Thu, Jun 15, 2017 at 6:53 PM, Stefan Bodewig  wrote:
>> ...We use the default configuration of the bundle plugin, only marking some
>> imports as optional. So we are exporting all our packages...

> Ok. In the OSGi world it's only APIs and utility classes that should
> be exported, implementations should be hidden.

> But this requires separating these things (API, public utilities,
> implementation) in their own packages - if you don't do that, using
> OSGi semantic versioning might not help much and the whole thing might
> be moot.

It may be more difficult than that. Some format specific packages are
actually mixtures of API and implementation as we provide extensions
only supported for a specific format. Things like which compression
level to use for gzip or the dialect to use when tar encounters file
names longer thann 100 characters ...

> And reorganizing your packages might cause too much pain compared to
> the benefits, although it's good in the long term. So maybe something
> for a major release.

If we ever get enough momentum for this, yes :-)

> The format specific packages should be only implementation, correct?
> With only their APIs being exported.

Not in our current world, no.

>> ... What bad happens if the published version of a package changes even if
>> there is no change at all - this is what happens for some packages if we
>> keep on doing what we have done all the time

> As above - this will require some OSGi users to upgrade or recompile
> other bundles that depends on yours, although technically that
> wouldn't be needed.

Understood, thanks.

>> ...What I really wanted to say is if the bugfix means the exported package
>> version now is "1.17.1" and the bundle version is "1.19" won't we
>> confuse the hell out of our users if we tell them they need version
>> 1.17.1 of the package that's contained inside of Compress 1.19 - as
>> opposed to telling them "upgrade to Compress 1.19"?...

> If the exported package versions haven't changed (because the bugfix
> code is implementation only so not exported) , in OSGi you can use
> either the old or the new version of the bundle, without any other
> changes to your system as OSGi won't see the change. Users will have
> to be informed to upgrade to 1.19 to get the bugfix, and based on no
> exported package versions having changed they will know they don't
> need any other changes in their system.

Interesting. This means OSGi only provides a way for consumers to say
which version of an API they want, but not which implementation. This
means as a consumer you can't say "I want version 1.19 of Compress
because I know it contains an important fix". This feels more limited in
expressiveness than I had expected.

>> ...I'm also afraid we'll have to grep through git logs to figure out which
>> version of Compress a bug is reported against if the reporter talks
>> about the version of an exported package rather than the version of the
>> bundle

> They shouldn't, tracking should always happen against the version of
> the artifact that you release.

Phew, this is good. :-)

> I think the key is cleanly separating the code so that Java packages
> do not mix APIs, public utilities and bundle-private code.

> If that's done, the rest follows naturally.

> If that's not done, having independent version numbers for each
> package might cause more pain that benefits.

Thank you very much.

> HTH, and nice "talking" to you Stefan after all this time!

Indeed!

Cheers

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Code formatting for COMMONS (was Re: [GitHub] commons-text issue #52: Test: Improved testcase coverage for StrBuilder)

[Stefan Bodewig]

On 2017-06-19, Simon Spero wrote:

> Is there a set of commons code formatting conventions? More particularly,
> is there a machine readable file of same? I use intellij, so native,
> checkstyle, or Eclipse is fine.

This probably would be something that was decided at the component level
and may be different between components. Some components may not have
any conventions at all - Compress is one such component for example:
http://commons.apache.org/proper/commons-compress/conventions.html

I don't see any conventions documented for Text either.

Stefan

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: OSGi Version at Package Level

[Bertrand Delacretaz]

Hi Stefan,

On Thu, Jun 15, 2017 at 6:53 PM, Stefan Bodewig  wrote:
> ...We use the default configuration of the bundle plugin, only marking some
> imports as optional. So we are exporting all our packages...

Ok. In the OSGi world it's only APIs and utility classes that should
be exported, implementations should be hidden.

But this requires separating these things (API, public utilities,
implementation) in their own packages - if you don't do that, using
OSGi semantic versioning might not help much and the whole thing might
be moot.

And reorganizing your packages might cause too much pain compared to
the benefits, although it's good in the long term. So maybe something
for a major release.

> ...If the API of a package changes with a new release we are on the safe
> side with the current approach...

Yes. You might cause unnecessary incompatibilities with client OSGi
bundles that specify a restricted import versions range, that's
inconvenient but not dramatic.

>
> ...What is the expectation if only the implementation of a package changes?...

That should be invisible from the OSGi side of things. You will
mention in your release notes that users need to upgrade to the new
*bundle version* to get the new implementation, but the versions of
the OSGi exported packages wouldn't change.

Again this is moot if everything's exported or if packages mix things up.

> ...What is the expectation for the format specific packages if the version
> of the utils package they internally depend on changes? Do the format
> specific packages need a version update as well? Does the bundle plugin
> detect this?...

The format specific packages should be only implementation, correct?
With only their APIs being exported.

>
>... What bad happens if the published version of a package changes even if
> there is no change at all - this is what happens for some packages if we
> keep on doing what we have done all the time

As above - this will require some OSGi users to upgrade or recompile
other bundles that depends on yours, although technically that
wouldn't be needed.

> ...What I really wanted to say is if the bugfix means the exported package
> version now is "1.17.1" and the bundle version is "1.19" won't we
> confuse the hell out of our users if we tell them they need version
> 1.17.1 of the package that's contained inside of Compress 1.19 - as
> opposed to telling them "upgrade to Compress 1.19"?...

If the exported package versions haven't changed (because the bugfix
code is implementation only so not exported) , in OSGi you can use
either the old or the new version of the bundle, without any other
changes to your system as OSGi won't see the change. Users will have
to be informed to upgrade to 1.19 to get the bugfix, and based on no
exported package versions having changed they will know they don't
need any other changes in their system.

> ...I'm also afraid we'll have to grep through git logs to figure out which
> version of Compress a bug is reported against if the reporter talks
> about the version of an exported package rather than the version of the
> bundle

They shouldn't, tracking should always happen against the version of
the artifact that you release. Exported package versions then
naturally derive from whatever changes are made, and provide API-level
compatibility guarantees that are very useful in large systems.

>... Maybe I'm making a bigger problem of this than it really is...

I think the key is cleanly separating the code so that Java packages
do not mix APIs, public utilities and bundle-private code.

If that's done, the rest follows naturally.

If that's not done, having independent version numbers for each
package might cause more pain that benefits.

HTH, and nice "talking" to you Stefan after all this time!
-Bertrand

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org