Re: Discuss: Move Geronimo to Attic
ther we could move then to another community. >>>>> Ideally with still using the org.apache.geronimo groupId and packages. >>>>> Otherwise it would be quite some problem for the users. >>>>> >>>>> LieGrue, >>>>> strub >>>>> >>>>>> Am 09.03.2017 um 14:46 schrieb Alex Karasulu <akaras...@apache.org>: >>>>>> >>>>>> I think more important than whether or not JEE is popular (or whatever >>>>>> along those lines), are the questions about community health and is the >>>>>> PMC still capable of fulfilling its duties. >>>>>> >>>>>> My 2 cents, >>>>>> --Alex >>>>>> >>>>>> On Thu, Mar 9, 2017 at 12:08 PM, Mark Struberg <strub...@yahoo.de> wrote: >>>>>> Romain and I went through the Geronimo SVN and made a list of which >>>>>> components are used by other projects. >>>>>> >>>>>> >>>>>> Useful Geronimo components from >>>>>> https://svn.apache.org/repos/asf/geronimo/ >>>>>> >>>>>> https://svn.apache.org/repos/asf/geronimo/KEYS >>>>>> >>>>>> https://svn.apache.org/repos/asf/geronimo/components/txmanager >>>>>> • TomEE (txmgr+connector) >>>>>> • Meecrowave (txmgr) >>>>>> • Aries (txmgr) >>>>>> >>>>>> https://svn.apache.org/repos/asf/geronimo/components/geronimo-schema-javaee_6 >>>>>> >>>>>> https://svn.apache.org/repos/asf/geronimo/genesis/ >>>>>> • Maven parents for geronimo-specs >>>>>> >>>>>> https://svn.apache.org/repos/asf/geronimo/javamail/ >>>>>> • TomEE as delivery >>>>>> • Lot of standalone >>>>>> • -> we can ask Hendrik pby >>>>>> >>>>>> https://svn.apache.org/repos/asf/geronimo/specs/ >>>>>> • TomEE >>>>>> • OpenWebBeans >>>>>> • Meecrowave >>>>>> • OpenJPA >>>>>> • Johnzon >>>>>> • BatchEE >>>>>> • Karaf >>>>>> • Aries >>>>>> • Tons of external customer projects which don’t want to use some >>>>>>official javax jars due to licensing concerns >>>>>> >>>>>> https://svn.apache.org/repos/asf/geronimo/xbean/ >>>>>> • TomEE >>>>>> • OpenWebBeans >>>>>> • Meecrowave >>>>>> • Aries >>>>>> • Karaf >>>>>> • OpenJPA >>>>>> • CXF (supported) >>>>>> >>>>>> Osgi-locator too but guess this one can drop and belong to karaf or >>>>>> servicemix. >>>>>> Q: well we need the osgi locator in our geronimo-specs, isn’t? >>>>>> >>>>>> >>>>>> I've created a google doc. Just ping me if you want to edit something >>>>>> and I'll share it. >>>>>> >>>>>> David, you mentioned JASPIC. I could not find that even. Is this inside >>>>>> the geronimo-server probably? >>>>>> Are there other gems which are not maintained as components but just >>>>>> inside geronimo? >>>>>> >>>>>> txs and LieGrue, >>>>>> strub >>>>>> >>>>>> >>>>>>> Am 09.03.2017 um 08:44 schrieb David Jencks <david.a.jen...@gmail.com>: >>>>>>> >>>>>>> I go back and forth on whether to shut G down completely. Perhaps it >>>>>>> would be useful to inventory which parts are used by which other >>>>>>> projects? Off the top of my head…. >>>>>>> >>>>>>> Specs …. who uses G’s and who has their own? >>>>>>> >>>>>>> Components…. I think there are several users of the transaction >>>>>>> manager, I don’t know about the connector framework, and I’m pretty >>>>>>> sure no one uses my jaspic implementation. The TM is stable but now >>>>>>> that faster than spinning rust persistent memory is popular the logger
Re: Discuss: Move Geronimo to Attic
On March 8, 2017 at 10:44:45 AM, Mark Struberg (strub...@yahoo.de) wrote: Alan, I understand that you don't want to put much more energy into this project. That is totally understandable and fine. But while you are PMC chair you still cannot declare that the project is dead as long as there are enough PMC members still active to keep the project going. Mark, I agree with Alan and Kevan, though put into my own words I think the project and community is no longer viable (and has not been for a while). I do believe there are still useful aspects to the project, but I don’t think its enough to leave on its own. We can certainly wait for more PMC members to chime in if they are still monitoring. As Jeff recommended I’m including the private@ list for PMC folks that may not be paying as much attention to the dev@ list. Before we dump the project I suggest we start with an analysis of where we are right now. What about starting look into .) Who is still active and willing to continue Geronimo as a ee-commons project? So far I’ve not really seen anyone over the past days of communication about this. But we’ll see. —jason .) Which project parts of the project are of some shared interest and might be good to get some maintenance love and some realistic chance that this is gonna happening? I can’t speak for the others, but I have zero interested in putting any love in to any of what is presently here. I will defer to others to explain if they feel otherwise, though I do recall some chatter on private@ but will probably need those folks to re-post to dev@ to include that discussion. —jason
Re: Updating Geronimo site automation was: Cron jdillon@minotaur /home/jdillon/ws/site/bin/sync
Heh, are you saying it would be cool with you if I look into it? :-P --jason On Thursday, June 14, 2012 at 1:03 PM, Kevan Miller wrote: On Jun 14, 2012, at 2:04 PM, Jason Dillon wrote: Anyone want to look into setting this up? If not I can look into it further when I've got some free time. Hey Jason, That'd be cool with me. Thanks! --kevan
Updating Geronimo site automation was: Cron jdillon@minotaur /home/jdillon/ws/site/bin/sync
Anyone want to look into setting this up? If not I can look into it further when I've got some free time. --jason On Thursday, June 14, 2012 at 7:09 AM, Kevan Miller wrote: On Jun 13, 2012, at 11:25 PM, Forrest Xia wrote: On Thu, Jun 14, 2012 at 5:06 AM, Jason Dillon jdil...@apache.org (mailto:jdil...@apache.org) wrote: Is this site sync stuff still in use? Hi Jason, I think they are still in use to sync svn content to geronimo web site folder. Anyone else know more details about this? As far as I understand, this must change by the end of 2012 -- http://www.apache.org/dev/project-site.html and there have been emails sent to the PMC. See http://www.apache.org/dev/project-site.html for more information. The sooner this occurs the better, IMO… --kevan
Fw: Cron jdillon@minotaur /home/jdillon/ws/site/bin/sync
Is this site sync stuff still in use? --jason Forwarded message: From: Cron Daemon jdil...@apache.org To: jdil...@apache.org Date: Wednesday, June 13, 2012 2:05:06 PM Subject: Cron lt;jdillon@minotaurgt; /home/jdillon/ws/site/bin/sync svn: E155036: Please see the 'svn upgrade' command svn: E155036: Working copy '/x1/home/jdillon/ws/site' is too old (format 10, created by Subversion 1.6) svn: E155036: Please see the 'svn upgrade' command svn: E155036: Working copy '/x1/home/jdillon/ws/site' is too old (format 10, created by Subversion 1.6)
BTW… WOW
Its been a long time since I fired up the server, but I just did (to look at the keystore muck) and WOW. 3.0 looks really nice... from the web-console at least. I still have issue with the text-console you are using, but eh whatever ;-) Nice work folks! --jason
Re: low entropy on linux systems
Installing rngd/rng-tools also can help fix these sorts of problems. --jason On Jul 14, 2011, at 7:19 PM, Kevan Miller wrote: From time to time I encounter a problem starting a Geronimo server on a Linux system (I've always seen it on Ubuntu -- but the problem could exist on other distributions). The server start seems to hang. However, if you're patient, which I rarely am, the server will eventually start. If you're inquisitive, and dump the stack traces of the java process, you'll see something like: main prio=10 tid=0x40c0d800 nid=0xa79 runnable [0x7f57a04fb000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:220) at sun.security.provider.NativePRNG$RandomIO.readFully(NativePRNG.java:185) at sun.security.provider.NativePRNG$RandomIO.implGenerateSeed(NativePRNG.java:202) - locked 0xdaad63e0 (a java.lang.Object) at sun.security.provider.NativePRNG$RandomIO.access$300(NativePRNG.java:108) at sun.security.provider.NativePRNG.engineGenerateSeed(NativePRNG.java:102) at java.security.SecureRandom.generateSeed(SecureRandom.java:495) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.getSalt(PKCS12KeyStore.java:477) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.calculateMac(PKCS12KeyStore.java:834) at com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore.engineStore(PKCS12KeyStore.java:788) - locked 0xd3b5a768 (a com.sun.net.ssl.internal.pkcs12.PKCS12KeyStore) at java.security.KeyStore.store(KeyStore.java:1117) ... This problem isn't Geronimo specific. But since I see it from time to time, thought it would be worth passing along to the community... The Sun/Oracle-based JVM is attempting to generate a pseudo-random number to be used as a seed for an SSL server socket. To generate the pseudo-random number, the JVM is reading from the /dev/random device to obtain some random information for the seed. The problem is that reads from the /dev/random device will block if the system does not have a good source of random events. So, the Geronimo server startup is blocked waiting for enough random information to be returned from /dev/random. This article may be help understand the basic issue -- http://en.wikipedia.org/wiki//dev/random#Linux I'm no security expert. And I don't know the potential implications, but the simplest way that I've found to avoid the problem is to use the /dev/urandom device, instead of /dev/random. Do this by specifying the following java property '-Djava.security.egd=file:/dev/./urandom'. So, the following should work well: $ GERONIMO_OPTS=-Djava.security.egd=file:/dev/./urandom ./geronimo run --long Note to self -- would be nice to record this on our Wiki somewhere. Anyway, hope this is useful... --kevan
Re: Rename the term j2ee to javaee or jee in G3.0?
Come on just use javaee, and be done with it. --jason On Jan 29, 2010, at 9:22 PM, Donald Woods wrote: You cannot use JEE to refer to Java EE. We had several instances of the JEE usage on our OpenJPA website/docs and were politely reminded of the correct naming by one of our PMC members who works for Sun :-) For distribution names (like zip and plugin filenames) I agree that we need to come up with a consistent naming scheme that is compatible with the Sun guidelines. BUT, in the source code, I would argue we can use jee all we want, as they are internal variables/attribute names. -Donald On 1/29/10 3:00 AM, Jack Cai wrote: I remember that jee is not a good abbreviation. So maybe javaee or ee. -Jack On Fri, Jan 29, 2010 at 3:11 PM, Shawn Jiang genspr...@gmail.com mailto:genspr...@gmail.com wrote: Good idea if following concerns are addressed: 1, This might break some user's existing deployment plan. 2, Doc and Example need update as well after such a change. On Fri, Jan 29, 2010 at 11:09 AM, Rex Wang rwo...@gmail.com mailto:rwo...@gmail.com wrote: hi, I think it is a good time to stop calling j2ee in our new Geronimo. There are a lot of places using this term, such as plugin project names, artifact names, j2eeType... So which one is more appropriate, javaee or jee? Any thoughts? -- Lei Wang (Rex) rwonly AT apache.org http://apache.org -- Shawn
Re: Is there any plan to migrate existing geronimo shell commands from gshell to karaf shell in geronimo 3.0 ?
On Nov 4, 2009, at 2:31 PM, Shawn Jiang wrote: Geronimo 2.x has its own shell which bases on gshell uses groovy to define commands.(I don't kown why but I don't like this) BTW, I only used Groovy for the launching commands because of the nice integration with Ant... and because of the desire to have platform independent scripts to control muck on launch. The rest of those commands should probably have been pure Java. --jason
Re: Do we want to apply genesis 2.0 resource filtering best practice ?
Me too :-) I guess that is why I put that in there, just never
updated projects to use it.
--jason
On Jul 16, 2009, at 1:08 PM, David Jencks wrote:
On Jul 15, 2009, at 10:46 PM, Shawn Jiang wrote:
I noticed there's a maven resource best practice defined in genesis-
default-flava-2.0.pom.
1, Put normal resource under : ${project.basedir}/ src/main/resources
2, Put the resource that needs filtering under: ${project.basedir}/
src/main/filtered-resources
At the same time, many projects in Geronimo does not follow this
practice. A JIRA was opened for this : https://issues.apache.org/jira/browse/GERONIMO-4737
If no objection, I'm going to use GERONIMO-4737 to fix this kind of
problems in current code base. Any comments ?
Looks like a good idea to me!
thanks
david jencks
--
Shawn
Re: Setup a Geonimo FAQ ?
So... go to town... or am I missing something? --jason On Jul 7, 2009, at 12:42 PM, Shawn Jiang wrote: OK, I also noticed that Knowledge Base page can be found as FAQ in geronimo homepage. FAQ Browse SpaceAdd Page View Edit Attachments (0) Info Added by Jason Dillon, last edited by Jason Dillon on Jun 22, 2006 (view change) Labels: (None) EDIT --- Seems it has not been updated from 2006. We need to 1, Remove some stale content. 2, Add some new FAQ there. Hope that can reduce FAQ questions in mailing list. On Tue, Jul 7, 2009 at 1:08 PM, Jason Dillon ja...@planet57.com wrote: The Knowledge Base was intended to be the home for FAQ-ish thingys. --jason On Jul 7, 2009, at 12:04 PM, Shawn Jiang wrote: Obviously, there are really some FAQ in the mailing list such as 1, Lib conflict including myface, spring 2, Log4j 3, JPA JTA/Non-JTA DS requirement. 4, web-service out of memory 5, Classloading problem caused by bad EAR package structure. .. We need a formal page to record these FAQ. (only found two related page [1] and [2] with google). [1]http://docs.huihoo.com/apache/geronimo/1.1/geronimo-eclipse-plugin-faq.html [2]http://cwiki.apache.org/GMOxKB/index.html -- Shawn -- Shawn
Re: Setup a Geonimo FAQ ?
The Knowledge Base was intended to be the home for FAQ-ish thingys. --jason On Jul 7, 2009, at 12:04 PM, Shawn Jiang wrote: Obviously, there are really some FAQ in the mailing list such as 1, Lib conflict including myface, spring 2, Log4j 3, JPA JTA/Non-JTA DS requirement. 4, web-service out of memory 5, Classloading problem caused by bad EAR package structure. .. We need a formal page to record these FAQ. (only found two related page [1] and [2] with google). [1]http://docs.huihoo.com/apache/geronimo/1.1/geronimo-eclipse-plugin-faq.html [2]http://cwiki.apache.org/GMOxKB/index.html -- Shawn
Re: svn commit: r790675 - /geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/geronimo/blueprint/container/BlueprintContainerImpl.java
On Jul 2, 2009, at 11:56 PM, gno...@apache.org wrote:
eventDispatcher.blueprintEvent(new
BlueprintEvent(BlueprintEvent.DESTROYED,
getBundleContext().getBundle(), getExtenderBundle()));
-LOGGER.debug(Module container destroyed: +
this.bundleContext);
+LOGGER.debug(Blueprint container destroyed: +
this.bundleContext);
}
This should probably be:
LOGGER.debug(Blueprint container destroyed: {}, this.bundleContext);
--jason
Framework as its own sub-project?
Is it time to make framework its own sub-project? Seems like it would reduce some complexity if the bits needed to `mvn -Dstage=bootstrap install` where separate... leaving server to pull in its outputs, build plugins and then assemble. Eventually plugins can be split off. But right now it looks like the framework modules are fairly well isolated. Is it time to split framework from server? --jason
[jira] Created: (GSHELL-163) Upgrade to org.apache.sshd 0.1.0
Upgrade to org.apache.sshd 0.1.0 Key: GSHELL-163 URL: https://issues.apache.org/jira/browse/GSHELL-163 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Commands - SSH Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-163) Upgrade to org.apache.sshd 0.1.0
[ https://issues.apache.org/jira/browse/GSHELL-163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-163. --- Resolution: Fixed Upgrade to org.apache.sshd 0.1.0 Key: GSHELL-163 URL: https://issues.apache.org/jira/browse/GSHELL-163 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - SSH Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GERONIMO-4709) start-server's -j flag does not work
[ https://issues.apache.org/jira/browse/GERONIMO-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GERONIMO-4709: --- Summary: start-server's -j flag does not work (was: start-servers' -j flag does not work) start-server's -j flag does not work Key: GERONIMO-4709 URL: https://issues.apache.org/jira/browse/GERONIMO-4709 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.4 Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 2.1.5, 2.2 Problem is that node.setAttribute(String, String) won't coerce 2nd param of type java.io.File to string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GERONIMO-4709) start-servers' -j flag does not work
start-servers' -j flag does not work Key: GERONIMO-4709 URL: https://issues.apache.org/jira/browse/GERONIMO-4709 Project: Geronimo Issue Type: Bug Security Level: public (Regular issues) Components: commands Affects Versions: 2.1.4 Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 2.1.5, 2.2 Problem is that node.setAttribute(String, String) won't coerce 2nd param of type java.io.File to string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4709) start-server's -j flag does not work
[ https://issues.apache.org/jira/browse/GERONIMO-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GERONIMO-4709. -- Resolution: Fixed start-server's -j flag does not work Key: GERONIMO-4709 URL: https://issues.apache.org/jira/browse/GERONIMO-4709 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Affects Versions: 2.1.4 Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 2.1.5, 2.2 Problem is that node.setAttribute(String, String) won't coerce 2nd param of type java.io.File to string. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r788006 - /geronimo/server/trunk/framework/modules/geronimo-commands/src/main/groovy/org/apache/geronimo/commands/StartServerCommand.groovy
I guess no one ever tested the start-server -j flag, cause its been
broke for a long time. Should work now though.
--jason
On Jun 24, 2009, at 7:56 PM, jdil...@apache.org wrote:
Author: jdillon
Date: Wed Jun 24 12:56:16 2009
New Revision: 788006
URL: http://svn.apache.org/viewvc?rev=788006view=rev
Log:
(GERONIMO-4709) Allow start-server -j to work
Modified:
geronimo/server/trunk/framework/modules/geronimo-commands/src/
main/groovy/org/apache/geronimo/commands/StartServerCommand.groovy
Modified: geronimo/server/trunk/framework/modules/geronimo-commands/
src/main/groovy/org/apache/geronimo/commands/StartServerCommand.groovy
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/framework/modules/geronimo-commands/src/main/groovy/org/apache/geronimo/commands/StartServerCommand.groovy?rev=788006r1=788005r2=788006view=diff
=
=
=
=
=
=
=
=
==
--- geronimo/server/trunk/framework/modules/geronimo-commands/src/
main/groovy/org/apache/geronimo/commands/StartServerCommand.groovy
(original)
+++ geronimo/server/trunk/framework/modules/geronimo-commands/src/
main/groovy/org/apache/geronimo/commands/StartServerCommand.groovy
Wed Jun 24 12:56:16 2009
@@ -135,7 +135,7 @@
}
log.info(Using Java virtual machine:
$javaVirtualMachine)
-node.setAttribute('jvm', javaVirtualMachine)
+node.setAttribute('jvm',
javaVirtualMachine.absolutePath)
}
javaFlags.each {
Re: Eliminating the svn repo
It would be great to get rid of the local repo in svn. I forget, but I think jtidy is needed by the muck that generates html reports for whatever reason. Would be good to get the dwr and dojo stuff published. BTW, we are using some really old versions of dojo, any chance on updating those? --jason On Jun 24, 2009, at 3:40 PM, David Jencks wrote: The svn repo is a terrible idea and violates the principle that all the dependencies of anything in the maven central repo, must be in the maven central repo. I've been working to remove the need for stuff in there with some success. What's left is: jtidy. This appears to be a dependency only of the testsuite-maven- plugin. The project is not very active, although it is built with maven 2. Does anyone know what exactly it's used for? Can we get rid of it? Otherwise I guess we'll have to see if we can get the project to release something. directwebremoting. Our version (2.0.5) appears to have been released but not to a maven repo. There's a 3.0.M1 released milestone. I suggest we try it and see if it works for us. Does anyone know if the 2.0.3 version would work? dojo. I don't know what's in our 0.4.3 dojo-ajax and 1.1.1 dojo- mini jars but I see maven releases of dojo-war at 1.1.1, 1.2 and 1.3 Maybe we can extract what we need from this. Are we still using the 0.4.3 stuff? There's a 0.4.3 dojo-rhino jar. maybe it's related. thanks david jencks
Re: genesis-flava - genesis-default-flava
I spent a lot of hours with genesis 1.x looking through all the poms for the setting that was causing behavior I was wondering about to want to eliminate every bit of unnecessary complexity I could. In the event we come up with a flava that doesn't want to inherit from default-flava we can put it as a direct child of the root genesis project. Fair enough :-) I also changed the groupId to o.a.g.genesis from o.a.g.genesis.flava. why? Fewer groupIds == simpler better IMO. I don't see what the additional groupId adds except complexity and chance for confusion. Am I missing something? Its just a tool for organizing similar modules, like packages in java. I tend to organize stuff, which is why I put all flava's into their own groupId. --jason
genesis-flava - genesis-default-flava
Why was this module change made? If I recall I setup genesis-flava and genesis-default-flava (as a child of the previous) on purpose. Why was this changed? --jason
Re: genesis-flava - genesis-default-flava
On Jun 22, 2009, at 11:03 PM, David Jencks wrote: On Jun 22, 2009, at 6:58 AM, Jason Dillon wrote: Why was this module change made? If I recall I setup genesis-flava and genesis-default-flava (as a child of the previous) on purpose. Why was this changed? Because I couldn't see the purpose. What good did genesis-flava do? It seemed to me that it only required maven to load one more pom for every genesis-using project. If you don't like genesis- java*-flava being children of genesis-default-flava then I think we should still avoid genesis-flava and make all the genesis-*-flava children of genesis. I think I did that because I was unsure that every flava would want to include all of the default java stuff. Your only problem is the download of an additional pom? I also changed the groupId to o.a.g.genesis from o.a.g.genesis.flava. why? --jason
Re: Assemblies in the repo and their dependencies
I am having trouble getting trunk to build atm, so I looked at 2.1
first. Right away this bit of magic in the pom failed:
snip
execution
idcopy-framework/id
phaseprocess-resources/phase
goals
goalrun/goal
/goals
configuration
tasks
mkdir dir=$
{project.build.directory}/assembly/
copy todir=$
{project.build.directory}/assembly
fileset dir=$
{project.build.directory}/unpack/geronimo-framework-${version}
/fileset
/copy
java
classname=org.apache.geronimo.jaxws.builder.GShellCommandRegistration
fork=yes failonerror=true
classpath
refid=maven.runtime.classpath/
arg value=$
{project.build.directory}/assembly/
arg value=gsh-wsgen.properties/
/java
/tasks
/configuration
/execution
/snip
Obviously because the antrun classpath did not pick up anything,
easily resolved by using dependencies for this plugin (or moving to
gmaven, still unsure if mvn can handle redef of the plugin with
dependencies in cases like this).
Then build dies missing legal files:
snip
[INFO] [tools:verify-legal-files {execution: verify-legal-files}]
[INFO] Checking legal files in: geronimo-tomcat6-javaee5-2.1.5-
SNAPSHOT-bin.zip
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Artifact does not contain any legal files: geronimo-tomcat6-
javaee5-2.1.5-SNAPSHOT-bin.zip
[INFO]
[INFO] For more information, run Maven with the -e switch
[INFO]
[INFO] Total time: 1 minute 13 seconds
[INFO] Finished at: Thu Jun 18 20:03:26 ICT 2009
[INFO] Final Memory: 99M/177M
[INFO]
/snip
So at least on 2.1 there looks to be some thing about dependency scope
which is needed for the assembly to function. Once I get trunk to
build I will check there too.
--jason
On Jun 18, 2009, at 4:31 AM, David Jencks wrote:
On Jun 17, 2009, at 1:36 AM, Jason Dillon wrote:
Why do the assemblies in the repository have dependencies? I
realize that they are probably there to facilitate the build, but
shouldn't they all be marked as scopeprovided/scope?
The reason I think they should be, is that when a user wants to use
the geronimo-maven-plugin with the assembly -bin in the repository,
before they can even download the assembly -bin, first mvn has to
go resolve every single dependency which is used to build that
assembly -bin.
I think this is broken, while I can resolve by adding a tone of
excludes, I think that this problem should be solved so that users
can more easily consume the assembly artifacts we publish to the
repository.
Any one know how easy/feasible with the current stuff (trunk and
2.1.x) it would be to mark all dependencies as provided?
Just thinking about it I don't see why it would cause problems.
Would you like to try it and see if the server at least builds? If
there are no obvious problems I'd be fine with this change.
thanks
david jencks
--jason
Re: Assemblies in the repo and their dependencies
My trunk build keeps puking on: snip Missing: -- 1) org.apache.geronimo.ext.tomcat:jasper:jar:6.0.18-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file - DgroupId=org.apache.geronimo.ext.tomcat -DartifactId=jasper - Dversion=6.0.18-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.geronimo.ext.tomcat -DartifactId=jasper -Dversion=6.0.18-SNAPSHOT -Dpackaging=jar -Dfile=/ path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.codehaus.mojo.jspc:jspc-maven-plugin:maven-plugin:2.0-alpha-2 2) org.apache.geronimo.ext.tomcat:jasper:jar:6.0.18-SNAPSHOT /snip Where is this dep? --jason On Jun 18, 2009, at 4:31 AM, David Jencks wrote: On Jun 17, 2009, at 1:36 AM, Jason Dillon wrote: Why do the assemblies in the repository have dependencies? I realize that they are probably there to facilitate the build, but shouldn't they all be marked as scopeprovided/scope? The reason I think they should be, is that when a user wants to use the geronimo-maven-plugin with the assembly -bin in the repository, before they can even download the assembly -bin, first mvn has to go resolve every single dependency which is used to build that assembly -bin. I think this is broken, while I can resolve by adding a tone of excludes, I think that this problem should be solved so that users can more easily consume the assembly artifacts we publish to the repository. Any one know how easy/feasible with the current stuff (trunk and 2.1.x) it would be to mark all dependencies as provided? Just thinking about it I don't see why it would cause problems. Would you like to try it and see if the server at least builds? If there are no obvious problems I'd be fine with this change. thanks david jencks --jason
Re: Assemblies in the repo and their dependencies
hrm... weird... will try to clean some of my repo and build again. --jason On Jun 18, 2009, at 8:39 PM, Ivan wrote: It is in http://repository.apache.org/snapshots. But this site is in the root pom file, it should not have problem in downloading this module. Ivan 2009/6/18 Jason Dillon ja...@planet57.com My trunk build keeps puking on: snip Missing: -- 1) org.apache.geronimo.ext.tomcat:jasper:jar:6.0.18-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file - DgroupId=org.apache.geronimo.ext.tomcat -DartifactId=jasper - Dversion=6.0.18-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.apache.geronimo.ext.tomcat -DartifactId=jasper -Dversion=6.0.18-SNAPSHOT -Dpackaging=jar - Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) org.codehaus.mojo.jspc:jspc-maven-plugin:maven-plugin:2.0- alpha-2 2) org.apache.geronimo.ext.tomcat:jasper:jar:6.0.18-SNAPSHOT /snip Where is this dep? --jason On Jun 18, 2009, at 4:31 AM, David Jencks wrote: On Jun 17, 2009, at 1:36 AM, Jason Dillon wrote: Why do the assemblies in the repository have dependencies? I realize that they are probably there to facilitate the build, but shouldn't they all be marked as scopeprovided/scope? The reason I think they should be, is that when a user wants to use the geronimo-maven-plugin with the assembly -bin in the repository, before they can even download the assembly -bin, first mvn has to go resolve every single dependency which is used to build that assembly -bin. I think this is broken, while I can resolve by adding a tone of excludes, I think that this problem should be solved so that users can more easily consume the assembly artifacts we publish to the repository. Any one know how easy/feasible with the current stuff (trunk and 2.1.x) it would be to mark all dependencies as provided? Just thinking about it I don't see why it would cause problems. Would you like to try it and see if the server at least builds? If there are no obvious problems I'd be fine with this change. thanks david jencks --jason -- Ivan
Assemblies in the repo and their dependencies
Why do the assemblies in the repository have dependencies? I realize that they are probably there to facilitate the build, but shouldn't they all be marked as scopeprovided/scope? The reason I think they should be, is that when a user wants to use the geronimo-maven-plugin with the assembly -bin in the repository, before they can even download the assembly -bin, first mvn has to go resolve every single dependency which is used to build that assembly - bin. I think this is broken, while I can resolve by adding a tone of excludes, I think that this problem should be solved so that users can more easily consume the assembly artifacts we publish to the repository. Any one know how easy/feasible with the current stuff (trunk and 2.1.x) it would be to mark all dependencies as provided? --jason
Re: Assemblies in the repo and their dependencies
Okay, I will give it a shot on trunk first, if that works I will try on branches/2.1. --jason On Jun 18, 2009, at 4:31 AM, David Jencks wrote: On Jun 17, 2009, at 1:36 AM, Jason Dillon wrote: Why do the assemblies in the repository have dependencies? I realize that they are probably there to facilitate the build, but shouldn't they all be marked as scopeprovided/scope? The reason I think they should be, is that when a user wants to use the geronimo-maven-plugin with the assembly -bin in the repository, before they can even download the assembly -bin, first mvn has to go resolve every single dependency which is used to build that assembly -bin. I think this is broken, while I can resolve by adding a tone of excludes, I think that this problem should be solved so that users can more easily consume the assembly artifacts we publish to the repository. Any one know how easy/feasible with the current stuff (trunk and 2.1.x) it would be to mark all dependencies as provided? Just thinking about it I don't see why it would cause problems. Would you like to try it and see if the server at least builds? If there are no obvious problems I'd be fine with this change. thanks david jencks --jason
Re: Odd (c) text in 2.1.4 console
Okay, thx. /me wonders how we let that slide into an official release hrmmm --jason On Jun 16, 2009, at 1:20 PM, Shawn Jiang wrote: Jason, The odd message at the bottom of console is a known JIRA: https://issues.apache.org/jira/browse/GERONIMO-4605 On Tue, Jun 16, 2009 at 1:30 PM, Jason Dillon ja...@planet57.com wrote: Was using the 2.1.4+tomcat release and found this very odd: Also, why do we say Apache Tomcat/... instead of Geronimo+Tomcat/ 2.1.4? Totally agree with you that Geronimo+Tomcat/2.1.4 is more appropriate here. --jason -- Shawn
Re: Errors on console deploy not show in console
Why is that an extra operation to show the details of the error? Why not simply include the details? --jason On Jun 16, 2009, at 1:18 PM, Shawn Jiang wrote: There's a show details button to show the error. I agree that the *NOT* part should be hi-lighted. On Tue, Jun 16, 2009 at 1:34 PM, Jason Dillon ja...@planet57.com wrote: Why do we not show the error of a deployment, or in this case app start in the console: Also, shouldn't the *not* part be hi-lighted bold+red or something? It does not look all that dissimilar to a successful deploy+start, so it might be easily missed. --jason -- Shawn
Re: Default war deployed w/o plan gets /WebApp_ID context?
Even a random context would be better than always using / WebApp_ID... but I would imagine that it should first try and create a unique context from the filename, encoding muck as needed. Otherwise, how about something more like /webappcounter. --jason On Jun 16, 2009, at 1:15 PM, Shawn Jiang wrote: Agreed, use war file name as the default context is a good start. On Tue, Jun 16, 2009 at 2:01 PM, Ivan xhh...@gmail.com wrote: WebApp_ID is not so friendly, not sure when it begins, this should be improved, maybe we could use the war file's name as the default context. 2009/6/16 Jason Dillon ja...@planet57.com Aren't we trying to do something a little bit more intelligent about picking a context for deployed wars w/o a plan.xml? Seems like all of these default/... wars want to mount under / WebApp_ID... forcing me to make a plan for them, just to set the context. Is this how it always worked? --jason -- Ivan -- Shawn
Re: Default war deployed w/o plan gets /WebApp_ID context?
I have to retract this with some shame... *blush* I didn't realize that all of the silly webapps I was testing had their web-app id=WebApp_ID ... OMG. --jason On Jun 16, 2009, at 1:29 PM, Jason Dillon wrote: Even a random context would be better than always using / WebApp_ID... but I would imagine that it should first try and create a unique context from the filename, encoding muck as needed. Otherwise, how about something more like /webappcounter. --jason On Jun 16, 2009, at 1:15 PM, Shawn Jiang wrote: Agreed, use war file name as the default context is a good start. On Tue, Jun 16, 2009 at 2:01 PM, Ivan xhh...@gmail.com wrote: WebApp_ID is not so friendly, not sure when it begins, this should be improved, maybe we could use the war file's name as the default context. 2009/6/16 Jason Dillon ja...@planet57.com Aren't we trying to do something a little bit more intelligent about picking a context for deployed wars w/o a plan.xml? Seems like all of these default/... wars want to mount under / WebApp_ID... forcing me to make a plan for them, just to set the context. Is this how it always worked? --jason -- Ivan -- Shawn
Re: Default war deployed w/o plan gets /WebApp_ID context?
On Jun 16, 2009, at 2:40 PM, David Jencks wrote: On Jun 16, 2009, at 12:08 AM, Jason Dillon wrote: I have to retract this with some shame... *blush* I didn't realize that all of the silly webapps I was testing had their web-app id=WebApp_ID ... It's news to me that tomcat does this it must be a result of feeding the web.xml into digester. I'm pretty sure jetty ignores any id attributes this is pretty weird use of the id attribute IMHO and is certainly beyond the spec. thanks david jencks Hrm... maybe its not such a good thing to let Tomcat do that? --jason
Re: Default war deployed w/o plan gets /WebApp_ID context?
I think that is the case now, I was confused (still a little too) as to why the web-app id= was being used instead. --jason On Jun 16, 2009, at 4:15 PM, Rex Wang wrote: IMO, war file's name is more user friendly. -Rex 2009/6/16 Ivan xhh...@gmail.com WebApp_ID is not so friendly, not sure when it begins, this should be improved, maybe we could use the war file's name as the default context. 2009/6/16 Jason Dillon ja...@planet57.com Aren't we trying to do something a little bit more intelligent about picking a context for deployed wars w/o a plan.xml? Seems like all of these default/... wars want to mount under / WebApp_ID... forcing me to make a plan for them, just to set the context. Is this how it always worked? --jason -- Ivan
Re: svn commit: r785118 - /geronimo/server/trunk/pom.xml
Why is apache.snapshots old and apache.people.snapshots is new? --jason On Jun 16, 2009, at 4:17 PM, xuhaih...@apache.org wrote: Author: xuhaihong Date: Tue Jun 16 09:17:37 2009 New Revision: 785118 URL: http://svn.apache.org/viewvc?rev=785118view=rev Log: Update the id of old snapshot site people.apache.org to apache.people.snapshots Modified: geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=785118r1=785117r2=785118view=diff = = = = = = = = == --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Tue Jun 16 09:17:37 2009 @@ -2632,7 +2632,7 @@ specify where Genesis lives to pick it up any other repositories. -- repository -idapache.snapshots/id +idapache.people.snapshots/id nameApache Snapshots Repository/name urlhttp://people.apache.org/repo/m2-snapshot- repository/url layoutdefault/layout
Re: svn commit: r785118 - /geronimo/server/trunk/pom.xml
Why is server/trunk not using the new snapshots repository? --jason On Jun 16, 2009, at 4:47 PM, Ivan wrote: For in the root Apache 6 pom file, a snapshot site has a same id of apache.snapshots, which points to a new site : http://repository.apache.org/snapshots Thanks ! Ivan 2009/6/16 Jason Dillon ja...@planet57.com Why is apache.snapshots old and apache.people.snapshots is new? --jason On Jun 16, 2009, at 4:17 PM, xuhaih...@apache.org wrote: Author: xuhaihong Date: Tue Jun 16 09:17:37 2009 New Revision: 785118 URL: http://svn.apache.org/viewvc?rev=785118view=rev Log: Update the id of old snapshot site people.apache.org to apache.people.snapshots Modified: geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=785118r1=785117r2=785118view=diff = = = = = = = = == --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Tue Jun 16 09:17:37 2009 @@ -2632,7 +2632,7 @@ specify where Genesis lives to pick it up any other repositories. -- repository -idapache.snapshots/id +idapache.people.snapshots/id nameApache Snapshots Repository/name urlhttp://people.apache.org/repo/m2-snapshot- repository/url layoutdefault/layout -- Ivan
Re: svn commit: r785118 - /geronimo/server/trunk/pom.xml
The head of http://people.apache.org/repo/m2-snapshot-repository/ states: snip NOTE: Some projects have moved their snapshots to a new repository at http://repository.apache.org/snapshots . You should update your Maven builds to use the new repository url since the contents of this repository is also proxied and aggregated at the new url. /snip So it makes sense to use it and not add another repository into the mix. --jason On Jun 16, 2009, at 4:58 PM, Jason Dillon wrote: Why is server/trunk not using the new snapshots repository? --jason On Jun 16, 2009, at 4:47 PM, Ivan wrote: For in the root Apache 6 pom file, a snapshot site has a same id of apache.snapshots, which points to a new site : http://repository.apache.org/snapshots Thanks ! Ivan 2009/6/16 Jason Dillon ja...@planet57.com Why is apache.snapshots old and apache.people.snapshots is new? --jason On Jun 16, 2009, at 4:17 PM, xuhaih...@apache.org wrote: Author: xuhaihong Date: Tue Jun 16 09:17:37 2009 New Revision: 785118 URL: http://svn.apache.org/viewvc?rev=785118view=rev Log: Update the id of old snapshot site people.apache.org to apache.people.snapshots Modified: geronimo/server/trunk/pom.xml Modified: geronimo/server/trunk/pom.xml URL: http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=785118r1=785117r2=785118view=diff = = = = = = = = = = --- geronimo/server/trunk/pom.xml (original) +++ geronimo/server/trunk/pom.xml Tue Jun 16 09:17:37 2009 @@ -2632,7 +2632,7 @@ specify where Genesis lives to pick it up any other repositories. -- repository -idapache.snapshots/id +idapache.people.snapshots/id nameApache Snapshots Repository/name urlhttp://people.apache.org/repo/m2-snapshot- repository/url layoutdefault/layout -- Ivan
Re: Odd (c) text in 2.1.4 console
Kay :-) --jason On Jun 16, 2009, at 8:31 PM, Donald Woods wrote: It was in a rush to get the admin console security vulnerabilities fixed and everyone had a chance to review and test the changes that went in before 2.1.4 was released :-) -Donald Jason Dillon wrote: Okay, thx. /me wonders how we let that slide into an official release hrmmm --jason On Jun 16, 2009, at 1:20 PM, Shawn Jiang wrote: Jason, The odd message at the bottom of console is a known JIRA: https://issues.apache.org/jira/browse/GERONIMO-4605 https://issues.apache.org/jira/browse/GERONIMO-4605 On Tue, Jun 16, 2009 at 1:30 PM, Jason Dillon ja...@planet57.com mailto:ja...@planet57.com wrote: Was using the 2.1.4+tomcat release and found this very odd: Also, why do we say Apache Tomcat/... instead of Geronimo+Tomcat/2.1.4? Totally agree with you that Geronimo+Tomcat/2.1.4 is more appropriate here. --jason -- Shawn
Errors on console deploy not show in console
Why do we not show the error of a deployment, or in this case app start in the console: inline: Geronimo Console-1.jpg Also, shouldn't the *not* part be hi-lighted bold+red or something? It does not look all that dissimilar to a successful deploy+start, so it might be easily missed. --jason
Re: nabble needs attention
I think it was me... --jason On Jun 7, 2009, at 10:47 PM, David Jencks wrote: Apparently we're supposed to upgrade our nabble stuff... http://www.nabble.com/help/Answer.jtp?id=42skin=134 which you get to by clicking the are you the owner of this project warning link from e.g. http://www.nabble.com/Geronimo-f134.html So who _is_ the owner of this stuff? I haven't been able to figure out with a little googling. Maybe we should document on the wiki who has worked on these external resources? thanks david jencks
Re: svn commit: r767630 - /geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/geronimo/blueprint/Activator.java
Um, what kinda javadoc is this. From what I have seen stuff like this tends to stay, asis... so if you take the effort to check something like this in, why not add real docs? --jason On Apr 23, 2009, at 2:30 AM, gno...@apache.org wrote: Author: gnodet Date: Wed Apr 22 19:30:51 2009 New Revision: 767630 URL: http://svn.apache.org/viewvc?rev=767630view=rev Log: Remove todo Modified: geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/ apache/geronimo/blueprint/Activator.java Modified: geronimo/sandbox/blueprint/blueprint-core/src/main/java/ org/apache/geronimo/blueprint/Activator.java URL: http://svn.apache.org/viewvc/geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/apache/geronimo/blueprint/Activator.java?rev=767630r1=767629r2=767630view=diff = = = = = = = = == --- geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/ apache/geronimo/blueprint/Activator.java (original) +++ geronimo/sandbox/blueprint/blueprint-core/src/main/java/org/ apache/geronimo/blueprint/Activator.java Wed Apr 22 19:30:51 2009 @@ -43,8 +43,6 @@ /** * TODO: javadoc * - * TODO: handle ModuleContextListener - * * @author a href=mailto:dev@geronimo.apache.org;Apache Geronimo Project/a * @version $Rev: 760378 $, $Date: 2009-03-31 11:31:38 +0200 (Tue, 31 Mar 2009) $ */
Re: [Blueprint] A few things
On Apr 20, 2009, at 12:58 AM, Guillaume Nodet wrote: Here are a few points i'd like to discuss about the blueprint implementation: * logging api: should be use JUL, commons-logging, slf4j ? slf4j I hope... :-) --jason
Re: Whence the geronimo kernel?
On Mar 12, 2009, at 1:26 AM, David Jencks wrote: I believe that xbean-spring is still unnecessary noisy when compared to something like the Spring Bean Builder (http://www.grails.org/Spring+Bean+Builder ). That looks nice, but is there any syntax validation possible? I'm pretty much unwilling to use groovy for anything at this point due to my bad experiences with lack of pre-runtime syntax validation and unclear error messages writing some simple gshell commands. xml is really horrible but most editors do support validation against a schema. On the other hand, I think we could come up with something even shorter, clearer, and to the point, with syntax validation, using scala. Why Scala? --jason
[jira] Commented: (GERONIMO-4557) geronimo/stop-server -p 3099 can't shutdown a server with NamingPort changed to 3099 in config_substitutions.properties.
[ https://issues.apache.org/jira/browse/GERONIMO-4557?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12677271#action_12677271 ] Jason Dillon commented on GERONIMO-4557: This is not a GShell issue... its a Geronimo issue with its GShell command implementations. Moved from GSHELL to GERONIMO. In the future please do not file issues which are related to a Geronimo GShell command impl in the GSHELL JIRA project. geronimo/stop-server -p 3099 can't shutdown a server with NamingPort changed to 3099 in config_substitutions.properties. -- Key: GERONIMO-4557 URL: https://issues.apache.org/jira/browse/GERONIMO-4557 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Environment: XP + SUN JDK 1.5 + geronimo-tomcat-2.1.4-snapshot_20090225 Reporter: Shawn Jiang Assignee: Jason Dillon Reproduce steps: 1, Change NamingPort=3099 in var/config-substitutions.properties. 2, Use GShell command geronimo/start-server to start the server. 3, Use Use GShell command geronimo/stop-server -p 3099 to stop the server. Expected result: the server could be shutdown and return to the GShell command line mode. Actually result: The server can't be shutdown, can't return to the GShell command line. Root Cause: You have to use geronimo/start-server -p 3099 to start server if you want use geronimo/stop-server -p 3099 to stop the server. I believe there should not be a -p args for geronimo/start-server command. Instead, geronimo/start-server should read NamingPort=3099 in config.substitutions.properties to avoid the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Assigned: (GERONIMO-4557) geronimo/stop-server -p 3099 can't shutdown a server with NamingPort changed to 3099 in config_substitutions.properties.
[ https://issues.apache.org/jira/browse/GERONIMO-4557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon reassigned GERONIMO-4557: -- Assignee: (was: Jason Dillon) geronimo/stop-server -p 3099 can't shutdown a server with NamingPort changed to 3099 in config_substitutions.properties. -- Key: GERONIMO-4557 URL: https://issues.apache.org/jira/browse/GERONIMO-4557 Project: Geronimo Issue Type: Bug Security Level: public(Regular issues) Components: commands Environment: XP + SUN JDK 1.5 + geronimo-tomcat-2.1.4-snapshot_20090225 Reporter: Shawn Jiang Reproduce steps: 1, Change NamingPort=3099 in var/config-substitutions.properties. 2, Use GShell command geronimo/start-server to start the server. 3, Use Use GShell command geronimo/stop-server -p 3099 to stop the server. Expected result: the server could be shutdown and return to the GShell command line mode. Actually result: The server can't be shutdown, can't return to the GShell command line. Root Cause: You have to use geronimo/start-server -p 3099 to start server if you want use geronimo/stop-server -p 3099 to stop the server. I believe there should not be a -p args for geronimo/start-server command. Instead, geronimo/start-server should read NamingPort=3099 in config.substitutions.properties to avoid the problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Make framework build the entire framework server
On Feb 18, 2009, at 7:15 AM, David Jencks wrote: On Feb 17, 2009, at 12:14 PM, Donald Woods wrote: Sounds worth the time to try it out. Two requests: 1) If this works, we publish the framework assembly instead of the two minimal assemblies to the Download page for 2.2, as this would allow users to build their own custom minimal server assembly (and of course some docs telling users how to create the old minimal assembly from this new framework assembly.) I'm neutral or slightly +0.1 on this idea. I don't actually see how it relates to my proposal but if everyone agrees I'm fine with this idea. Less = more IMO, so I'm +1 2) If time permits, can we move or duplicate relevant testsuite modules into a new testsuite dir under either the framework dir or a new framework-testsuite dir, so that we can verify the basic framework cmdline scripts and installing plugins (like Jetty/Tomcat to make an equivalent minimal assembly)? I like this idea. For a few months now when I work on a plugin set (mconsole, activemq) I've included a custom server aseembly in the plugin group and added at least one integration test. This has really helped speed up feature development. IIUC you are proposing doing the same for framework. Sure, +1 --jason
Re: [VOTE] Use apache's nexus for release and snapshot staging and deployment
+1 --jason On Feb 18, 2009, at 2:17 AM, David Jencks wrote: Last week I noted that there's an apache nexus installation that we can use for staging and deployment... https://issues.apache.org/jira/browse/INFRA-1896 They suggest a vote on this, so here goes. Lets ask sonatype/infra to move geronimo to using nexus for deployment. +1 about time already +0 needs more thought -1... I prefer doing things the hard way :-D Vote open for 72 hours. thanks david jencks
Re: [DISCUSS] Release gshell 1.0-alpha2
On Feb 18, 2009, at 9:54 PM, Kevan Miller wrote: On Feb 17, 2009, at 12:32 PM, Jason Dillon wrote: None of those files are included in a release. They're part of the source release, whether or not they're in the binary distribution is irrelevant... The binary files (build, extract, etc) are pretty trivial. So, I wouldn't require a re-release for those... They look like somebody's private build tools. I doubt they should really be in svn. Some of them don't look like they'd work (i.e. rebuild is calling 'nukeTargets'). Sure, they could be removed, they are the scripts I run, I got tired of having to recreate them when my laptop drive kept crashing. NOTES.txt looks like a todo list. Prolly should be removed, but I wouldn't hold up a release for that either. Um, why would I want to remove a todo list? What about README.txt should that also be removed? The above files should be cleaned up on trunk... Why? Assume GShell.mdxml is generated by a tool, and therefore wouldn't require a license header. Are you using this as a development aid? This is the MagicDraw UML models for the project. * * * IMO, the source distribution already contains a top-level LICENSE.txt and NOTICE.txt and that should be good enough to cover any of the files which are in question. --jason
Re: [DISCUSS] Release gshell 1.0-alpha2
None of those files are included in a release. --jason On Feb 17, 2009, at 10:47 PM, Joe Bohn wrote: I ran rat against the tag and found the following files missing the Apache license header. These are probably alright because I don't see them included in any of the distribution artifacts ... but I thought I would check in just in case. ./NOTES.txt ./build ./extract ./gsh ./rebuild ./src/uml/GShell.mdxml Joe
Re: [VOTE] Release gshell 1.0-alpha2
+1 --jason On Feb 14, 2009, at 5:44 PM, Guillaume Nodet wrote: I've uploaded a release of gshell 1.0-alpha2. The staging repo is available at: http://people.apache.org/~gnodet/staging/gshell-1.0-alpha2 The svn tag is: https://svn.apache.org/repos/asf/geronimo/gshell/tags/gshell-1.0-alpha-2/ Please review and vote ! [ ] +1 Release gshell-1.0-alpha2 [ ] -1 Do not -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: svn commit: r744122 - /geronimo/gshell/tags/gshell-1.0-alpha-2/
What happened? --jason On Feb 13, 2009, at 9:26 PM, gno...@apache.org wrote: Author: gnodet Date: Fri Feb 13 14:26:06 2009 New Revision: 744122 URL: http://svn.apache.org/viewvc?rev=744122view=rev Log: Rollback release Removed: geronimo/gshell/tags/gshell-1.0-alpha-2/
Re: svn commit: r744122 - /geronimo/gshell/tags/gshell-1.0-alpha-2/
k --jason On Feb 13, 2009, at 10:01 PM, Guillaume Nodet wrote: I will commit a patch that is kinda blocking on windows. It's minimal, but has been raised while i was doing the release. So I will commit the patch and restart the release asap. 2009/2/13 Jason Dillon ja...@planet57.com: What happened? --jason On Feb 13, 2009, at 9:26 PM, gno...@apache.org wrote: Author: gnodet Date: Fri Feb 13 14:26:06 2009 New Revision: 744122 URL: http://svn.apache.org/viewvc?rev=744122view=rev Log: Rollback release Removed: geronimo/gshell/tags/gshell-1.0-alpha-2/ -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Commented: (GSHELL-159) NegativeArraySizeException is thrown when using just the Shell Impementation when running tests.
[ https://issues.apache.org/jira/browse/GSHELL-159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12673267#action_12673267 ] Jason Dillon commented on GSHELL-159: - This should have been fixed by the gshell-terminal module's jline terminal adapters. NegativeArraySizeException is thrown when using just the Shell Impementation when running tests. Key: GSHELL-159 URL: https://issues.apache.org/jira/browse/GSHELL-159 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Components: Wisdom Affects Versions: 1.0-alpha-2 Reporter: Edell Nolan Assignee: Jason Dillon Attachments: gshell-159.patch If just using the shell implementation when running tests - a real teminal may not be created and as a result the teminalWidth results in a negative value. Example: Is using the servicemix kernel gshell itests [localShell] ERROR org.apache.servicemix.kernel.gshell.core.LocalConsole - Exiti ng shell due to caught exception java.lang.NegativeArraySizeException java.lang.NegativeArraySizeException at java.lang.AbstractStringBuilder.init(AbstractStringBuilder.java:44) at java.lang.StringBuilder.init(StringBuilder.java:81) at org.apache.geronimo.gshell.wisdom.shell.ShellImpl.repeat(ShellImpl.ja va:265) at org.apache.geronimo.gshell.wisdom.shell.ShellImpl.run(ShellImpl.java: 242) at org.apache.servicemix.kernel.gshell.core.ShellWrapper.run(ShellWrappe r.java:81) at org.apache.servicemix.kernel.gshell.core.LocalConsole.run(LocalConsol e.java:125) at java.lang.Thread.run(Thread.java:595) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r744143 - /geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/shell/ShellImpl.java
Hrm, this should have been fixed by the gshell-terminal adapters...
and why that if () was removed.
--jason
On Feb 13, 2009, at 10:21 PM, gno...@apache.org wrote:
Author: gnodet
Date: Fri Feb 13 15:21:56 2009
New Revision: 744143
URL: http://svn.apache.org/viewvc?rev=744143view=rev
Log:
GSHELL-159: NegativeArraySizeException is thrown when using just the
Shell Impementation when running tests.
Modified:
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/shell/ShellImpl.java
Modified: geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/
main/java/org/apache/geronimo/gshell/wisdom/shell/ShellImpl.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/shell/ShellImpl.java?rev=744143r1=744142r2=744143view=diff
=
=
=
=
=
=
=
=
==
--- geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/shell/ShellImpl.java (original)
+++ geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/shell/ShellImpl.java Fri Feb
13 15:21:56 2009
@@ -238,7 +238,11 @@
String message =
application.getModel().getBranding().getWelcomeMessage();
if (message != null) {
io.out.print(message);
-io.out.println(repeat(-,
io.getTerminal().getTerminalWidth() - 1));
+int width = io.getTerminal().getTerminalWidth() - 1;
+if (width = 0) {
+width = 80;
+}
+io.out.println(repeat(-, width));
io.out.flush();
}
}
Re: Proposed build change to not run IT by default
Yay! Can you make them activate with -Dit plz? --jason On Feb 12, 2009, at 5:41 AM, David Jencks wrote: While I much prefer running the testsuite integration tests by default I think it is no longer a reasonable strategy. Due to the bootstrap requirements the default modules have to be in a default profile in the root pom. So, the no-it profile has all the default modules except testsuite in it. So far so good. However, there are now a few special purpose test servers scattered around the project, in at least activemq and mconsole. These build a minimal server with the associated plugin bits and make sure it starts and maybe does something simple. These are really really handy when you're working on that plugin set. However, we might not want to force everyone to run them all the time, so they ought to be in a profile. With the current setup we need to have a default profile with everything and a no-it profile without the custom servers. IMO this is too hard to maintain and we should have the real modules outside any profile and the integration tests in a with-it profile. This will presumably require changes to whatever scripts are running our automated builds to include the with-it profile. I've opened GERONIMO-4536 for this. I'm going to go ahead with this, we can roll it back if there are objections or problems. thanks david jencks
[jira] Commented: (GSHELL-157) Dynamically adding / removing commands does not work well
[ https://issues.apache.org/jira/browse/GSHELL-157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12671563#action_12671563 ] Jason Dillon commented on GSHELL-157: - Ya, a side effect of leaning on VFS to handle the storage, I notice there is a problem with setting/unsetting/setting aliases too. Dynamically adding / removing commands does not work well - Key: GSHELL-157 URL: https://issues.apache.org/jira/browse/GSHELL-157 Project: GShell Issue Type: Bug Security Level: public(Regular issues) Reporter: Guillaume Nodet Assignee: Guillaume Nodet Fix For: 1.0-alpha-2 When resolving commands, the command resolver uses a virtual file system. Unfortunately, the data for virtual file systems is always cached, which means that removing a command will still make it available for resolution. The cache problem is caused by the DelegateFileObject which does not refresh the underlying file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [GSHELL] Timeframe ?
maven-project-2.1.0-r72 is on the nexus instance on our zone, but looks like its not running, not sure why... will take a look in a bit. --jason On Feb 4, 2009, at 2:47 PM, Guillaume Nodet wrote: Done. I still have a problem with the dependency on maven-project-2.1.0-r72 which I can't found anymore. I will try to upgrade to 3.0-alpha-1 and see what it gives. On Wed, Feb 4, 2009 at 04:47, Jason Dillon ja...@planet57.com wrote: Yes, go ahead. --jason On Feb 4, 2009, at 3:04 AM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel before this month. Do you want me to roll back to genesis 1.6 ? On Mon, Jan 12, 2009 at 06:14, Jason Dillon ja...@planet57.com wrote: Well, I think its mostly Genesis 2.0 that is causing the lag on GShell's release. I'm going to see about fixing that this week, otherwise rolling back to the Genesis 1.6 stuff for the alpha-2. --jason On Jan 7, 2009, at 5:52 PM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel in the near future. What are the missing bits to release GShell soon ? On Fri, Oct 17, 2008 at 08:25, Jason Dillon jason.dil...@gmail.com wrote: The GShell APIs are getting closer and closer to stability. The major changes have all been committed, and I don't have any plans to make any other significant changes to the core APIs. What I am doing now is trying to slim down the core dependencies and speed up the boot time... and sorting out some of the many HACK/TODO comments which I've littered the codebase with. As for an alpha-2 release, I imagine that will be on the horizon soon. I don't plan on having all of the little things fixed before that, though I hope to sort out a few of the more significant ones before releasing. If I had to guess I'd say that the codebase should be in a position to be released in 2-4 weeks at present change velocity. --jason On Oct 16, 2008, at 2:23 PM, Guillaume Nodet wrote: In ServiceMix, we are considering upgrading to the latest trunk of GShell and I've already done the bigger part of the upgrade locally on my HD. Btw, I've committed a few small changes for that yesterday. However, I'm worried about the stability of gshell. We currently use an old and unreleased version of gshell, but I'd like to avoid such issue and having to rewrite this integration once more. Jason, what's your feeling about gshell's stability (in terms of APIs) and a possible ETA for a new release (be it alpha-2 or whatever) ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [GSHELL] Timeframe ?
That should be fine. --jason On Feb 4, 2009, at 3:40 PM, Guillaume Nodet wrote: I've just build gshell using maven-project-2.1.0-M1 and it builds and starts correctly. Maybe we sould use that one instead ? or does r72 includes other mandatory fixes ? On Wed, Feb 4, 2009 at 09:07, Jason Dillon ja...@planet57.com wrote: maven-project-2.1.0-r72 is on the nexus instance on our zone, but looks like its not running, not sure why... will take a look in a bit. --jason On Feb 4, 2009, at 2:47 PM, Guillaume Nodet wrote: Done. I still have a problem with the dependency on maven-project-2.1.0-r72 which I can't found anymore. I will try to upgrade to 3.0-alpha-1 and see what it gives. On Wed, Feb 4, 2009 at 04:47, Jason Dillon ja...@planet57.com wrote: Yes, go ahead. --jason On Feb 4, 2009, at 3:04 AM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel before this month. Do you want me to roll back to genesis 1.6 ? On Mon, Jan 12, 2009 at 06:14, Jason Dillon ja...@planet57.com wrote: Well, I think its mostly Genesis 2.0 that is causing the lag on GShell's release. I'm going to see about fixing that this week, otherwise rolling back to the Genesis 1.6 stuff for the alpha-2. --jason On Jan 7, 2009, at 5:52 PM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel in the near future. What are the missing bits to release GShell soon ? On Fri, Oct 17, 2008 at 08:25, Jason Dillon jason.dil...@gmail.com wrote: The GShell APIs are getting closer and closer to stability. The major changes have all been committed, and I don't have any plans to make any other significant changes to the core APIs. What I am doing now is trying to slim down the core dependencies and speed up the boot time... and sorting out some of the many HACK/TODO comments which I've littered the codebase with. As for an alpha-2 release, I imagine that will be on the horizon soon. I don't plan on having all of the little things fixed before that, though I hope to sort out a few of the more significant ones before releasing. If I had to guess I'd say that the codebase should be in a position to be released in 2-4 weeks at present change velocity. --jason On Oct 16, 2008, at 2:23 PM, Guillaume Nodet wrote: In ServiceMix, we are considering upgrading to the latest trunk of GShell and I've already done the bigger part of the upgrade locally on my HD. Btw, I've committed a few small changes for that yesterday. However, I'm worried about the stability of gshell. We currently use an old and unreleased version of gshell, but I'd like to avoid such issue and having to rewrite this integration once more. Jason, what's your feeling about gshell's stability (in terms of APIs) and a possible ETA for a new release (be it alpha-2 or whatever) ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: [GSHELL] Timeframe ?
Yes, go ahead. --jason On Feb 4, 2009, at 3:04 AM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel before this month. Do you want me to roll back to genesis 1.6 ? On Mon, Jan 12, 2009 at 06:14, Jason Dillon ja...@planet57.com wrote: Well, I think its mostly Genesis 2.0 that is causing the lag on GShell's release. I'm going to see about fixing that this week, otherwise rolling back to the Genesis 1.6 stuff for the alpha-2. --jason On Jan 7, 2009, at 5:52 PM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel in the near future. What are the missing bits to release GShell soon ? On Fri, Oct 17, 2008 at 08:25, Jason Dillon jason.dil...@gmail.com wrote: The GShell APIs are getting closer and closer to stability. The major changes have all been committed, and I don't have any plans to make any other significant changes to the core APIs. What I am doing now is trying to slim down the core dependencies and speed up the boot time... and sorting out some of the many HACK/TODO comments which I've littered the codebase with. As for an alpha-2 release, I imagine that will be on the horizon soon. I don't plan on having all of the little things fixed before that, though I hope to sort out a few of the more significant ones before releasing. If I had to guess I'd say that the codebase should be in a position to be released in 2-4 weeks at present change velocity. --jason On Oct 16, 2008, at 2:23 PM, Guillaume Nodet wrote: In ServiceMix, we are considering upgrading to the latest trunk of GShell and I've already done the bigger part of the upgrade locally on my HD. Btw, I've committed a few small changes for that yesterday. However, I'm worried about the stability of gshell. We currently use an old and unreleased version of gshell, but I'd like to avoid such issue and having to rewrite this integration once more. Jason, what's your feeling about gshell's stability (in terms of APIs) and a possible ETA for a new release (be it alpha-2 or whatever) ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
[jira] Commented: (GSHELL-156) Disable system bell by default
[ https://issues.apache.org/jira/browse/GSHELL-156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12668766#action_12668766 ] Jason Dillon commented on GSHELL-156: - I'm tempted to leave it in there just to annoy windows users, *nix and Mac OSX (which is a *nix system btw) don't disregard the bell, its just easier to configure if its on or off. I suggest you a) switch to a real operating system or b) google how to disable the bell from your cmd.exe (or whatever console app you are using). Disable system bell by default -- Key: GSHELL-156 URL: https://issues.apache.org/jira/browse/GSHELL-156 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Commands - Shell Affects Versions: 1.0-alpha-2 Environment: Windows Reporter: Chris Custine Assignee: Jason Dillon Priority: Minor Attachments: nobell.patch On WIndows, attempting to backspace at the beginning of a line causes the system bell to sound, thereby knocking many a user off their chair. I would recommend disabling this for the sake of Windows users. *nix systems and Mac OSX shells seem to disregard the system bell commands by default so disabling the system bell in the ConsoleReader by default shouldn't affect them adversely. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: git, hg or bzr for G development?
On Jan 28, 2009, at 12:07 AM, Kevan Miller wrote: What does git have that svn doesn't which makes you so interested in the subject? IIUC, the major advantages of GIT are: * offline commits - you can commit changes, even if online. * cheap branching - this would make it much simpler for individuals to create private local branches and work on implementing a particular feature, without interfering with other development they might be working on in the same code branch. * fast merging - given the cheap branching, you need to do a lot of merging, which GIT is supposed to do very well GIT would not be a replacement of SVN. The GIT repositories are actually mirroring svn. GIT would just be a new tool for accessing our code. There are some usages of GIT that would not fit well into an Apache project. For instance, I would not want to see project members using GIT as a private means of sharing code updates. Ultimately, code needs to get into our svn repo -- that's where we should be sharing code. Why do you have a problem with users sharing code via their own GIT repos? I guess I can kinda see your concern, but I'd expect folks with significant changes to the codebase to want to share their GIT repos with others *before* pushing those changes back into SVN. Barring any objections, I'm going to request that Geronimo be added to the GIT mirrors later this week. No objections here, so far I really like GIT, only thing I don't like is the huge wait while I setup my local repo due to the crazy ASF SVN singleton repository. --jason
Re: git, hg or bzr for G development?
On Jan 28, 2009, at 1:47 AM, Kevan Miller wrote: There are some usages of GIT that would not fit well into an Apache project. For instance, I would not want to see project members using GIT as a private means of sharing code updates. Ultimately, code needs to get into our svn repo -- that's where we should be sharing code. Why do you have a problem with users sharing code via their own GIT repos? I guess I can kinda see your concern, but I'd expect folks with significant changes to the codebase to want to share their GIT repos with others *before* pushing those changes back into SVN. Right. So, I wouldn't want a few people to decide to implement some new function, start sharing code (privately amongst themselves), and then dump it into svn. IIUC, GIT makes this pretty easy to do. Currently, this sort of activity would happen in an svn sandbox or via patches posted to a Jira. In either case the collaboration and work should be public. I want to make sure we maintain this. Jay's example of a security-related patch is a very compelling example as to why sharing code directly via GIT instead of SVN can be a good idea at times. Until *everyone* is using GIT and we have community policies governing its usage, svn and our mailing lists are where we need to be collaborating. Why does *everyone* need to use GIT? IMO it is just a tool, some folks might prefer BZR, HG or SVK, making use of the features/ advantages that each tool provides. I don't see why there would ever need to be a point where *everyone* is on the same tool since ATM the underlying authoritative and definitive location for the codebase is the ASF SVN. * * * I really don't see what the harm is that you seem worried about. I'm not sure that we need any policies governing its usage either, no more than we need guidelines on how some one uses /bin/vi or notepad.exe, unless you mean the content not the tool, and in that case I think the general docs we have on that is sufficient. IMO GIT allows for a much more flexible development model, and I really don't see why we'd want to take away that flexibly with tape (of the red kind). :-\ --jason
[jira] Reopened: (GERONIMO-4170) Upgrade Selenium version for Firefox 3
[ https://issues.apache.org/jira/browse/GERONIMO-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon reopened GERONIMO-4170: Assignee: Jason Dillon (was: Donald Woods) Upgrade Selenium version for Firefox 3 -- Key: GERONIMO-4170 URL: https://issues.apache.org/jira/browse/GERONIMO-4170 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: testsuite Affects Versions: 2.1.2, 2.2 Reporter: Donald Woods Assignee: Jason Dillon Priority: Minor Fix For: 2.2 The current Selenium 1.0-beta-1 artifacts do not support using Firefox3 (on Linux or MacOSX.) When a snapshot or next beta does support FF3, then we should upgrade. The current 1.0-SNAPSHOT artifacts as of the 20080627 version still does not work with FF3 on Linux. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GERONIMO-4170) Upgrade Selenium version for Firefox 3
[ https://issues.apache.org/jira/browse/GERONIMO-4170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GERONIMO-4170. -- Resolution: Fixed Fix Version/s: (was: 2.1.4) Upgraded to selenium-maven-plugin 1.0-rc-1 which uses selenium 1.0-beta-2 Upgrade Selenium version for Firefox 3 -- Key: GERONIMO-4170 URL: https://issues.apache.org/jira/browse/GERONIMO-4170 Project: Geronimo Issue Type: Improvement Security Level: public(Regular issues) Components: testsuite Affects Versions: 2.1.2, 2.2 Reporter: Donald Woods Assignee: Jason Dillon Priority: Minor Fix For: 2.2 The current Selenium 1.0-beta-1 artifacts do not support using Firefox3 (on Linux or MacOSX.) When a snapshot or next beta does support FF3, then we should upgrade. The current 1.0-SNAPSHOT artifacts as of the 20080627 version still does not work with FF3 on Linux. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: New selenium-m-p snap out...
Seems to work, I do get some failures in the testsuite ~5 of them, but I also see them in a clean checkout, so I went ahead and made the changes to use selenium-maven-plugin 1.0-rc-1 (which I just released). --jason On Fri, Jan 16, 2009 at 7:53 PM, Kevan Miller kevan.mil...@gmail.com wrote: On Jan 16, 2009, at 2:04 AM, Jason Dillon wrote: ... looks like it works fine with FF3. I'm gonna see how well it works in server/trunk and then will publish a release if it works. Excellent. Thanks Jason. --kevan
Using Nexus on zone?
Any comments on using the nexus install on the zone for the custom artifacts we need for our builds? I'd like to make this live. --jason
Re: Using Nexus on zone?
The process of adding artifacts is adding new bits to: https://svn.apache.org/repos/asf/geronimo/repository/trunk/ The nexus simply proxies/caches from this URL. --jason On Jan 16, 2009, at 7:56 PM, Kevan Miller wrote: On Jan 16, 2009, at 6:35 AM, Jason Dillon wrote: Any comments on using the nexus install on the zone for the custom artifacts we need for our builds? I'd like to make this live. Yes. I want to understand the process for adding artifacts to the repository. IMO, we must have community oversight of these resources and they must follow a release process. We currently have this, since the repository is part of each of our releases. --kevan
Re: [Discussion] Add a geronimo status command
File a JIRA, explaining what it does that you don't like and what you would prefer to see it do. --jason On Jan 15, 2009, at 1:06 PM, Jack Cai wrote: I found a relevant GShell command called geronimo/wait-for-server that might do the job. The command will check whether all relevent configurations are fully started. So we can issue something like - gsh -c geronimo/wait-for-server -u system -w manager -t 30 The command exits with code 0 if it finds the server, and code 100 if not. The unpleasant thing is, same as many GShell command, it will spit out a lot of constituent and exception information and results in an abnormal JVM shutdown upon failure. Is this something we want to improve in future? -Jack 2009/1/14 Ivan xhh...@gmail.com No sure whether we have a special command to query the deployed applications' status ( I know that we could get those status via JMX). If not, I guess that we could extend the Jack's ideas to query all the modules' status. We could provide more information about the module more than the list module command, such as context path for web applications etc Thanks for any comment ! 2009/1/13 Jack Cai greensi...@gmail.com In line below. 2009/1/13 Donald Woods dwo...@apache.org How do you propose to handle status while the server is starting or stopping? How many states would be returned? Would this also be exposed over JMX? Currently the kernel only has two status: running or not running. Do we want to add more status in it? But I assume it's not easy to get an accurate starting/stopping status. How would it really differ from the deployer list-modules command we already have? Maybe that command needs to return better rc/status/ message when the server is still starting/stopping or not started? The proposed command only deals with the kernel, and will provide meaningful exit code to indicate the status so that other programs can call this script to query server status. The list-modules command deals with the modules and is mostly for human interaction. -Jack -Donald Jack Cai wrote: I've seen users asking how to query server status [1], and recently I was also asked for the same question by a colleague. So I think maybe it's good that Geronimo provide a cross-platform means for querying server status. After looking into the code that does server shutdown, I realize it's pretty easy to achieve that. All I need to do is to - 1. Refactor the org.apache.geronimo.deployment.cli.StopServer class to something more general, e.g., ServerControl. We can make it to do status query or shutdown based on an extra parameter that's passed in, or make it a super class and create another 2 subclasses to do status query and shutdown respectively. 2. Add a new command to the geronimo.(sh/bat) script, e.g., status. And based on how Step 1 is done, we can either reuse the shutdown.jar (probably rename it to control.jar); or create a new status.jar just to do status query, and leave the shutdown.jar to do the shutdown. 3. The code that does the real status query work will be as simply as serverControl.getRunningKernel().isRunning(). I prefer to reuse the shutdown.jar. If you see no problem with my current thinking, I'll go ahead to create a JIRA with a patch. -Jack [1] http://www.nabble.com/status-from-shell-script-(System-V-starup)-td20472233s134.html -- Ivan
New selenium-m-p snap out...
... looks like it works fine with FF3. I'm gonna see how well it works in server/trunk and then will publish a release if it works. --jason
Re: [GSHELL] Timeframe ?
Well, I think its mostly Genesis 2.0 that is causing the lag on GShell's release. I'm going to see about fixing that this week, otherwise rolling back to the Genesis 1.6 stuff for the alpha-2. --jason On Jan 7, 2009, at 5:52 PM, Guillaume Nodet wrote: We are planning a release of ServiceMix Kernel in the near future. What are the missing bits to release GShell soon ? On Fri, Oct 17, 2008 at 08:25, Jason Dillon jason.dil...@gmail.com wrote: The GShell APIs are getting closer and closer to stability. The major changes have all been committed, and I don't have any plans to make any other significant changes to the core APIs. What I am doing now is trying to slim down the core dependencies and speed up the boot time... and sorting out some of the many HACK/TODO comments which I've littered the codebase with. As for an alpha-2 release, I imagine that will be on the horizon soon. I don't plan on having all of the little things fixed before that, though I hope to sort out a few of the more significant ones before releasing. If I had to guess I'd say that the codebase should be in a position to be released in 2-4 weeks at present change velocity. --jason On Oct 16, 2008, at 2:23 PM, Guillaume Nodet wrote: In ServiceMix, we are considering upgrading to the latest trunk of GShell and I've already done the bigger part of the upgrade locally on my HD. Btw, I've committed a few small changes for that yesterday. However, I'm worried about the stability of gshell. We currently use an old and unreleased version of gshell, but I'd like to avoid such issue and having to rewrite this integration once more. Jason, what's your feeling about gshell's stability (in terms of APIs) and a possible ETA for a new release (be it alpha-2 or whatever) ? -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open Source SOA http://fusesource.com
Re: svn commit: r732905 - /geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/config/projects/Geronimo_CTS/report/ReportGenerator.groovy
FYI, you should be able to just use iterModel.name, or if you want
something like:
def zipName = ${targetDir}/logs/${iterModel.name}.zip
--jason
On Jan 9, 2009, at 8:38 AM, jawar...@apache.org wrote:
Author: jawarner
Date: Thu Jan 8 17:38:03 2009
New Revision: 732905
URL: http://svn.apache.org/viewvc?rev=732905view=rev
Log:
Fixing typo in zip file name
Modified:
geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/
config/projects/Geronimo_CTS/report/ReportGenerator.groovy
Modified: geronimo/sandbox/build-support/libraries/system/1/groovy/
gbuild/config/projects/Geronimo_CTS/report/ReportGenerator.groovy
URL:
http://svn.apache.org/viewvc/geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/config/projects/Geronimo_CTS/report/ReportGenerator.groovy?rev=732905r1=732904r2=732905view=diff
=
=
=
=
=
=
=
=
==
--- geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/
config/projects/Geronimo_CTS/report/ReportGenerator.groovy (original)
+++ geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/
config/projects/Geronimo_CTS/report/ReportGenerator.groovy Thu Jan
8 17:38:03 2009
@@ -240,7 +240,7 @@
}
// Zip relevant logs for posting on iteration page for
download
-def zipName = targetDir + /logs/ iterModel.getName()
+ .zip
+def zipName = targetDir + /logs/ +
iterModel.getName() + .zip
ant.zip(destfile: zipName) {
zipfileset( dir: workDir, includes: 'logs/' )
Re: [CONF] Apache Geronimo: SideNav Subprojects (page edited)
Why aren't these links? Its pointless IMO to add items to nav pages which are not links of some sort. --jason On Jan 6, 2009, at 10:38 PM, conflue...@apache.org wrote: Page Edited : GMOxSITE : SideNav Subprojects SideNav Subprojects has been edited by Donald Woods (Jan 06, 2009). (View changes) Content: Development Tools Sample Applications GBuild GShell XBean Yoko Java EE Specs Components Plugins Powered by Atlassian Confluence (Version: 2.2.9 Build:#527 Sep 07, 2006) - Bug/feature request Unsubscribe or edit your notifications preferences
Re: git, hg or bzr for G development?
Um, that is way to big for me to answer here. Suggest you watch: http://www.youtube.com/watch?v=4XpnKHJAok8 --jason On Dec 27, 2008, at 3:48 AM, Jacek Laskowski wrote: On Thu, Dec 18, 2008 at 7:55 AM, Jason Dillon ja...@planet57.com wrote: I've been doing some experimenting using svn.eu.apache.org with git, so far it has gone well. What does git have that svn doesn't which makes you so interested in the subject? Jacek -- Jacek Laskowski Notatnik Projektanta Java EE - http://www.JacekLaskowski.pl
Re: [jira] Created: (GSHELL-151) Repackage org.apache.geronimo.gshell.* - org.apache.gshell.*
On Dec 18, 2008, at 1:12 AM, Donald Woods wrote: Seems that as a community we should keep our project name as part of all groupIds we generate... If no one else feels that way, then fine, I will not call for a vote, but my opinion stands... :-) Just curious what you think about xbean and yoko packaging given your opinion.. ? --jason
Re: svn commit: r727321 - in /geronimo/gshell/trunk: gshell-api/src/main/java/org/apache/geronimo/gshell/command/ gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/comma
Should be up now.
--jason
On Dec 20, 2008, at 7:56 PM, Gert Vanthienen wrote:
L.S.,
Thanks for making new SNAPSHOTs available again! Could we have
another new
SNAPSHOT for
http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/gshell/wisdom/gshell-wisdom-core/1.0-alpha-2-SNAPSHOT/
as well?
Regards,
Gert
Gert Vanthienen wrote:
L.S.,
Do you have any idea when we will have a -SNAPSHOT available on
people.apache.org that contains this change? The last gshell-api
SNAPSHOT
available at
http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/gshell/gshell-api/1.0-alpha-2-SNAPSHOT/
seems to be over a week old.
Regards,
Gert
Jason Dillon wrote:
Thx :-)
--jason
On Dec 17, 2008, at 4:31 PM, gno...@apache.org wrote:
Author: gnodet
Date: Wed Dec 17 01:31:44 2008
New Revision: 727321
URL: http://svn.apache.org/viewvc?rev=727321view=rev
Log:
GSHELL-154: Create interfaces to represent links and aliases
Added:
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Alias.java
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Link.java
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/command/AliasImpl.java
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/command/LinkImpl.java
Modified:
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/config/PluginParser.java
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/plugin/bundle/
CommandBundle.java
Added: geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Alias.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Alias.java?rev=727321view=auto
=
=
=
=
=
=
=
=
=
=
=
===
--- geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Alias.java (added)
+++ geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Alias.java Wed Dec 17 01:31:44 2008
@@ -0,0 +1,33 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.geronimo.gshell.command;
+
+/**
+ * Convenient way to register an alias.
+ *
+ * @version $Rev: 705507 $ $Date: 2008-10-17 10:22:12 +0200 (Fri,
17 Oct 2008) $
+ */
+public interface Alias {
+
+String getName();
+
+String getAlias();
+
+}
Added: geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Link.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Link.java?rev=727321view=auto
=
=
=
=
=
=
=
=
=
=
=
===
--- geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Link.java (added)
+++ geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Link.java Wed Dec 17 01:31:44 2008
@@ -0,0 +1,33 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.geronimo.gshell.command;
+
+/**
+ * Provides a convenient way to register a link
+ *
+ * @version $Rev: 705507 $ $Date: 2008-10-17 10:22:12 +0200 (Fri,
17 Oct 2008) $
+ */
+public
Re: svn commit: r727321 - in /geronimo/gshell/trunk: gshell-api/src/main/java/org/apache/geronimo/gshell/command/ gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/comma
Guillaume, did you ever finish publishing snaps?
--jason
On Dec 20, 2008, at 7:56 PM, Gert Vanthienen wrote:
L.S.,
Thanks for making new SNAPSHOTs available again! Could we have
another new
SNAPSHOT for
http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/gshell/wisdom/gshell-wisdom-core/1.0-alpha-2-SNAPSHOT/
as well?
Regards,
Gert
Gert Vanthienen wrote:
L.S.,
Do you have any idea when we will have a -SNAPSHOT available on
people.apache.org that contains this change? The last gshell-api
SNAPSHOT
available at
http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/gshell/gshell-api/1.0-alpha-2-SNAPSHOT/
seems to be over a week old.
Regards,
Gert
Jason Dillon wrote:
Thx :-)
--jason
On Dec 17, 2008, at 4:31 PM, gno...@apache.org wrote:
Author: gnodet
Date: Wed Dec 17 01:31:44 2008
New Revision: 727321
URL: http://svn.apache.org/viewvc?rev=727321view=rev
Log:
GSHELL-154: Create interfaces to represent links and aliases
Added:
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Alias.java
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Link.java
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/command/AliasImpl.java
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/command/LinkImpl.java
Modified:
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/config/PluginParser.java
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/plugin/bundle/
CommandBundle.java
Added: geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Alias.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Alias.java?rev=727321view=auto
=
=
=
=
=
=
=
=
=
=
=
===
--- geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Alias.java (added)
+++ geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Alias.java Wed Dec 17 01:31:44 2008
@@ -0,0 +1,33 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.geronimo.gshell.command;
+
+/**
+ * Convenient way to register an alias.
+ *
+ * @version $Rev: 705507 $ $Date: 2008-10-17 10:22:12 +0200 (Fri,
17 Oct 2008) $
+ */
+public interface Alias {
+
+String getName();
+
+String getAlias();
+
+}
Added: geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Link.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Link.java?rev=727321view=auto
=
=
=
=
=
=
=
=
=
=
=
===
--- geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Link.java (added)
+++ geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Link.java Wed Dec 17 01:31:44 2008
@@ -0,0 +1,33 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.geronimo.gshell.command;
+
+/**
+ * Provides a convenient way to register a link
+ *
+ * @version $Rev: 705507 $ $Date: 2008-10-17 10:22:12 +0200 (Fri,
17
Re: [jira] Created: (GSHELL-151) Repackage org.apache.geronimo.gshell.* - org.apache.gshell.*
On Dec 16, 2008, at 11:41 AM, Donald Woods wrote: Seems like something we should vote on, given our specs, samples, components and plugin subprojects all use org.apache.geronimo.* IMO specs, samples, components and plugins are all specific to geronimo, so the sub-package makes sense. xbean on the other hand is not geronimo specific directly under o.a. IMO GShell is not geronimo-specific, closer in nature to xbean than to specs or components. So for me the change of packages makes a lot of sense. --jason -Donald Jason Dillon wrote: No, it just seems that subprojects don't seem to use the parents namespace. mina, activemq seems to follow that, even xbean does that. so i figured I would drop the extra layer. --jason On Dec 16, 2008, at 12:39 AM, Donald Woods wrote: Are you proposing GShell becoming a TLP and not a Geronimo subproject? -Donald Jason Dillon (JIRA) wrote: Repackage org.apache.geronimo.gshell.* - org.apache.gshell.* - Key: GSHELL-151 URL: https://issues.apache.org/jira/browse/ GSHELL-151 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Priority: Critical Fix For: 1.0-beta-1
Re: git, hg or bzr for G development?
I've been doing some experimenting using svn.eu.apache.org with git, so far it has gone well. I've been reading infra mail some folks do run into problems from time to time. So I'm limiting my changes to only small things, no large refactorings yet, but it is looking very hopeful. That and there has been some discussion on the infra list about an ASF git repo, hopefully that will be per TLP, but who knows. --jason On Dec 6, 2008, at 1:22 AM, Kevan Miller wrote: On Dec 4, 2008, at 9:13 AM, Jason Dillon wrote: Has anyone figured out a way to use git, hg, or bzr for G (or other ASF) development? Some projects are creating git mirrors of svn. There's been some chatter on infrastructure@ I haven't really looked at it. I don't recall any hg or bzr discussions. IIUC, you have to use the eu svn server. Also saw the following http://markmail.org/message/fzzy7nepk7olx5fl#query :+page:1+mid:zrujbjp7dqj5di4z+state:results --kevan
Re: svn commit: r727321 - in /geronimo/gshell/trunk: gshell-api/src/main/java/org/apache/geronimo/gshell/command/ gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/comma
Thx :-)
--jason
On Dec 17, 2008, at 4:31 PM, gno...@apache.org wrote:
Author: gnodet
Date: Wed Dec 17 01:31:44 2008
New Revision: 727321
URL: http://svn.apache.org/viewvc?rev=727321view=rev
Log:
GSHELL-154: Create interfaces to represent links and aliases
Added:
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Alias.java
geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Link.java
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/command/AliasImpl.java
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/command/LinkImpl.java
Modified:
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/config/PluginParser.java
geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/plugin/bundle/
CommandBundle.java
Added: geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Alias.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Alias.java?rev=727321view=auto
=
=
=
=
=
=
=
=
==
--- geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Alias.java (added)
+++ geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Alias.java Wed Dec 17 01:31:44 2008
@@ -0,0 +1,33 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.geronimo.gshell.command;
+
+/**
+ * Convenient way to register an alias.
+ *
+ * @version $Rev: 705507 $ $Date: 2008-10-17 10:22:12 +0200 (Fri,
17 Oct 2008) $
+ */
+public interface Alias {
+
+String getName();
+
+String getAlias();
+
+}
Added: geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Link.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/geronimo/gshell/command/Link.java?rev=727321view=auto
=
=
=
=
=
=
=
=
==
--- geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Link.java (added)
+++ geronimo/gshell/trunk/gshell-api/src/main/java/org/apache/
geronimo/gshell/command/Link.java Wed Dec 17 01:31:44 2008
@@ -0,0 +1,33 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * License); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * AS IS BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+
+package org.apache.geronimo.gshell.command;
+
+/**
+ * Provides a convenient way to register a link
+ *
+ * @version $Rev: 705507 $ $Date: 2008-10-17 10:22:12 +0200 (Fri,
17 Oct 2008) $
+ */
+public interface Link {
+
+String getName();
+
+String getTarget();
+
+}
Added: geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/
main/java/org/apache/geronimo/gshell/wisdom/command/AliasImpl.java
URL:
http://svn.apache.org/viewvc/geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/java/org/apache/geronimo/gshell/wisdom/command/AliasImpl.java?rev=727321view=auto
=
=
=
=
=
=
=
=
==
--- geronimo/gshell/trunk/gshell-wisdom/gshell-wisdom-core/src/main/
java/org/apache/geronimo/gshell/wisdom/command/AliasImpl.java (added)
+++
Re: Geronimo VM-appliance?
Yes I'm definetly going to include full svn, mvn, etc. With a prepopulated local repo for the developers appliance. *** Was thinking about calling the effort GBox. Any thoughts? --jason On Dec 16, 2008, at 11:54 AM, Jack Cai greensi...@gmail.com wrote: If it's for developers, maybe add Maven too. -Jack 2008/12/16 Donald Woods dwo...@apache.org OS+Java 6+FF3+Server+Samples+Eclipse+GEP would be ideal for developers -Donald Jason Dillon wrote: Any idea why kinda of images you'd like to see? I'm gonna try and craft a simple, base-os+Geronimo image to test out. But I think we might want one which has say roller configured perhaps even another which can demonstrate AMQ's message distribution over a cluster. --jason On Dec 15, 2008, at 3:24 PM, David Jencks wrote: I think this is a great idea. I doubt we can host it at apache. unless we do something like bsd + harmony (not even sure if that is likely to work) thanks david jencks On Dec 15, 2008, at 12:01 AM, Jason Dillon wrote: I've been playing around with VMWare, trying to optimize my virtualization configuration, and it occurred to me that folks who are savvy to the virtualization concept might benefit from having a linux+openjdk+geronimo appliance ready to play with perhaps another which is ready for enterprise configuration. From an Apache POV its another distribution, specific to a virtualization tool, like VMWare, but users who already have the required tools installed, can basically download + install + run, and they have a functional environment... IMO this is really nice as it drops a ton of evil platform issues (er ya *F*-windows) but also can resolve issues about which JDK did you install and did you configure your JAVA_HOME, blah, blah, blah. There are a ton of problems a newbie might run into when trying to play around with Geronimo as we all know. Granted, not everyone is going to have a virtualization environment setup, but some will I'm sure... probably even the more savvy users I would guess (and well we can probably give docs to explain how to setup some virt stuff too if needed). But those who do, we can deliver them highly functionally images for playing or images tailored for enterprise consumption. That might be one which is bare-minimum for folks that need a starting point to roll uber- custom configurations (perhaps with a nice build env setup already for them, primed with repo artifacts) or one for users that want to deploy clustered ejb+web applications, and then another for simple web apps. Seems to me that the advantage here is that you can configure the server and provide simple admin+user documentation on a known quantity... that being the VM which we publish for them. That VM *should* perform *approximately* the same on any non-virtual host configuration (assuming we craft the image correctly). But, okay I'm no math genius, but from my perspective... lets say 10x users have a problem due to config stuff right now, maybe 1-2x might have a problem with the image (its damn easy to setup a VM-configuration these days, and also damn easy to install an image). So, *assuming* that folks are savvy with VM-technology, it might very well be *easier* to provide a VM image pre-configured for their evaluation/exploration of Geronimo. I don't really expect folks to use that image for production, but I would expect them to learn from then image to build their production environment, perhaps even copying the configuration from the image as a bootstrap (and I think we should provide docs on how to do that). Though for some folks, the image (say the simple webapp image) might work just fine. I've seen a lot of mails about system dependent problems... windows especially, damn I hate that platform... but there are other problems too. Like folks on Redhat who don't uninstall the crappy GNU java muck and manually install the sun/ibm JDK, etc. So I'm not just hating on windows (though you and I both know I really, really, really... really hate it). * * * Bottom line is that I think use of virtual machines is becoming more popular. I think it would be beneficial to Geronimo if we provided one (or more) virtual machines images to showcase Geronimo's full power... and reduce the myriad of complications some initial users run into why running locally on their own systems. And furthermore, we can provide more customized images which fully exploit the full power of the system, without having to go and complicate our build (create new assemblies, slowing down build/dev times, etc). After writing all this, I think the only real issue is, since we are part of Apache and this would technically be considered some sort of *release* artifact... who does including Linux (whatever distro) jive with the ASF legally? I believe its a good idea... obviously or I would not have wasted
Re: [jira] Created: (GSHELL-151) Repackage org.apache.geronimo.gshell.* - org.apache.gshell.*
Sure. I just but that issue in there so I don't forget :-) --jason On Dec 16, 2008, at 11:41 AM, Donald Woods dwo...@apache.org wrote: Seems like something we should vote on, given our specs, samples, components and plugin subprojects all use org.apache.geronimo.* -Donald Jason Dillon wrote: No, it just seems that subprojects don't seem to use the parents namespace. mina, activemq seems to follow that, even xbean does that. so i figured I would drop the extra layer. --jason On Dec 16, 2008, at 12:39 AM, Donald Woods wrote: Are you proposing GShell becoming a TLP and not a Geronimo subproject? -Donald Jason Dillon (JIRA) wrote: Repackage org.apache.geronimo.gshell.* - org.apache.gshell.* - Key: GSHELL-151 URL: https://issues.apache.org/jira/browse/ GSHELL-151 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Priority: Critical Fix For: 1.0-beta-1
Geronimo VM-appliance?
I've been playing around with VMWare, trying to optimize my virtualization configuration, and it occurred to me that folks who are savvy to the virtualization concept might benefit from having a linux +openjdk+geronimo appliance ready to play with perhaps another which is ready for enterprise configuration. From an Apache POV its another distribution, specific to a virtualization tool, like VMWare, but users who already have the required tools installed, can basically download + install + run, and they have a functional environment... IMO this is really nice as it drops a ton of evil platform issues (er ya *F*-windows) but also can resolve issues about which JDK did you install and did you configure your JAVA_HOME, blah, blah, blah. There are a ton of problems a newbie might run into when trying to play around with Geronimo as we all know. Granted, not everyone is going to have a virtualization environment setup, but some will I'm sure... probably even the more savvy users I would guess (and well we can probably give docs to explain how to setup some virt stuff too if needed). But those who do, we can deliver them highly functionally images for playing or images tailored for enterprise consumption. That might be one which is bare- minimum for folks that need a starting point to roll uber-custom configurations (perhaps with a nice build env setup already for them, primed with repo artifacts) or one for users that want to deploy clustered ejb+web applications, and then another for simple web apps. Seems to me that the advantage here is that you can configure the server and provide simple admin+user documentation on a known quantity... that being the VM which we publish for them. That VM *should* perform *approximately* the same on any non-virtual host configuration (assuming we craft the image correctly). But, okay I'm no math genius, but from my perspective... lets say 10x users have a problem due to config stuff right now, maybe 1-2x might have a problem with the image (its damn easy to setup a VM-configuration these days, and also damn easy to install an image). So, *assuming* that folks are savvy with VM-technology, it might very well be *easier* to provide a VM image pre-configured for their evaluation/exploration of Geronimo. I don't really expect folks to use that image for production, but I would expect them to learn from then image to build their production environment, perhaps even copying the configuration from the image as a bootstrap (and I think we should provide docs on how to do that). Though for some folks, the image (say the simple webapp image) might work just fine. I've seen a lot of mails about system dependent problems... windows especially, damn I hate that platform... but there are other problems too. Like folks on Redhat who don't uninstall the crappy GNU java muck and manually install the sun/ibm JDK, etc. So I'm not just hating on windows (though you and I both know I really, really, really... really hate it). * * * Bottom line is that I think use of virtual machines is becoming more popular. I think it would be beneficial to Geronimo if we provided one (or more) virtual machines images to showcase Geronimo's full power... and reduce the myriad of complications some initial users run into why running locally on their own systems. And furthermore, we can provide more customized images which fully exploit the full power of the system, without having to go and complicate our build (create new assemblies, slowing down build/dev times, etc). After writing all this, I think the only real issue is, since we are part of Apache and this would technically be considered some sort of *release* artifact... who does including Linux (whatever distro) jive with the ASF legally? I believe its a good idea... obviously or I would not have wasted the time to try and explain my thoughts to you. But I'm unsure that the ASF can allow for such things, short of an ASF operating-system coming into existence (which I'm neither counting on, nor hope happens). Perhaps a separate sourceforge or code.google project might suite better for legal issues? Anyways, seems like a good idea, I'd like to see it happen, its not that hard... what do you folks think? --jason
Re: Geronimo VM-appliance?
On Dec 15, 2008, at 3:24 PM, David Jencks wrote: I think this is a great idea. I doubt we can host it at apache. unless we do something like bsd + harmony (not even sure if that is likely to work) Thats what I've been realizing... But can we link to it/documented it from apache? --jason
Re: Geronimo VM-appliance?
Any idea why kinda of images you'd like to see? I'm gonna try and craft a simple, base-os+Geronimo image to test out. But I think we might want one which has say roller configured perhaps even another which can demonstrate AMQ's message distribution over a cluster. --jason On Dec 15, 2008, at 3:24 PM, David Jencks wrote: I think this is a great idea. I doubt we can host it at apache. unless we do something like bsd + harmony (not even sure if that is likely to work) thanks david jencks On Dec 15, 2008, at 12:01 AM, Jason Dillon wrote: I've been playing around with VMWare, trying to optimize my virtualization configuration, and it occurred to me that folks who are savvy to the virtualization concept might benefit from having a linux+openjdk+geronimo appliance ready to play with perhaps another which is ready for enterprise configuration. From an Apache POV its another distribution, specific to a virtualization tool, like VMWare, but users who already have the required tools installed, can basically download + install + run, and they have a functional environment... IMO this is really nice as it drops a ton of evil platform issues (er ya *F*-windows) but also can resolve issues about which JDK did you install and did you configure your JAVA_HOME, blah, blah, blah. There are a ton of problems a newbie might run into when trying to play around with Geronimo as we all know. Granted, not everyone is going to have a virtualization environment setup, but some will I'm sure... probably even the more savvy users I would guess (and well we can probably give docs to explain how to setup some virt stuff too if needed). But those who do, we can deliver them highly functionally images for playing or images tailored for enterprise consumption. That might be one which is bare-minimum for folks that need a starting point to roll uber- custom configurations (perhaps with a nice build env setup already for them, primed with repo artifacts) or one for users that want to deploy clustered ejb+web applications, and then another for simple web apps. Seems to me that the advantage here is that you can configure the server and provide simple admin+user documentation on a known quantity... that being the VM which we publish for them. That VM *should* perform *approximately* the same on any non-virtual host configuration (assuming we craft the image correctly). But, okay I'm no math genius, but from my perspective... lets say 10x users have a problem due to config stuff right now, maybe 1-2x might have a problem with the image (its damn easy to setup a VM-configuration these days, and also damn easy to install an image). So, *assuming* that folks are savvy with VM-technology, it might very well be *easier* to provide a VM image pre-configured for their evaluation/exploration of Geronimo. I don't really expect folks to use that image for production, but I would expect them to learn from then image to build their production environment, perhaps even copying the configuration from the image as a bootstrap (and I think we should provide docs on how to do that). Though for some folks, the image (say the simple webapp image) might work just fine. I've seen a lot of mails about system dependent problems... windows especially, damn I hate that platform... but there are other problems too. Like folks on Redhat who don't uninstall the crappy GNU java muck and manually install the sun/ibm JDK, etc. So I'm not just hating on windows (though you and I both know I really, really, really... really hate it). * * * Bottom line is that I think use of virtual machines is becoming more popular. I think it would be beneficial to Geronimo if we provided one (or more) virtual machines images to showcase Geronimo's full power... and reduce the myriad of complications some initial users run into why running locally on their own systems. And furthermore, we can provide more customized images which fully exploit the full power of the system, without having to go and complicate our build (create new assemblies, slowing down build/dev times, etc). After writing all this, I think the only real issue is, since we are part of Apache and this would technically be considered some sort of *release* artifact... who does including Linux (whatever distro) jive with the ASF legally? I believe its a good idea... obviously or I would not have wasted the time to try and explain my thoughts to you. But I'm unsure that the ASF can allow for such things, short of an ASF operating- system coming into existence (which I'm neither counting on, nor hope happens). Perhaps a separate sourceforge or code.google project might suite better for legal issues? Anyways, seems like a good idea, I'd like to see it happen, its not that hard... what do you folks think? --jason
Re: [jira] Created: (GSHELL-151) Repackage org.apache.geronimo.gshell.* - org.apache.gshell.*
No, it just seems that subprojects don't seem to use the parents namespace. mina, activemq seems to follow that, even xbean does that. so i figured I would drop the extra layer. --jason On Dec 16, 2008, at 12:39 AM, Donald Woods wrote: Are you proposing GShell becoming a TLP and not a Geronimo subproject? -Donald Jason Dillon (JIRA) wrote: Repackage org.apache.geronimo.gshell.* - org.apache.gshell.* - Key: GSHELL-151 URL: https://issues.apache.org/jira/browse/GSHELL-151 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Priority: Critical Fix For: 1.0-beta-1
[jira] Created: (GSHELL-150) Add support to resolve artifacts with Maven Mercury
Add support to resolve artifacts with Maven Mercury --- Key: GSHELL-150 URL: https://issues.apache.org/jira/browse/GSHELL-150 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Support - Artifact + Mercury Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-151) Repackage org.apache.geronimo.gshell.* - org.apache.gshell.*
Repackage org.apache.geronimo.gshell.* - org.apache.gshell.* - Key: GSHELL-151 URL: https://issues.apache.org/jira/browse/GSHELL-151 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Priority: Critical Fix For: 1.0-beta-1 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Simple Monitoring Console Server Assemblies?
Why are we building Simple Monitoring Console Server assemblies? Do we ship these? Why? --jason
Re: Simple Monitoring Console Server Assemblies?
And why on earth does the build run by default selenium-based integration tests? Even when -Pno-it is configured? --jason On Dec 14, 2008, at 6:51 PM, Jason Dillon wrote: Why are we building Simple Monitoring Console Server assemblies? Do we ship these? Why? --jason
[jira] Created: (GSHELL-152) Add gshell-maven-plugin to allow command execution via mvn
Add gshell-maven-plugin to allow command execution via mvn -- Key: GSHELL-152 URL: https://issues.apache.org/jira/browse/GSHELL-152 Project: GShell Issue Type: New Feature Security Level: public (Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (GSHELL-153) Configure the maven-license-plugin
Configure the maven-license-plugin -- Key: GSHELL-153 URL: https://issues.apache.org/jira/browse/GSHELL-153 Project: GShell Issue Type: Improvement Security Level: public (Regular issues) Components: Build Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (GSHELL-152) Add gshell-maven-plugin to allow command execution via mvn
[ https://issues.apache.org/jira/browse/GSHELL-152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon updated GSHELL-152: Component/s: (was: Build) Maven Plugin Add gshell-maven-plugin to allow command execution via mvn -- Key: GSHELL-152 URL: https://issues.apache.org/jira/browse/GSHELL-152 Project: GShell Issue Type: New Feature Security Level: public(Regular issues) Components: Maven Plugin Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-3 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Closed: (GSHELL-153) Configure the maven-license-plugin
[
https://issues.apache.org/jira/browse/GSHELL-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason Dillon closed GSHELL-153.
---
Resolution: Fixed
Fix Version/s: (was: 1.0-alpha-3)
1.0-alpha-2
This is done in Genesis 2.0-SNAPSHOT, use {{mvn -Plicense-check}} to run.
Configure the maven-license-plugin
--
Key: GSHELL-153
URL: https://issues.apache.org/jira/browse/GSHELL-153
Project: GShell
Issue Type: Improvement
Security Level: public(Regular issues)
Components: Build
Reporter: Jason Dillon
Assignee: Jason Dillon
Fix For: 1.0-alpha-2
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: svn commit: r725965 - /geronimo/server/trunk/pom.xml - sourceEncoding?
Here:
http://maven.apache.org/plugins/maven-resources-plugin/resources-mojo.html#encoding
And here is a more general document about it:
http://docs.codehaus.org/display/MAVENUSER/POM+Element+for+Source+File+Encoding
--jason
On Dec 12, 2008, at 9:40 PM, Donald Woods wrote:
Jason, how does this property get used?
-Donald
jdil...@apache.org wrote:
Author: jdillon
Date: Fri Dec 12 03:18:14 2008
New Revision: 725965
URL: http://svn.apache.org/viewvc?rev=725965view=rev
Log:
Set encoding
Modified:
geronimo/server/trunk/pom.xml
Modified: geronimo/server/trunk/pom.xml
URL:
http://svn.apache.org/viewvc/geronimo/server/trunk/pom.xml?rev=725965r1=725964r2=725965view=diff
=
=
=
=
=
=
=
=
=
=
--- geronimo/server/trunk/pom.xml (original)
+++ geronimo/server/trunk/pom.xml Fri Dec 12 03:18:14 2008
@@ -51,6 +51,8 @@
/scm
properties
+project.build.sourceEncodingUTF-8/
project.build.sourceEncoding
+ !--
NOTE: Project version, to be used instead of ${pom.version}
since that
value magically changes when using SNAPSHOT versions.
Re: poms in the G repository?
On Dec 5, 2008, at 3:43 AM, David Jencks wrote: On Dec 4, 2008, at 5:55 AM, Jason Dillon wrote: Hi I just realized (or rather remembered) that the G repository doesn't include any poms. This presents a little bit of a problem for integrating the latest GShell which uses Maven2 poms to determine which dependencies to grap/load when installing a GShell command plugin. Any thoughts on including those pom files? I have no principled objections... I'd like to look over your code a bit. What would you like to look at? I can point you in the right direction... Maven typically packages a pom into the artifact is there any chance of using that pom instead of the separate file? Yes, but we can't always expect that, since G (at least) flips those off. Anyways, I'm going to continue to work on integrating things and getting a gshell plugin to bootstrap a G server from a minimal gshell assembly. --jason
[jira] Closed: (GSHELL-149) Get the default value for 'gshell.prompt' from Application/Branding
[ https://issues.apache.org/jira/browse/GSHELL-149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason Dillon closed GSHELL-149. --- Resolution: Fixed Fix Version/s: (was: 1.0-alpha-3) 1.0-alpha-2 Get the default value for 'gshell.prompt' from Application/Branding --- Key: GSHELL-149 URL: https://issues.apache.org/jira/browse/GSHELL-149 Project: GShell Issue Type: Improvement Security Level: public(Regular issues) Components: Application, Wisdom Reporter: Jason Dillon Assignee: Jason Dillon Fix For: 1.0-alpha-2 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r724558 - in /geronimo/server/trunk: ./ plugingroups/javaee5-jetty/ plugingroups/javaee5-jetty/src/main/history/ plugingroups/javaee5-tomcat/ plugingroups/javaee5-tomcat/src/main/histo
Why do we need 2 sets of activemq modules? If the new ones work, then
lets just use them.
--jason
On Dec 9, 2008, at 9:26 PM, Donald Woods wrote:
One of 2 good questions...
The ${activemqString} was put in there by Jencks, so I just kept
using it, but it should probably be removed.
Also, I don't like the renaming to activemq5-* for our modules/cars,
as now both our Samples and user apps will have to be updated to use
the new CAR names
If there are no objections, I'll delete the old activemq plugins and
rename the activemq5 plugins, so we don't break everyone.
-Donald
Jarek Gawor wrote:
If we are switching to activemq5 why do we need this $
{activemqString}
substitution?
Jarek
On Mon, Dec 8, 2008 at 6:59 PM, [EMAIL PROTECTED] wrote:
Author: djencks
Date: Mon Dec 8 15:59:58 2008
New Revision: 724558
URL: http://svn.apache.org/viewvc?rev=724558view=rev
Log:
GERONIMO-4337 upgrade to activemq 5.2. Reduced console
functionality
Added:
geronimo/server/trunk/plugins/activemq5/geronimo-activemq5/src/
main/java/org/apache/geronimo/activemq/management/
ActiveMQTransportConnector.java (with props)
Modified:
geronimo/server/trunk/plugingroups/javaee5-jetty/pom.xml
geronimo/server/trunk/plugingroups/javaee5-jetty/src/main/
history/dependencies.xml
geronimo/server/trunk/plugingroups/javaee5-tomcat/pom.xml
geronimo/server/trunk/plugingroups/javaee5-tomcat/src/main/
history/dependencies.xml
geronimo/server/trunk/plugins/activemq5/activemq5-broker/src/
main/history/dependencies.xml
geronimo/server/trunk/plugins/activemq5/activemq5-broker/src/
main/plan/plan.xml
geronimo/server/trunk/plugins/activemq5/activemq5-portlets/src/
main/java/org/apache/geronimo/console/jmsmanager/helper/
AmqJMSMessageHelper.java
geronimo/server/trunk/plugins/activemq5/activemq5-portlets/src/
main/java/org/apache/geronimo/console/jmsmanager/server/
BaseJMSPortlet.java
geronimo/server/trunk/plugins/activemq5/activemq5-portlets/src/
main/java/org/apache/geronimo/console/jmsmanager/server/
JMSConnectorPortlet.java
geronimo/server/trunk/plugins/activemq5/activemq5-portlets/src/
main/resources/jms-resource-providers.properties
geronimo/server/trunk/plugins/activemq5/activemq5-portlets/src/
main/webapp/WEB-INF/view/jmsmanager/server/connector/normal.jsp
geronimo/server/trunk/plugins/activemq5/activemq5-portlets/src/
main/webapp/WEB-INF/view/jmsmanager/server/normal.jsp
geronimo/server/trunk/plugins/activemq5/activemq5-server/pom.xml
geronimo/server/trunk/plugins/activemq5/geronimo-activemq5/src/
main/java/org/apache/geronimo/activemq/BrokerServiceGBeanImpl.java
geronimo/server/trunk/plugins/activemq5/geronimo-activemq5/src/
main/java/org/apache/geronimo/activemq/management/
ActiveMQManagerGBean.java
geronimo/server/trunk/plugins/activemq5/pom.xml
geronimo/server/trunk/pom.xml
geronimo/server/trunk/testsuite/commands-testsuite/gshell/src/
test/java/org/apache/geronimo/testsuite/gshell/deploy/
DeployTest.java
geronimo/server/trunk/testsuite/console-testsuite/advanced/src/
test/java/org/apache/geronimo/testsuite/console/JMSServerTest.java
geronimo/server/trunk/testsuite/enterprise-testsuite/jms-tests/
jms-ear/src/main/resources/META-INF/geronimo-application.xml
geronimo/server/trunk/testsuite/web-testsuite/test-web-
references/web-references-ear/src/main/resources/META-INF/geronimo-
application.xml
Re: svn commit: r724818 - /geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy
Hey, you really should not rely on system environment variables here,
as that kinda defeats the purpose of using the svn-based controllers
for all configuration.
I'd recommend you revert this and setup defaults in the controllers.
--jason
On Dec 10, 2008, at 1:50 AM, [EMAIL PROTECTED] wrote:
Author: jawarner
Date: Tue Dec 9 10:50:26 2008
New Revision: 724818
URL: http://svn.apache.org/viewvc?rev=724818view=rev
Log:
Pull maven opts from agent environment
Modified:
geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/
system/commands/MavenCommand.groovy
Modified: geronimo/sandbox/build-support/libraries/system/1/groovy/
gbuild/system/commands/MavenCommand.groovy
URL:
http://svn.apache.org/viewvc/geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/system/commands/MavenCommand.groovy?rev=724818r1=724817r2=724818view=diff
=
=
=
=
=
=
=
=
==
--- geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/
system/commands/MavenCommand.groovy (original)
+++ geronimo/sandbox/build-support/libraries/system/1/groovy/gbuild/
system/commands/MavenCommand.groovy Tue Dec 9 10:50:26 2008
@@ -32,7 +32,7 @@
def mavenHome = 'tools/maven'
-def mavenOpts = null
+def mavenOpts = System.getenv('MAVEN_OPTS')
def repoDir = 'repository'
Re: 2.2 (trunk) bucket-o-snapshots
Commons-logging should not be included at all, we are using the slf4j adapters. --jason On Dec 10, 2008, at 2:18 AM, Donald Woods wrote: We also have multiple versions of some depends getting pulled into the assemblies right now, that needs to get fixed: commons-logging - 1.0.3 and 1.0.4 xpp3 and xpp3_min org.apache.ws.commons.schema.XmlSchema - 1.4.2 and SNAPSHOT Some new/questionable depends: com.envoisolutions.sxc.sxc-jaxb and sxc-runtime org.jvnet.staxex quartz.quartz And backport-util-concurrent is still in the distro... Also, can we remove com/sun/xml/ws/jaxws-rt and jaxws-tools, now that we are using CXF for wsgen? -Donald Joe Bohn wrote: It has been mentioned several times that we should be looking to release Geronimo 2.2 before the end of the year (preferrably mid- December). Before we can consider a release there are a large number of snapshots that need to be removed/replaced in our project. Can anybody shed any light on these (or others that I may have missed)? OpenEJB 3.1-SNAPSHOT - Actually, OpenEJB 3.1 was released in late October. However, the trunk version was never updated and some additional changes have been included. Recent changes in Geronimo trunk now require this snapshot that is actually newer than the 3.1 release. IMO we should revert the trunk change and attempt to work with the released OpenEJB 3.1. Axis2 SNAPSHOT (yep, it's just SNAPSHOT without a number). IIUC correctly we need to get an Axis2 release before we can consider a Geronimo 2.2 release. Does anybody know how close we are to getting an Axis2 release? Axiom SNAPSHOT (yep. it's just SNAPSHOT too). I believe this is required by Axis2 ... so if Axis2 is released then they will have to get Axiom released as well (and we can pick up the released version). -xBean 3.5-SNAPSHOT. Is this snapshot really required (I presume it must be)? In branches/2.1 we're still using 3.3. It looks like the latest released version is 3.4.3. I'll give that a shot if I don't hear from anybody that we really need 3.5. -wadi 2.1-SNAPSHOT. Is this snapshot really required (I presume it must be)? In branches/2.1 we're using 2.0. What function requires 2.1-SNAPSHOT and is can somebody directly involved with wadi provide an estimate on when this might be released? -geronimo_j2ee-connector_1.6_spec 1.0-EA-SNAPSHOT. Are we at a point where we can release this spec or do we need to wait until we verify tck? - geronimo-jaspi_1.0_spec 1.0-SNAPSHOT. Are we at a point where we can release this spec or do we need to wait until we verify tck? - geronimo-servlet_3.0_spec 1.0-EA-SNAPSHOT. Are we at a point where we can release this spec or do we need to wait until we verify tck? - geronimo-jaspi 1.0-SNAPSHOT. This is a new geronimo component. How close is this to being able to be released? - geronimo-concurrent_1.0_spec 1.0-SNAPSHOT. How close is this to being able to be released? - XmlSchema SNAPSHOT (yep, it's just SNAPSHOT). I believe this is also related to Axis2 dependencies and will have to be resolved by Axis2 as they release. - woden* 1.0-SNAPSHOT. This is also related to Axis2 and will have to be resolved for an Axis2 release so we will pull in whatever they require. - selenium-maven-plugin 1.0-rc-1-SNAPSHOT. I believe that we pulled this in trying to resolve the FF3 issues. It's not clear to me if we would have to remove this SNAPSHOT prior to a release but I think it would be best to ensure that the tagged release can always be built and run with tests - therefore I think we should remove it. Any other opinions? - jspc-maven-plugin 2.0-alpha-2-SNAPSHOT. I'm not sure why this is updated (in branches/2.1 we use 2.0-alpha-1-20070806). Anybody know? We should remove it. - jspc-compiler-tomcat6 2.0-alpha-2-SNAPSHOT. I'm not sure why this was updated either. In branches/2.1 we updated the maven plugin (above) but not the compiler but in trunk both were updated to the alpha-2-SNAPSHOT. Anybody know why? - ianal-maven-plugin 1.0-alpha-1-SNAPSHOT. No doubt to support the new legal file processing. Is there a released version we can use instead of the SNAPSHOT or do we need to get a release here are well? Joe
