Re: M2 migration status
The tomcat-builder is waiting! I will fix the mixed spacing in the axis-builder tomorrow. I would also like to remove the legacy apache-cvs repository from the parent pom. It is not needed anymore. Thanks Anita --- Jacek Laskowski <[EMAIL PROTECTED]> wrote: > 2006/3/17, Jacek Laskowski <[EMAIL PROTECTED]>: > > 2006/3/17, Prasad Kashyap > <[EMAIL PROTECTED]>: > > > Jacek, cancel your weekend plans. You have a > bunch of patches to apply > > > that will keep you busy all weekend :-) Just > kidding. > > > > Gonna apply the patches this weekend. I hope it > won't take the whole > > weekend, though ;) > > I think I have finished applying the patches. If > there're any left, > please speak up. I'll be around ;) > > Jacek > > -- > Jacek Laskowski > http://www.laskowski.org.pl > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (GERONIMO-1645) Module migration to Maven2: tomcat
[ http://issues.apache.org/jira/browse/GERONIMO-1645?page=comments#action_12370932 ] Anita Kulshreshtha commented on GERONIMO-1645: -- I am still getting LF endings on windows. Could you please set eol style to native. > Module migration to Maven2: tomcat > -- > > Key: GERONIMO-1645 > URL: http://issues.apache.org/jira/browse/GERONIMO-1645 > Project: Geronimo > Type: Sub-task > Components: Tomcat > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Anita Kulshreshtha > Attachments: maven-metadata-local.xml, part_fixes.patch, pom.patch, > pom.patch, pom.patch, pom.patch, pom.patch, pom.patch, pom.xml, pom.xml, > pom.xml, pom.xml, tomcat-tests.patch > > It's a task to help keep track of the progress of the tomcat module build > migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Supporting XBean services within the GBean kernel
On 3/17/06, Dain Sundstrom <[EMAIL PROTECTED]> wrote: > James, you always ask the hardest questions :) :) > On Mar 17, 2006, at 1:00 AM, James Strachan wrote: [snip] > The short answer is not without a lot of work and re-architecting of > the Geronimo kernel. My rough plan is to not do a full XBean > integration until Geronimo 2.0, but in the 1.x tree I would like to > continue to simplify and add more features from xbean. Specifically, > I would like to integrate the xbean-reflect package for building > attributes into Geronimo. This will allow us to build arbitrarily > complex attribute values which can contain references to other > GBeans. I have already added an optional flag to turn of proxing of > references between GBeans and hope to have that always on in Geronimo > 1.2. I doubt we will be able to add xbean-spring to Geronimo until 2.0. > > > Something like a GBean which boots up the XBean kernel and exposes > > all the registered services as GBeans would do the trick. It > > shouldn't be too hard right? > > Unfortunately, it just isn't the way Geronimo works. You're right, it probably is better to wait for 2.0; though I'm sure we can come up with some kind of solution for 1.x even if it is a bit crappy. e.g. previous GBean integrations of ActiveMQ were pretty much one crappy GBean that created all of the ActiveMQ POJOs and just registered a single GBean with Geronimo; so worst case I'm sure we can do something similar where we have a simple XBeanGBean that might create oodles of POJOs, but just exposes itself as a single GBean; I was secretly hoping we could do something a little better than that - but even that, I'd be OK with it as a tactical solution until the 2.0 goodness comes along. e.g. deploy any Spring/XBean XML config file as a single GBean would be pretty useful; even if its not that granular But certainly, 2.0 is where the fun's gonna start :) -- James --- http://radio.weblogs.com/0112098/
Re: M2 migration status
2006/3/17, Jacek Laskowski <[EMAIL PROTECTED]>: > 2006/3/17, Prasad Kashyap <[EMAIL PROTECTED]>: > > Jacek, cancel your weekend plans. You have a bunch of patches to apply > > that will keep you busy all weekend :-) Just kidding. > > Gonna apply the patches this weekend. I hope it won't take the whole > weekend, though ;) I think I have finished applying the patches. If there're any left, please speak up. I'll be around ;) Jacek -- Jacek Laskowski http://www.laskowski.org.pl
[jira] Updated: (GERONIMO-1723) Module migration to Maven2: axis-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1723?page=all ] Jacek Laskowski updated GERONIMO-1723: -- Summary: Module migration to Maven2: axis-builder (was: Module migration to Maven 2: axis-builder) > Module migration to Maven2: axis-builder > > > Key: GERONIMO-1723 > URL: http://issues.apache.org/jira/browse/GERONIMO-1723 > Project: Geronimo > Type: Sub-task > Components: webservices > Reporter: Jacek Laskowski > Assignee: Anita Kulshreshtha > Fix For: 1.x > Attachments: pom.patch > > It's a task to help keep track of the progress of the module build migration > to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1723) Module migration to Maven 2: axis-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1723?page=comments#action_12370929 ] Jacek Laskowski commented on GERONIMO-1723: --- Committed revision 386783. Thanks Anita! Some notes: * description was missing. Let's migrate as much as possible. * No need to specify packaging - jar is default * Spacing is mized - 2 and 4-spaces * dependency versions should not be specified in the subproject's pom where appropriate - they're inherited from the parent pom (we'll have to think how many dependencies put in the parent pom) * xmlbeans plugin created META-INF directory in the module itself - change that and the directory is created in target/classes (nb: take a look at the content of the directory - the property - project.build.directory - is not resolved properly) > Module migration to Maven 2: axis-builder > - > > Key: GERONIMO-1723 > URL: http://issues.apache.org/jira/browse/GERONIMO-1723 > Project: Geronimo > Type: Sub-task > Components: webservices > Reporter: Jacek Laskowski > Assignee: Anita Kulshreshtha > Fix For: 1.x > Attachments: pom.patch > > It's a task to help keep track of the progress of the module build migration > to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Clean build of Geronimo under m2
I hit a basic problem trying to do a clean build. The specs trunk works fine, but the main trunk dies at random intervals due to timeouts against the apache.org repositories (I think it's those). Anyone else having the same problem? Things are good if I turn those off (except for the various parts of Geronimo that are not built against released transitives - directory seemed to unfix itself, so the fix must have been overwritten somehow). Hen
[jira] Commented: (GERONIMO-1706) Module migration to Maven2: j2ee
[ http://issues.apache.org/jira/browse/GERONIMO-1706?page=comments#action_12370927 ] Jacek Laskowski commented on GERONIMO-1706: --- Committed revision 386779. Please verify it works and report. Anything left here? > Module migration to Maven2: j2ee > > > Key: GERONIMO-1706 > URL: http://issues.apache.org/jira/browse/GERONIMO-1706 > Project: Geronimo > Type: Sub-task > Components: buildsystem > Reporter: Anita Kulshreshtha > Assignee: Anita Kulshreshtha > Attachments: pom.xml, pruned-dep-j2ee.patch > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1727) Module migration to Maven2: connector
[ http://issues.apache.org/jira/browse/GERONIMO-1727?page=all ] Jacek Laskowski updated GERONIMO-1727: -- Summary: Module migration to Maven2: connector (was: Module migration to Maven 2: connector) > Module migration to Maven2: connector > - > > Key: GERONIMO-1727 > URL: http://issues.apache.org/jira/browse/GERONIMO-1727 > Project: Geronimo > Type: Sub-task > Components: connector > Versions: 1.x > Reporter: Jacek Laskowski > > It's a task to keep track of the progress of the module build migration to > Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1731) Module migration to Maven2: jetty
[ http://issues.apache.org/jira/browse/GERONIMO-1731?page=all ] Jacek Laskowski updated GERONIMO-1731: -- Summary: Module migration to Maven2: jetty (was: Module migration to Maven 2: jetty) > Module migration to Maven2: jetty > - > > Key: GERONIMO-1731 > URL: http://issues.apache.org/jira/browse/GERONIMO-1731 > Project: Geronimo > Type: Sub-task > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Prasad Kashyap > Attachments: jetty.patch > > It's a task to keep track of the progress of the module build migration to > Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1731) Module migration to Maven 2: jetty
[ http://issues.apache.org/jira/browse/GERONIMO-1731?page=comments#action_12370926 ] Jacek Laskowski commented on GERONIMO-1731: --- Committed revision 386778. Thanks Prasad! Some notes: * Changed description from 'Geronimo Jetty' to 'Geronimo Jetty Integration' as it was in project.xml * jettyVersion was set to 5.1.5rc2, but it should've been 5.1.10. I wonder how it worked for you? * Since it's a new m2-ized module the top-level module should be changed, too. Don't forget to rebuild the top-level project so that the change for Jetty version is taken into account, i.e. 'mvn -o -N install' in $GERONIMO_SOURCES_HOME > Module migration to Maven 2: jetty > -- > > Key: GERONIMO-1731 > URL: http://issues.apache.org/jira/browse/GERONIMO-1731 > Project: Geronimo > Type: Sub-task > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Prasad Kashyap > Attachments: jetty.patch > > It's a task to keep track of the progress of the module build migration to > Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1727) Module migration to Maven 2: connector
[ http://issues.apache.org/jira/browse/GERONIMO-1727?page=comments#action_12370925 ] Jacek Laskowski commented on GERONIMO-1727: --- No if they're unnecessary. If the tests pass and the module builds from the top-level as well as its own directory I don't think we should worry about it. My comment about the project.properties file was to bring out attention to it and upon testing decide what to do with it. Does it mean that the file is not required/used by M1, either? > Module migration to Maven 2: connector > -- > > Key: GERONIMO-1727 > URL: http://issues.apache.org/jira/browse/GERONIMO-1727 > Project: Geronimo > Type: Sub-task > Components: connector > Versions: 1.x > Reporter: Jacek Laskowski > > It's a task to keep track of the progress of the module build migration to > Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1645) Module migration to Maven2: tomcat
[ http://issues.apache.org/jira/browse/GERONIMO-1645?page=comments#action_12370923 ] Jacek Laskowski commented on GERONIMO-1645: --- Partially committed as revision 386775. Give it a try. Thanks Anita! > Module migration to Maven2: tomcat > -- > > Key: GERONIMO-1645 > URL: http://issues.apache.org/jira/browse/GERONIMO-1645 > Project: Geronimo > Type: Sub-task > Components: Tomcat > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Anita Kulshreshtha > Attachments: maven-metadata-local.xml, part_fixes.patch, pom.patch, > pom.patch, pom.patch, pom.patch, pom.patch, pom.patch, pom.xml, pom.xml, > pom.xml, pom.xml, tomcat-tests.patch > > It's a task to help keep track of the progress of the tomcat module build > migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: M2 migration status
On 3/17/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote:
> 2006/3/17, anita kulshreshtha <[EMAIL PROTECTED]>:
> > Good news.. I just added a line
> > ${basedir}
> > to surefire configuraiton for tomcat and built it
> > with
> > mvn -o -Dmodule=tomcat clean test
> >I think we can use this temporarily, until maven
> > guys decide to fix it.
>
> Excellent! I wish I could've helped a bit more, but I'm completely
> swamped with the M2 internals to see how it really works. The more I
> look at the sources, the more addicted to them I am ;) I think I'll
> give up for a while as I've got a huge backlog of M2 patches to apply.
> People may get nervous and step down, shouldn't they? ;)
>
> That's great to work with such highly dedicated and motivated people
> like you and Prasad who keep pace of the migration. Thanks!
+1; it's been fun trying to keep up with you both :)
Hen
[jira] Commented: (GERONIMO-1645) Module migration to Maven2: tomcat
[ http://issues.apache.org/jira/browse/GERONIMO-1645?page=comments#action_12370922 ] Jacek Laskowski commented on GERONIMO-1645: --- I'm unable to apply the patch, possibly because of the line endings changes. Could you make sure that the line endings are untouched before creating a patch? > Module migration to Maven2: tomcat > -- > > Key: GERONIMO-1645 > URL: http://issues.apache.org/jira/browse/GERONIMO-1645 > Project: Geronimo > Type: Sub-task > Components: Tomcat > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Anita Kulshreshtha > Attachments: maven-metadata-local.xml, part_fixes.patch, pom.patch, > pom.patch, pom.patch, pom.patch, pom.patch, pom.patch, pom.xml, pom.xml, > pom.xml, pom.xml, tomcat-tests.patch > > It's a task to help keep track of the progress of the tomcat module build > migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-629) test case SslTransportBrokerTest not working
[ http://jira.activemq.org/jira//browse/AMQ-629?page=all ] Adrian Co resolved AMQ-629: --- Resolution: Fixed Fix Version: (was: 4.1) 4.0 M5 Fixed by correcting the path to the keystore. > test case SslTransportBrokerTest not working > > > Key: AMQ-629 > URL: http://jira.activemq.org/jira//browse/AMQ-629 > Project: ActiveMQ > Type: Bug > Components: Test Cases > Reporter: james strachan > Assignee: Adrian Co > Fix For: 4.0 M5 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (GERONIMO-1713) Module migration to Maven2: j2ee-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1713?page=all ] Jacek Laskowski resolved GERONIMO-1713: --- Fix Version: 1.x Resolution: Fixed Committed revision 386771. Please verify and report. > Module migration to Maven2: j2ee-builder > > > Key: GERONIMO-1713 > URL: http://issues.apache.org/jira/browse/GERONIMO-1713 > Project: Geronimo > Type: Sub-task > Components: buildsystem > Reporter: Anita Kulshreshtha > Assignee: Prasad Kashyap > Fix For: 1.x > Attachments: j2ee-builder-apply-me.patch, j2ee-builder.patch, test-setup.zip > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1646) Module migration to Maven2: tomcat-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1646?page=all ] Anita Kulshreshtha updated GERONIMO-1646: - Attachment: pom.patch Please discard all the other patches. Added forkmode=once and set user.dir to basedir. > Module migration to Maven2: tomcat-builder > -- > > Key: GERONIMO-1646 > URL: http://issues.apache.org/jira/browse/GERONIMO-1646 > Project: Geronimo > Type: Sub-task > Components: Tomcat > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Anita Kulshreshtha > Attachments: pom.patch, pom.patch, pom.patch > > It's a task to help keep track of the progress of the tomcat-builder module > build migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1645) Module migration to Maven2: tomcat
[ http://issues.apache.org/jira/browse/GERONIMO-1645?page=all ] Anita Kulshreshtha updated GERONIMO-1645: - Attachment: pom.patch Please discard all the other patches. Added forkmode=once and set user.dir to basedir. > Module migration to Maven2: tomcat > -- > > Key: GERONIMO-1645 > URL: http://issues.apache.org/jira/browse/GERONIMO-1645 > Project: Geronimo > Type: Sub-task > Components: Tomcat > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Anita Kulshreshtha > Attachments: maven-metadata-local.xml, part_fixes.patch, pom.patch, > pom.patch, pom.patch, pom.patch, pom.patch, pom.patch, pom.xml, pom.xml, > pom.xml, pom.xml, tomcat-tests.patch > > It's a task to help keep track of the progress of the tomcat module build > migration to Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Restructuring top level pom.xml
Agreed, but that is easy enough to overcome with a few well placed properties. --jason On 3/17/06, David Blevins <[EMAIL PROTECTED]> wrote: > > On Mar 17, 2006, at 1:44 PM, Jason Dillon wrote: > > >> Really ? When I first cut my teeth with m2 working on itests, I > >> remember something like having to make the artifactid and directory > >> same. But if that is not the case, then great ! We can/should go > >> ahead > >> and create intermediate pom.xmls for the existing dir structure. > > > > They do not need to be the same. > > They don't have to be the same, but maven assumes they are. If you > deviate from that you have to do things like put a full scmUrl in > every pom because it can't be "inherited" correctly. Without an > valid scmUrl (among other things ) you can't hook an m2 project into > Continuum. > > Not a requirement, but I certainly don't want to be the one updating > scmUrls in 70 different poms each time we branch or tag :) > > -David > > > I do think that is is probably a good idea if they are the same, just > > so you know where to find the module that build some jar, but in some > > cases, with really nested structures it becomes more unmanageable to > > keep the directory name and the artifactId the same. > > > > --jason > > > >
[jira] Updated: (GERONIMO-1672) Module migration to Maven2: security
[ http://issues.apache.org/jira/browse/GERONIMO-1672?page=all ] Anita Kulshreshtha updated GERONIMO-1672: - Attachment: pom.patch please apply this and the m2-log4j.patch. This patch sets user.dir to basedir. > Module migration to Maven2: security > - > > Key: GERONIMO-1672 > URL: http://issues.apache.org/jira/browse/GERONIMO-1672 > Project: Geronimo > Type: Task > Components: security > Versions: 1.x > Environment: All > Reporter: Anita Kulshreshtha > Assignee: Anita Kulshreshtha > Fix For: 1.x > Attachments: m2-log4j.patch, pom.patch, pom.patch, pom.patch > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Restructuring top level pom.xml
On Mar 17, 2006, at 1:44 PM, Jason Dillon wrote: Really ? When I first cut my teeth with m2 working on itests, I remember something like having to make the artifactid and directory same. But if that is not the case, then great ! We can/should go ahead and create intermediate pom.xmls for the existing dir structure. They do not need to be the same. They don't have to be the same, but maven assumes they are. If you deviate from that you have to do things like put a full scmUrl in every pom because it can't be "inherited" correctly. Without an valid scmUrl (among other things ) you can't hook an m2 project into Continuum. Not a requirement, but I certainly don't want to be the one updating scmUrls in 70 different poms each time we branch or tag :) -David I do think that is is probably a good idea if they are the same, just so you know where to find the module that build some jar, but in some cases, with really nested structures it becomes more unmanageable to keep the directory name and the artifactId the same. --jason
Re: M2 migration status
Jacek,
THANKS! It was a pleasure to work on m2 migration
because of the quick turnaround time for the patches.
You had to keep up with so many patches and some time
add code without the patches!
Thnanks
Anita
--- Jacek Laskowski <[EMAIL PROTECTED]> wrote:
> 2006/3/17, anita kulshreshtha <[EMAIL PROTECTED]>:
> > Good news.. I just added a line
> > ${basedir}
> > to surefire configuraiton for tomcat and built it
> > with
> > mvn -o -Dmodule=tomcat clean test
> >I think we can use this temporarily, until
> maven
> > guys decide to fix it.
>
> Excellent! I wish I could've helped a bit more, but
> I'm completely
> swamped with the M2 internals to see how it really
> works. The more I
> look at the sources, the more addicted to them I am
> ;) I think I'll
> give up for a while as I've got a huge backlog of M2
> patches to apply.
> People may get nervous and step down, shouldn't
> they? ;)
?
>
> That's great to work with such highly dedicated and
> motivated people
> like you and Prasad who keep pace of the migration.
> Thanks!
>
> > Anita
>
> Jacek
>
> --
> Jacek Laskowski
> http://www.laskowski.org.pl
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: Restructuring top level pom.xml
> Would you then move all the code inside to the same package, as in > org.apache.geronimo.modules.kernel or > org.apache.geronimo.applications.daytrader? Package names do not need to relate directly to Maven groupIds. Especially not for intermediate grouping modules, that do not directly relate to code anyways. I do not recommend that package names be altered at this time. Once maven2 conversion is finished and it is time to rethink the general structure, it might be a good idea to try and sync up package names. I don't think that we ever want to have a org.apache.geronimo.modules.kernel... but perhaps a org.apache.geronimo.applications.daytrader. --jason
Re: Incubations
On Fri, 17 Mar 2006, Jason Dillon wrote: > Prior to escalation to the ASF, a Podling needs to show that : > > * it is a worthy and healthy project; > * it truly fits within the ASF framework;and > * it "gets" the Apache Way. > > > Part of the way is to resolve conflict with in the community. > lichtner's comment of "should pack up its code and move somewhere > else" is IMO sensationalism and is not helpful to the Geronimo > community, or to the incoming podling communities which we are trying > to resolve how best to integrate with our own. To someone who is "ASF or nothing" it was not helpful. To people whose first priority is the code, it could be helpful.
Re: Restructuring top level pom.xml
On Mar 17, 2006, at 2:18 PM, Alan D. Cabrera wrote: Jacek Laskowski wrote: 2006/3/17, Prasad Kashyap <[EMAIL PROTECTED]>: This will make our top level pom.xml a huge big list. Are we sure we want to keep it structured this way ? Hi Prasad, It looks that we're quickly approaching Dave's idea when he had envisioned the modules listed in one place would require a lot of effort to maintain. I personally don't think we have since lost the time as I couldn't see it the first time while having read Dave's email. Now, we're finally more experienced to get the gist of what he was saying ;) I'm for changing the parent pom to include only a few modules with a few more submodules rather than keeping them all in it. If it doesn't work we can always restructure it again ;) Any comments before the change appears? Maybe the members of the children POMs' group ids could be named: org.apache.geronimo.applications org.apache.geronimo.modules Etc. Would you then move all the code inside to the same package, as in org.apache.geronimo.modules.kernel or org.apache.geronimo.applications.daytrader? -David
Re: Events page on website
Good idea. Do you know know how to add this? -dain On Mar 17, 2006, at 11:58 AM, Hernan Cunico wrote: Absolutely, in addition to adding a link in the community table we could give it more visibility by adding a new tab on the top nav bar (right next to subprojects) Cheers! Hernan Dain Sundstrom wrote: I propose we add an events page to the community section of our website. This page would contain a calendar of all upcoming Geronimo related events (conferences, webcasts, parties, java user groups, hackathons etc.). For example, Aaron, James and I are doing a Geronimo webcast and Aaron, James, Jeff and I are all presenting at TSSS next week. I also think we should list the next few up coming events on the main page above the news sections. What do you think? -dain
Re: Restructuring top level pom.xml
> Maybe the members of the children POMs' group ids could be named: > > org.apache.geronimo.applications > org.apache.geronimo.modules That seems very reasonable to me. --jason
REPOST: Need site file renamed in svn to fix invalid file name on windows
Must have got lost in the email traffic. Original Message Subject:Need site file renamed in svn to fix invalid file name on windows Date: Thu, 16 Mar 2006 15:58:42 +1100 From: John Sisson <[EMAIL PROTECTED]> To: activemq-dev@geronimo.apache.org I get the following error during an svn update due to the Wiki page having an asterisk and question mark as part of the name: Error: Can't check path 'C:\dev\asf\incubator\activemq\site\How+do+I+deploy+activemq-ra-*.rar+to+weblogic?': The filename, directory name, or volume label syntax is incorrect. I have renamed the wiki page to "How to deploy activemq-ra-version.rar to weblogic" Can a committer please rename the svn file: activemq/site/How+do+I+deploy+activemq-ra-*.rar+to+weblogic? to: activemq/site/How+to+deploy+activemq-ra-*.rar+to+weblogic and regenerate the site so users on windows can check out the activemq site files. Thanks, John
Re: M2 migration status
2006/3/17, anita kulshreshtha <[EMAIL PROTECTED]>:
> Good news.. I just added a line
> ${basedir}
> to surefire configuraiton for tomcat and built it
> with
> mvn -o -Dmodule=tomcat clean test
>I think we can use this temporarily, until maven
> guys decide to fix it.
Excellent! I wish I could've helped a bit more, but I'm completely
swamped with the M2 internals to see how it really works. The more I
look at the sources, the more addicted to them I am ;) I think I'll
give up for a while as I've got a huge backlog of M2 patches to apply.
People may get nervous and step down, shouldn't they? ;)
That's great to work with such highly dedicated and motivated people
like you and Prasad who keep pace of the migration. Thanks!
> Anita
Jacek
--
Jacek Laskowski
http://www.laskowski.org.pl
Re: M2 migration status
2006/3/17, Prasad Kashyap <[EMAIL PROTECTED]>: > Jacek, cancel your weekend plans. You have a bunch of patches to apply > that will keep you busy all weekend :-) Just kidding. Gonna apply the patches this weekend. I hope it won't take the whole weekend, though ;) > Prasad Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: Restructuring top level pom.xml
Jacek Laskowski wrote: 2006/3/17, Prasad Kashyap <[EMAIL PROTECTED]>: This will make our top level pom.xml a huge big list. Are we sure we want to keep it structured this way ? Hi Prasad, It looks that we're quickly approaching Dave's idea when he had envisioned the modules listed in one place would require a lot of effort to maintain. I personally don't think we have since lost the time as I couldn't see it the first time while having read Dave's email. Now, we're finally more experienced to get the gist of what he was saying ;) I'm for changing the parent pom to include only a few modules with a few more submodules rather than keeping them all in it. If it doesn't work we can always restructure it again ;) Any comments before the change appears? Maybe the members of the children POMs' group ids could be named: org.apache.geronimo.applications org.apache.geronimo.modules Etc. Regards, Alan
[jira] Created: (AMQ-643) maxInactivityDuration does not seem to work properly
maxInactivityDuration does not seem to work properly Key: AMQ-643 URL: http://jira.activemq.org/jira//browse/AMQ-643 Project: ActiveMQ Type: Bug Components: Connector Versions: 4.0 M5 Environment: AMQ 4 03/17/2006 SNAPSHOT Solaris 8, 10 Reporter: Kevin Yaussy Fix For: 4.0 M5 AMQ 4 03/17/2006 SNAPSHOT Using maxInactivityDuration causes a connection to automatically break after the inactivity duration, even though nothing is wrong with either side of the connection. Tracing it through, it looks like the KeepAliveInfo command does not require a response. This means that the KeepAlive sent never results in receive activity. So, if both processes are perfectly fine, just not sending any data, the connection breaks due to InactivityMonitor.readCheck. I've changed KeepAliveInfo.java to return true for isResponseRequired. This seems to fix the problem, from a client perspective, anyway. However, if this is used for broker-to-broker connections, and you force a problem with one of the brokers (like doing pstop on Solaris), major problems will happen: 1) The broker that is left alone seems to break the connection. But, it continues to attempt to send messages to the failed broker. It was mentioned in the forum at one point you were going to have the broker unregister subscriptions so it would not attempt to send messages to the failed broker. Doesn't seem like this is in place. 2) If you reawaken the pstopped broker, the two brokers never really recover properly. Connections continue to get broken, over and over again. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Incubations
> Similiarly, if the primary criteria for graduation from incubation is > indoctrination into "The ASF Way", and not code or community maturity, this > is something that needs to be communicated. If the reverse is the case, > this needs to be communicated as well. See http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Exit+Requirements The first bits of that section state: Prior to escalation to the ASF, a Podling needs to show that : * it is a worthy and healthy project; * it truly fits within the ASF framework;and * it "gets" the Apache Way. Part of the way is to resolve conflict with in the community. lichtner's comment of "should pack up its code and move somewhere else" is IMO sensationalism and is not helpful to the Geronimo community, or to the incoming podling communities which we are trying to resolve how best to integrate with our own. --jason
Re: M2 migration status
Jacek, cancel your weekend plans. You have a bunch of patches to apply that will keep you busy all weekend :-) Just kidding. interop is the last module left to migrate. It's maven.xml defines a whole bunch of goals that I don't know who uses. Cheers Prasad On 3/17/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: > > > --- Prasad Kashyap <[EMAIL PROTECTED]> > wrote: > > > Inline - > > > > Cheers > > Prasad > > > > On 3/17/06, anita kulshreshtha <[EMAIL PROTECTED]> > > wrote: > > > Prasad, > > >While working on tomcat-builder I realised that > > if > > > I need a geronimo jar not yet converted to m2, I > > can > > > get it from maven1 repo by using the following > > groupId > > > geronimo > > > geronimo-security > > > > And the reason you are saying this is because .. ? > The geronimo-security.jar produced by > skipping the tests can not be trusted. It is used by > jetty. > > Thnaks > Anita > > > > > > ... > > > If this does not work, I will try your > > patch. > > > > Jetty passes all the tests but one test called the > > SecurityTest. It > > produces the same stacktrace that the failing tests > > in my security > > module produces. So I think it should work for you. > > > > > > > > I am still working on security. It works for me > > with > > > 1. cd modules/security and mvn clean test > > > > I can't get even this to work. > > > > I am skipping the security tests for now. Everything > > is fine. > > > > > __ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com >
Re: Restructuring top level pom.xml
> Really ? When I first cut my teeth with m2 working on itests, I > remember something like having to make the artifactid and directory > same. But if that is not the case, then great ! We can/should go ahead > and create intermediate pom.xmls for the existing dir structure. They do not need to be the same. I do think that is is probably a good idea if they are the same, just so you know where to find the module that build some jar, but in some cases, with really nested structures it becomes more unmanageable to keep the directory name and the artifactId the same. --jason
Re: Restructuring top level pom.xml
On 3/17/06, Jason Dillon <[EMAIL PROTECTED]> wrote: > IMO #2 is a nice to have... But is certainly not required to add intermediate > poms to group modules. > Really ? When I first cut my teeth with m2 working on itests, I remember something like having to make the artifactid and directory same. But if that is not the case, then great ! We can/should go ahead and create intermediate pom.xmls for the existing dir structure. > Once maven2ization is done, then I imagine than the entire project structure > should be reevaluated and ultimatly changed. Agree. We can look at changing the dir names then to keep it same as artifactids. > > --jason Cheers Prasad
Re: Restructuring top level pom.xml
IMO #2 is a nice to have... But is certainly not required to add intermediate poms to group modules. Once maven2ization is done, then I imagine than the entire project structure should be reevaluated and ultimatly changed. --jason -Original Message- From: "Prasad Kashyap" <[EMAIL PROTECTED]> Date: Fri, 17 Mar 2006 15:36:18 To:dev@geronimo.apache.org Subject: Re: Restructuring top level pom.xml Thank you David. - You wrote This means two things: 1. there needs to be modules/pom.xml which is the parent of everything in modules. Same goes for the other dirs, configs, assemblies, etc. The parent pom of modules/pom.xml would be the root pom.xml (if we want a root pom). 2. each child project must use it's artifactId as it's directory name. So 'kernel' becomes 'geronimo-kernel', etc. - Yep, this is what I was talking about. So I guess we'll have to wait till we are completely done with migrating to Maven2 before we do #2 above. That would be the safest thing to do given the ongoing maven 1 builds. Cheers Prasad On 3/17/06, David Blevins <[EMAIL PROTECTED]> wrote: > On Mar 17, 2006, at 10:32 AM, Prasad Kashyap wrote: > > > Our top level pom.xml lists all the modules that M2 must traverse to > > build them individually. We currently have around 40 modules specified > > in the list. We'll soon add some more and then move on to adding 53 > > configs, 16 applications, 7 plugins and some 6 assemblies (give or > > take a few more). > > > > This will make our top level pom.xml a huge big list. Are we sure we > > want to keep it structured this way ? > > > > What say we have add pom.xmls in the intermediate directories like > > modules, config, applications, assemblies, plugins etc. These would go > > forth and build the directories under them. This would kep our top > > level pom.xml easy to read. This would also mirror the tree structure > > that we currently have. > > > > Here are my thoughts on the subject: > > http://www.mail-archive.com/dev@geronimo.apache.org/msg18122.html > > -David > >
Re: Events page on website
2006/3/17, Dain Sundstrom <[EMAIL PROTECTED]>: > I propose we add an events page to the community section of our > website. This page would contain a calendar of all upcoming Geronimo > related events (conferences, webcasts, parties, java user groups, > hackathons etc.). For example, Aaron, James and I are doing a > Geronimo webcast and Aaron, James, Jeff and I are all presenting at > TSSS next week. I also think we should list the next few up coming > events on the main page above the news sections. > > What do you think? Whow, loads of events on their way! Awesome. +1 for the idea. > -dain Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: Restructuring top level pom.xml
2006/3/17, David Blevins <[EMAIL PROTECTED]>: > Here are my thoughts on the subject: > > http://www.mail-archive.com/dev@geronimo.apache.org/msg18122.html I still keep it in my archive as I couldn't fully get the gist of it the first time. It seems we're growing up ;) > -David Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: Events page on website
Good idea. :-) --jason -Original Message- From: Dain Sundstrom <[EMAIL PROTECTED]> Date: Fri, 17 Mar 2006 11:31:38 To:dev@geronimo.apache.org Subject: Events page on website I propose we add an events page to the community section of our website. This page would contain a calendar of all upcoming Geronimo related events (conferences, webcasts, parties, java user groups, hackathons etc.). For example, Aaron, James and I are doing a Geronimo webcast and Aaron, James, Jeff and I are all presenting at TSSS next week. I also think we should list the next few up coming events on the main page above the news sections. What do you think? -dain
Re: Restructuring top level pom.xml
2006/3/17, Prasad Kashyap <[EMAIL PROTECTED]>: > This will make our top level pom.xml a huge big list. Are we sure we > want to keep it structured this way ? Hi Prasad, It looks that we're quickly approaching Dave's idea when he had envisioned the modules listed in one place would require a lot of effort to maintain. I personally don't think we have since lost the time as I couldn't see it the first time while having read Dave's email. Now, we're finally more experienced to get the gist of what he was saying ;) I'm for changing the parent pom to include only a few modules with a few more submodules rather than keeping them all in it. If it doesn't work we can always restructure it again ;) Any comments before the change appears? I think the another issue that's quickly coming to the surface is the top-level resources that don't belong to any of submodules, i.e. etc and xdocs directories as well as *.txt files. Although xdocs should migrate to its own module, the rest will likely disappear since they're mostly for M1 purposes. > Prasad Jacek -- Jacek Laskowski http://www.laskowski.org.pl
Re: Restructuring top level pom.xml
pom.xmls in the intermediate directories would be good IMO. --jason -Original Message- From: "Prasad Kashyap" <[EMAIL PROTECTED]> Date: Fri, 17 Mar 2006 13:32:24 To:dev@geronimo.apache.org Subject: Restructuring top level pom.xml Our top level pom.xml lists all the modules that M2 must traverse to build them individually. We currently have around 40 modules specified in the list. We'll soon add some more and then move on to adding 53 configs, 16 applications, 7 plugins and some 6 assemblies (give or take a few more). This will make our top level pom.xml a huge big list. Are we sure we want to keep it structured this way ? What say we have add pom.xmls in the intermediate directories like modules, config, applications, assemblies, plugins etc. These would go forth and build the directories under them. This would kep our top level pom.xml easy to read. This would also mirror the tree structure that we currently have. Cheers Prasad
Re: Restructuring top level pom.xml
Thank you David. - You wrote This means two things: 1. there needs to be modules/pom.xml which is the parent of everything in modules. Same goes for the other dirs, configs, assemblies, etc. The parent pom of modules/pom.xml would be the root pom.xml (if we want a root pom). 2. each child project must use it's artifactId as it's directory name. So 'kernel' becomes 'geronimo-kernel', etc. - Yep, this is what I was talking about. So I guess we'll have to wait till we are completely done with migrating to Maven2 before we do #2 above. That would be the safest thing to do given the ongoing maven 1 builds. Cheers Prasad On 3/17/06, David Blevins <[EMAIL PROTECTED]> wrote: > On Mar 17, 2006, at 10:32 AM, Prasad Kashyap wrote: > > > Our top level pom.xml lists all the modules that M2 must traverse to > > build them individually. We currently have around 40 modules specified > > in the list. We'll soon add some more and then move on to adding 53 > > configs, 16 applications, 7 plugins and some 6 assemblies (give or > > take a few more). > > > > This will make our top level pom.xml a huge big list. Are we sure we > > want to keep it structured this way ? > > > > What say we have add pom.xmls in the intermediate directories like > > modules, config, applications, assemblies, plugins etc. These would go > > forth and build the directories under them. This would kep our top > > level pom.xml easy to read. This would also mirror the tree structure > > that we currently have. > > > > Here are my thoughts on the subject: > > http://www.mail-archive.com/dev@geronimo.apache.org/msg18122.html > > -David > >
Re: Incubations
I personally didn't find anything sensational about lichtner's e-mail. I think he raises a valid point. If the primary goal of Apache Geronimo is to develope a quality, open source J2EE offering as a means of advancing the interests of the ASF (whatever those may be), as opposed to an end in and of itself, this is something potential contributors have a right to know. Similiarly, if the primary criteria for graduation from incubation is indoctrination into "The ASF Way", and not code or community maturity, this is something that needs to be communicated. If the reverse is the case, this needs to be communicated as well. Ian It's better to be hated for who you are than loved for who you are not Ian D. Stewart Appl Dev Analyst-Advisory, DCS Automation JPMorganChase Global Technology Infrastructure Phone: (614) 244-2564 Pager: (888) 260-0078 David Blevins <[EMAIL PROTECTED]To: dev@geronimo.apache.org si.com> cc: Subject: Re: Incubations 03/17/2006 01:32 PM Please respond to dev Seriously, people. Let's refrain from sensational emails whose only point is to make things worse. We are all here cause we want to work together and make great communities, software and a better ASF. -David On Mar 17, 2006, at 10:23 AM, lichtner wrote: > > I wanted to see what this incubation problem is all about, so I took a > look at the web site http://incubator.apache.org/resolution.html . > > It says that the B.o.D. has determined that it's in "the best > interests of > the Foundation" to create this incubator PMC charged with "providing > guidance", to help products engender "their own collaborative > community", > and "educating" new developers. > > So you do not want to get incubated by Apache unless: > > - You care deeply about the Apache Foundation. > - You project needs "guidance." > - You need your project to have a "community." > > Philosophy eventually rises up to the surface. This resolution may > explain > why we are seeing so many emails about ActiveMQ graduating etc. > > The Apache Foundation is generous to provide resources to open-source > projects, but this is not an entirely selfless act. If your project > consists of one person, it does not qualify as a good ASF project > because > it doesn't have a "community", for example. If your project doesn't > believe in democracy then it's not a good ASF project. > > Personally, I would not get a project incubated to help ASF be all > it can > be. I don't necessarily care about ASF, I do care about the Apache > httpd > and the other projects which are hosted by ASF but which might as > well be > hosted somewhere else. > > I think that if Geronimo is at odds with ASF's idealistic, abstract > motivations it should pack up its code and move somewhere else > where it > can focus on coding. If they are only staying for the free services > then > perhaps IBM can donate those. > > Not to mention that the project is so big it could have its own > foundation ... >
[event] TheServerSide Java Symposium - March 23-25
Several of us will be presenting at TheServerSide Java Symposium in Vegas next week (http://javasymposium.techtarget.com/index.html). I've pulled together, what I think is a complete list of the Geronimo related sessions. If I missed one, please speak up. Thursday, March 23 -- Transforming Enterprise Java into an Enterprise Commodity Geir Magnusson Jr. 9:00 am - 9:50 am Java has gone from a media and technology darling to a watermark platform in the industry. As a result, products have changed from being daring adoptions to more commoditized acquisitions - where even application servers are being repackaged and tuned for specific deployments. Geir Magnusson Jr. will present 'Transforming Enterprise Java into a Commodity,' an in-depth address about what commoditization means for the Java platform and its implications for the vendor and the developer community. Open Source SOA Using POJOs James Strachan 10:00 am - 11:15 am This session will provide an overview of how folks should develop SOA applications so they can take advantage of various middleware technologies like JMS, RMI, WS, JBI, BPEL etc yet keep their code simple and POJO like and to deal with things like asynchronous messaging, ESBs and so forth showing examples using different Apache tools and frameworks. Friday, March 24 Apache Geronimo Prime-time Jeff Genender 11:30 am - 12:45 pm Apache Geronimo is the latest open source application server to achieve J2EE 1.4 certification, making it ready for prime time in the Enterprise. It is now a real contender in the open source application server market and offers a unique architecture making different open- source projects pluggable and capable of building customized stacks. This session will present an overview of Apache Geronimo, its architecture, its major open source components, how it works, and how to configure and use the application server. This session will cover Geronimo's different concepts such as the kernel, GBeans, deployment and different configurations, and running the application server. Saturday, March 25 -- J2EE Development with Apache Geronimo Aaron Mulder and Dain Sundstrom 2:30 pm - 3:45 pm Apache Geronimo is an open source, J2EE-certified application server, and this session introduces Geronimo from the perspective of a J2EE developer. Do you have experience developing J2EE applications, but no idea how to get started with Geronimo? Or perhaps not sure whether to go with Tomcat, JBoss, or Geronimo? We'll start with a brief comparison with other open source app servers. Then we'll get you up to speed with J2EE development for Geronimo, from the administration console, to configuring database pools, JMS destinations, and securityrealms, to writing deployment descriptors for Geronimo and using the included deployment tools. You'll learn everything you need to install and configure the server, port your applications, and deploy them on Geronimo. Service Oriented Architecture with JBI and ServiceMix Bruce Snyder 2:30 pm - 3:45 pm Service oriented architecture (SOA) has been around for years in many forms. But in recent years, Web Services standards are providing a much more solid definition. Web Services Definition Language (WSDL) is a protocol- and technology- independent standard used to describe Web Services and model interactions between endpoints and is a key technology within Web Services. Java Business Integration (JBI) provides a standards-based architecture for enterprise integration. JBI does not define a traditional application programming model. Instead, it embraces a service-oriented approach to structuring enterprise functions, where JBI components function as service providers and consumers. JBI models services produced and consumed by components using a WSDL- based messaging model. As developers, once we get past all of these definitions, how are we to develop applications using these concepts? This session will explain JBI and ServiceMix and how they all fit together to provide a full SOA platform for developing composite applications.
[event] Geronimo Webcast - March 22, 2006 at 2:00 PM EST
Free Registration: http://searchWebServices.com/r/0,,54047,00.htm?IBM When: March 22, 2006 at 2:00 PM EST (19:00 GMT) Speakers: Dain Sundstrom - Chief Architect, IBM Gluecode Aaron Mulder - Chief Technology Officer, Chariot Solutions. James Strachan - Chief Architect, LogicBlaze Summary: The Apache Software Foundation is an open community of developers and users dedicated to creating high quality software that leads the way in its field. During this first in a series of Webcasts on Apache Geronimo, key committers in the Apache Geronimo project will discuss the community process and the J2EE application server technology in Apache Geronimo. Wondering what everyone is talking about? Looking for cool technology that'll help you get your job done faster without having to wrestle with unintegrated technology? Then spend some time learning about Geronimo, the value of community, and why it's the right choice for you. Hint: Simple, easy to use technology, a truly innovative, open community based on meritocracy, supported by developers, users, and companies around the world.
[jira] Commented: (AMQ-632) TaskRunnerFactory from broker is not carried along to Broker-to-Broker connections
[ http://jira.activemq.org/jira//browse/AMQ-632?page=comments#action_35817 ] Kevin Yaussy commented on AMQ-632: -- James, The config settings on networkConnector works famously, as of the 3/17/2006 SNAPSHOT (it did not work against 3/15/2006 SNAPSHOT). So, just need the official change for the TaskRunnerFactory so that dispatchAsync between brokers actually takes place. > TaskRunnerFactory from broker is not carried along to Broker-to-Broker > connections > -- > > Key: AMQ-632 > URL: http://jira.activemq.org/jira//browse/AMQ-632 > Project: ActiveMQ > Type: Bug > Components: Broker > Versions: 4.0 M5 > Reporter: Kevin Yaussy > Fix For: 4.0 M5 > Attachments: VMTransportFactory.java > > > When trying to enable dispatchAsync for broker-to-broker connections (which, > since I've not found a way to configure demandForwardingBridge in the broker > XML, I had to hard code by setting the default value of dispatchAsync in > DemandForwardingBridge.java), I found that the TaskRunnerFactory from the > broker was not being carried through to the Network connections. > I'm not sure if the way I fixed it is fully acceptable or not, however the > attached VMTransportFactory.java seems to fix the issue. I changed > doCompositeConnect to call setTaskRunnerFactory on the newly created > TransportConnector. > The change is against SNAPSHOT 03/14/2006. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: Incubations
I agree. While opinions are valuable, when they are collected in emails like this they become dangerous and harmful. --jason On Mar 17, 2006, at 10:32 AM, David Blevins wrote: Seriously, people. Let's refrain from sensational emails whose only point is to make things worse. We are all here cause we want to work together and make great communities, software and a better ASF. -David On Mar 17, 2006, at 10:23 AM, lichtner wrote: I wanted to see what this incubation problem is all about, so I took a look at the web site http://incubator.apache.org/resolution.html . It says that the B.o.D. has determined that it's in "the best interests of the Foundation" to create this incubator PMC charged with "providing guidance", to help products engender "their own collaborative community", and "educating" new developers. So you do not want to get incubated by Apache unless: - You care deeply about the Apache Foundation. - You project needs "guidance." - You need your project to have a "community." Philosophy eventually rises up to the surface. This resolution may explain why we are seeing so many emails about ActiveMQ graduating etc. The Apache Foundation is generous to provide resources to open-source projects, but this is not an entirely selfless act. If your project consists of one person, it does not qualify as a good ASF project because it doesn't have a "community", for example. If your project doesn't believe in democracy then it's not a good ASF project. Personally, I would not get a project incubated to help ASF be all it can be. I don't necessarily care about ASF, I do care about the Apache httpd and the other projects which are hosted by ASF but which might as well be hosted somewhere else. I think that if Geronimo is at odds with ASF's idealistic, abstract motivations it should pack up its code and move somewhere else where it can focus on coding. If they are only staying for the free services then perhaps IBM can donate those. Not to mention that the project is so big it could have its own foundation ...
Re: Events page on website
Absolutely, in addition to adding a link in the community table we could give it more visibility by adding a new tab on the top nav bar (right next to subprojects) Cheers! Hernan Dain Sundstrom wrote: I propose we add an events page to the community section of our website. This page would contain a calendar of all upcoming Geronimo related events (conferences, webcasts, parties, java user groups, hackathons etc.). For example, Aaron, James and I are doing a Geronimo webcast and Aaron, James, Jeff and I are all presenting at TSSS next week. I also think we should list the next few up coming events on the main page above the news sections. What do you think? -dain
Re: Restructuring top level pom.xml
On Mar 17, 2006, at 10:32 AM, Prasad Kashyap wrote: Our top level pom.xml lists all the modules that M2 must traverse to build them individually. We currently have around 40 modules specified in the list. We'll soon add some more and then move on to adding 53 configs, 16 applications, 7 plugins and some 6 assemblies (give or take a few more). This will make our top level pom.xml a huge big list. Are we sure we want to keep it structured this way ? What say we have add pom.xmls in the intermediate directories like modules, config, applications, assemblies, plugins etc. These would go forth and build the directories under them. This would kep our top level pom.xml easy to read. This would also mirror the tree structure that we currently have. Here are my thoughts on the subject: http://www.mail-archive.com/dev@geronimo.apache.org/msg18122.html -David
Re: Events page on website
This sounds like a great idea. Perhaps "Events" can be added as a link under community? As more events arise and are posted, this would be a great way to build community involvement for the Geronimo project. It would be a helpful and organized way to locate Geronimo events. Glenn Dain Sundstrom wrote: I propose we add an events page to the community section of our website. This page would contain a calendar of all upcoming Geronimo related events (conferences, webcasts, parties, java user groups, hackathons etc.). For example, Aaron, James and I are doing a Geronimo webcast and Aaron, James, Jeff and I are all presenting at TSSS next week. I also think we should list the next few up coming events on the main page above the news sections. What do you think? -dain
[jira] Commented: (GERONIMO-1727) Module migration to Maven 2: connector
[
http://issues.apache.org/jira/browse/GERONIMO-1727?page=comments#action_12370872
]
Prasad Kashyap commented on GERONIMO-1727:
--
The connector module worked fine just the way it was (in the top down builds
too). Then I tried to "migrate" these properties into it
maven.junit.fork=true
maven.junit.jvmargs=-Djava.security.auth.login.config=src/test-data/data/login.config
-ea
by doing this -
maven-surefire-plugin
src/test-data/data/login.config
once
${basedir}
-enableassertions
Now it fails !!
Should we still try to migrate the project.properties ? :-)
> Module migration to Maven 2: connector
> --
>
> Key: GERONIMO-1727
> URL: http://issues.apache.org/jira/browse/GERONIMO-1727
> Project: Geronimo
> Type: Sub-task
> Components: connector
> Versions: 1.x
> Reporter: Jacek Laskowski
>
> It's a task to keep track of the progress of the module build migration to
> Maven2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Events page on website
I propose we add an events page to the community section of our website. This page would contain a calendar of all upcoming Geronimo related events (conferences, webcasts, parties, java user groups, hackathons etc.). For example, Aaron, James and I are doing a Geronimo webcast and Aaron, James, Jeff and I are all presenting at TSSS next week. I also think we should list the next few up coming events on the main page above the news sections. What do you think? -dain
[jira] Updated: (GERONIMO-1750) Unable to run tradeStreamerAppclient
[ http://issues.apache.org/jira/browse/GERONIMO-1750?page=all ] Lin Sun updated GERONIMO-1750: -- Description: I performed the following command: java -jar client.jar tradeStreamerAppclient then got the following exception: 09:37:12,203 INFO [Log4jService] -- 09:37:12,203 INFO [Log4jService] Started Logging Service 09:37:12,203 INFO [JvmVendor] IBM JVM detected from IBM Corporation 09:37:14,578 INFO [CommandLine] Server startup completed TradeStreamer getInitial Context 09:37:17,047 INFO [ActiveMQConnection] channel status changed: Channel: TcpTransportChannel: Socket[addr=localhost/127. 0.0.1,port=61616,localport=4290] has connected Caught an unexpected exception! java.lang.NullPointerException at javax.swing.ImageIcon.(ImageIcon.java:168) at org.apache.geronimo.samples.daytrader.client.TradeClientGUI.(TradeClientGUI.java:59) at org.apache.geronimo.samples.daytrader.client.TradeClient.startClient(TradeClient.java:81) at org.apache.geronimo.samples.daytrader.client.TradeClient.main(TradeClient.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at org.apache.geronimo.client.AppClientContainer.main(AppClientContainer.java:143) at org.apache.geronimo.client.AppClientContainer$$FastClassByCGLIB$$b5beae18.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.system.main.CommandLine.invokeMainGBean(CommandLine.java:90) at org.apache.geronimo.system.main.ClientCommandLine.(ClientCommandLine.java:71) at org.apache.geronimo.system.main.ClientCommandLine.main(ClientCommandLine.java:46) 09:37:21,328 INFO [CommandLine] Server shutdown begun 09:37:21,344 ERROR [GBeanInstance] GBeanInstance should already be stopped before die() is called: objectName=geronimo.c lient:J2EEApplication=client-application,J2EEServer=client,JCAResource=activemq/activemq-ra/3.2.2.ibm/rar,j2eeType=JCACo nnectionFactory,name=jms/TopicConnectionFactory state=starting 09:37:21,344 ERROR [GBeanInstance] GBeanInstance should already be stopped before die() is called: objectName=geronimo.c lient:J2EEApplication=client-application,J2EEServer=client,j2eeType=ResourceAdapterModule,name=activemq/activemq-ra/3.2. 2.ibm/rar state=starting 09:37:21,359 INFO [CommandLine] Client shutdown completed The reason caused this exception is that the client tries to load a picture file named "/images/tradeLogoSmall.gif", but can't find it. Here's an excerpt from TradeClientGUI.java: private static final String TRADELOGO_FILENAME = "/images/tradeLogoSmall.gif"; private static final String WEBSPHERELOGO_FILENAME = "/images/WEBSPHERE_18P_UNIX.GIF"; ... ImageIcon iconTrade = new ImageIcon(this.getClass().getResource(TRADELOGO_FILENAME)); ImageIcon iconWS = new ImageIcon(this.getClass().getResource(WEBSPHERELOGO_FILENAME)); The fix is to supply these two images logo images to geronimo\daytrader\streamer\src\images directory . I used the existing images (DayTraderHead_red.gif & GLogo_450x50.gif) from the web directory: private static final String TRADELOGO_FILENAME = "/images/DayTraderHead_red.gif"; private static final String GERONIMOLOGO_FILENAME = "/images/GLogo_450x50.gif"; ... ImageIcon iconTrade = new ImageIcon(this.getClass().getResource(TRADELOGO_FILENAME)); ImageIcon iconWS = new ImageIcon(this.getClass().getResource(GERONIMOLOGO_FILENAME)); And add the following to the geronimo\daytrader\streamer\project.xml file: (below the tag) src images/*.* was: I performed the following command: java -jar client.jar tradeStreamerAppclient then got the following exception: 09:37:12,203 INFO [Log4jService] -- 09:37:12,203 INFO [Log4jService] Started Logging Service 09:37:12,203 INFO [JvmVendor] IBM JVM detected from IBM Corporation 09:37:14,578 INFO [CommandLine] Server startup completed TradeStreamer getInitial Context 09:37:17,047 IN
[jira] Updated: (GERONIMO-1731) Module migration to Maven 2: jetty
[ http://issues.apache.org/jira/browse/GERONIMO-1731?page=all ] Prasad Kashyap updated GERONIMO-1731: - Attachment: jetty.patch Dependency list pruned. SecurityTest.java is failing for me. But that's just for me. Same problem like the Security module. Anita verified this patch and it passed for her. > Module migration to Maven 2: jetty > -- > > Key: GERONIMO-1731 > URL: http://issues.apache.org/jira/browse/GERONIMO-1731 > Project: Geronimo > Type: Sub-task > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Prasad Kashyap > Attachments: jetty.patch > > It's a task to keep track of the progress of the module build migration to > Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (GERONIMO-1750) Unable to run tradeStreamerAppclient
Unable to run tradeStreamerAppclient Key: GERONIMO-1750 URL: http://issues.apache.org/jira/browse/GERONIMO-1750 Project: Geronimo Type: Bug Components: sample apps Versions: 1.0 Environment: winXP, Reporter: Lin Sun Priority: Minor I performed the following command: java -jar client.jar tradeStreamerAppclient then got the following exception: 09:37:12,203 INFO [Log4jService] -- 09:37:12,203 INFO [Log4jService] Started Logging Service 09:37:12,203 INFO [JvmVendor] IBM JVM detected from IBM Corporation 09:37:14,578 INFO [CommandLine] Server startup completed TradeStreamer getInitial Context 09:37:17,047 INFO [ActiveMQConnection] channel status changed: Channel: TcpTransportChannel: Socket[addr=localhost/127. 0.0.1,port=61616,localport=4290] has connected Caught an unexpected exception! java.lang.NullPointerException at javax.swing.ImageIcon.(ImageIcon.java:168) at org.apache.geronimo.samples.daytrader.client.TradeClientGUI.(TradeClientGUI.java:59) at org.apache.geronimo.samples.daytrader.client.TradeClient.startClient(TradeClient.java:81) at org.apache.geronimo.samples.daytrader.client.TradeClient.main(TradeClient.java:63) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:85) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:58) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:60) at java.lang.reflect.Method.invoke(Method.java:391) at org.apache.geronimo.client.AppClientContainer.main(AppClientContainer.java:143) at org.apache.geronimo.client.AppClientContainer$$FastClassByCGLIB$$b5beae18.invoke() at net.sf.cglib.reflect.FastMethod.invoke(FastMethod.java:53) at org.apache.geronimo.gbean.runtime.FastMethodInvoker.invoke(FastMethodInvoker.java:38) at org.apache.geronimo.gbean.runtime.GBeanOperation.invoke(GBeanOperation.java:118) at org.apache.geronimo.gbean.runtime.GBeanInstance.invoke(GBeanInstance.java:835) at org.apache.geronimo.kernel.basic.BasicKernel.invoke(BasicKernel.java:178) at org.apache.geronimo.system.main.CommandLine.invokeMainGBean(CommandLine.java:90) at org.apache.geronimo.system.main.ClientCommandLine.(ClientCommandLine.java:71) at org.apache.geronimo.system.main.ClientCommandLine.main(ClientCommandLine.java:46) 09:37:21,328 INFO [CommandLine] Server shutdown begun 09:37:21,344 ERROR [GBeanInstance] GBeanInstance should already be stopped before die() is called: objectName=geronimo.c lient:J2EEApplication=client-application,J2EEServer=client,JCAResource=activemq/activemq-ra/3.2.2.ibm/rar,j2eeType=JCACo nnectionFactory,name=jms/TopicConnectionFactory state=starting 09:37:21,344 ERROR [GBeanInstance] GBeanInstance should already be stopped before die() is called: objectName=geronimo.c lient:J2EEApplication=client-application,J2EEServer=client,j2eeType=ResourceAdapterModule,name=activemq/activemq-ra/3.2. 2.ibm/rar state=starting 09:37:21,359 INFO [CommandLine] Client shutdown completed The reason caused this exception is that the client tries to load a picture file named "/images/tradeLogoSmall.gif", but can't find it. Here's an excerpt from TradeClientGUI.java: private static final String TRADELOGO_FILENAME = "/images/tradeLogoSmall.gif"; private static final String WEBSPHERELOGO_FILENAME = "/images/WEBSPHERE_18P_UNIX.GIF"; ... ImageIcon iconTrade = new ImageIcon(this.getClass().getResource(TRADELOGO_FILENAME)); ImageIcon iconWS = new ImageIcon(this.getClass().getResource(WEBSPHERELOGO_FILENAME)); The fix is to supply these two images logo images to geronimo\daytrader\streamer\src\images directory . I used the existing images (DayTraderHead_red.gif & GLogo_450x50.gif) from the web directory: private static final String TRADELOGO_FILENAME = "/images/DayTraderHead_red.gif"; private static final String GERONIMOLOGO_FILENAME = "/images/GLogo_450x50.gif"; ... ImageIcon iconTrade = new ImageIcon(this.getClass().getResource(TRADELOGO_FILENAME)); ImageIcon iconWS = new ImageIcon(this.getClass().getResource(GERONIMOLOGO_FILENAME)); And add the following in the -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (GERONIMO-1726) Module migration to Maven 2: common
[ http://issues.apache.org/jira/browse/GERONIMO-1726?page=comments#action_12370863 ] Prasad Kashyap commented on GERONIMO-1726: -- Jacek, I don't see any properties files in this module. Was that comment meant for some other module, maybe ? > Module migration to Maven 2: common > --- > > Key: GERONIMO-1726 > URL: http://issues.apache.org/jira/browse/GERONIMO-1726 > Project: Geronimo > Type: Sub-task > Components: common > Versions: 1.x > Reporter: Jacek Laskowski > > It's almost there. Properties are in incorrect dirs - should go to > src/properties (and eventually to src/main/properties) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Restructuring top level pom.xml
Our top level pom.xml lists all the modules that M2 must traverse to build them individually. We currently have around 40 modules specified in the list. We'll soon add some more and then move on to adding 53 configs, 16 applications, 7 plugins and some 6 assemblies (give or take a few more). This will make our top level pom.xml a huge big list. Are we sure we want to keep it structured this way ? What say we have add pom.xmls in the intermediate directories like modules, config, applications, assemblies, plugins etc. These would go forth and build the directories under them. This would kep our top level pom.xml easy to read. This would also mirror the tree structure that we currently have. Cheers Prasad
org.apache.geronimo.gbean.NoProxy=true
Forgot to mention, I added an experimental flag to 1.1 which will turn off proxying in GBean references. This means that the injected reference will be the actual service instance and not a proxy to the service. My guess is this will break a few services that use ProxyManager.getProxyTarget(Objcet), since the reference won't be a proxy. All of these uses will have be rewritten to not assume a proxy if we want to keep use this flag. To turn it on, you simply set the system property org.apache.geronimo.gbean.NoProxy=true. This is property is picked up by a static block in the AbstractGBeanReference class, so the property will apply for the life of the kernel class loader (normally the life of the vm). -dain
Re: Incubations
Seriously, people. Let's refrain from sensational emails whose only point is to make things worse. We are all here cause we want to work together and make great communities, software and a better ASF. -David On Mar 17, 2006, at 10:23 AM, lichtner wrote: I wanted to see what this incubation problem is all about, so I took a look at the web site http://incubator.apache.org/resolution.html . It says that the B.o.D. has determined that it's in "the best interests of the Foundation" to create this incubator PMC charged with "providing guidance", to help products engender "their own collaborative community", and "educating" new developers. So you do not want to get incubated by Apache unless: - You care deeply about the Apache Foundation. - You project needs "guidance." - You need your project to have a "community." Philosophy eventually rises up to the surface. This resolution may explain why we are seeing so many emails about ActiveMQ graduating etc. The Apache Foundation is generous to provide resources to open-source projects, but this is not an entirely selfless act. If your project consists of one person, it does not qualify as a good ASF project because it doesn't have a "community", for example. If your project doesn't believe in democracy then it's not a good ASF project. Personally, I would not get a project incubated to help ASF be all it can be. I don't necessarily care about ASF, I do care about the Apache httpd and the other projects which are hosted by ASF but which might as well be hosted somewhere else. I think that if Geronimo is at odds with ASF's idealistic, abstract motivations it should pack up its code and move somewhere else where it can focus on coding. If they are only staying for the free services then perhaps IBM can donate those. Not to mention that the project is so big it could have its own foundation ...
Incubations
I wanted to see what this incubation problem is all about, so I took a look at the web site http://incubator.apache.org/resolution.html . It says that the B.o.D. has determined that it's in "the best interests of the Foundation" to create this incubator PMC charged with "providing guidance", to help products engender "their own collaborative community", and "educating" new developers. So you do not want to get incubated by Apache unless: - You care deeply about the Apache Foundation. - You project needs "guidance." - You need your project to have a "community." Philosophy eventually rises up to the surface. This resolution may explain why we are seeing so many emails about ActiveMQ graduating etc. The Apache Foundation is generous to provide resources to open-source projects, but this is not an entirely selfless act. If your project consists of one person, it does not qualify as a good ASF project because it doesn't have a "community", for example. If your project doesn't believe in democracy then it's not a good ASF project. Personally, I would not get a project incubated to help ASF be all it can be. I don't necessarily care about ASF, I do care about the Apache httpd and the other projects which are hosted by ASF but which might as well be hosted somewhere else. I think that if Geronimo is at odds with ASF's idealistic, abstract motivations it should pack up its code and move somewhere else where it can focus on coding. If they are only staying for the free services then perhaps IBM can donate those. Not to mention that the project is so big it could have its own foundation ...
Re: Supporting XBean services within the GBean kernel
James, you always ask the hardest questions :) On Mar 17, 2006, at 1:00 AM, James Strachan wrote: I fell for the charms of XBean a long time ago; both ActiveMQ and ServiceMix have been using it as its primary configuration mechanism for some time. I recently XBean-ified Jetty too which took about an hour and can currently configure most of Jetty. Incidentally there's currently a real simple file system based deployer that can walk the file system building up classpath trees and booting up any XBean or Spring applications it finds. e.g. the following test repository boots up ActiveMQ fully configured via XBean. (This deployer could use some work to be able to deal with service and classpath dependencies, to allow graphs rather than just trees to be used) http://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-server/ src/test/repository/ The GBean integration of ActiveMQ has always been pretty simple and limited; I"ve always wanted full rich integration where every single transport connector, network connector, journal configuration, thread pool, queue, topic, connection & subscription are all richly available to the GBean kernel & management subsystem etc. We kinda have that today with a combination of XBean and JMX; but it doesn't really integrate yet with the GBean kernel. So I'm wondering if we can put together some kind of GBean facade to XBean; so the current kernel sees the XBean world as just a bunch of GBeans and anything which can deploy in XBean (which includes pretty much every Spring application on the planet) suddenly becomes available nicely into the GBean world. The short answer is not without a lot of work and re-architecting of the Geronimo kernel. My rough plan is to not do a full XBean integration until Geronimo 2.0, but in the 1.x tree I would like to continue to simplify and add more features from xbean. Specifically, I would like to integrate the xbean-reflect package for building attributes into Geronimo. This will allow us to build arbitrarily complex attribute values which can contain references to other GBeans. I have already added an optional flag to turn of proxing of references between GBeans and hope to have that always on in Geronimo 1.2. I doubt we will be able to add xbean-spring to Geronimo until 2.0. Something like a GBean which boots up the XBean kernel and exposes all the registered services as GBeans would do the trick. It shouldn't be too hard right? Unfortunately, it just isn't the way Geronimo works. A second question is; what to do about JMX. In ActiveMQ we've written a bunch of MBeans so whether you use ActiveMQ in J2SE or J2EE you can point JConsole at the JVM and see all the various stats, queue depths, buffer sizes and so forth. Some of these things are created at deployment time; though most of them come and go as clients connect to the broker and the brokers own runtime state changes e.g. deach connection & subscription has an MBean; clients can create new destinations at runtime etc. How would it be best to integrate those into the GBean infrastructure - or would it be best to just leave them in JMX and let the management portlets just use JMX to access them. I'm not sure on this one. -dain
[jira] Updated: (GERONIMO-1732) Module migration to Maven 2: jetty-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1732?page=all ] Prasad Kashyap updated GERONIMO-1732: - Attachment: jetty-builder.patch Module migrated. Dep list pruned. > Module migration to Maven 2: jetty-builder > -- > > Key: GERONIMO-1732 > URL: http://issues.apache.org/jira/browse/GERONIMO-1732 > Project: Geronimo > Type: Sub-task > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Prasad Kashyap > Attachments: jetty-builder.patch > > It's a task to keep track of the progress of the module build migration to > Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ActiveMQ Graduation From Incubator
There are some good ideas in here. Though I don't see Alan complaining. I do see that Alan did compiled a list (STATUS file), pointed to it, and sent the list out to people asking for feedback and discussion. Seems like a positive start. -David On Mar 17, 2006, at 9:33 AM, Leo Simons wrote: Alan, Incubation is something incubating communities have to do, and something incubating communities are responsible for. Those communities get some help and guidance from their mentors and the people on the [EMAIL PROTECTED] mailing list, but never enough since most of those people are volunteers with other things to do with their free time. (...) What is not fair is casting aside a few months of e-mail and face- to-face history of various people trying to help with this incubation thing, stamp your feet once every few weeks, and demand that people go and make a specific list of specific tasks you need to do. This is now the third time I've seen you do this and it is the third time I'm telling you this is not how it works. (...) Here's a list of things to do (subjectively, none of these are easy): * stop complaining. Right now. It is not fair. * compile your own list, try to make it as extensive as possible. mail-archives.apache.org is your friend, people have spent hundreds of hours writing hundreds of e-mails to explain this to you and to those that came before you. * send the list out to people (like [EMAIL PROTECTED]) for feedback and discussion. * work to address the list. * keep a record of this work. * point to the record (STATUS file). * spend time explaining concisely in a format processable by humans during a concall, what is in this record, what changed, etc, and send this in time when Noel asks for a report for the board meeting. * look back on this process and document what you learned so others can benefit from it. The idea that ActiveMQ as a community (not the software, I have no clue about the software) is ready to leave the incubator, is well, awkward. The very fact that there are long e-mail threads like this everytime I look at [EMAIL PROTECTED] should be enough indication that it is not. LSD On Wed, Mar 15, 2006 at 06:28:12PM -0800, Alan D. Cabrera wrote: Noel J. Bergman wrote: Alan D. Cabrera wrote: I only see infrastructure issues in your list of concerns that would prevent the graduation of ActiveMQ. Look again, but also at comments from Dims, Henri and others. At the moment, only Dims has taken the time to enumerate a list of concerns. Henri and the others have provided well thought out points on the definition of umbrella projects and whether AMQ should be a TLP or subproject; these not really being impediments to graduation but the necessary discourse about the final disposition of AMQ when it graduates that I was looking for when I initially sent out my email. You express an opinion that it should be a TLP but mention that it has a long way to go before it's ready for that. Can you enumerate what remains, aside from the infrastructure issues See my reply to Dain. And I do feel that some of it does come down to being able to convey a subjective confidence to the Incubator PMC that the community really does "get it" regarding ASF principles and practices. And that is supposed to happen before, not after, a community leaves the Incubator. There are a number of definitions for the word "subjective". If subjective means that your concerns may be peculiar to yourself, can you not explicitly state what you'd like to see? If you are unable to communicate what those are, we may not unable to address them. Is that fair to the AMQ community? If AMQ has less inspiring aspirations and was to initially land as a sub-project I am not sure how much difference there ought to be, but some of that comes down to the landing PMC. I do have a concern an issue of fairness. Consider David Blevin's well-stated views, including "We've more or less been running as TLPs [for] the past two plus years already." So if we have some community that has been autonomous, and it becomes part of another TLP within the ASF, how fair would it be for the members of that community to lose their decision making ability? I would say not, so are they going to be made part of the destination PMC, which would be required for them to have binding votes? This is a generic issue. I would have to cross-reference in detail the PMC and committer lists for ActiveMQ and Geronimo to be specific to this case. I do realize that there is overlap, but also others who are part of ActiveMQ and are not part of Geronimo. Is Geronimo prepared to welcome them as Committers on the Geronimo TLP and members of the Geronimo PMC? Related comment will go as a reply to David Blevins. If I take away the list of infrastructure issues, I only see the need to have a thorough discussion as to where
[jira] Deleted: (AMQ-598) test
[ http://jira.activemq.org/jira//browse/AMQ-598?page=all ] james strachan deleted AMQ-598: --- > test > > > Key: AMQ-598 > URL: http://jira.activemq.org/jira//browse/AMQ-598 > Project: ActiveMQ > Type: Bug > Reporter: Hiram Chirino > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ActiveMQ Graduation From Incubator
Leo, Many of the folks in the ActiveMQ project already have been through the incubation process once before when we put Geronimo though. It's not like this is our first rodeo. So in our eyes we really do think we are very close to having satisfied the incubation requirements. I think Alan was opening up the discussion to get constructive feed back on what people feel is missing. For example, you have an opinion that "The idea that ActiveMQ as a community is ready to leave the incubator, is well, awkward." You are aware that this was a community that was started by Apache committers and run very much in the Apache meritocratic style when it was the codehaus right? So in sort, it would be nice for you to explain this opinion a little more. Regards, Hiram On 3/17/06, Leo Simons <[EMAIL PROTECTED]> wrote: > Alan, > > Incubation is something incubating communities have to do, and something > incubating communities are responsible for. Those communities get some > help and guidance from their mentors and the people on the > [EMAIL PROTECTED] mailing list, but never enough since most of those people > are volunteers with other things to do with their free time. > > (...) > > What is not fair is casting aside a few months of e-mail and face-to-face > history of various people trying to help with this incubation thing, stamp > your feet once every few weeks, and demand that people go and make a > specific list of specific tasks you need to do. This is now the third time > I've seen you do this and it is the third time I'm telling you this is not > how it works. > > (...) > > Here's a list of things to do (subjectively, none of these are easy): > > * stop complaining. Right now. It is not fair. > > * compile your own list, try to make it as extensive as possible. >mail-archives.apache.org is your friend, people have spent hundreds >of hours writing hundreds of e-mails to explain this to you and to >those that came before you. > > * send the list out to people (like [EMAIL PROTECTED]) for feedback >and discussion. > > * work to address the list. > > * keep a record of this work. > > * point to the record (STATUS file). > > * spend time explaining concisely in a format processable by humans >during a concall, what is in this record, what changed, etc, and >send this in time when Noel asks for a report for the board meeting. > > * look back on this process and document what you learned so others >can benefit from it. > > The idea that ActiveMQ as a community (not the software, I have no > clue about the software) is ready to leave the incubator, is well, > awkward. The very fact that there are long e-mail threads like this > everytime I look at [EMAIL PROTECTED] should be enough indication that > it is not. > > LSD > > On Wed, Mar 15, 2006 at 06:28:12PM -0800, Alan D. Cabrera wrote: > > Noel J. Bergman wrote: > > >Alan D. Cabrera wrote: > > > > > > > > >>I only see infrastructure issues in your list of concerns > > >>that would prevent the graduation of ActiveMQ. > > >> > > > > > >Look again, but also at comments from Dims, Henri and others. > > > > > > > At the moment, only Dims has taken the time to enumerate a list of > > concerns. Henri and the others have provided well thought out points on > > the definition of umbrella projects and whether AMQ should be a TLP or > > subproject; these not really being impediments to graduation but the > > necessary discourse about the final disposition of AMQ when it graduates > > that I was looking for when I initially sent out my email. > > > > >>You express an opinion that it should be a TLP but mention that it has a > > >>long way to go before it's ready for that. Can you enumerate what > > >>remains, aside from the infrastructure issues > > >> > > > > > >See my reply to Dain. And I do feel that some of it does come down to > > >being > > >able to convey a subjective confidence to the Incubator PMC that the > > >community really does "get it" regarding ASF principles and practices. And > > >that is supposed to happen before, not after, a community leaves the > > >Incubator. > > > > > > > There are a number of definitions for the word "subjective". If > > subjective means that your concerns may be peculiar to yourself, can you > > not explicitly state what you'd like to see? If you are unable to > > communicate what those are, we may not unable to address them. Is that > > fair to the AMQ community? > > > > >>If AMQ has less inspiring aspirations and was to initially land > > >>as a sub-project > > >> > > > > > >I am not sure how much difference there ought to be, but some of that comes > > >down to the landing PMC. I do have a concern an issue of fairness. > > > > > >Consider David Blevin's well-stated views, including "We've more or less > > >been running as TLPs [for] the past two plus years already." So if we have > > >some community that has been autonomous, and it becomes part of another TLP > > >within the ASF, how f
Re: M2 migration status
--- Prasad Kashyap <[EMAIL PROTECTED]> wrote: > Inline - > > Cheers > Prasad > > On 3/17/06, anita kulshreshtha <[EMAIL PROTECTED]> > wrote: > > Prasad, > >While working on tomcat-builder I realised that > if > > I need a geronimo jar not yet converted to m2, I > can > > get it from maven1 repo by using the following > groupId > > geronimo > > geronimo-security > > And the reason you are saying this is because .. ? The geronimo-security.jar produced by skipping the tests can not be trusted. It is used by jetty. Thnaks Anita > > > ... > > If this does not work, I will try your > patch. > > Jetty passes all the tests but one test called the > SecurityTest. It > produces the same stacktrace that the failing tests > in my security > module produces. So I think it should work for you. > > > > > I am still working on security. It works for me > with > > 1. cd modules/security and mvn clean test > > I can't get even this to work. > > I am skipping the security tests for now. Everything > is fine. > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
[jira] Commented: (AMQ-639) Broker is not re-connecting to a network of brokers after going down and then being brought back up
[ http://jira.activemq.org/jira//browse/AMQ-639?page=comments#action_35815 ] james strachan commented on AMQ-639: (BTW that issue was fixed in the last hour or so in SVN) > Broker is not re-connecting to a network of brokers after going down and then > being brought back up > --- > > Key: AMQ-639 > URL: http://jira.activemq.org/jira//browse/AMQ-639 > Project: ActiveMQ > Type: Bug > Components: Broker > Versions: 4.0 M4 > Reporter: Brian Diesenhaus > Priority: Critical > Fix For: 4.0 M5 > > > I have set up a network of brokers with the following configuration: > http://activemq.org/config/1.0";> >class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/> > >managementContext="#mc"> > > > > > > > > > > > > >discoveryUri="multicast://bfe2"/> > > > > > > > > > > > > > > > I then run a series of tests (producing and consuming on the network of > brokers). Then I shut one broker down and then start it up again it can't > see the other brokers in the network but the other brokers can see it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-639) Broker is not re-connecting to a network of brokers after going down and then being brought back up
[ http://jira.activemq.org/jira//browse/AMQ-639?page=comments#action_35814 ] james strachan commented on AMQ-639: BTW I wonder if the exception you are getting is related to this fix... http://jira.activemq.org/jira/browse/AMQ-600 which was causing InvalidClientIDException to be thrown when network errors occur by handling the IOException in the wrong way > Broker is not re-connecting to a network of brokers after going down and then > being brought back up > --- > > Key: AMQ-639 > URL: http://jira.activemq.org/jira//browse/AMQ-639 > Project: ActiveMQ > Type: Bug > Components: Broker > Versions: 4.0 M4 > Reporter: Brian Diesenhaus > Priority: Critical > Fix For: 4.0 M5 > > > I have set up a network of brokers with the following configuration: > http://activemq.org/config/1.0";> >class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/> > >managementContext="#mc"> > > > > > > > > > > > > >discoveryUri="multicast://bfe2"/> > > > > > > > > > > > > > > > I then run a series of tests (producing and consuming on the network of > brokers). Then I shut one broker down and then start it up again it can't > see the other brokers in the network but the other brokers can see it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (GERONIMO-1706) Module migration to Maven2: j2ee
[ http://issues.apache.org/jira/browse/GERONIMO-1706?page=all ] Prasad Kashyap updated GERONIMO-1706: - Attachment: pruned-dep-j2ee.patch Pruned dependencies list > Module migration to Maven2: j2ee > > > Key: GERONIMO-1706 > URL: http://issues.apache.org/jira/browse/GERONIMO-1706 > Project: Geronimo > Type: Sub-task > Components: buildsystem > Reporter: Anita Kulshreshtha > Assignee: Anita Kulshreshtha > Attachments: pom.xml, pruned-dep-j2ee.patch > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: ActiveMQ Graduation From Incubator
Alan, Incubation is something incubating communities have to do, and something incubating communities are responsible for. Those communities get some help and guidance from their mentors and the people on the [EMAIL PROTECTED] mailing list, but never enough since most of those people are volunteers with other things to do with their free time. (...) What is not fair is casting aside a few months of e-mail and face-to-face history of various people trying to help with this incubation thing, stamp your feet once every few weeks, and demand that people go and make a specific list of specific tasks you need to do. This is now the third time I've seen you do this and it is the third time I'm telling you this is not how it works. (...) Here's a list of things to do (subjectively, none of these are easy): * stop complaining. Right now. It is not fair. * compile your own list, try to make it as extensive as possible. mail-archives.apache.org is your friend, people have spent hundreds of hours writing hundreds of e-mails to explain this to you and to those that came before you. * send the list out to people (like [EMAIL PROTECTED]) for feedback and discussion. * work to address the list. * keep a record of this work. * point to the record (STATUS file). * spend time explaining concisely in a format processable by humans during a concall, what is in this record, what changed, etc, and send this in time when Noel asks for a report for the board meeting. * look back on this process and document what you learned so others can benefit from it. The idea that ActiveMQ as a community (not the software, I have no clue about the software) is ready to leave the incubator, is well, awkward. The very fact that there are long e-mail threads like this everytime I look at [EMAIL PROTECTED] should be enough indication that it is not. LSD On Wed, Mar 15, 2006 at 06:28:12PM -0800, Alan D. Cabrera wrote: > Noel J. Bergman wrote: > >Alan D. Cabrera wrote: > > > > > >>I only see infrastructure issues in your list of concerns > >>that would prevent the graduation of ActiveMQ. > >> > > > >Look again, but also at comments from Dims, Henri and others. > > > > At the moment, only Dims has taken the time to enumerate a list of > concerns. Henri and the others have provided well thought out points on > the definition of umbrella projects and whether AMQ should be a TLP or > subproject; these not really being impediments to graduation but the > necessary discourse about the final disposition of AMQ when it graduates > that I was looking for when I initially sent out my email. > > >>You express an opinion that it should be a TLP but mention that it has a > >>long way to go before it's ready for that. Can you enumerate what > >>remains, aside from the infrastructure issues > >> > > > >See my reply to Dain. And I do feel that some of it does come down to > >being > >able to convey a subjective confidence to the Incubator PMC that the > >community really does "get it" regarding ASF principles and practices. And > >that is supposed to happen before, not after, a community leaves the > >Incubator. > > > > There are a number of definitions for the word "subjective". If > subjective means that your concerns may be peculiar to yourself, can you > not explicitly state what you'd like to see? If you are unable to > communicate what those are, we may not unable to address them. Is that > fair to the AMQ community? > > >>If AMQ has less inspiring aspirations and was to initially land > >>as a sub-project > >> > > > >I am not sure how much difference there ought to be, but some of that comes > >down to the landing PMC. I do have a concern an issue of fairness. > > > >Consider David Blevin's well-stated views, including "We've more or less > >been running as TLPs [for] the past two plus years already." So if we have > >some community that has been autonomous, and it becomes part of another TLP > >within the ASF, how fair would it be for the members of that community to > >lose their decision making ability? I would say not, so are they going to > >be made part of the destination PMC, which would be required for them to > >have binding votes? > > > >This is a generic issue. I would have to cross-reference in detail the PMC > >and committer lists for ActiveMQ and Geronimo to be specific to this case. > >I do realize that there is overlap, but also others who are part of > >ActiveMQ > >and are not part of Geronimo. Is Geronimo prepared to welcome them as > >Committers on the Geronimo TLP and members of the Geronimo PMC? > > > >Related comment will go as a reply to David Blevins. > > > > > > If I take away the list of infrastructure issues, I only see the need to > have a thorough discussion as to where AMQ will land when it graduates. > Once this settles down and we, hopefully, reach a consensus we will be > ready to vote, imho. > > > > Regards, > Alan > >
[jira] Resolved: (AMQ-573) add ability to redelivery messages that have been sent to a DLQ to the original queue
[ http://jira.activemq.org/jira//browse/AMQ-573?page=all ] Hiram Chirino resolved AMQ-573: --- Resolution: Fixed Fix Version: (was: 4.1) 4.0 M5 The JMX QueueView now has a copy and delete methods that can be used to do the requested task > add ability to redelivery messages that have been sent to a DLQ to the > original queue > - > > Key: AMQ-573 > URL: http://jira.activemq.org/jira//browse/AMQ-573 > Project: ActiveMQ > Type: New Feature > Reporter: james strachan > Assignee: Hiram Chirino > Fix For: 4.0 M5 > > > can we know from a message on a DLQ where it should go - if so some method > like... > redeliverFromDLQ() > would do the trick (which would be a no-op for non-DLQs) > or failing that a method > moveToQueue(String destination name) > moveToTopic(String destination name) > which works like purge, but moves to a new destination rather than deleting -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-533) Unable to create ACTIVEMQ_ACK table
[ http://jira.activemq.org/jira//browse/AMQ-533?page=all ] Hiram Chirino resolved AMQ-533: --- Resolution: Fixed Fix Version: 4.0 M5 > Unable to create ACTIVEMQ_ACK table > --- > > Key: AMQ-533 > URL: http://jira.activemq.org/jira//browse/AMQ-533 > Project: ActiveMQ > Type: Bug > Components: Message Store > Versions: 3.2.2 > Environment: MySQL 4.1.11 (InnoDB engine, UTF-8 default characterset), MySQL > 3.1.8 connector/J, Java 1.5.0_06, Windows XP SP2, ActiveMQ 3.2.2 > Reporter: N W > Priority: Blocker > Fix For: 4.0 M5 > > > I received the following error when trying to run ActiveMQ for the first time > in the above environment: > "Specified key was too long; max key length is 1024 bytes..." > when ActiveMQ tries to create the ACTIVEMQ_ACKS table. It looks like the pk > for that table involves two columns which are defined in > DefaultStatementProvider.java as being VARCHAR(250)s. In in UTF-8 > characterset each char is composed of 3 bytes such that in this case the pk > will be 1500 bytes which exceeds the max length for a InnoDB primary key. > Is there a spec. which stipulates that containernameDataType and > subscriptionIdDataType should be VARCHAR(250)? Could these be changed to say > VARCHAR(128) or some such so that the pk on that table will fall within the > 1024 byte limit? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-465) deadlock when using VM transport and Jencks...
[ http://jira.activemq.org/jira//browse/AMQ-465?page=all ] Hiram Chirino resolved AMQ-465: --- Resolution: Fixed Fix Version: (was: 4.1) 4.0 M5 > deadlock when using VM transport and Jencks... > -- > > Key: AMQ-465 > URL: http://jira.activemq.org/jira//browse/AMQ-465 > Project: ActiveMQ > Type: Bug > Versions: 4.0 M4 > Reporter: james strachan > Assignee: Hiram Chirino > Fix For: 4.0 M5 > > > Background here: http://forums.logicblaze.com/posts/list/146.page > It seems to be VM protocol specific -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[VOTE] create 4.0-RC1 release of ActiveMQ
The 4.0 release of ActiveMQ is long overdue; since we started incubation we've got out of the good habit of releasing early and releasing often. So I'd like us to get back on track making frequent releases even though we are still in the incubator (we can work on the community building and infrastructure issues in parallel to getting good releases out that people can use & give us feedback on). So I'd like us to create a release candidate (4.0-RC1) of what 4.0 will be so we can iron out any gremlins before the full 4.0 release. I've put a Release Plan together on the wiki http://docs.codehaus.org/display/ACTIVEMQ/Release+Plans in particular http://docs.codehaus.org/display/ACTIVEMQ/4.0+RC+1+Guide So please can you vote on whether to go ahead and start making this release. When the binary distro is done, we'll have another vote to approve the distro - then ask for the Incubator PMC's blessing to actually ship the release. [ ] +1 create the 4.0-RC1 distribution [ ] -1 veto the creation of the distro because: .. Here's my +1 -- James --- http://radio.weblogs.com/0112098/
unit test failures
Hi, community! I experiment with running Geronimo on various JVM's. The interesting thing I've encountered is that some of unit tests fail on BEA Jrockit VM. I've got at least three failures unique to BEA Jrockit 1.4.2_04 VM: Module: modules/directoryTest: org.apache.geronimo.directory.RunningTest Result: VM hangs Module: modules/timerTest: org.apache.geronimo.timer.NontransactionalThreadPooledTimerTest.testTasksInUnspecifiedTxContextOutput: expected:<20> but was:<19> Module: modules/tomcatTest: org.apache.geronimo.tomcat.JAASSecurityTest.testNotAuthorizedOutput: expected:<> but was: These tests pass on all Sun VMs. Situation with Jrockit 1.5 is much worse - more than 60 failures. It may result in overall instability while running Geronimo on BEA.Any comments & suggestions? Alexei Zakharov,Intel Middleware Product Division
Re: M2 migration status
Inline - Cheers Prasad On 3/17/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote: > Prasad, >While working on tomcat-builder I realised that if > I need a geronimo jar not yet converted to m2, I can > get it from maven1 repo by using the following groupId > geronimo > geronimo-security And the reason you are saying this is because .. ? > ... > If this does not work, I will try your patch. Jetty passes all the tests but one test called the SecurityTest. It produces the same stacktrace that the failing tests in my security module produces. So I think it should work for you. > > I am still working on security. It works for me with > 1. cd modules/security and mvn clean test I can't get even this to work. I am skipping the security tests for now. Everything is fine.
[jira] Commented: (AMQ-639) Broker is not re-connecting to a network of brokers after going down and then being brought back up
[ http://jira.activemq.org/jira//browse/AMQ-639?page=comments#action_35812 ] Brian Diesenhaus commented on AMQ-639: -- I did some testing this morning and here is what I found: 1. The broker is re-connecting. Looking at the connection in the JMX console all the brokers can see each other. This was not the case before. 2. The brokers that were not brought down are throwing the below exception when the broker re-connects. 3. Running the test again after the broker comes up only about 1/3 of the message make it to the broker that was brought back up and then it . INFO: Async error occurred: javax.jms.InvalidClientIDException: Broker: bfe-grieg - Client: NC_bfe-holst_inboundbfe-grieg already connected javax.jms.InvalidClientIDException: Broker: bfe-grieg - Client: NC_bfe-holst_inboundbfe-grieg already connected at org.apache.activemq.broker.region.RegionBroker.addConnection(RegionBroker.java:151) at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:64) at org.apache.activemq.advisory.AdvisoryBroker.addConnection(AdvisoryBroker.java:67) at org.apache.activemq.broker.BrokerFilter.addConnection(BrokerFilter.java:64) at org.apache.activemq.broker.MutableBrokerFilter.addConnection(MutableBrokerFilter.java:76) at org.apache.activemq.broker.AbstractConnection.processAddConnection(AbstractConnection.java:500) at org.apache.activemq.command.ConnectionInfo.visit(ConnectionInfo.java:106) at org.apache.activemq.broker.AbstractConnection.service(AbstractConnection.java:196) at org.apache.activemq.broker.TransportConnection$1.onCommand(TransportConnection.java:62) at org.apache.activemq.transport.ResponseCorrelator.onCommand(ResponseCorrelator.java:88) at org.apache.activemq.transport.TransportFilter.onCommand(TransportFilter.java:70) at org.apache.activemq.transport.vm.VMTransport.oneway(VMTransport.java:75) at org.apache.activemq.transport.MutexTransport.oneway(MutexTransport.java:44) at org.apache.activemq.transport.ResponseCorrelator.oneway(ResponseCorrelator.java:55) at org.apache.activemq.network.DemandForwardingBridgeSupport.startLocalBridge(DemandForwardingBridgeSupport.java:175) at org.apache.activemq.network.DemandForwardingBridgeSupport$3.run(DemandForwardingBridgeSupport.java:147) > Broker is not re-connecting to a network of brokers after going down and then > being brought back up > --- > > Key: AMQ-639 > URL: http://jira.activemq.org/jira//browse/AMQ-639 > Project: ActiveMQ > Type: Bug > Components: Broker > Versions: 4.0 M4 > Reporter: Brian Diesenhaus > Priority: Critical > Fix For: 4.0 M5 > > > I have set up a network of brokers with the following configuration: > http://activemq.org/config/1.0";> >class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer"/> > >managementContext="#mc"> > > > > > > > > > > > > >discoveryUri="multicast://bfe2"/> > > > > > > > > > > > > > > > I then run a series of tests (producing and consuming on the network of > brokers). Then I shut one broker down and then start it up again it can't > see the other brokers in the network but the other brokers can see it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (AMQ-638) no way to get broker-led replay of messages for messages ACK'd in a transaction after rollback
[ http://jira.activemq.org/jira//browse/AMQ-638?page=all ] james strachan updated AMQ-638: --- Priority: Trivial (was: Major) > no way to get broker-led replay of messages for messages ACK'd in a > transaction after rollback > -- > > Key: AMQ-638 > URL: http://jira.activemq.org/jira//browse/AMQ-638 > Project: ActiveMQ > Type: Improvement > Components: Broker > Reporter: james strachan > Assignee: Hiram Chirino > Priority: Trivial > Fix For: 4.0 > > > Currently in OpenWire the client is expected to replay messages ACK'd in a > transaction and then rolled back - which in general is a much better idea as > its simpler & faster & avoids common ordering problems. > However for simple stomp clients, we should have an option to allow a > Rollback to mean, redeliver all messages which were ACK'd in the transaction. > I wonder should we add a flag to ConsumerInfo to indicate if > brokerRedeliveryOnRollback is enabled? Then we can keep Stomp clients super > simple. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-638) no way to get broker-led replay of messages for messages ACK'd in a transaction after rollback
[ http://jira.activemq.org/jira//browse/AMQ-638?page=comments#action_35808 ] james strachan commented on AMQ-638: BTW I patched the ruby client to perform client side redelivery, so its a non-issue now for ruby clients > no way to get broker-led replay of messages for messages ACK'd in a > transaction after rollback > -- > > Key: AMQ-638 > URL: http://jira.activemq.org/jira//browse/AMQ-638 > Project: ActiveMQ > Type: Improvement > Components: Broker > Reporter: james strachan > Assignee: Hiram Chirino > Fix For: 4.0 > > > Currently in OpenWire the client is expected to replay messages ACK'd in a > transaction and then rolled back - which in general is a much better idea as > its simpler & faster & avoids common ordering problems. > However for simple stomp clients, we should have an option to allow a > Rollback to mean, redeliver all messages which were ACK'd in the transaction. > I wonder should we add a flag to ConsumerInfo to indicate if > brokerRedeliveryOnRollback is enabled? Then we can keep Stomp clients super > simple. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: M2 migration status
Prasad,
While working on tomcat-builder I realised that if
I need a geronimo jar not yet converted to m2, I can
get it from maven1 repo by using the following groupId
geronimo
geronimo-security
...
If this does not work, I will try your patch.
I am still working on security. It works for me with
1. cd modules/security and mvn clean test
2. mvn clean test -Dmodule=security
It still does not work as part of the full build.
One of the path is still not correct :
Caused by: java.io.FileNotFoundException:
C:\DOCUME~1\User\LOCALS~1\Temp\target\login-audit.log
(The system cannot find the path specified)
at java.io.FileOutputStream.openAppend(Native Method)
This leads me to believe that we need to request
maven guys to fix this. In maven1 there was a property
called maven.junit.dir which could be set to indicate
the directory in which the jvm should be forked.
Surefire does not have it. Either a property should be
available or surefire should fork the jvm correctly
from the child project and set user.dir.
I am runnig some more tests.
Thnaks
Anita
--- Prasad Kashyap <[EMAIL PROTECTED]>
wrote:
> Anita,
>
> Remember how security module works for everybody
> else but just me. The
> security test in Jetty fails with the exact same
> stacktrace as the
> security module. I have a feeling that this might
> work for everybody
> else too.
>
> I have tried both forkmode settings but in vain !
>
> Could you please try this jetty patch and let me
> know ?
>
> The deps list in the pom.xml is not pruned yet.
>
> Cheers
> Prasad
>
> On 3/17/06, anita kulshreshtha <[EMAIL PROTECTED]>
> wrote:
> >
> >
> > --- Prasad Kashyap <[EMAIL PROTECTED]>
> > wrote:
> >
> > > Anita,
> > >
> > > You can do away with this line that you have in
> your
> > > tomcat's pom
> > >
> >
>
${user.home}/.m2/repository
> > >
> > > You can get it by using
> ${settings.localRepository}.
> > > You don't need to
> > > have a settings.xml file.
> >
> >This patch is already waiting to be
> > applied.
> >
> > Thnaks
> > Anita
> > >
> > > Cheers
> > > Prasad
> > >
> > >
> > > On 3/17/06, Prasad Kashyap
> > > <[EMAIL PROTECTED]> wrote:
> > > > Jetty has the same issue. Tests run
> successfuly
> > > from inside the
> > > > module. Fail from the top level dir.
> > > >
> > > > On 3/17/06, Prasad Kashyap
> > > <[EMAIL PROTECTED]> wrote:
> > > > > Working on it !
> > > > >
> > > > > Cheers
> > > > > Prasad
> > > > >
> > > > > On 3/17/06, anita kulshreshtha
> > > <[EMAIL PROTECTED]> wrote:
> > > > > > I just built tomcat-builder and
> security
> > > from the
> > > > > > top level!! All with surefire
> 2.1.3-SNAPSHOT!
> > > I think
> > > > > > now we can call everything except jetty
> > > migrated. Any
> > > > > > takers for jetty ?
> > > > > >
> > > > > > Thnaks
> > > > > > Anita
> > > > > >
> > > > > > --- anita kulshreshtha
> <[EMAIL PROTECTED]>
> > > wrote:
> > > > > >
> > > > > > > Good news.. I just added a line
> > > > > > > ${basedir}
> > > > > > > to surefire configuraiton for tomcat
> and
> > > built it
> > > > > > > with
> > > > > > > mvn -o -Dmodule=tomcat clean test
> > > > > > >I think we can use this temporarily,
> > > until maven
> > > > > > > guys decide to fix it.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Anita
> > > > > > > --- anita kulshreshtha
> <[EMAIL PROTECTED]>
> > > wrote:
> > > > > > >
> > > > > > > >Few more things
> > > > > > > > 1. Need to remove
> > > > > > > >true
> > > > > > > > in all *-builders.
> > > > > > > > 2. All paths in java.io are resolved
> to
> > > user.dir
> > > > > > > > which
> > > > > > > > is the dir in which the jvm was
> invoked.
> > > M2 is not
> > > > > > > > invoking the jvm in the correct
> directory.
> > > It
> > > > > > > causes
> > > > > > > > all the paths to be resolved
> incorrectly.
> > > All the
> > > > > > > > log
> > > > > > > > files axis.log, login-audit.log,
> > > network.log are
> > > > > > > > not
> > > > > > > > created properly.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Anita
> > > > > > > >
> > > > > > > > --- Prasad Kashyap
> > > <[EMAIL PROTECTED]>
> > > > > > > > wrote:
> > > > > > > >
> > > > > > > > > All but just the following 4 modules
> to
> > > be
> > > > > > > > migrated.
> > > > > > > > >
> > > > > > > > > interop
> > > > > > > > > jetty
> > > > > > > > > jetty-builder
> > > > > > > > > axis-builder.
> > > > > > > > >
> > > > > > > > > Then there are the "almost-there"
> > > modules. These
> > > > > > > > > modules have pending
> > > > > > > > > work like one of the following -
> > > > > > > > > 1. tests don't work due to surefire
> > > plugin's
> > > > > > > bugs
> > > > > > > > > 2. properties/other resources are
> not
> > > procesed.
> > > > > > > > > 3. properties/resources are not in
> the
> > > m2 dir
> > > > > > > > > structure.
> > > > > > > > >
> > > > > > > > > Patches ready :
> > > > > > > > > j2ee-builder :
> > > > > > > > >
> >
[jira] Reopened: (AMQ-465) deadlock when using VM transport and Jencks...
[ http://jira.activemq.org/jira//browse/AMQ-465?page=all ] Hiram Chirino reopened AMQ-465: --- forgot to update fix for version. > deadlock when using VM transport and Jencks... > -- > > Key: AMQ-465 > URL: http://jira.activemq.org/jira//browse/AMQ-465 > Project: ActiveMQ > Type: Bug > Versions: 4.0 M4 > Reporter: james strachan > Assignee: Hiram Chirino > Fix For: 4.0 M5 > > > Background here: http://forums.logicblaze.com/posts/list/146.page > It seems to be VM protocol specific -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-465) deadlock when using VM transport and Jencks...
[ http://jira.activemq.org/jira//browse/AMQ-465?page=all ] Hiram Chirino resolved AMQ-465: --- Resolution: Fixed The asyncDispatch setting configured on the connection was not being honored by the connectionConsumers. Fixed so now the default should be to do async dispatch so the deadlock should not occur with the default configuration anymore. > deadlock when using VM transport and Jencks... > -- > > Key: AMQ-465 > URL: http://jira.activemq.org/jira//browse/AMQ-465 > Project: ActiveMQ > Type: Bug > Versions: 4.0 M4 > Reporter: james strachan > Assignee: Hiram Chirino > Fix For: 4.1 > > > Background here: http://forums.logicblaze.com/posts/list/146.page > It seems to be VM protocol specific -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (AMQ-533) Unable to create ACTIVEMQ_ACK table
[ http://jira.activemq.org/jira//browse/AMQ-533?page=comments#action_35809 ] Hiram Chirino commented on AMQ-533: --- ActiveMQ has not been enhanced so that the SQL statements used can be tuned. In you case, you would want to used something similar to... For more info on what attributes can be set on the statements element, see: http://activemq.codehaus.org/maven/apidocs/org/apache/activemq/store/jdbc/Statements.html All the settable bean properties can be used as attributes of the element. > Unable to create ACTIVEMQ_ACK table > --- > > Key: AMQ-533 > URL: http://jira.activemq.org/jira//browse/AMQ-533 > Project: ActiveMQ > Type: Bug > Components: Message Store > Versions: 3.2.2 > Environment: MySQL 4.1.11 (InnoDB engine, UTF-8 default characterset), MySQL > 3.1.8 connector/J, Java 1.5.0_06, Windows XP SP2, ActiveMQ 3.2.2 > Reporter: N W > Priority: Blocker > Fix For: 4.0 M5 > > > I received the following error when trying to run ActiveMQ for the first time > in the above environment: > "Specified key was too long; max key length is 1024 bytes..." > when ActiveMQ tries to create the ACTIVEMQ_ACKS table. It looks like the pk > for that table involves two columns which are defined in > DefaultStatementProvider.java as being VARCHAR(250)s. In in UTF-8 > characterset each char is composed of 3 bytes such that in this case the pk > will be 1500 bytes which exceeds the max length for a InnoDB primary key. > Is there a spec. which stipulates that containernameDataType and > subscriptionIdDataType should be VARCHAR(250)? Could these be changed to say > VARCHAR(128) or some such so that the pk on that table will fall within the > 1024 byte limit? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (GERONIMO-1732) Module migration to Maven 2: jetty-builder
[ http://issues.apache.org/jira/browse/GERONIMO-1732?page=all ] Prasad Kashyap reassigned GERONIMO-1732: Assign To: Prasad Kashyap > Module migration to Maven 2: jetty-builder > -- > > Key: GERONIMO-1732 > URL: http://issues.apache.org/jira/browse/GERONIMO-1732 > Project: Geronimo > Type: Sub-task > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Prasad Kashyap > > It's a task to keep track of the progress of the module build migration to > Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-635) ruby stomp client test failures against 4.x
[ http://jira.activemq.org/jira//browse/AMQ-635?page=all ] james strachan resolved AMQ-635: Resolution: Fixed tests are all working now. I added client side redelivery of ACK'd messages on rollback (abort in the ruby client) > ruby stomp client test failures against 4.x > --- > > Key: AMQ-635 > URL: http://jira.activemq.org/jira//browse/AMQ-635 > Project: ActiveMQ > Type: Bug > Versions: 4.0 M4 > Reporter: james strachan > Assignee: james strachan > Fix For: 4.0 M5 > > > The test suite for Ruby Stomp is not currently working against SVN HEAD of > ActiveMQ 4.x -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Resolved: (AMQ-492) Design error in MulticastDiscoveryAgent use of FailoverTransportConnector?
[ http://jira.activemq.org/jira//browse/AMQ-492?page=all ] Hiram Chirino resolved AMQ-492: --- Resolution: Fixed > Design error in MulticastDiscoveryAgent use of FailoverTransportConnector? > -- > > Key: AMQ-492 > URL: http://jira.activemq.org/jira//browse/AMQ-492 > Project: ActiveMQ > Type: Bug > Components: Connector > Versions: 4.0 > Environment: w2k and linux w java 1.5 > Reporter: Dennis Cook > Assignee: Hiram Chirino > Fix For: 4.0 > > > I have been trying to get my head around the multicast discovery mechanism. > In particular its use of the FailoverTransport class is bothering me. The > issue presented itself when viewing the DEBUG level log entries that were > generated after one broker of a pair, connected using this discovery > mechanism, was stopped. The FailoverTransport went into a very tight endless > loop of attempts to reconnect. > My first thought to tweak the Failover properties in the network connector > URI. But alais, the uri was for the multicast not the failover. No problem, > just duplicate the failover properties on the multicast agent. After doing > so, I started to think why is failover needed at all wont the connection > be reestablished when the broker returns and advertises itself again? > Can someone comment on this issue? Is the bug that the failover properties > where not available or is the problem that failover was used at all? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.activemq.org/jira//secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: M2 migration status
Anita,
Remember how security module works for everybody else but just me. The
security test in Jetty fails with the exact same stacktrace as the
security module. I have a feeling that this might work for everybody
else too.
I have tried both forkmode settings but in vain !
Could you please try this jetty patch and let me know ?
The deps list in the pom.xml is not pruned yet.
Cheers
Prasad
On 3/17/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:
>
>
> --- Prasad Kashyap <[EMAIL PROTECTED]>
> wrote:
>
> > Anita,
> >
> > You can do away with this line that you have in your
> > tomcat's pom
> >
> ${user.home}/.m2/repository
> >
> > You can get it by using ${settings.localRepository}.
> > You don't need to
> > have a settings.xml file.
>
>This patch is already waiting to be
> applied.
>
> Thnaks
> Anita
> >
> > Cheers
> > Prasad
> >
> >
> > On 3/17/06, Prasad Kashyap
> > <[EMAIL PROTECTED]> wrote:
> > > Jetty has the same issue. Tests run successfuly
> > from inside the
> > > module. Fail from the top level dir.
> > >
> > > On 3/17/06, Prasad Kashyap
> > <[EMAIL PROTECTED]> wrote:
> > > > Working on it !
> > > >
> > > > Cheers
> > > > Prasad
> > > >
> > > > On 3/17/06, anita kulshreshtha
> > <[EMAIL PROTECTED]> wrote:
> > > > > I just built tomcat-builder and security
> > from the
> > > > > top level!! All with surefire 2.1.3-SNAPSHOT!
> > I think
> > > > > now we can call everything except jetty
> > migrated. Any
> > > > > takers for jetty ?
> > > > >
> > > > > Thnaks
> > > > > Anita
> > > > >
> > > > > --- anita kulshreshtha <[EMAIL PROTECTED]>
> > wrote:
> > > > >
> > > > > > Good news.. I just added a line
> > > > > > ${basedir}
> > > > > > to surefire configuraiton for tomcat and
> > built it
> > > > > > with
> > > > > > mvn -o -Dmodule=tomcat clean test
> > > > > >I think we can use this temporarily,
> > until maven
> > > > > > guys decide to fix it.
> > > > > >
> > > > > > Thanks
> > > > > > Anita
> > > > > > --- anita kulshreshtha <[EMAIL PROTECTED]>
> > wrote:
> > > > > >
> > > > > > >Few more things
> > > > > > > 1. Need to remove
> > > > > > >true
> > > > > > > in all *-builders.
> > > > > > > 2. All paths in java.io are resolved to
> > user.dir
> > > > > > > which
> > > > > > > is the dir in which the jvm was invoked.
> > M2 is not
> > > > > > > invoking the jvm in the correct directory.
> > It
> > > > > > causes
> > > > > > > all the paths to be resolved incorrectly.
> > All the
> > > > > > > log
> > > > > > > files axis.log, login-audit.log,
> > network.log are
> > > > > > > not
> > > > > > > created properly.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Anita
> > > > > > >
> > > > > > > --- Prasad Kashyap
> > <[EMAIL PROTECTED]>
> > > > > > > wrote:
> > > > > > >
> > > > > > > > All but just the following 4 modules to
> > be
> > > > > > > migrated.
> > > > > > > >
> > > > > > > > interop
> > > > > > > > jetty
> > > > > > > > jetty-builder
> > > > > > > > axis-builder.
> > > > > > > >
> > > > > > > > Then there are the "almost-there"
> > modules. These
> > > > > > > > modules have pending
> > > > > > > > work like one of the following -
> > > > > > > > 1. tests don't work due to surefire
> > plugin's
> > > > > > bugs
> > > > > > > > 2. properties/other resources are not
> > procesed.
> > > > > > > > 3. properties/resources are not in the
> > m2 dir
> > > > > > > > structure.
> > > > > > > >
> > > > > > > > Patches ready :
> > > > > > > > j2ee-builder :
> > > > > > > >
> > > > > >
> > http://issues.apache.org/jira/browse/GERONIMO-1713
> > > > > > > > axis-builder :
> > > > > > > >
> > > > > >
> > http://issues.apache.org/jira/browse/GERONIMO-1723
> > > > > > > >
> > > > > > > > Cheers
> > > > > > > > Prasad
> > > > > > > >
> > > > > > > > On 3/13/06, Prasad Kashyap
> > > > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > > > > > j2ee-builder done. I have also pruned
> > the
> > > > > > > > dependency lists for
> > > > > > > > > j2ee-builder and j2ee.
> > > > > > > > >
> > > > > > > > > Will update the patch now.
> > > > > > > > >
> > > > > > > > > Cheers
> > > > > > > > > Prasad
> > > > > > > > >
> > > > > > > > > On 3/13/06, Henri Yandell
> > <[EMAIL PROTECTED]>
> > > > > > > > wrote:
> > > > > > > > > > On 3/10/06, Jacek Laskowski
> > > > > > > <[EMAIL PROTECTED]>
> > > > > > > > wrote:
> > > > > > > > > > > 2006/3/9, Henri Yandell
> > > > > > > <[EMAIL PROTECTED]>:
> > > > > > > > > > >
> > > > > > > > > > > > The
> > geronimo-spec-j2ee-deployment module
> > > > > > > was
> > > > > > > > giving errors; but I
> > > > > > > > > > > > realised I was building under
> > JDK 1.5.
> > > > > > It
> > > > > > > > works fine under 1.4; so
> > > > > > > > > > > > something for the future there
> > perhaps.
> > > > > > > > > > >
> > > > > > > > > > > I think I've seen a way to make
> > sure that
> > > > > > M2
> > > > > > > > is used on Java 1.4.
> > > > > > > > > > >
> > > > > > > > > > > Now, there might be a way to
> > leverage it
> > > > > > and
>
Re: M2 migration status
Jetty has the same issue. Tests run successfuly from inside the
module. Fail from the top level dir.
On 3/17/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> Working on it !
>
> Cheers
> Prasad
>
> On 3/17/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> > I just built tomcat-builder and security from the
> > top level!! All with surefire 2.1.3-SNAPSHOT! I think
> > now we can call everything except jetty migrated. Any
> > takers for jetty ?
> >
> > Thnaks
> > Anita
> >
> > --- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> >
> > > Good news.. I just added a line
> > > ${basedir}
> > > to surefire configuraiton for tomcat and built it
> > > with
> > > mvn -o -Dmodule=tomcat clean test
> > >I think we can use this temporarily, until maven
> > > guys decide to fix it.
> > >
> > > Thanks
> > > Anita
> > > --- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> > >
> > > >Few more things
> > > > 1. Need to remove
> > > >true
> > > > in all *-builders.
> > > > 2. All paths in java.io are resolved to user.dir
> > > > which
> > > > is the dir in which the jvm was invoked. M2 is not
> > > > invoking the jvm in the correct directory. It
> > > causes
> > > > all the paths to be resolved incorrectly. All the
> > > > log
> > > > files axis.log, login-audit.log, network.log are
> > > > not
> > > > created properly.
> > > >
> > > > Thanks
> > > > Anita
> > > >
> > > > --- Prasad Kashyap <[EMAIL PROTECTED]>
> > > > wrote:
> > > >
> > > > > All but just the following 4 modules to be
> > > > migrated.
> > > > >
> > > > > interop
> > > > > jetty
> > > > > jetty-builder
> > > > > axis-builder.
> > > > >
> > > > > Then there are the "almost-there" modules. These
> > > > > modules have pending
> > > > > work like one of the following -
> > > > > 1. tests don't work due to surefire plugin's
> > > bugs
> > > > > 2. properties/other resources are not procesed.
> > > > > 3. properties/resources are not in the m2 dir
> > > > > structure.
> > > > >
> > > > > Patches ready :
> > > > > j2ee-builder :
> > > > >
> > > http://issues.apache.org/jira/browse/GERONIMO-1713
> > > > > axis-builder :
> > > > >
> > > http://issues.apache.org/jira/browse/GERONIMO-1723
> > > > >
> > > > > Cheers
> > > > > Prasad
> > > > >
> > > > > On 3/13/06, Prasad Kashyap
> > > > > <[EMAIL PROTECTED]> wrote:
> > > > > > j2ee-builder done. I have also pruned the
> > > > > dependency lists for
> > > > > > j2ee-builder and j2ee.
> > > > > >
> > > > > > Will update the patch now.
> > > > > >
> > > > > > Cheers
> > > > > > Prasad
> > > > > >
> > > > > > On 3/13/06, Henri Yandell <[EMAIL PROTECTED]>
> > > > > wrote:
> > > > > > > On 3/10/06, Jacek Laskowski
> > > > <[EMAIL PROTECTED]>
> > > > > wrote:
> > > > > > > > 2006/3/9, Henri Yandell
> > > > <[EMAIL PROTECTED]>:
> > > > > > > >
> > > > > > > > > The geronimo-spec-j2ee-deployment module
> > > > was
> > > > > giving errors; but I
> > > > > > > > > realised I was building under JDK 1.5.
> > > It
> > > > > works fine under 1.4; so
> > > > > > > > > something for the future there perhaps.
> > > > > > > >
> > > > > > > > I think I've seen a way to make sure that
> > > M2
> > > > > is used on Java 1.4.
> > > > > > > >
> > > > > > > > Now, there might be a way to leverage it
> > > and
> > > > > ensure Java 1.4 runtime.
> > > > > > > >
> > > > > > > > > Next I get errors from the Geronimo ::
> > > > > Directory module; this is
> > > > > > > > > because I'm being a aggressive and
> > > turning
> > > > > off the snapshot
> > > > > > > > > repositories in the top pom.
> > > > directory-asn1
> > > > > depends on commons-test,
> > > > > > > > > which is unreleased. In this case the
> > > > ideal
> > > > > solution is to set
> > > > > > > > > commons-test to test scope so it doesn't
> > > > end
> > > > > up in the build - I'll
> > > > > > > > > work on getting that changed - or just
> > > > > having them not depend on
> > > > > > > > > commons-test :)
> > > > > > > >
> > > > > > > > Great. I'm looking forward to committing
> > > > your
> > > > > patch ;)
> > > > > > >
> > > > > > > Fixed it at the other end. The commons-test
> > > > > dependency no longer gets
> > > > > > > passed along transitively.
> > > > > > >
> > > > > > > Now I find that everything builds from the
> > > top
> > > > > down - except for the 2
> > > > > > > Tomcat tests that already appear to be being
> > > > > looked into. This is with
> > > > > > > the snapshot repositories commented out -
> > > they
> > > > > slow things down and
> > > > > > > seem to lead to errors that mean I have to
> > > > keep
> > > > > repeating the build
> > > > > > > until they've finally downloaded things.
> > > > There's
> > > > > some way to change
> > > > > > > their strategy I think - must look into
> > > this.
> > > > > > >
> > > > > > > Slowly moving axis-builder along. Looks like
> > > > the
> > > > > Maven xmlbeans plugin
> > > > > > > depends on a snapshot version of xmlbeans,
> > > so
> > > > > that's irritating :)
> > > > > > >
>
Re: M2 migration status
--- Prasad Kashyap <[EMAIL PROTECTED]>
wrote:
> Anita,
>
> You can do away with this line that you have in your
> tomcat's pom
>
${user.home}/.m2/repository
>
> You can get it by using ${settings.localRepository}.
> You don't need to
> have a settings.xml file.
This patch is already waiting to be
applied.
Thnaks
Anita
>
> Cheers
> Prasad
>
>
> On 3/17/06, Prasad Kashyap
> <[EMAIL PROTECTED]> wrote:
> > Jetty has the same issue. Tests run successfuly
> from inside the
> > module. Fail from the top level dir.
> >
> > On 3/17/06, Prasad Kashyap
> <[EMAIL PROTECTED]> wrote:
> > > Working on it !
> > >
> > > Cheers
> > > Prasad
> > >
> > > On 3/17/06, anita kulshreshtha
> <[EMAIL PROTECTED]> wrote:
> > > > I just built tomcat-builder and security
> from the
> > > > top level!! All with surefire 2.1.3-SNAPSHOT!
> I think
> > > > now we can call everything except jetty
> migrated. Any
> > > > takers for jetty ?
> > > >
> > > > Thnaks
> > > > Anita
> > > >
> > > > --- anita kulshreshtha <[EMAIL PROTECTED]>
> wrote:
> > > >
> > > > > Good news.. I just added a line
> > > > > ${basedir}
> > > > > to surefire configuraiton for tomcat and
> built it
> > > > > with
> > > > > mvn -o -Dmodule=tomcat clean test
> > > > >I think we can use this temporarily,
> until maven
> > > > > guys decide to fix it.
> > > > >
> > > > > Thanks
> > > > > Anita
> > > > > --- anita kulshreshtha <[EMAIL PROTECTED]>
> wrote:
> > > > >
> > > > > >Few more things
> > > > > > 1. Need to remove
> > > > > >true
> > > > > > in all *-builders.
> > > > > > 2. All paths in java.io are resolved to
> user.dir
> > > > > > which
> > > > > > is the dir in which the jvm was invoked.
> M2 is not
> > > > > > invoking the jvm in the correct directory.
> It
> > > > > causes
> > > > > > all the paths to be resolved incorrectly.
> All the
> > > > > > log
> > > > > > files axis.log, login-audit.log,
> network.log are
> > > > > > not
> > > > > > created properly.
> > > > > >
> > > > > > Thanks
> > > > > > Anita
> > > > > >
> > > > > > --- Prasad Kashyap
> <[EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > >
> > > > > > > All but just the following 4 modules to
> be
> > > > > > migrated.
> > > > > > >
> > > > > > > interop
> > > > > > > jetty
> > > > > > > jetty-builder
> > > > > > > axis-builder.
> > > > > > >
> > > > > > > Then there are the "almost-there"
> modules. These
> > > > > > > modules have pending
> > > > > > > work like one of the following -
> > > > > > > 1. tests don't work due to surefire
> plugin's
> > > > > bugs
> > > > > > > 2. properties/other resources are not
> procesed.
> > > > > > > 3. properties/resources are not in the
> m2 dir
> > > > > > > structure.
> > > > > > >
> > > > > > > Patches ready :
> > > > > > > j2ee-builder :
> > > > > > >
> > > > >
> http://issues.apache.org/jira/browse/GERONIMO-1713
> > > > > > > axis-builder :
> > > > > > >
> > > > >
> http://issues.apache.org/jira/browse/GERONIMO-1723
> > > > > > >
> > > > > > > Cheers
> > > > > > > Prasad
> > > > > > >
> > > > > > > On 3/13/06, Prasad Kashyap
> > > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > > > > j2ee-builder done. I have also pruned
> the
> > > > > > > dependency lists for
> > > > > > > > j2ee-builder and j2ee.
> > > > > > > >
> > > > > > > > Will update the patch now.
> > > > > > > >
> > > > > > > > Cheers
> > > > > > > > Prasad
> > > > > > > >
> > > > > > > > On 3/13/06, Henri Yandell
> <[EMAIL PROTECTED]>
> > > > > > > wrote:
> > > > > > > > > On 3/10/06, Jacek Laskowski
> > > > > > <[EMAIL PROTECTED]>
> > > > > > > wrote:
> > > > > > > > > > 2006/3/9, Henri Yandell
> > > > > > <[EMAIL PROTECTED]>:
> > > > > > > > > >
> > > > > > > > > > > The
> geronimo-spec-j2ee-deployment module
> > > > > > was
> > > > > > > giving errors; but I
> > > > > > > > > > > realised I was building under
> JDK 1.5.
> > > > > It
> > > > > > > works fine under 1.4; so
> > > > > > > > > > > something for the future there
> perhaps.
> > > > > > > > > >
> > > > > > > > > > I think I've seen a way to make
> sure that
> > > > > M2
> > > > > > > is used on Java 1.4.
> > > > > > > > > >
> > > > > > > > > > Now, there might be a way to
> leverage it
> > > > > and
> > > > > > > ensure Java 1.4 runtime.
> > > > > > > > > >
> > > > > > > > > > > Next I get errors from the
> Geronimo ::
> > > > > > > Directory module; this is
> > > > > > > > > > > because I'm being a aggressive
> and
> > > > > turning
> > > > > > > off the snapshot
> > > > > > > > > > > repositories in the top pom.
> > > > > > directory-asn1
> > > > > > > depends on commons-test,
> > > > > > > > > > > which is unreleased. In this
> case the
> > > > > > ideal
> > > > > > > solution is to set
> > > > > > > > > > > commons-test to test scope so it
> doesn't
> > > > > > end
> > > > > > > up in the build - I'll
> > > > > > > > > > > work on getting that changed -
> or just
> > > > > > > having them not depend on
> > > > > > > > > > > commons-test :)
> > > > > > > > > >
> > > > > > >
Re: M2 migration status
Anita,
You can do away with this line that you have in your tomcat's pom
${user.home}/.m2/repository
You can get it by using ${settings.localRepository}. You don't need to
have a settings.xml file.
Cheers
Prasad
On 3/17/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> Jetty has the same issue. Tests run successfuly from inside the
> module. Fail from the top level dir.
>
> On 3/17/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote:
> > Working on it !
> >
> > Cheers
> > Prasad
> >
> > On 3/17/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> > > I just built tomcat-builder and security from the
> > > top level!! All with surefire 2.1.3-SNAPSHOT! I think
> > > now we can call everything except jetty migrated. Any
> > > takers for jetty ?
> > >
> > > Thnaks
> > > Anita
> > >
> > > --- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> > >
> > > > Good news.. I just added a line
> > > > ${basedir}
> > > > to surefire configuraiton for tomcat and built it
> > > > with
> > > > mvn -o -Dmodule=tomcat clean test
> > > >I think we can use this temporarily, until maven
> > > > guys decide to fix it.
> > > >
> > > > Thanks
> > > > Anita
> > > > --- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> > > >
> > > > >Few more things
> > > > > 1. Need to remove
> > > > >true
> > > > > in all *-builders.
> > > > > 2. All paths in java.io are resolved to user.dir
> > > > > which
> > > > > is the dir in which the jvm was invoked. M2 is not
> > > > > invoking the jvm in the correct directory. It
> > > > causes
> > > > > all the paths to be resolved incorrectly. All the
> > > > > log
> > > > > files axis.log, login-audit.log, network.log are
> > > > > not
> > > > > created properly.
> > > > >
> > > > > Thanks
> > > > > Anita
> > > > >
> > > > > --- Prasad Kashyap <[EMAIL PROTECTED]>
> > > > > wrote:
> > > > >
> > > > > > All but just the following 4 modules to be
> > > > > migrated.
> > > > > >
> > > > > > interop
> > > > > > jetty
> > > > > > jetty-builder
> > > > > > axis-builder.
> > > > > >
> > > > > > Then there are the "almost-there" modules. These
> > > > > > modules have pending
> > > > > > work like one of the following -
> > > > > > 1. tests don't work due to surefire plugin's
> > > > bugs
> > > > > > 2. properties/other resources are not procesed.
> > > > > > 3. properties/resources are not in the m2 dir
> > > > > > structure.
> > > > > >
> > > > > > Patches ready :
> > > > > > j2ee-builder :
> > > > > >
> > > > http://issues.apache.org/jira/browse/GERONIMO-1713
> > > > > > axis-builder :
> > > > > >
> > > > http://issues.apache.org/jira/browse/GERONIMO-1723
> > > > > >
> > > > > > Cheers
> > > > > > Prasad
> > > > > >
> > > > > > On 3/13/06, Prasad Kashyap
> > > > > > <[EMAIL PROTECTED]> wrote:
> > > > > > > j2ee-builder done. I have also pruned the
> > > > > > dependency lists for
> > > > > > > j2ee-builder and j2ee.
> > > > > > >
> > > > > > > Will update the patch now.
> > > > > > >
> > > > > > > Cheers
> > > > > > > Prasad
> > > > > > >
> > > > > > > On 3/13/06, Henri Yandell <[EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > > > > On 3/10/06, Jacek Laskowski
> > > > > <[EMAIL PROTECTED]>
> > > > > > wrote:
> > > > > > > > > 2006/3/9, Henri Yandell
> > > > > <[EMAIL PROTECTED]>:
> > > > > > > > >
> > > > > > > > > > The geronimo-spec-j2ee-deployment module
> > > > > was
> > > > > > giving errors; but I
> > > > > > > > > > realised I was building under JDK 1.5.
> > > > It
> > > > > > works fine under 1.4; so
> > > > > > > > > > something for the future there perhaps.
> > > > > > > > >
> > > > > > > > > I think I've seen a way to make sure that
> > > > M2
> > > > > > is used on Java 1.4.
> > > > > > > > >
> > > > > > > > > Now, there might be a way to leverage it
> > > > and
> > > > > > ensure Java 1.4 runtime.
> > > > > > > > >
> > > > > > > > > > Next I get errors from the Geronimo ::
> > > > > > Directory module; this is
> > > > > > > > > > because I'm being a aggressive and
> > > > turning
> > > > > > off the snapshot
> > > > > > > > > > repositories in the top pom.
> > > > > directory-asn1
> > > > > > depends on commons-test,
> > > > > > > > > > which is unreleased. In this case the
> > > > > ideal
> > > > > > solution is to set
> > > > > > > > > > commons-test to test scope so it doesn't
> > > > > end
> > > > > > up in the build - I'll
> > > > > > > > > > work on getting that changed - or just
> > > > > > having them not depend on
> > > > > > > > > > commons-test :)
> > > > > > > > >
> > > > > > > > > Great. I'm looking forward to committing
> > > > > your
> > > > > > patch ;)
> > > > > > > >
> > > > > > > > Fixed it at the other end. The commons-test
> > > > > > dependency no longer gets
> > > > > > > > passed along transitively.
> > > > > > > >
> > > > > > > > Now I find that everything builds from the
> > > > top
> > > > > > down - except for the 2
> > > > > > > > Tomcat tests that already appear to be being
> > > > > > looked into. This is with
> > > > > > > > the snapshot
[jira] Assigned: (GERONIMO-1731) Module migration to Maven 2: jetty
[ http://issues.apache.org/jira/browse/GERONIMO-1731?page=all ] Prasad Kashyap reassigned GERONIMO-1731: Assign To: Prasad Kashyap > Module migration to Maven 2: jetty > -- > > Key: GERONIMO-1731 > URL: http://issues.apache.org/jira/browse/GERONIMO-1731 > Project: Geronimo > Type: Sub-task > Versions: 1.x > Reporter: Jacek Laskowski > Assignee: Prasad Kashyap > > It's a task to keep track of the progress of the module build migration to > Maven2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: M2 migration status
Working on it !
Cheers
Prasad
On 3/17/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> I just built tomcat-builder and security from the
> top level!! All with surefire 2.1.3-SNAPSHOT! I think
> now we can call everything except jetty migrated. Any
> takers for jetty ?
>
> Thnaks
> Anita
>
> --- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
>
> > Good news.. I just added a line
> > ${basedir}
> > to surefire configuraiton for tomcat and built it
> > with
> > mvn -o -Dmodule=tomcat clean test
> >I think we can use this temporarily, until maven
> > guys decide to fix it.
> >
> > Thanks
> > Anita
> > --- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> >
> > >Few more things
> > > 1. Need to remove
> > >true
> > > in all *-builders.
> > > 2. All paths in java.io are resolved to user.dir
> > > which
> > > is the dir in which the jvm was invoked. M2 is not
> > > invoking the jvm in the correct directory. It
> > causes
> > > all the paths to be resolved incorrectly. All the
> > > log
> > > files axis.log, login-audit.log, network.log are
> > > not
> > > created properly.
> > >
> > > Thanks
> > > Anita
> > >
> > > --- Prasad Kashyap <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > All but just the following 4 modules to be
> > > migrated.
> > > >
> > > > interop
> > > > jetty
> > > > jetty-builder
> > > > axis-builder.
> > > >
> > > > Then there are the "almost-there" modules. These
> > > > modules have pending
> > > > work like one of the following -
> > > > 1. tests don't work due to surefire plugin's
> > bugs
> > > > 2. properties/other resources are not procesed.
> > > > 3. properties/resources are not in the m2 dir
> > > > structure.
> > > >
> > > > Patches ready :
> > > > j2ee-builder :
> > > >
> > http://issues.apache.org/jira/browse/GERONIMO-1713
> > > > axis-builder :
> > > >
> > http://issues.apache.org/jira/browse/GERONIMO-1723
> > > >
> > > > Cheers
> > > > Prasad
> > > >
> > > > On 3/13/06, Prasad Kashyap
> > > > <[EMAIL PROTECTED]> wrote:
> > > > > j2ee-builder done. I have also pruned the
> > > > dependency lists for
> > > > > j2ee-builder and j2ee.
> > > > >
> > > > > Will update the patch now.
> > > > >
> > > > > Cheers
> > > > > Prasad
> > > > >
> > > > > On 3/13/06, Henri Yandell <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > > On 3/10/06, Jacek Laskowski
> > > <[EMAIL PROTECTED]>
> > > > wrote:
> > > > > > > 2006/3/9, Henri Yandell
> > > <[EMAIL PROTECTED]>:
> > > > > > >
> > > > > > > > The geronimo-spec-j2ee-deployment module
> > > was
> > > > giving errors; but I
> > > > > > > > realised I was building under JDK 1.5.
> > It
> > > > works fine under 1.4; so
> > > > > > > > something for the future there perhaps.
> > > > > > >
> > > > > > > I think I've seen a way to make sure that
> > M2
> > > > is used on Java 1.4.
> > > > > > >
> > > > > > > Now, there might be a way to leverage it
> > and
> > > > ensure Java 1.4 runtime.
> > > > > > >
> > > > > > > > Next I get errors from the Geronimo ::
> > > > Directory module; this is
> > > > > > > > because I'm being a aggressive and
> > turning
> > > > off the snapshot
> > > > > > > > repositories in the top pom.
> > > directory-asn1
> > > > depends on commons-test,
> > > > > > > > which is unreleased. In this case the
> > > ideal
> > > > solution is to set
> > > > > > > > commons-test to test scope so it doesn't
> > > end
> > > > up in the build - I'll
> > > > > > > > work on getting that changed - or just
> > > > having them not depend on
> > > > > > > > commons-test :)
> > > > > > >
> > > > > > > Great. I'm looking forward to committing
> > > your
> > > > patch ;)
> > > > > >
> > > > > > Fixed it at the other end. The commons-test
> > > > dependency no longer gets
> > > > > > passed along transitively.
> > > > > >
> > > > > > Now I find that everything builds from the
> > top
> > > > down - except for the 2
> > > > > > Tomcat tests that already appear to be being
> > > > looked into. This is with
> > > > > > the snapshot repositories commented out -
> > they
> > > > slow things down and
> > > > > > seem to lead to errors that mean I have to
> > > keep
> > > > repeating the build
> > > > > > until they've finally downloaded things.
> > > There's
> > > > some way to change
> > > > > > their strategy I think - must look into
> > this.
> > > > > >
> > > > > > Slowly moving axis-builder along. Looks like
> > > the
> > > > Maven xmlbeans plugin
> > > > > > depends on a snapshot version of xmlbeans,
> > so
> > > > that's irritating :)
> > > > > >
> > > > > > Hen
> > > > > >
> > > > >
> > > >
> > >
> > >
> > > __
> > > Do You Yahoo!?
> > > Tired of spam? Yahoo! Mail has the best spam
> > > protection around
> > > http://mail.yahoo.com
> > >
> >
> >
> > __
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > http://mail.yahoo.com
> >
>
>
> ___
Re: M2 migration status
I just built tomcat-builder and security from the
top level!! All with surefire 2.1.3-SNAPSHOT! I think
now we can call everything except jetty migrated. Any
takers for jetty ?
Thnaks
Anita
--- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> Good news.. I just added a line
> ${basedir}
> to surefire configuraiton for tomcat and built it
> with
> mvn -o -Dmodule=tomcat clean test
>I think we can use this temporarily, until maven
> guys decide to fix it.
>
> Thanks
> Anita
> --- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
>
> >Few more things
> > 1. Need to remove
> >true
> > in all *-builders.
> > 2. All paths in java.io are resolved to user.dir
> > which
> > is the dir in which the jvm was invoked. M2 is not
> > invoking the jvm in the correct directory. It
> causes
> > all the paths to be resolved incorrectly. All the
> > log
> > files axis.log, login-audit.log, network.log are
> > not
> > created properly.
> >
> > Thanks
> > Anita
> >
> > --- Prasad Kashyap <[EMAIL PROTECTED]>
> > wrote:
> >
> > > All but just the following 4 modules to be
> > migrated.
> > >
> > > interop
> > > jetty
> > > jetty-builder
> > > axis-builder.
> > >
> > > Then there are the "almost-there" modules. These
> > > modules have pending
> > > work like one of the following -
> > > 1. tests don't work due to surefire plugin's
> bugs
> > > 2. properties/other resources are not procesed.
> > > 3. properties/resources are not in the m2 dir
> > > structure.
> > >
> > > Patches ready :
> > > j2ee-builder :
> > >
> http://issues.apache.org/jira/browse/GERONIMO-1713
> > > axis-builder :
> > >
> http://issues.apache.org/jira/browse/GERONIMO-1723
> > >
> > > Cheers
> > > Prasad
> > >
> > > On 3/13/06, Prasad Kashyap
> > > <[EMAIL PROTECTED]> wrote:
> > > > j2ee-builder done. I have also pruned the
> > > dependency lists for
> > > > j2ee-builder and j2ee.
> > > >
> > > > Will update the patch now.
> > > >
> > > > Cheers
> > > > Prasad
> > > >
> > > > On 3/13/06, Henri Yandell <[EMAIL PROTECTED]>
> > > wrote:
> > > > > On 3/10/06, Jacek Laskowski
> > <[EMAIL PROTECTED]>
> > > wrote:
> > > > > > 2006/3/9, Henri Yandell
> > <[EMAIL PROTECTED]>:
> > > > > >
> > > > > > > The geronimo-spec-j2ee-deployment module
> > was
> > > giving errors; but I
> > > > > > > realised I was building under JDK 1.5.
> It
> > > works fine under 1.4; so
> > > > > > > something for the future there perhaps.
> > > > > >
> > > > > > I think I've seen a way to make sure that
> M2
> > > is used on Java 1.4.
> > > > > >
> > > > > > Now, there might be a way to leverage it
> and
> > > ensure Java 1.4 runtime.
> > > > > >
> > > > > > > Next I get errors from the Geronimo ::
> > > Directory module; this is
> > > > > > > because I'm being a aggressive and
> turning
> > > off the snapshot
> > > > > > > repositories in the top pom.
> > directory-asn1
> > > depends on commons-test,
> > > > > > > which is unreleased. In this case the
> > ideal
> > > solution is to set
> > > > > > > commons-test to test scope so it doesn't
> > end
> > > up in the build - I'll
> > > > > > > work on getting that changed - or just
> > > having them not depend on
> > > > > > > commons-test :)
> > > > > >
> > > > > > Great. I'm looking forward to committing
> > your
> > > patch ;)
> > > > >
> > > > > Fixed it at the other end. The commons-test
> > > dependency no longer gets
> > > > > passed along transitively.
> > > > >
> > > > > Now I find that everything builds from the
> top
> > > down - except for the 2
> > > > > Tomcat tests that already appear to be being
> > > looked into. This is with
> > > > > the snapshot repositories commented out -
> they
> > > slow things down and
> > > > > seem to lead to errors that mean I have to
> > keep
> > > repeating the build
> > > > > until they've finally downloaded things.
> > There's
> > > some way to change
> > > > > their strategy I think - must look into
> this.
> > > > >
> > > > > Slowly moving axis-builder along. Looks like
> > the
> > > Maven xmlbeans plugin
> > > > > depends on a snapshot version of xmlbeans,
> so
> > > that's irritating :)
> > > > >
> > > > > Hen
> > > > >
> > > >
> > >
> >
> >
> > __
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > http://mail.yahoo.com
> >
>
>
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: M2 migration status
I wonder if this a problem with maven.
I had done the same thing in this tomcat patch that I had submitted here.
http://issues.apache.org/jira/secure/attachment/12324025/tomcat-tests.patch
+props.setProperty("user.dir", basedir);
I think somewhere in our code, we are using the "user.dir" to
construct paths and create objects.
The "user.dir" should remain set to where the jvm was forked off and
the "basedir" should be set to the module's directory. Now there might
be instances when the the 2 properties match, eg.
1) in a top down build the forkmode is set to pertest and the jvm may
be forked from inside the module
2) the module is built from inside it (not top down).
What do you think ?
Cheers
Prasad
On 3/17/06, anita kulshreshtha <[EMAIL PROTECTED]> wrote:
> Good news.. I just added a line
> ${basedir}
> to surefire configuraiton for tomcat and built it
> with
> mvn -o -Dmodule=tomcat clean test
>I think we can use this temporarily, until maven
> guys decide to fix it.
>
> Thanks
> Anita
> --- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
>
> >Few more things
> > 1. Need to remove
> >true
> > in all *-builders.
> > 2. All paths in java.io are resolved to user.dir
> > which
> > is the dir in which the jvm was invoked. M2 is not
> > invoking the jvm in the correct directory. It causes
> > all the paths to be resolved incorrectly. All the
> > log
> > files axis.log, login-audit.log, network.log are
> > not
> > created properly.
> >
> > Thanks
> > Anita
> >
> > --- Prasad Kashyap <[EMAIL PROTECTED]>
> > wrote:
> >
> > > All but just the following 4 modules to be
> > migrated.
> > >
> > > interop
> > > jetty
> > > jetty-builder
> > > axis-builder.
> > >
> > > Then there are the "almost-there" modules. These
> > > modules have pending
> > > work like one of the following -
> > > 1. tests don't work due to surefire plugin's bugs
> > > 2. properties/other resources are not procesed.
> > > 3. properties/resources are not in the m2 dir
> > > structure.
> > >
> > > Patches ready :
> > > j2ee-builder :
> > > http://issues.apache.org/jira/browse/GERONIMO-1713
> > > axis-builder :
> > > http://issues.apache.org/jira/browse/GERONIMO-1723
> > >
> > > Cheers
> > > Prasad
> > >
> > > On 3/13/06, Prasad Kashyap
> > > <[EMAIL PROTECTED]> wrote:
> > > > j2ee-builder done. I have also pruned the
> > > dependency lists for
> > > > j2ee-builder and j2ee.
> > > >
> > > > Will update the patch now.
> > > >
> > > > Cheers
> > > > Prasad
> > > >
> > > > On 3/13/06, Henri Yandell <[EMAIL PROTECTED]>
> > > wrote:
> > > > > On 3/10/06, Jacek Laskowski
> > <[EMAIL PROTECTED]>
> > > wrote:
> > > > > > 2006/3/9, Henri Yandell
> > <[EMAIL PROTECTED]>:
> > > > > >
> > > > > > > The geronimo-spec-j2ee-deployment module
> > was
> > > giving errors; but I
> > > > > > > realised I was building under JDK 1.5. It
> > > works fine under 1.4; so
> > > > > > > something for the future there perhaps.
> > > > > >
> > > > > > I think I've seen a way to make sure that M2
> > > is used on Java 1.4.
> > > > > >
> > > > > > Now, there might be a way to leverage it and
> > > ensure Java 1.4 runtime.
> > > > > >
> > > > > > > Next I get errors from the Geronimo ::
> > > Directory module; this is
> > > > > > > because I'm being a aggressive and turning
> > > off the snapshot
> > > > > > > repositories in the top pom.
> > directory-asn1
> > > depends on commons-test,
> > > > > > > which is unreleased. In this case the
> > ideal
> > > solution is to set
> > > > > > > commons-test to test scope so it doesn't
> > end
> > > up in the build - I'll
> > > > > > > work on getting that changed - or just
> > > having them not depend on
> > > > > > > commons-test :)
> > > > > >
> > > > > > Great. I'm looking forward to committing
> > your
> > > patch ;)
> > > > >
> > > > > Fixed it at the other end. The commons-test
> > > dependency no longer gets
> > > > > passed along transitively.
> > > > >
> > > > > Now I find that everything builds from the top
> > > down - except for the 2
> > > > > Tomcat tests that already appear to be being
> > > looked into. This is with
> > > > > the snapshot repositories commented out - they
> > > slow things down and
> > > > > seem to lead to errors that mean I have to
> > keep
> > > repeating the build
> > > > > until they've finally downloaded things.
> > There's
> > > some way to change
> > > > > their strategy I think - must look into this.
> > > > >
> > > > > Slowly moving axis-builder along. Looks like
> > the
> > > Maven xmlbeans plugin
> > > > > depends on a snapshot version of xmlbeans, so
> > > that's irritating :)
> > > > >
> > > > > Hen
> > > > >
> > > >
> > >
> >
> >
> > __
> > Do You Yahoo!?
> > Tired of spam? Yahoo! Mail has the best spam
> > protection around
> > http://mail.yahoo.com
> >
>
>
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://m
Re: M2 migration status
Good news.. I just added a line
${basedir}
to surefire configuraiton for tomcat and built it
with
mvn -o -Dmodule=tomcat clean test
I think we can use this temporarily, until maven
guys decide to fix it.
Thanks
Anita
--- anita kulshreshtha <[EMAIL PROTECTED]> wrote:
>Few more things
> 1. Need to remove
>true
> in all *-builders.
> 2. All paths in java.io are resolved to user.dir
> which
> is the dir in which the jvm was invoked. M2 is not
> invoking the jvm in the correct directory. It causes
> all the paths to be resolved incorrectly. All the
> log
> files axis.log, login-audit.log, network.log are
> not
> created properly.
>
> Thanks
> Anita
>
> --- Prasad Kashyap <[EMAIL PROTECTED]>
> wrote:
>
> > All but just the following 4 modules to be
> migrated.
> >
> > interop
> > jetty
> > jetty-builder
> > axis-builder.
> >
> > Then there are the "almost-there" modules. These
> > modules have pending
> > work like one of the following -
> > 1. tests don't work due to surefire plugin's bugs
> > 2. properties/other resources are not procesed.
> > 3. properties/resources are not in the m2 dir
> > structure.
> >
> > Patches ready :
> > j2ee-builder :
> > http://issues.apache.org/jira/browse/GERONIMO-1713
> > axis-builder :
> > http://issues.apache.org/jira/browse/GERONIMO-1723
> >
> > Cheers
> > Prasad
> >
> > On 3/13/06, Prasad Kashyap
> > <[EMAIL PROTECTED]> wrote:
> > > j2ee-builder done. I have also pruned the
> > dependency lists for
> > > j2ee-builder and j2ee.
> > >
> > > Will update the patch now.
> > >
> > > Cheers
> > > Prasad
> > >
> > > On 3/13/06, Henri Yandell <[EMAIL PROTECTED]>
> > wrote:
> > > > On 3/10/06, Jacek Laskowski
> <[EMAIL PROTECTED]>
> > wrote:
> > > > > 2006/3/9, Henri Yandell
> <[EMAIL PROTECTED]>:
> > > > >
> > > > > > The geronimo-spec-j2ee-deployment module
> was
> > giving errors; but I
> > > > > > realised I was building under JDK 1.5. It
> > works fine under 1.4; so
> > > > > > something for the future there perhaps.
> > > > >
> > > > > I think I've seen a way to make sure that M2
> > is used on Java 1.4.
> > > > >
> > > > > Now, there might be a way to leverage it and
> > ensure Java 1.4 runtime.
> > > > >
> > > > > > Next I get errors from the Geronimo ::
> > Directory module; this is
> > > > > > because I'm being a aggressive and turning
> > off the snapshot
> > > > > > repositories in the top pom.
> directory-asn1
> > depends on commons-test,
> > > > > > which is unreleased. In this case the
> ideal
> > solution is to set
> > > > > > commons-test to test scope so it doesn't
> end
> > up in the build - I'll
> > > > > > work on getting that changed - or just
> > having them not depend on
> > > > > > commons-test :)
> > > > >
> > > > > Great. I'm looking forward to committing
> your
> > patch ;)
> > > >
> > > > Fixed it at the other end. The commons-test
> > dependency no longer gets
> > > > passed along transitively.
> > > >
> > > > Now I find that everything builds from the top
> > down - except for the 2
> > > > Tomcat tests that already appear to be being
> > looked into. This is with
> > > > the snapshot repositories commented out - they
> > slow things down and
> > > > seem to lead to errors that mean I have to
> keep
> > repeating the build
> > > > until they've finally downloaded things.
> There's
> > some way to change
> > > > their strategy I think - must look into this.
> > > >
> > > > Slowly moving axis-builder along. Looks like
> the
> > Maven xmlbeans plugin
> > > > depends on a snapshot version of xmlbeans, so
> > that's irritating :)
> > > >
> > > > Hen
> > > >
> > >
> >
>
>
> __
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam
> protection around
> http://mail.yahoo.com
>
__
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Re: M2 migration status
Few more things 1. Need to remove true in all *-builders. 2. All paths in java.io are resolved to user.dir which is the dir in which the jvm was invoked. M2 is not invoking the jvm in the correct directory. It causes all the paths to be resolved incorrectly. All the log files axis.log, login-audit.log, network.log are not created properly. Thanks Anita --- Prasad Kashyap <[EMAIL PROTECTED]> wrote: > All but just the following 4 modules to be migrated. > > interop > jetty > jetty-builder > axis-builder. > > Then there are the "almost-there" modules. These > modules have pending > work like one of the following - > 1. tests don't work due to surefire plugin's bugs > 2. properties/other resources are not procesed. > 3. properties/resources are not in the m2 dir > structure. > > Patches ready : > j2ee-builder : > http://issues.apache.org/jira/browse/GERONIMO-1713 > axis-builder : > http://issues.apache.org/jira/browse/GERONIMO-1723 > > Cheers > Prasad > > On 3/13/06, Prasad Kashyap > <[EMAIL PROTECTED]> wrote: > > j2ee-builder done. I have also pruned the > dependency lists for > > j2ee-builder and j2ee. > > > > Will update the patch now. > > > > Cheers > > Prasad > > > > On 3/13/06, Henri Yandell <[EMAIL PROTECTED]> > wrote: > > > On 3/10/06, Jacek Laskowski <[EMAIL PROTECTED]> > wrote: > > > > 2006/3/9, Henri Yandell <[EMAIL PROTECTED]>: > > > > > > > > > The geronimo-spec-j2ee-deployment module was > giving errors; but I > > > > > realised I was building under JDK 1.5. It > works fine under 1.4; so > > > > > something for the future there perhaps. > > > > > > > > I think I've seen a way to make sure that M2 > is used on Java 1.4. > > > > > > > > Now, there might be a way to leverage it and > ensure Java 1.4 runtime. > > > > > > > > > Next I get errors from the Geronimo :: > Directory module; this is > > > > > because I'm being a aggressive and turning > off the snapshot > > > > > repositories in the top pom. directory-asn1 > depends on commons-test, > > > > > which is unreleased. In this case the ideal > solution is to set > > > > > commons-test to test scope so it doesn't end > up in the build - I'll > > > > > work on getting that changed - or just > having them not depend on > > > > > commons-test :) > > > > > > > > Great. I'm looking forward to committing your > patch ;) > > > > > > Fixed it at the other end. The commons-test > dependency no longer gets > > > passed along transitively. > > > > > > Now I find that everything builds from the top > down - except for the 2 > > > Tomcat tests that already appear to be being > looked into. This is with > > > the snapshot repositories commented out - they > slow things down and > > > seem to lead to errors that mean I have to keep > repeating the build > > > until they've finally downloaded things. There's > some way to change > > > their strategy I think - must look into this. > > > > > > Slowly moving axis-builder along. Looks like the > Maven xmlbeans plugin > > > depends on a snapshot version of xmlbeans, so > that's irritating :) > > > > > > Hen > > > > > > __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com
Re: [jira] Commented: (MSUREFIRE-78) forkMode=once or pertest does not work on windows
Oops! The link is to File in javadoc Thnaks Anita --- anita kulshreshtha <[EMAIL PROTECTED]> wrote: > The jvm is being forked in the geronimo > directory. > All the paths in java.io are resolved against > user.dir > file:///D:/mytools/javadoc1.4/docs/api/index.html > I have tested that the user.dir is set to > /geronimo > and not .../geronimo/modules/a-module. > > Thnaks > Anita > > --- Prasad Kashyap <[EMAIL PROTECTED]> > wrote: > > > Since security is not working for me I cannot > > recreate your scenario > > and debug it. But if you can find the same problem > > in any other > > module, please let me know and I'll try it out for > > you. > > > > Let me also know if it this problem occurs with > > 2.1.3 or 2.2 version > > of the surefire plugin. > > > > Cheers > > Prasad > > > > On 3/17/06, anita kulshreshtha > <[EMAIL PROTECTED]> > > wrote: > > > comments inline. > > > > > > --- Prasad Kashyap > <[EMAIL PROTECTED]> > > > wrote: > > > > > > > There are issues with the 2.2-SNAPSHOT. > > > > > > > > 1. With the connector module: > > > > The connector module tests don't fail but > spews > > a > > > > lot, A LOT, of a > > > > java.lang.AssertError. > > > > > > > > 2. With the "basedir" system property: > > > > The system property "basedir" set by the > > > > connector-builder module > > > > seems to be stuck and used by other modules > > > > following it. So the tests > > > > for the client-builder fails. When > > client-builder > > > > module's > > > > PlanParsingTest reads the "basedir" system > > property, > > > > it gets it as set > > > > to connector-builder !! If you skip the > > > > client-builder tests, then > > > > tests of directory module downstream fails for > > the > > > > same reason. When > > > > you skip the connector-builder tests, the > > "basedir" > > > > is set to j2ee, > > > > another module further upstream. > > >I think the problem is that surefire is > not > > > forking the jvm in the correct directory. > > > For example if mvn -Dmodule=security is used > > > basedir is set correctly to > > > ..geronimo/modules/security (have tested this > with > > > 2.1.3-SNAPSHOT). > > > But the jvm is forked in geronimo directory. In > > maven1 > > > maven.junit.dir could be used to set this > > directory. > > > But surefire does not have a similar property. > So > > I > > > can not test this. But this does expalin the > > strange > > > paths like > > > ...geronimo/./target/. in many modules. > > > Does this make sense? > > > > > > Thnaks > > > Anita > > > > > > > > > > > > > > The same problems are not seen in surefire > > > > 2.1.3-SNAPSHOT plugin. > > > > > > > > Cheers > > > > Prasad > > > > > > > > On 3/16/06, Prasad Kashyap > > > > <[EMAIL PROTECTED]> wrote: > > > > > I added the following section to the > > > > and now it > > > > > downloaded the surefire-plugin 2.2-SNAPSHOT. > > But > > > > it also downloaded a > > > > > LOT of other pluigns too. So I am not sure > if > > what > > > > I did was right. > > > > > > > > > > > > > > > > > > > > true > > > > > > > > > > Apache CVS > > > > > Apache CVS of the Central > > > > Repository > > > > > > > > > > > > > > > http://cvs.apache.org/maven-snapshot-repository > > > > > > > > > > > > > > > Cheers > > > > > Prasad > > > > > > > > > > On 3/16/06, Prasad Kashyap > > > > <[EMAIL PROTECTED]> wrote: > > > > > > Hmm.. I tried to use the 2.2-SNAPSHOT. It > > > > couldn't find that in any repo. > > > > > > > > > > > > I tried to build it. But the copy in the > > trunk > > > > still says, 2.1.3-SNAPSHOT . > > > > > > > > > > > > > > > > (http://svn.apache.org/viewcvs.cgi/maven/plugins/trunk/maven-surefire-plugin/pom.xml?view=markup) > > > > > > > > > > > > I couldn't find the discussion in the > maven > > dev > > > > list that Brett mentioned. > > > > > > > > > > > > I am missing something here. > > > > > > > > > > > > > > > > > > Cheers > > > > > > Prasad > > > > > > > > > > > > > > > > > > On 3/16/06, anita kulshreshtha > > > > <[EMAIL PROTECTED]> wrote: > > > > > > > Jacek, > > > > > > > We need to change to surefire-plugin > > version > > > > > > > 2.2-SNAPSHOT. > > > > > > > > > > > > > > Thnaks > > > > > > > Anita > > > > > > > Note: forwarded message attached. > > > > > > > > > > > > > > > > > > > > > > > > > > > __ > > > > > > > Do You Yahoo!? > > > > > > > Tired of spam? Yahoo! Mail has the best > > spam > > > > protection around > > > > > > > http://mail.yahoo.com > > > > > > > > > > > > > > > > > > > > > -- Forwarded message -- > > > > > > > From: "Brett Porter (JIRA)" > > > > <[EMAIL PROTECTED]> > > > > > > > To: [EMAIL PROTECTED] > > > > > > > Date: Wed, 15 Mar 2006 20:16:32 -0600 > > (CST) > > > > > > > Subject: [jira] Commented: > (MSUREFIRE-78) > > > > forkMode=once or pertest does not work on > > windows > > > > > > > [ > > > > > > > > > > http://jira.codehaus.org/bro
Re: M2 migration status
All but just the following 4 modules to be migrated. interop jetty jetty-builder axis-builder. Then there are the "almost-there" modules. These modules have pending work like one of the following - 1. tests don't work due to surefire plugin's bugs 2. properties/other resources are not procesed. 3. properties/resources are not in the m2 dir structure. Patches ready : j2ee-builder : http://issues.apache.org/jira/browse/GERONIMO-1713 axis-builder : http://issues.apache.org/jira/browse/GERONIMO-1723 Cheers Prasad On 3/13/06, Prasad Kashyap <[EMAIL PROTECTED]> wrote: > j2ee-builder done. I have also pruned the dependency lists for > j2ee-builder and j2ee. > > Will update the patch now. > > Cheers > Prasad > > On 3/13/06, Henri Yandell <[EMAIL PROTECTED]> wrote: > > On 3/10/06, Jacek Laskowski <[EMAIL PROTECTED]> wrote: > > > 2006/3/9, Henri Yandell <[EMAIL PROTECTED]>: > > > > > > > The geronimo-spec-j2ee-deployment module was giving errors; but I > > > > realised I was building under JDK 1.5. It works fine under 1.4; so > > > > something for the future there perhaps. > > > > > > I think I've seen a way to make sure that M2 is used on Java 1.4. > > > > > > Now, there might be a way to leverage it and ensure Java 1.4 runtime. > > > > > > > Next I get errors from the Geronimo :: Directory module; this is > > > > because I'm being a aggressive and turning off the snapshot > > > > repositories in the top pom. directory-asn1 depends on commons-test, > > > > which is unreleased. In this case the ideal solution is to set > > > > commons-test to test scope so it doesn't end up in the build - I'll > > > > work on getting that changed - or just having them not depend on > > > > commons-test :) > > > > > > Great. I'm looking forward to committing your patch ;) > > > > Fixed it at the other end. The commons-test dependency no longer gets > > passed along transitively. > > > > Now I find that everything builds from the top down - except for the 2 > > Tomcat tests that already appear to be being looked into. This is with > > the snapshot repositories commented out - they slow things down and > > seem to lead to errors that mean I have to keep repeating the build > > until they've finally downloaded things. There's some way to change > > their strategy I think - must look into this. > > > > Slowly moving axis-builder along. Looks like the Maven xmlbeans plugin > > depends on a snapshot version of xmlbeans, so that's irritating :) > > > > Hen > > >
