[GitHub] commons-rng pull request #6: RNG-37 make KN table long

[cur4so]

Github user cur4so closed the pull request at:

https://github.com/apache/commons-rng/pull/6


---

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

Re: [beanutils] Toward 2.0.0

[sebb]

On 28 December 2017 at 22:50, Stephen Colebourne  wrote:
> On 28 December 2017 at 19:49, Gary Gregory  wrote:
>> Hi All,
>>
>> - BeanUtils now has a new package o.a.c.beanutils2.
>> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
>> which caused the above.
>>
>> What more do we want before releasing 2.0.0?
>>
>> Updating from BU 1.x to 2.x should be "simple" for now: Just update your
>> imports.
>
> This can make things far worse for end users. If jar file A updates to
> v2.0 but jar file B does not, an application C that depends on A and B
> cannot pass the output of [beanutils] around. Instead, it gets the
> same class names repeated twice, and horrid conversion code. While I
> understand the jar hell problem fully, I'm not sure that package
> renaming the whole jar is really any better - its just a different
> kind of hell.

At least it's possible to write bridging code should it be necessary.
And any problems are immediately obvious.

Whereas if two incompatible jars are on the classpath, there's no way
to ensure which version of a class will be loaded.
And problems may not always appear until the worst possible moment.

Other things being equal (see below), I would rather have a situation
with a messy solution than a situation with none.

> If only one class exposes one problem return type in a method that not
> everyone uses, it seems _on balance_ better to change the method
> without changing the package names. The bump to v2.0 would still be a
> sufficient indication of the potential compatibility issue (rarely hit
> in reality). However, if the method in question is a vital part of the
> main API, it might be worth changing the package name.
>
> In other words, I think the presumption that all breaking changes
> require a package name change is damaging - the package name change
> should be an action of last resort.

I agree that some changes that break strict compatibility may
sometimes be permissible.
If the change only affects an esoteric or non-recommended use of the
API then it's probably better to keep the existing package.
However that assumes there is a work-round for any users who are affected.

> Stephen
>
> -
> 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

Re: [beanutils] Toward 2.0.0

[Stephen Colebourne]

On 28 December 2017 at 19:49, Gary Gregory  wrote:
> Hi All,
>
> - BeanUtils now has a new package o.a.c.beanutils2.
> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
> which caused the above.
>
> What more do we want before releasing 2.0.0?
>
> Updating from BU 1.x to 2.x should be "simple" for now: Just update your
> imports.

This can make things far worse for end users. If jar file A updates to
v2.0 but jar file B does not, an application C that depends on A and B
cannot pass the output of [beanutils] around. Instead, it gets the
same class names repeated twice, and horrid conversion code. While I
understand the jar hell problem fully, I'm not sure that package
renaming the whole jar is really any better - its just a different
kind of hell.

If only one class exposes one problem return type in a method that not
everyone uses, it seems _on balance_ better to change the method
without changing the package names. The bump to v2.0 would still be a
sufficient indication of the potential compatibility issue (rarely hit
in reality). However, if the method in question is a vital part of the
main API, it might be worth changing the package name.

In other words, I think the presumption that all breaking changes
require a package name change is damaging - the package name change
should be an action of last resort.

Stephen

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

Re: [beanutils] Toward 2.0.0

[sebb]

On 28 December 2017 at 22:02, Dave Brosius  wrote:
> beanutils 3 exposed 'FastHashMap' which was a commons collections 3 data
> structure in it's own interface. That went away in commons collections 4,
> and so i modified the beanutils 4 interface to use ConcurrentHashMaps. Thus
> the need for a package rename.

I see. So it's not just a case of changing imports.

If any user code has used that part of the interface, it will have to
be changed.

>
>
> On 12/28/2017 04:56 PM, sebb wrote:
>>
>> On 28 December 2017 at 19:49, Gary Gregory  wrote:
>>>
>>> Hi All,
>>>
>>> - BeanUtils now has a new package o.a.c.beanutils2.
>>> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
>>> which caused the above.
>>>
>>> What more do we want before releasing 2.0.0?
>>>
>>> Updating from BU 1.x to 2.x should be "simple" for now: Just update your
>>> imports.
>>
>> Surely there must be some other breaking changes otherwise there would
>> be no need to change the package name?
>>
>>> Thoughts?
>>>
>>> Gary
>>
>> -
>> 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
>

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

Re: [beanutils] Toward 2.0.0

[Dave Brosius]

beanutils 3 exposed 'FastHashMap' which was a commons collections 3 data 
structure in it's own interface. That went away in commons collections 
4, and so i modified the beanutils 4 interface to use 
ConcurrentHashMaps. Thus the need for a package rename.



On 12/28/2017 04:56 PM, sebb wrote:

On 28 December 2017 at 19:49, Gary Gregory  wrote:

Hi All,

- BeanUtils now has a new package o.a.c.beanutils2.
- BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
which caused the above.

What more do we want before releasing 2.0.0?

Updating from BU 1.x to 2.x should be "simple" for now: Just update your
imports.

Surely there must be some other breaking changes otherwise there would
be no need to change the package name?


Thoughts?

Gary

-
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

Re: [beanutils] Toward 2.0.0

[sebb]

On 28 December 2017 at 19:49, Gary Gregory  wrote:
> Hi All,
>
> - BeanUtils now has a new package o.a.c.beanutils2.
> - BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
> which caused the above.
>
> What more do we want before releasing 2.0.0?
>
> Updating from BU 1.x to 2.x should be "simple" for now: Just update your
> imports.

Surely there must be some other breaking changes otherwise there would
be no need to change the package name?

> Thoughts?
>
> Gary

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

Re: Questions regarding improving the Apache Commons release process.

[Rob Tompkins]

> On Dec 28, 2017, at 4:05 AM, Hervé BOUTEMY  wrote:
> 
> Hi Rob,
> 
> one additional point: currently, for Maven itself, instead of adding new 
> Maven-specific ReleasePhase(s) to the default configuration, or configure 
> them in 
> our parent pom (I'm not sure documentation on how to do that is available: I 
> could not find it), we chose first to create a separate "dist-tool" to check 
> consistency of what is currently published in misc places and provide some 
> commands to fix when an inconsistency is found.
> 
> This happens through daily reports done by a Jenkins job [1]:
> - distribution area vs Maven Central [2] 
> - version from Maven site vs Maven Central [3]
> 
> We did not produce any release nor made it really configurable for 
> conventions 
> different from Maven ones (like Common's -src & -bin), but at least there is 
> a 
> configuration file to define artifacts to check [4]

Interesting. Thanks,.

-Rob

> 
> HTH
> 
> Hervé
> 
> 
> [1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/
> 
> [2] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
> dist-tool-check-source-release.html
> 
> [3] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
> dist-tool-check-index-page.html
> 
> [4] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
> dist-tool.conf.html
> 
> Le mercredi 27 décembre 2017, 23:32:49 CET Rob Tompkins a écrit :
>> Stephen,
>> 
>> I can’t thank you enough for your reply. I’ll take your suggestions and
>> continue to sandbox around using the maven-release-plugin as a guideline.
>> 
>> All the best and happy holidays,
>> -Rob
>> 
>>> On Dec 26, 2017, at 5:27 AM, Stephen Connolly
>>>  wrote:> 
>>> On Tue 26 Dec 2017 at 03:10, Rob Tompkins  > wrote:
 Hello all,
 
 Pardon, maybe this should have gone to your @user list, but why not ping
 the dev crew. I’ve been playing around the ideas surrounding our fairly
 manual release process for the components in Commons, and I was hoping
 for
 some insights.
 
 Scripting the version changes isn’t really that big of a deal for us, and
 that I can manage. But, when it comes to publishing our artifacts to the
 apache nexus repository, and then separately publishing our -src and -bin
 assemblies to the dev dist subversion repository (and consequently
 deleting
 those artifacts from nexus as they’re “attached” for the purpose of gpg
 signing), I feel it a tad cumbersome.
 
 I’ve fiddled around a little with the idea of detaching the -src and -bin
 assemblies after gpg signing with some success, but then I have to delve
 into the mechanics of publishing those up to the subversion repository,
 and
 clearly that problem has already been solved.
>>> 
>>> Is your problem you don’t want those going to Nexus staging but only to
>>> dist? Or is it that you want them *also* going to dist.
>>> 
>>> Personally... I see no reason to remove them from going to Nexus staging
>>> (in fact I have a background plan to add secondary signing support to
>>> staging... i’m Waiting to see the Nexus 3 staging APIs before attempting
>>> though. That would mean that the PMC would be able to *add* their GPG
>>> signature to the staged artifacts as part of the voting... in which case
>>> you’d want to hold off uploading to dist until *after* the vote so you get
>>> the full set of signatures)
>>> 
>>> If you want to upload a subset of attached artifacts to dist as part of
>>> the
>>> release, that seems much more tenable... just a derivative of the
>>> scm-publish plugin from what I can see.
>>> 
>>> So I find myself in the space of trying to shoehorn our process into its
>>> 
 the main maven-release-plugin, which I’ve found a tad difficult, versus
 writing our own release plugin, which feels like I would be duplicating
 tons of code (which I don’t want to do).
>>> 
>>> So the release plugin is really two parts:
>>> 
>>> 1. A toolkit for writing release plugins
>>> 
>>> 2. An example that does the job for the requirements of the Maven TLP and
>>> has seemed “sufficient” for a lot of other people.
>>> 
>>> As such, if you have different needs, do not feel bad about having to
>>> encode differently... hopefully the toolkit half of the codebase is
>>> sufficient for you.
>>> 
 I’m curious if you guys have any thoughts on the matter as I’ve been
 playing around in the space for a little while now.
 
 Cheers and happy holidays from UTC-5,
 -Rob
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands,
 e-mail: dev-h...@maven.apache.org 
 
 --
>>> 
>>> Sent from my phone
> 
> 

[beanutils] Toward 2.0.0

[Gary Gregory]

Hi All,

- BeanUtils now has a new package o.a.c.beanutils2.
- BeanUtils now depends on Apache Commons Collection 4 (instead of 3),
which caused the above.

What more do we want before releasing 2.0.0?

Updating from BU 1.x to 2.x should be "simple" for now: Just update your
imports.

Thoughts?

Gary

Re: [beanutils] Missing entries in changes.xml since 1.9.3

[Gary Gregory]

On Wed, Dec 27, 2017 at 11:39 AM, Gary Gregory 
wrote:

> Hi All,
>
> Whomever committed since 1.9.3, please update the changes.xml file to
> reflect changes that have JIRA issues like BEANUTILS-500.
>

Done.

Gary


>
> Thank you,
> Gary
>

Re: [beanutils] Update to Java 7

[Gary Gregory]

On Wed, Dec 27, 2017 at 12:00 PM, Gary Gregory 
wrote:

> FYI:
>
> I plan on updating [beanutils] to Java 7. This should make the code base
> slightly more appealing.
>

Done.

Gary


>
> Gary
>

Re: Error in commons collections4 Caused by java util ConcurrentModificationException

[Gary Gregory]

Just like it says on the Javadoc:
https://docs.oracle.com/javase/7/docs/api/java/util/ConcurrentModificationException.html

One piece of code must be reading while another is writing on the
collection.

Gary

On Thu, Dec 28, 2017 at 11:21 AM, durairaj t  wrote:

> Hi All,
>
> I'm using comm.coll4 with JBOSS EAP sever 7.0 runtime and getting the below
> error,
>
> I don't know whats going on, Any help?
>
>
> Error Message:
> __
>
> Caused by: java.util.ConcurrentModificationException
> at org.apache.commons.collections4.map.AbstractLinkedMap$LinkIt
> erator.nextEntry(AbstractLinkedMap.java:552)
> at org.apache.commons.collections4.map.AbstractLinkedMap$LinkMa
> pIterator.next(AbstractLinkedMap.java:357)
> at org.apache.commons.collections4.map.AbstractHashedMap.doWrit
> eObject(AbstractHashedMap.java:1233)
> at org.apache.commons.collections4.map.LinkedMap.writeObject(
> LinkedMap.java:124)
> at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> thodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.marshalling.reflect.SerializableClass.callWriteObj
> ect(SerializableClass.java:271)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:976)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(Ri
> verMarshaller.java:854)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(Ri
> verMarshaller.java:1032)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:988)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:967)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:967)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:967)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:967)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:967)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:967)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(Ri
> verMarshaller.java:854)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(Ri
> verMarshaller.java:1032)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:988)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(Ri
> verMarshaller.java:854)
> at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(Bl
> ockMarshaller.java:65)
> at org.jboss.marshalling.river.BlockMarshaller.writeObject(Bloc
> kMarshaller.java:56)
> at org.jboss.marshalling.MarshallerObjectOutputStream.writeObje
> ctOverride(MarshallerObjectOutputStream.java:50)
> at org.jboss.marshalling.river.RiverObjectOutputStream.writeObj
> ectOverride(RiverObjectOutputStream.java:179)
> at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:344)
> at java.util.concurrent.CopyOnWriteArrayList.writeObject(CopyOn
> WriteArrayList.java:972)
> at sun.reflect.GeneratedMethodAccessor44.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
> thodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at org.jboss.marshalling.reflect.SerializableClass.callWriteObj
> ect(SerializableClass.java:271)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:976)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(Ri
> verMarshaller.java:854)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(Ri
> verMarshaller.java:1032)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:988)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(Ri
> verMarshaller.java:854)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(Ri
> verMarshaller.java:1032)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:988)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:967)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
> bleObject(RiverMarshaller.java:967)
> at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(Ri
> verMarshaller.java:854)
> at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(Bl
> ockMarshaller.java:65)
> at org.jboss.marshalling.river.BlockMarshaller.writeObject(Bloc
> kMarshaller.java:56)
> at org.jboss.marshalling.MarshallerObjectOutputStream.writeObje
> ctOverride(MarshallerObjectOutputStream.java:50)
> at org.jboss.marshalling.river.RiverObjectOutputStream.writeObj
> ectOverride(RiverObjectOutputStream.java:179)
> at 

Error in commons collections4 Caused by java util ConcurrentModificationException

[durairaj t]

Hi All,

I'm using comm.coll4 with JBOSS EAP sever 7.0 runtime and getting the below
error,

I don't know whats going on, Any help?


Error Message:
__

Caused by: java.util.ConcurrentModificationException
at org.apache.commons.collections4.map.AbstractLinkedMap$LinkIt
erator.nextEntry(AbstractLinkedMap.java:552)
at org.apache.commons.collections4.map.AbstractLinkedMap$LinkMa
pIterator.next(AbstractLinkedMap.java:357)
at org.apache.commons.collections4.map.AbstractHashedMap.doWrit
eObject(AbstractHashedMap.java:1233)
at org.apache.commons.collections4.map.LinkedMap.writeObject(
LinkedMap.java:124)
at sun.reflect.GeneratedMethodAccessor36.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
thodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.marshalling.reflect.SerializableClass.callWriteObj
ect(SerializableClass.java:271)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:976)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(Ri
verMarshaller.java:854)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(Ri
verMarshaller.java:1032)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:988)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:967)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:967)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:967)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:967)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:967)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:967)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(Ri
verMarshaller.java:854)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(Ri
verMarshaller.java:1032)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:988)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(Ri
verMarshaller.java:854)
at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(Bl
ockMarshaller.java:65)
at org.jboss.marshalling.river.BlockMarshaller.writeObject(Bloc
kMarshaller.java:56)
at org.jboss.marshalling.MarshallerObjectOutputStream.writeObje
ctOverride(MarshallerObjectOutputStream.java:50)
at org.jboss.marshalling.river.RiverObjectOutputStream.writeObj
ectOverride(RiverObjectOutputStream.java:179)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:344)
at java.util.concurrent.CopyOnWriteArrayList.writeObject(CopyOn
WriteArrayList.java:972)
at sun.reflect.GeneratedMethodAccessor44.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
thodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.marshalling.reflect.SerializableClass.callWriteObj
ect(SerializableClass.java:271)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:976)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(Ri
verMarshaller.java:854)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(Ri
verMarshaller.java:1032)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:988)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(Ri
verMarshaller.java:854)
at org.jboss.marshalling.river.RiverMarshaller.doWriteFields(Ri
verMarshaller.java:1032)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:988)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:967)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa
bleObject(RiverMarshaller.java:967)
at org.jboss.marshalling.river.RiverMarshaller.doWriteObject(Ri
verMarshaller.java:854)
at org.jboss.marshalling.river.BlockMarshaller.doWriteObject(Bl
ockMarshaller.java:65)
at org.jboss.marshalling.river.BlockMarshaller.writeObject(Bloc
kMarshaller.java:56)
at org.jboss.marshalling.MarshallerObjectOutputStream.writeObje
ctOverride(MarshallerObjectOutputStream.java:50)
at org.jboss.marshalling.river.RiverObjectOutputStream.writeObj
ectOverride(RiverObjectOutputStream.java:179)
at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:344)
at java.util.concurrent.ConcurrentHashMap.writeObject(Concurren
tHashMap.java:1413)
at sun.reflect.GeneratedMethodAccessor43.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe
thodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.jboss.marshalling.reflect.SerializableClass.callWriteObj
ect(SerializableClass.java:271)
at org.jboss.marshalling.river.RiverMarshaller.doWriteSerializa

Re: [VOTE] Release Commons JCS 2.2.1 based on RC3

[Jean-Louis MONTEIRO]

Thanks Romain for pushing this release so hard.
I have yank JCS from my project and replaced with another impl.

Thanks anyway.


Le dim. 24 déc. 2017 à 10:23, Romain Manni-Bucau  a
écrit :

> My own +1 (dont think the issues we found are worth blocking a release but
> would be happy to get help to solve them next year)
>
> And merry Xmas to everybody
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github <
> https://github.com/rmannibucau> |
> LinkedIn 
>
> 2017-12-23 13:52 GMT+01:00 Jörg Schaible :
>
> > Am Sat, 23 Dec 2017 09:06:41 +0100 schrieb Romain Manni-Bucau:
> >
> > > Hi Jorg,
> > >
> > > It doesnt break IDE support but has some "dead" code from my
> > > understanding,
> > > no?
> >
> > OK, I should have checked it myself. I got Oliver wrong and thought it
> > contains only cruft, but the cruft is only
> > additional ;-)
> >
> > In that case I change my vote to +1
> >
> > Merry Xmas,
> > Jörg
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: Questions regarding improving the Apache Commons release process.

[Hervé BOUTEMY]

Hi Rob,

one additional point: currently, for Maven itself, instead of adding new 
Maven-specific ReleasePhase(s) to the default configuration, or configure them 
in 
our parent pom (I'm not sure documentation on how to do that is available: I 
could not find it), we chose first to create a separate "dist-tool" to check 
consistency of what is currently published in misc places and provide some 
commands to fix when an inconsistency is found.

This happens through daily reports done by a Jenkins job [1]:
- distribution area vs Maven Central [2] 
- version from Maven site vs Maven Central [3]

We did not produce any release nor made it really configurable for conventions 
different from Maven ones (like Common's -src & -bin), but at least there is a 
configuration file to define artifacts to check [4]

HTH

Hervé


[1] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/

[2] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
dist-tool-check-source-release.html

[3] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
dist-tool-check-index-page.html

[4] https://builds.apache.org/view/M-R/view/Maven/job/dist-tool-plugin/site/
dist-tool.conf.html

Le mercredi 27 décembre 2017, 23:32:49 CET Rob Tompkins a écrit :
> Stephen,
> 
> I can’t thank you enough for your reply. I’ll take your suggestions and
> continue to sandbox around using the maven-release-plugin as a guideline.
> 
> All the best and happy holidays,
> -Rob
> 
> > On Dec 26, 2017, at 5:27 AM, Stephen Connolly
> >  wrote:> 
> > On Tue 26 Dec 2017 at 03:10, Rob Tompkins > wrote:
> >> Hello all,
> >> 
> >> Pardon, maybe this should have gone to your @user list, but why not ping
> >> the dev crew. I’ve been playing around the ideas surrounding our fairly
> >> manual release process for the components in Commons, and I was hoping
> >> for
> >> some insights.
> >> 
> >> Scripting the version changes isn’t really that big of a deal for us, and
> >> that I can manage. But, when it comes to publishing our artifacts to the
> >> apache nexus repository, and then separately publishing our -src and -bin
> >> assemblies to the dev dist subversion repository (and consequently
> >> deleting
> >> those artifacts from nexus as they’re “attached” for the purpose of gpg
> >> signing), I feel it a tad cumbersome.
> >> 
> >> I’ve fiddled around a little with the idea of detaching the -src and -bin
> >> assemblies after gpg signing with some success, but then I have to delve
> >> into the mechanics of publishing those up to the subversion repository,
> >> and
> >> clearly that problem has already been solved.
> > 
> > Is your problem you don’t want those going to Nexus staging but only to
> > dist? Or is it that you want them *also* going to dist.
> > 
> > Personally... I see no reason to remove them from going to Nexus staging
> > (in fact I have a background plan to add secondary signing support to
> > staging... i’m Waiting to see the Nexus 3 staging APIs before attempting
> > though. That would mean that the PMC would be able to *add* their GPG
> > signature to the staged artifacts as part of the voting... in which case
> > you’d want to hold off uploading to dist until *after* the vote so you get
> > the full set of signatures)
> > 
> > If you want to upload a subset of attached artifacts to dist as part of
> > the
> > release, that seems much more tenable... just a derivative of the
> > scm-publish plugin from what I can see.
> > 
> > So I find myself in the space of trying to shoehorn our process into its
> > 
> >> the main maven-release-plugin, which I’ve found a tad difficult, versus
> >> writing our own release plugin, which feels like I would be duplicating
> >> tons of code (which I don’t want to do).
> > 
> > So the release plugin is really two parts:
> > 
> > 1. A toolkit for writing release plugins
> > 
> > 2. An example that does the job for the requirements of the Maven TLP and
> > has seemed “sufficient” for a lot of other people.
> > 
> > As such, if you have different needs, do not feel bad about having to
> > encode differently... hopefully the toolkit half of the codebase is
> > sufficient for you.
> > 
> >> I’m curious if you guys have any thoughts on the matter as I’ve been
> >> playing around in the space for a little while now.
> >> 
> >> Cheers and happy holidays from UTC-5,
> >> -Rob
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> >>  For additional commands,
> >> e-mail: dev-h...@maven.apache.org 
> >> 
> >> --
> > 
> > Sent from my phone



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