Re: Commons-email with jakarta.mail?

[Jean-Louis MONTEIRO]

Hi,

Jakarta Mail is under vote at the minute and should go out hopefully in a
few days.
https://www.eclipse.org/lists/jakarta.ee-spec/msg00788.html

Some work has been done on the Apache Geronimo side of things recently. Not
sure about the status though.

Le jeu. 3 sept. 2020 à 17:52, Xeno Amess  a écrit :

> 5.0.0 means this :
> https://github.com/eclipse-ee4j/servlet-api/releases/tag/5.0.0-RELEASE
> And I believe that is the first release who introduced new namespaces for
> jakarta.
> And as you've already noticed, there even be no jakarta-
> mail 2.0 release to use now.
> I don't think it worthy to maintain a thread based on some rc
> dependencies...
> I'd rather take actions when they really release.
> After all they (means jakarta-mail here) even do not have a clear roadmap
> for the 2.0 release, as far as I know...
>
> David Goodenough  于2020年9月3日周四 下午11:17写道：
>
> > On Thursday, 3 September 2020 15:58:53 BST Xeno Amess wrote:
> > >  > Is there a version of commons-email which uses
> > > >
> > > > the new jakarta-mail API rather than the old
> > > > javax.mail API?
> > >
> > > of course not.
> > > They just released 5.0.0, which use the new API, at just 4 days ago...
> > I was not expecting a final version, just a snapshot, like the 2.0-RC6
> > versions of jakarta-
> > mail currently on maven.  Not quite sure what you mean by 5.0.0?
> > >
> > > > If not is one planned?
> > >
> > > No ideas.
> >
> >
> >
>


-- 
Jean-Louis

Re: [FileUpload] Major version 2

[Jean-Louis MONTEIRO]

I'd say compile low and run high.
So unless there is really something you need from Java 17 or 21, why not
compiling lower?

It would open the release to be used more widely in my opinion.

Now I agree that making sure it runs on java 17 and 21 at least is great.

Le ven. 21 juil. 2023, 18:40, Glavo  a écrit :

> +1 for Java 17.
>
> Glavo
>
> On Fri, Jul 21, 2023 at 10:18 PM Gary Gregory 
> wrote:
>
> > Now that 2.0.0-M1 is out the door, let's talk about Java platform
> > requirements.
> >
> > I propose that for 2.0.0, FileUpload be bumped from Java 8 to 11, if not
> > 17.
> >
> > If you are going to ask why, see my reply in the [pool] thread
> > (https://lists.apache.org/thread/ngyrssxndklltzkoqfqx4n780h4b5vwk)
> >
> > Gary
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>

Re: Proposed Contribution to Apache Commons,

[Jean-Louis MONTEIRO]

Overall agree with the feedback.
I may have missed some emails in the thread, but did we get another email
from Norman to provide us with a bit more information?

Again I might have missed it. Apologies if so.

Jean-Louis

Le jeu 29 oct. 2015 06:34, Phil Steitz  a écrit :

> Thanks, Dave.
>
> Instructions below look good enough to me for the VOTE.  Will kick that
> off later today.
>
> Phil
>
> > On Oct 29, 2015, at 5:56 AM, Dave Brosius  wrote:
> >
> > git clone g...@github.com:NormanShapiro/Naomi.git
> > git checkout gh-pages
> >
> >
> > if you like, I already have a fork on github of it, I can merge gh-pages
> into master, and delete the gh-pages branch, and then the repo will be
> obviously just a one branch project.
> >
> >
> >
> >
> >
> >> On 10/28/2015 08:19 PM, Phil Steitz wrote:
> >> I am not seeing any -1s on this, so I would like to proceed with a
> >> VOTE to accept the code and start the IP clearance process.  For
> >> that I need a definitive snapshot of somewhere that I can point to
> >> for the VOTE and clearance docs.  My git-foo is pretty limited.  Can
> >> someone suggest a stable URL that we can use to identify the code
> >> that we will be accepting, should the VOTE pass?
> >>
> >> Thanks!
> >>
> >> Phil
> >>
> >>> On 10/25/15 12:25 PM, dbrosIus wrote:
> >>> +1 and git please
> >>>
> >>>  Original message 
> >>> From: Phil Steitz 
> >>> Date: 10/25/2015  3:15 PM  (GMT-05:00)
> >>> To: Commons Developers List 
> >>> Subject: Re: Proposed Contribution to Apache Commons,
> >>>
>  On 10/2/15 12:08 PM, Gary Gregory wrote:
>  Well, a champion can volunteer to shepherd this through our incubator
> I
>  suppose,
> >>> OK, I will volunteer to do this.  I propose that we start this as a
> >>> Commons Sandbox project.  To do that, we need a VOTE to accept the
> >>> code, a software grant and the IP clearance form [1] submitted to
> >>> the Incubator PMC.  We can use either git or svn for the new sandbox
> >>> repo.
> >>>
> >>> Any objections?  Any preference for git or svn?
> >>>
> >>> Phil
> >>>
> >>> [1]
> http://incubator.apache.org/ip-clearance/ip-clearance-template.html
> >>>
> >>>
>    like CommonsRDF, which seems pretty inactive ATM. There is also
>  the issue of "donate and forget" vs. staying plugged in the community.
> 
>  I just do not have the extra FOSS cycles to dig into the code ATM to
> see
>  what's under the hood.
> 
>  Gary
> 
> > On Fri, Oct 2, 2015 at 12:01 PM, Phil Steitz 
> wrote:
> >
> >> On 10/2/15 11:46 AM, Gary Gregory wrote:
> >> I do not have time to dig into this one ATM but I'd like to give my
> 2c.
> >>
> >> Does this project introduce a new RE-like language or is it an API
> > wrapper
> >> for REs? It sounds like it is both.
> > It looks to me like what it says it is, which is an alternative to
> > REs, which IMO is a nice idea.  Less "pattern matching language" and
> > more objects expressing matching intent.  End result is less
> > developer thought required to accomplish a common task.  Seems to
> > fit nicely in Commons to me.
> >
> > Phil
> >> A project like this I could see in Commons if the project was split
> into
> > an
> >> API module and modules for different pattern matching languages,
> where
> > the
> >> standard Java RE would be the reference example. Naomi (I love the
> name
> >> BTW, someones wife or daughter?) would be another implementation
> module.
> >> With both under its belt, the project would be on fairly solid
> footing
> >> (granted I do not know Naomi). You could even imaging
> implementations
> > that
> >> would accept a JXPath or a SQL WHERE clause.
> >>
> >> If the project is only meant to introduce a new RE-like language,
> then a
> >> TLP would be probably more appropriate.
> >>
> >> 2c,
> >> Gary
> >>
> >> On Thu, Oct 1, 2015 at 11:58 PM, Henri Yandell 
> > wrote:
> >>> On Tue, Sep 29, 2015 at 5:42 PM, Phil Steitz <
> phil.ste...@gmail.com>
> >>> wrote:
> >>>
> > On 9/29/15 3:55 PM, Gary Gregory wrote:
> > Norman,
> >
> > Hello and welcome to Apache Commons.
> >
> > It's not clear to me why Naomi is better than regular
> expressions.
>  Pointing
> > to Javadocs is not the best way to get traction.
> >
> > Your project would be better served by having some documentation
> on
> >>> your
> > front page with an example driven tutorial.
> >
> > Is Naomi faster than REs?
> >
> > What can I do in Naomi that REs can't do? And vice-versa.
> >
> > Examples of this on your front page would help you at least get
> folks
> >>> to
> > consider learning a brand new way of doing things...
>  +1
>  The code in SimpleExamples starts to get to this.  Looks
> interesting
> 

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

Fwd: Maintenance release for JCS 2.2

[Jean-Louis MONTEIRO]

Hi,

I am currently facing performance issues with the CDI integration because
of the reflection.
I have successfully tested the patch from Romain and would like to know if
there is a maintenance release planned soon?

Thanks
Jean-Louis

Re: Maintenance release for JCS 2.2

[Jean-Louis MONTEIRO]

Yes a 2.2.1 would be awesome.
Thanks guys.

Lemme know if there is anything I can do to help

On mar. 19 sept. 2017 à 08:54 Romain Manni-Bucau 
wrote:

> Hi JL,
>
> I'm planning to work on it this week-end or next week (depending how long
> it will be to setup my new computer).
>
> Will probably be a 2.2.1 from a branch from the previous discussions we had
> so we will need to backport the changes but nothing blocking.
>
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog
> <https://blog-rmannibucau.rhcloud.com> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | JavaEE Factory
> <https://javaeefactory-rmannibucau.rhcloud.com>
>
> 2017-09-18 18:29 GMT+02:00 Gary Gregory :
>
> > Hi,
> >
> > JCS 2.2 is out already: https://commons.apache.org/proper/commons-jcs/
> >
> > Do you mean the _next_ release?
> >
> > Gary
> >
> > On Mon, Sep 18, 2017 at 9:28 AM, Jean-Louis MONTEIRO  >
> > wrote:
> >
> > > Hi,
> > >
> > > I am currently facing performance issues with the CDI integration
> because
> > > of the reflection.
> > > I have successfully tested the patch from Romain and would like to know
> > if
> > > there is a maintenance release planned soon?
> > >
> > > Thanks
> > > Jean-Louis
> > >
> >
>

Apache Commons Monitoring write access

[Jean-Louis MONTEIRO]

Hi guys,

I've been working on Apache Commons Monitoring (from the sandbox/trunk).
I did some fixes and would like to push others.
I'm also working on a new feature.

After discussing with Romain and Mark, they asked me to push a mail here.
Would it be possible to get write access to the sandbox sub tree?

My Apache id is jlmonteiro.

Thanks

-- 
Jean-Louis

Re: Apache Commons Monitoring write access

[Jean-Louis MONTEIRO]

Thanks a lot.
Yes, gonna try to push a small fix.

Jean-Louis


2013/9/2 Luc Maisonobe 

> Le 02/09/2013 13:14, Jean-Louis MONTEIRO a écrit :
> > Hi guys,
> >
> > I've been working on Apache Commons Monitoring (from the sandbox/trunk).
> > I did some fixes and would like to push others.
> > I'm also working on a new feature.
> >
> > After discussing with Romain and Mark, they asked me to push a mail here.
> > Would it be possible to get write access to the sandbox sub tree?
> >
> > My Apache id is jlmonteiro.
>
> I have added you to the list. could you check it works?
>
> best regards,
> Luc
>
> >
> > Thanks
> >
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Jean-Louis

Re: Apache Commons Monitoring write access

[Jean-Louis MONTEIRO]

Works fine.
Commit #1519417

Thanks again.
Jean-Louis


2013/9/2 Jean-Louis MONTEIRO 

> Thanks a lot.
> Yes, gonna try to push a small fix.
>
> Jean-Louis
>
>
> 2013/9/2 Luc Maisonobe 
>
>> Le 02/09/2013 13:14, Jean-Louis MONTEIRO a écrit :
>> > Hi guys,
>> >
>> > I've been working on Apache Commons Monitoring (from the sandbox/trunk).
>> > I did some fixes and would like to push others.
>> > I'm also working on a new feature.
>> >
>> > After discussing with Romain and Mark, they asked me to push a mail
>> here.
>> > Would it be possible to get write access to the sandbox sub tree?
>> >
>> > My Apache id is jlmonteiro.
>>
>> I have added you to the list. could you check it works?
>>
>> best regards,
>> Luc
>>
>> >
>> > Thanks
>> >
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>>
>
>
> --
> Jean-Louis
>



-- 
Jean-Louis

Re: svn commit: r1528612 - /commons/sandbox/monitoring/trunk/reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java

[Jean-Louis MONTEIRO]

Apologize for the late answer.
Not sure to understand the purpose of the request.
Could you detail cause it's not used anywhere else?

JLouis


2013/10/3 sebb 

> On 2 October 2013 21:12,   wrote:
> > Author: jlmonteiro
> > Date: Wed Oct  2 20:12:29 2013
> > New Revision: 1528612
> >
> > URL: http://svn.apache.org/r1528612
> > Log:
> > Fixing configuration property typo
> >
> > Modified:
> >
> commons/sandbox/monitoring/trunk/reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java
> >
> > Modified:
> commons/sandbox/monitoring/trunk/reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java
> > URL:
> http://svn.apache.org/viewvc/commons/sandbox/monitoring/trunk/reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java?rev=1528612&r1=1528611&r2=1528612&view=diff
> >
> ==
> > ---
> commons/sandbox/monitoring/trunk/reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java
> (original)
> > +++
> commons/sandbox/monitoring/trunk/reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java
> Wed Oct  2 20:12:29 2013
> > @@ -35,7 +35,7 @@ public final class PluginRepository {
> >  if (name == null) {
> >  throw new IllegalArgumentException("plugin name can't
> be null");
> >  }
> > -if (!Configuration.is(name + "activated", true)) {
> > +if (!Configuration.is(name + ".activated", true)) {
>
> I assume that this string is used elsewhere within monitoring?
> If so, it should be defined once as a String constant (with Javadoc)
> and used throughout.
> Or there could be a method to convert a name by appending the suffix.
>
> >  continue;
> >  }
> >
> >
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Jean-Louis

Re: svn commit: r1528612 - /commons/sandbox/monitoring/trunk/reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java

[Jean-Louis MONTEIRO]

Hey guys,

I don't want to interrupt such an interesting discussion.
I just wanted to fix a typo I caught up.

If creating a constant with the right javadoc is ok, let's just do it,
there is no big issue on that.
Lemme me know if the following works.

jlmonteiro$ svn ci -m "Adding a constant for the activation flag."
reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java
Sending
 
reporting/src/main/java/org/apache/commons/monitoring/reporting/web/plugin/PluginRepository.java
Transmitting file data .
Committed revision 1529670.

JLouis


2013/10/5 Christian Grobmeier 

> On 5 Oct 2013, at 14:29, James Carman wrote:
>
>  On Sat, Oct 5, 2013 at 7:03 AM, Benedikt Ritter 
>> wrote:
>>
>>>
>>> I'm not sure I agree with all of your points. Yes, the sandbox is a
>>> place to try new ideas out. Does this mean certain quality criterions do
>>> not apply? I don't think so. This all has to be corrected before promotion,
>>> so why not make it correct right from the start?
>>>
>>>
>> Sometimes it helps people to get their ideas down and working without
>> worrying about "correctness."  That's why writers have a rough draft,
>> after all.  The creative process is best left unencumbered when
>> nurturing a new idea.  The sandbox is all about letting folks work on
>> an idea they have.  It's a *sandbox*!  Yes, it does mean that certain
>> quality criteria do not apply, until the point when the component
>> wishes to graduate to "proper."  At that point, we can put on our
>> white gloves and go over every last line (or look at Sonar reports) if
>> we wish.
>>
>>  Is pointing out that something may be improved nit-picking? Well, I
>>> think it depends :-) Just sending a -1 for a commit like this would
>>> definitely be. In this case an improvement has been pointed out. I'm more
>>> then happy for feedback like this, because it helps me become a better
>>> developer. And in the end, discussing commits is part of the game ;-)
>>>
>>>
>> Yes, in a sandbox environment, pointing out a small "magic string"
>> infraction is nit-picking.  Leave the authors alone and let them work
>> through their ideas.  If you want to help out with the code, jump in
>> and help.  It takes longer to write an email and participate in the
>> back-and-forth that ensues than it does to just fix it yourself.  For
>> issues like this, we really need to be using a tool like Sonar.  Sonar
>> will objectively look at the code for infractions such as this (among
>> many others).  The author can then look at the Sonar reports and see
>> areas that might need improvement at their leisure (the group will
>> also do so before graduating the component to proper).  The other
>> great thing about Sonar is that it has verbiage in there about why the
>> rule is a rule and what can be done to fix the issue, so it's also a
>> teaching tool.  Most likely, the author fully understands why it's bad
>> to have "magic strings" in their code, but just wanted to get their
>> ideas into code and working before worrying about such issues.  They
>> can clean it up later (or some of us can jump in and help).
>>
>> This is the exact reason that I personally would *never* start a new
>> project here at Commons again.  I would invite certain colleagues to
>> collaborate on github or something and then later bring the code into
>> the organization.
>>
>
> I am very sorry to say that I feel pretty similar.
>
> Commons is a lot on nit-picking. It once was an innovating place.
> But often we discuss to many formalities or jdk 1.3 vs 1.5 vs 1.7 instead
> of just making releases. Working at Commons is pretty much complicated.
> It starts with a super complicated black magic parent pom and ends with
> discussing
> the value magic strings in the sandbox.
>
> I see your point Dominik. We need to discuss commits. But not at any time,
> often not in the sandbox and not at any place.
>
> We are slow. Guava isn't slow. That's why more and more people walk over
> to that place.
> The way to long discussion on using annotation in Commons Collections is a
> good example.
>
> Just want to say, the topic has changed. If anybody has the energy to
> change the subject, it's the right time.
>
>
> --**--**-
> To unsubscribe, e-mail: 
> dev-unsubscribe@commons.**apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Jean-Louis

Re: [DISCUSS] Mission Statement for Commons...

[Jean-Louis MONTEIRO]

+1, looks like there are plenty of examples.
Agree with Phil, how could we make things lighter or easier?

I mean to get more release out.

Jean-Louis


2013/10/6 Phil Steitz 

>
>
> > On Oct 6, 2013, at 1:11 PM, Oliver Heger 
> wrote:
> >
> > Hi Christian,
> >
> > Am 06.10.2013 21:44, schrieb Christian Grobmeier:
> >> James,
> >>
> >> thank you.
> >>
> >> I believe Commons is in a bad shape.
> >>
> >> Look at Commons Collections. Before 4 years somebody
> >> said Guava is more modern, he his answer seems to be widely accepted.
> >> http://stackoverflow.com/a/167/690771
> >> This guy said we have no generics. What did we do in the past 4 years?
> >>
> http://search.maven.org/#search%7Cgav%7C1%7Cg%3A%22commons-collections%22%20AND%20a%3A%22commons-collections%22
> >>
> >>
> >> Nothing. At least nothing visible. Its fine we have a beta. I wonder why
> >> we haven't managed
> >> to officially release this? The last release is from 2008.
> >>
> >> I did consider to put my JSON component to Commons. But I didn't.
> >> Reason: I really need the component
> >> and I calculated how long it would take to release it here. I thought,
> >> it's not helping me
> >> to develop it here. I simply don't have the time.
> >>
> >> I thought a long while about it.
> >>
> >> We had discussions like: do we really need Generics? It works without!
> >> Do we really drop an outdated JDK? We might have users
> >> who run JDK 1.3! And so on. Finally this led us to the situation where
> >> almost all of our users seem to have JDK 1.3 and
> >> are not interested in generics - in 2013. The users who want modern
> >> features go to Guava. We maintain legacy code. And seriously, a lot of
> >> code works without generics. This is no reason to not include them.
> >>
> >> We discuss magic strings in the sandbox. Why? We don't need to discuss
> >> that. Before we release we can simply check Sonar. Safe the time to
> >> discuss. Fix it or leave it to Sonar to report it.
> >>
> >> We seem to think perfect documentation is more valuable then quick
> >> releases. Is it?
> >>
> >> We seem to be proud of our build. I am not. It's complex. It's no fun.
> >> Releases should be do-able in a short time, maybe
> >> even automated.
> >>
> >> It is so sad that lot of good features like Collections with Generics
> >> were blocked such a long time or drowning in discussions.
> >>
> >> I agree we should support old users. But if we don't have the manpower,
> >> we can't support them. They need to accept we are moving on. We are
> >> blocked with our backwards compatible ideas and innovation is far away.
> >>
> >> When I spoke to young developers about Commons they asked me if it still
> >> exists. Nobody of them is interested in our community.
> >>
> >> For the mission statement I would wish to see things like that:
> >>
> >> Commons Components…
> >>
> >> …are released quickly and often
> >> …do use modern JDKs and support old JDKs only as long as they are
> >> supported by Oracle
> >> …we make use of modern Java features when they are available
> >> …can be easily released
> >> …can be released without having 100% perfect documentation or perfect
> >> implementations
> >> …are build by Community who wants to learn, experiment and create new
> >> features more than by Community which wants to be backwards compatible
> >> for a long time
> >> …are allowed to release major versions with api breaks as they want
> >>
> >> Cheers
> >> Christian
> > I agree with many of your points. Another example is [csv] which is
> > about to be released for ages. Here, I think, the main impediment is
> > that we try to come up with a *perfect* API because due to our rules of
> > backwards compatibility it is so difficult to correct any mistakes later.
> >
> > I still think that backwards compatibility is very important, but we
> > really should define a process which allows us to experiment with new
> APIs.
> >
> > As a suggestion to improve this situation, could we agree on an alpha
> > release process allowing us to push releases with the aim of getting
> > community feedback? Where we explicitly state that incompatible changes
> > are possible (and likely)?
> >
> > We did something similar with [collections] 4, but there were many
> > limitations (the release was not allowed to be uploaded to Maven central
> > for instance). If we did such experimental releases more often, there
> > would hopefully not be the fear of defining a broken API, and we would
> > see more releases.
>
> +1 let's agree on how to do alphas.
>
> Phil
> >
> > Oliver
> >
> >>
> >>> On 6 Oct 2013, at 20:30, James Carman wrote:
> >>>
> >>> All,
> >>>
> >>> The Apache Commons project seems to be languishing as of late and we
> >>> need some rejuvenation.  Perhaps we should try to define our mission
> >>> as a project.  What are our goals?  What do we want to accomplish?
> >>> Who are our users/customers?  What non-functional qualities do we want
> >>> our software to exhibit?  How do we want to conduct

Re: [DISCUSS] Mission Statement for Commons...

[Jean-Louis MONTEIRO]

Hi Jochen,

Well summarized.
And I think you figured out what the real problem is.

We could work as in Incubator, isn't it?
Having one big umbrella and real subprojects.



JLouis


2013/10/7 Jochen Wiedmann 

> I believe that the problem is Commons structure. To have one big project
> which such a lot of subprojects blocks building a small community. You're
> not supposed to be a part of the small subproject, but the big community
> "Commons". While the former would be appealing for a newcomer, the latter
> just doesn't work (too many unknown people).
>
> I have no alternatives to offer, but my feeling is we should attempt to
> build smaller, more centralized parts with separate mailing lists, etc.
> Obviously, this might lead to a Jakarta-ization, but there are worse things
> than being split into subprojects.
>
>
>
>
>
> On Sun, Oct 6, 2013 at 8:30 PM, James Carman  >wrote:
>
> > All,
> >
> > The Apache Commons project seems to be languishing as of late and we
> > need some rejuvenation.  Perhaps we should try to define our mission
> > as a project.  What are our goals?  What do we want to accomplish?
> > Who are our users/customers?  What non-functional qualities do we want
> > our software to exhibit?  How do we want to conduct ourselves?  How
> > often do we want to do releases?  What else?
> >
> > Sincerely,
> >
> > James
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> > For additional commands, e-mail: dev-h...@commons.apache.org
> >
> >
>
>
> --
> "That's what prayers are ... it's frightened people trying to make friends
> with the bully!"
>
> Terry Pratchett. The Last Hero
>



-- 
Jean-Louis

[jira] Created: (DBCP-297) Ciphered passwords

[Jean-Louis MONTEIRO]

Hi,

As discussed here some weeks ago in OpenEJB dev's list, I finally decided to
add this feature in commons dbcp because it seemed to me more relevant
(instead of having it in OpenEJB itself).

Any feedback ?
Jean-Louis

-Message d'origine-
De : Jean-Louis MONTEIRO (JIRA) [mailto:j...@...]
Envoyé : mercredi 15 juillet 2009 11:31
À : Monteiro Jean-Louis
Objet : [jira] Created: (DBCP-297) Ciphered passwords

Ciphered passwords
--

 Key: DBCP-297
 URL: https://issues.apache.org/jira/browse/DBCP-297
 Project: Commons Dbcp
  Issue Type: New Feature
 Environment: All
Reporter: Jean-Louis MONTEIRO
 Fix For: 1.4


It would be nice to allow ciphered passwords with pluggable codec
mechanisms. 
-- 
View this message in context: 
http://www.nabble.com/-jira--Created%3A-%28DBCP-297%29-Ciphered-passwords-tp24506436p24506436.html
Sent from the Commons - Dev mailing list archive at Nabble.com.


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

Re: [jira] Created: (DBCP-297) Ciphered passwords

[Jean-Louis MONTEIRO]

Hi guys,

any news ?

Jean-Louis


Jean-Louis MONTEIRO wrote:
> 
> Hi,
> 
> As discussed here some weeks ago in OpenEJB dev's list, I finally decided
> to add this feature in commons dbcp because it seemed to me more relevant
> (instead of having it in OpenEJB itself).
> 
> Any feedback ?
> Jean-Louis
> 
> -----Message d'origine-
> De : Jean-Louis MONTEIRO (JIRA) [mailto:j...@...]
> Envoyé : mercredi 15 juillet 2009 11:31
> À : Monteiro Jean-Louis
> Objet : [jira] Created: (DBCP-297) Ciphered passwords
> 
> Ciphered passwords
> --
> 
>  Key: DBCP-297
>  URL: https://issues.apache.org/jira/browse/DBCP-297
>  Project: Commons Dbcp
>   Issue Type: New Feature
>  Environment: All
> Reporter: Jean-Louis MONTEIRO
>  Fix For: 1.4
> 
> 
> It would be nice to allow ciphered passwords with pluggable codec
> mechanisms. 
> 

-- 
View this message in context: 
http://www.nabble.com/-jira--Created%3A-%28DBCP-297%29-Ciphered-passwords-tp24506436p25112826.html
Sent from the Commons - Dev mailing list archive at Nabble.com.


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

Re: [jcs] jcache support?

[Jean-Louis MONTEIRO]

+1, that'd be awesome.
I don't think it's a big word/rework. Crossing fingers, it's just a matter
of some interfaces and an SPI to implement.

JLouis


2014-04-21 20:39 GMT+02:00 Thomas Vandahl :

> On 21.04.14 19:06, Romain Manni-Bucau wrote:
> > saw it, I can rephrase the question this way: will tomee be able to
> > rely on jcs or should we directly use ehcache as do cxf already for
> > other needs.
> >
> > I'd like to see an apache product in the box but not sure we'll find
> > enough time to make it real short term
> >
>
> Me too. I think it should be not too hard and the 2.0 release is
> certainly a good milestone to work on this. At the moment, however, I
> maintain this project pretty much alone and I have no idea what JCache
> means and how it is related to the current architecture of JCS.
> I'm willing to help as much as I can.
>
> Bye, Thomas.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Jean-Louis

Re: [jcs] jcache support?

[Jean-Louis MONTEIRO]

You mean move to the sandbox area to work more easily on JCache
specification implementation.
And maybe try to get JCS to incubator and then try to promote to TLP?

Not sure I got all your points.

JLouis


2014-04-25 8:43 GMT+02:00 Romain Manni-Bucau :

> Did some more work ( still attached to
> https://issues.apache.org/jira/browse/JCS-118 - side note: i didnt
> recheck defaults tests here so maybe seomthing is broken regarding the
> configuration I changed a bit as mentionned in a comment )
>
> The question at this point is how to go ahead? My main issue is while
> we don't have a fully working patch how can we share changes. Not sure
> patches are the best solution. [sandbox] could be since we are more to
> have perms.
>
> wdyt?
>
>
> Romain Manni-Bucau
> Twitter: @rmannibucau
> Blog: http://rmannibucau.wordpress.com/
> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> Github: https://github.com/rmannibucau
>
>
> 2014-04-22 9:41 GMT+02:00 Jean-Louis MONTEIRO :
> > +1, that'd be awesome.
> > I don't think it's a big word/rework. Crossing fingers, it's just a
> matter
> > of some interfaces and an SPI to implement.
> >
> > JLouis
> >
> >
> > 2014-04-21 20:39 GMT+02:00 Thomas Vandahl :
> >
> >> On 21.04.14 19:06, Romain Manni-Bucau wrote:
> >> > saw it, I can rephrase the question this way: will tomee be able to
> >> > rely on jcs or should we directly use ehcache as do cxf already for
> >> > other needs.
> >> >
> >> > I'd like to see an apache product in the box but not sure we'll find
> >> > enough time to make it real short term
> >> >
> >>
> >> Me too. I think it should be not too hard and the 2.0 release is
> >> certainly a good milestone to work on this. At the moment, however, I
> >> maintain this project pretty much alone and I have no idea what JCache
> >> means and how it is related to the current architecture of JCS.
> >> I'm willing to help as much as I can.
> >>
> >> Bye, Thomas.
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> >> For additional commands, e-mail: dev-h...@commons.apache.org
> >>
> >>
> >
> >
> > --
> > Jean-Louis
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>


-- 
Jean-Louis

Re: [jcs] jcache support?

[Jean-Louis MONTEIRO]

+1 Olivier
Thx


2014-04-28 7:02 GMT+02:00 Romain Manni-Bucau :

> +1
>
> Open question is jcs-jcache instead of jcs-tck (and jcache tests = tcks). I
> think it makes sense to extract it
> Le 28 avr. 2014 00:47, "Olivier Lamy"  a écrit :
>
> > BTW the ideal would be to use modules in the build as:
> > commons-jcs
> >   commons-jcs-core
> >   commons-jcs-tck
> >
> > Any issues with changing the structure?
> >
> > Olivier
> >
> > On 28 April 2014 09:32, Olivier Lamy  wrote:
> > > Hi,
> > > I will have a look at the pr. Then move to defaut maven sources
> > directories.
> > >
> > > *NOTE*: jsr 107 is java 1.7 required. (just before someone complain :-)
> > ).
> > >
> > > Then I agree on moving to incubator.
> > >
> > >
> > >
> > > On 27 April 2014 19:10, Romain Manni-Bucau 
> > wrote:
> > >> side note: do we plan - after jcache first support please otherwise
> > >> merge will be a pain - to align project structure on the default maven
> > >> one (src/main/java, src/main/resources, src/test/java,
> > >> src/test/resources)?
> > >>
> > >> would surely be easier for any new volunteer.
> > >>
> > >>
> > >> Romain Manni-Bucau
> > >> Twitter: @rmannibucau
> > >> Blog: http://rmannibucau.wordpress.com/
> > >> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >> Github: https://github.com/rmannibucau
> > >>
> > >>
> > >> 2014-04-26 19:31 GMT+02:00 Romain Manni-Bucau  >:
> > >>> forked https://github.com/rmannibucau/commons-jcs,
> > >>>
> > >>>
> > >>> still some work to make TCKs passing (first step) then make it usable
> > >>> (think we'll pass tck in local mode then we need to make them
> > >>> distributed friendly).
> > >>>
> > >>> current status:
> > >>> Tests run: 465, Failures: 70, Errors: 22, Skipped: 0
> > >>>
> > >>> PS: can be run using tck.sh
> > >>>
> > >>>
> > >>> Romain Manni-Bucau
> > >>> Twitter: @rmannibucau
> > >>> Blog: http://rmannibucau.wordpress.com/
> > >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >>> Github: https://github.com/rmannibucau
> > >>>
> > >>>
> > >>> 2014-04-25 15:10 GMT+02:00 Romain Manni-Bucau  >:
> > >>>> Ok, will try.
> > >>>>
> > >>>> Thanks
> > >>>>
> > >>>>
> > >>>> Romain Manni-Bucau
> > >>>> Twitter: @rmannibucau
> > >>>> Blog: http://rmannibucau.wordpress.com/
> > >>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >>>> Github: https://github.com/rmannibucau
> > >>>>
> > >>>>
> > >>>> 2014-04-25 14:24 GMT+02:00 Siegfried Goeschl :
> > >>>>> Hi folks,
> > >>>>>
> > >>>>> don't know the official view of things (current ASF Git support)
> but
> > I use
> > >>>>> GitHub to work on refactoring since it allows broader contribution
> > (only
> > >>>>> GitHub account is required)
> > >>>>>
> > >>>>> Cheers,
> > >>>>>
> > >>>>> Siegfried Goeschl
> > >>>>>
> > >>>>>
> > >>>>> On 25.04.14 09:28, Romain Manni-Bucau wrote:
> > >>>>>>
> > >>>>>> yep was the idea.
> > >>>>>>
> > >>>>>> promoting jcs to incubator would definively be great.
> > >>>>>>
> > >>>>>> The short term question and sandbox reference was more: how can we
> > >>>>>> work together on tcks. Using patches makes it hard (you need to
> > merge
> > >>>>>> all patches etc if several people are contributing).
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> Romain Manni-Bucau
> > >>>>>> Twitter: @rmannibucau
> > >>>>>> Blog: http://rmannibucau.wordpress.com/
> > >>>>>> LinkedIn: http://fr.linkedin.com/in/rmannibucau
> > >>>>&

Re: [jcs] building with JSR-107 TCK

[Jean-Louis MONTEIRO]

I have a compilation issue FYI, either with jdk6 or jdk7

JLouis


2014-05-01 18:43 GMT+02:00 Mark Struberg :

> Hi!
>
> I've looked at Continuum and it seems like it fails since weeks now.
>
> Anyone successfully did run it with jdk-1.6?
>
>
> If so, we should rather look at the Continuum config.
>
>
> LieGrue,
> strub
>
>
>
>
>
> > On Thursday, 1 May 2014, 16:39, Thomas Vandahl  wrote:
> > > On 01.05.14 09:52, Mark Struberg wrote:
> >
> >>  Hi folks!
> >>
> >>  I've moved the TCK run into an own profile. You can activate it via
> >>
> >>  $> mvn clean install -PjcacheTck
> >>
> >>  We should also activate it by default during a release.
> >>
> >>  Btw, why is this project target 1.7? We do not use anything from java7
> > right?
> >
> > For some reason, The Test(TM) is failing again on Continuum. Is it
> > possible that this has something to do with you latest modifications?
> >
> > One more question regarding the Continuum build. Obviously, the build
> > deploys a snapshot into the snapshot repository. If you look at
> >
> http://repository.apache.org/content/groups/snapshots/org/apache/commons/commons-jcs/2.0-SNAPSHOT/
> > almost everything is there, just the jar is missing. Any idea why this
> > happens?
> >
> > Bye, Thomas.
> >
> >
> >
> > -
> > 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
>
>


-- 
Jean-Louis

Re: [jcs] building with JSR-107 TCK

[Jean-Louis MONTEIRO]

He he, sure :)

Here is the error even in Java 7.
ERROR]
/Users/jlmonteiro/devs/asf/commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java:[92,129]
cannot find symbol
  symbol:   class MyThreadFactory
  location: class org.apache.commons.jcs.utils.threadpool.ThreadPoolManager
[ERROR]
/Users/jlmonteiro/devs/asf/commons/proper/jcs/trunk/commons-jcs-jcache/src/main/java/org/apache/commons/jcs/jcache/JCSCache.java:[93,68]
cannot find symbol
  symbol:   class MyThreadFactory
  location: class org.apache.commons.jcs.utils.threadpool.ThreadPoolManager

JLouis


2014-05-02 7:07 GMT+02:00 Romain Manni-Bucau :

> Hey JL, nice to know better to have details ;). When I checked yesterday
> Mark didnt commit his work and the missing parts of my patch which should
> be merged so I guess it will be fixed soon.
> Le 1 mai 2014 23:18, "Jean-Louis MONTEIRO"  a écrit :
>
> > I have a compilation issue FYI, either with jdk6 or jdk7
> >
> > JLouis
> >
> >
> > 2014-05-01 18:43 GMT+02:00 Mark Struberg :
> >
> > > Hi!
> > >
> > > I've looked at Continuum and it seems like it fails since weeks now.
> > >
> > > Anyone successfully did run it with jdk-1.6?
> > >
> > >
> > > If so, we should rather look at the Continuum config.
> > >
> > >
> > > LieGrue,
> > > strub
> > >
> > >
> > >
> > >
> > >
> > > > On Thursday, 1 May 2014, 16:39, Thomas Vandahl 
> wrote:
> > > > > On 01.05.14 09:52, Mark Struberg wrote:
> > > >
> > > >>  Hi folks!
> > > >>
> > > >>  I've moved the TCK run into an own profile. You can activate it via
> > > >>
> > > >>  $> mvn clean install -PjcacheTck
> > > >>
> > > >>  We should also activate it by default during a release.
> > > >>
> > > >>  Btw, why is this project target 1.7? We do not use anything from
> > java7
> > > > right?
> > > >
> > > > For some reason, The Test(TM) is failing again on Continuum. Is it
> > > > possible that this has something to do with you latest modifications?
> > > >
> > > > One more question regarding the Continuum build. Obviously, the build
> > > > deploys a snapshot into the snapshot repository. If you look at
> > > >
> > >
> >
> http://repository.apache.org/content/groups/snapshots/org/apache/commons/commons-jcs/2.0-SNAPSHOT/
> > > > almost everything is there, just the jar is missing. Any idea why
> this
> > > > happens?
> > > >
> > > > Bye, Thomas.
> > > >
> > > >
> > > >
> > > > -
> > > > 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
> > >
> > >
> >
> >
> > --
> > Jean-Louis
> >
>



-- 
Jean-Louis

Re: [pool] Usage of logging API in common-pool ?

[Jean-Louis MONTEIRO]

Hey guys,

As Gary, I did also some AOP tricks to gather information from POOL and
DBCP.
It works fine, but agree that some more configurable logging would help.

In regards to the right logging implementation or the right facade to use,
I'd say, none.
Why not just using JUL?

It comes from the JDK so no additional lib, as I fully understand Phil's
point (in Apache TomEE for instance).
In latest JDK versions (5 and following), it proved to be a good choice and
in many projects I'm involved to, we have been using only JUL.
No facade because each one think it's the best until the next one comes out
;-)
No impl, cause obviously it's never the one user wants.

There are some bridge between JUL and the most well known impl, so that's
why I think it's a good balance.

Hope it helps.
Jean-Louis


2014-07-20 17:06 GMT+02:00 Phil Steitz :

> On 7/20/14, 7:54 AM, Phil Steitz wrote:
> > On 7/19/14, 5:45 PM, Gary Gregory wrote:
> >> I just had a case today actually, where I had to unroll
> PoolUtils.prefill
> >> and add logging before each call to addObject().
> > Why?
> >
> > Nine times out of ten, when you think you need logging when using
> > [pool], you can get what you need by instrumenting *your* factory.
> > In pool2, you also have all of the lifecycle stuff in the
> > PooledObjects and the JMX instrumentation.
> >
> >>  Quite a shame to be forced
> >> to do that because pool does not log. In the end, this helped me debug
> my
> >> problem but now, I'm leave the code unrolled of course. IMO, pool is a
> >> mid-level component that should log; and do so with Log4j 2.
> > If [pool] is midlevel, what exactly is low-level?  Pool is depended
> > on by lots of projects for a pretty simple, low-level function and
> > it has no dependencies itself.  Performance and lightweight
> > deployment are important.  In 2.0, we have added good JMX
> > instrumentation and I think with the right listeners, we should be
> > able to handle everything but the few internal corner cases like
> > OOMEs that write to System.err in the current code.  Adding a
> > logging dependency just for these seems a shame to me.   If we
> > decide we have to add something, it should be commons-logging, for
> > consistency with [dbcp] and for the same reasons that choice was
> > made [1].  I would really like to avoid it, if possible, though.
> >
> > [1] http://markmail.org/images/permalink.gif
>
> Oops! should be
> [1] http://markmail.org/message/j2vmk4uidb3uuv6k
> >
> > Phil
> >> Gary
> >>
> >>
> >> On Sat, Jul 19, 2014 at 6:35 PM, Phil Steitz 
> wrote:
> >>
> >>> On 7/18/14, 2:18 PM, Anthony Communier wrote:
>  Hello,
> 
>  There are some parts of the code that use printStackTrace in order to
> >>> show
>  errors. It means that it's difficult to have control on how log will
> be
>  produced. Those stacks will mainly go to application server logs and
> not
>  directly into application logs if an application server is used (like
>  tomcat, Jboss, ..). That's why I suggest to use logging API, like
> other
>  libraries
> 
>  I have posted an issue in Jira POOL-266 (
>  https://issues.apache.org/jira/browse/POOL-266). Phil Steitz added a
>  comment on the issue (Today 21:1)
> 
>  "The reason that we don't use a logging API is to avoid introducing a
>  dependency. If we do go that route, we should be consistent with DBCP
> and
>  use commons-logging. I am not sure we really want to go this way,
> >>> though. I
>  am more inclined to support the suggestion in POOL-267. It would be
> >>> better
>  to discuss these things on the commons dev mailing list."
> >>> Unfortunately, the POOL-267 approach works only for the abandoned
> >>> instance tracking part.  I had forgotten that we have in fact added
> >>> some printStackTraces for errors (sort of extreme cases, but
> >>> still...) in 2.x.  We need a solution for these as well.  See [1]
> >>> for previous discussion of this topic.
> >>>
> >>> Now that we cut 2.x releases, we obviously have to think about
> >>> compatibility.  I think the listeners stuff should be able to be
> >>> done compatibly; but adding a dependency is probably not something
> >>> we want to do in a dot release.
> >>>
> >>> What would be great would be a way to add listeners / configuration
> >>> options that would make it possible for users to pipe trace info to
> >>> whatever persistence mechanisms they want.  We have talked about
> >>> this in the past, but never settled on an approach.  Again, see
> >>> [1].  I tend to agree with the sentiment that a low-level component
> >>> like [pool] should emit very little, ideally nothing, in terms of
> >>> logging, but provide good access to the information needed by
> >>> components up the stack to handle and report errors and gather
> >>> diagnostic information.
> >>>
> >>> Phil
> >>>
> >>> [1] http://markmail.org/message/zuufedzkfx62v5eq
>  Regards,
> 
>  Anthony Communier
> 
> >>> ---

Re: Announce: Commons Inject

[Jean-Louis MONTEIRO]

See comments here after.

Le 4 nov. 2014 17:09, "Emmanuel Bourg"  a écrit :
>
> Le 04/11/2014 15:55, Jochen Wiedmann a écrit :
>
> > Any feedback welcome.
>
> Hi Jochen,
>
> I'm not a dependency injection expert so I can't really comment on the
> design, I could just make trivial observations like the use of the 'I'
> prefix for the interfaces which isn't used in the commons components and
> may lead to some confusing names (IMutableBindingSource is not immutable).

+1 C++ like inheritance. Very old and usually not used.

> I'm more concerned by the viability of this project as a Apache Commons
> component:
> - Are there other committers interested in maintaining this project?
> - Will this be used by other Apache projects? I tend to see Apache
> Commons as the place to factorize common code used across Apache
> projects, I'm not sure it works very well in the other direction.
> - I'm under the impression there are already well established
> implementations of JSR 330, what was the motivation behind this
> implementation? What are the selling points of this implementation
> compared to the others?

+1
And +1 for Romain as well. Contributing to openwebbeans would avoid
splitting community and efforts. Moreover, owb already passes this 330 tck
and more. It's well tested and integrated in various other apache projects
and more.
If it does not fit your needs you are more than welcome to contribute and
every contribution is valuable.

> - Why bringing this in Apache Commons instead of starting on Github?
>
> Emmanuel Bourg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>