Re: JIRA Mangled?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Aaron Mulder wrote: > Starting an hour or two ago, I'm having all kinds of trouble with JIRA > bug pages showing up mangled. Usually they come up with some text > that clearly should be markup and then lay out wrong, or I get two > whole copies of the bug content side by side, but one time a page came > up looking like a text version of a binary file. Both Safari and > Firefox are doing the same thing for me, both on Mac and Linux. For > example: > > in the middle of http://issues.apache.org/jira/browse/GERONIMO-1450 > > 200 OK > > Definitely a jira problem. [same in Firefox WinXP] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFD19UraCoPKRow/gARAil/AKCLsWQN6yuhlKbnwzbt80RPCVI2qwCgnIIy 2+GV+BdgJwaf/1NbeI6GhO0= =kVxM -END PGP SIGNATURE-
Re: geronimo build failed (again and again)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yoseph Widjaya wrote: | Hi geronimoer | | I just d/l the fresh and building using maven seems | like there is a files that cannot be read here is the | error log coming from the build | | Unable to obtain goal [plugin:install] -- | /home/yosep/.maven/cache/maven-plugin-plugin-1.5.2/plugin.jelly:56:37: | Failed to copy | /home/yosep/geronimo/plugins/geronimo-packaging-plugin/target/geronimo-packaging-plugin-0.1.1.jar | to | /usr/java/maven/plugins/geronimo-packaging-plugin-0.1.1.jar | due to | /usr/java/maven/plugins/geronimo-packaging-plugin-0.1.1.jar | (Permission denied) | Total time: 56 seconds | Finished at: Sun Jun 26 07:16:06 EST 2005 | | | any idea | | thanks | | __ | Do You Yahoo!? | Tired of spam? Yahoo! Mail has the best spam protection around | http://mail.yahoo.com | | Might want to make sure the user (yosep) running the build has permission to write to the plugins directory (/usr/java/maven/plugins) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCvioHaCoPKRow/gARAiF1AKDDNSnXukUQVjDVTi0CSAueWgLHPgCgxbqK E1mOpR/Gm7L9etLiwVxJXY4= =H0Cr -END PGP SIGNATURE-
Re: Stable/Unstable/Sandbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Jencks wrote: | | I don't know about fair, but I am finding this discussion nearly as | distracting as the previous one that we put on hold. I still don't see | what exotic svn tricks might buy us over normal svn usage, and don't | want to spend a lot of time thinking about it until we pass all the | tests. I still think everyones perspective may change once we are | passing all the tests and have fixed the few egregious architectural | problems that crept in. | | I would like to put this discussion on hold until we pass all the tests | | thanks | david jencks Agreed. I'm still in favor of 'modification of structure' in the interests of ease of localized maintenance and possible deployment/deliverable options not currently available, but I'd much rather put that on a "TODO" list for after certification than take more time now to discuss it. Very difficult to advocate "certification first" and "restructure thoughts now" when those involved in the certification process would undoubtedly need to be in on the restructure thoughts process. First things first. My .02 Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCnP38aCoPKRow/gARAuJCAKC6Abi1oUVMJA7Gq9wRAJyUsQo1DgCgprU0 nUtdvbP7y8vvNN4vvQvwVZk= =7+VS -END PGP SIGNATURE-
Re: [VOTE] Certification stability
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Blevins wrote: | We are having a lot of great discussion which should continue. I do want to make sure we are getting somewhere, so let's all vote that we at least agree on one form of stability; certification. Probably obvious, but one step toward inching our way to some form of agreement on stability. | | VOTE: Certification status is our primary mark of stability at this time. | | Note this is not the multiple choice variety we usually do. Just +1/+0/-0/-1 the statement above and give your $0.02 on negative votes. | | -David | | +1 (non-binding) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCnPidaCoPKRow/gARAteXAKDzC+8pT13YgXfQKVqUqbhx8UjongCgwicG GoTnSuuBZCxatUF8fsh6GNw= =ZfpT -END PGP SIGNATURE-
Re: Stable/Unstable/Sandbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Blevins wrote: | | Just going to throw out that I think the only goal we can all agree on is to not regress on certification once we achieve it. | | -David | Combined with not slowing down progress on attaining that certification. :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCnPbfaCoPKRow/gARAotlAKCpKqZNTRBvUz4yJENzXSYgZM6pAACeOXNn /Qaa/eRFdNLRRT0ozT02pDc= =Qex9 -END PGP SIGNATURE-
Re: Geronimo subprojects?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 David Jencks wrote: | So far I am completely unconvinced by any arguments in this thread. | | As a thought experiment, lets suppose we had already released a | certified geronimo, say last month, and we had solved most of our build | problems, say with maven2. So, we have a certified branch and trunk, | and all the geronimo developers are happily working on new features on | trunk. | | In this scenario exactly what needs changing and why? | | thanks | david jencks | I don't believe there's anything wrong with your 'thought experiment'. My view is, however, that never is there work to be done everywhere in a project. Taking your scenario above - all developers are happily working on new features on trunk and there's a security problem in a particular module. What went from "there's nothing wrong with this approach" now shifts to "we need to get this fixed as soon as possible" for a particular module. Again, this is most certainly doable with the structure as-is. However, a faster fix/test/release cycle would be possible if the module was able to handle it at that level instead of involving the whole of geronimo's code and developer base for everything from "if your code involves this module" (perhaps a 'new feature' not in any way involved with what the bug is) to testing and documentation. I don't think there is a "right" or "wrong" way to do it. Both work. I personally believe smaller is better - then integrate. I also believe this would promote multiple 'pre-built' deployment options (not "make it possible", just promote). But I'm only one person. Just proposing options for greater flexibility. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCmLSJaCoPKRow/gARAg35AJ9IfDwevATEMfyEuwv2JWMVoHygugCdFmLU qat86jpRD2Qu4ifDT4Upe48= =gXBM -END PGP SIGNATURE-
Re: Geronimo subprojects?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: | |> My questions at the root of this are: |> ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of |> a 'minimal' Geronimo? Is it able to claim anything with regard to the |> TCK? | | | It depends on the specifications the subproject is implementing and if | Sun has a stand-alone tck for the specifications. For example, if it | were the Geronimo 'just a webserver edition' we could certify it for | servlets and jsp because they have standalone tcks, but if it were tx | and jca we could not certify it since there are no standalone tcks for | those specs. Understood. My main question was if there was some sort of 'prohibition' on the use of 'full system' pass/fail statistics for those pieces that do, in fact, have their own tcks. [I don't view this as a roadblock to anything, but a definite plus if each individual piece that was able (due to having and passing their own tcks) could state it passes.] | | On the other hand, I'm sure if enough people are interested, sufficient | pressure could be applied to Sun to carve a stand-alone tck out of the | j2ee monolith. This I would see as a 'good thing'. Amazing how software has progressed (*cough*) to 'smaller components combined into larger applications', but tests (even certifications) aren't quite there yet. | |> ~ 2. In stating "there is a demonstrated desire", what roadblocks or |> opposition is there to having each of the current modules (short of the |> kernel, common, core and presumably deployment - and anything else |> needed for the server to start-up and do nothing) each be |> 'self-contained'? Obviously the 'base' server would have to know what |> it's really capable of (unless you go off the deep end with discovery), |> but over and above that base it seems that a WebConnector - be it Jetty |> for user 1 or Tomcat for user 2 may be used with or without Naming, with |> or without Spring and/or Transactions, etc. Why would there be a need to |> limit modules just to what there is a "demonstrated desire" to have? | | | Each subproject has an inherent amount of overhead. For example, each | subproject needs a separate project management committee, each one will | need to produce releases (not an easy task) and so on. I would sat | that "there is a demonstrated desire" when we have enough people | showing up to handle the overhead and work on the code. I personally | would say one person is not enough, and seven is more then enough. Agreed. My view here would be to take the position "Here is the 'best laid plan', who is willing to make it work" instead of "Here is how people are working, what's the best plan we can come up with that doesn't affect that". Granted, there will probably be pieces that should probably be split out without resources to manage it, but if you aim high you have a better chance of getting an optimal solution in place. And nothing says that this can't be further refined down the road. | |> Making everything as small and self-contained (even if they don't 'run' |> on their own) seems to be a smart move in allowing a bug in one module |> to be fixed and made available without waiting on anything else (how |> many times have we wanted a typo fixed that had to wait for a completely |> new feature to be implemented?). | | | I think there are technical and realistic limits to this. Some modules | are simply to small to be full projects. For example the rmi | classloadder is like 5 classes. Also some modules naturally fit | together and have a high degree of coupling. For example the Tx | manager and the j2ca implementation naturally fit together. Now you | can use the Tx manager standalone, but you can't really use j2ca | without a Tx manager. Because of that linking the modules normally move | together. I would say we put both in one sub project and have them | release two jars. | | -dain Agreed here as well. The RMI classloader is what I consider 'too small to make it worth it' and fell in to my "as small and self-contained" as possible. Possible should be read with the implication of 'realistic'. My view on the tx/j2ca type of 'module' is tempered with "overhead costs" and agree that those types of modules may be best combined as you stated. (although removal of that tempered view thinks they should be separate, with the j2ca simply having a dependency on tx.) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCmLImaCoPKRow/gARAvX6AJ9Q54WWyRF1M7K6drBBBsOtbSdtrACeMJW3 LhwcnkO+Bqm9EtvL9h0fSsA= =ssHt -END PGP SIGNATURE-
Re: Geronimo subprojects?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dain Sundstrom wrote: | I just read through the long "Module restructure" thread, and it to me | is seems like many people are talking about how we break Geronimo into | subprojects without using the word subproject. The goals of the | "Module restructure" thread seem to be: | | 1) allow modules to branch to unstable without requiring the geronimo | trunk to take unstable code | 2) allow modules to have independent release cycles so they don't have | to wait for geronimo trunk | | Regardless what we call it, that is a sub project. I think we should | bite the bullet and talk about what sets of functionality make sense as | a subproject. For example, I think there is a demonstrated desire to | have a TX/JCA subproject in Geronimo. | | -dain | | Agreed. And this, if properly combined with 'common deployments', could be a major step toward getting new users more interested. Undoubtedly it will require a shift in developer processes, but in the long run it would (in theory - application of that theory being more in procedure than possibility) make fixes and enhancements swifter. My questions at the root of this are: ~ 1. Assuming the whole of Geronimo passes the TCK, what can be said of a 'minimal' Geronimo? Is it able to claim anything with regard to the TCK? ~ 2. In stating "there is a demonstrated desire", what roadblocks or opposition is there to having each of the current modules (short of the kernel, common, core and presumably deployment - and anything else needed for the server to start-up and do nothing) each be 'self-contained'? Obviously the 'base' server would have to know what it's really capable of (unless you go off the deep end with discovery), but over and above that base it seems that a WebConnector - be it Jetty for user 1 or Tomcat for user 2 may be used with or without Naming, with or without Spring and/or Transactions, etc. Why would there be a need to limit modules just to what there is a "demonstrated desire" to have? Making everything as small and self-contained (even if they don't 'run' on their own) seems to be a smart move in allowing a bug in one module to be fixed and made available without waiting on anything else (how many times have we wanted a typo fixed that had to wait for a completely new feature to be implemented?). My thoughts... Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCmKh6aCoPKRow/gARAmOpAKCVANxfB36tX36emF6nLvKy+a/IkACghrzo nG3rKqN5K3CNVFIEWPDSKjg= =BFcE -END PGP SIGNATURE-
Re: Module restructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Jeremy Boynes wrote: | Brian K. Wallace wrote: | |> |> Wouldn't the proper use of svn:externals take care of a lot of this? |> have svn co geronimo basically read from the externals to pull whatever |> modules (as well as other components) you want while letting each module |> handle its own stable/unstable structure? [obviously have a standard for |> that structure would be HIGHLY desirable] Might be a chore setting up |> those externals at first, but after that it'd just be there (unless new |> modules/etc were added) |> | | | All our modules are in the same SVN repo so we don't need to use | externals, we can just copy. This would be a good option for integrating | other projects if we needed to do that at the source level. AIUI though | they would also need to be on SVN and not all are. | | -- | Jeremy | | Don't need, and can't use aren't quite the same, tho'. This was the part that led me to believe (erroneously) that this thread was about deliverables only. In your example: .../geronimo/stable/1.0/modules/transaction .../geronimo/stable/1.2/modules/transaction .../geronimo/stable/2.0/modules/transaction .../geronimo/unstable/1.3/modules/transaction .../geronimo/unstable/2.1/modules/transaction I'd think that transaction (as well as all other modules) might have stable, unstable, as well as 'releases'. stable (above) could just externalize transaction's stable (along with all the other modules), as could unstable and 'releases' at that higher level. Obviously this would have to be an SVN only exercise, but if you can allow a user/developer to check out X and hide that X is made up of 50 different 'externals', but also allow them to check out just 1 of those 50 modules without having to dig through an entire structure... ? Not thinking you were on track to restructure quite that much, so I'll go back to 'observing'. :-) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCl7KKaCoPKRow/gARAqsSAJ9jd9TCHzDKo3Jevs9/3x22jEJLiQCg0rOd rI/bBEIW5t8tUn/Gkq1SPOI= =V9zh -END PGP SIGNATURE-
Re: Module restructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alan D. Cabrera wrote: | | | Jeremy Boynes wrote, On 5/27/2005 7:26 PM: | |> David Blevins wrote: |> |> This one |> |>> |>> ../repos/asf/geronimo/unstable/modules/transaction |>> ../repos/asf/geronimo/stable/modules/transaction |>> | Why would we have two versions of transaction? | | | Regards, | Alan | | | Wouldn't the proper use of svn:externals take care of a lot of this? have svn co geronimo basically read from the externals to pull whatever modules (as well as other components) you want while letting each module handle its own stable/unstable structure? [obviously have a standard for that structure would be HIGHLY desirable] Might be a chore setting up those externals at first, but after that it'd just be there (unless new modules/etc were added) -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCl67YaCoPKRow/gARAlgcAJ49h37F3OBvnPiPpR5V2GPj+XqCUQCg2s8b BhOfXzsntTFnFzw82VLIedY= =wtD9 -END PGP SIGNATURE-
Re: Module restructure
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Stefan Arentz wrote: | ... | | Security-wise it is also a nightmare. There is so much stuff running in | the container that I have no idea of. I usually bind the instance to | localhost and do port translation for those TCP/IP services that need | to be exposed, but even then there are still many ways to connect to it | from localhost that could potentially expose information or give | control to unauthorized people. | | S. | Exactly. And seeing another huge "everything to everyone" server is why I never got motivated to do more than observe Geronimo. I'd be better served keeping up on what I have to do to keep my existing 'monolith' as secure as possible. If it can be broken down, re-arranged, reassembled - and still "just work", it would be THE server to use - not just "another" server. Brian -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (MingW32) iD8DBQFCl2kZaCoPKRow/gARAtT0AKDTGdqFdKGwhwMqVOmsSGkKPLXkXgCeL2vr ua9uF67yfhbZMVPcztRL7IM= =qcty -END PGP SIGNATURE-
Re: Module restructure
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Stefan Arentz wrote:
| On May 27, 2005, at 6:07 PM, Jeremy Boynes wrote:
|
|> Stefan brings up the question of whether we want to release sub-
|> modules of Geronimo separately. I think this is a good idea and would
|> propose the following restructure of the tree to move in this direction.
|
|
| Let me just explain my motivation a bit, maybe that will also help for
| the plan.
|
| In my original email I said something about not needing all the J2EE
| stuff. I exaggerated a bit of course, but most of the applications that
| I have been writing in the last couple of years are done mostly with a
| subset of the whole J2EE umbrella. Some apps were just some network
| service wrapped in (JMX) beans, a service exposed with Spring (Burlap,
| XML-RPC) other apps were simply a web app backed by a shared Spring
| context. I've never needed all the stuff in J2EE.
|
| So far I've always done this on JBoss. Their MBean stuff works ok, but
| I wish it was easier to 'downsize' jboss to just a container with the
| stuff I need. That never really seemed to be their goal however. The
| complexity of their configuration files shows that.
|
| So, what I would really like to see wrt Geronimo is an absolute minimal
| server with add-on packages for things like a web container, jms
| provider, etc. You want to host a web app? Throw in the Tomcat or Jetty
| personality. Need JMS too, add ActiveMQ. Persistence? Simply add a
| hibernate deployer. Mix and match so that it does what your app needs.
|
| This is where Geronimo could shine and even take away a large chunk of
| Tomcat; most people just want to deploy their web app and optionally
| add some more services without having to understand a full J2EE stack.
| Geronimo can fill that void extremely well I think. (Simple Web
| Container .. .. J2EE Monolith)
|
| Ok so just complaining doesn't work well for this project, so what I
| really would like to do is start figuring out how I can give Geronimo
| 'personalities' for popular combinations of technology. Like,
|
| - Geronimo Kernel + Tomcat + JSTL2.0 + Spring + Hibernate
| - Geronimo Kernel + Web Services
| - Geronimo Kernel + JMX Enabled custom network service
|
| and then do some writing about it on the wiki. Make recipes for people,
| or even complete packages that are downloadable.
|
| I really think this is how Geronimo can also get acceptance with a much
| larger crowd.
|
| S.
|
I'm not a committer, nor have I been more than an observer to what
Geronimo is doing and where it's going - primarily because everything
I've seen has placed it in the JBoss realm. I've used JBoss for quite a
while and am always amazed at the functionality it has ingrained in it
for which I just have no use. Most of my time spent upgrading is in
finding out how to turn things off that have changed.
This message caught my attention. For the first time, I've seen that I'm
not the only person who things this might be a good idea. I don't want
the world in a server - I just want to be able to add the pieces if/when
I need them to an existing server. This is something JBoss bypasses
entirely... you want to be able to add the pieces? voila - they're added
- - enjoy - whether you wanted them all 'built-in' or not.
I do think this will lead to greater adoption by new users (as well as
those others who want what I do - "the minimal server to do the job,
with expansion capabilities"), as well as greater 'user questions' ("Why
do I get this error?" "Because you don't have the Web Services package
installed/configured"). Questions can be documented all over the place
and users will still come to the mailing list and ask. That, however,
IMHO, is much better than those users already having a "monolith" and
sticking with it rather than move to a Geronimo "monolith" (monolith
used here not in a single application of monolithic proportions, but the
server with mandated functionality that, even when disabled, is still
taking up space). And I'm a firm believer that "it's on the Wiki" isn't
a substitute for good documentation included in the product - it's an
added method of documentation.
As for the pre-packaged versions - I think this would, indeed, be a boon
to Geronimo - - - as long as the individual 'services' were packaged for
some sort of 'drop-in deployment' into an existing Geronimo server as well.
My thoughts...
Brian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFCl2YbaCoPKRow/gARAnMNAJ9gxTlKzzp3pRHfd8i2GfQfvl8aIACgru71
6+OCdlthfHuBXTqUKB8JSR8=
=/uYw
-END PGP SIGNATURE-
