Hi,

I merged some PRs to update the scm section and infra confirmed that the
svn repos has been passed to read only mode when they started the
migration process.

regards,

François
[email protected]

Le 21/07/2021 à 11:04, Francois Papon a écrit :
>
> Good point!
>
> I will update the scm section of the pom and ask to pass the the old
> svn repo in read only.
>
> François
> [email protected]
> Le 21/07/2021 à 11:02, Romain Manni-Bucau a écrit :
>> great news!
>> did the <scm> section and release plugin was updated to enable releases?
>> Also should we pass svn in read only if possible? recall xbean
>> already got some weird state where we pushed to both locations
>>
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
>> <https://rmannibucau.metawerx.net/> | Old Blog
>> <http://rmannibucau.wordpress.com> | Github
>> <https://github.com/rmannibucau> | LinkedIn
>> <https://www.linkedin.com/in/rmannibucau> | Book
>> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>>
>>
>> Le mer. 21 juil. 2021 à 11:00, Jean-Baptiste Onofré <[email protected]
>> <mailto:[email protected]>> a écrit :
>>
>>     Thanks for the update and taking action !
>>
>>     Regards
>>     JB
>>
>>     On 7/21/21 10:58 AM, Francois Papon wrote:
>>     > Hi all,
>>     >
>>     > This 3 repo has moved successfuly to gitbox:
>>     >
>>     >    https://github.com/apache/geronimo-xbean
>>     <https://github.com/apache/geronimo-xbean>
>>     >    https://github.com/apache/geronimo-javamail
>>     <https://github.com/apache/geronimo-javamail>
>>     >    https://github.com/apache/geronimo-txmanager
>>     <https://github.com/apache/geronimo-txmanager>
>>     >
>>     > We can now merge the pending PRs.
>>     >
>>     > regards,
>>     >
>>     > François
>>     > [email protected] <mailto:[email protected]>
>>     >
>>     > Le 08/06/2021 à 14:15, Richard Zowalla a écrit :
>>     >> Thx for the ticket id !
>>     >>
>>     >> Am Dienstag, den 08.06.2021, 14:07 +0200 schrieb Francois Papon:
>>     >>> Hi,
>>     >>>
>>     >>> Migration is still pending, waiting for infra:
>>     >>>
>>     >>> https://issues.apache.org/jira/browse/INFRA-21908
>>     <https://issues.apache.org/jira/browse/INFRA-21908>
>>     >>> <https://issues.apache.org/jira/browse/INFRA-21908
>>     <https://issues.apache.org/jira/browse/INFRA-21908>>
>>     >>>
>>     >>> regards,
>>     >>>
>>     >>> François
>>     >>> [email protected] <mailto:[email protected]>
>>     >>>
>>     >>> Le 08/06/2021 à 13:56, Richard Zowalla a écrit :
>>     >>>> Hi François,
>>     >>>>
>>     >>>> any updates from INFRA on this? Couldnt find the ticket id
>>     anymore,
>>     >>>> sry.
>>     >>>>
>>     >>>> Gruss
>>     >>>> Richard
>>     >>>>
>>     >>>> Am Mittwoch, den 19.05.2021, 09:38 +0200 schrieb Francois Papon:
>>     >>>>> Hi,
>>     >>>>>
>>     >>>>> Yes, we plan to do this just after the migration to git ;)
>>     >>>>>
>>     >>>>> regards,
>>     >>>>>
>>     >>>>> François
>>     >>>>> [email protected] <mailto:[email protected]>
>>     >>>>>
>>     >>>>> Le 19/05/2021 à 09:09, Zowalla, Richard a écrit :
>>     >>>>>> Hi,
>>     >>>>>>
>>     >>>>>> thanks for your response! I think, that [1] might also affect
>>     >>>>>> the
>>     >>>>>> hard-
>>     >>>>>> coded TLS1.0 in GERONIMO-6792 [2], so the pending patch would
>>     >>>>>> be
>>     >>>>>> very
>>     >>>>>> appreciated.
>>     >>>>>>
>>     >>>>>> Maybe after the migration to git? ;)
>>     >>>>>>
>>     >>>>>> Gruss
>>     >>>>>> Richard
>>     >>>>>>
>>     >>>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8202343
>>     <https://bugs.openjdk.java.net/browse/JDK-8202343>
>>     >>>>>> [2] https://issues.apache.org/jira/browse/GERONIMO-6792
>>     <https://issues.apache.org/jira/browse/GERONIMO-6792>
>>     >>>>>>
>>     >>>>>> Am Samstag, den 01.05.2021, 08:20 +0200 schrieb
>>     >>>>>> [email protected] <mailto:[email protected]>:
>>     >>>>>>> Hi,
>>     >>>>>>>
>>     >>>>>>> I think I can take a look to the Jira and merge the PRs.
>>     >>>>>>>
>>     >>>>>>> regards,
>>     >>>>>>>
>>     >>>>>>> François
>>     >>>>>>> [email protected] <mailto:[email protected]>
>>     >>>>>>>
>>     >>>>>>> Le 28/04/2021 à 11:09, Zowalla, Richard a écrit :
>>     >>>>>>>> Just to follow up on this thread:
>>     >>>>>>>>
>>     >>>>>>>> Do we have any plans for moving forward with the mail-
>>     >>>>>>>> related
>>     >>>>>>>> patches?
>>     >>>>>>>> The hard-coded TLS config in mail is a bit "pain" ;)
>>     >>>>>>>>
>>     >>>>>>>> Gruss
>>     >>>>>>>> Richard
>>     >>>>>>>>
>>     >>>>>>>> Am Dienstag, den 23.03.2021, 08:50 +0100 schrieb Romain
>>     >>>>>>>> Manni-
>>     >>>>>>>> Bucau:
>>     >>>>>>>>> Well it can use a singleton but from a factory method. So
>>     >>>>>>>>> immediate
>>     >>>>>>>>> solution is to add a public static X getInstance();.
>>     >>>>>>>>> But as mentionned it means, to keep the pluggability we
>>     >>>>>>>>> should
>>     >>>>>>>>> target
>>     >>>>>>>>> with such a spi, you will enforce all other impl to use
>>     >>>>>>>>> such
>>     >>>>>>>>> a
>>     >>>>>>>>> pattern (you cant' just switch with -D easily since
>>     >>>>>>>>> adding is
>>     >>>>>>>>> easy
>>     >>>>>>>>> but dropping system props is almost impossible).
>>     >>>>>>>>> A noarg public constructor is trivial and more natural
>>     >>>>>>>>> with
>>     >>>>>>>>> resources
>>     >>>>>>>>> IMHO - but once again tomee can does all the work to
>>     >>>>>>>>> makes it
>>     >>>>>>>>> equivalent, just requires to duplicate/wrap the impls of
>>     >>>>>>>>> the
>>     >>>>>>>>> SPI
>>     >>>>>>>>> in
>>     >>>>>>>>> tomee codebase which sounds weird to me ("we have an impl
>>     >>>>>>>>> but
>>     >>>>>>>>> you
>>     >>>>>>>>> need to use another one").
>>     >>>>>>>>>
>>     >>>>>>>>> On a more personal note I think this pattern is no more
>>     >>>>>>>>> relevant
>>     >>>>>>>>> and
>>     >>>>>>>>> has more pitfalls since you enforce a static instance as
>>     >>>>>>>>> soon
>>     >>>>>>>>> as
>>     >>>>>>>>> the
>>     >>>>>>>>> class is loaded whereas it is not needed depending the
>>     >>>>>>>>> lifecycle
>>     >>>>>>>>> of
>>     >>>>>>>>> your main - it is not much but still, I see it as a leak
>>     >>>>>>>>> in
>>     >>>>>>>>> terms
>>     >>>>>>>>> of
>>     >>>>>>>>> design (indeed this one is not important and not a
>>     >>>>>>>>> blocker
>>     >>>>>>>>> but
>>     >>>>>>>>> all
>>     >>>>>>>>> implies to move to the noarg public constructor on my
>>     >>>>>>>>> side).
>>     >>>>>>>>> Maybe a habit and personal choice so would be great to
>>     >>>>>>>>> have
>>     >>>>>>>>> another
>>     >>>>>>>>> opinion to move forward :).
>>     >>>>>>>>>
>>     >>>>>>>>> Le mar. 23 mars 2021 à 08:38, Zowalla, Richard <
>>     >>>>>>>>> [email protected]
>>     <mailto:[email protected]>> a écrit :
>>     >>>>>>>>>> Hi,
>>     >>>>>>>>>>
>>     >>>>>>>>>> I think, it is about the configuration flexibility in
>>     >>>>>>>>>> tomee's
>>     >>>>>>>>>> <resource> definitions, which wouldn't allow the use of
>>     >>>>>>>>>> a
>>     >>>>>>>>>> singleton
>>     >>>>>>>>>> instance. Hence, the consuming project would need to
>>     >>>>>>>>>> implement
>>     >>>>>>>>>> the
>>     >>>>>>>>>> interface to make it possible. But I am not that deep
>>     >>>>>>>>>> as
>>     >>>>>>>>>> Romain
>>     >>>>>>>>>> in
>>     >>>>>>>>>> the
>>     >>>>>>>>>> TomEE codebase, so it is still a guess from my side.
>>     >>>>>>>>>>
>>     >>>>>>>>>> Gruss
>>     >>>>>>>>>> Richard
>>     >>>>>>>>>>
>>     >>>>>>>>>> Am Montag, den 22.03.2021, 23:14 +0100 schrieb Florent
>>     >>>>>>>>>> Guillaume:
>>     >>>>>>>>>>> Hi,
>>     >>>>>>>>>>>
>>     >>>>>>>>>>> I can drop the private constructor if you want.
>>     >>>>>>>>>>> I'm surprised it's needed though, as the default
>>     >>>>>>>>>>> instance
>>     >>>>>>>>>>> is
>>     >>>>>>>>>> already
>>     >>>>>>>>>>> used by the code if no value is provided for the
>>     >>>>>>>>>>> timeProvider
>>     >>>>>>>>>>> parameter of TransactionImpl.
>>     >>>>>>>>>>>
>>     >>>>>>>>>>> Florent
>>     >>>>>>>>>>>
>>     >>>>>>>>>>>
>>     >>>>>>>>>>> On Mon, Mar 22, 2021 at 5:49 PM Romain Manni-Bucau <
>>     >>>>>>>>>>> [email protected] <mailto:[email protected]>>
>>     wrote:
>>     >>>>>>>>>>>> Hi Richard,
>>     >>>>>>>>>>>>
>>     >>>>>>>>>>>> I still think SystemCurrentTime should have a
>>     >>>>>>>>>>>> public
>>     >>>>>>>>>>>> noarg
>>     >>>>>>>>>>>> constructor (or just drop the private one) since it
>>     >>>>>>>>>>>> will
>>     >>>>>>>>>>>> enable
>>     >>>>>>>>>>>> tomee to fully configure dynamically the tx mgr
>>     >>>>>>>>>>>> with
>>     >>>>>>>>>>>> this
>>     >>>>>>>>>>>> new
>>     >>>>>>>>>>>> feature but otherwise +1 to apply them all.
>>     >>>>>>>>>>>>
>>     >>>>>>>>>>>> Romain Manni-Bucau
>>     >>>>>>>>>>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>>     >>>>>>>>>>>> |
>>     >>>>>>>>>>>> Book
>>     >>>>>>>>>>>>
>>     >>>>>>>>>>>>
>>     >>>>>>>>>>>> Le lun. 22 mars 2021 à 17:03, Zowalla, Richard <
>>     >>>>>>>>>>>> [email protected]
>>     <mailto:[email protected]>> a écrit :
>>     >>>>>>>>>>>>> Hi all,
>>     >>>>>>>>>>>>>
>>     >>>>>>>>>>>>> wanted to raise attention on this again. 6792
>>     >>>>>>>>>>>>> would
>>     >>>>>>>>>>>>> be
>>     >>>>>>>>>>>>> very
>>     >>>>>>>>>> nice
>>     >>>>>>>>>>>>> as we
>>     >>>>>>>>>>>>> should allow TLS/SSL protocol versions for a
>>     >>>>>>>>>>>>> given
>>     >>>>>>>>>>>>> mail
>>     >>>>>>>>>> server
>>     >>>>>>>>>>>>> instead
>>     >>>>>>>>>>>>> of falling back to some hard-coded default.
>>     >>>>>>>>>>>>>
>>     >>>>>>>>>>>>> Gruss
>>     >>>>>>>>>>>>> Richard
>>     >>>>>>>>>>>>>
>>     >>>>>>>>>>>>> Am Mittwoch, den 24.02.2021, 09:33 +0100 schrieb
>>     >>>>>>>>>>>>> Romain
>>     >>>>>>>>>> Manni-
>>     >>>>>>>>>>>>> Bucau:
>>     >>>>>>>>>>>>>> Hi all,
>>     >>>>>>>>>>>>>>
>>     >>>>>>>>>>>>>> AFAIK we have a few pending patches to
>>     >>>>>>>>>>>>>> apply/issue
>>     >>>>>>>>>>>>>> to
>>     >>>>>>>>>> close:
>>     >>>>>>>>>>>>>> - [mail]
>>     >>>>>>>>>> https://issues.apache.org/jira/browse/GERONIMO-6792
>>     <https://issues.apache.org/jira/browse/GERONIMO-6792>:
>>     >>>>>>>>>>>>> update
>>     >>>>>>>>>>>>>> some defaults and config capacity
>>     >>>>>>>>>>>>>> - [mail]
>>     >>>>>>>>>> https://issues.apache.org/jira/browse/GERONIMO-6801
>>     <https://issues.apache.org/jira/browse/GERONIMO-6801>
>>     >>>>>>>>>>>>> and
>>     >>>>>>>>>>>>>>
>>     https://issues.apache.org/jira/browse/GERONIMO-6800
>>     <https://issues.apache.org/jira/browse/GERONIMO-6800>
>>     >>>>>>>>>> (setText)
>>     >>>>>>>>>>>>>> - [transaction-manager]
>>     >>>>>>>>>>>>>>
>>     https://issues.apache.org/jira/browse/GERONIMO-6805
>>     <https://issues.apache.org/jira/browse/GERONIMO-6805>
>>     >>>>>>>>>>>>>> :
>>     >>>>>>>>>>>>>> enable
>>     >>>>>>>>>> to
>>     >>>>>>>>>>>>> change
>>     >>>>>>>>>>>>>> the time evaluator impl
>>     >>>>>>>>>>>>>>
>>     >>>>>>>>>>>>>> If someone else can have a review it would be
>>     >>>>>>>>>>>>>> great
>>     >>>>>>>>>>>>>> (feel
>>     >>>>>>>>>> free
>>     >>>>>>>>>>>>> to
>>     >>>>>>>>>>>>>> apply the patch or I can do it after).
>>     >>>>>>>>>>>>>>
>>     >>>>>>>>>>>>>> note: some of the patches are waiting for some
>>     >>>>>>>>>>>>>> feedback
>>     >>>>>>>>>>>>>> -
>>     >>>>>>>>>> in
>>     >>>>>>>>>>>>>> particular txmgr one, wonder about tomee
>>     >>>>>>>>>>>>>> <resource>
>>     >>>>>>>>>>>>>> usage
>>     >>>>>>>>>> which
>>     >>>>>>>>>>>>> can
>>     >>>>>>>>>>>>>> need to remove the private constructor of the
>>     >>>>>>>>>>>>>> default
>>     >>>>>>>>>>>>>> impl
>>     >>>>>>>>>> to
>>     >>>>>>>>>>>>> enable
>>     >>>>>>>>>>>>>> to configure the impl completely.
>>     >>>>>>>>>>>>>>
>>     >>>>>>>>>>>>>> Thanks,
>>     >>>>>>>>>>>>>> Romain Manni-Bucau
>>     >>>>>>>>>>>>>> @rmannibucau |  Blog | Old Blog | Github |
>>     >>>>>>>>>>>>>> LinkedIn
>>     >>>>>>>>>>>>>> Book
>>
>>     -- 
>>     Jean-Baptiste Onofré
>>     [email protected] <mailto:[email protected]>
>>     http://blog.nanthrax.net <http://blog.nanthrax.net>
>>     Talend - http://www.talend.com <http://www.talend.com>
>>

Reply via email to