Re: [VOTE] Release Geronimo Spec JCDI 2.0 v1.0.1

[Alan Cabrera]

+1 on releasing as is

The notice and removal of the run_sigtest.sh file can happen later, if you wish.


Regards,
Alan

> On Aug 31, 2017, at 7:04 AM, John D. Ament <johndam...@apache.org> wrote:
> 
> It looks like there's a few other errors in the NOTICE file.  If you want I 
> can re-roll with the fixes.
> 
> Sigtests were run as a part of 
> https://issues.apache.org/jira/browse/GERONIMO-6553 
> <https://issues.apache.org/jira/browse/GERONIMO-6553> there were no sig 
> changes in this release.  I'm actually not set up to run sigtests (and not 
> sure its relevance to this release).
> 
> The tag can be found at 
> http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jcdi_2.0_spec-1.0.1/
>  
> <http://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jcdi_2.0_spec-1.0.1/>
> 
> John
> 
> On Thu, Aug 31, 2017 at 9:50 AM Alan Cabrera <l...@toolazydogs.com 
> <mailto:l...@toolazydogs.com>> wrote:
> Thanks.  A few questions:
> What is the tag for this release?
> Do we want to include run_sigtest.sh and not the requisite test jars?
> If the answer is yes, should we include a README that explains how to get the 
> test jars?
> Should the NOTICE file have 2017 instead of 2015?
> 
> Regards,
> Alan
> 
>> On Aug 31, 2017, at 3:19 AM, John D. Ament <johndam...@apache.org 
>> <mailto:johndam...@apache.org>> wrote:
>> 
>> Thanks for the reminder Alan.  Fixed, key is present now.
>> 
>> John
>> 
>> On Thu, Aug 31, 2017 at 2:26 AM Alan Cabrera <l...@toolazydogs.com 
>> <mailto:l...@toolazydogs.com>> wrote:
>> John, is your key in https://svn.apache.org/repos/asf/geronimo/KEYS? 
>> <https://svn.apache.org/repos/asf/geronimo/KEYS?>
>> 
>> 
>> Regards,
>> Alan
>> 
>>> On Aug 30, 2017, at 5:10 PM, John D. Ament <johndam...@apache.org 
>>> <mailto:johndam...@apache.org>> wrote:
>>> 
>>> Hi All
>>> 
>>> I was running the steps needed to release JCDI 2.0 Spec v1.0.1.  There's 
>>> only a couple small changes in this release:
>>> 
>>> - Handle CDIProvider per the spec (cache the provider, lazily call the impl)
>>> - Added a @since 2.0 on setObserverMethod
>>> 
>>> Staging Repo: 
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1036/ 
>>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1036/>
>>> Source release: 
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-1036/org/apache/geronimo/specs/geronimo-jcdi_2.0_spec/1.0.1/geronimo-jcdi_2.0_spec-1.0.1-source-release.zip
>>>  
>>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1036/org/apache/geronimo/specs/geronimo-jcdi_2.0_spec/1.0.1/geronimo-jcdi_2.0_spec-1.0.1-source-release.zip>
>>>  
>>> (sha1, asc, md5 are next to this file)
>>> 
>>> I'll leave this vote open at least 72 hours, hopefully get 3 binding +1's 
>>> by then.
>>> 
>>> Here's my own +1 to release
>>> 
>>> [ ] +1 ship it
>>> [ ] +/- 0 don't care
>>> [ ] -1 don't ship because...
>> 
> 

Re: [VOTE] Release Geronimo Spec JCDI 2.0 v1.0.1

[Alan Cabrera]

Thanks.  A few questions:
What is the tag for this release?
Do we want to include run_sigtest.sh and not the requisite test jars?
If the answer is yes, should we include a README that explains how to get the 
test jars?
Should the NOTICE file have 2017 instead of 2015?

Regards,
Alan

> On Aug 31, 2017, at 3:19 AM, John D. Ament <johndam...@apache.org> wrote:
> 
> Thanks for the reminder Alan.  Fixed, key is present now.
> 
> John
> 
> On Thu, Aug 31, 2017 at 2:26 AM Alan Cabrera <l...@toolazydogs.com 
> <mailto:l...@toolazydogs.com>> wrote:
> John, is your key in https://svn.apache.org/repos/asf/geronimo/KEYS? 
> <https://svn.apache.org/repos/asf/geronimo/KEYS?>
> 
> 
> Regards,
> Alan
> 
>> On Aug 30, 2017, at 5:10 PM, John D. Ament <johndam...@apache.org 
>> <mailto:johndam...@apache.org>> wrote:
>> 
>> Hi All
>> 
>> I was running the steps needed to release JCDI 2.0 Spec v1.0.1.  There's 
>> only a couple small changes in this release:
>> 
>> - Handle CDIProvider per the spec (cache the provider, lazily call the impl)
>> - Added a @since 2.0 on setObserverMethod
>> 
>> Staging Repo: 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1036/ 
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1036/>
>> Source release: 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1036/org/apache/geronimo/specs/geronimo-jcdi_2.0_spec/1.0.1/geronimo-jcdi_2.0_spec-1.0.1-source-release.zip
>>  
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1036/org/apache/geronimo/specs/geronimo-jcdi_2.0_spec/1.0.1/geronimo-jcdi_2.0_spec-1.0.1-source-release.zip>
>>  
>> (sha1, asc, md5 are next to this file)
>> 
>> I'll leave this vote open at least 72 hours, hopefully get 3 binding +1's by 
>> then.
>> 
>> Here's my own +1 to release
>> 
>> [ ] +1 ship it
>> [ ] +/- 0 don't care
>> [ ] -1 don't ship because...
> 

Re: [VOTE] Release Geronimo Spec JCDI 2.0 v1.0.1

[Alan Cabrera]

John, is your key in https://svn.apache.org/repos/asf/geronimo/KEYS? 



Regards,
Alan

> On Aug 30, 2017, at 5:10 PM, John D. Ament  wrote:
> 
> Hi All
> 
> I was running the steps needed to release JCDI 2.0 Spec v1.0.1.  There's only 
> a couple small changes in this release:
> 
> - Handle CDIProvider per the spec (cache the provider, lazily call the impl)
> - Added a @since 2.0 on setObserverMethod
> 
> Staging Repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1036/ 
> 
> Source release: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1036/org/apache/geronimo/specs/geronimo-jcdi_2.0_spec/1.0.1/geronimo-jcdi_2.0_spec-1.0.1-source-release.zip
>  
> 
>  
> (sha1, asc, md5 are next to this file)
> 
> I'll leave this vote open at least 72 hours, hopefully get 3 binding +1's by 
> then.
> 
> Here's my own +1 to release
> 
> [ ] +1 ship it
> [ ] +/- 0 don't care
> [ ] -1 don't ship because...

Re: [VOTE] retire/EOL the Geronimo Server part?

[Alan Cabrera]

+1


Regards,
Alan

> On Aug 30, 2017, at 12:09 PM, Mark Struberg  wrote:
> 
> Picking this up and pushing it further!
> 
> After discussing this topic many times and finding no one willing to spend 
> time to actively evolve nor even maintain the Geronimo Server part I'd say we 
> should finally call a VOTE:
> 
> This is a VOTE to announce the EOL the Geronimo Server parts, mostly 
> * https://svn.apache.org/repos/asf/geronimo/server/
> * https://svn.apache.org/repos/asf/geronimo/gshell/
> 
> We will also have to update our site, moving most of the current stuff to a 
> 'legacy' area and rework it to focus on the new project agenda: to serve 
> common EE components for other ASF projects.
> 
> We also have a directory which contains binaries (jars) which don't even have 
> a license information.
> We should absolutely get rid of them anyway from our repo!
> https://svn.apache.org/repos/asf/geronimo/repository/
> 
> 
> Note that this vote is only about the Geroniom Server but NOT about the 
> shared components.
> Those components will be further maintained - or moved to a different project 
> later.
> 
> This includes, but is not limited to, the following Geronimo parts:
> * the specs
> * genesis (parents for xbean and specs)
> * xbean
> * the components javamail, transaction, config
> Those parts WILL STAY, 
> 
> So please VOTE:
> 
> [+1] Publicly announce that the Geroniom Server is EOL (End of Life) and will 
> not further be maintained but that the Geronimo Project will from now on 
> focus on reusable Java Enterprise components.
> 
> [+0] meh, I don't care
> 
> [-1] Nope, stop I need the Geronimo Server and I will ACTIVELY help to 
> maintain and evolve it in the future!
> 
> 
> 
> Here is my +1 
> 
> LieGrue,
> strub
> 
> 
>> Am 11.05.2017 um 22:09 schrieb Kevan Miller :
>> 
>> There should be a public vote.
>> 
>> On Wed, Apr 26, 2017 at 9:13 PM, Jean-Louis MONTEIRO  
>> wrote:
>> I think we came to an agreement so far
>> 
>> 
>> Le mar. 25 avr. 2017 à 00:21, Mark Struberg  a écrit :
>> Or do we need another formal vote?
>> 
>> If we are all on the same boat, when, how and who is drafting the 
>> Announcement?
>> 
>> LieGrue,
>> strub
>> 
>> 
> 

Re: CI for Geronimo Config

[Alan Cabrera]

> On Jul 3, 2017, at 5:37 PM, John D. Ament  wrote:
> 
> 
> 
> On Mon, Jul 3, 2017 at 7:01 PM John D. Ament  > wrote:
> On Mon, Jul 3, 2017 at 6:39 PM Romain Manni-Bucau  > wrote:
> 
> 
> Le 4 juil. 2017 00:01, "John D. Ament"  > a écrit :
> All,
> 
> I noticed a couple of things with running Geronimo Config locally.
> 
> - If I build from source (the MP config repo) and then build Geronimo Config 
> its all good.  However, when the JAR is downloaded via the maven repo, I get 
> errors like this:
> 
> arquillianBeforeTest(org.eclipse.microprofile.config.tck.ConverterTest)  Time 
> elapsed: 0.003 sec  <<< FAILURE!
> 
> java.lang.RuntimeException: Could not inject members
> 
> Caused by: org.apache.webbeans.exception.ProxyGenerationException: 
> java.lang.SecurityException: class 
> "org.eclipse.microprofile.config.Config$$OwbNormalScopeProxy0"'s signer 
> information does not match signer information of other classes in the same 
> package
> 
> Caused by: java.lang.SecurityException: class 
> "org.eclipse.microprofile.config.Config$$OwbNormalScopeProxy0"'s signer 
> information does not match signer information of other classes in the same 
> package
> 
> I suspect its because security manager is enabled and the OWB proxies are 
> ending up in the same package as the Eclipse classes.  Of course it could 
> have been a temporary thing as I had a local cached build.
> 
> 
> 
> - There's no Jenkins job.  Would anyone be against adding a Jenkins job?
> 
> 
> 
> +1
> 
> Turns out there was a Jenkins job, just not on the Geronimo view.  Its there 
> now.
>  
> 
> - There's only tests for OWB.  Would anyone be against adding tests for Weld?
> 
> 
> 
> +0 while it stays simple (not the same hierarchy DS has for instance but 
> think it is doable)
> 
> 
> I was hoping it could be as simple as 
> https://github.com/hammock-project/hammock-fault-tolerance/blob/master/pom.xml#L81-L165
>  
> 
>  (which itself is a WIP, and not working 100%)
>  
> 
> - There's still one failing TCK assertion, 
> 
> 
> 
> Tests run: 36, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 1.584 sec 
> <<< FAILURE! - in TestSuite
> 
> can_inject_simple_values_when_defined(org.eclipse.microprofile.config.tck.CDIPlainInjectionTest)
>   Time elapsed: 0.023 sec  <<< FAILURE!
> 
> java.lang.NumberFormatException: For input string: 
> "org.eclipse.microprofile.config.configproperty.unconfigureddvalue"
> 
>   at 
> org.eclipse.microprofile.config.tck.CDIPlainInjectionTest.getBeanOfType(CDIPlainInjectionTest.java:110)
> 
>   at 
> org.eclipse.microprofile.config.tck.CDIPlainInjectionTest.can_inject_simple_values_when_defined(CDIPlainInjectionTest.java:67)
> 
> 
> 
> 
> I dug into this one a bit more.  The ServiceLoader mechanism is choking on 
> the inner class for the config source.  It doesn't find it even though it's 
> there as a service provider.  The TCK test is a little weird.  I'm inclined 
> to say the TCK should be changed, as reaching into a public static class 
> across the JARs is a bit weird.
>  
> 
> Ok, I got this one working.  Turns out it was more issues with handling of 
> default values.  At least locally now the TCK passes 100%.  However, Jenkins 
> fails because of the issue I noted above.

Awesome!  A while back I asked about how the CI was setup.  Were you able to 
find any docs on details about the CI pipeline?  I’m happy to start some seed 
docs.


Regards,
Alan

Re: [VOTE] [RESULT] geronimo-jsonb_1.0 v 1.0 API jar

[Alan Cabrera]

+1 - tardy 


Regards,
Alan

> On Apr 24, 2017, at 12:36 PM, Mark Struberg  wrote:
> 
> Time to tally the vote.
> 
> The VOTE has passed with the following
> 
> +1: Romain Manni-Bucau, Jean-Louis Monteiro, Guillaume Nodet, Reinhard 
> Sandtner, Hendrik Saly, Mark Struberg
> No -1 nor +0
> 
> txs to all who voted!
> 
> I'll gonna continue with the release steps.
> 
> txs and LieGrue,
> strub
> 
> 
>> Am 21.04.2017 um 17:16 schrieb Mark Struberg :
>> 
>> Hi!
>> 
>> Please VOTE on releasing version 1.0 of the Geronimo JSONB 1.0 API (JSON 
>> Binding).
>> 
>> The staging repo is
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1033/
>> 
>> The source package can be found at:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1032/org/apache/geronimo/specs/geronimo-jsonb_1.0_spec/1.0/
>> 
>> I've verified the signature by comparing it to the official spec PFD API jar 
>> which got released today.
>> 
>> Please VOTE
>> 
>> [+1] ship it!
>> [+0] meh, don't care
>> [-1] stop, because there is a ${showstopper}
>> 
>> 
>> The VOTE is open for 72h min.
>> 
>> Here is my own +1
>> 
>> txs and LieGrue,
>> strub
> 

Re: [VOTE] fold the various Geronimo subproject mailing lists to the main lists

[Alan Cabrera]

> On Apr 21, 2017, at 6:24 AM, Mark Struberg  wrote:
> 
> Hi!
> 
> We currently have quite a few lists which have very low traffic.
> 
> My findings are a result of browsing lists.a.o.
> 
> 
> user@g.a.o -> merge into dev@g.a.o We only had 2 messages in the whole last 
> year!


I think it’s useful to have a dev/user lists.  The dearth of emails is due to 
the lack of activity, not over-organized email lists.

> xbean-dev@g.a.o -> move to dev@g.a.o
> 
> xbean-user@g.a.o -> move to dev@g.a.o
> 
> xbean-scm@g.a.o -> move to scm@g.a.o 

There’s already a ticket to remove these.

> geronimo-tck@g.a.o -> Last mail on Feb 2015. Traffic might to to 
> jcp-private@a.o; With Geronimo server getting discontinued we don't need the 
> TCK over here anyway

This email list is for technical discussions concerning the state of TCK 
adherence of Geronimo.  Our TCK contract prohibits discussions of this kind 
from being public and only those developers that are “registered” may 
participate, i.e. it can’t be folded into the pmc list.  If there is any 
possibility of future TCK work, it needs to be kept around.

> pmc@g.a.o -> close it; hmm is this still alive? Should all go to 
> private@g.a.o;

Hmm, we have both?  One is not the alias of the other?

> servicemix-tck@g.a.o -> close it; 

There’s already a ticket to remove this.

> tck-committs@g.a.o -> close it;

Similar to geronimo-tck@g.a.o , If there is any 
possibility of future TCK work, it needs to be kept around.


> security@g.a.o -> full of spam! hell, this is a mess, we should drop it and 
> use private@g.a.o for handling security related things. wdyt?

There shouldn’t be any spam on this list since it’s moderated.  I don’t see 
any, but I haven’t performed a detailed inventory of my spam folders.  The 
mailing list security@*.a.o is kinda a known standard where security 
organizations can privately report security problems.

> As a result we would keep the following lists:
> 
> dev@g.a.o
> private@g.a.o
> scm@g.a.o (might eventually get renamed to committs@g.a.o to fit other ASF 
> projects, but that not urgent)
> 
> 
> Any objections?
> 
> The VOTE is open for 72h, after that I'll trigger the infra work.
> 
> Here is my +1

With that said, I’m a +0.5 to remove those lists for which there is a ticket.


Regards,
Alan

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

The commit activity you speak of is really just small number of minor patches 
and a merge of years of work by IBM.  I’m just adding a bit of clarity there.  
On it’s own, it indicates to me that the “home for Java API specs” is not a 
fruitful path.  As it stands, there’s not a lot of activity and I still haven’t 
heard a clear case that things will ever improve on that front.

With that said, I think the config front will be very fruitful.  I’ve already 
outlined my ideas and I think that Geronimo would be a good seed from which to 
start with.
I’ll stick around to work on configuration on a macro level.  Hopefully it will 
dovetail with your work.

We could still keep the specs around.  I see no harm in that.


Regards,
Alan



> On Mar 24, 2017, at 8:55 AM, Mark Struberg <strub...@yahoo.de> wrote:
> 
> Of course we do not have a huge community. But a very long lasting one. And 
> there is not really standstill. There have been 64 committs in the last 3 
> monts. This is actually not too bad!
> 
> So how to move on?
> 
> Who wants to remain active in the PMC? Who wants to leave?
> 
> We already pinned down the parts where there certainly IS community. 
> In addition to that I would like to bring in Geronimo-Config  as an 
> implementation of the Microprofile-Config specification.
> Discussions have been going on last year all work has been done by me on my 
> github account. But would love to bring it over here.
> 
> I'll dig the old projects charter and try to kick off a reboot together with 
> Romain, Jean-Louis, Reinhard, Guillaume and whoever else is willing to have a 
> helping hand from time to time. Note that everyone is welcome, even if he 
> currently has no time to commit but only wants to provide guide and feedback.
> 
> The first step I recommend is be to merge various mailing lists together.
> Then we need to verify the charter and probably tweak it for the new goal.
> We also need to communicate that we do not further maintain the Geronimo 
> Server parts.
> 
> Any objection?
> 
> LieGrue,
> strub
> 
> 
>> Am 13.03.2017 um 20:46 schrieb Kevan Miller <kevan.mil...@gmail.com>:
>> 
>> "need" and "in use" does not necessarily translate into community. The need 
>> for the geronimo components that have been discussed is not new. As far as I 
>> can tell, so far, that has not translated into a community. 
>> 
>> If we want to continue the project, demonstrate the community that is needed 
>> for the project to continue. As I stated previously, a good starting point: 
>> create a new charter for the project, identify active PMC 
>> members/committers, and obtain board approval. 
>> 
>> On Sun, Mar 12, 2017 at 12:01 PM, Mark Struberg <strub...@yahoo.de> wrote:
>> Hi Alan!
>> 
>> There are quite a few things which fit into this scenario imo.
>> 
>> I think we really miss some 'toolbox project' for EE components at the ASF.
>> There was a tendency to make all those projects own TLPs for some time. But 
>> that approach simply doesn't scale, and we end up with the same people in 
>> most of those projects anyway.
>> So moving the ones with lower activity into a common TLP would solve this 
>> problem. Geronimo could probably become this project.
>> 
>> There are a lot old EE folks around which have tremendous knowledge. And 
>> there are certain technologies which are really cool, but have the classical 
>> EE-lifecycle up-down in terms of activity.
>> That + the already existing components could be a great chance.
>> 
>> As you already said yourself: the terms of the big fat EE servers is over. 
>> But nevertheless the technology and requirement behind most of the single 
>> parts is still valid and often unbeaten.
>> But nowadays it's more about making it easy to plug & play those technology 
>> libs together more freely as they are needed. Thus moving the focus on 
>> maintaining the components and not the server could be really appreciated by 
>> the community.
>> 
>> You said there will be community if there is a need. I fully agree, and even 
>> more I see a need for those parts.
>> 
>> LieGrue,
>> strub
>> 
>>> Am 12.03.2017 um 19:15 schrieb Alan Cabrera <l...@toolazydogs.com>:
>>> 
>>> After a good night’s sleep, I re-read this thread and I’ll respond without 
>>> trying to guide you in where and how you decide to go with your efforts; 
>>> thanks in advance for letting me reboot my reply.  :)
>>> 
>>> Any pivot that this community decides upon, will have to be justified to 
>>> the ASF board.  We will need to explain what will

Re: Merging old mailing lists

[Alan Cabrera]

I think that it still makes sense to keep the user and dev lists separate.  The 
mailing lists below are from projects that have been assimilated.


Regards,
Alan


> On Mar 12, 2017, at 5:58 PM, David Jencks <david.a.jen...@gmail.com> wrote:
> 
> +1,
> I think we can also merge the user and dev lists… any others?
> 
> david jencks
> 
>> On Mar 12, 2017, at 11:41 AM, Alan Cabrera <a...@toolazydogs.com 
>> <mailto:a...@toolazydogs.com>> wrote:
>> 
>> I’m thinking that, regardless of this project’s direction, the following 
>> mailing lists should be merged into Geronimo’s existing mailing lists:
>> servicemix-...@geronimo.apache.org 
>> <mailto:servicemix-...@geronimo.apache.org>
>> xbean-...@geronimo.apache.org <mailto:xbean-...@geronimo.apache.org>
>> xbean-...@geronimo.apache.org <mailto:xbean-...@geronimo.apache.org>
>> xbean-u...@geronimo.apache.org <mailto:xbean-u...@geronimo.apache.org>
>> 
>> Regards,
>> Alan
>> 
> 

Merging old mailing lists

[Alan Cabrera]

I’m thinking that, regardless of this project’s direction, the following 
mailing lists should be merged into Geronimo’s existing mailing lists:
servicemix-...@geronimo.apache.org
xbean-...@geronimo.apache.org
xbean-...@geronimo.apache.org
xbean-u...@geronimo.apache.org

Regards,
Alan

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

After a good night’s sleep, I re-read this thread and I’ll respond without 
trying to guide you in where and how you decide to go with your efforts; thanks 
in advance for letting me reboot my reply.  :)

Any pivot that this community decides upon, will have to be justified to the 
ASF board.  We will need to explain what will be different and justify how it 
will generate sustainable community activity.  With regards to that, I have two 
general concerns:
Will this this specific endeavor generate any new sustainable community 
activity? 
Will any new activity of this specific endeavor represent activity that is 
unique to Geronimo or are we doing the chores of other projects to provide the 
appearance of activity?
The current level activity, is due to spec maintenance for downstream 
dependencies and we must admit that it is quite low.  Being an upstream 
“aggregator” does not provide appreciable added value at the cost of the 
doubled administration.  The specter of duplicate work will, in reality, never 
arise; this de facto efficiency is due to the awesomeness of the ASL 2.0 
license.  The case for being an aggregator weakens even more given the fact 
that there just isn't a lot of work involved in maintaining specs.

Things aren’t much better for the shared sub-systems.  If there was something 
compelling that needed to be done on the shared sub-systems, it would have been 
begun already; given the industry’s penchant for greenfield development (NIH) I 
doubt they will ever be revamped.

This is why I went on my “need” soapbox.  Some new need must be found for 
Geronimo to provide.


Regards,
Alan


> On Mar 9, 2017, at 8:49 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> I have quite a hard time to understand why it is an issue having a project 
> led by the aggregation of others and not by itself? Assume one sec we close 
> Geronimo or it doesnt exist, then we'll move the bit of code in one of the 
> project - let say tomee - and tomee will becomes the exact same kind of 
> project. The alternative is to split in a lot of small projects but as 
> mentionned a lot of overlap is in these projects in term of forces and it 
> doesn't work really better, it just multiply the work load for each 
> contributor. That's why I think G is not a bad solution as it is today. Scope 
> surely needs to be refined like Mark started to do and objectives are clearly 
> a bit different than a project pushing its own server/solution but I think 
> there is a space for it and for Apache I think it is saner this way.
> 
> 
> 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-03-09 17:01 GMT+01:00 Alan Cabrera <l...@toolazydogs.com 
> <mailto:l...@toolazydogs.com>>:
> It has been my personal experience that need is the catalyst for a vibrant 
> OSS project.  The product and community spring forth from that.  Adopting an 
> “if we build it they will come” tactic does not usually result in success.  
> Rather than rummaging through the trunk to see what bits people might be 
> attracted to, maybe it might be better to look at the existing JEE-related 
> OSS communities out there and ask “what need are they not fulfilling?”
> 
> That would answer passersby’s questions of “why would I be interested in this 
> project?”  
> 
> That would be a slam dunk to present to the ASF board, “Geronimo is now 
> focused on fulfilling a new need, X”.
> 
> What unfulfilled need is out there?
> 
> 
> Regards,
> Alan
> 
> 
> 
>> On Mar 9, 2017, at 7:04 AM, Mark Struberg <strub...@yahoo.de 
>> <mailto:strub...@yahoo.de>> wrote:
>> 
>> I totally agree.
>> 
>> But interest from the community is always a product of a good product and 
>> feature roadmap.
>> Without any good product you will not be able to build a sustainable 
>> community around it.
>> 
>> Of course there are many things which can trash a community despite a good 
>> product. But without product there is no community.
>> At the end we are not here only because the people are great, but because we 
>> see a benefit in the product we create in this project - AND the people are 
>> great ;)
>> 
>> So my first goal was to identify the features which might be of interest.
>> The next step is to check whether there is enough community interest in 
>> those features or whether we could move then to another community. Ideally 
>> with still using the org.apache.geronimo gro

Re: Yoko work

[Alan Cabrera]

(Sorry, my reply was “stuck” in the draft folder)

Many thanks!  It’s great to see external products giving back to their OSS 
siblings.  

Hope to see more great work!


Regards,
Alan

> On Feb 28, 2017, at 3:25 PM, David Jencks  wrote:
> 
> I’ve merged the commits from Joe Chacko, Neil Richards and myself into yoko 
> master and closed the related jira issues.
> 
> I think there may have been some further development at IBM after I left, I 
> will try to see if we can get that added in, perhaps with more help from 
> Joe/Neil.
> 
> thanks
> david jencks
> 

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

I’m not opposed to aggregation, per se.  I’m just trying to point out a 
possibly different way of jumpstarting community activity, a different way of 
searching for a new direction for Geronimo.

It’s different than doing an inventory of stuff we have and thinking, “how can 
we make this stuff more enticing to people?”  An inventory is good, but make 
sure that it’s not an inventory of deck chairs on the Titanic.  Collecting such 
an inventory may just be busywork, and a bit premature, without the the goal of 
fulfilling a specific need to provide direction.  The inventory of stuff as a 
starting point may blind one to other possibilities for Geronimo.

Elucidating the need comes first.  The enumerating features to fulfill that 
need comes second.  Once that is known it will help provide direction as to 
what parts of Geronimo are relevant and what aren’t, what parts need to be 
spruced up and what parts are fine as is.

Think BIG!

I have one idea.  It’s something that I don’t think has been done yet, at least 
to the extent that it’s been done at LinkedIn, and it fulfills a dire need.  

The management of runtime-configurations for heterogeneous global environments. 
 At LinkedIn, we treat runtime properties like code.  Not just in the sense of 
a “source code repository”, but also in the sense that services can declare 
what properties they consume and the CI/CD pipeline will prevent those 
properties from being borked.  This is very handy when properties are shared 
amongst multiple services across multiple fabrics.  It also does constraint 
checking to make sure properties adhere to certain constraints that can be set 
at the component code level, service level, and “SRE level”.

Such a system can provide visibility as to what properties are being used, not 
being used, or need to be provided before rolling a service into a new 
fabric/edge.

It fulfills a need for what is usually given little thought as a service is 
tossed over the wall for an SRE to contend with.  It forces early conversations 
between the component provider and the service owner.  It forces early 
conversations between a service owner and the SRE, before deployment.  It 
forces component and service owners to diligently consider how their products 
will be managed out in the field, possibly before code is even cut, and 
globally enforces those runtime contracts throughout the lifetime of that 
product in the CI/CD pipeline.

So, this isn’t just JEE.  This is JEE, Play, ATS, Docker, Rails, Httpd, NodeJS, 
Hadoop, …

This isn’t just services.  This is the CI/CD pipeline of Jenkins, Travis, …

Well, that’s it.  One idea to consider.


Regards,
Alan

> On Mar 9, 2017, at 8:49 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> I have quite a hard time to understand why it is an issue having a project 
> led by the aggregation of others and not by itself? Assume one sec we close 
> Geronimo or it doesnt exist, then we'll move the bit of code in one of the 
> project - let say tomee - and tomee will becomes the exact same kind of 
> project. The alternative is to split in a lot of small projects but as 
> mentionned a lot of overlap is in these projects in term of forces and it 
> doesn't work really better, it just multiply the work load for each 
> contributor. That's why I think G is not a bad solution as it is today. Scope 
> surely needs to be refined like Mark started to do and objectives are clearly 
> a bit different than a project pushing its own server/solution but I think 
> there is a space for it and for Apache I think it is saner this way.
> 
> 
> 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-03-09 17:01 GMT+01:00 Alan Cabrera <l...@toolazydogs.com 
> <mailto:l...@toolazydogs.com>>:
> It has been my personal experience that need is the catalyst for a vibrant 
> OSS project.  The product and community spring forth from that.  Adopting an 
> “if we build it they will come” tactic does not usually result in success.  
> Rather than rummaging through the trunk to see what bits people might be 
> attracted to, maybe it might be better to look at the existing JEE-related 
> OSS communities out there and ask “what need are they not fulfilling?”
> 
> That would answer passersby’s questions of “why would I be interested in this 
> project?”  
> 
> That would be a slam dunk to present to the ASF board, “Geronimo is now 
> focused on fulfilling a new need, X”.
> 
> What unfulfilled need is out there?
> 
> 
> Regards,
> Alan
> 
> 
> 
>> On Mar 9

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

It has been my personal experience that need is the catalyst for a vibrant OSS 
project.  The product and community spring forth from that.  Adopting an “if we 
build it they will come” tactic does not usually result in success.  Rather 
than rummaging through the trunk to see what bits people might be attracted to, 
maybe it might be better to look at the existing JEE-related OSS communities 
out there and ask “what need are they not fulfilling?”

That would answer passersby’s questions of “why would I be interested in this 
project?”  

That would be a slam dunk to present to the ASF board, “Geronimo is now focused 
on fulfilling a new need, X”.

What unfulfilled need is out there?


Regards,
Alan



> On Mar 9, 2017, at 7:04 AM, Mark Struberg  wrote:
> 
> I totally agree.
> 
> But interest from the community is always a product of a good product and 
> feature roadmap.
> Without any good product you will not be able to build a sustainable 
> community around it.
> 
> Of course there are many things which can trash a community despite a good 
> product. But without product there is no community.
> At the end we are not here only because the people are great, but because we 
> see a benefit in the product we create in this project - AND the people are 
> great ;)
> 
> So my first goal was to identify the features which might be of interest.
> The next step is to check whether there is enough community interest in those 
> features or whether we could move then to another community. Ideally with 
> still using the org.apache.geronimo groupId and packages. Otherwise it would 
> be quite some problem for the users.
> 
> LieGrue,
> strub
> 
>> Am 09.03.2017 um 14:46 schrieb Alex Karasulu :
>> 
>> I think more important than whether or not JEE is popular (or whatever along 
>> those lines), are the questions about community health and is the PMC still 
>> capable of fulfilling its duties.
>> 
>> My 2 cents,
>> --Alex
>> 
>> On Thu, Mar 9, 2017 at 12:08 PM, Mark Struberg  wrote:
>> Romain and I went through the Geronimo SVN and made a list of which 
>> components are used by other projects.
>> 
>> 
>> Useful Geronimo components from https://svn.apache.org/repos/asf/geronimo/
>> 
>> https://svn.apache.org/repos/asf/geronimo/KEYS
>> 
>> https://svn.apache.org/repos/asf/geronimo/components/txmanager
>>• TomEE (txmgr+connector)
>>• Meecrowave (txmgr)
>>• Aries (txmgr)
>> 
>> https://svn.apache.org/repos/asf/geronimo/components/geronimo-schema-javaee_6
>> 
>> https://svn.apache.org/repos/asf/geronimo/genesis/
>>• Maven parents for geronimo-specs
>> 
>> https://svn.apache.org/repos/asf/geronimo/javamail/
>>• TomEE as delivery
>>• Lot of standalone
>>• -> we can ask Hendrik pby
>> 
>> https://svn.apache.org/repos/asf/geronimo/specs/
>>• TomEE
>>• OpenWebBeans
>>• Meecrowave
>>• OpenJPA
>>• Johnzon
>>• BatchEE
>>• Karaf
>>• Aries
>>• Tons of external customer projects which don’t want to use some 
>> official javax jars due to licensing concerns
>> 
>> https://svn.apache.org/repos/asf/geronimo/xbean/
>>• TomEE
>>• OpenWebBeans
>>• Meecrowave
>>• Aries
>>• Karaf
>>• OpenJPA
>>• CXF (supported)
>> 
>> Osgi-locator too but guess this one can drop and belong to karaf or 
>> servicemix.
>> Q: well we need the osgi locator in our geronimo-specs, isn’t?
>> 
>> 
>> I've created a google doc. Just ping me if you want to edit something and 
>> I'll share it.
>> 
>> David, you mentioned JASPIC. I could not find that even. Is this inside the 
>> geronimo-server probably?
>> Are there other gems which are not maintained as components but just inside 
>> geronimo?
>> 
>> txs and LieGrue,
>> strub
>> 
>> 
>>> Am 09.03.2017 um 08:44 schrieb David Jencks :
>>> 
>>> I go back and forth on whether to shut G down completely.  Perhaps it would 
>>> be useful to inventory which parts are used by which other projects? Off 
>>> the top of my head….
>>> 
>>> Specs …. who uses G’s and who has their own?
>>> 
>>> Components…. I think there are several users of the transaction manager, I 
>>> don’t know about the connector framework, and I’m pretty sure no one uses 
>>> my jaspic implementation.  The TM is stable but now that faster than 
>>> spinning rust persistent memory is popular the logger could probably be 
>>> rewritten to be much faster.
>>> 
>>> xbean …. tomee I believe, anyone else?  Does activemq still use 
>>> xbean-spring?  Knowing more about osgi now I might be able to gets 
>>> xbean-blueprint to work:-)
>>> 
>>> yoko is used by IBM, I doubt anyone else will get all excited about CORBA 
>>> and start contributing.
>>> 
>>> Any other bits being used?
>>> 
>>> If we kept G around in a reduced state, how will we maintain enough 
>>> interest to file the board reports? 

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

> On Mar 8, 2017, at 10:44 AM, Mark Struberg <strub...@yahoo.de> wrote:
> 
> Alan, I understand that you don't want to put much more energy into this 
> project. That is totally understandable and fine. 
> But while you are PMC chair you still cannot declare that the project is dead 
> as long as there are enough PMC members still active to keep the project 
> going.

Let me be perfectly clear.  I am not declaring this project dead.  I have 
started a long delayed public discussion about possibly moving Geronimo to the 
Attic.  We’ve had this discussion many times over the years on the private PMC 
list, out of concern of spooking potential public interest.  Now, I am 
declaring that it’s time to discuss this publicly; my opening of the discussion 
to the public spurred at the request of an ASF board member.

The questions you ask below, have they not already been asked, privately and 
publicly, multiple times over the past half decade?  Can you provide your 
opinion as to how many more unanswered calls to action must take place before 
the project can feel comfortable donating the used bits of Geronimo to the 
active OSS projects that actually use them?  Before the project embarks on yet 
another SOS it is important to know what is your concrete criteria that the 
project can use to honestly declare to the ASF board and corporate members that 
there is an active community here.  It is also important to know what is your 
concrete criteria for deciding that a reasonable effort has been made and it’s 
time to wind down.  Keep in mind that both criteria can be applied to what 
efforts and results have already taken place over the past decade.  Details as 
to what is different from this effort from what has been done in the past would 
be helpful to garner consensus.

These are not hard requirements being dictated by me, but a suggestion to 
prepare us for what will inevitably be asked of us should the project soldier 
on.  In addition to a consensus that an effort should be made, there should be 
a consensus on clear and transparent criteria for failure as well as success.

> Before we dump the project I suggest we start with an analysis of where we 
> are right now.
> 
> What about starting look into
> .) Who is still active and willing to continue Geronimo as a ee-commons 
> project?
> .) Which project parts of the project are of some shared interest and might 
> be good to get some maintenance love and some realistic chance that this is 
> gonna happening?
> 
> txs and LieGrue,
> strub
> 
> 
>> Am 08.03.2017 um 16:38 schrieb Alan Cabrera <l...@toolazydogs.com>:
>> 
>> I agree and I even acknowledged that below, but what I feel Mark and you are 
>> not acknowledging is that the interest/activity is for a smaller subset of 
>> JEE.  Of that subset, even you list the OSS projects that are supporting the 
>> JEE bits that are still relevant.  They have active communities and are even 
>> likely to be using our implementation of our specs, but that is not 
>> reflective of the viability of Geronimo as an active JEE project at the ASF. 
>> 
>> Let us keep in mind that the raison d’être of Geronimo is the complete 
>> implementation of the JEE standard.  The JEE spec licensing that the project 
>> is bound to goes through excruciating lengths to make sure that the spec is 
>> implemented in toto and not piecemeal.  Given that the overwhelming bulk of 
>> the code is simply an inclusion of external OSS projects, when the existing 
>> active OSS projects are factored out there’s not a lot left.  There’s no 
>> denying that much of what’s left is good technology.  It’s just not enough 
>> to jumpstart a new active OSS community.  And this is the crux of the 
>> matter, community.
>> 
>> Does Geronimo still have good technology? Yes.
>> 
>> When one factors out the existing OSS overlap, is it enough to jumpstart a 
>> new active community?  No.
>> 
>> A few engineers applying patches once a year is not an active community.  To 
>> be sure the downstream OSS projects are appreciative.  However, what’s the 
>> point?  The engineering activity here is really a proxy for other OSS 
>> projects and not indicative of the viability of Geronimo as an active ASF 
>> project.  Things get fixed and released, but in the end the wider community 
>> goes to the other OSS projects to consume those artifacts.
>> 
>> Geronimo had a great run.  It made significant contributions to the 
>> industry.  However, the relevancy of the JEE spec has wained and the dearth 
>> of activity is concrete proof of that.
>> 
>> With that said, this does not prevent a set of enterprising engineers with 
>> “can do” attitudes to pick over the bones tha

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

+1

> On Mar 9, 2017, at 5:46 AM, Alex Karasulu  wrote:
> 
> I think more important than whether or not JEE is popular (or whatever along 
> those lines), are the questions about community health and is the PMC still 
> capable of fulfilling its duties.
> 
> My 2 cents,
> --Alex
> 
> On Thu, Mar 9, 2017 at 12:08 PM, Mark Struberg  > wrote:
> Romain and I went through the Geronimo SVN and made a list of which 
> components are used by other projects.
> 
> 
> Useful Geronimo components from https://svn.apache.org/repos/asf/geronimo/ 
> 
> 
> https://svn.apache.org/repos/asf/geronimo/KEYS 
> 
> 
> https://svn.apache.org/repos/asf/geronimo/components/txmanager 
> 
> • TomEE (txmgr+connector)
> • Meecrowave (txmgr)
> • Aries (txmgr)
> 
> https://svn.apache.org/repos/asf/geronimo/components/geronimo-schema-javaee_6 
> 
> 
> https://svn.apache.org/repos/asf/geronimo/genesis/ 
> 
> • Maven parents for geronimo-specs
> 
> https://svn.apache.org/repos/asf/geronimo/javamail/ 
> 
> • TomEE as delivery
> • Lot of standalone
> • -> we can ask Hendrik pby
> 
> https://svn.apache.org/repos/asf/geronimo/specs/ 
> 
> • TomEE
> • OpenWebBeans
> • Meecrowave
> • OpenJPA
> • Johnzon
> • BatchEE
> • Karaf
> • Aries
> • Tons of external customer projects which don’t want to use some 
> official javax jars due to licensing concerns
> 
> https://svn.apache.org/repos/asf/geronimo/xbean/ 
> 
> • TomEE
> • OpenWebBeans
> • Meecrowave
> • Aries
> • Karaf
> • OpenJPA
> • CXF (supported)
> 
> Osgi-locator too but guess this one can drop and belong to karaf or 
> servicemix.
> Q: well we need the osgi locator in our geronimo-specs, isn’t?
> 
> 
> I've created a google doc. Just ping me if you want to edit something and 
> I'll share it.
> 
> David, you mentioned JASPIC. I could not find that even. Is this inside the 
> geronimo-server probably?
> Are there other gems which are not maintained as components but just inside 
> geronimo?
> 
> txs and LieGrue,
> strub
> 
> 
> > Am 09.03.2017 um 08:44 schrieb David Jencks  > >:
> >
> > I go back and forth on whether to shut G down completely.  Perhaps it would 
> > be useful to inventory which parts are used by which other projects? Off 
> > the top of my head….
> >
> > Specs …. who uses G’s and who has their own?
> >
> > Components…. I think there are several users of the transaction manager, I 
> > don’t know about the connector framework, and I’m pretty sure no one uses 
> > my jaspic implementation.  The TM is stable but now that faster than 
> > spinning rust persistent memory is popular the logger could probably be 
> > rewritten to be much faster.
> >
> > xbean …. tomee I believe, anyone else?  Does activemq still use 
> > xbean-spring?  Knowing more about osgi now I might be able to gets 
> > xbean-blueprint to work:-)
> >
> > yoko is used by IBM, I doubt anyone else will get all excited about CORBA 
> > and start contributing.
> >
> > Any other bits being used?
> >
> > If we kept G around in a reduced state, how will we maintain enough 
> > interest to file the board reports?  Some days  I think I might have enough 
> > interest and some days not.
> >
> > If we did not shut down the whole project would we mark the removed bits 
> > (server primarily) as not being developed or move them to the attic?
> >
> > thanks
> > david jencks
> >
> >> On Mar 8, 2017, at 11:15 PM, Romain Manni-Bucau  >> > wrote:
> >>
> >> A valid point is activity related to G happens elsewhere, However 
> >> elsewhere is not "tomee" which would make things simple to move but A, B, 
> >> C so shutting down G is likely the easiest solution for G itself but also 
> >> the worse for all its dependent projects - and ASF consistency since G is 
> >> now seen as the owner of specs, xbean etcToday G is the result of 
> >> communities and I don't see it as a bad thing even if not common @ASF. It 
> >> allows new interactions with sometimes completely different area of 
> >> knowledge which is actually great and can't happen elsewhere IMHO (the 
> >> dead of G would mean fork per project probably).
> >>
> >>
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >>
> >> 

Re: Discuss: Move Geronimo to Attic

[Alan Cabrera]

and they still get committs and love.
> 
> I'd definitly keep them alive.
> 
> I'm aware that quite some older PMC members have historically been interested 
> in the Geronimo AppServer and not in maintaining the ee-commons part of the 
> geronimo project.
> But instead of dumping the whole project I'd say we just retire the Geronimo 
> AppServer and consolidate and focus on the single pieces. There are 
> potentially other things like Sirona-incubating which we could move over as 
> sub-projects even.
> 
> Of course I perfectly understand if some of the older PMC members which are 
> not interested in the adopted roadmap want to retire.
> 
> txs for all the hard work!
> 
> LieGrue,
> strub
> 
> 
> > Am 07.03.2017 um 22:44 schrieb Alan Cabrera <l...@toolazydogs.com 
> > <mailto:l...@toolazydogs.com>>:
> >
> > IMO, consultants and researchers are the earthworms of a vibrant OS 
> > community that meets the standards sought after at the ASF.  I don’t see 
> > how we’re going to attract them.  While the ideas posited on the mailing 
> > lists are pretty interesting, I just don’t see any of the ideas attracting 
> > a larger active community.  The reasons for this are
> >   • the lack of interest in JEE
> >   • inability to use a reasonably current JEE TCK
> >   • the size and age of the legacy code base
> >   • project members unable to commit time resources to mentor new 
> > members
> > When one reads about JEE not being “dead yet”, one is actually reading 
> > about a very small subset of the JEE spec.  To be sure, there are 
> > interesting problems still to be solved within certain silos of JEE.  I 
> > can’t think of anything that would apply to the entire pantheon of JEE 
> > bits; imo TomEE is already focused on the sweet spot of JEE bits that are 
> > still relevant.  One is hard pressed to think of any JEE sub-system in 
> > Geronimo that is not already separate project. The reality is that Geronimo 
> > was an amalgam of OSS projects and the industry has preserved those JEE 
> > bits that are still relevant.  The "value add", in no small part, of 
> > Geronimo was the comprehensive testing of the JEE pantheon in toto via the 
> > TCK.
> >
> > Given that we cannot use a reasonably current JEE TCK, the project is 
> > prevented from engaging in a role of JEE-commons of sorts.  Frankly, even 
> > if we were to get the current JEE TCK, nobody really cares anymore and, as 
> > I mentioned above, the interesting JEE bits are already being worked on 
> > elsewhere with their own specific TCKs.
> >
> > The size and age of the codebase makes it virtually impenetrable.  When one 
> > precludes spec commits, I think the last real commit has been about a half 
> > a decade ago; I wouldn’t be surprised if it was longer.  I personally have 
> > been knee deep in it recently but find spelunking through it very daunting. 
> >  I’d rather spend any free time I have in some greenfield endeavor.
> >
> > I’m certain that other project members and passersby are of the same mind.  
> > Since I have such little time to do greenfield coding, I have even less 
> > time to mentor someone who is interested in tinkering with the code base.  
> > I’ve no doubt that others are of the same mind on this as well; witness the 
> > dearth of replies to inquiries on this list.
> >
> > There is a lot of blood, sweat, and tears in this project.  I, for one, am 
> > honored to have been able to work with the world’s brightest coders on the 
> > planet.  I have a lot of great memories, and hangovers, of our once vibrant 
> > community and it’s very hard for me to start this thread.  I think we 
> > should shutdown.  If anyone had a real interest in any kind of resurrection 
> > it would have happened by now.
> >
> > If we have consensus on moving to the Attic, I will start a vote.  How 
> > things are “wound down” will be discussed in a separate thread, soon to 
> > follow.
> >
> >
> > Regards,
> > Alan Cabrera
> > V.P. Apache Geronimo
> >
> > P.S.  Please resist the urge hop in and administer CPR.  Before jumping on 
> > the table, be brutally honest and ask yourself if you are operating on 
> > actionable facts, or fond well earned memories.
> >
> >
> 
> 

Discuss: Move Geronimo to Attic

[Alan Cabrera]

IMO, consultants and researchers are the earthworms of a vibrant OS community 
that meets the standards sought after at the ASF.  I don’t see how we’re going 
to attract them.  While the ideas posited on the mailing lists are pretty 
interesting, I just don’t see any of the ideas attracting a larger active 
community.  The reasons for this are
the lack of interest in JEE
inability to use a reasonably current JEE TCK
the size and age of the legacy code base 
project members unable to commit time resources to mentor new members
When one reads about JEE not being “dead yet”, one is actually reading about a 
very small subset of the JEE spec.  To be sure, there are interesting problems 
still to be solved within certain silos of JEE.  I can’t think of anything that 
would apply to the entire pantheon of JEE bits; imo TomEE is already focused on 
the sweet spot of JEE bits that are still relevant.  One is hard pressed to 
think of any JEE sub-system in Geronimo that is not already separate project. 
The reality is that Geronimo was an amalgam of OSS projects and the industry 
has preserved those JEE bits that are still relevant.  The "value add", in no 
small part, of Geronimo was the comprehensive testing of the JEE pantheon in 
toto via the TCK.

Given that we cannot use a reasonably current JEE TCK, the project is prevented 
from engaging in a role of JEE-commons of sorts.  Frankly, even if we were to 
get the current JEE TCK, nobody really cares anymore and, as I mentioned above, 
the interesting JEE bits are already being worked on elsewhere with their own 
specific TCKs.

The size and age of the codebase makes it virtually impenetrable.  When one 
precludes spec commits, I think the last real commit has been about a half a 
decade ago; I wouldn’t be surprised if it was longer.  I personally have been 
knee deep in it recently but find spelunking through it very daunting.  I’d 
rather spend any free time I have in some greenfield endeavor.

I’m certain that other project members and passersby are of the same mind.  
Since I have such little time to do greenfield coding, I have even less time to 
mentor someone who is interested in tinkering with the code base.  I’ve no 
doubt that others are of the same mind on this as well; witness the dearth of 
replies to inquiries on this list.

There is a lot of blood, sweat, and tears in this project.  I, for one, am 
honored to have been able to work with the world’s brightest coders on the 
planet.  I have a lot of great memories, and hangovers, of our once vibrant 
community and it’s very hard for me to start this thread.  I think we should 
shutdown.  If anyone had a real interest in any kind of resurrection it would 
have happened by now.  

If we have consensus on moving to the Attic, I will start a vote.  How things 
are “wound down” will be discussed in a separate thread, soon to follow. 


Regards,
Alan Cabrera
V.P. Apache Geronimo

P.S.  Please resist the urge hop in and administer CPR.  Before jumping on the 
table, be brutally honest and ask yourself if you are operating on actionable 
facts, or fond well earned memories.

Re: let's use the Help-Wanted page for adding JavaDoc to our specs?

[Alan Cabrera]

> On Jan 18, 2017, at 12:21 PM, Mark Struberg  wrote:
> 
> Hi folks!
> 
> What about using the Apache Help-Wanted page and doing a few tweets about 
> beefing up our geronimo-specs docs?
> 
> Do you think that's worth a try?

Sounds like a great idea!


Regards,
Alan

Re: [DICSUSS] the future direction of the Apache Geronimo project

[Alan Cabrera]

> On Jan 6, 2017, at 12:34 PM, David Jencks  wrote:
> 
> I’m not sure how much interest there would be in an osgi based javaee app 
> server.  I expect osgi-aware projects would likely try to avoid most of the 
> javaee cruft and go directly to better-integrated-with osgi stuff such as 
> that being demonstrated in enroute and non-osgi aware projects would be 
> likely to want something lighter weight such as tomee.
> 
> However….. should anyone wish to revive Geronimo… my advice would be:
> 
> - drop the geronimo framework.
> - (possibly) write a config admin management agent that reads something like 
> current geronimo configuration files and turns them into osgi configurations. 
>  I think some way of representing data trees in an osgi configuration is 
> essential.  I tend to prefer encoding the path to a data element in the key, 
> so values are all simple, but most osgi people seem to prefer encoding the 
> data tree in json or yaml with simple keys and complex values.  I think osgi 
> R7 is likely to support the latter approach.
> - Rewrite all the integration code (most of geronimo) to use up-to-date (R7, 
> actually) declarative services.  As part of this, make actual bundles with 
> only interfaces exported and all the implementation   hidden.
> - Run it in plain Karaf.
> 
> This would involve an extended period in which little to nothing worked.
> 
> When I tried to osgi-ify geronimo, I was hampered by
> - trying to do it pretty much by myself — it is too large a job for one 
> person IMO.
> - trying to keep a working product most of the time — starting over with a DS 
> based component model is definitely the way to proceed
> - the DS implementation was too buggy, I didn’t know enough about DS, and the 
> DS spec was too primitive — all of these have been fixed, although I don’t 
> imagine I would  participate much in a revival much beyond giving advice.

Is there a simple place to start where we can start doing tight iterations?  
What’s the simplest JEE bit that we can start with?  Maybe we start with Yoko?

re: configuration - configuration has a lot of definitions, though there may be 
a standard definition in this context and I have forgotten it.  Are you 
referring to how one can assemble the various bits of JEE onto an OSGi runtime?

I think we should also re-boot the build framework as well.  The current one 
seems to be quite complicated and impenetrable.  I am now a Gradle fan-boi.


Regards,
Alan

Re: More on Yoko

[Alan Cabrera]

Works for me.


Regards,
Alan

> On Jan 16, 2017, at 3:36 PM, David Jencks <david.a.jen...@gmail.com> wrote:
> 
> As far as my experiments have shown, I can’t modify the git commit messages 
> to include the jira issue numbers I created to match the commits without 
> completely losing the git branch structure.
> 
> Therefore I’d like to simply try to merge the ibm contributions directly and 
> put the git commit hashes into the jira issues.  Hopefully I can do this 
> without problems from Alan’s update of the NOTICE file :-)
> 
> Thoughts? Objections?
> 
> thanks
> david jencks
> 
>> On Oct 14, 2016, at 7:46 AM, Alan Cabrera <l...@toolazydogs.com> wrote:
>> 
>> Git has been set up:
>> 
>> https://git-wip-us.apache.org/repos/asf?p=geronimo-yoko.git
>> 
>> 
>> Regards,
>> Alan
>> 
>>> On Oct 4, 2016, at 3:34 PM, David Jencks <david_jen...@yahoo.com> wrote:
>>> 
>>> Hi,
>>> 
>>> I’m no longer with IBM, but before I left I was strongly encouraged to make 
>>> the work we did on yoko publicly accessible, so it’s now at 
>>> https://github.com/djencks/geronimo-yoko
>>> 
>>> Both Joe Chacko and Neil Richards have now filed ICLAs.  I somewhat doubt 
>>> they will have time to massage the existing commits, nor do I know if it’s 
>>> possible to do without linearizing git history.  I’m hoping to have time 
>>> and energy to experiment with this.  At worst I think we could put the git 
>>> revision hashes into the Jira issues rather than the (preferable) reverse.
>>> 
>>> I’ve seen some vague rumors lately that it’s possible to have some repos 
>>> under git and some under svn.  When I have a little more time I’d like to 
>>> investigate this.  Do we need  a vote to authorize changing the yoko repo 
>>> to git?
>>> 
>>> thanks
>>> david jencks
>>> 
>>> 
>>> 
>> 
> 

Re: [VOTE] release geronimo-flava 2.3

[Alan Cabrera]

+1


Regards,
Alan

> On Nov 22, 2016, at 3:32 AM, Mark Struberg  wrote:
> 
> Hi folks!
> 
> Please VOTE on the release of geronimo-flava-2.3.
> We need this for every Java8 based spec jar.
> 
> Here is the staging repo:
> https://repository.apache.org/content/repositories/orgapachegeronimo-1029/
> 
> The source release can be found here
> https://repository.apache.org/content/repositories/orgapachegeronimo-1029/org/apache/geronimo/genesis/genesis/2.3/
> 
> My KEY can be found in https://svn.apache.org/repos/asf/geronimo/KEYS
> 
> [+1] ship it!
> [+0] meh, don't care
> [-1] stop, becaue ${showstopper}
> 
> The VOTE is open for 72h.
> 
> Here is my own +1
> 
> 
> txs and LieGrue,
> strub
> 
> 

Re: [VOTE] release geronimo-flava 2.3

[Alan Cabrera]

Oi, sorry.  Let me review it later this afternoon.

> On Dec 4, 2016, at 2:33 PM, Mark Struberg  wrote:
> 
> ping, anyone up for the vote?
> 
> txs and LieGrue,
> strub
> 
> 
>> Am 22.11.2016 um 14:18 schrieb Romain Manni-Bucau :
>> 
>> +1
>> 
>> 
>> Romain Manni-Bucau
>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
>> 
>> 2016-11-22 12:32 GMT+01:00 Mark Struberg :
>> Hi folks!
>> 
>> Please VOTE on the release of geronimo-flava-2.3.
>> We need this for every Java8 based spec jar.
>> 
>> Here is the staging repo:
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1029/
>> 
>> The source release can be found here
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1029/org/apache/geronimo/genesis/genesis/2.3/
>> 
>> My KEY can be found in https://svn.apache.org/repos/asf/geronimo/KEYS
>> 
>> [+1] ship it!
>> [+0] meh, don't care
>> [-1] stop, becaue ${showstopper}
>> 
>> The VOTE is open for 72h.
>> 
>> Here is my own +1
>> 
>> 
>> txs and LieGrue,
>> strub
>> 
>> 
>> 
> 

[REPORT] Apache Geronimo - October 2016

[Alan Cabrera]

## Description: 
Apache Geronimo is a JEE6 certified open source server runtime that integrates
the best open source projects to create Java/OSGi server runtimes that meet 
the needs of enterprise developers and system administrators.
   
## Issues: 
- We are concerned with the lack of community activity
- The inability to obtain a AL2.0 compatible JEE TCK pins Geronimo to JEE6
- CI/TCK setup has fallen into disrepair
   
## Ongoing Work - prepare for possible breakup and shuttering or downsizing:
- bring in any PMC members of sibling projects in Geronimo's JEE6 universe
- inventory any required interactions between individual specs
- inventory outstanding bugs in JEE6 specs and assess the amount of work 
  required
- inventory what are the outstanding security issues and assess the amount of 
  work required  (will likely need to remove distributions until fixes can be 
put into place)
- inventory CI setup and assess the amount of work required
- inventory TCK setup and assess the amount of work required

## Activity: 
- Released geronimo-validation-1.1 v1.0
- Apache Yoko moved to git to be worked on by David Jencks, Joe Chacko,
  and Neil Richards
   
## Health report: 
- Last quarter was a very light quarter for Apache Geronimo, in spite of
  this quarter's release 
   
## PMC changes: 
   
 - Currently 42 PMC members. 
 - No new PMC members added in the last 3 months 
 - Last PMC addition was Romain Manni-Bucau on Wed Aug 06 2014 
   
## Committer base changes: 
   
 - Adding Joe Chacko and Neil Richards. 
   
## Releases: 
   
 - Released geronimo-validation-1.1 v1.0 
   
## Mailing list activity: 
   
 - Even though there is a moderate level of activity on the mailing lists,
   it is still very low. 
   
 - dev@geronimo.apache.org:  
- 356 subscribers (up 0 in the last 3 months): 
- 95 emails sent to list (36 in previous quarter) 
   
 - geronimo-...@geronimo.apache.org:  
- 43 subscribers (up 0 in the last 3 months) 
   
 - s...@geronimo.apache.org:  
- 99 subscribers (up 0 in the last 3 months): 
- 16 emails sent to list (26 in previous quarter) 
   
 - servicemix-...@geronimo.apache.org:  
- 10 subscribers (up 0 in the last 3 months) 
   
 - tck-comm...@geronimo.apache.org:  
- 6 subscribers (up 0 in the last 3 months) 
   
 - u...@geronimo.apache.org:  
- 447 subscribers (up 0 in the last 3 months): 
- 2 emails sent to list (1 in previous quarter) 
   
 - xbean-...@geronimo.apache.org:  
- 36 subscribers (up 1 in the last 3 months): 
- 9 emails sent to list (7 in previous quarter) 
   
 - xbean-...@geronimo.apache.org:  
- 17 subscribers (up 0 in the last 3 months): 
- 1 emails sent to list (0 in previous quarter) 
   
 - xbean-u...@geronimo.apache.org:  
- 34 subscribers (up 0 in the last 3 months): 
- 1 emails sent to list (0 in previous quarter) 
   
   
## JIRA activity: 
   
 - 5 JIRA tickets created in the last 3 months 
 - 4 JIRA tickets closed/resolved in the last 3 months 

Re: [RESULT][VOTE] Release geronimo-validation 1.0 of the 1.1 spec version

[Alan Cabrera]

Yay!


Regards,
Alan

> On Oct 14, 2016, at 2:52 AM, Romain Manni-Bucau  wrote:
> 
> Which makes 3 +1 bindings and no other votes.
> 
> Thanks Mark and Guillaume!
> 
> Will promote the binaries now.
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Wordpress Blog 
>  | Github  
> | LinkedIn  | Tomitriber 
>  | JavaEE Factory 
> 
> 2016-10-14 11:49 GMT+02:00 Guillaume Nodet  >:
> +1
> 
> 2016-10-06 14:37 GMT+02:00 Romain Manni-Bucau  >:
> Hi again,
> 
> I'd still like to release a 1.0 of our validation jar.
> 
> After having checked with gunnar the jar and removed the @Deprecated we had 
> our jar should be fine (see 
> https://github.com/beanvalidation/beanvalidation.org/issues/35#issuecomment-251938455
>  
> 
>  for the conversation on that) so I staged a 1.0 (yeah!).
> 
> Here is the staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1027/ 
> 
> 
> And the source jar is at: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1027/org/apache/geronimo/specs/geronimo-validation_1.1_spec/1.0/geronimo-validation_1.1_spec-1.0-source-release.zip
>  
> 
> 
> 
> My key can be found at
> https://dist.apache.org/repos/dist/release/tomee/KEYS 
> 
> 
> please VOTE
> [+1] all fine
> [+0] don't care
> [-1] stop, because ${good.reason}
> 
> here is my +1
> 
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Wordpress Blog 
>  | Github  
> | LinkedIn  | Tomitriber 
>  | JavaEE Factory 
> 
> 
> 
> -- 
> 
> Guillaume Nodet
> 
> Red Hat, Open Source Integration
> 
> Email: gno...@redhat.com 
> Web: http://fusesource.com 
> Blog: http://gnodet.blogspot.com/ 
> 
> 

Re: More on Yoko

[Alan Cabrera]

Git has been set up:

https://git-wip-us.apache.org/repos/asf?p=geronimo-yoko.git


Regards,
Alan

> On Oct 4, 2016, at 3:34 PM, David Jencks  wrote:
> 
> Hi,
> 
> I’m no longer with IBM, but before I left I was strongly encouraged to make 
> the work we did on yoko publicly accessible, so it’s now at 
> https://github.com/djencks/geronimo-yoko
> 
> Both Joe Chacko and Neil Richards have now filed ICLAs.  I somewhat doubt 
> they will have time to massage the existing commits, nor do I know if it’s 
> possible to do without linearizing git history.  I’m hoping to have time and 
> energy to experiment with this.  At worst I think we could put the git 
> revision hashes into the Jira issues rather than the (preferable) reverse.
> 
> I’ve seen some vague rumors lately that it’s possible to have some repos 
> under git and some under svn.  When I have a little more time I’d like to 
> investigate this.  Do we need  a vote to authorize changing the yoko repo to 
> git?
> 
> thanks
> david jencks
> 
> 
> 

Re: [VOTE] Release geronimo-validation 1.0 spec API

[Alan Cabrera]

Where is the tag for this release?  I don’t see it in 

https://svn.apache.org/repos/asf/geronimo/specs/tags/ 



Regards,
Alan

> On Oct 6, 2016, at 4:54 AM, Romain Manni-Bucau  wrote:
> 
> Hi guys,
> 
> I'd like to release a 1.0 of our validation jar.
> 
> After having checked with gunnar the jar and removed the @Deprecated we had 
> our jar should be fine (see 
> https://github.com/beanvalidation/beanvalidation.org/issues/35#issuecomment-251938455
>  
> 
>  for the conversation on that) so I staged a 1.0 (yeah!).
> 
> Here is the staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1026/ 
> 
> 
> And the source jar is at: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1026/org/apache/geronimo/specs/geronimo-validation_1.1_spec/1.0/geronimo-validation_1.1_spec-1.0-source-release.zip
>  
> 
> 
> 
> 
> My key can be found at
> https://dist.apache.org/repos/dist/release/tomee/KEYS 
> 
> 
> please VOTE
> [+1] all fine
> [+0] don't care
> [-1] stop, because ${good.reason}
> 
> here is my +1
> 
> Thanks,
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Wordpress Blog 
>  | Github  
> | LinkedIn  | Tomitriber 
>  | JavaEE Factory 
> 

Re: [VOTE] Release geronimo-validation 1.0 spec API

[Alan Cabrera]

Great.  Where is the TCK and how was it obtained?  I’d like to double check 
that we are allowed to use it.


Regards,
Alan

> On Oct 6, 2016, at 5:21 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> this is a requirement for an implementation but yes bval passes it with this 
> and previous release. It is just about removing @Deprecated
> 
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog 
> <https://blog-rmannibucau.rhcloud.com/> | Old Wordpress Blog 
> <http://rmannibucau.wordpress.com/> | Github <https://github.com/rmannibucau> 
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber 
> <http://www.tomitribe.com/> | JavaEE Factory 
> <https://javaeefactory-rmannibucau.rhcloud.com/>
> 2016-10-06 14:19 GMT+02:00 Alan Cabrera <l...@toolazydogs.com 
> <mailto:l...@toolazydogs.com>>:
> IIUC, one of the licensing requirements of the spec is that it passes the 
> TCK.  Was the TCK run against this release?
> 
> 
> Regards,
> Alan
> 
> 
>> On Oct 6, 2016, at 4:54 AM, Romain Manni-Bucau <rmannibu...@gmail.com 
>> <mailto:rmannibu...@gmail.com>> wrote:
>> 
>> Hi guys,
>> 
>> I'd like to release a 1.0 of our validation jar.
>> 
>> After having checked with gunnar the jar and removed the @Deprecated we had 
>> our jar should be fine (see 
>> https://github.com/beanvalidation/beanvalidation.org/issues/35#issuecomment-251938455
>>  
>> <https://github.com/beanvalidation/beanvalidation.org/issues/35#issuecomment-251938455>
>>  for the conversation on that) so I staged a 1.0 (yeah!).
>> 
>> Here is the staging repo: 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1026/ 
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1026/>
>> 
>> And the source jar is at: 
>> https://repository.apache.org/content/repositories/orgapachegeronimo-1026/org/apache/geronimo/specs/geronimo-validation_1.1_spec/1.0/geronimo-validation_1.1_spec-1.0-source-release.zip
>>  
>> <https://repository.apache.org/content/repositories/orgapachegeronimo-1026/org/apache/geronimo/specs/geronimo-validation_1.1_spec/1.0/geronimo-validation_1.1_spec-1.0-source-release.zip>
>> 
>> 
>> 
>> My key can be found at
>> https://dist.apache.org/repos/dist/release/tomee/KEYS 
>> <https://dist.apache.org/repos/dist/release/tomee/KEYS>
>> 
>> please VOTE
>> [+1] all fine
>> [+0] don't care
>> [-1] stop, because ${good.reason}
>> 
>> here is my +1
>> 
>> Thanks,
>> Romain Manni-Bucau
>> @rmannibucau <https://twitter.com/rmannibucau> |  Blog 
>> <https://blog-rmannibucau.rhcloud.com/> | Old Wordpress Blog 
>> <http://rmannibucau.wordpress.com/> | Github 
>> <https://github.com/rmannibucau> | LinkedIn 
>> <https://www.linkedin.com/in/rmannibucau> | Tomitriber 
>> <http://www.tomitribe.com/> | JavaEE Factory 
>> <https://javaeefactory-rmannibucau.rhcloud.com/>
> 

Re: [VOTE] Release geronimo-validation 1.0 spec API

[Alan Cabrera]

IIUC, one of the licensing requirements of the spec is that it passes the TCK.  
Was the TCK run against this release?


Regards,
Alan


> On Oct 6, 2016, at 4:54 AM, Romain Manni-Bucau  wrote:
> 
> Hi guys,
> 
> I'd like to release a 1.0 of our validation jar.
> 
> After having checked with gunnar the jar and removed the @Deprecated we had 
> our jar should be fine (see 
> https://github.com/beanvalidation/beanvalidation.org/issues/35#issuecomment-251938455
>  
> 
>  for the conversation on that) so I staged a 1.0 (yeah!).
> 
> Here is the staging repo: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1026/ 
> 
> 
> And the source jar is at: 
> https://repository.apache.org/content/repositories/orgapachegeronimo-1026/org/apache/geronimo/specs/geronimo-validation_1.1_spec/1.0/geronimo-validation_1.1_spec-1.0-source-release.zip
>  
> 
> 
> 
> 
> My key can be found at
> https://dist.apache.org/repos/dist/release/tomee/KEYS 
> 
> 
> please VOTE
> [+1] all fine
> [+0] don't care
> [-1] stop, because ${good.reason}
> 
> here is my +1
> 
> Thanks,
> Romain Manni-Bucau
> @rmannibucau  |  Blog 
>  | Old Wordpress Blog 
>  | Github  
> | LinkedIn  | Tomitriber 
>  | JavaEE Factory 
> 

Re: More on Yoko

[Alan Cabrera]

> On Oct 4, 2016, at 5:37 PM, Alan Cabrera <l...@toolazydogs.com> wrote:
> 
> 
>> On Oct 4, 2016, at 3:34 PM, David Jencks <david_jen...@yahoo.com> wrote:
>> 
>> Hi,
>> 
>> I’m no longer with IBM, but before I left I was strongly encouraged to make 
>> the work we did on yoko publicly accessible, so it’s now at 
>> https://github.com/djencks/geronimo-yoko
>> 
>> Both Joe Chacko and Neil Richards have now filed ICLAs.  I somewhat doubt 
>> they will have time to massage the existing commits, nor do I know if it’s 
>> possible to do without linearizing git history.  I’m hoping to have time and 
>> energy to experiment with this.  At worst I think we could put the git 
>> revision hashes into the Jira issues rather than the (preferable) reverse.
>> 
>> I’ve seen some vague rumors lately that it’s possible to have some repos 
>> under git and some under svn.  When I have a little more time I’d like to 
>> investigate this.  Do we need  a vote to authorize changing the yoko repo to 
>> git?
> 
> I don’t think anyone would mind.  What do we do, file a Jira ticket?

Ok, looks like we move svn -> git.  Then enable github integration.  Should we 
start w/ Yoko to work out the kinks?


Regards,
Alan

Re: More on Yoko

[Alan Cabrera]

> On Oct 4, 2016, at 3:34 PM, David Jencks  wrote:
> 
> Hi,
> 
> I’m no longer with IBM, but before I left I was strongly encouraged to make 
> the work we did on yoko publicly accessible, so it’s now at 
> https://github.com/djencks/geronimo-yoko
> 
> Both Joe Chacko and Neil Richards have now filed ICLAs.  I somewhat doubt 
> they will have time to massage the existing commits, nor do I know if it’s 
> possible to do without linearizing git history.  I’m hoping to have time and 
> energy to experiment with this.  At worst I think we could put the git 
> revision hashes into the Jira issues rather than the (preferable) reverse.
> 
> I’ve seen some vague rumors lately that it’s possible to have some repos 
> under git and some under svn.  When I have a little more time I’d like to 
> investigate this.  Do we need  a vote to authorize changing the yoko repo to 
> git?

I don’t think anyone would mind.  What do we do, file a Jira ticket?


Regards,
Alan

Running the TCK

[Alan Cabrera]

It’s been a while since I’ve gotten the TCK running.  A while back I 
“organized” my notes and can’t seem to find my TCK notes.

Does anyone have any notes handy?  If it requires a conversation we can “meet” 
on the TCK list.


Regards,
Alan

[REPORT] Apache Geronimo - July 2016

[Alan Cabrera]

## Description: 
Apache Geronimo is a JEE6 certified open source server runtime that integrates
the best open source projects to create Java/OSGi server runtimes that meet 
the needs of enterprise developers and system administrators.
   
## Issues: 
- We are concerned with the lack of community activity
- The inability to obtain a AL2.0 compatible JEE TCK pins Geronimo to JEE6
- CI/TCK setup has fallen into disrepair

## Next Steps - prepare for possible breakup and shuttering or downsizing:
- bring in any PMC members of sibling projects in Geronimo's JEE6 universe
- inventory any required interactions between individual specs
- inventory outstanding bugs in JEE6 specs and assess the amount of work 
  required
- inventory what are the outstanding security issues and assess the amount of 
  work required  (will likely need to remove distributions until fixes can be 
put into place)
- inventory CI setup and assess the amount of work required
- inventory TCK setup and assess the amount of work required
   
## Activity: 
 - No releases
 - Patch to JavaMail 1.4 needs to pass TCK before it can be *officially* 
   released. (it is likely to be published as an alpha release, as was done in
 past)
 - Some have expressed an interest in JEE configuration - overlap w/ Tamaya 
   podling.  (too early to tell if this effort will come to fruition)
   
## Health report: 
- Last quarter was a very light quarter for Apache Geronimo. 
   
## PMC changes: 
   
 - Currently 42 PMC members. 
 - No new PMC members added in the last 3 months 
 - Last PMC addition was Romain Manni-Bucau on Wed Aug 06 2014 
   
## Committer base changes: 
   
 - Currently 69 committers. 
 - No new committers added in the last 3 months 
 - Last committer addition was Hendrik Saly at Thu Oct 23 2014 
   
## Releases: 
   
 - Last release was 3.18 on Tue May 20 2014 
   
## Mailing list activity: 
   
 - TODO Please explain what the following statistics mean 
   for the project. If there is nothing significant in the figures, omit this 
   section. 
   
 - dev@geronimo.apache.org:  
- 355 subscribers (up 0 in the last 3 months): 
- 50 emails sent to list (24 in previous quarter) 
   
 - geronimo-...@geronimo.apache.org:  
- 43 subscribers (up 0 in the last 3 months) 
   
 - s...@geronimo.apache.org:  
- 99 subscribers (up 0 in the last 3 months): 
- 26 emails sent to list (3 in previous quarter) 
   
 - servicemix-...@geronimo.apache.org:  
- 10 subscribers (up 0 in the last 3 months) 
   
 - tck-comm...@geronimo.apache.org:  
- 6 subscribers (up 1 in the last 3 months) 
   
 - u...@geronimo.apache.org:  
- 447 subscribers (down -4 in the last 3 months): 
- 2 emails sent to list (8 in previous quarter) 
   
 - xbean-...@geronimo.apache.org:  
- 35 subscribers (up 1 in the last 3 months): 
- 7 emails sent to list (0 in previous quarter) 
   
 - xbean-...@geronimo.apache.org:  
- 17 subscribers (up 0 in the last 3 months): 
- 0 emails sent to list (0 in previous quarter) 
   
 - xbean-u...@geronimo.apache.org:  
- 34 subscribers (up 1 in the last 3 months): 
- 0 emails sent to list (1 in previous quarter) 
   
   
## JIRA activity: 
   
 - 4 JIRA tickets created in the last 3 months 
 - 1 JIRA tickets closed/resolved in the last 3 months 

Re: Configuration for Java SE and Java EE JSR

[Alan Cabrera]

You’re welcome to ticker around w/ configuration with the Geronimo JEE pantheon.

Tamaya developers are welcome ticker around w/ configuration with the Geronimo 
JEE pantheon.

It’s ok if Geronimo has two, or even more, different configuration mechanisms.  
I predict that the config adapter to accommodate the two would be pretty damn 
interesting, especially if it were a result of collaboration between Tamaya 
developers and your team, Mark.

I will explicitly point out, as I’ve said in other emails on this topic, 
discussions of JSR/JCP have no place on these mailing lists, usually.

With that said, how can we help?  I know that we need to pull off the dust 
covers of a lot of our tooling.  I’m generating an inventory of what’s fallen 
into disrepair.


Regards,
Alan

> On Jul 14, 2016, at 3:10 PM, Mark Struberg  wrote:
> 
> Hi folks!
> 
> I’ve started to extract the configuration work I’ve done in OWB, MyFaces and 
> DeltaSpike into an own little project.
> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard 
> Petracek.
> 
> My goal is to establish an own JSR for configuration.
> 
> So far it consists of 2 classes for the API and 4 classes for the SPI.
> The source can be found here.
> https://github.com/struberg/javaConfig
> 
> And that’s pretty much it! There is not much more needed for it.
> 
> I would love to move this to Geronimo. Simply because geronimo is kind of an 
> EE-commons for the ASF nowadays ;)
> 
> wdyt?
> 
> LieGrue,
> strub

Re: Configuration for Java SE and Java EE JSR

[Alan Cabrera]

Can we have a weekend moratorium on this thread so we call all cool off?

I’d like to toss out some important points to consider over the weekend.

TL;DR:
it’s ok for there to be multiple ASF projects that accomplish the exact same 
thing
any competent person is welcome to join any ASF project
the Apache Software Foundation, itself, does not submit JSRs
It’s ok for there to be multiple ASF projects that accomplish the exact same 
thing

There is no land grab of ideas or product spaces here at the ASF.  If a bunch 
of people I wanted to implement a map/reduce system we could. The fact that 
Apache Hadoop is in existence shouldn’t be a barrier.  I’ll go even further and 
say that because of AL2.0, we could fork bits, or even co-opt huge swaths of 
code, from Apache Hadoop and use it to our own means.  The only criteria the 
ASF would hold our new project to is that of a healthy vibrant community.

Any competent person is welcome to join any ASF project

Anyone could join our new fictitious project, even Apache Hadoop developers.  
An interesting result of this is that just because people worked on Apache 
Hadoop, they are not married to Apache Hadoop.  They are not traitors if they 
decide to also dabble in our new project.  So long as there are healthy vibrant 
communities on both sides, e.g. interactions are done in a respectful manner, 
it’s all good in the eyes of the ASF.

The Apache Software Foundation, itself, does not incubate/submit JSRs

The protocol etiquette of submitting a JSR is, thankfully, the JCP’s headache 
and such discussions should take place outside of the ASF project mailing 
lists.  Also, just because a project is a part of the ASF does not ensure that 
it will be a viable JSR. Being an ASF project does not imply that the ASF 
explicitly or implicitly endorses it as a JSR contender. IMHO, it may be a bit 
premature to submit a JSR for this problem domain; jm2c.


Regards,
Alan


> On Jul 14, 2016, at 3:10 PM, Mark Struberg  wrote:
> 
> Hi folks!
> 
> I’ve started to extract the configuration work I’ve done in OWB, MyFaces and 
> DeltaSpike into an own little project.
> For the MyFaces and DeltaSpike parts I got help from ASF member Gerhard 
> Petracek.
> 
> My goal is to establish an own JSR for configuration.
> 
> So far it consists of 2 classes for the API and 4 classes for the SPI.
> The source can be found here.
> https://github.com/struberg/javaConfig
> 
> And that’s pretty much it! There is not much more needed for it.
> 
> I would love to move this to Geronimo. Simply because geronimo is kind of an 
> EE-commons for the ASF nowadays ;)
> 
> wdyt?
> 
> LieGrue,
> strub

[REPORT] Apache Geronimo - May 2016

[Alan Cabrera]

## Description: 
Apache Geronimo is an open source server runtime that integrates the best open
source projects to create Java/OSGi server runtimes that meet the needs of
enterprise developers and system administrators.
   
## Issues: 
- We are concerned with our current level of community activity.
- There are outstanding concerns about the inability to obtain a
  compatible JEE TCK and how that will ultimately affect the project.
- The PMC has missed quarterly reports.
- Still chasing down getting IBM’s WAS Liberty application server
  fixes to the Yoko ORB integrated.  Hoping to get the original
  engineers to perform the integration.
   
## Activity: 
 - No releases
 - Patch to JavaMail 1.4 to be released soon
   
## Health report: 
- Last quarter was a very light quarter for Apache Geronimo. 
  
## PMC changes: 
   
 - Currently 42 PMC members. 
 - No new PMC members added in the last 3 months 
 - Last PMC addition was Romain Manni-Bucau on Wed Aug 06 2014 
   
## Committer base changes: 
   
 - Currently 69 committers. 
 - No new committers added in the last 3 months 
 - Last committer addition was Hendrik Saly at Thu Oct 23 2014 
   
## Releases: 
   
 - Last release was 3.18 on Tue May 20 2014 
   
## Mailing list activity: 
   
 - Activity is low.  Community responds reasinably quickly
   to submitted patches
   
 - dev@geronimo.apache.org:  
- 356 subscribers (down -1 in the last 3 months): 
- 44 emails sent to list (23 in previous quarter) 
   
 - geronimo-...@geronimo.apache.org:  
- 43 subscribers (down -1 in the last 3 months) 
   
 - s...@geronimo.apache.org:  
- 99 subscribers (down -1 in the last 3 months): 
- 24 emails sent to list (1 in previous quarter) 
   
 - servicemix-...@geronimo.apache.org:  
- 10 subscribers (up 0 in the last 3 months) 
   
 - tck-comm...@geronimo.apache.org:  
- 6 subscribers (up 1 in the last 3 months) 
   
 - u...@geronimo.apache.org:  
- 450 subscribers (down -4 in the last 3 months): 
- 7 emails sent to list (8 in previous quarter) 
   
 - xbean-...@geronimo.apache.org:  
- 35 subscribers (up 1 in the last 3 months): 
- 5 emails sent to list (3 in previous quarter) 
   
 - xbean-...@geronimo.apache.org:  
- 17 subscribers (up 0 in the last 3 months): 
- 0 emails sent to list (3 in previous quarter) 
   
 - xbean-u...@geronimo.apache.org:  
- 34 subscribers (up 1 in the last 3 months): 
- 1 emails sent to list (1 in previous quarter) 
   
   
## JIRA activity: 
   
 - 1 JIRA tickets created in the last 3 months 
 - 1 JIRA tickets closed/resolved in the last 3 months 
   

[jira] [Closed] (XBEAN-291) Help USA@.1 (866) 503.0554:(((( Gmail support phone number QB Witty%*! (1*866*503*0554 )~Gmail (QB.PRO) tech support number

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/XBEAN-291?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera closed XBEAN-291.
--
Resolution: Invalid

> Help USA@.1 (866) 503.0554: Gmail support phone number QB Witty%*! 
> (1*866*503*0554 )~Gmail (QB.PRO) tech support number
> ---
>
> Key: XBEAN-291
> URL: https://issues.apache.org/jira/browse/XBEAN-291
> Project: XBean
>  Issue Type: Bug
>Reporter: sachini
>
> Help USA@.1 (866) 503.0554: Gmail support phone number - plugin detail 
> Help USA@.1 (866) 503.0554: Gmail support phone number QB Witty%*! 
> (1*866*503*0554 )~Gmail (QB.PRO) tech support number, Gmail 2013 support 
> number, Gmail customer service number USA Helpline TECH 
> ))1-866-503-0554((Gmail technical support phone number Gmail phone number QB 
> SUPPORT ON ((1-866-503- 0554)) Gmail PHONE NUMBER AND Gmail SUPPORT PHONE 
> NUMBER Gmail Toll Free, Intuit@(1-866-503- 0554)@ Gmail Tech Support Phone 
> Number provides online solution for all USA/CANADA clients. For any help of 
> query call 1 866 503 0554 to get all Gmail account solution. @@Call, 
> 1-866-503-0554 for all type help by Gmail tech support phone number, Intuit 
> Gmail Tech Support Phone Number, Gmail Help Desk Phone Number, Gmail tech 
> support number, Gmail technical support phone number,@@@ Gmail phone number, 
> Gmail technical support number, Gmail support phone number, Gmail technical 
> support, Gmail Customer Service Phone Number, Gmail Customer Service Number, 
> Gmail Customer Support Phone Number, Gmail Customer Support Number, Gmail 
> Customer Service Helpline Number, Gmail Customer Care Number, Gmail support 
> team phone number, @ Gmail help number-Gmail Helpline Number;Gmail help 
> phone numberGmail Helpline Number, Gmail Tech Support Toll free Number, Gmail 
> Support Telephone Number,Gmail Tech Support Telephone number, Gmail Tech 
> Support contact number, Gmail support contact number, Gmail technical support 
> contact number. Call, Gmail tech support phone number, Intuit Gmail Tech 
> Support Phone Number, Gmail Help Desk Phone Number,Gmail tech support number, 
> Gmail technical support phone number, Gmail phone number, Gmail technical 
> support number, Gmailsupport phone number. It is very popular toll free 
> number which provide by Gmail technical support, Gmail Customer Service Phone 
> Number,Gmail Customer Service Number, Gmail Customer Support Phone Number, 
> Gmail Customer Support Number, Gmail Customer Service Helpline Number, Gmail 
> Customer Care Number, Gmail support team phone number. Call, Gmail tech 
> support phone number, IntuitGmail Tech Support Phone Number, Gmail Help Desk 
> Phone Number, Gmail tech support number, Gmail technical support phone 
> number, Gmail phone number, Gmail technical support number, Gmail support 
> phone number, Gmail technical support, GmailCustomer Service Phone Number, 
> Gmail Customer Service Number, Gmail Customer Support Phone Number, Gmail 
> Customer Support Number, Gmail Customer Service Helpline Number, Gmail 
> Customer Care Number, Gmail support team phone number, Gmail help 
> number-Gmail Helpline Number; Gmail help phone number, Gmail Helpline Number, 
> Gmail Tech Support Toll free Number, GmailSupport Telephone Number, Gmail 
> Tech Support Telephone number, Gmail Tech Support contact number, Gmail 
> support contact number,Gmail technical support contact number, Gmail support 
> phone number, Gmail payroll support phone number. Gmail payroll customer 
> support phone number 1866-503-0554 Gmail technical help telephone number, 
> Gmail technical help contact number, Gmail technical support contact number, 
> Gmail contact number, Gmail contact phone number, Gmail contact telephone 
> number, Gmail 24 hour contact number, Gmail customer support contact number, 
> Gmail customer service contact number, Gmail official number, Gmail official 
> contact number, Gmail 866 contact number, Gmail toll free number, 866 number 
> for Gmail support, Gmail 24/7 support phone number Gmail support phone 
> number,Gmail support phone number,Gmail help phone number, Gmail technical 
> support number.GmailPRO support number, Gmail phone number, Gmail tech 
> support number, Gmail customer support number, Gmail customer support phone 
> number, Gmail customer service phone number, Gmail payroll customer service 
> phone number, GmailPRO support phone number. Help@Call 1-866-503-0554/.Gmail 
> 24/7 support phone
> https://www.lonelyplanet.com/thorntree/forums/americas-united-states-of-america/united-states/gmail-1-844-550-1555-tech-support-phone-number-gmail-customer-support-number-usa-canada-uk-australia



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Need quarterly board report for this month

[Alan Cabrera]

We missed last month’s report.  Would someone like to take a crack at this 
month’s?


Regards,
Alan

Re: Slack channel?

[Alan Cabrera]

> On May 11, 2016, at 10:09 AM, Romain Manni-Bucau <rmannibu...@gmail.com> 
> wrote:
> 
> 
> 
> 2016-05-11 16:05 GMT+02:00 Alan Cabrera <l...@toolazydogs.com 
> <mailto:l...@toolazydogs.com>>:
> 
>> On May 10, 2016, at 4:00 AM, Romain Manni-Bucau <rmannibu...@gmail.com 
>> <mailto:rmannibu...@gmail.com>> wrote:
>> 
>> @Mark: bot are supported as well as web hooks.
> 
> Yes, excellent support for bots/web hooks.
> 
> I also like how you can search old chat threads as well as be alerted when 
> text matches certain patterns.
> 
> 
> You can't in the free version, don't recall the number exactly but there is a 
> limit of content which is quite reachable for a long term solution.

Let me reach out to them.  Maybe we can get the “non-free” version.


Regards,
Alan

Re: Slack channel?

[Alan Cabrera]

> On May 10, 2016, at 4:00 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> @Mark: bot are supported as well as web hooks.

Yes, excellent support for bots/web hooks.

I also like how you can search old chat threads as well as be alerted when text 
matches certain patterns.

> Didn't investigate more than connecting and saying hello on few channels but 
> seems gitter.im <http://gitter.im/> is used for a lot of OS projects 
> (probably cause linked to github/twitter OOTB). Maybe another option if we 
> are tired of IRC.
> 
> 
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> |  Blog 
> <http://rmannibucau.wordpress.com/> | Github <https://github.com/rmannibucau> 
> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Tomitriber 
> <http://www.tomitribe.com/> | JavaEE Factory 
> <https://javaeefactory-rmannibucau.rhcloud.com/>
> 2016-05-09 21:09 GMT+02:00 Mark Struberg <strub...@yahoo.de 
> <mailto:strub...@yahoo.de>>:
> hmm, no bot support, commercial, not really open, ...
> Great for commercial projects, but imo not that good for an OSS project.
> 
> LieGrue,
> strub
> 
> 
> 
> 
> 
> > On Saturday, 30 April 2016, 20:01, Alan Cabrera <l...@toolazydogs.com 
> > <mailto:l...@toolazydogs.com>> wrote:
> > > wdyt?  I love Slack.
> >
> >
> > Regards,
> > Alan
> >
> 

Re: geronimo-javamail_1.4-1.9.0 release?

[Alan Cabrera]

What work remains?


> On Apr 30, 2016, at 6:26 PM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 
> +1
> 
> Dont recall the exact status but 1.5 work started at some point. Should it 
> get synch-ed+go out at the same time?
> Le 1 mai 2016 00:17, "David Jencks" <david_jen...@yahoo.com 
> <mailto:david_jen...@yahoo.com>> a écrit :
> That would be great!
> 
> david jencks
> 
> > On Apr 30, 2016, at 3:09 PM, Alan Cabrera <l...@toolazydogs.com 
> > <mailto:l...@toolazydogs.com>> wrote:
> >
> > I’ve just committed GERONIMO-6552.  I think it’s time to do a 1.9.0 release 
> > of geronimo-javamail_1.4.  Any objections?
> >
> >
> > Regards,
> > Alan
> >
> 

[jira] [Closed] (GERONIMO-6552) Javamail module not fully reads SMTP server responses

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera closed GERONIMO-6552.
--
Resolution: Fixed

> Javamail module not fully reads SMTP server responses
> -
>
> Key: GERONIMO-6552
> URL: https://issues.apache.org/jira/browse/GERONIMO-6552
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>Reporter: Alexei Osipov
>    Assignee: Alan Cabrera
>Priority: Minor
> Attachments: GERONIMO_6552_Read_all_lines_after_sending_content.patch
>
>
> Method {{sendData(MimeMessage msg)}} of class {{SMTPConnection}} in module 
> {{geronimo-javamail_1.4_provider}} reads only first line of response after 
> sending content.
> This causes two problems in case of *multi-line* response:
> 1) Only the first line of response is received from remote server. So the 
> SMPT session is left in inconsistent state.
> 2) In case of error only the first line of error message is passed to 
> exception.
> The problem is present in geronimo-javamail_1.4_provider version 1.8.4 and in 
> trunk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

geronimo-javamail_1.4-1.9.0 release?

[Alan Cabrera]

I’ve just committed GERONIMO-6552.  I think it’s time to do a 1.9.0 release of 
geronimo-javamail_1.4.  Any objections?


Regards,
Alan

[jira] [Assigned] (GERONIMO-6552) Javamail module not fully reads SMTP server responses

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-6552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera reassigned GERONIMO-6552:
--

Assignee: Alan Cabrera

> Javamail module not fully reads SMTP server responses
> -
>
> Key: GERONIMO-6552
> URL: https://issues.apache.org/jira/browse/GERONIMO-6552
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: mail
>Reporter: Alexei Osipov
>    Assignee: Alan Cabrera
>Priority: Minor
> Attachments: GERONIMO_6552_Read_all_lines_after_sending_content.patch
>
>
> Method {{sendData(MimeMessage msg)}} of class {{SMTPConnection}} in module 
> {{geronimo-javamail_1.4_provider}} reads only first line of response after 
> sending content.
> This causes two problems in case of *multi-line* response:
> 1) Only the first line of response is received from remote server. So the 
> SMPT session is left in inconsistent state.
> 2) In case of error only the first line of error message is passed to 
> exception.
> The problem is present in geronimo-javamail_1.4_provider version 1.8.4 and in 
> trunk.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Slack channel?

[Alan Cabrera]

wdyt?  I love Slack.


Regards,
Alan

[REPORT] Apache Geronimo - February 2016

[Alan Cabrera]

Please feel free to chime in with suggestions and changes:

## Description: 
Apache Geronimo is an open source server runtime that integrates the best open
source projects to create Java/OSGi server runtimes that meet the needs of
enterprise developers and system administrators.
   
## Issues: 
- We are concerned with our current level of community activity. 
- There are outstanding concerns about the inability to obtain a 
  compatible JEE TCK and how that will ultimately affect the project.
- Missed a few quarterly reports.  Need to get back on track.
- Need to follow up on getting IBM’s WAS Liberty application server
  fixes to the Yoko ORB integrated.  Hoping to get the original 
  engineers to perform the integration.
   
## Activity: 
 - No releases
   
## Health report: 
- Last quarter was a very light quarter for Apache Geronimo.  This was
  likely due to the holidays.
   
## PMC changes: 
   
 - Currently 42 PMC members. 
 - No new PMC members added in the last 3 months 
 - Last PMC addition was Romain Manni-Bucau on Wed Aug 06 2014 
   
## Committer base changes: 
   
 - Currently 69 committers. 
 - No new committers added in the last 3 months 
 - Last committer addition was Hendrik Saly at Thu Oct 23 2014 
   
## Releases: 
   
 - Last release was 3.18 on Tue May 20 2014 
   
## Mailing list activity: 
   
 - dev@geronimo.apache.org:  
- 357 subscribers (down -1 in the last 3 months): 
- 23 emails sent to list (28 in previous quarter) 
   
 - geronimo-...@geronimo.apache.org:  
- 44 subscribers (up 1 in the last 3 months) 
   
 - s...@geronimo.apache.org:  
- 100 subscribers (up 1 in the last 3 months): 
- 1 emails sent to list (7 in previous quarter) 
   
 - servicemix-...@geronimo.apache.org:  
- 10 subscribers (up 1 in the last 3 months) 
   
 - tck-comm...@geronimo.apache.org:  
- 5 subscribers (up 1 in the last 3 months) 
   
 - u...@geronimo.apache.org:  
- 454 subscribers (up 2 in the last 3 months): 
- 9 emails sent to list (3 in previous quarter) 
   
 - xbean-...@geronimo.apache.org:  
- 34 subscribers (up 1 in the last 3 months): 
- 3 emails sent to list (9 in previous quarter) 
   
 - xbean-...@geronimo.apache.org:  
- 17 subscribers (up 1 in the last 3 months): 
- 3 emails sent to list (6 in previous quarter) 
   
 - xbean-u...@geronimo.apache.org:  
- 33 subscribers (down -1 in the last 3 months): 
- 2 emails sent to list (0 in previous quarter) 
   
   
## JIRA activity: 
   
 - 1 JIRA tickets created in the last 3 months 
 - 0 JIRA tickets closed/resolved in the last 3 months 
   

Board report time 2015-12

[Alan Cabrera]

Here's the report that I sent to the board:

https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2015-12+-+December
 


If I missed something please let me know.  Thanks!


Regards,
Alan

[REPORT] Apache Geronimo - December 2015

[Alan Cabrera]

## Description:
Apache Geronimo is an open source server runtime that integrates the best open
source projects to create Java/OSGi server runtimes that meet the needs of
enterprise developers and system administrators.

## Issues:
- We are concerned with our current level of community activity. Some 
discussions
were started about next-gen Geronimo effort. Work needs to be done to kickstart
the conversation of where the community would like to take the project.

## Activity:
- A release of JavaMail
- A release of XBean
- Some developers have come forward to offer new features and fixes to Apache 
Yoko 
from the IBM WAS Liberty server. The smell of some fresh members is in the air!

## Health report:
- The project is a mature implementation of a mature technology. Given 
Geronimo's 
size and complexity coming up to speed and finding a compelling bit to work on 
is
a daunting task, to say the least. A fresh re-write or re-org of components 
into 
something that is compelling given contemporary sensibilities will likely spur 
activity since it should open up some green field opportunities. The trick will 
be
to balance the re-write/re-org with keeping important core capabilities, e.g. 
OSGi;
we don't want to throw the baby out with the bathwater. This fall is a good 
time 
to start the discussion with hopes of beginning a fresh start in the new year. 

- With that said, it should be pointed out that of the activity that occurs, it 
is 
indicative of an engaged community.
 
## PMC changes: 

- Currently 42 PMC members. 
- No new PMC members added in the last 3 months 
- Last PMC addition was Romain Manni-Bucau on Wed Aug 06 2014 

## Committer base changes: 

- Currently 69 committers. 
- No new committers added in the last 3 months 
- Last committer addition was Hendrik Saly at Thu Oct 23 2014 

## Releases:
 - XBean 4.5

 - geronimo-javamail_1.4 1.9.0-alpha-2


## Mailing list activity: 

- dev@geronimo.apache.org: 
- 357 subscribers (down -4 in the last 3 months): 
- 40 emails sent to list (79 in previous quarter) 

- servicemix-...@geronimo.apache.org: 
- 9 subscribers (up 0 in the last 3 months) 

- xbean-...@geronimo.apache.org: 
- 16 subscribers (up 0 in the last 3 months): 
- 7 emails sent to list (3 in previous quarter) 

- xbean-u...@geronimo.apache.org: 
- 34 subscribers (up 0 in the last 3 months): 
- 1 emails sent to list (0 in previous quarter) 

- tck-comm...@geronimo.apache.org: 
- 4 subscribers (up 0 in the last 3 months) 

- u...@geronimo.apache.org: 
- 452 subscribers (down -7 in the last 3 months): 
- 10 emails sent to list (5 in previous quarter) 

- geronimo-...@geronimo.apache.org: 
- 43 subscribers (up 0 in the last 3 months) 

- s...@geronimo.apache.org: 
- 99 subscribers (up 0 in the last 3 months): 
- 5 emails sent to list (23 in previous quarter) 

- xbean-...@geronimo.apache.org: 
- 33 subscribers (up 0 in the last 3 months): 
- 5 emails sent to list (12 in previous quarter) 


## JIRA activity: 

- 5 JIRA tickets created in the last 3 months 
- 2 JIRA tickets closed/resolved in the last 3 months

[REPORT] Apache Geronimo - November 2015

[Alan Cabrera]

## Description:
  Apache Geronimo is an open source server runtime that integrates the best open
  source projects to create Java/OSGi server runtimes that meet the needs of
  enterprise developers and system administrators.
   
## Issues:
- We are concerned with our current level of community activity.  Some 
discussions
were started about next-gen Geronimo effort.  Work needs to be done to kickstart
the conversation of where the community would like to take the project.
 
## Activity: 
 - A release of JavaMail
 - Some developers have come forward to offer new features and fixes to Apache 
Yoko 
   from the IBM WAS Liberty server.  The smell of some fresh members is in the 
air!
   
## Health report: 
 - The project is a mature implementation of a mature technology.  Given 
Geronimo's 
   size and complexity coming up to speed and finding a compelling bit to work 
on is
   a daunting task, to say the least.  A fresh re-write or re-org of components 
into 
   something that is compelling given contemporary sensibilities will likely 
spur 
   activity since it should open up some green field opportunities.  The trick 
will be
   to balance the re-write/re-org with keeping important core capabilities, 
e.g. OSGi;
   we don't want to throw the baby out with the bathwater.  This fall is a good 
time 
   to start the discussion with hopes of beginning a fresh start in the new 
year.  
 
-  With that said, it should be pointed out that of the activity that occurs, 
it is 
   indicative of an engaged community.
 
   
## PMC changes: 
   
 - Currently 42 PMC members. 
 - No new PMC members added in the last 3 months 
 - Last PMC addition was Romain Manni-Bucau on Wed Aug 06 2014 
   
## Committer base changes: 
   
 - Currently 69 committers. 
 - No new committers added in the last 3 months 
 - Last committer addition was Hendrik Saly at Thu Oct 23 2014 
   
## Releases: 
   
 - geronimo-javamail_1.4 1.9.0-alpha-2
   
## Mailing list activity: 
   
 - dev@geronimo.apache.org:  
- 358 subscribers (down -3 in the last 3 months): 
- 24 emails sent to list (102 in previous quarter) 
   
 - servicemix-...@geronimo.apache.org:  
- 9 subscribers (up 0 in the last 3 months) 
   
 - xbean-...@geronimo.apache.org:  
- 16 subscribers (up 0 in the last 3 months): 
- 4 emails sent to list (10 in previous quarter) 
   
 - xbean-u...@geronimo.apache.org:  
- 34 subscribers (up 0 in the last 3 months): 
- 0 emails sent to list (0 in previous quarter) 
   
 - tck-comm...@geronimo.apache.org:  
- 4 subscribers (up 0 in the last 3 months) 
   
 - u...@geronimo.apache.org:  
- 453 subscribers (down -6 in the last 3 months): 
- 3 emails sent to list (9 in previous quarter) 
   
 - geronimo-...@geronimo.apache.org:  
- 43 subscribers (up 0 in the last 3 months) 
   
 - s...@geronimo.apache.org:  
- 99 subscribers (up 0 in the last 3 months): 
- 7 emails sent to list (37 in previous quarter) 
   
 - xbean-...@geronimo.apache.org:  
- 33 subscribers (up 0 in the last 3 months): 
- 2 emails sent to list (20 in previous quarter) 
   
   
## JIRA activity: 
   
 - 6 JIRA tickets created in the last 3 months 
 - 2 JIRA tickets closed/resolved in the last 3 months 

[jira] [Commented] (XBEAN-278) Blueprint Namespace Handler improperly parsed flat-collections

[Alan Cabrera (JIRA)]

[ 
https://issues.apache.org/jira/browse/XBEAN-278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14347049#comment-14347049
 ] 

Alan Cabrera commented on XBEAN-278:


Dan, I saw the pull request.  I thought you had the karma to commit this 
yourself.  

 Blueprint Namespace Handler improperly parsed flat-collections
 --

 Key: XBEAN-278
 URL: https://issues.apache.org/jira/browse/XBEAN-278
 Project: XBean
  Issue Type: Bug
Affects Versions: 4.1
Reporter: Daniel Kulp

 When parsing a flat collections, the fist item is processed correctly 
 creating the MutableColectionMetadata and setting the childeMetadata to the 
 listMeta which is then added to the bean.
 For subsequent items, item is added to the list correctly.  However, the 
 childeMetadata remains null (which is likely proper).  However, at the end of 
 the 'if/else' chain in XBeanNamespaceHandler, if childMeta is null, it 
 creates another childMeta with the value of the element (likely an empty 
 string).   This causes beans to fail to be created.
 Patch coming soon.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: [ANNOUNCE] Welcome Hendrik Saly as new Apache Geronimo committer

[Alan Cabrera]

Congrats!!!

Sent from my iPhone

 On Oct 24, 2014, at 12:47 AM, Mark Struberg strub...@yahoo.de wrote:
 
 Hi!
 
 Due to his contributions to various spec APIs and other EE parts the Apache 
 Geronimo PMC invited Hendrik Saly to become an Apache Geronimo committer. 
 
 We are glad he accepted and would like to welcome him on board of this 
 project!
 
 Welcome Hendrik, and we hope you have fun!
 
 
 The Apache Geronimo PMC
 

Re: [VOTE] geronimo javamail 1.8.4

[Alan Cabrera]

Is your PGP key in https://svn.apache.org/repos/asf/geronimo/KEYS?  I can’t get 
the signatures to verify.


Regards,
Alan


On Jul 20, 2014, at 12:40 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:

 Hi guys
 
 I'd like to call a vote for geronimo javamail 1.8.4
 
 It mainly fixes a bug for pop3 protocol where INBOX was replaced by INPUT in 
 our code (https://issues.apache.org/jira/browse/GERONIMO-6523)
 
 Here is the staging repo: 
 https://repository.apache.org/content/repositories/orgapachegeronimo-1002/
 
 vote will be opened for 3 days or until 3 pmc votes are obtained as usually.
 
 
 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau

Re: [VOTE] geronimo javamail 1.8.4

[Alan Cabrera]

+1 - binding


Regards,
Alan

On Jul 20, 2014, at 12:40 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:

 Hi guys
 
 I'd like to call a vote for geronimo javamail 1.8.4
 
 It mainly fixes a bug for pop3 protocol where INBOX was replaced by INPUT in 
 our code (https://issues.apache.org/jira/browse/GERONIMO-6523)
 
 Here is the staging repo: 
 https://repository.apache.org/content/repositories/orgapachegeronimo-1002/
 
 vote will be opened for 3 days or until 3 pmc votes are obtained as usually.
 
 
 Romain Manni-Bucau
 Twitter: @rmannibucau
 Blog: http://rmannibucau.wordpress.com/
 LinkedIn: http://fr.linkedin.com/in/rmannibucau
 Github: https://github.com/rmannibucau

Re: Your project uses a possibly LGPL dependency: com.icegreen.greenmail:greenmail

[Alan Cabrera]

On Jul 12, 2014, at 12:54 PM, Hendrik Dev hendrikde...@gmail.com wrote:

 Hi,
 
 i am the author and IP holder of the javamail mock2 library which
 maybe can be used an as alternative for greenmail here.
 Its not exactly doing what greenmail is doing (mock2 is mocking
 javamail classes like Folder, Transport, Store and so on and does not
 emulate a mailserver on the protocol level) but normally this doesn't
 matter.
 I am also willing to donate the stuff to apache incubator if its
 considered to be worthy and useful.
 
 Library is here: https://github.com/salyh/javamail-mock2 (AL License)

Awesome!  If the library is published to maven.org, and I see that it is, then 
the only work ahead is to port our tests to it.   Would you be interested in 
helping?

I do notice that it's still in beta.  When do you anticipate a regular 
release?  I don't think that this would stop us from porting our tests but as a 
user of the project I'm just curious.

Finally, there's no need for you to go to through the Incubator for use to use 
your project in our tests.  However, there's no reason to for you to not go 
there if you think you could grow a nice healthy community around it.


Regards,
Alan

 
 Thanks
 Hendrik
 
 
 On Sat, Jul 12, 2014 at 9:36 PM, Steve Rowe sar...@gmail.com wrote:
 Hi, my name is Steve Rowe, and I'm a member of the Apache Lucene PMC.
 
 We recently discovered that the greenmail Java library, which declares its
 license as ASLv2 in its POM and elsewhere, has LGPL license headers in its
 source code files.  In response the Lucene project reverted a recent commit
 containing this depedency.
 
 I conducted a survey of current Apache releases and found that four Apache
 projects include source code that links to the greenmail library: Syncope,
 OODT, Oozie and Geronimo.  Additionally, Axis2 has a Maven POM that includes
 a greenmail dependency, though I couldn't find any current releases
 containing this dependency.  Details are posted on
 https://issues.apache.org/jira/browse/LEGAL-206; I would appreciate your
 project's involvement.
 
 An issue was filed with the greenmail project on Sourceforge earlier this
 year asking for clarification http://sourceforge.net/p/greenmail/bugs/8/,
 but there has been no response on that issue, or any other issue, for that
 matter - the project may be dead, as it has seen no activity for some time.
 
 Steve
 
 
 
 -- 
 Hendrik Saly (salyh, hendrikdev22)
 @hendrikdev22
 PGP: 0x22D7F6EC

Re: Board Report Time

[Alan Cabrera]

+1  Thanks!


Regards,
Alan

On Jan 8, 2014, at 10:50 AM, Kevan Miller kevan.mil...@gmail.com wrote:

 Looks good to me. Thanks Jarek!
 --kevan
 
 
 On Wed, Jan 8, 2014 at 7:50 AM, Jarek Gawor jga...@gmail.com wrote:
 Last chance to review / update the draft. I will publish it later today.
 
 Thanks,
 Jarek
 
 On Mon, Jan 6, 2014 at 11:22 AM, Jarek Gawor jga...@gmail.com wrote:
  Sorry, it's a bit late but I created a draft board report for January:
  https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2014-01+-+January
 
  If I missed something please let me know or go ahead and update the
  page directly.
 
  The report is due on the 8th (Wednesday).
 
  Jarek
 

Re: Board Report Time

[Alan Cabrera]

+1  Thanks!


Regards,
Alan

On Jan 8, 2014, at 10:50 AM, Kevan Miller kevan.mil...@gmail.com wrote:

 Looks good to me. Thanks Jarek!
 --kevan
 
 
 On Wed, Jan 8, 2014 at 7:50 AM, Jarek Gawor jga...@gmail.com wrote:
 Last chance to review / update the draft. I will publish it later today.
 
 Thanks,
 Jarek
 
 On Mon, Jan 6, 2014 at 11:22 AM, Jarek Gawor jga...@gmail.com wrote:
  Sorry, it's a bit late but I created a draft board report for January:
  https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2014-01+-+January
 
  If I missed something please let me know or go ahead and update the
  page directly.
 
  The report is due on the 8th (Wednesday).
 
  Jarek
 

Re: Board Report Time

[Alan Cabrera]

+1  Thanks!


Regards,
Alan

On Jan 8, 2014, at 10:50 AM, Kevan Miller kevan.mil...@gmail.com wrote:

 Looks good to me. Thanks Jarek!
 --kevan
 
 
 On Wed, Jan 8, 2014 at 7:50 AM, Jarek Gawor jga...@gmail.com wrote:
 Last chance to review / update the draft. I will publish it later today.
 
 Thanks,
 Jarek
 
 On Mon, Jan 6, 2014 at 11:22 AM, Jarek Gawor jga...@gmail.com wrote:
  Sorry, it's a bit late but I created a draft board report for January:
  https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2014-01+-+January
 
  If I missed something please let me know or go ahead and update the
  page directly.
 
  The report is due on the 8th (Wednesday).
 
  Jarek
 

Re: [VOTE] take2 - release xbean-3.14

[Alan Cabrera]

How are you guys able to get a clean rat:check?


Regards,
Alan

On May 30, 2013, at 12:03 AM, Mark Struberg strub...@yahoo.de wrote:

 
 Hi!
 
 I'd like to call a 2nd VOTE for releasing xbean-3.14.
 This time I fixed the missing license headers and activated RAT for each 
 build.
 
 
 The staging repo can be found here:
 https://repository.apache.org/content/repositories/orgapachegeronimo-038/
 
 The tag is https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.14/
 
 And here comes the source.zip:
 
 https://repository.apache.org/content/repositories/orgapachegeronimo-038/org/apache/xbean/xbean/3.14/xbean-3.14-source-release.zip
 
 sha1: 
 
 
 0362adbf3364a86c5fa91001a72152a2a3a83935
 
 The VOTE is open for 72h
 
 [+1] all fine, let's ship it
 [+0] meh don't care
 [-1] nope because it contains a ${blocker}
 
 
 LieGrue,
 strub
 

Re: [VOTE] Release Geronimo eclipse plugin 3.0.1 - second try

[Alan Cabrera]

How are you guys able to get a clean rat:check?


Regards,
Alan

On May 29, 2013, at 1:31 AM, Forrest Xia forres...@gmail.com wrote:

 Hi Devs,
 
 Second try to release GEP 3.0.1. It fixed the build problem on Mac OS.
 
 Please vote Geronimo eclipse plugin(GEP) 3.0.1 release. This is a release 
 along with Geronimo server runtime release 3.0.1. 
 
 For details, see 
 http://people.apache.org/builds/geronimo/eclipse/updates/PLUGIN_RELEASE-NOTES-3.0.1.txt
 
 The GEP code up for vote is:
 https://repository.apache.org/content/repositories/orgapachegeronimo-031/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0.1/geronimo-eclipse-plugin-3.0.1-source-release.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-031/org/apache/geronimo/devtools/geronimo-eclipse-plugin/3.0.1/geronimo-eclipse-plugin-3.0.1-source-release.zip
 
 To build this source code, you need to build maven-eclipsepde-plugin 1.2 
 first(Its vote is ongoing now):
 http://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/tags/maven-plugins-1.2/
 
 NOTE: Please use Maven 2.2.1 and Java 6 to build them.
 
 The GEP staging update site is:
 http://people.apache.org/builds/geronimo/eclipse/updates/
 
 The release staging site is:
 https://repository.apache.org/content/repositories/orgapachegeronimo-031
 
 The tag has created at:
 http://svn.apache.org/repos/asf/geronimo/devtools/eclipse-plugin/tags/geronimo-eclipse-plugin-3.0.1/
 
 Vote will be at most open for 72 hours.
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 
 -- 
 Thanks!
 
 Regards, Forrest

Re: enabled RAT checks during build

[Alan Cabrera]

On May 29, 2013, at 2:01 AM, Mark Struberg strub...@yahoo.de wrote:

 hi folks!
 
 I've enabled apache-rat in the whole xbean build. Which means the build is 
 now defunct due to a few missing licenses.
 Hope we gonna fix those soon…

Great idea!


Regards,
Alan

Re: enabled RAT checks during build

[Alan Cabrera]

My 2 cents, I prefer to have this turned on and feel that littering the source 
tree with patch files and the like is a poor practice; I've seen too many debug 
files accidentally checked in during my lifetime.

Just my 2 cents.


Regards,
Alan


On May 29, 2013, at 8:17 AM, Jarek Gawor jga...@gmail.com wrote:

 I don't know about others but my source tree is usually polluted with
 patch files and other files that I create during
 development/testing/debugging. With Rat enabled by default my build
 will fail (as it does currently after doing svn up on xbean). So I
 would prefer to either delay RAT until the deploy phase or just enable
 RAT on the buildbot setup for xbean.
 
 Jarek
 
 
 On Wed, May 29, 2013 at 5:01 AM, Mark Struberg strub...@yahoo.de wrote:
 hi folks!
 
 I've enabled apache-rat in the whole xbean build. Which means the build is 
 now defunct due to a few missing licenses.
 Hope we gonna fix those soon...
 
 LieGrue,
 strub

Re: [VOTE] Release Geronimo eclipse plugin 3.0.1

[Alan Cabrera]

On May 28, 2013, at 7:10 AM, Forrest Xia forres...@gmail.com wrote:

 GEP only build with maven 2.2.1
 

On Mac OS X 10.8.3:

[INFO] 
[ERROR] FATAL ERROR
[INFO] 
[INFO] An invalid artifact was detected.

This artifact might be in your project's POM, or it might have been included 
transitively during the resolution process. Here is the information we do have 
for this artifact:

o GroupID: org.eclipse.plugins
o ArtifactID:  org.eclipse.swt.cocoa.macosx
o Version:  MISSING 
o Type:jar

[INFO] 
[INFO] Trace
org.apache.maven.artifact.InvalidArtifactRTException: For artifact 
{org.eclipse.plugins:org.eclipse.swt.cocoa.macosx:null:jar}: The version cannot 
be empty.
at 
org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:147)
at 
org.apache.maven.artifact.DefaultArtifact.init(DefaultArtifact.java:122)
at 
org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:158)
at 
org.apache.maven.artifact.factory.DefaultArtifactFactory.createDependencyArtifact(DefaultArtifactFactory.java:70)
at 
org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:439)
at 
org.apache.maven.project.MavenProject.createArtifacts(MavenProject.java:1651)
at 
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1489)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:442)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
at 
org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO] 

Re: [DISCUSSION] How to compile GEP

[Alan Cabrera]

On May 28, 2013, at 8:14 AM, Kevan Miller kevan.mil...@gmail.com wrote:

 
 On May 28, 2013, at 11:05 AM, Forrest Xia forres...@gmail.com wrote:
 
 What's your configuration on Mac OS?
 
 Java version? In what module does the problem happen?
 
 I've tried both Java 6 and Java 7. 
 
 Java 6 fails with:
 
 snip/
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] An invalid artifact was detected.
 
 This artifact might be in your project's POM, or it might have been included 
 transitively during the resolution process. Here is the information we do 
 have for this artifact:
 
o GroupID: org.eclipse.plugins
o ArtifactID:  org.eclipse.swt.cocoa.macosx
o Version:  MISSING 
o Type:jar
 

I get the same error, Java 6.


Regards,
Alan

Re: [VOTE] Release Geronimo eclipse plugin 3.0.1

[Alan Cabrera]

Known issues of the tool we use to build should percolate up to the known 
issues in our release notes, imo.


Regards,
Alan

On May 28, 2013, at 8:38 AM, Forrest Xia forres...@gmail.com wrote:

 Some known issues there fyi.
  [Known issue]
  1. GEP 3.0.0 uses maven-eclipsepde-plugin v1.1, which means it can not be 
  built successfully on 64bit win7 and 64bit macos. See following JIRAs for 
  details.
  - https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-737 Could not 
  build GEP3.0 under win7-64bit
  - https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-674 Could not 
  build GEP3.0 under macos-64bit
  2. Also, please use maven v2.2.1 to build GEP 3.0.0 as following JIRA is 
  still open.
  - https://issues.apache.org/jira/browse/GERONIMODEVTOOLS-694 Can not build 
  GEP with maven 3.0
 
 
 On Tue, May 28, 2013 at 11:31 PM, Alan Cabrera l...@toolazydogs.com wrote:
 
 On May 28, 2013, at 7:10 AM, Forrest Xia forres...@gmail.com wrote:
 
 GEP only build with maven 2.2.1
 
 
 On Mac OS X 10.8.3:
 
 [INFO] 
 
 [ERROR] FATAL ERROR
 [INFO] 
 
 [INFO] An invalid artifact was detected.
 
 This artifact might be in your project's POM, or it might have been included 
 transitively during the resolution process. Here is the information we do 
 have for this artifact:
 
 o GroupID: org.eclipse.plugins
 o ArtifactID:  org.eclipse.swt.cocoa.macosx
 o Version:  MISSING 
 o Type:jar
 
 [INFO] 
 
 [INFO] Trace
 org.apache.maven.artifact.InvalidArtifactRTException: For artifact 
 {org.eclipse.plugins:org.eclipse.swt.cocoa.macosx:null:jar}: The version 
 cannot be empty.
   at 
 org.apache.maven.artifact.DefaultArtifact.validateIdentity(DefaultArtifact.java:147)
   at 
 org.apache.maven.artifact.DefaultArtifact.init(DefaultArtifact.java:122)
   at 
 org.apache.maven.artifact.factory.DefaultArtifactFactory.createArtifact(DefaultArtifactFactory.java:158)
   at 
 org.apache.maven.artifact.factory.DefaultArtifactFactory.createDependencyArtifact(DefaultArtifactFactory.java:70)
   at 
 org.apache.maven.project.artifact.MavenMetadataSource.createArtifacts(MavenMetadataSource.java:439)
   at 
 org.apache.maven.project.MavenProject.createArtifacts(MavenProject.java:1651)
   at 
 org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1489)
   at 
 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:442)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:694)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:556)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:535)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:387)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:348)
   at 
 org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:180)
   at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:328)
   at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:138)
   at org.apache.maven.cli.MavenCli.main(MavenCli.java:362)
   at 
 org.apache.maven.cli.compat.CompatibleMain.main(CompatibleMain.java:60)
   at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   at java.lang.reflect.Method.invoke(Method.java:597)
   at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
   at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
   at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
   at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
 [INFO] 
 
 
 
 
 
 -- 
 Thanks!
 
 Regards, Forrest

Re: [DISCUSS] Release Geronimo 3.0.1

[Alan Cabrera]

I get 

(linkedin)[acabrera-mn:geronimo-3.0.1 507]$ mvn clean install
[INFO] Scanning for projects...
[WARNING] The POM for 
org.apache.geronimo.buildsupport:car-maven-plugin:jar:3.0.1 is missing, no 
dependency information available
[ERROR] The build could not read 30 projects - [Help 1]
[ERROR]   
[ERROR]   The project 
org.apache.geronimo.modules:geronimo-clustering:3.0.1-SNAPSHOT 
(/Users/acabrera/geronimo-3.0.1/plugins/clustering/geronimo-clustering/pom.xml) 
has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact 
org.apache.geronimo.plugins:clustering:pom:3.0.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 25, column 13 - [Help 2]
[ERROR]   
[ERROR]   The project 
org.apache.geronimo.modules:geronimo-clustering-wadi:3.0.1-SNAPSHOT 
(/Users/acabrera/geronimo-3.0.1/plugins/clustering/geronimo-clustering-wadi/pom.xml)
 has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact 
org.apache.geronimo.plugins:clustering:pom:3.0.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 25, column 13 - [Help 2]
[ERROR]   
[ERROR]   The project org.apache.geronimo.modules:geronimo-farm:3.0.1-SNAPSHOT 
(/Users/acabrera/geronimo-3.0.1/plugins/clustering/geronimo-farm/pom.xml) has 1 
error
[ERROR] Non-resolvable parent POM: Could not find artifact 
org.apache.geronimo.plugins:clustering:pom:3.0.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 25, column 13 - [Help 2]
[ERROR]   
[ERROR]   The project 
org.apache.geronimo.modules:geronimo-deploy-farm:3.0.1-SNAPSHOT 
(/Users/acabrera/geronimo-3.0.1/plugins/clustering/geronimo-deploy-farm/pom.xml)
 has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact 
org.apache.geronimo.plugins:clustering:pom:3.0.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 25, column 13 - [Help 2]
[ERROR]   
[ERROR]   The project 
org.apache.geronimo.modules:geronimo-plugin-farm:3.0.1-SNAPSHOT 
(/Users/acabrera/geronimo-3.0.1/plugins/clustering/geronimo-plugin-farm/pom.xml)
 has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact 
org.apache.geronimo.plugins:clustering:pom:3.0.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 25, column 13 - [Help 2]
[ERROR]   
[ERROR]   The project org.apache.geronimo.configs:clustering:3.0.1-SNAPSHOT 
(/Users/acabrera/geronimo-3.0.1/plugins/clustering/clustering/pom.xml) has 1 
error
[ERROR] Non-resolvable parent POM: Could not find artifact 
org.apache.geronimo.plugins:clustering:pom:3.0.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 25, column 13 - [Help 2]
[ERROR]   
[ERROR]   The project 
org.apache.geronimo.configs:wadi-clustering:3.0.1-SNAPSHOT 
(/Users/acabrera/geronimo-3.0.1/plugins/clustering/wadi-clustering/pom.xml) has 
1 error
[ERROR] Non-resolvable parent POM: Could not find artifact 
org.apache.geronimo.plugins:clustering:pom:3.0.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 25, column 13 - [Help 2]
[ERROR]   
[ERROR]   The project org.apache.geronimo.configs:farming:3.0.1-SNAPSHOT 
(/Users/acabrera/geronimo-3.0.1/plugins/clustering/farming/pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact 
org.apache.geronimo.plugins:clustering:pom:3.0.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 25, column 13 - [Help 2]
[ERROR]   
[ERROR]   The project org.apache.geronimo.configs:plugin-farm:3.0.1-SNAPSHOT 
(/Users/acabrera/geronimo-3.0.1/plugins/clustering/plugin-farm/pom.xml) has 1 
error
[ERROR] Non-resolvable parent POM: Could not find artifact 
org.apache.geronimo.plugins:clustering:pom:3.0.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 25, column 13 - [Help 2]
[ERROR]   
[ERROR]   The project 
org.apache.geronimo.configs:plugin-farm-member:3.0.1-SNAPSHOT 
(/Users/acabrera/geronimo-3.0.1/plugins/clustering/plugin-farm-member/pom.xml) 
has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact 
org.apache.geronimo.plugins:clustering:pom:3.0.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 25, column 13 - [Help 2]
[ERROR]   
[ERROR]   The project 
org.apache.geronimo.assemblies:geronimo-plugin-farm-node:3.0.1-SNAPSHOT 
(/Users/acabrera/geronimo-3.0.1/plugins/clustering/geronimo-plugin-farm-node/pom.xml)
 has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact 
org.apache.geronimo.plugins:clustering:pom:3.0.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 22, column 13 - [Help 2]
[ERROR]   
[ERROR]   The project 
org.apache.geronimo.configs:plugin-farm-datasource:3.0.1-SNAPSHOT 
(/Users/acabrera/geronimo-3.0.1/plugins/clustering/plugin-farm-datasource/pom.xml)
 has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact 
org.apache.geronimo.plugins:clustering:pom:3.0.1-SNAPSHOT and 
'parent.relativePath' points at wrong local POM @ line 22, 

Re: [VOTE] Release Geronimo Tomcat fork 7.0.39.2 for a security fix

[Alan Cabrera]

+1


Regards,
Alan

On May 16, 2013, at 11:06 PM, Forrest Xia forres...@gmail.com wrote:

 Hi,
 
 Please revote for the Geronimo Tomcat fork 7.0.39.2 release, which merges a 
 tomcat security fix for CVE-2013-2071
 
 The components up for vote are:
 https://repository.apache.org/content/repositories/orgapachegeronimo-008/org/apache/geronimo/ext/tomcat/tomcat-parent-7.0.39/7.0.39.2/tomcat-parent-7.0.39-7.0.39.2-source-release.zip
 
 
 Staging repo is here:
 https://repository.apache.org/content/repositories/orgapachegeronimo-008
 
 tag is here:
 http://svn.apache.org/repos/asf/geronimo/external/tags/tomcat-parent-7.0.39.2
 
 
  Vote open 72 hours
 
  [ ] +1 release this
  [ ] 0 don't care
  [ ] -1 don't release this (please explain)
 
 -- 
 Thanks!
 
 Regards, Forrest

Re: [VOTE] Release Geronimo Tomcat 7.0.39.1

[Alan Cabrera]

I got

[ERROR] Failed to execute goal 
org.codehaus.mojo:rat-maven-plugin:1.0-alpha-3:check (default-cli) on project 
tomcat-parent-7.0.39: Too many unapproved licenses: 1 - [Help 1]

for a mvn rat: check.  Do we care?


Regards,
Alan

On May 9, 2013, at 9:15 AM, Forrest Xia forres...@gmail.com wrote:

 Hi,
 
 Please vote for the Geronimo Tomcat 7.0.39.1 release, which is based on 
 Tomcat 7.0.39 tag.
 
 The components up for vote are:
 https://repository.apache.org/content/repositories/orgapachegeronimo-026/org/apache/geronimo/ext/tomcat/tomcat-parent-7.0.39/7.0.39.1/tomcat-parent-7.0.39-7.0.39.1-source-release.zip
 
 
 Staging repo is here:
 https://repository.apache.org/content/repositories/orgapachegeronimo-026
 
 tag is here:
 https://svn.apache.org/repos/asf/geronimo/external/tags/tomcat-parent-7.0.39.1
 
 
  Vote open 72 hours
 
  [ ] +1 release this
  [ ] 0 don't care
  [ ] -1 don't release this (please explain)
 
 -- 
 Thanks!
 
 Regards, Forrest

[jira] [Closed] (GERONIMO-1587) Document versioning process

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera closed GERONIMO-1587.
--


 Document versioning process
 ---

 Key: GERONIMO-1587
 URL: https://issues.apache.org/jira/browse/GERONIMO-1587
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: specs
Reporter: Alan Cabrera
Assignee: Alan Cabrera

 Document versioning process.  Start w/ Specs

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Commented] (GERONIMO-1587) Document versioning process

[Alan Cabrera (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13652751#comment-13652751
 ] 

Alan Cabrera commented on GERONIMO-1587:


https://cwiki.apache.org/GMOxDEV/spec-versioning.html

 Document versioning process
 ---

 Key: GERONIMO-1587
 URL: https://issues.apache.org/jira/browse/GERONIMO-1587
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: specs
Reporter: Alan Cabrera
Assignee: Alan Cabrera

 Document versioning process.  Start w/ Specs

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Resolved] (GERONIMO-1587) Document versioning process

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-1587?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera resolved GERONIMO-1587.


Resolution: Fixed

 Document versioning process
 ---

 Key: GERONIMO-1587
 URL: https://issues.apache.org/jira/browse/GERONIMO-1587
 Project: Geronimo
  Issue Type: Task
  Security Level: public(Regular issues) 
  Components: specs
Reporter: Alan Cabrera
Assignee: Alan Cabrera

 Document versioning process.  Start w/ Specs

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Created: (GERONIMO-5645) JSR319 - Availability Management for Java

[Alan Cabrera (JIRA)]

JSR319 - Availability Management for Java
-

 Key: GERONIMO-5645
 URL: https://issues.apache.org/jira/browse/GERONIMO-5645
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: specs
Reporter: Alan Cabrera
Assignee: Alan Cabrera


Adding JSR319 - Availability Management for Java v1.0

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (YOKO-405) Cleanup the maven 2 POMs

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/YOKO-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera closed YOKO-405.
-

Resolution: Not A Problem

 Cleanup the maven 2 POMs
 

 Key: YOKO-405
 URL: https://issues.apache.org/jira/browse/YOKO-405
 Project: Yoko - CORBA Server
  Issue Type: Task
  Security Level: public(Regular issues) 
Reporter: Alan Cabrera
Assignee: Alan Cabrera
 Fix For: v1.0.0


 POMs can stand to be cleaned up a bit.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-4168) JSR319 - Availability Management for Java

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-4168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera closed GERONIMO-4168.
--

Resolution: Fixed

 JSR319 - Availability Management for Java
 -

 Key: GERONIMO-4168
 URL: https://issues.apache.org/jira/browse/GERONIMO-4168
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: specs
Reporter: Alan Cabrera
Assignee: Alan Cabrera

 Will place in v0.4 version of the spec.  Will update as the spec evolves.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

JSR319 - Availability Management for Java

[Alan Cabrera]

This looks pretty interesting to me.  I'm going to start goofing  
around with it even though the spec version is 0.4 and I never seem to  
have a lot of time on my hands.


Anyone else interested as well?


Regards,
Alan

[jira] Created: (GERONIMO-4168) JSR319 - Availability Management for Java

[Alan Cabrera (JIRA)]

JSR319 - Availability Management for Java
-

 Key: GERONIMO-4168
 URL: https://issues.apache.org/jira/browse/GERONIMO-4168
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public (Regular issues)
  Components: specs
Reporter: Alan Cabrera
Assignee: Alan Cabrera


Will place in v0.4 version of the spec.  Will update as the spec evolves.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Commented: (GERONIMO-3960) Make the spec jars OSGi friendly

[Alan Cabrera (JIRA)]

[ 
https://issues.apache.org/jira/browse/GERONIMO-3960?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12590045#action_12590045
 ] 

Alan Cabrera commented on GERONIMO-3960:


What about bundle updates?  I don't think that this code will handle those 
situations.

 Make the spec jars OSGi friendly
 

 Key: GERONIMO-3960
 URL: https://issues.apache.org/jira/browse/GERONIMO-3960
 Project: Geronimo
  Issue Type: New Feature
  Security Level: public(Regular issues) 
  Components: specs
Reporter: Guillaume Nodet
 Attachments: stax-osgi.diff




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: Entropy, or the heat death of the geronimo code base

[Alan Cabrera]

The sandbox/james is now quietly sleeping in my compost pile in my  
back yard.



Regards,
Alan

On Feb 28, 2008, at 3:07 PM, David Jencks wrote:

A few years ago I read about an information based perpetual motion  
machine someone came up with.  IIRC many people studied it for  
quite a while before realizing that the flaw was an assumption that  
erasing information was free.  It turned out to require the same  
energy as apparently extracted from the machine.


By applying this green svn energy saving principle we have an  
unparalleled opportunity to assure that future visitors to our svn  
repo will have no way of finding the live code.


OR...

we could clean up the leftovers from completed refactoring efforts  
and releases.


Here's the stuff I have located in a quick scan that I think has  
more recent versions elsewhere or is completely obsolete and can be  
removed, organized by last committer:


pmcmahan:

plugins/activemq
plugins/console
plugins/debugviews
plugins/jee-management
plugins/plancreator
plugins/pluto
plugins/system-database

djencks:
sandbox/servlet-2.5 (I'm not the last committer but did merge this  
into trunk) (I've removed this)

sandbox/geronimo-jaspi (I merged this into trunk, and removed it)

jdillon

sandbox/g1.1-activemq4
sandbox/repository (did this make it into the wiki?  I'm planning  
to propose using http://maven.apache.org/developers/release/ 
releasing.html as the basis for releasing g. stuff, is this relevant?)


dain:
sandbox/plugins/global-jndi (I'm pretty sure I've got this all into  
trunk)


prasad:
sandbox/restructure

kevan:
sandbox/xsds  Didn't these get moved somewhere more appropriate?

rick:
sandbox/mail  (You had nothing to do with this, but could you look  
and check if there is anything useful inside?)


alan:
sandbox/james (this appears to be a basically unmodified copy of  
james)


dblevins:
server/branches/jpa-plugin  (looks like a branch to play with jpa  
that never went anywhere)
specs/branches/jee5-spec (See GERONIMO-2358 Not sure why this  
didn't get removed or is my svn messed up?)


gnodet:
specs/branches/geronimo-servlet_2.5_spec-1.1.1
specs/branches/geronimo-stax-api_1.0_spec-1.0.1



Does anyone have any clue what this is:

sandbox/spring-assembly (last modified 2006)


--

If you know about one of these and think it should stay please  
reply.  If you know it should go you can remove it, tell me to  
remove it, or do nothing and I will in a few days.


thanks
david jencks

[jira] Created: (XBEAN-102) StaticRecipeTest fails

[Alan Cabrera (JIRA)]

StaticRecipeTest fails
--

 Key: XBEAN-102
 URL: https://issues.apache.org/jira/browse/XBEAN-102
 Project: XBean
  Issue Type: Bug
Affects Versions: 3.4
Reporter: Alan Cabrera


testAll(org.apache.xbean.recipe.StaticRecipeTest)  Time elapsed: 0.003 sec   
FAILURE!
junit.framework.AssertionFailedError: 3 arg constructor should never be called
at junit.framework.Assert.fail(Assert.java:47)
at org.apache.xbean.recipe.Person.init(Person.java:57)
at 
org.apache.xbean.recipe.StaticRecipeTest.testAll(StaticRecipeTest.java:32)
at 
org.apache.xbean.recipe.StaticRecipeTest.testAll(StaticRecipeTest.java:32)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)


-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (XBEAN-77) ClassFinder needs better error handling

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/XBEAN-77?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera updated XBEAN-77:
--

Fix Version/s: (was: 3.1)
   3.4

 ClassFinder needs better error handling
 ---

 Key: XBEAN-77
 URL: https://issues.apache.org/jira/browse/XBEAN-77
 Project: XBean
  Issue Type: Bug
Affects Versions: 3.0
Reporter: David Jencks
 Fix For: 3.4


 ClassFinder uses e.printStackTrace() as an error reporting mechanism.  This 
 needs to be fixed somehow.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Updated: (XBEAN-92) UrlSet excludePaths() method throws a nullpointer exception if the pathString argument is null

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/XBEAN-92?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera updated XBEAN-92:
--

Fix Version/s: 3.4

 UrlSet excludePaths() method throws a nullpointer exception if the pathString 
 argument is null
 --

 Key: XBEAN-92
 URL: https://issues.apache.org/jira/browse/XBEAN-92
 Project: XBean
  Issue Type: Bug
 Environment: IBM JDK 5
Reporter: karan singh malhi
Assignee: David Blevins
Priority: Blocker
 Fix For: 3.4


 With IBM JDK 5, when we try to get the system property java.endorsed.dirs, it 
 returns null.  This is a critical issue as it prevents OpenEjb from starting 
 In UrlSet, the following method will lead to a NullPointerException:
 public UrlSet excludeJavaEndorsedDirs() throws MalformedURLException {
 return excludePaths(System.getProperty(java.endorsed.dirs));
 }
 This is because the excludePaths() method assumes that the pathString 
 argument is always non-null.
public UrlSet excludePaths(String pathString) throws MalformedURLException 
 {
 String[] paths = pathString.split(File.pathSeparator);
 UrlSet urlSet = this;
 for (String path : paths) {
 File file = new File(path);
 urlSet = urlSet.exclude(file);
 }
 return urlSet;
 }

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Assigned: (GERONIMO-2336) JSR 196: JavaTM Authentication Service Provider Interface for Containers API

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera reassigned GERONIMO-2336:
--

Assignee: (was: Alan Cabrera)

 JSR 196: JavaTM Authentication Service Provider Interface for Containers API
 

 Key: GERONIMO-2336
 URL: https://issues.apache.org/jira/browse/GERONIMO-2336
 Project: Geronimo
  Issue Type: RTC
  Security Level: public(Regular issues) 
  Components: security
Reporter: Alan Cabrera

 JSR196 API in geronimo/specs/brances/jsr196
 (http://jcp.org/en/jsr/detail?id=196)

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Re: [VOTE] Release XBean 3.2

[Alan Cabrera]

Thanks Guillaume for following up on this tedious but important task.


Regards,
Alan

On Oct 5, 2007, at 11:55 AM, Guillaume Nodet wrote:


I have finally uploaded a new release condidate.
Please review.  I have only modified the root pom to make sure the
jars include the needed files.

On 10/5/07, Guillaume Nodet [EMAIL PROTECTED] wrote:

So Dan Kulp helped me debugging this problem.
It comes from a bug in 2.0.3 version of maven-source-plugin.
So i will lock it to 2.0.2 and it seems to work.
I will recut a release now

On 10/5/07, Guillaume Nodet [EMAIL PROTECTED] wrote:

I've tried different things and I can't find a way to include the
META-INF / NOTICE in the source jar.

And here's my system:

Guillaume-Nodets-MacPro:~/work/geronimo/xbean/tags/xbean-3.2 gnodet$
mvn -version
Maven version: 2.0.7
Java version: 1.5.0_07
OS name: mac os x version: 10.4.10 arch: i386


On 10/4/07, Kevan Miller [EMAIL PROTECTED] wrote:


On Oct 3, 2007, at 4:31 PM, Guillaume Nodet wrote:


Hmm, too easy I think.
The real jars already contain these resources in META-INF.
The problem is with the source jars that are generated by  
maven, not

the binary jars.
I suppose the javadocs jars have the same problems.


Hmm. When I build tags/xbean-3.2 (just running 'mvn', the sources
jars (e.g. xbean-3.2/xbean-osgi/target/xbean-osgi-3.2-sources.jar)
contain the NOTICE and LICENSE files.

This is on Mac OS X and Maven 2.0.7. What system/OS and what  
command

are you using to build?

--kevan







--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/




--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/




--
Cheers,
Guillaume Nodet

Blog: http://gnodet.blogspot.com/

Re: Slim spring?

[Alan Cabrera]

+1 spring-module approach, marking all the spring jars as provided.


Regards,
Alan

On Jul 19, 2007, at 7:28 PM, Dain Sundstrom wrote:

How does everyone feel about changing from the uber-spring jar (2M)  
to the spring module jars?  Here is a sizing chart:


spring-beans-2.0.5.jar379K
spring-context-2.0.5.jar  156K
  
  531K

spring-web-2.0.5.jar  148K  # optional for web context
spring-jmx-2.0.5.jar   85K  # optional xbean-server


With full spring at 2M this is a pretty big savings.  This will  
also help to keep the modules free of using other stuff from spring.


On the other hand, maven and uber jars don't always get along.  If  
anther project imports xbean-spring, they will either need to use  
the spring module jars, or exclude them transitively from the xbean- 
spring.  Alternatively, we could mark them as provided, and then  
the importing project will need to explicitly import spring in  
which ever form they like.


I'd prefer we go with the spring-module approach, but mark all the  
spring jars as provided.  This make it easier for users to upgrade  
to newer spring releases (no exclude/reinclude).


-dain

BTW, I did test this actually works :)

RE: [VOTE] Release XBean 3.0.1

[Alan Cabrera]

+1


Regards,
Alan


-Original Message-
From: Guillaume Nodet [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Sent: 5/25/2007 12:56 AM
Subject: [VOTE] Release XBean 3.0.1

I have tagged an XBean 3.0.1 version at
  http://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.0.1/

Compared to 3.0, the only change is a fix in the main pom where
the version property has been left to 3.0-SNAPSHOT, thus causing
unwanted references to snapshots poms.

Please review the tag and vote for this release.  Once the vote passes,
I will upload the release to the repository.

[ ] +1 Release XBean 3.0.1 based on the proposed tag
[ ] +/- 0
[ ] -1 Do not release

Here's my +1

-- 
Cheers,
Guillaume Nodet

Principal Engineer, IONA
Blog: http://gnodet.blogspot.com/

)

[jira] Assigned: (GERONIMO-3122) Unable to create a (MySQL) database pool

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-3122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera reassigned GERONIMO-3122:
--

Assignee: (was: Alan Cabrera)

Not sure if this was supposed to be assigned to me.

 Unable to create a (MySQL) database pool
 

 Key: GERONIMO-3122
 URL: https://issues.apache.org/jira/browse/GERONIMO-3122
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: databases
Affects Versions: 2.0-M3
 Environment: mysql/mysql-connector-java/3.1.12/jar 
 MySQL 5.0.27
 Win-Xp
 Java 1.6
Reporter: kalyan

 I tried to create new database pool using 
 1. Database Pool Wizard
 2. Importing from Jboss 4.
 That time I got the following exception.
  EXCEPTION WHILE CREATING 
 DATABASE POOL USING THE GERONIMO DATABASE POOL WIZARD  ///
 Geronimo Application Server started
 22:44:35,401 ERROR [DatabasePoolPortlet] Unable to save connection pool
 javax.enterprise.deploy.spi.exceptions.InvalidModuleException: No configurer 
 for module type: rar registered
 at 
 org.apache.geronimo.deployment.plugin.jmx.JMXDeploymentManager.createConfiguration(JMXDeploymentManager.java:302)
 at 
 org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.save(DatabasePoolPortlet.java:880)
 at 
 org.apache.geronimo.console.databasemanager.wizard.DatabasePoolPortlet.processAction(DatabasePoolPortlet.java:338)
 at 
 org.apache.pluto.core.PortletServlet.dispatch(PortletServlet.java:229)
 at 
 org.apache.pluto.core.PortletServlet.doPost(PortletServlet.java:163)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
 at 
 org.apache.pluto.core.PortletServlet.service(PortletServlet.java:153)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at 
 org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:687)
 at 
 org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:590)
 at 
 org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
 at 
 org.apache.pluto.invoker.impl.PortletInvokerImpl.invoke(PortletInvokerImpl.java:120)
 at 
 org.apache.pluto.invoker.impl.PortletInvokerImpl.action(PortletInvokerImpl.java:68)
 at 
 org.apache.pluto.PortletContainerImpl.processPortletAction(PortletContainerImpl.java:164)
 at 
 org.apache.pluto.portalImpl.core.PortletContainerWrapperImpl.processPortletAction(PortletContainerWrapperImpl.java:82)
 at org.apache.pluto.portalImpl.Servlet.doGet(Servlet.java:227)
 at org.apache.pluto.portalImpl.Servlet.doPost(Servlet.java:267)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:713)
 at javax.servlet.http.HttpServlet.service(HttpServlet.java:806)
 at 
 org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
 at 
 org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
 at 
 org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:228)
 at 
 org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
 at 
 org.apache.geronimo.tomcat.valve.DefaultSubjectValve.invoke(DefaultSubjectValve.java:56)
 at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:525)
 at 
 org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:338)
 at 
 org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:47)
 at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
 at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
 at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
 at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:517)
 at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:212)
 at 
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
 at 
 org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:634)
 at 
 org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:445)
 at java.lang.Thread.run(Thread.java:619

[jira] Created: (GERONIMO-2782) Test

[Alan Cabrera (JIRA)]

Test


 Key: GERONIMO-2782
 URL: https://issues.apache.org/jira/browse/GERONIMO-2782
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
Reporter: Alan Cabrera
 Assigned To: Alan Cabrera




-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Closed: (GERONIMO-2782) Test

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2782?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera closed GERONIMO-2782.
--

Resolution: Fixed

 Test
 

 Key: GERONIMO-2782
 URL: https://issues.apache.org/jira/browse/GERONIMO-2782
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Reporter: Alan Cabrera
 Assigned To: Alan Cabrera



-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

[jira] Resolved: (GERONIMO-2692) Current specs/trunk fails to build, due to missing modules

[Alan Cabrera (JIRA)]

 [ 
https://issues.apache.org/jira/browse/GERONIMO-2692?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Alan Cabrera resolved GERONIMO-2692.


Resolution: Fixed

Thanks Donald!

 Current specs/trunk fails to build, due to missing modules
 --

 Key: GERONIMO-2692
 URL: https://issues.apache.org/jira/browse/GERONIMO-2692
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: specs
Affects Versions: 2.0-M2
Reporter: Donald Woods
 Fix For: 2.0-M2

 Attachments: G2692-specs-2.0.patch


 The current geronimo/specs/trunk fails to build, because several specs were 
 released and moved out of /trunk, but were not removed from the modules list 
 to build in the main pom.xml.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
https://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [ANNOUNCE] Please welcome Christopher M. Cardona as our newest Committer

[Alan Cabrera]

Congrats Chris!Regards,AlanOn Oct 18, 2006, at 4:26 AM, Gianny Damour wrote:Hi,The Geronimo PMC is pleased to announce that Christopher M. Cardona has recently accepted our invitation to become an Apache Geronimo Committer. Over the past few months, Chris has been working on the improvement of the Server Console and has demonstrated initiatives and a noteworthy ability to work with others.Congratulations and Welcome Christopher!  --Apache Geronimo - http://geronimo.apache.orgApache Yoko - http://incubator.apache.org/yokoLiveTribe - http://www.livetribe.org 

[ANNOUNCE] Please welcome Vamsavardhana Reddy as one of our newest Committer

[Alan Cabrera]

The Geronimo PMC is pleased to announce that Vamsavardhana Reddy has recently accepted our invitation to become an Apache Geronimo Committer.  Vamsi has been submitting many great patches for an embarrassing long time.  The breadth of his patches is remarkable but we are excited by the possibility of him working on security.Congratulations and welcome Vamsi!Regards,Alan--Apache Geronimo - http://geronimo.apache.orgApache Yoko - http://incubator.apache.org/yokoLiveTribe - http://www.livetribe.org 

Re: [VOTE] Release XBean 2.7

[Alan Cabrera]

+1

Regards,
Alan


On Oct 16, 2006, at 10:32 AM, Guillaume Nodet wrote:


As proposed in the earlier discussion, I start
a vote about releasing xbean-2.7 from the
current svn head.  This will enable to use
maven release plugin to directly upload the
release to the maven repository.

[ ] +1 release xbean 2.7 from current snapshot
[ ] 0
[ ] -1 do not release xbean

Here's my +1

--
Cheers,
Guillaume Nodet

[jira] Closed: (GERONIMO-1432) DirectConfigurationEntry should not wrap principals

[Alan Cabrera (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1432?page=all ]

Alan Cabrera closed GERONIMO-1432.
--

Resolution: Fixed

 DirectConfigurationEntry should not wrap principals
 ---

 Key: GERONIMO-1432
 URL: http://issues.apache.org/jira/browse/GERONIMO-1432
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Affects Versions: 1.0
Reporter: Alan Cabrera
 Assigned To: Alan Cabrera
 Fix For: 1.2


 DirectConfigurationEntry should not wrap principals.  It's meant as a simple 
 login.config equivalent when Geornimo security is installed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: [Discussion] Are we done merging from branch/dead-1.2?

[Alan Cabrera]

On Sep 11, 2006, at 10:23 AM, Dain Sundstrom wrote:

Alan, Aaron, Hiram, Matt, Jan, Jeff, Jacek, John, James, Jules and  
Kevin,


You all have commits documented in the https://svn.apache.org/repos/ 
asf/geronimo/server/trunk/all_changes.log file as not merged from  
dead-1.2 into trunk.  Please take a moment either let us know which  
commits need to be merged, or edit the file to note the commits  
that don't need a merge.


A summary of your commits follow:


adc
r367046 3 lines PR: GERONIMO-1432 Removed wrapPrincipals attribute.


Merged.


Regards,
Alan

[jira] Closed: (GERONIMO-2279) FileKeyStoreInstance: Does not save keyPasswords after removing an entry

[Alan Cabrera (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-2279?page=all ]

Alan Cabrera closed GERONIMO-2279.
--

Fix Version/s: (was: 1.1.2)
   Resolution: Fixed

Thanks!

 FileKeyStoreInstance: Does not save keyPasswords after removing an entry
 

 Key: GERONIMO-2279
 URL: http://issues.apache.org/jira/browse/GERONIMO-2279
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 1.1
Reporter: Vamsavardhana Reddy
 Assigned To: Alan Cabrera
Priority: Minor
 Fix For: 1.2

 Attachments: GERONIMO-2279.patch


 keyPasswords are not saved after the password of deleted entry is removed 
 from the HashMap.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMO-2266) FileAuditLoginModule: Does not log failed attempts

[Alan Cabrera (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-2266?page=all ]

Alan Cabrera closed GERONIMO-2266.
--

Resolution: Duplicate

GERONIMO-2294

 FileAuditLoginModule: Does not log failed attempts
 --

 Key: GERONIMO-2266
 URL: http://issues.apache.org/jira/browse/GERONIMO-2266
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: security
Affects Versions: 1.0
 Environment: WinXP, G 1.1.1-SNAPSHOT
Reporter: Vamsavardhana Reddy
 Assigned To: Alan Cabrera
 Fix For: 1.1.2, 1.2


 I have created an audit enabled security realm.  I notice that only 
 successful login attempts are logged to the file.  Failed attempts are never 
 logged!!!

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Reopened: (GERONIMO-1432) DirectConfigurationEntry should not wrap principals

[Alan Cabrera (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-1432?page=all ]

Alan Cabrera reopened GERONIMO-1432:


Fix Version/s: 1.2
   (was: 1.x)
 

 DirectConfigurationEntry should not wrap principals
 ---

 Key: GERONIMO-1432
 URL: http://issues.apache.org/jira/browse/GERONIMO-1432
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Affects Versions: 1.0
Reporter: Alan Cabrera
 Assigned To: Alan Cabrera
 Fix For: 1.2


 DirectConfigurationEntry should not wrap principals.  It's meant as a simple 
 login.config equivalent when Geornimo security is installed.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Closed: (GERONIMO-2368) Unable to create a (MySQL) database pool

[Alan Cabrera (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-2368?page=all ]

Alan Cabrera closed GERONIMO-2368.
--

Resolution: Fixed

 Unable to create a (MySQL) database pool
 

 Key: GERONIMO-2368
 URL: http://issues.apache.org/jira/browse/GERONIMO-2368
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: databases
Affects Versions: 1.1.1
 Environment: Fedora Core 5
 MySQL 5.0.22
Reporter: Jay D. McHugh
 Assigned To: Alan Cabrera

 I tried to install the MySQL JDBC driver (installation worked) and define my 
 datasource.
 Trying to create the datasource using the wizard locked up the browser and 
 resulted in the following log file (I tried twice - that is why the error 
 appears two times):
 Copying into repository 
 mysql-connector-java-3.1.13/mysql-connector-java-3.1.13/bin/jar... Finished.
 08:41:52,551 ERROR [CoyoteAdapter] An exception or error occurred in the 
 container during the request processing
 java.lang.IllegalArgumentException: Qualifier patterns must be present when 
 first URLPattern is an exact pattern
at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98)
at 
 javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:47)
at 
 org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermission(TomcatGeronimoRealm.java:200)
at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
at 
 org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342)
at 
 org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at 
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at 
 org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
at 
 org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at 
 org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:534)
 08:42:50,280 ERROR [CoyoteAdapter] An exception or error occurred in the 
 container during the request processing
 java.lang.IllegalArgumentException: Qualifier patterns must be present when 
 first URLPattern is an exact pattern
at javax.security.jacc.URLPatternSpec.init(URLPatternSpec.java:98)
at 
 javax.security.jacc.WebResourcePermission.init(WebResourcePermission.java:47)
at 
 org.apache.geronimo.tomcat.realm.TomcatGeronimoRealm.hasResourcePermission(TomcatGeronimoRealm.java:200)
at 
 org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:506)
at 
 org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:342)
at 
 org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:31)
at 
 org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at 
 org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at 
 org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at 
 org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:541)
at 
 org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at 
 org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at 
 org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:667)
at 
 org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at 
 org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:80)
at 
 org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:684)
at java.lang.Thread.run(Thread.java:534)
 I was only able to get through the first page of the wizard before it locked 
 up.  Here are the values that I entered:
 Name of Database Pool:   plc
 Database Type:  MySQL
 I also tried deploying from the command line using

Re: [VOTE] Geronimo Development Process

[Alan Cabrera]

[X] +1 CTR with documentation guidelines


Regards,
Alan

[jira] Updated: (GERONIMO-2354) Replace concurrent with backport-concurrent-util

[Alan Cabrera (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-2354?page=all ]

Alan Cabrera updated GERONIMO-2354:
---

Attachment: (was: GERONIMO-2354.diff)

 Replace concurrent with backport-concurrent-util
 

 Key: GERONIMO-2354
 URL: http://issues.apache.org/jira/browse/GERONIMO-2354
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Affects Versions: 1.2
Reporter: Jason Dillon
 Attachments: GERONIMO-2354-openejb2.diff, GERONIMO-2354.diff


 Replace usage of concurrent classes with backport-concurrent-util.  
 Preparation for using java.util.concurrent in JDK 1.5, and reduce the need 
 for 2 sets of concurrent classes on the boot classloader.
 Sill need to include concurrent, as activeio and openejb still have some 
 dependencies upon it... but this brings us a step closer to not needing both.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] Updated: (GERONIMO-2354) Replace concurrent with backport-concurrent-util

[Alan Cabrera (JIRA)]

 [ http://issues.apache.org/jira/browse/GERONIMO-2354?page=all ]

Alan Cabrera updated GERONIMO-2354:
---

Attachment: (was: GERONIMO-2354-openejb2.diff)

 Replace concurrent with backport-concurrent-util
 

 Key: GERONIMO-2354
 URL: http://issues.apache.org/jira/browse/GERONIMO-2354
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
Affects Versions: 1.2
Reporter: Jason Dillon
 Attachments: GERONIMO-2354-openejb2.diff, GERONIMO-2354.diff


 Replace usage of concurrent classes with backport-concurrent-util.  
 Preparation for using java.util.concurrent in JDK 1.5, and reduce the need 
 for 2 sets of concurrent classes on the boot classloader.
 Sill need to include concurrent, as activeio and openejb still have some 
 dependencies upon it... but this brings us a step closer to not needing both.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira