Re: are we d'accord to retire the Geronimo Server part?

[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: site cleanup

[Kevan Miller]

?

http://geronimo.apache.org/ is maintained by confluence. There's an edit
icon in the upper right corner.

kevan

On Tue, Apr 25, 2017 at 12:20 AM, Mark Struberg  wrote:

> Hi folks!
>
> Can someone point me to more docs about how the G site is maintained?
> Would love to reorg it a bit and add info about GeronimoConfig.
>
> txs and LieGrue,
> strub
>

Re: Discuss: Move Geronimo to Attic

[Kevan Miller]

I'll be leaving.

On Fri, Mar 24, 2017 at 4:21 PM, Romain Manni-Bucau <rmannibu...@gmail.com>
wrote:

> +1
>
> Le 25 mars 2017 00:17, "David Jencks" <david.a.jen...@gmail.com> a écrit :
>
>> I like this approach.  Thank you for making a concrete suggestion and
>> taking the lead. I intend to stay on the PMC and at least occasionally help
>> out.
>>
>> david jencks
>>
>> > 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

Re: Discuss: Move Geronimo to Attic

[Kevan Miller]

"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  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 :
> >
> > 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 
> 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 |  Blog | Old Blog | Github | LinkedIn | JavaEE Factory
> >>
> >> 2017-03-09 17:01 GMT+01:00 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 

Re: Discuss: Move Geronimo to Attic

[Kevan Miller]

Thanks Alan! Many thanks for all you've done!

I think we all agree that it is time to retire the Geronimo Server portions
of the project.

My apologies to Romain, Mark, David, and others, but:

I think the entire project should be retired. I confess that I am not
closely following the dev list (I scan it from time to time for a general
sense of what's happening).

I don't see sufficient community behind the remaining sub-projects. If the
Geronimo project didn't exist, I seriously doubt that there would be calls
to form a new Geronimo EE Commons project. In my view, Geronimo is a
convenient code repository for some people interested in releasing code.
Thus, I think the entire project should be moved to the Attic. If there are
parts of the project that should live on, then let them be incorporated
into projects that will provide them the community they deserve.

And now the olive branch...

If there is sufficient community, then that community should be able to
develop a new project description (
https://projects.apache.org/project.html?geronimo) and report to the board.
Note that this change of the project's charter, may require approval by the
Board. And I expect there may be some reluctance to create a new
Commons-style project at the ASF. If we're (you're) able to accomplish
this, then you have my full support.

kevan

On Wed, Mar 8, 2017 at 1:34 AM, Romain Manni-Bucau 
wrote:

> I share that vision (the one of Mark).
>
> The ee-commons part is really used and still active (even if in
> maintenance mode for several parts) and we need to ensure other projects
> can still rely on it (karaf, tomee, owb, meecrowave, openjpa, ... plus
> several open source ones).
>
> EE is also not dead, likely no more trendy since server side techno is no
> more a challenge but still a real need.
>
> Geronimo AppService not being really developped or maintained anymore I
> can see it being frozen (attic or not is a detail IMO) but other parts are
> still a very good fit for Geronimo community IMO.
>
>
> Romain Manni-Bucau
> @rmannibucau  |  Blog
>  | Old Blog
>  | Github
>  | LinkedIn
>  | JavaEE Factory
> 
>
> 2017-03-08 10:26 GMT+01:00 Mark Struberg :
>
>> I see no lack of interest in Java EE to be honest. Of course
>> Microservices are currently spilled high on the hype cycle, but that will
>> quickly blow up imo.
>> MS architecture is only very good for a certain kind of application. For
>> most business apps the granularity is way too fine grain and the missing TX
>> handling is often a showstopper (even if Managers don't see this yet).
>>
>> You are certainly right that there is a lack of interest in the *huge*
>> big-iron app servers!
>> So yes, TomEE, Meecrowave etc fill the sweet spot which is interesting
>> for 85% of apps.
>>
>> I also do not have a problem with the missing TCK. Of course it would be
>> better to have one. But the only real progress is currently in CDI and BVal
>> and those TCKs are available under ALv2 even.
>>
>> The main problem imo is that the Geronimo server part is not actively
>> maintained anymore and OSGi is not a really good fit for JavaEE anyway. Not
>> that OSGi itself is bad, but it's not a good fit.
>> Don't get me wrong, the Geronimo AppServer was a big step 14 years ago,
>> and all the people involved in this effort back then layed a rock solid
>> fundament for all that came after that. But the architecture is still quite
>> outdated imo and it didn't get maintained for way too long.
>>
>>
>> Otoh there is really a lot of good technology available inside the
>> geronimo project.
>>
>> * geronimo-jta
>> * javamail
>> * xbean (including finder, scanner etc)
>> * the specs
>> and quite a few other nice parts 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 :
>> >
>> > 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 

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

[Kevan Miller]

Thanks Eduardo!

If there are people interested in working on updating the Geronimo server,
I'm sure the community would happily support these efforts. So, if you or
anyone else are interested, please speak up!

Also, if there are people interested in supporting the currently released
version(s) of the Geronimo, server, I think the community would be
supportive of these efforts, also.

Unfortunately, there has not been much interest from the current community
for either of these efforts. I confess that I'm not planning on providing
support for the existing codebase or working on a new version of the
Geronimo server.

Mark,
Your plan seems reasonable to me. Unless we plan on supporting the current
version of the server (fixing bugs and security exposures) and/or
developing a new updated server, I think we must move the server subproject
to the Attic.

I do not plan on participating in the community for either commons or
server development. Once the future plans for the Geronimo Server have been
finalized, I will plan on resigning from the PMC.

kevan

On Tue, Dec 20, 2016 at 7:21 AM, Eduardo Garcia 
wrote:

> It would be desirable to have an official new version, with full
> compatibility with new Java JDK's (this helps promoting people on using
> it), also updating official web page, and Eclipse Plugin.
>
> I had to put the front-end of a project into a TomEE due web-responsive
> JSF requirements, but still using Geronimo as the core (back-end), by
> using microservices (Restlet/Jackson).  Geronimo really rocks, but I
> think it is time to get a renew version compatible with new key libraries.
>
> I really like Geronimo AppServer and hope it continue growing.  In my
> case, I started using geronimo because it was really easy for me
> learning it with the Eclipse Tools available at that time (IBM OSGi
> Tools).  Right now I have to use WAS or Liberty Tools with Eclipse Luna.
>
> My wish list for Geronimo:
> - Updated OSGi framework
> - Been able to install Camel
> - Updated MyFaces compatibility and fix some non-critical bugs
> - Compatibility with new JDK
> - Updated Eclipse Plugin
> -  Try to deliver a new release once a year
>
> hope next year could join you guys in making some of this happen.
>
>
>
> On 12/16/2016 12:54 PM, Mark Struberg wrote:
> > Parts which I found to be actively maintained and very useful
> >
> > * specs
> > * xbean
> > * javamail
> > * transactionmanager
> > * flava (needed for specs)
> >
> > I'm sure there are others which are not on my radar,...
> >
> > LieGrue,
> > strub
> >
> >> Am 15.12.2016 um 21:41 schrieb David Jencks :
> >>
> >> I agree.  Which components specifically are you thinking of?
> >>
> >> david jencks
> >>
> >>> On Dec 15, 2016, at 1:57 AM, Mark Struberg  wrote:
> >>>
> >>> Hi folks!
> >>>
> >>> There have been some thoughts about resurrecting activity on the
> Geronimo AppServer.
> >>> So imo the first step is to find a spot which makes sense. Software
> doesn't get built just for fun.
> >>> Of course if no fun is involved then a project is doomed as well.
> >>> But otoh if it doesn't get used then the quality suffers a lot and the
> fun is gone as well.
> >>>
> >>> So we have a few Java App Servers (just at the ASF), sorted from
> fastest/smallest to full EE
> >>>
> >>> * Mina as Socket Server
> >>> * Tomcat as native Servlet Container
> >>> * Brand new: OpenWebBeans Meecrowave as Microprofile server
> (Tomcat9+OWB+Johnzon+CXF+log4j2). In a whooping 9MB all in one CLI fatjar
> btw ;)
> >>> * TomEE WebProfile (EE6 and EE7)
> >>> * TomEE Full (EE6 and EE7)
> >>> * Geronimo (EE6, OSGi)
> >>>
> >>> + httpd of course (but not Java)
> >>>
> >>> To be honest I've not seen the Geronimo AppServer in production since
> quite a few years. Otoh the components maintained over here are of great
> quality and also an important puzzle part of many other projects. In my
> eyes Geronio could re-focus on becomming kind of EE-comons of the ASF.
> >>>
> >>> What do others think?
> >>>
> >>> LieGrue,
> >>> strub
> >>>
> >>>
> >
>
>

Re: Javamail 1.4 Version 1.9.0 proposal

[Kevan Miller]

On Tue, Nov 11, 2014 at 1:16 PM, Hendrik Dev hendrikde...@gmail.com wrote:

 But despite of that the feature discussion is the important one. Have
 not looked yet on greenmail 1.4 but i would like to use a real
 mailserver to test the javamail impl. and james seems to be the
 perfect candidate:
 its an apache project, its (mostly) rfc compliant, its suitable for
 unittesting and possibly synergy effects if the project use each
 other.


All sounds good.



 The big problem of geronimo javamail (impl, not spec) is the (almost
 complete) absence of unittests. Writing these should not be limited by
 a fake implementation like greenmail especially for testing IMAP
 (which is itself a mess already :-)


Yes. Afraid most of the testing has been from the TCK. More unit tests
would be fantastic!

--kevan

Re: Javamail 1.4 Version 1.9.0 proposal

[Kevan Miller]

Hi Hendrik.

On Tue, Nov 11, 2014 at 11:27 AM, Hendrik Dev hendrikde...@gmail.com
wrote:

 Hi Kevan,

 thanks, wil try to split commits.

 About greenmail replacement:
 Two reasons, mainly because greenmail does not support advanced imap
 features (like IDLE) and does not support some basics like Pop3 APOP and
 AUTH=PLAIN (both are buggy in the current geronimo javamail version) and a
 lot more. Other reason is the unclear license situation for greenmail.


Thanks for the info. I have no problems with a switch to James. I just want
to see the change discussed. This helps others understand, both now and,
more importantly, in the future.

It's my understanding that there is a new greenmail release. I haven't
looked at it, but my understanding is that it should clear up the licensing
questions. Again, not arguing for or against. Just making sure facts are
laid out...

--kevan

Re: Javamail 1.4 Version 1.9.0 proposal

[Kevan Miller]

Thanks Hendrik!

That's a lot of changes to digest. I'm not sure how you intend to commit
them, but if it's possible/feasible, please commit in functional pieces.
Not all at once...

Some explanation/background of the greenmail - James replacement would be
appreciated...

--kevan

On Sat, Nov 8, 2014 at 4:10 PM, Hendrik Dev hendrikde...@gmail.com wrote:

 I did some work on Javamail 1.4  and want to discuss the changes
 before commit them:

 - Replaced greenmail with apache james
 - Added new testcases, more to come ...
 - Fixed APOP authentication for POP3
 - Starttls is now also working for POP3
 - Some love for pom's
 - Fixed issues:

 Support for properties mail.protocol.socketFactory and
 mail.protocol.ssl.socketFactory
 https://issues.apache.org/jira/browse/GERONIMO-5429

 Support for property starttls.require
 https://issues.apache.org/jira/browse/GERONIMO-5430

 starttls.required is not supported by JavaMail
 https://issues.apache.org/jira/browse/GERONIMO-5873


 You can review the proposed changes here:

 https://github.com/salyh/geronimo-javamail/commit/7bac5b296025a9de098428e88756c5b06ae44b2e

 or get the diff here:

 https://raw.githubusercontent.com/salyh/geronimo-javamail/7bac5b296025a9de098428e88756c5b06ae44b2e/svn.diff

 Site is here:
 http://people.apache.org/~salyh/geronimo-javamail_1.4/1.9.0-SNAPSHOT/

 Thanks for your comments or feedback
 Hendrik

 --
 Hendrik Saly (salyh, hendrikdev22)
 @hendrikdev22
 PGP: 0x22D7F6EC

Re: Jira permissions

[Kevan Miller]

You should be all set. I also gave Mark and Romain jira admin privileges.

On Tue, Oct 28, 2014 at 1:49 AM, Hendrik Dev hendrikde...@gmail.com wrote:

 Can someone with the right karma grant me some more jira permissions
 so that i can assign issues and close issues?

 Javamail gets some love from me ... :-)

 Jira id is salyh

 Thanks
 Hendrik

 --
 Hendrik Saly (salyh, hendrikdev22)
 @hendrikdev22
 PGP: 0x22D7F6EC

Re: Board report time

[Kevan Miller]

Looks good. Thanks Jarek.

--kevan

On Sat, Oct 11, 2014 at 5:23 AM, Jarek Gawor jga...@gmail.com wrote:

 Hi all,

 This is a bit late but I created a draft board report for October:


 https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2014-10+-+October

 If I missed something please let me know or go ahead and update the
 page directly.

 Thanks,
 Jarek

Re: [VOTE] release Geronimo Genesis 2.2

[Kevan Miller]

+1

signature, hashes, license/notice, build, RAT all look good to me.

Thanks Mark!

--kevan

On Thu, Sep 11, 2014 at 12:13 AM, Mark Struberg strub...@yahoo.de wrote:

 Hi!

 genesis is our parents project collector for all geronimo projects.
 The main changes for 2.2 have been the automatic enablement of the
 apache-rat plugin (Apache Creadur) and version updates of many other maven
 plugins. I also fixed quite a few missing versions for some maven plugins.

 I updated all geronimo-spec projects to use 2.2-SNAPSHOT as a test and
 they all build fine.

 The staging repo can be found here:

 https://repository.apache.org/content/repositories/orgapachegeronimo-1005/

 The source release:


 http://repository.apache.org/content/repositories/orgapachegeronimo-1005/org/apache/geronimo/genesis/genesis/2.2/genesis-2.2-source-release.zip

 My key can be found at

 https://svn.apache.org/repos/asf/geronimo/KEYS



 please VOTE
 [+1] all fine, ship it
 [+0] meh, don't care
 [-1] stop, because ${reason}



 The VOTE is open for 72h.

 here is my +1

 txs and LieGrue,
 strub

Re: KEYS file, where's the official location?

[Kevan Miller]

IIRC, there used to be more KEYS files... ;-)

dist/geronimo/KEYS is the official location for release signing keys
(should be the case for all . For tracking purposes (maybe?) we've also had
a copy in svn -- geronimo/KEYS. The two files should be kept in sync. I
don't really recall the exact reason why we have two... And getting out of
sync, is not good...

--kevan


On Sat, Aug 23, 2014 at 11:28 AM, Alan D. Cabrera l...@toolazydogs.com
wrote:

 We seem to have two locations for our KEYS file,
 http://svn.apache.org/repos/asf/geronimo/KEYS and
 http://www.apache.org/dist/geronimo/KEYS.

 Which one is the official one?


 Regards,
 Alan

Re: [VOTE] geronimo javamail 1.8.4

[Kevan Miller]

On Mon, Jul 21, 2014 at 12:16 PM, Alan Cabrera l...@toolazydogs.com wrote:

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


Thanks Alan! I failed to note that I didn't have gpg on the machine I
validated the release on... Need to get that fixed...

Re: [VOTE] geronimo javamail 1.8.4

[Kevan Miller]

I'm voting on the release archive:
http://repository.apache.org/content/repositories/orgapachegeronimo-1002/org/apache/geronimo/javamail/geronimo-javamail_1.4/1.8.4/geronimo-javamail_1.4-1.8.4-source-release.tar.gz

The release archive should be identified as part of the vote.

I have the following test errors:
  testMessages(org.apache.geronimo.javamail.store.pop3.POP3StoreTest)
  testMessages(org.apache.geronimo.javamail.store.imap.IMAPStoreTest)

Which seems to be caused by local DNS problems. I assume it is passing for
others.

Everything else looks good: license/notice, build, checksums

+1

--kevan



On Sun, 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

[Kevan Miller]

Thanks Steve. For clarity:

This message announces a license switch for Greenmail --
http://sourceforge.net/p/greenmail/mailman/message/58953/
However, some/most/all of the src license headers are still labeled as
LGPL. There would also be general questions about the license switch --
were all necessary copyrights properly held to make this license switch?
And subsequent to the switch were all changes/contributions made under ALv2?

Depending on the outcome of these questions, you may or may not want to
treat the greenmail dependency as LGPL. Assuming it is held to be LGPL,
then a question of how the dependency is used? Bundling an LGPL dependency
is bad. Direct source linkage to LGPL, likewise. Simple build / test maven
dependency would be OK from an ASF perspective...


On Sat, Jul 12, 2014 at 12: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

Re: Board report time

[Kevan Miller]

Looks good to me. Thanks Jarek.

--kevan


On Tue, Jul 8, 2014 at 7:15 AM, Jarek Gawor jga...@gmail.com wrote:

 Hi all,

 Sorry, it's a bit late but I created a draft board report for July:

 https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2014-07+-+July

 If I missed something please let me know or go ahead and update the
 page directly.

 The report is due on the 9th (Wednesday).

 Thanks,
 Jarek

Re: Board Report Time

[Kevan Miller]

Looks good to me. Thanks Jarek.

--kevan


On Mon, Apr 7, 2014 at 10:18 AM, Jarek Gawor jga...@gmail.com wrote:

 Hi all,

 I created a draft board report for April:

 https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2014-04+-+April

 If I missed something please let me know or go ahead and update the
 page directly.

 The report is due on the 9th (Wednesday).

 Thanks,
 Jarek

Re: Board Report Time

[Kevan Miller]

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

[Kevan Miller]

Thanks Jarek. Looks good to me.

--kevan


On Fri, Oct 4, 2013 at 11:13 AM, Jarek Gawor jga...@gmail.com wrote:

 I created a draft board report for October:

 https://cwiki.apache.org/confluence/display/GMOxPMGT/Apache+Geronimo+Board+Report+-+2013-10+-+October

 If I missed something please let me know of update the page.

 The report is due on the 9th (Wednesday).

 Jarek

Re: [CONF] Apache Geronimo v2.0 - JA Jalan Tikus.com Download Game PC dan Android Gratis Terbaru dengan Server Lokal

[Kevan Miller]

Thanks Jay!

--kevan

On Sep 27, 2013, at 12:08 PM, Jay D. McHugh (Confluence) 
conflue...@apache.org wrote:

...
 Page removed by Jay D. McHugh
 
 
 
 

[jira] [Commented] (XBEAN-245) JarFile object left open in XBean finder

[Kevan Miller (JIRA)]

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

Kevan Miller commented on XBEAN-245:


The Patch Available status was set by Anonymous User. I don't see any 
recent code activity that would indicate the problem was newly fixed. And 
Patch Available is really intended to show that a patch has been posted to a 
Jira (not in SVN). 

I haven't been following developments closely, but I doubt that there is a 
patch...

 JarFile object left open in XBean finder 
 -

 Key: XBEAN-245
 URL: https://issues.apache.org/jira/browse/XBEAN-245
 Project: XBean
  Issue Type: Bug
  Components: finder
Affects Versions: 3.10, 3.12
Reporter: Lazar Kirchev
 Attachments: test.zip


 In the constructor of org.apache.xbean.finder.archive.JarArchive. In its 
 constructor a JarFile object is created (on line 53) and this jar never gets 
 closed. 
 To reproduce the problem use the attached zip. It contains a test bundle - 
 JarArchiveTest, the Eclipse project for it and a jar file, used by the test. 
 The only thing that the test bundle does is to call 
 ClasspathArchive.archive(ClassLoader, URL) in its Activator.start() method.
 Steps to reproduce:
 1. install and start JarArchiveTest_1.0.0.jar in an OSGi environment (it 
 should contain at the minimum org.apache.xbean.finder.shaded and its 
 dependencies - org.apache.xbean.asm.shaded, org.apache.xbean.bundleutils and 
 org.slf4j.api); the dummy.jar should be in the working folder - the test 
 bundle searches it as ./dummy.jar.
 2. try to delete dummy.jar - it should not be possible
 3. stop JarArchiveTest_1.0.0.jar and try to delete dummy.jar - it should not 
 be possible
 4. uninstall JarArchiveTest_1.0.0.jar and try to delete dummy.jar - it should 
 not be possible
  

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

[ANNOUNCE] Jarek Gawor has been appointed as the the PMC Chair of the Geronimo Project

[Kevan Miller]

All,
Due to recent changes in my life, I've had less and less time to devote to the 
Geronimo project. Last month, I told the PMC that I wished to step down from my 
PMC Chair duties. 

The Geronimo PMC unanimously nominated Jarek Gawor to become the PMC Chair. I'm 
happy to announce that at this month's board meeting, the ASF Board appointed 
Jarek the new PMC Chair of the Geronimo project. 

As anyone following the Geronimo project should know, Jarek has been bringing a 
tremendous amount to the project in multiple ways. Please take a moment to 
thank Jarek for taking on this new role.

Finally, to all the PMC members, committers, contributors, and users -- thanks 
for making my job as PMC chair so easy and enjoyable. It's been a pleasure 
working with you. 

--kevan

Re: Would like to contribute

[Kevan Miller]

On Jun 7, 2013, at 3:04 PM, Andrew McCright and...@us.ibm.com wrote:

 Hi All, 
 
 I would like to contribute some code - specifically some Java EE 7 API code.  
 The JIRA web tool does not give me an option to assign an issue to me.  Do I 
 need to be in some sort of contributor list?  If so, can someone please add 
 me? 

Cool! Thanks Andy! What's your JIRA id?

--kevan

Re: Would like to contribute

[Kevan Miller]

On Jun 7, 2013, at 3:16 PM, Deepal Jayasinghe dee...@opensource.lk wrote:

 A JIRA cannot be assigned to you unless you are a developer (committer), but 
 you should be able to contribute to the issue such as submit patches etc…

Not quite. There is a JIRA category of 'contributor'. We allow JIRA's to be 
assigned to Geronimo contributors. You are correct that anyone can submit 
patches.

--kevan

Re: [VOTE] [RESULT] take2 - release xbean-3.14

[Kevan Miller]

On Jun 2, 2013, at 6:03 AM, Mark Struberg strub...@yahoo.de wrote:

 Time to close the VOTE
 
 
 The VOTE has passed with the following:
 
 +1: Forrest Xia, Romain Manni-Bucau, Kevan Miller, Jarek Gawor
 +0: none
 -1: none
 
 
 I'll go on and propagate the artifacts.
 Kevan, can you please again take over the task of cleaning up JIRA and do the 
 'official' stuff like the ANN mail?

Anybody else able to help Mark with this? Or better yet, Mark do you not have 
karma to do the JIRA cleanup? We can get that fixed...

As release manager, better for you to send the announce email…

--kevan

Re: [VOTE PASS] Geronimo devtools maven-eclipsepde-plugin 1.2 release

[Kevan Miller]

Forrest, by my count this vote was open just a bit more than 24 hours. The norm 
is a minimum of 72 hours. There are times when expedited release votes can be 
used, but not without discussion.

I notice that there is not an actual source archive that is buildable. The 
references sources jar only contains java sources. Anyone else bothered by 
this? The ASF norm is to vote on source archives prepared by the release 
manager. I assume everyone else is voting on the svn tag? 

--kevan
 
On May 30, 2013, at 7:51 AM, Forrest Xia forres...@gmail.com wrote:

 +1 vote: Forrest, Jarek, Janet, Shawn, Ivan.
 
 No -1 and +0.
 
 
 On Thu, May 30, 2013 at 3:40 PM, Ivan xhh...@gmail.com wrote:
 +1
 
 
 2013/5/30 Shawn Jiang genspr...@gmail.com
 +1
 
 
 On Wed, May 29, 2013 at 2:46 PM, Forrest Xia forres...@gmail.com wrote:
 Hi all,
 
 To make Geronimo eclipse plugin compiled on Mac OS, we need to release a new 
 maven-eclipsepde-plugin 1.2.
 
 Here are artifacts for vote:
 Source code:
 https://repository.apache.org/content/repositories/orgapachegeronimo-030/org/apache/geronimo/devtools/maven-eclipsepde-plugin/1.2/maven-eclipsepde-plugin-1.2-sources.jar
 
 svn tag:
 http://svn.apache.org/repos/asf/geronimo/devtools/maven-plugins/tags/maven-plugins-1.2/
 
 NOTE: please build it with maven 2.2.1 and Java 6.
 
 Vote will be at most open for 72 hours.
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 
 
 -- 
 Thanks!
 
 Regards, Forrest
 
 
 
 -- 
 Shawn
 
 
 
 -- 
 Ivan
 
 
 
 -- 
 Thanks!
 
 Regards, Forrest

Re: [VOTE] take2 - release xbean-3.14

[Kevan Miller]

There's one minor problem, that I see. 

The source archive contains a DEPENDENCIES file that causes the RAT check to 
fail. After removing the file, I'm able to build. This file is not present in 
the svn tag.

Everything else looks good: signature/checksum, license/notice, source, RAT. 
I'm ok with or without fixing this DEPENDENCIES issue (as long as it's fixed 
for future releases). 

So, here's my +1 for release.

--kevan

On May 30, 2013, at 3: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

[Kevan Miller]

Here's my +1

Signature/checksum, license/notice, RAT, and build all look good.

On Mac OS, I built as follows:

$ PATH=/usr/local/apache-maven-2.2.1/bin:$PATH  
M2_HOME=/usr/local/apache-maven-2.2.1/ 
JAVA_HOME=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home 
mvn clean install

--kevan

On May 29, 2013, at 4: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: [VOTE] Release Geronimo eclipse plugin 3.0.1

[Kevan Miller]

How are you building? I'm getting the following errors. Maybe a Mac OS issue?

[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 14.681s
[INFO] Finished at: Tue May 28 09:26:29 EDT 2013
[INFO] Final Memory: 20M/83M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) 
on project org.apache.geronimo.runtime.common: Compilation failure: Compilation 
failure:
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[21,31]
 package org.eclipse.core.runtime does not exist
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[22,31]
 package org.eclipse.core.runtime does not exist
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[23,31]
 package org.eclipse.core.runtime does not exist
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[24,25]
 package org.osgi.framework does not exist
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[26,28]
 cannot find symbol
[ERROR] symbol: class Plugin
[ERROR] public class Logger extends Plugin{
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[27,16]
 cannot find symbol
[ERROR] symbol  : class ILog
[ERROR] location: class org.apache.geronimo.runtime.common.log.Logger
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[44,19]
 cannot find symbol
[ERROR] symbol  : class BundleContext
[ERROR] location: class org.apache.geronimo.runtime.common.log.Logger
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[52,18]
 cannot find symbol
[ERROR] symbol  : class BundleContext
[ERROR] location: class org.apache.geronimo.runtime.common.log.Logger
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[33,9]
 cannot find symbol
[ERROR] symbol  : variable super
[ERROR] location: class org.apache.geronimo.runtime.common.log.Logger
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[30,1]
 method does not override or implement a method from a supertype
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[39,2]
 cannot find symbol
[ERROR] symbol  : variable super
[ERROR] location: class org.apache.geronimo.runtime.common.log.Logger
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[36,1]
 method does not override or implement a method from a supertype
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[46,2]
 cannot find symbol
[ERROR] symbol  : variable super
[ERROR] location: class org.apache.geronimo.runtime.common.log.Logger
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[47,28]
 cannot find symbol
[ERROR] symbol  : method getLog()
[ERROR] location: class org.apache.geronimo.runtime.common.log.Logger
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-eclipse-plugin-3.0.1/plugins/org.apache.geronimo.runtime.common/src/main/java/org/apache/geronimo/runtime/common/log/Logger.java:[43,1]
 method does not override or implement a method from a supertype
[ERROR] 
[ERROR] 

Re: [VOTE] Release Geronimo eclipse plugin 3.0.1

[Kevan Miller]

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

 GEP only build with maven 2.2.1

If so, can we put a BUILDING or README with build instructions? Won't require 
it for this release, but would be good to have clear instructions. 

I'm still having a build error:

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


--kevan

Re: [DISCUSSION] How to compile GEP

[Kevan Miller]

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:

[INFO] 
[INFO] Building org.apache.geronimo.st.ui
[INFO]task-segment: [clean, install]
[INFO] 
[INFO] [clean:clean {execution: default-clean}]
[INFO] [eclipsepde:manifestbundles {execution: initialize}]
[INFO] [eclipsepde:install {execution: initialize}]
[INFO] org.eclipse.jface.text : 3.7.1-r371_v20110825-0800 already exists in 
local repository.
[INFO] org.eclipse.core.runtime : 3.7.0-v20110110 already exists in local 
repository.
[INFO] org.eclipse.jdt.debug.ui : 3.6.1-v20110803_r371 already exists in local 
repository.
[INFO] org.eclipse.ui.views : 3.6.0-I20110412-0800 already exists in local 
repository.
[INFO] org.eclipse.core.filebuffers : 3.5.200-v20110505-0800 already exists in 
local repository.
[INFO] org.eclipse.equinox.common : 3.6.0-v20110523 already exists in local 
repository.
[INFO] org.eclipse.wst.common.core : 1.2.0-v200908252030 already exists in 
local repository.
[INFO] org.eclipse.core.commands : 3.6.0-I20110111-0800 already exists in local 
repository.
[INFO] org.eclipse.wst.sse.ui : 1.3.1-v201108191312 already exists in local 
repository.
[INFO] org.eclipse.ui.forms : 3.5.100-v20110425 already exists in local 
repository.
[INFO] org.eclipse.ui.ide : 3.7.0-v20110809-1737 already exists in local 
repository.
[INFO] org.eclipse.ui.workbench.texteditor : 3.7.0-v20110505-0800 already 
exists in local repository.
[INFO] org.eclipse.core.contenttype : 3.4.100-v20110423-0524 already exists in 
local repository.
[INFO] org.eclipse.jface : 3.7.0-I20110522-1430 already exists in local 
repository.
[INFO] org.eclipse.wst.xml.ui : 1.1.201-v201108151912 already exists in local 
repository.
[INFO] org.eclipse.wst.common.project.facet.core : 1.4.200-v201103170332 
already exists in local repository.
[INFO] org.eclipse.core.resources : 3.7.100-v20110510-0712 already exists in 
local repository.
[INFO] org.eclipse.equinox.preferences : 3.4.1-R37x_v20110725 already exists in 
local repository.
[INFO] org.eclipse.ltk.core.refactoring : 3.5.201-r371_v20110824-0800 already 
exists in local repository.
[INFO] org.eclipse.jst.j2ee.web : 1.1.501-v201108231500 already exists in local 
repository.
[INFO] org.eclipse.jst.server.core : 1.2.202-v20110419 already exists in local 
repository.
[INFO] org.eclipse.debug.core : 3.7.0-v20110518 already exists in local 
repository.
[INFO] org.eclipse.jst.j2ee : 1.1.501-v201108231845 already exists in local 
repository.
[INFO] org.eclipse.debug.ui : 3.7.101-v20110817_r371 already exists in local 
repository.
[INFO] org.eclipse.wst.common.frameworks : 1.2.101-v201107192200 already exists 
in local repository.
[INFO] org.eclipse.equinox.registry : 3.5.101-R37x_v20110810-1611 already 
exists in local repository.
[INFO] org.eclipse.wst.server.ui : 1.1.306-v20110823_1704 already exists in 
local repository.
[INFO] SWTFragment:  Dependency {groupId=org.eclipse.plugins, 
artifactId=org.eclipse.swt.cocoa.macosx, version=null, type=jar}
[ERROR] Bundle for dependency not found: org.eclipse.swt.cocoa.macosx
[INFO] org.eclipse.swt : 3.7.1-v3738a already exists in local repository.
[INFO] org.eclipse.osgi : 3.7.1-R37x_v20110808-1106 already exists in local 
repository.
[INFO] org.eclipse.ui.editors : 3.7.0-v20110517-0800 already exists in local 
repository.
[INFO] org.eclipse.ui : 3.7.0-I20110602-0100 already exists in local repository.
[INFO] org.eclipse.wst.common.modulecore : 1.2.101-v201108231700 already exists 
in local repository.
[INFO] org.eclipse.ui.workbench : 3.7.0-I20110519-0100 already exists in local 
repository.
[INFO] org.eclipse.core.jobs : 3.5.100-v20110404 already exists in local 
repository.
[INFO] org.eclipse.jdt.launching : 3.6.1-v20110803_r371 already exists in local 
repository.
[INFO] org.eclipse.jdt.core : 3.7.1-v_B76_R37x already exists in local 
repository.
[INFO] org.eclipse.text : 3.5.101-r371_v20110810-0800 already exists in local 
repository.
[INFO] org.eclipse.equinox.app : 1.3.100-v20110321 already exists in local 
repository.
[INFO] org.eclipse.wst.server.core : 1.1.303-v20110816_1717 already exists in 
local repository.
[INFO] org.eclipse.wst.common.project.facet.ui : 1.4.200-v201103311536 already 
exists in local repository.
[INFO] org.eclipse.jem.util : 2.1.100-v201103021400 already exists in local 
repository.
[INFO] [build-helper:parse-version {execution: parse-version}]
[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 

Re: [DISCUSSION] How to compile GEP

[Kevan Miller]

On May 28, 2013, at 11:21 AM, Shawn Jiang genspr...@gmail.com wrote:

 Kevan,
 
 Are you using Mac 64bit ?

Yes.

--kevan

Re: [Vote] Geronimo Eclipse Plugin (GEP) 3.0.0 RC1

[Kevan Miller]

On Jul 17, 2012, at 2:25 AM, Yi Xiao xiaoyijhondeve...@gmail.com wrote:

 Hi Jarek,
 
 You are right.
  I use mvn release:prepare -Pallsubproject and mvn release:perform 
 -Pallsubproject but there is no allsubproject profile...
 
 Thank you for pointing it out.
 I will re-release it.

If we cannot build GEP on Mac OS and we must build using Mavan 2.2.1, can we 
please add a BUILDING or README that documents these requirements/restrictions? 

I have not built (or tested GEP), but license/notice, source, rat, etc all look 
good to me. I should be able to vote for the release once the SNAPSHOT issues 
are resolved.

--kevan

Re: [Vote] Geronimo Eclipse Plugin (GEP) 3.0.0 RC1

[Kevan Miller]

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

 what you mean I should be able to vote for the release once the SNAPSHOT 
 issues are resolved.??


On Jul 17, 2012, at 2:25 AM, Yi Xiao xiaoyijhondeve...@gmail.com wrote:

 Hi Jarek,
 
 You are right.
  I use mvn release:prepare -Pallsubproject and mvn release:perform 
 -Pallsubproject but there is no allsubproject profile...
 
 Thank you for pointing it out.
 I will re-release it.
 
 On Mon, Jul 16, 2012 at 11:23 PM, Jarek Gawor jga...@gmail.com wrote:
 John,
 
 Looks like the testsuite pom files still use SNAPSHOT versions.

--kevan

Re: [Vote] Geronimo Eclipse Plugin (GEP) 3.0.0 RC1

[Kevan Miller]

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

 what you mean I should be able to vote for the release once the SNAPSHOT 
 issues are resolved.??

Oops. Sorry for all the noise I generated. You can ignore… I was searching mail 
history and accidentally thought this was the current vote thread…

--kevan

Re: [DISCUSSION] How to compile GEP

[Kevan Miller]

On May 28, 2013, at 11:48 AM, Jarek Gawor jga...@gmail.com wrote:

 Alan, Kevan, can you try changing the maven-eclipsepde-plugin version
 dependency to 1.2-SNAPSHOT and see if the code at least compiles now?

Hi Jarek,
Using Java 6, Maven 2.2.1 and 1.2-SNAPSHOT of the maven-eclipsepde-plugin 
allows me to build on Mac OS.

--kevan

Re: [VOTE] release xbean-3.14

[Kevan Miller]

Hi Mark,
I'm seeing a few problems. Looks like I may have missed them in the last 
release. Anyway, I think they need to be fixed. My bad for not seeing sooner...

Missing an Apache source license header: 

xbean-finder/src/test/java/org/apache/xbean/finder/ClassAnnotationFinderTest.java
xbean-finder/src/test/java/org/acme/ClassAnnotatedClass.java
xbean-finder/src/test/java/org/acme/NotAnnotated.java (not absolutely 
necessary, but would be good to see the Copyright (c) 2011 David Blevins 
removed. will need his permission or for him to do that)

Everything else is looking pretty good. License/Notice, and build looks good. 
So, looks like I'd be +1, if the above were resolved.

--kevan

On May 28, 2013, at 1:33 PM, Mark Struberg strub...@yahoo.de wrote:

 
 
 Hi!
 
 I'd like to call a VOTE for releasing xbean-3.14
 
 The staging repo can be found here:
 https://repository.apache.org/content/repositories/orgapachegeronimo-014/
 
 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-014/org/apache/xbean/xbean/3.14/xbean-3.14-source-release.zip
 
 sha1: 
 
 a3dffcaf6672db1543e46b0e7ffa0acf84cdf929
 
 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 3.0.1 - third try

[Kevan Miller]

+1

signature/checksum, license/notice, rat, build, and simple testing all look 
good. Thanks Forrest!

--kevan

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

 This is the third time to vote for Geronimo 3.0.1 release. Thanks Jarek to 
 help on fixing Geronimo-6034.
 
 For Geronimo 3.0.1 release, there are these major changes:
 1. JSF 2.1 support
 2. JDBC 4 support
 3. Some components upgrade, including Tomcat, JPA, Yoko, Tranql, ActiveMQ
 4. Quite a few bugs fixes
 
 For details, see 
 http://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-3.0.1/RELEASE_NOTES-3.0.1.txt
 
 The server code up for vote is:
 https://repository.apache.org/content/repositories/orgapachegeronimo-034/org/apache/geronimo/geronimo/3.0.1/geronimo-3.0.1-source-release.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-034/org/apache/geronimo/geronimo/3.0.1/geronimo-3.0.1-source-release.zip
 
 The binary code up for vote is:
 Java EE 6 Full Profile Tomcat Assemblies:
 https://repository.apache.org/content/repositories/orgapachegeronimo-034/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6/3.0.1/geronimo-tomcat7-javaee6-3.0.1-bin.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-034/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6/3.0.1/geronimo-tomcat7-javaee6-3.0.1-bin.zip
 
 Java EE 6 Web Profile Tomcat Assemblies:
 https://repository.apache.org/content/repositories/orgapachegeronimo-034/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6-web/3.0.1/geronimo-tomcat7-javaee6-web-3.0.1-bin.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-034/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6-web/3.0.1/geronimo-tomcat7-javaee6-web-3.0.1-bin.zip
 
 Little-G Tomcat Assemblies:
 https://repository.apache.org/content/repositories/orgapachegeronimo-034/org/apache/geronimo/assemblies/geronimo-tomcat7-minimal/3.0.1/geronimo-tomcat7-minimal-3.0.1-bin.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-034/org/apache/geronimo/assemblies/geronimo-tomcat7-minimal/3.0.1/geronimo-tomcat7-minimal-3.0.1-bin.zip
 
 Staging repo is:
 https://repository.apache.org/content/repositories/orgapachegeronimo-034/
 
 The tag has created at:
 http://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-3.0.1
 
 Java EE 6 TCKs all passed!
 
 Vote will be at least open for 72 hours.
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 
 -- 
 Thanks!
 
 Regards, Forrest

[DISCUSS] Release Geronimo 3.0.1

[Kevan Miller]

I've been trying off and on to get a clean build since Friday. I'm currently 
failing with:

[ERROR] Failed to execute goal on project geronimo-clustering-wadi: Could not 
resolve dependencies for project 
org.apache.geronimo.modules:geronimo-clustering-wadi:bundle:3.0.1-SNAPSHOT: 
Could not find artifact 
org.apache.geronimo.ext.tomcat:tribes:jar:7.0.39.1-SNAPSHOT in apache.snapshots 
(http://repository.apache.org/snapshots) - [Help 1]

I can try to clean out my maven repo. See if that helps. However:

looks like a lot of pom.xml files have parent's pointing to 3.0.1-SNAPSHOT. 
Try running 'grep -Rni --include=pom.xml snapshot *' 

--kevan

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

 Hi Devs,
 
 Please vote Geronimo 3.0.1 release with these major differences from the 
 previous release:
 1. JSF 2.1 support
 2. JDBC 4 support
 3. Some components upgrade, including Tomcat, JPA, Yoko, Tranql, ActiveMQ
 4. Quite a few bugs fixes
 
 For details, see 
 http://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-3.0.1/RELEASE_NOTES-3.0.1.txt
 
 The server code up for vote is:
 https://repository.apache.org/content/repositories/orgapachegeronimo-009/org/apache/geronimo/geronimo/3.0.1/geronimo-3.0.1-source-release.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-009/org/apache/geronimo/geronimo/3.0.1/geronimo-3.0.1-source-release.zip
 
 The binary code up for vote is:
 Java EE 6 Full Profile Tomcat Assemblies:
 https://repository.apache.org/content/repositories/orgapachegeronimo-009/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6/3.0.1/geronimo-tomcat7-javaee6-3.0.1-bin.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-009/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6/3.0.1/geronimo-tomcat7-javaee6-3.0.1-bin.zip
 
 Java EE 6 Web Profile Tomcat Assemblies:
 https://repository.apache.org/content/repositories/orgapachegeronimo-009/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6-web/3.0.1/geronimo-tomcat7-javaee6-web-3.0.1-bin.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-009/org/apache/geronimo/assemblies/geronimo-tomcat7-javaee6-web/3.0.1/geronimo-tomcat7-javaee6-web-3.0.1-bin.zip
 
 Little-G Tomcat Assemblies:
 https://repository.apache.org/content/repositories/orgapachegeronimo-009/org/apache/geronimo/assemblies/geronimo-tomcat7-minimal/3.0.1/geronimo-tomcat7-minimal-3.0.1-bin.tar.gz
 https://repository.apache.org/content/repositories/orgapachegeronimo-009/org/apache/geronimo/assemblies/geronimo-tomcat7-minimal/3.0.1/geronimo-tomcat7-minimal-3.0.1-bin.zip
 
 Staging repo is:
 https://repository.apache.org/content/repositories/orgapachegeronimo-009/
 
 The tag has created at:
 http://svn.apache.org/repos/asf/geronimo/server/tags/geronimo-3.0.1
 
 Java EE 6 TCKs all passed!
 
 Vote will be at least open for 72 hours.
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 
 -- 
 Thanks!
 
 Regards, Forrest

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

[Kevan Miller]

All looks good to me. Source, license/notice, rat, build…

Thanks Forrest!

--kevan
On May 17, 2013, at 2:06 AM, 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: Time for a new Geronimo 3 release?

[Kevan Miller]

On May 16, 2013, at 10:22 AM, Jarek Gawor jga...@gmail.com wrote:

 I'm ok with trying 7.0.40. If it takes more then a week to resolve any
 potential regressions we can always switch back to 7.0.39 quickly.
 Alternatively, we can also port back specific fixes from 7.0.40 to our
 7.0.39.

I'm fine with either approach. If a patched 7.0.39 is simpler, then do that…

--kevan

[jira] [Commented] (GERONIMO-6451) API jar for JSR 338 - JPA 2.1

[Kevan Miller (JIRA)]

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

Kevan Miller commented on GERONIMO-6451:


Hi Pinaki,
I assume that you've created the source in geronimo-jpa_2.1_spec-1.0-src.jar? 

Is there a reason why this source is not built from our 2.0 source (i.e. 
https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-jpa_2.0_spec). 

BTW, we'd be happy to svn copy geronimo-jpa_2.0_spec to geronimo-jpa_2.1_spec...

 API jar for JSR 338 - JPA 2.1
 -

 Key: GERONIMO-6451
 URL: https://issues.apache.org/jira/browse/GERONIMO-6451
 Project: Geronimo
  Issue Type: Sub-task
  Security Level: public(Regular issues) 
Reporter: Kevin Sutter
 Attachments: geronimo-jpa_2.1_spec-1.0.jar, 
 geronimo-jpa_2.1_spec-1.0.jar, geronimo-jpa_2.1_spec-1.0-src.jar


 Updated JPA 2.1 jar for Java EE 7.

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

Re: Time for a new Geronimo 3 release?

[Kevan Miller]

On May 12, 2013, at 10:29 PM, Forrest Xia forres...@gmail.com wrote:

 Tomcat fork 7.0.39.1 is out, shall we start release of 3.0.1? Anything more 
 to add, please comment it on, or I will start the release process around May 
 16.

Unless I'm mistaken, looks like we'll need to move up to 7.0.40.

--kevan

Re: [VOTE] Release Geronimo Tomcat fork 7.0.39.1

[Kevan Miller]

+1

Source, license/notice, RAT, and build all look good to me.

--kevan

On May 9, 2013, at 10:41 PM, Forrest Xia forres...@gmail.com wrote:

 Hi,
 
 Please revote 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-029/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-029
 
 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

Re: [VOTE] Release Geronimo Tomcat 7.0.39.1

[Kevan Miller]

On May 9, 2013, at 1:17 PM, Alan Cabrera l...@toolazydogs.com wrote:

 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?

Depending on the file(s), we care…

Here are the files that I see that are flagged by RAT:

 !? ./DEPENDENCIES
 !? ./HowTo.txt
  N ./LICENSE
  N ./NOTICE
   ./jasper-el/src/main/java/org/apache/el/parser/ELParser.java
   ./jasper-el/src/main/java/org/apache/el/parser/ELParserConstants.java
   ./jasper-el/src/main/java/org/apache/el/parser/ELParserTokenManager.java
   ./jasper-el/src/main/java/org/apache/el/parser/ELParserTreeConstants.java
   ./jasper-el/src/main/java/org/apache/el/parser/JJTELParserState.java
   ./jasper-el/src/main/java/org/apache/el/parser/Node.java
   ./jasper-el/src/main/java/org/apache/el/parser/ParseException.java
   ./jasper-el/src/main/java/org/apache/el/parser/SimpleCharStream.java
   ./jasper-el/src/main/java/org/apache/el/parser/Token.java
   ./jasper-el/src/main/java/org/apache/el/parser/TokenMgrError.java

The jasper-el files are all machine generated. Here's a sample header:

/* Generated By:JavaCC: Do not edit this line. TokenMgrError.java Version 5.0 */
/* JavaCCOptions: */
package org.apache.el.parser;

So, these look fine to me. LICENSE/NOTICE/DEPENDENCIES are not an issue. 

HowTo.txt should have a src license header. Once that's fixed I should be +1...

--kevan

Re: Time for a new Geronimo 3 release?

[Kevan Miller]

On May 8, 2013, at 3:00 PM, Jarek Gawor jga...@gmail.com wrote:

 Hi all,
 
 I think it's probably a good time to have a new Geronimo 3 release
 (3.0.1?). We've fixed a bunch of stuff, upgraded Tomcat, OpenJPA, and
 fixed Java 7 complication issues. TCK is also looking pretty good now.
 
 Thoughts?

Sounds great to me. I assume this is with the current set of dependencies? E.g. 
OpenEJB 4.0.0-beta-1, xbean 3.11.1, myfaces 2.1.11, etc…

Would be good to run a similar email by the user list…

--kevan

Re: Permission to translate your page at http://geronimo.apache.org/

[Kevan Miller]

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

 Hi!
 
 I think there is no issue as long as you 
 
 a.) prominently link to the Apache Geronimo page as origin of the info
 b.) follow the few guidelines listed in our Trademarks page 
 http://apache.org/foundation/marks/

As our web site is licensed under Apache License v2, the terms of our license 
must also be adhered to…

In general, we have no issue with translation of documentation. Even better, we 
encourage the donation of translated documentation to the project. Geronimo 
documentation has been translated to a number of languages: Spanish, French, 
Polish, Portuguese, and Japanese. See https://cwiki.apache.org/geronimo/

Note that this is almost certainly a scam. it's very likely that we are about 
to receive an email requesting that we add a link back from our project to this 
translated documentation. That is not going to happen. This is simply an 
attempt to increase the page rank of their web site.

Anja, if that is your motivation for translating the documentation, please 
don't bother. We will not link back to your website.

All, some background:

http://www.opensourcecatholic.com/blog/jeff-geerling/strange-requests
http://s.apache.org/translation_scam

There have been some other emails in the ASF on this topic…

--kevan

Re: Spam blitz on yoko wiki

[Kevan Miller]

On Apr 16, 2013, at 7:59 AM, Rick McGuire rick...@gmail.com wrote:

 I've been seeing a deluge of spam-type updates on the yoko wiki.  Is there 
 some sort of permission problem with that wiki that's allowing these?

FYI. The incubator-yoko wiki is no more…

http://wiki.apache.org/incubator-yoko/

No wiki configuration matching the URL found!

--kevan

Re: xbean finder getURLs()

[Kevan Miller]

On Apr 17, 2013, at 3:22 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:

 Hi,
 
 in org.apache.xbean.finder.UrlSet#getUrls we rely on META-INF (or ) to find 
 jars. There are cases where it doesn't work at all (a common case where i saw 
 it is when you only have META-INF/MANIFEST.MF which is consider for a single 
 entry and not META-INF then MANIFEST.MF - depends the build tool/zip format 
 if i understood correctly)
 
 the question are:
 1) do we getresources(META-INF/MANIFEST.MF) too
 2) why not simply querying the classloader which is very very often an 
 URLClassLoader - if (yes) return Arrays.asList(classLoader.getURLs()); else 
 currentImpl;
 
 The 2 seems less correct but in practise i think it is more efficient - we 
 can do both too (testing URLClassLoader and if not adding MANIFEST.MF listing)
 
 wdyt?

Hi Romain,
I'd be interested in some examples. What tools/jars don't contain a META-INF? 
But contain META-INF/MANIFEST.MF?

Anyway, given that they (tools/jars) evidently exist, I guess 2) is ok. As you 
say, it may be faster. Concern will be about changing the behavior. But if we 
get sufficient testing, should be ok…

--kevan

Re: xbean finder getURLs()

[Kevan Miller]

On Apr 25, 2013, at 9:25 AM, Romain Manni-Bucau rmannibu...@gmail.com wrote:

 tested a bit perfs using AppClassLoader only (so it can be a bit different in 
 a JavaEE or OSGi envrt)
 
 single call: URLClassLoader = 654 vs getResources = 1130 (ms but the unit 
 is not important)
 1000 calls: 5503 vs 612621
 
 i'll check our tests are still passing then commit the change if nobody 
 shouts before

Sounds good. Thanks Romain.

--kevan

update dependencies?

[Kevan Miller]

I see there is a new OpenJPA release. I also noticed that our OpenEJB 
depencency is 4.0.0-beta-1.

Any plans on updating these (or other dependencies)?

--kevan

Re: update dependencies?

[Kevan Miller]

On Apr 23, 2013, at 10:16 AM, Jarek Gawor jga...@gmail.com wrote:

 Updating dependencies sometimes can be a lot of work. So as long as
 updating OpenJPA /. OpenEJB doesn't cause a lot headaches I'm all for
 it. But in short term I think we should be concentrating on getting a
 new 3.0 release out.

Understood. But let's please make this explicit. 

There's been movement towards a 3.0.1 release, but I don't think anyone's 
formally volunteered to be RC or identify a general target for the release.

If we decide whether or not to upgrade dependencies, that's all fine. Would 
like to see some analysis/discussion of this…

--kevan

Re: Spam blitz on yoko wiki

[Kevan Miller]

On Apr 16, 2013, at 8:59 AM, Kevan Miller kevan.mil...@gmail.com wrote:

 
 On Apr 16, 2013, at 8:53 AM, Kevan Miller kevan.mil...@gmail.com wrote:
 
 Hi Rick,
 Yes, must be.
 
 Is there any reason to preserve this wiki? At first, I couldn't understand 
 why I wasn't seeing the same spam. Until I realized that this is 
 incubator-yoko and not the yoko wiki within geronimo.
 
 Here's the current wiki -- http://geronimo.apache.org/yoko/
 
 I think we have two choices:
 
 1. delete the spam and shutdown write-access to the wiki (or reduce write 
 access to the wiki to a known group). Or,
 2. delete the wiki (I assume that the spam doesn't need to be deleted, in 
 this case. but that would be infra's call).
 
 Preference? Could you take one of these steps? If not, let me know and I'll 
 do it -- just let me know…
 
 By the way for either action, we'll need to raise an Infra jira -- 
 https://issues.apache.org/jira/browse/INFRA

I've generated a Jira to have the wiki deleted -- 
https://issues.apache.org/jira/browse/INFRA-6174

--kevan

Re: Java EE 7 API jars

[Kevan Miller]

On Apr 19, 2013, at 8:18 AM, Jean-Louis MONTEIRO jeano...@gmail.com wrote:

 Hi Kevan,
 
 Yes, if someone could create a new branch that'd be great thought I don't 
 plan to work on a lot next week.
 Kevin already created all JIRAs so I just need to submit patches.

OK, Jean-Louis:

https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-ejb_3.2_spec

I tweaked pom.xml and NOTICE, but did nothing else (including not trying to 
build).

Thanks!

--kevan

Re: Java EE 7 API jars

[Kevan Miller]

On Apr 18, 2013, at 1:40 AM, Jean-Louis MONTEIRO jeano...@gmail.com wrote:

 Hi Kevan,
 
 Maybe I could help on EJB 3.2 part.

That would be great. Let us know and someone could svn copy create the initial 
branch. 

My advise would be to start with a few small patches. Give the community a 
chance to see your contributions in smaller chunks. Should help make the 
process go more smoothly…

--kevan

[jira] [Commented] (GERONIMO-6446) Build with Java 7

[Kevan Miller (JIRA)]

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

Kevan Miller commented on GERONIMO-6446:


One note -- flipping the logic around (checking for Mac OS  Java 6) may make 
things easier when Java 8 shows up. We have no guarantees, though...

 Build with Java 7
 -

 Key: GERONIMO-6446
 URL: https://issues.apache.org/jira/browse/GERONIMO-6446
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: buildsystem
Affects Versions: 3.0.0
Reporter: Jarek Gawor
Assignee: Jarek Gawor

 Ensure that 3.0 branch builds with Java 7.

--
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] [Updated] (GERONIMO-6449) Java EE 7 API jar files

[Kevan Miller (JIRA)]

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

Kevan Miller updated GERONIMO-6449:
---

Component/s: Java EE 7

 Java EE 7 API jar files
 ---

 Key: GERONIMO-6449
 URL: https://issues.apache.org/jira/browse/GERONIMO-6449
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: Java EE 7
Reporter: Kevin Sutter
  Labels: javaee

 Based on the discussion on the dev mailing list, creating a set of JIRAs 
 seems to be the best way to get the ball rolling on developing the set of API 
 jars for Java EE 7.  I'll create this parent JIRA along with the individual 
 sub-tasks for each of the major Java EE 7 technologies.  There have also been 
 several maintenance releases of other JSRs related to Java EE 7.  I didn't 
 automatically create sub-tasks for each of these since I'm not positive API 
 updates were required for each of them.  We can create those as sub-tasks as 
 needed.
 I'm not familiar with the Geronimo version strategy, so I'll let someone else 
 fill those fields in.  Also, there doesn't seem to be a javaee7 component 
 identified yet for Geronimo, if somebody can create one of those and assign 
 it to this JIRA.
 This will be a group effort.  Whatever group needs a particular spec API jar 
 file will probably be the first one to sign up to do the work.  But, even 
 with that, there will probably be multiple people or teams verifying or 
 contributing to the end result.

--
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-6449) Java EE 7 API jar files

[Kevan Miller (JIRA)]

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

Kevan Miller commented on GERONIMO-6449:


Great. Thanks KevIn.

I've created a Java EE 7 component and assigned it to this Jira (but not the 
sub-tasks).

We have typically tracked Geronimo server version numbers in Jira (and not spec 
version numbers -- there's too many of them. and many slightly different).

 Java EE 7 API jar files
 ---

 Key: GERONIMO-6449
 URL: https://issues.apache.org/jira/browse/GERONIMO-6449
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: Java EE 7
Reporter: Kevin Sutter
  Labels: javaee

 Based on the discussion on the dev mailing list, creating a set of JIRAs 
 seems to be the best way to get the ball rolling on developing the set of API 
 jars for Java EE 7.  I'll create this parent JIRA along with the individual 
 sub-tasks for each of the major Java EE 7 technologies.  There have also been 
 several maintenance releases of other JSRs related to Java EE 7.  I didn't 
 automatically create sub-tasks for each of these since I'm not positive API 
 updates were required for each of them.  We can create those as sub-tasks as 
 needed.
 I'm not familiar with the Geronimo version strategy, so I'll let someone else 
 fill those fields in.  Also, there doesn't seem to be a javaee7 component 
 identified yet for Geronimo, if somebody can create one of those and assign 
 it to this JIRA.
 This will be a group effort.  Whatever group needs a particular spec API jar 
 file will probably be the first one to sign up to do the work.  But, even 
 with that, there will probably be multiple people or teams verifying or 
 contributing to the end result.

--
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-6446) Build with Java 7

[Kevan Miller (JIRA)]

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

Kevan Miller commented on GERONIMO-6446:


Working for me

 Build with Java 7
 -

 Key: GERONIMO-6446
 URL: https://issues.apache.org/jira/browse/GERONIMO-6446
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: buildsystem
Affects Versions: 3.0.0
Reporter: Jarek Gawor
Assignee: Jarek Gawor

 Ensure that 3.0 branch builds with Java 7.

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

Re: Java EE 7 API jars

[Kevan Miller]

On Apr 17, 2013, at 4:57 PM, Kevin Sutter kwsut...@gmail.com wrote:

 Hi,
 Is there any activity in the Geronimo community to create and house the API 
 jar files for Java EE 7 technologies, just like we've had available in the 
 past with previous spec levels?  Is this work has already been started, could 
 you point me at the JIRA or wiki or whatever is tracking this piece of work?  
 If the work hasn't been started, how should we kickstart this activity?
 
 The Java EE 7 family of specifications is very near to being finalized.  It 
 would be great to have these API jar files available for those projects that 
 will be implementing the specifications.  And, I think the Geronimo project 
 is a great holding place.  Not that the Geronimo team has to do all the work, 
 but it would be good to have a central project.

Hi Kevin,
Yes, there has been some work/discussion. Mark Struberg mentioned that he was 
going to start work on commons-annotation-1.2. 

I haven't seen any concerted effort to start building all Java 7 specs. Nor any 
effort to track Java 7 spec creation. A Jira with sub-tasks is probably a good 
way to start. Perhaps you want to give it a try? (Since it seems you may have 
an itch… ;-)

--kevan

Re: Spam blitz on yoko wiki

[Kevan Miller]

Hi Rick,
Yes, must be.

Is there any reason to preserve this wiki? At first, I couldn't understand why 
I wasn't seeing the same spam. Until I realized that this is incubator-yoko and 
not the yoko wiki within geronimo.

Here's the current wiki -- http://geronimo.apache.org/yoko/

I think we have two choices:

1. delete the spam and shutdown write-access to the wiki (or reduce write 
access to the wiki to a known group). Or,
2. delete the wiki (I assume that the spam doesn't need to be deleted, in this 
case. but that would be infra's call).

Preference? Could you take one of these steps? If not, let me know and I'll do 
it -- just let me know…

--kevan

On Apr 16, 2013, at 7:59 AM, Rick McGuire rick...@gmail.com wrote:

 I've been seeing a deluge of spam-type updates on the yoko wiki.  Is there 
 some sort of permission problem with that wiki that's allowing these?
 
 Rick
 
 
  Original Message 
 Subject:  [Incubator-yoko Wiki] Trivial Update of SangRigby by SangRigby
 Date: Sat, 13 Apr 2013 00:50:34 -
 From: Apache Wiki wikidi...@apache.org
 Reply-To: yoko-...@incubator.apache.org
 To:   Apache Wiki wikidi...@apache.org
 
 
 
 Dear Wiki user,
 
 You have subscribed to a wiki page or wiki category on Incubator-yoko Wiki 
 for change notification.
 
 The SangRigby page has been changed by SangRigby:
 http://wiki.apache.org/incubator-yoko/SangRigby
 
 New page:
 I am 18 years old and my name is Sang Rigby. I life in Purmerend 
 (Netherlands).BR
 BR
 BR
 my website :: 
 [[http://buzca.info/blog/view/115638/jigsaw-health-promotion-code|simply 
 click the up coming internet site]]
 
 
 

Re: Spam blitz on yoko wiki

[Kevan Miller]

On Apr 16, 2013, at 8:53 AM, Kevan Miller kevan.mil...@gmail.com wrote:

 Hi Rick,
 Yes, must be.
 
 Is there any reason to preserve this wiki? At first, I couldn't understand 
 why I wasn't seeing the same spam. Until I realized that this is 
 incubator-yoko and not the yoko wiki within geronimo.
 
 Here's the current wiki -- http://geronimo.apache.org/yoko/
 
 I think we have two choices:
 
 1. delete the spam and shutdown write-access to the wiki (or reduce write 
 access to the wiki to a known group). Or,
 2. delete the wiki (I assume that the spam doesn't need to be deleted, in 
 this case. but that would be infra's call).
 
 Preference? Could you take one of these steps? If not, let me know and I'll 
 do it -- just let me know…

By the way for either action, we'll need to raise an Infra jira -- 
https://issues.apache.org/jira/browse/INFRA

--kevan

Re: commons-annotation-1.2.MR2

[Kevan Miller]

On Apr 16, 2013, at 3:32 PM, Mark Struberg strub...@yahoo.de wrote:

 hi folks!
 
 In CDI and EJB for EE7 we need a few things from commons-annotation-1.2.MR2.
 Most important is the new javax.annotation.Priority annotation.
 
 Should I just svn copy the geronimo-annotation_1.1_spec module and add the 
 missing annotations?

Hi Mark,
Are you proposing that we svn copy geronimo-annotation_1.1_spec to a new 
geronimo-annotation_1.2_spec and start adding new features defined by the new 
spec?

If so, then yes. Sounds good to me. Thanks!

--kevan

[jira] [Commented] (GERONIMO-6446) Build with Java 7

[Kevan Miller (JIRA)]

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

Kevan Miller commented on GERONIMO-6446:


This is a slightly more general was of accomplishing that work-around:

{code}
$ sudo mkdir `/usr/libexec/java_home`/Classes 
$ sudo ln -s `/usr/libexec/java_home`/lib/tools.jar 
`/usr/libexec/java_home`/Classes/classes.jar
{code}



 Build with Java 7
 -

 Key: GERONIMO-6446
 URL: https://issues.apache.org/jira/browse/GERONIMO-6446
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: buildsystem
Affects Versions: 3.0.0
Reporter: Jarek Gawor
Assignee: Jarek Gawor

 Ensure that 3.0 branch builds with Java 7.

--
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-6446) Build with Java 7

[Kevan Miller (JIRA)]

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

Kevan Miller commented on GERONIMO-6446:


I now get the following error:

{code}
[ERROR] Failed to execute goal 
org.apache.geronimo.buildsupport:car-maven-plugin:3.0.1-SNAPSHOT:package 
(default-package) on project uddi-tomcat: could not package plugin: Unable to 
generate the wsdl file using wsgen. InvocationTargetException: 
com/sun/mirror/apt/AnnotationProcessorFactory: 
com.sun.mirror.apt.AnnotationProcessorFactory in classloader null - [Help 1]
{code}

 Build with Java 7
 -

 Key: GERONIMO-6446
 URL: https://issues.apache.org/jira/browse/GERONIMO-6446
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: buildsystem
Affects Versions: 3.0.0
Reporter: Jarek Gawor
Assignee: Jarek Gawor

 Ensure that 3.0 branch builds with Java 7.

--
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-6446) Build with Java 7

[Kevan Miller (JIRA)]

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

Kevan Miller commented on GERONIMO-6446:


FYI, I'm seeing the following:

{code}
Exception in thread main java.lang.AssertionError: Missing tools.jar at: 
/Library/Java/JavaVirtualMachines/jdk1.7.0_17.jdk/Contents/Home/Classes/classes.jar.
 Expression: file.exists()
at 
org.codehaus.groovy.runtime.InvokerHelper.assertFailed(InvokerHelper.java:395)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.assertFailed(ScriptBytecodeAdapter.java:683)
at 
org.codehaus.mojo.jspc.CompilationMojoSupport.findToolsJar(CompilationMojoSupport.groovy:371)
at 
org.codehaus.mojo.jspc.CompilationMojoSupport.this$4$findToolsJar(CompilationMojoSupport.groovy)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:86)
at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:230)
at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:912)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrentN(ScriptBytecodeAdapter.java:78)
at 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter.invokeMethodOnCurrent0(ScriptBytecodeAdapter.java:112)
at 
org.codehaus.mojo.jspc.CompilationMojoSupport.execute(CompilationMojoSupport.groovy:318)
at 
org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
at 
org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84)
at 
org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
at 
org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:319)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:156)
at org.apache.maven.cli.MavenCli.execute(MavenCli.java:537)
at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:196)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:141)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:290)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:230)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:409)
at 
org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:352)
{code}

in

{code}
[INFO] 
[INFO] Building Geronimo Plugins, System Database :: Portlets 3.0.1-SNAPSHOT
[INFO] 
{code}

This must be a known/resolved problem... My first google search didn't turn up 
anything... 

 Build with Java 7
 -

 Key: GERONIMO-6446
 URL: https://issues.apache.org/jira/browse/GERONIMO-6446
 Project: Geronimo
  Issue Type: Improvement
  Security Level: public(Regular issues) 
  Components: buildsystem
Affects Versions: 3.0.0
Reporter: Jarek Gawor
Assignee: Jarek Gawor

 Ensure that 3.0 branch builds with Java 7.

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

Re: [tranql-dev] tranql connector release candidate for jdbc 4 support

[Kevan Miller]

On Apr 5, 2013, at 3:58 PM, David Jencks david_jen...@yahoo.com wrote:

 I've put together a release candidate for the tranql connector projects 
 staged at 
 
 https://nexus.codehaus.org/content/repositories/orgtranql-016/
 
 The main purpose is to support jdbc 4.  I also simplified the prepared 
 statement cache code by moving it to a new abstract MCF class and making the 
 individual MCFs that support prepared statement caching themselves inherit 
 from the new abstract class.  I also provided a generic wrapper that does PS 
 caching.  Geronimo might want to use this in the @Datasource support, I'm not 
 sure.
 
 Please take a look.  If there are no problems reported I plan to release 
 these no sooner than monday.

Nice. Thanks David!

I know there have been some users quite eager for JDBC4 support. Hoping they'd 
be willing to give this a try -- would be a great way to validate.

--kevan

Re: JDBC 4

[Kevan Miller]

On Mar 19, 2013, at 12:05 PM, Kevan Miller kevan.mil...@gmail.com wrote:

 It's my understanding that we don't currently support JDBC 4 api's in 3.0. 
 Are there plans to fix this? IIRC, we need a TranQL release?

Anybody looking into this?

IMO, this must be fixed prior to our next 3.0.x release -- i.e. I'll vote -1 
for a release that doesn't fix it...

--kevan

Re: [VOTE] Release geronimo-jaxws_2.2_spec-1.2

[Kevan Miller]

All looks good to me: sigs/checksum, source/rat, license/notice, build…

+1

--kevan

On Mar 29, 2013, at 11:15 PM, Jarek Gawor jga...@gmail.com wrote:

 Hi all,
 
 I would like to call a vote on geronimo-jaxws_2.2_spec-1.2. It is a
 minor release that contains GERONIMO-6432.
 
 Source archives:
 https://repository.apache.org/content/repositories/orgapachegeronimo-037/org/apache/geronimo/specs/geronimo-jaxws_2.2_spec/1.2/
 
 Source tag:
 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jaxws_2.2_spec-1.2
 
 Staging repository:
 https://repository.apache.org/content/repositories/orgapachegeronimo-037/
 
 Vote will be open for 72 hours.
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 
 Here's my +1.
 
 Jarek

Re: [VOTE] (take 2) Release yoko-1.4

[Kevan Miller]

Looks good to me. Sig/checksum, source/RAT, LICENSE/NOTICE, build…

Here's my +1

Thanks Jarek!

--kevan

On Apr 2, 2013, at 11:07 AM, Jarek Gawor jga...@gmail.com wrote:

 Hi all,
 
 I would like to call a vote on yoko-1.4. It is a minor release that
 contains TCK related fixes (GERONIMOTCK-133, GERONIMOTCK-142) and
 Genesis update to build with Java 7.
 
 Source archives:
 https://repository.apache.org/content/repositories/orgapachegeronimo-052/org/apache/yoko/yoko/1.4/
 
 Source tag:
 https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.4/
 
 Staging repository:
 https://repository.apache.org/content/repositories/orgapachegeronimo-052/
 
 Vote will be open for 72 hours.
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 
 Here's my +1.
 
 Jarek

Re: [VOTE] Release yoko-1.4

[Kevan Miller]

Is there a reason why yoko hasn't moved to the new genesis plugin to enable 
building with java 7?

--kevan

On Mar 29, 2013, at 11:33 PM, Jarek Gawor jga...@gmail.com wrote:

 Hi all,
 
 I would like to call a vote on yoko-1.4. It is a minor release that
 contains TCK related fixes (GERONIMOTCK-133, GERONIMOTCK-142).
 
 Source archives:
 https://repository.apache.org/content/repositories/orgapachegeronimo-038/org/apache/yoko/yoko/1.4/
 
 Source tag:
 https://svn.apache.org/repos/asf/geronimo/yoko/tags/yoko-1.4/
 
 Staging repository:
 https://repository.apache.org/content/repositories/orgapachegeronimo-038/
 
 Vote will be open for 72 hours.
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 
 Here's my +1.
 
 Jarek

Re: [VOTE] Release yoko-1.4

[Kevan Miller]

On Apr 1, 2013, at 10:30 AM, Jarek Gawor jga...@gmail.com wrote:

 I tired compiling Yoko (and jax-ws spec) on Java 7 and it compiled
 fine with the old (2.0) genesis.

Hmm. Yoko failed for me on Java 7. I'll retry to confirm...

--kevan

Re: [VOTE] Release yoko-1.4

[Kevan Miller]

On Apr 1, 2013, at 10:30 AM, Jarek Gawor jga...@gmail.com wrote:

 I tired compiling Yoko (and jax-ws spec) on Java 7 and it compiled
 fine with the old (2.0) genesis.

Here are my results:

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) 
on project yoko-rmi-impl: Compilation failure: Compilation failure:
[ERROR] could not parse error message: warning: [options] bootstrap class path 
not set in conjunction with -source 1.5
[ERROR] 
/Users/kevan/tmp/release/yoko-1.4/yoko-rmi-impl/src/main/java/org/apache/yoko/rmi/impl/ValueHandlerImpl.java:53:
 warning: ReflectionFactory is internal proprietary API and may be removed in a 
future release
[ERROR] private ValueDescriptor desc(Class clz, String repid, RunTime runtime) {
[ERROR] ^
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/yoko-1.4/yoko-rmi-impl/src/main/java/org/apache/yoko/rmi/impl/ValueDescriptor.java:[349,51]
 ReflectionFactory is internal proprietary API and may be removed in a future 
release
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/yoko-1.4/yoko-rmi-impl/src/main/java/org/apache/yoko/rmi/impl/FieldDescriptor.java:[24,29]
 Unsafe is internal proprietary API and may be removed in a future release
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/yoko-1.4/yoko-rmi-impl/src/main/java/org/apache/yoko/rmi/util/corba/Field.java:[32,17]
 Unsafe is internal proprietary API and may be removed in a future release
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/yoko-1.4/yoko-rmi-impl/src/main/java/org/apache/yoko/rmi/util/corba/Field.java:[37,19]
 Unsafe is internal proprietary API and may be removed in a future release
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/yoko-1.4/yoko-rmi-impl/src/main/java/org/apache/yoko/rmi/util/corba/Field.java:[38,8]
 Unsafe is internal proprietary API and may be removed in a future release
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/yoko-1.4/yoko-rmi-impl/src/main/java/org/apache/yoko/rmi/util/corba/Field.java:[40,23]
 Unsafe is internal proprietary API and may be removed in a future release
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/yoko-1.4/yoko-rmi-impl/src/main/java/org/apache/yoko/rmi/util/corba/Field.java:[45,30]
 Unsafe is internal proprietary API and may be removed in a future release
[ERROR] - [Help 1]
[ERROR] 
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR] 
[ERROR] For more information about the errors and possible solutions, please 
read the following articles:
[ERROR] [Help 1] 
http://cwiki.apache.org/confluence/display/MAVEN/MojoFailureException
[ERROR] 
[ERROR] After correcting the problems, you can resume the build with the command
[ERROR]   mvn goals -rf :yoko-rmi-impl

Re: [VOTE] Release yoko-1.4

[Kevan Miller]

On Apr 1, 2013, at 10:00 PM, Shawn Jiang genspr...@gmail.com wrote:

 I got the same failures.  But is this a real stop issue ?

A stop issue is something that fails to conform to the requirements of the ASF. 
So, no…

My personal opinion is that all of our releases should build with Java 7 -- as 
this the the JDK level most people will be building with. 

I'm wavering between -1 and -0. 

Here's my -0.

--kevan

JDBC 4

[Kevan Miller]

It's my understanding that we don't currently support JDBC 4 api's in 3.0. Are 
there plans to fix this? IIRC, we need a TranQL release?

--kevan

[ANNOUNCE] Welcome Romain Manni-Bucau as a new Geronimo committer

[Kevan Miller]

Everyone,
In recognition of his contributions to the Geronimo project, the Geronimo PMC 
has invited Romain Manni-Bucau to become a committer on our project. We are 
pleased to announce that he has accepted our invitation. 

Please join us in congratulating Romain. Welcome!

--kevan

Re: [VOTE] [RESULT] (take 2) Release genesis-2.1 and xbean-3.13

[Kevan Miller]

On Mar 15, 2013, at 8:58 AM, Mark Struberg strub...@yahoo.de wrote:

 Np, thank to you for helping. 
 
 Btw, with the 'what else' I meant things like a announcement mail and moving 
 binaries to a download area. 
 Not sure if / how this is done for such partly releases in G#.

Ah. I see. The news (http://geronimo.apache.org/news-archive.html) and mailing 
list announcements have normally been around the more consumable releases 
(server, eclipse plugin, samples). That's not to say that xbean/genesis can't 
have similar treatment… But not necessary, either, IMO.

--kevan

Re: [VOTE] Release geronimo-jsp_2.2_spec-1.2 and geronimo-el_2.2_spec-1.0.4

[Kevan Miller]

Thanks. I switched the pom to use genesis 2.1 and see it builds…

I'm +1 for the releases, with some hesitation...

Going forward, I think we should require that our releases are buildable with 
Java 7 JDK.

--kevan

On Mar 13, 2013, at 8:38 PM, Jarek Gawor jga...@gmail.com wrote:

 I see that when compiling with Java 7. It compiles fine with Java 6. I
 think that's the difference of using genesis 2.0 vs 2.1.
 
 Jarek
 
 On Wed, Mar 13, 2013 at 6:45 PM, Kevan Miller kevan.mil...@gmail.com wrote:
 I get the following error, if I build with Java 7 on Mac OS. Do you see the 
 same? Or something different?
 
 [INFO] 
 
 [INFO] BUILD FAILURE
 [INFO] 
 
 [INFO] Total time: 5.139s
 [INFO] Finished at: Wed Mar 13 18:38:10 EDT 2013
 [INFO] Final Memory: 17M/190M
 [INFO] 
 
 [ERROR] Failed to execute goal 
 org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile 
 (default-compile) on project geronimo-jsp_2.2_spec: Compilation failure: 
 Compilation failure:
 [ERROR] could not parse error message: warning: [options] bootstrap class 
 path not set in conjunction with -source 1.5
 [ERROR] 
 /Users/kevan/tmp/release/geronimo-jsp_2.2_spec-1.2/src/main/java/javax/servlet/jsp/tagext/TagAdapter.java:24:
  warning: [deprecation] ExpressionEvaluator in javax.servlet.jsp.el has been 
 deprecated
 [ERROR] * Wraps any SimpleTag and exposes it using a Tag interface.  This is 
 used
 [ERROR] ^
 [ERROR]
 [ERROR] 
 /Users/kevan/tmp/release/geronimo-jsp_2.2_spec-1.2/src/main/java/javax/servlet/jsp/tagext/TagAdapter.java:[25,17]
  [deprecation] VariableResolver in javax.servlet.jsp.el has been deprecated
 [ERROR]
 [ERROR] 
 /Users/kevan/tmp/release/geronimo-jsp_2.2_spec-1.2/src/main/java/javax/servlet/jsp/JspContext.java:[226,20]
  [deprecation] ExpressionEvaluator in javax.servlet.jsp.el has been 
 deprecated
 [ERROR]
 [ERROR] 
 /Users/kevan/tmp/release/geronimo-jsp_2.2_spec-1.2/src/main/java/javax/servlet/jsp/JspContext.java:[239,20]
  [deprecation] VariableResolver in javax.servlet.jsp.el has been deprecated
 [ERROR] - [Help 1]
 [ERROR]
 
 --kevan
 
 
 On Mar 13, 2013, at 12:58 AM, Jarek Gawor jga...@gmail.com wrote:
 
 Hi all,
 
 I would like to call a vote on geronimo-jsp_2.2_spec-1.2 and
 geronimo-el_2.2_spec-1.0.4:
 
 geronimo-jsp_2.2_spec-1.2:
 - minor release, contains minor performance improvements (r1387447)
 and a synchronization fix (r1386839).
 - source archives:
 https://repository.apache.org/content/repositories/orgapachegeronimo-003/org/apache/geronimo/specs/geronimo-jsp_2.2_spec/1.2/
 - source tag:
 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsp_2.2_spec-1.2/
 
 geronimo-el_2.2_spec-1.0.4:
 - minor release, contains minor performance improvements (r1376237).
 - source archives:
 https://repository.apache.org/content/repositories/orgapachegeronimo-003/org/apache/geronimo/specs/geronimo-el_2.2_spec/1.0.4/
 - source tag:
 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-el_2.2_spec-1.0.4/
 
 Staging repository (contains all artifacts for both specs):
 - https://repository.apache.org/content/repositories/orgapachegeronimo-003/
 
 Vote will be open for 72 hours.
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)
 

Re: [VOTE] [RESULT] (take 2) Release genesis-2.1 and xbean-3.13

[Kevan Miller]

On Mar 14, 2013, at 1:28 PM, Mark Struberg strub...@yahoo.de wrote:

 hi folks!
 
 Time to tally the votes
 
 For genesis:
 
 +1: Jarek Gawor, Kevan Miller, David Blevins, Guillaume Nodet , Forrest Xia
 +1 (nonbinding): Romain Manni-Buccau, Mark Struberg
 
 For xbean
 
 +1: Kevan Miller, David Blevins, FGuillaume Nodet, Forrest Xia
 +0: Jarek Gawor, 
 +1 (nonbinding): Romain Manni-Buccau, Mark Struberg
 txs 4 all who voted!
 
 I gonna push the maven artifacts to central (and later remove the unnecessary 
 repo section from the xbean pom).
 
 What else is to be done in geronimo-land for such a 'spare-parts' release?

That's typically it. I'll close out the XBean release in Jira…

--kevan

Re: [VOTE] [RESULT] (take 2) Release genesis-2.1 and xbean-3.13

[Kevan Miller]

On Mar 14, 2013, at 1:28 PM, Mark Struberg strub...@yahoo.de wrote:

 hi folks!
 
 Time to tally the votes
 
 For genesis:
 
 +1: Jarek Gawor, Kevan Miller, David Blevins, Guillaume Nodet , Forrest Xia
 +1 (nonbinding): Romain Manni-Buccau, Mark Struberg
 
 For xbean
 
 +1: Kevan Miller, David Blevins, FGuillaume Nodet, Forrest Xia
 +0: Jarek Gawor, 
 +1 (nonbinding): Romain Manni-Buccau, Mark Struberg
 txs 4 all who voted!
 
 I gonna push the maven artifacts to central (and later remove the unnecessary 
 repo section from the xbean pom).
 
 What else is to be done in geronimo-land for such a 'spare-parts' release?

Oh yeah… Thanks!

--kevan

Re: [VOTE] aspectjrt-1.6.8_2, aspectjweaver-1.6.8_2, and commons-httpclient-3.1_2

[Kevan Miller]

Here's my +1 for all 3.

Source, rat, build, license/notice -- all looked good.

--kevan

On Mar 13, 2013, at 10:56 AM, Jarek Gawor jga...@gmail.com wrote:

 Hi all,
 
 I would like to call a vote on aspectjrt-1.6.8_2,
 aspectjweaver-1.6.8_2, and commons-httpclient-3.1_2.
 
 aspectjrt-1.6.8_2:
  - minor release, contains GERONIMO-6415.
  - source archives:
 https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/bundles/aspectjrt/1.6.8_2/
  - source tag:
 https://svn.apache.org/repos/asf/geronimo/bundles/tags/aspectjrt-1.6.8_2/
 
 aspectjweaver-1.6.8_2:
  - minor release, contains GERONIMO-6415.
  - source archives:
 https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/bundles/aspectjweaver/1.6.8_2
  - source tag:
 https://svn.apache.org/repos/asf/geronimo/bundles/tags/aspectjweaver-1.6.8_2/
 
 commons-httpclient-3.1_2:
  - minor release, contains GERONIMO-6406.
  - source archives:
 https://repository.apache.org/content/repositories/orgapachegeronimo-005/org/apache/geronimo/bundles/commons-httpclient/3.1_2/
  - source tag:
 https://svn.apache.org/repos/asf/geronimo/bundles/tags/commons-httpclient-3.1_2/
 
 Staging repository (contains all artifacts for all bundles):
  - https://repository.apache.org/content/repositories/orgapachegeronimo-005/
 
 Vote will be open for 72 hours.
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

Re: [VOTE] Release geronimo-jsp_2.2_spec-1.2 and geronimo-el_2.2_spec-1.0.4

[Kevan Miller]

I get the following error, if I build with Java 7 on Mac OS. Do you see the 
same? Or something different?

[INFO] 
[INFO] BUILD FAILURE
[INFO] 
[INFO] Total time: 5.139s
[INFO] Finished at: Wed Mar 13 18:38:10 EDT 2013
[INFO] Final Memory: 17M/190M
[INFO] 
[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:2.0.2:compile (default-compile) 
on project geronimo-jsp_2.2_spec: Compilation failure: Compilation failure:
[ERROR] could not parse error message: warning: [options] bootstrap class path 
not set in conjunction with -source 1.5
[ERROR] 
/Users/kevan/tmp/release/geronimo-jsp_2.2_spec-1.2/src/main/java/javax/servlet/jsp/tagext/TagAdapter.java:24:
 warning: [deprecation] ExpressionEvaluator in javax.servlet.jsp.el has been 
deprecated
[ERROR] * Wraps any SimpleTag and exposes it using a Tag interface.  This is 
used
[ERROR] ^
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-jsp_2.2_spec-1.2/src/main/java/javax/servlet/jsp/tagext/TagAdapter.java:[25,17]
 [deprecation] VariableResolver in javax.servlet.jsp.el has been deprecated
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-jsp_2.2_spec-1.2/src/main/java/javax/servlet/jsp/JspContext.java:[226,20]
 [deprecation] ExpressionEvaluator in javax.servlet.jsp.el has been deprecated
[ERROR] 
[ERROR] 
/Users/kevan/tmp/release/geronimo-jsp_2.2_spec-1.2/src/main/java/javax/servlet/jsp/JspContext.java:[239,20]
 [deprecation] VariableResolver in javax.servlet.jsp.el has been deprecated
[ERROR] - [Help 1]
[ERROR] 

--kevan


On Mar 13, 2013, at 12:58 AM, Jarek Gawor jga...@gmail.com wrote:

 Hi all,
 
 I would like to call a vote on geronimo-jsp_2.2_spec-1.2 and
 geronimo-el_2.2_spec-1.0.4:
 
 geronimo-jsp_2.2_spec-1.2:
  - minor release, contains minor performance improvements (r1387447)
 and a synchronization fix (r1386839).
  - source archives:
 https://repository.apache.org/content/repositories/orgapachegeronimo-003/org/apache/geronimo/specs/geronimo-jsp_2.2_spec/1.2/
  - source tag:
 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-jsp_2.2_spec-1.2/
 
 geronimo-el_2.2_spec-1.0.4:
  - minor release, contains minor performance improvements (r1376237).
  - source archives:
 https://repository.apache.org/content/repositories/orgapachegeronimo-003/org/apache/geronimo/specs/geronimo-el_2.2_spec/1.0.4/
  - source tag:
 https://svn.apache.org/repos/asf/geronimo/specs/tags/geronimo-el_2.2_spec-1.0.4/
 
 Staging repository (contains all artifacts for both specs):
  - https://repository.apache.org/content/repositories/orgapachegeronimo-003/
 
 Vote will be open for 72 hours.
 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

Re: [VOTE] (take 2) Release genesis-2.1 and xbean-3.13

[Kevan Miller]

Here are the Jira release notes for xbean:

Release Notes - XBean - Version 3.13

** Bug
* [XBEAN-233] - Support for RetentionPolicy.CLASS broken for ElementType 
FIELD, METHOD and CONSTRUCTOR
* [XBEAN-238] - ClassNotFoundException not catch so missing classes make 
AnnotationFinder scanning fail
* [XBEAN-241] - finder doesn't handle #

** New Feature
* [XBEAN-184] - Use wiring API for wired bundle calculation
* [XBEAN-189] - Add a new method in BundleUtils to determine which OSGi 
runtime is used now
* [XBEAN-237] - AnnotationFinder should provide methods to search for 
annotated method/constructor parameters


I've updated the copyright dates in the NOTICE files for Genesis and XBean in 
their development trunk. 

Other than the bad copyright dates, everything looks good to me. Here's my +1

--kevan

On Mar 8, 2013, at 3:12 PM, Mark Struberg strub...@yahoo.de wrote:

 
 
 Hi!
 
 I'd like to call a VOTE for the re-roll on genesis-2.1 and xbean-3.13.
 I fixed the issues catched by Jarek, txs 4 the catch!
 
 
 The Maven Staging Repo which contains both releases (xbean needs genesis):
 https://repository.apache.org/content/repositories/orgapachegeronimo-004/
 
 
 SVN source tag for genesis:
 https://svn.apache.org/repos/asf/geronimo/genesis/tags/genesis-2.1/
 
 SVN source tag for xbean:
 https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.13/
 
 Source releases (plus hashes) are available under:
 https://repository.apache.org/content/repositories/orgapachegeronimo-004/org/apache/geronimo/genesis/genesis/2.1/
 https://repository.apache.org/content/repositories/orgapachegeronimo-004/org/apache/xbean/xbean/3.13/
 
 
 
 My PGP release key 2FDB81B1 is available at
 https://svn.apache.org/repos/asf/geronimo/KEYS
 
 Kevan is so kind and will collect the JIRA bits (I have absolutely no 
 oversight about how to gather all the needed infos there).
 
 The VOTE will be open for 72 hours. 
 
 [ ] +1 approve 
 [ ] +0 no opinion
 [ ] -1 veto (and reason why) 
 
 
 There is a small (and old) guide for testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 In practice it's as easy as adding a profile to your ~/.m2/settings.xml 
 which contains the repository with the URL pointing to the 
 staging repo as posted above.
 
 
 txs and LieGrue,
 strub

Re: [VOTE] [CANCELLED] Release genesis-2.1 and xbean-3.13

[Kevan Miller]

Thanks Mark. One favor?

Please indicate the source that is being voted on. In this case, I believe it 
would be:

https://repository.apache.org/content/repositories/orgapachegeronimo-004/org/apache/geronimo/genesis/genesis/2.1/genesis-2.1-source-release.zip

and

https://repository.apache.org/content/repositories/orgapachegeronimo-004/org/apache/xbean/xbean/3.13/xbean-3.13-source-release.zip

--kevan


On Mar 8, 2013, at 3:59 AM, Mark Struberg strub...@yahoo.de wrote:

 FYI: here is the new staging repo. Will tinker the mail soon
 https://repository.apache.org/content/repositories/orgapachegeronimo-004/
 
 LieGrue,
 strub
 
 
 
 - Original Message -
 From: Mark Struberg strub...@yahoo.de
 To: dev@geronimo.apache.org dev@geronimo.apache.org
 Cc: 
 Sent: Friday, March 8, 2013 8:30 AM
 Subject: Re: [VOTE] [CANCELLED] Release genesis-2.1 and xbean-3.13
 
 T xs for catching this!
 I gonna reroll after this has been fixed. 
 
 It seems the 2 genesis modules you mentioned are not even in the modules 
 section since quite some time. Thus I gonna delete them from SVN if noone 
 objects. 
 
 
 
 Btw, the whole genesis project seems to be in a very bad shape. It e.g. 
 references a geronimo-genesis-skin in the site which does not exist!
 Gonna just drop it for now...
 
 
 LieGrue,
 strub
 
 
 From: Jarek Gawor jga...@gmail.com
 To: dev dev@geronimo.apache.org; Mark Struberg 
 strub...@yahoo.de 
 Sent: Friday, March 8, 2013 6:09 AM
 Subject: Re: [VOTE] Release genesis-2.1 and xbean-3.13
 
 Thank you for putting this all together! However, I did find a few problems:
 
 -1 for genesis. 1) geronimo-maven-plugin and geronimo-skip have
 SNAPHOST parents. If these are no longer needed then we should drop
 them from svn and not release them. 2) There is pluginRepository
 defined which points to
 http://people.apache.org/repo/m2-snapshot-repository which is no
 longer in use. I think that can be removed all together or at least
 changed to the nexus snapshot repository.
 
 -1 for xbean. In xbean I put in temporary repository/plugRepositry
 entries for apache snapshots repository so that genesis snapshots
 could be picked up (in the room pom.xml). Now that we are releasing
 genesis, those two repository entires are not needed anymore.
 
 Thanks again,
 
 Jarek
 
 On Thu, Mar 7, 2013 at 3:53 PM, Mark Struberg strub...@yahoo.de 
 wrote:
 Hi!
 
 I'd like to call a VOTE on genesis-2.1 and xbean-3.13.
 
 The Maven Staging Repo which contains both releases (xbean needs 
 genesis):
 
 https://repository.apache.org/content/repositories/orgapachegeronimo-001/
 
 
 SVN source tag for genesis:
 https://svn.apache.org/repos/asf/geronimo/genesis/tags/genesis-2.1/
 
 SVN source tag for xbean:
 https://svn.apache.org/repos/asf/geronimo/xbean/tags/xbean-3.13/
 
 Source releases (plus hashes) are available under:
 
 https://repository.apache.org/content/repositories/orgapachegeronimo-001/org/apache/geronimo/genesis/genesis/2.1/
 
 https://repository.apache.org/content/repositories/orgapachegeronimo-001/org/apache/xbean/xbean/3.13/
 
 My PGP release key 2FDB81B1 is available at
 https://svn.apache.org/repos/asf/geronimo/KEYS
 
 Kevan is so kind and will collect the JIRA bits (I have absolutely no
 oversight about how to gather all the needed infos there).
 
 The VOTE will be open for 72 hours.
 [ ] +1 approve
 [ ] +0 no opinion
 [ ] -1 veto (and reason why)
 
 
 There is a small (and old) guide for testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 In practice it's as easy as adding a profile to your 
 ~/.m2/settings.xml
 which contains the repository with the URL pointing to the 
 staging repo as
 posted above.
 
 
 txs and LieGrue,
 strub
 
 
 
 

Re: [VOTE] [CANCELLED] Release genesis-2.1 and xbean-3.13

[Kevan Miller]

On Mar 8, 2013, at 3:59 AM, Mark Struberg strub...@yahoo.de wrote:

 FYI: here is the new staging repo. Will tinker the mail soon
 https://repository.apache.org/content/repositories/orgapachegeronimo-004/

Hi Mark,
I looked over the releases in the staging repo. Things look good. The only 
issue that I saw was that the copyright dates in the NOTICE files are old. They 
should both be updated to 2013.

I don't treat this as a major issue. I wouldn't -1 a release just for this 
reason. But it is good practice to keep our NOTICE files up to date.

--kevan

Re: genesis + xbean release train

[Kevan Miller]

On Mar 7, 2013, at 1:56 PM, Mark Struberg strub...@yahoo.de wrote:

 Hi folks!
 
 If noone objects, then I gonna roll a genesis + xbean release tonight into a 
 single staging area.

Sounds good to me. 

--kevan

XBean Release?

[Kevan Miller]

Anybody able to work on releasing XBean? OpenEJB/TomEE is interested in seeing 
a release…

--kevan

[jira] [Commented] (GERONIMO-6138) JDBC 4 API is not supported

[Kevan Miller (JIRA)]

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

Kevan Miller commented on GERONIMO-6138:


For WAS CE support, you'll want to check with IBM.

However, this problem has been around for a while in Geronimo. We really should 
get this fixed. Any volunteers?

 JDBC 4 API is not supported 
 

 Key: GERONIMO-6138
 URL: https://issues.apache.org/jira/browse/GERONIMO-6138
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
Affects Versions: 3.0-M1, 3.0.0
Reporter: Arnaud MERGEY
 Fix For: 3.0.1


 I try to deploy an application that uses some JDBC 4 API like 
 java.sql.ResultSet.isClosed()
 This calls fails with following error
 java.lang.AbstractMethodError: 
 org.tranql.connector.jdbc.ResultSetHandle.isClosed()Z
 According to JEE 6 specifications, JDBC 4 API should be supported in Geronimo 
 3, and it seems not.

--
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-6429) CLONE - Problem with attribute manager

[Kevan Miller (JIRA)]

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

Kevan Miller commented on GERONIMO-6429:


The change that John mentions was in both our Geronimo 1.1 and 1.1.1 releases:

{code}
svn praise 
https://svn.apache.org/repos/asf/geronimo/server/tags/1.1.0/modules/system/src/java/org/apache/geronimo/system/configuration/LocalAttributeManager.java
{code}

{code}
svn diff 
https://svn.apache.org/repos/asf/geronimo/server/tags/1.1.0/modules/system/src/java/org/apache/geronimo/system/configuration/LocalAttributeManager.java
 
https://svn.apache.org/repos/asf/geronimo/server/tags/1.1.1/modules/system/src/java/org/apache/geronimo/system/configuration/LocalAttributeManager.java
{code}

Your build timestamp is much later than our 1.1 and 1.1.0 releases... And the 
line number from the exception text in your original comment does not exactly 
line up with the above source. So, I'm not sure what level of code you are 
running (and thus I'm not certain whether or not your build contains John's 
fix).




 CLONE - Problem with attribute manager
 --

 Key: GERONIMO-6429
 URL: https://issues.apache.org/jira/browse/GERONIMO-6429
 Project: Geronimo
  Issue Type: Bug
  Security Level: public(Regular issues) 
  Components: core
 Environment: 
 http://people.apache.org/~hogstrom/20060607/geronimo-jetty-j2ee-1.1-20060607.tar.gz
 Windows XP, cygwin
 Command line: java -jar bin/server.jar
 Free disk space: 3 Gb
Reporter: Amit S
Assignee: John Sisson
Priority: Critical

 gnodet@guillaumes /cygdrive/c/tmp/geronimo-1.1-20060607
 $ java -jar bin/server.jar
 Booting Geronimo Kernel (in Java 1.5.0_06)...
 Starting Geronimo Application Server v1.1-20060607
 [**   ] 30%  21s Starting 
 geronimo/system-database...20:32:49,484 ERROR [LocalAttributeManager] Error 
 saving attributes
 java.io.IOException: EXTREMELY CRITICAL!  Unable to move manageable 
 attributes working file to proper file name!  Configuration will revert to 
 defaults unless t
 his is manually corrected!  (could not rename 
 C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to 
 C:\tmp\geronimo-1.1-20060607\var\config\config.xml)
 at 
 org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449)
 at 
 org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618)
 at java.util.TimerThread.mainLoop(Unknown Source)
 at java.util.TimerThread.run(Unknown Source)
 [**   ] 84%  39s Starting 
 geronimo/webconsole-jett...20:33:07,890 ERROR [LocalAttributeManager] Error 
 saving attributes
 java.io.IOException: EXTREMELY CRITICAL!  Unable to move manageable 
 attributes working file to proper file name!  Configuration will revert to 
 defaults unless t
 his is manually corrected!  (could not rename 
 C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to 
 C:\tmp\geronimo-1.1-20060607\var\config\config.xml)
 at 
 org.apache.geronimo.system.configuration.LocalAttributeManager.save(LocalAttributeManager.java:449)
 at 
 org.apache.geronimo.system.configuration.LocalAttributeManager$2.run(LocalAttributeManager.java:618)
 at java.util.TimerThread.mainLoop(Unknown Source)
 at java.util.TimerThread.run(Unknown Source)
 [**] 100%  45s Startup complete
   Listening on Ports:
 1099 0.0.0.0 RMI Naming
 1527 0.0.0.0 Derby Connector
 4201 0.0.0.0 ActiveIO Connector EJB
 4242 0.0.0.0 Remote Login Listener
 8009 0.0.0.0 Jetty Connector AJP13
 8080 0.0.0.0 Jetty Connector HTTP
 8443 0.0.0.0 Jetty Connector HTTPS
  0.0.0.0 JMX Remoting Connector
61616 0.0.0.0 ActiveMQ Message Broker Connector
   Started Application Modules:
 EAR: geronimo/webconsole-jetty/1.1-20060607/car
 RAR: geronimo/activemq/1.1-20060607/car
 RAR: geronimo/system-database/1.1-20060607/car
 WAR: geronimo/remote-deploy-jetty/1.1-20060607/car
 WAR: geronimo/welcome-jetty/1.1-20060607/car
   Web Applications:
 http://guillaumes:8080/
 http://guillaumes:8080/console
 http://guillaumes:8080/console-standard
 http://guillaumes:8080/remote-deploy
 Geronimo Application Server started
 20:33:18,718 ERROR [LocalAttributeManager] Error saving attributes
 java.io.IOException: EXTREMELY CRITICAL!  Unable to move manageable 
 attributes working file to proper file name!  Configuration will revert to 
 defaults unless t
 his is manually corrected!  (could not rename 
 C:\tmp\geronimo-1.1-20060607\var\config\config.xml.working to 
 C:\tmp\geronimo-1.1-20060607\var\config\config.xml

Re: migration of web site to svnpubsub

[Kevan Miller]

On Jan 15, 2013, at 2:28 PM, Jarek Gawor jga...@gmail.com wrote:

 As you all probably noticed the svnpubsub area for the website has
 been setup. I've populated it with the static and wiki content. You
 should be able to kind of preview the site by opening
 https://svn.apache.org/repos/infra/websites/production/geronimo/content/index.html
 page in your browser. Some things like redirects might not work of
 course and there is a plenty of direct geronimo.apache.org links that
 might bring an old page. I'll also work on reducing some
 cwiki.apache.org links.
 
 Please do some sanity review (and update wiki if needed - I'll push
 updates manually later). I know that some non-english pages might be
 encoded wrong.
 
 Once we agree that the site is in a decent shape I'll ask infra to
 switch us over.

Hi Jarek,
It's looking pretty good to me. I didn't notice any problems. If anything, I 
noticed a few places where it looked like you had improved on the old site.

I'd give people a day or two to look things over. Once you're comfortable with 
things, I'd say feel free to pull the switch...

Thanks for all of this!

--kevan

Re: migration of web site to svnpubsub

[Kevan Miller]

On Jan 7, 2013, at 11:35 AM, Jarek Gawor jga...@gmail.com wrote:

 The svnpubsub dist area (item #1) for Geronimo is now setup - see [1].
 I populated it with the same artifacts that we had on
 /www/www.apache.org/dist/geronimo. Please review in case I missed
 something. I'll wait a day or so to let INFRA know to officially
 switch us over to this new way of publishing Geronimo distribution
 files.
 
 [1]: https://dist.apache.org/repos/dist/release/geronimo/

The only thing I noticed was that we're dropping the KEYS.xxx files (which are 
the historical versions of the KEYS file). I don't see a reason to carry these 
forward. So, I'm fine with that. That information should already be encoded in 
svn, anyway...

--kevan

Re: migration of web site to svnpubsub

[Kevan Miller]

On Jan 3, 2013, at 3:25 PM, Jarek Gawor jga...@gmail.com wrote:

 If there is no objections I'm going to start filing INFRA tickets to
 setup svnpubsub setup for Geronimo. Here's what I think we need:
 
 1) svnpubsub for Geronimo distributions. Basically, svnpubsub location
 such as https://dist.apache.org/repos/dist/release/geronimo which will
 be populated with the current contents of www.apache.org/dist/geronimo
 
 2) A buildbot setup that exports our wiki pages to svnpubsub location
 for our website (running periodically - e.g. nightly).
 
 3) svnpubsub location for our website that contains some static files
 such as javadocs, images, css, etc. Something like:
 https://svn.apache.org/repos/infra/websites/production/geronimo

Looks pretty reasonable to me. Though can't say that I've looked at any of this 
in any detail…

Thanks Jarek!

--kevan

Re: [spec] tab settings

[Kevan Miller]

On Jan 1, 2013, at 5:39 PM, Mark Struberg strub...@yahoo.de wrote:

 Hi!
 
 I found quite a few sources which have mixed tab/space policy. 
 
 In the JCDI packages I now switched all indenting back to spaces only. 
 
 To prevent such things I personally always enable the whitespace with a light 
 grey color.

Thanks. Spaces-only is the Geronimo coding standard 
(http://geronimo.apache.org/coding-standards.html#CodingStandards-Indentation). 
I personally hate tabs in source. So, appreciate your changes…

--kevan

Re: migration of web site to svnpubsub

[Kevan Miller]

On Dec 14, 2012, at 11:16 AM, Jarek Gawor jga...@gmail.com wrote:

 I think we need a short and long term solution. For the short term solution 
 let's try Dan's approach and see if that can work for us. Otherwise, we will 
 loose web site updates on the 1st. For the long term solution we can consider 
 switching to CMS or at least getting a clarification from the infra team if 
 we can continue to use the cwiki for the website. We do have a lot of pages 
 so switching to CMS might be challenging but we might have no choice (sooner 
 or later).

That sounds good to me.

--kevan

migration of web site to svnpubsub

[Kevan Miller]

All,
rsync-based updates of the geronimo web site will be frozen in January (very 
soon). We must migrate to svnpubsub (and optionally CMS) in order to have a 
website that we can change (seems like something we'd like to have).

For more information, see -- http://www.apache.org/dev/project-site.html

I'm going to have very limited time to do any work on this. Any volunteers?

--kevan

[ANNOUNCE] Welcome Mark Struberg as a new Geronimo committer

[Kevan Miller]

Everyone,
In recognition of his contributions to the Geronimo project, the Geronimo PMC 
has invited Mark Struberg to become a committer on our project. We are pleased 
to announce that he has accepted our invitation. 

Please join us in congratulating Mark. Welcome!

--kevan

Geronimo Plugins and Java 7

[Kevan Miller]

There have been several users reporting problems with installing Geronimo 
plugins while running with Java 7. Anybody able to investigate and provide a 
fix/work-around for our users? Clearly the current behavior is not good…

--kevan

Re: Geronimo Plugins and Java 7

[Kevan Miller]

On Dec 6, 2012, at 9:03 PM, Jerry Maine wrote:

 I had to install the plugins running on java 6 then turn around and run it 
 again with java 7.

Thanks. I was afraid of that… Hoping for something a bit better -- even 
permanent… ;-)

--kevan

Re: CDI-1.1 api

[Kevan Miller]

On Nov 27, 2012, at 8:42 AM, Mark Struberg wrote:

 Hi folks!
 
 We (OpenWebBeans) is starting to adopt CDI-1.1 and thus need to tweak and 
 document the CDI-1.1 API. 
 I'm one of the original main authors of the atinject and jcdi API packages 
 before they got moved over to geronimo/specs. I'm also on the CDI EG and OWB 
 PMC member. In other words: I know what to tweak ;)
 
 How should we proceed? Either you folks give me commit rights on the jcdi 
 modules or I will copy them back over to OWB so we are able to maintain them. 
 After the work is done we will move them back over here.
 
 wdyt?

Hi Mark,
I'd suggest you start working in geronimo/specs. If you can submit an 
incremental patch or two, that would be cool. 

Regardless, I expect that the minor obstacle can be remedied in relatively 
short order…

--kevan