date:20091210

Re: Help to apply patch to 2.1 branch for JIRA 3003

2009-12-10 Thread Ivan

I remebered that another patch should be committed at the same time, or
there will be TCK issues, will check it later.

2009/12/11 Jack Cai 

> Looks like the patch for JIRA 3003 never made into the 2.1 branch. Could
> someone help to commit that code? Thanks a lot.
>
> -Jack
>
>


-- 
Ivan

Help to apply patch to 2.1 branch for JIRA 3003

2009-12-10 Thread Jack Cai

Looks like the patch for JIRA 3003 never made into the 2.1 branch. Could
someone help to commit that code? Thanks a lot.

-Jack

[BUILD] trunk: Failed for Revision: 889487

2009-12-10 Thread gawor

Geronimo Revision: 889487 built with tests included
 
See the full build-2100.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20091210/build-2100.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20091210/unit-test-reports
 
  apache.snapshots (http://repository.apache.org/snapshots)

Path to dependency: 
1) 
org.apache.maven.plugins:maven-remote-resources-plugin:maven-plugin:1.0
2) org.apache.maven.shared:maven-common-artifact-filters:jar:1.0
3) org.apache.maven.shared:maven-plugin-testing-harness:jar:1.1


at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:576)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: 
Unable to get dependency information: Unable to read the metadata file for 
artifact 'org.codehaus.plexus:plexus-archiver:jar': Cannot find parent: 
org.codehaus.plexus:plexus-components for project: 
null:plexus-archiver:jar:1.0-alpha-7 for project 
null:plexus-archiver:jar:1.0-alpha-7
  org.codehaus.plexus:plexus-archiver:jar:1.0-alpha-7

from the specified remote repositories:
  central (http://repo1.maven.org/maven2),
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/),
  apache.snapshots (http://repository.apache.org/snapshots)

Path to dependency: 
1) 
org.apache.maven.plugins:maven-remote-resources-plugin:maven-plugin:1.0
2) org.apache.maven.shared:maven-common-artifact-filters:jar:1.0
3) org.apache.maven.shared:maven-plugin-testing-harness:jar:1.1


at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:432)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:437)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:437)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:300)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:288)
at 
org.apache.maven.plugin.DefaultPluginManager.ensurePluginContainerIsComplete(DefaultPluginManager.java:772)
at 
org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:606)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:431)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
... 16 more
Caused by: 
org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable 
to read the metadata file for artifact 
'org.codehaus.plexus:plexus-archiver:jar': Cannot find parent: 
org.codehaus.plexus:plexus-components for project: 
null:plexus-archiver:jar:1.0-alpha-7 for project 
null:plexus-archiver:jar:1.0-alpha-7
at 
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:183)
at 
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedArtifact(MavenMetadataSource.java:91)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:388)
.

Re: [VOTE] geronimo 2.2 release (2nd try)

2009-12-10 Thread Donald Woods


+1

Ran Tomcat assembly on my Mac with JDK 1.6 and a couple small samples.


-Donald


David Jencks wrote:
I've managed to come up with a 2nd 2.2 release candidate built using the 
maven-release-plugin.


This includes Kevan;s fixes of source headers and a warning removal.

See the jira issues here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220&styleName=Html&version=12312965 



Staged to

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



The main artifacts up for vote are the source release archives

https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.tar.gz 

https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.zip 



If you vote you should at least examine these and make sure something 
plausible builds from them.



[  ] +1 about time to push this out the door
[  ]  0 no opinion
[  ] -1 not this one  (please explain why)

Many thanks
david jencks

Re: [VOTE] geronimo 2.2 release (2nd try)

2009-12-10 Thread David Jencks

Jason and I also ran the jaspic tck (which is separate from the javaee
tck). After a little reconfiguration the servlet profile tests all
pass.

I'd like to call the vote soon, if you would like to vote please do so
soon.

thanks
david jencks
On Dec 10, 2009, at 8:11 AM, Jason Warner wrote:

+1 from me. I built the server and then ran the full tck
successfully.

~Jason Warner

On Thu, Dec 10, 2009 at 5:46 AM, Rick McGuire
wrote:
I was sort of waiting for a decision on whether those couple of
problems raised in the discuss thread were blockers or not. I guess
they're not, so here's my +1 too.

Rick

Kevan Miller wrote:
Here's my +1.
I reviewed the source and binaries in
https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/

--kevan

On Dec 8, 2009, at 2:56 AM, David Jencks wrote:

I've managed to come up with a 2nd 2.2 release candidate built using
the maven-release-plugin.

This includes Kevan;s fixes of source headers and a warning removal.

See the jira issues here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220&styleName=Html&version=12312965

Staged to

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

The main artifacts up for vote are the source release archives

https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.tar.gz

https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.zip

If you vote you should at least examine these and make sure
something plausible builds from them.

[ ] +1 about time to push this out the door
[ ] 0 no opinion
[ ] -1 not this one (please explain why)

Many thanks
david jencks

Re: [VOTE] geronimo 2.2 release (2nd try)

2009-12-10 Thread Jay D. McHugh

+1

I built the server from the source tar and was able to deploy and run my
app (includes EJBs, JPA, messaging, JSPs).

Jay

David Jencks wrote:
> I've managed to come up with a 2nd 2.2 release candidate built using the
> maven-release-plugin.
> 
> This includes Kevan;s fixes of source headers and a warning removal.
> 
> See the jira issues here:
> 
> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220&styleName=Html&version=12312965
> 
> 
> Staged to
> 
> https://repository.apache.org/content/repositories/orgapachegeronimo-043/
> 
> 
> The main artifacts up for vote are the source release archives
> 
> https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.tar.gz
> 
> https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.zip
> 
> 
> If you vote you should at least examine these and make sure something
> plausible builds from them.
> 
> 
> [  ] +1 about time to push this out the door
> [  ]  0 no opinion
> [  ] -1 not this one  (please explain why)
> 
> Many thanks
> david jencks

Re: Understanding the "partial=true; mandatory:=partial" trick

2009-12-10 Thread Jarek Gawor

On Wed, Dec 9, 2009 at 1:06 PM, Lin Sun  wrote:
> Hi,
>
> Do we have to use Require-Bundle here?  I would think Import-Package
> of packageX with the mandatory attribute should wire bundle 2 to
> bundle 1.
>
> Here's my understanding of your scenario:
>
> Bundle1:
> Export-Package:x;partial=true;mandatory:=partial
>
> Bundle2:
> Import-Package:x;partial=true
> Export-Package:x
>
>
> Any other bundles - should be wired to bundle 2:
> Import-Package:x

That's a good question. I tried it and it didn't work. I assume it was
because if Bundle 3 was wired to Bundle 2 it was only able to see
classes local to Bundle 2. That is, it acted like the Bundle 2 wasn't
re-exporting the additional classes from Bundle 1. But I guess if
Bundle 2 Required-Bundle: Bundle 1 these additional classes from
Bundle 1 would be visible to Bundle 3.

Jarek

[BUILD] trunk: Failed for Revision: 889400

2009-12-10 Thread gawor

Geronimo Revision: 889400 built with tests included
 
See the full build-1500.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20091210/build-1500.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20091210/unit-test-reports
 
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: 
Unable to get dependency information: Unable to read the metadata file for 
artifact 'org.codehaus.groovy.maven.support:ant-launcher-1.7.0:jar': Cannot 
find parent: org.codehaus.groovy.maven.support:gmaven-support for project: 
null:ant-launcher-1.7.0:jar:null for project null:ant-launcher-1.7.0:jar:null
  org.codehaus.groovy.maven.support:ant-launcher-1.7.0:jar:1.0-rc-2

from the specified remote repositories:
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  apache.snapshots (http://repository.apache.org/snapshots),
  openqa-releases (http://nexus.openqa.org/content/repositories/releases),
  ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/),
  central (http://repo1.maven.org/maven2),
  openqa-snapshots (http://nexus.openqa.org/content/repositories/snapshots)

Path to dependency: 
1) org.apache.geronimo.testsupport:testsupport-selenium:jar:3.0-SNAPSHOT
2) 
org.seleniumhq.selenium.client-drivers:selenium-java-client-driver:jar:1.0-beta-2
3) org.codehaus.groovy.maven.runtime:gmaven-runtime-default:jar:1.0-rc-2
4) org.codehaus.groovy.maven.runtime:gmaven-runtime-1.5:jar:1.0-rc-2


at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:432)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:437)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:437)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:437)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:74)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:300)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:288)
at 
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1417)
at 
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:407)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
... 16 more
Caused by: 
org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable 
to read the metadata file for artifact 
'org.codehaus.groovy.maven.support:ant-launcher-1.7.0:jar': Cannot find parent: 
org.codehaus.groovy.maven.support:gmaven-support for project: 
null:ant-launcher-1.7.0:jar:null for project null:ant-launcher-1.7.0:jar:null
at 
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedProject(MavenMetadataSource.java:183)
at 
org.apache.maven.project.artifact.MavenMetadataSource.retrieveRelocatedArtifact(MavenMetadataSource.java:91)
at 
org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:388)
... 25 more
Caused by: org.apache.maven.project.ProjectBuildingException: Cannot find 
parent: org.codehaus.groovy.maven.suppor

Re: Let's keep trunk easy to build

2009-12-10 Thread Kevan Miller

On Dec 10, 2009, at 10:57 AM, Jarek Gawor wrote:

> Hey all,
> 
> Let's keep (or try to) trunk easy to build. Whenever you make a change
> to some snapshot dependency please publish a new snapshot of it. That
> will make it easy for the next person to build the latest code.

That's a good point. Would it make sense to automate this? So, that new snaps 
are being deployed on a regular basis?

On the subject of builds, why are so many of our automated builds failing?

--kevan

Re: [VOTE] geronimo 2.2 release (2nd try)

2009-12-10 Thread Jason Warner

+1 from me.  I built the server and then ran the full tck successfully.

~Jason Warner


On Thu, Dec 10, 2009 at 5:46 AM, Rick McGuire  wrote:

> I was sort of waiting for a decision on whether those couple of problems
> raised in the discuss thread were blockers or not.  I guess they're not, so
> here's my +1 too.
>
> Rick
>
> Kevan Miller wrote:
>
>> Here's my +1.
>> I reviewed the source and binaries in
>> https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/
>>
>> --kevan
>>
>> On Dec 8, 2009, at 2:56 AM, David Jencks wrote:
>>
>>  I've managed to come up with a 2nd 2.2 release candidate built using the
>>> maven-release-plugin.
>>>
>>> This includes Kevan;s fixes of source headers and a warning removal.
>>>
>>> See the jira issues here:
>>>
>>>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220&styleName=Html&version=12312965<
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220&styleName=Html&version=12312965
>>> >
>>>
>>> Staged to
>>>
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-043/<
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-024
>>> >
>>>
>>>
>>> The main artifacts up for vote are the source release archives
>>>
>>>
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.tar.gz<
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-024/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.tar.gz
>>> >
>>>
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.zip<
>>> https://repository.apache.org/content/repositories/orgapachegeronimo-024/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.zip
>>> >
>>>
>>>
>>> If you vote you should at least examine these and make sure something
>>> plausible builds from them.
>>>
>>>
>>> [  ] +1 about time to push this out the door
>>> [  ]  0 no opinion
>>> [  ] -1 not this one  (please explain why)
>>>
>>> Many thanks
>>> david jencks
>>>
>>
>>
>

Let's keep trunk easy to build

2009-12-10 Thread Jarek Gawor

Hey all,

Let's keep (or try to) trunk easy to build. Whenever you make a change
to some snapshot dependency please publish a new snapshot of it. That
will make it easy for the next person to build the latest code.

Jarek

Re: Some spec API changes while compiling Tomcat 7 with Geronimo Servlet/JSP API

2009-12-10 Thread Ivan

Where did you get the error about missing
o.a.g.ext.tomcat:jasper:jar:7.0.0.0-SNAPSHOT , geronimo-tomcat-7.0.0.0 or
plugins/tomcat ?


2009/12/10 Rick McGuire 

> Ivan wrote:
>
>> Hi,
>>While compiling Tomcat 7 with our own Servlet/JSP API, there are some
>> errors about method signature changes. So far, I have no access to the new
>> specs, if anyone could, please help to check it.
>>javax.servlet.jsp.elExpressionEvaluator
>>1. The parameter expectedType in all the methods are changed to generic
>> type Class
>>2. javax.servlet.ServletContext
>>Map getServletRegistrations() ->
>> Map getServletRegistrations();
>>Map getFilterRegistrations(); ->
>> Map getFilterRegistrations();
>>   void setSessionTrackingModes(Set
>> sessionTrackingModes); -> void
>> setSessionTrackingModes(EnumSet sessionTrackingModes);
>>  Thanks !
>> --
>> Ivan
>>
> I'm having problems building 3.0 with the recent changes made to trunk to
> use the tomcat 7 version.  The big issue is the missing
> org.apache.geronimo.ext.tomcat:jasper:jar:7.0.0.0-SNAPSHOT version, but I
> assume it applies to all of the tomcat components.  I managed to track down
> the tomcat code in the sandbox, and once I updated to the
> tomcat.local.directory in the pom, I ran into this compilation problem.
>  This leaves me with a broken build at this point.  How did you generate a
> snapshot version so that the Geronimo trunk would compile?  Is it as simple
> as a missed commit on your sandbox code?
>
> Rick
>



-- 
Ivan

Re: Some spec API changes while compiling Tomcat 7 with Geronimo Servlet/JSP API

2009-12-10 Thread Rick McGuire


Ivan wrote:

Hi,
While compiling Tomcat 7 with our own Servlet/JSP API, there are 
some errors about method signature changes. So far, I have no access 
to the new specs, if anyone could, please help to check it.

javax.servlet.jsp.elExpressionEvaluator
1. The parameter expectedType in all the methods are changed to 
generic type Class

2. javax.servlet.ServletContext
Map getServletRegistrations() -> 
Map getServletRegistrations();
Map getFilterRegistrations(); -> 
Map getFilterRegistrations();
   void setSessionTrackingModes(Set 
sessionTrackingModes); -> void 
setSessionTrackingModes(EnumSet 
sessionTrackingModes);

  Thanks !
--
Ivan
I'm having problems building 3.0 with the recent changes made to trunk 
to use the tomcat 7 version.  The big issue is the missing   
org.apache.geronimo.ext.tomcat:jasper:jar:7.0.0.0-SNAPSHOT version, but 
I assume it applies to all of the tomcat components.  I managed to track 
down the tomcat code in the sandbox, and once I updated to the 
tomcat.local.directory in the pom, I ran into this compilation problem.  
This leaves me with a broken build at this point.  How did you generate 
a snapshot version so that the Geronimo trunk would compile?  Is it as 
simple as a missed commit on your sandbox code?


Rick

[BUILD] trunk: Failed for Revision: 889265

2009-12-10 Thread gawor

Geronimo Revision: 889265 built with tests included
 
See the full build-0900.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20091210/build-0900.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20091210/unit-test-reports
 

for artifact: 
  org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT

from the specified remote repositories:
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  ibiblio.org (http://repo.exist.com/maven2),
  ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/),
  apache.snapshots (http://repository.apache.org/snapshots)



[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Missing:
--
1) 
org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.servicemix.bundles 
-DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-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.servicemix.bundles 
-DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT
2) 
org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT

--
1 required artifact is missing.

for artifact: 
  org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT

from the specified remote repositories:
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  ibiblio.org (http://repo.exist.com/maven2),
  ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/),
  apache.snapshots (http://repository.apache.org/snapshots)


at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:576)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
at java.lang.reflect.Method.invoke(Method.java:599)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: 
org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing:
--
1) 
org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.servicemix.bundles 
-DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-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.servicemix.bundles 
-DartifactId=org.apache.servicemix.bundles.xpp3 -Dversion=1.1.4c_4-SNAPSHOT 
-Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT
2) 
org.apache.servicemix.bundles:org.apache.servicemix.bundles.xpp3:jar:1.1.4c_4-SNAPSHOT

--
1 required artifact is missing.

for artifact: 
  org.apache.geronimo.framework:geronimo-kernel:bundle:3.0-SNAPSHOT

from the specified remote repositories:
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  ibiblio.org (http://repo.exist.com/maven2),
  ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/),
  apache.snapshots

[BUILD] branches/2.2: Failed for Revision: 889245

2009-12-10 Thread gawor

Geronimo Revision: 889245 built with tests included
 
See the full build-0800.log file at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20091210/build-0800.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/2.2/20091210/unit-test-reports
 

--
1 required artifact is missing.

for artifact: 
  org.apache.geronimo.plugins:sysdb-console-jetty:car:2.2.1-SNAPSHOT

from the specified remote repositories:
  ibiblio.org (http://repo.exist.com/maven2),
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  apache.snapshots (http://repository.apache.org/snapshots)



[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Missing:
--
1) org.tranql:tranql-connector-postgresql-xa:rar:1.2

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.tranql 
-DartifactId=tranql-connector-postgresql-xa -Dversion=1.2 -Dpackaging=rar 
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.tranql 
-DartifactId=tranql-connector-postgresql-xa -Dversion=1.2 -Dpackaging=rar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.geronimo.plugins:sysdb-console-jetty:car:2.2.1-SNAPSHOT
2) org.tranql:tranql-connector-postgresql-xa:rar:1.2

--
1 required artifact is missing.

for artifact: 
  org.apache.geronimo.plugins:sysdb-console-jetty:car:2.2.1-SNAPSHOT

from the specified remote repositories:
  ibiblio.org (http://repo.exist.com/maven2),
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  apache.snapshots (http://repository.apache.org/snapshots)


at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:576)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: 
org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing:
--
1) org.tranql:tranql-connector-postgresql-xa:rar:1.2

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.tranql 
-DartifactId=tranql-connector-postgresql-xa -Dversion=1.2 -Dpackaging=rar 
-Dfile=/path/to/file

  Alternatively, if you host your own repository you can deploy the file there: 
  mvn deploy:deploy-file -DgroupId=org.tranql 
-DartifactId=tranql-connector-postgresql-xa -Dversion=1.2 -Dpackaging=rar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) org.apache.geronimo.plugins:sysdb-console-jetty:car:2.2.1-SNAPSHOT
2) org.tranql:tranql-connector-postgresql-xa:rar:1.2

--
1 required artifact is missing.

for artifact: 
  org.apache.geronimo.plugins:sysdb-console-jetty:car:2.2.1-SNAPSHOT

from the specified remote repositories:
  ibiblio.org (http://repo.exist.com/maven2),
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  apache.snapshots (http://repository.apache.org/snapshots)


at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:324)
at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:288)
at 
org.apache.maven.plugin.DefaultPluginManager.resolveTransitiveDependencies(DefaultPluginManager.java:1417)
at

Re: [VOTE] geronimo 2.2 release (2nd try)

2009-12-10 Thread Rick McGuire

I was sort of waiting for a decision on whether those couple of problems 
raised in the discuss thread were blockers or not.  I guess they're not, 
so here's my +1 too.


Rick

Kevan Miller wrote:
Here's my +1. 

I reviewed the source and binaries 
in https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/


--kevan

On Dec 8, 2009, at 2:56 AM, David Jencks wrote:

I've managed to come up with a 2nd 2.2 release candidate built using 
the maven-release-plugin.


This includes Kevan;s fixes of source headers and a warning removal.

See the jira issues here:

https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=10220&styleName=Html&version=12312965 



Staged to

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



The main artifacts up for vote are the source release archives

https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.tar.gz 

https://repository.apache.org/content/repositories/orgapachegeronimo-043/org/apache/geronimo/geronimo/2.2/geronimo-2.2-source-release.zip 



If you vote you should at least examine these and make sure something 
plausible builds from them.



[  ] +1 about time to push this out the door
[  ]  0 no opinion
[  ] -1 not this one  (please explain why)

Many thanks
david jencks

Pluto 2 in geronimo

2009-12-10 Thread David Jencks

I have pluto 2 working in geronimo trunk, wired with blueprint.  There  
are still a few exceptions on some console pages but they aren't  
related to pluto.


portlet 2 depends on jsr 188 ccpp and pluto uses the sun spec jar to  
build against.  My legal-fu is not up to deciphering whether we can  
turn the sun spec jar into a bundle and redistribute it, so I wrote  
new api classes from the javadoc.  See https://issues.apache.org/jira/browse/GERONIMO-4982 
  Advice would be great.


Assuming we want to keep my implementation, do we need to do anything  
licensing-wise before publishing snapshots?  Until this question is  
resolved you'lll need to build the spec jar locally before building  
trunk.


There is still a bunch of cleanup work I want to do for wiring pluto  
and integrating our admin console extension stuff.  Also we may be  
able to push some more code back into pluto.


thanks
david jencks

Re: [DISCUSS] geronimo 2.2 release (2nd try)

2009-12-10 Thread chi runhua

>
>
  It would be nice to have more infos on the Plugin based Farming
>> http://cwiki.apache.org/GMOxDOC22/plugin-based-farming.html
>> also in the RC the GShell deploy/farm command seems not available and
>> documented
>> gsh/> deploy/farm --help
>>
>
> I think these were renamed deploy/cluster
>
> thanks
> david jencks
>
>
> Just update the doc with the correct GShell command cluster/deploy. ^_^

You may also refer to a previous discussion about this feature.

http://old.nabble.com/Server-farm-management-based-on-plugins-to25556950s134.html

Anything else, just let us know.

Jeff

Re: Some spec API changes while compiling Tomcat 7 with Geronimo Servlet/JSP API

2009-12-10 Thread Ivan

OK, I am not familiar with the rules ;-(
So only those changes done are compatible with the old versions, increased
snapshot version could be used. Or even if it is a MR, we need to create a
new code base for it. Right ?

2009/12/10 David Jencks 

> This probably won't be backward compatible so we should probably
> copy/rename the project to geronimo-jsp_2.1MR2009_spec (with the actual MR
> number :-)
>
> thanks
> david jencks
>
> On Dec 9, 2009, at 11:58 PM, Ivan wrote:
>
> After googled, in Java EE 6, there is a maintence release for JSP 2.1, I
> will update our JSP spec dependency to 1.0.2-SNAPSHOT. I guess that there
> are other changes needed except for the generic types.
>
> 2009/12/10 Ivan 
>
>> Thanks, David.
>> I do have svn access to those spec codes, but just not sure whether the
>> methods signatures are really changed in the new spec 3.0. So ...
>> For JSP, it seems that there is no new 2.2 version in Java EE 6. Yes, I am
>> also curious about the parameter change, or just a new MR for 2.1? I am
>> checking it now.
>> BTW, once JSP/Servlet compilation errors disappeared, I would update the
>> Tomcat to 7.0.
>>
>> 2009/12/10 David Jencks 
>>
>> Hi Ivan,
>>>
>>> I fixed the servlet sig problems and am pushing a snapshot.
>>> I don't think we've tried to update the jsp spec yet.  Is there a new
>>> spec version (2.2?) or a MR that introduces these changes?
>>>
>>> BTW you should have no problems fixing these problems yourself, the specs
>>> are at e.g.
>>>
>>>
>>> https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-servlet_3.0_spec
>>>
>>> thanks
>>> david jencks
>>>
>>>
>>>
>>> On Dec 9, 2009, at 6:58 PM, Ivan wrote:
>>>
>>>  Hi,
While compiling Tomcat 7 with our own Servlet/JSP API, there are some
 errors about method signature changes. So far, I have no access to the new
 specs, if anyone could, please help to check it.
javax.servlet.jsp.elExpressionEvaluator
1. The parameter expectedType in all the methods are changed to
 generic type Class
2. javax.servlet.ServletContext
Map getServletRegistrations() ->
 Map getServletRegistrations();
Map getFilterRegistrations(); ->
 Map getFilterRegistrations();
   void setSessionTrackingModes(Set
 sessionTrackingModes); -> void
 setSessionTrackingModes(EnumSet sessionTrackingModes);
  Thanks !
 --
 Ivan

>>>
>>>
>>
>>
>> --
>> Ivan
>>
>
>
>
> --
> Ivan
>
>
>


-- 
Ivan

[jira] Commented: (GERONIMO-4982) ccpp (jsr 188) spec bundle

2009-12-10 Thread David Jencks (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788610#action_12788610
 ] 

David Jencks commented on GERONIMO-4982:


initial implementation rev 889147.  There are a few unimplmented bits

> ccpp (jsr 188) spec bundle
> --
>
> Key: GERONIMO-4982
> URL: https://issues.apache.org/jira/browse/GERONIMO-4982
> Project: Geronimo
>  Issue Type: Bug
>  Security Level: public(Regular issues) 
>  Components: console, osgi-bundles, specs
>Affects Versions: 3.0
>Reporter: David Jencks
>Assignee: David Jencks
> Fix For: 3.0
>
>
> Pluto 2 requires a ccpp spec jar.  They are using the sun one in the build.  
> I'm not sure if we can redistribute that or distribute a bundlized version of 
> it so I wrote a new implementation from the javadoc while we figure this out.
> Sun download page:
> http://jcp.org/aboutJava/communityprocess/final/jsr188/index.html
> license page:
> https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_JCP-Site/en_US/-/USD/ViewLicense-Start

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

[BUILD] trunk: Failed for Revision: 889128

2009-12-10 Thread gawor

Geronimo Revision: 889128 built with tests included
 
See the full build-0300.log file at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20091210/build-0300.log
 
 
See the unit test reports at 
http://people.apache.org/builds/geronimo/server/binaries/trunk/20091210/unit-test-reports
 

from the specified remote repositories:
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  apache.snapshots (http://repository.apache.org/snapshots),
  ibiblio.org (http://repo.exist.com/maven2),
  ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/),
  tuscany.repo (http://svn.apache.org/repos/asf/tuscany/maven)



[INFO] 
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Missing:
--
1) org.apache.maven:maven-plugin-api:jar:2.0.8

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.maven 
-DartifactId=maven-plugin-api -Dversion=2.0.8 -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.maven 
-DartifactId=maven-plugin-api -Dversion=2.0.8 -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) 
org.apache.geronimo.buildsupport:geronimo-osgi-plugin:maven-plugin:3.0-SNAPSHOT
2) org.apache.maven:maven-plugin-api:jar:2.0.8

--
1 required artifact is missing.

for artifact: 
  
org.apache.geronimo.buildsupport:geronimo-osgi-plugin:maven-plugin:3.0-SNAPSHOT

from the specified remote repositories:
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  apache.snapshots (http://repository.apache.org/snapshots),
  ibiblio.org (http://repo.exist.com/maven2),
  ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/),
  tuscany.repo (http://svn.apache.org/repos/asf/tuscany/maven)


at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:576)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:500)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:479)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:331)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:292)
at 
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:301)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: 
org.apache.maven.artifact.resolver.MultipleArtifactsNotFoundException: Missing:
--
1) org.apache.maven:maven-plugin-api:jar:2.0.8

  Try downloading the file manually from the project website.

  Then, install it using the command: 
  mvn install:install-file -DgroupId=org.apache.maven 
-DartifactId=maven-plugin-api -Dversion=2.0.8 -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.maven 
-DartifactId=maven-plugin-api -Dversion=2.0.8 -Dpackaging=jar 
-Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id]

  Path to dependency: 
1) 
org.apache.geronimo.buildsupport:geronimo-osgi-plugin:maven-plugin:3.0-SNAPSHOT
2) org.apache.maven:maven-plugin-api:jar:2.0.8

--
1 required artifact is missing.

for artifact: 
  
org.apache.geronimo.buildsupport:geronimo-osgi-plugin:maven-plugin:3.0-SNAPSHOT

from the specified remote repositories:
  codehaus.snapshots (http://snapshots.repository.codehaus.org),
  apache.snapshots (http://repository.apache.org/snapshots),
  ibiblio.org (http://repo.exist.com/maven2),
  ops4j.snapshots (http://repository.ops4j.org/mvn-snapshots/),
  tuscany.repo (http://svn.apache.org/repos/asf/tuscany/maven)


at 
org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:324)
at

Re: [DISCUSS] geronimo 2.2 release (2nd try)

2009-12-10 Thread David Jencks



On Dec 10, 2009, at 12:02 AM, frapien wrote:





Joe Bohn wrote:




It is not clear to me the purpose of the new assembly -
geronimo-plugin-farm-node-2.2.  Is this discussed someplace and  
will it
be made available as an individual download on from our download  
page?


https://issues.apache.org/jira/browse/GERONIMO-4284



It would be nice to have more infos on the Plugin based Farming
http://cwiki.apache.org/GMOxDOC22/plugin-based-farming.html
also in the RC the GShell deploy/farm command seems not available and
documented
gsh/> deploy/farm --help


I think these were renamed deploy/cluster

thanks
david jencks


ERROR NotFoundException: deploy/farm
any ideas on that

The file gshell.log of the RC contains lot of DEBUG-Messages (Jetyy,  
Tomcat)

How to disable these debugs in the Release 2.2?

08:49:36,116 DEBUG (main) [org.apache.geronimo.gshell.GShell]  
Initialized in

0:00:00.641
08:49:36,116 INFO  (main)
[org.apache.geronimo.gshell.DefaultCommandExecutor] Executing  
(String):

geronimo/start-server
08:49:36,116 DEBUG (main)
[org.apache.geronimo.gshell.parser.CommandLineParser] Parsing from  
reader:

java.io.stringrea...@1e845c2
08:49:36,131 DEBUG (main)
[org.apache.geronimo.gshell.DefaultCommandLineBuilder] CommandLine
(org.apache.geronimo.gshell.parser.ASTCommandLine)
08:49:36,131 DEBUG (main)
[org.apache.geronimo.gshell.DefaultCommandLineBuilder]  Expression
(org.apache.geronimo.gshell.parser.ASTExpression)
08:49:36,131 DEBUG (main)
[org.apache.geronimo.gshell.DefaultCommandLineBuilder]   PlainString(
geronimo/start-server )  
(org.apache.geronimo.gshell.parser.ASTPlainString)

08:49:36,131 INFO  (main)
[org.apache.geronimo.gshell.DefaultCommandExecutor] Executing
(geronimo/start-server): []
08:49:36,209 DEBUG (main)
[org.apache.geronimo.gshell.plugin.PlexusCommandWrapper] Child  
container

realm: gshell:e4ca5a52-2134-48b7-8968-15a38ac7c33b
08:49:36,241 DEBUG (main) [org.codehaus.plexus.PlexusContainer]  
Found 0

components to load on start
08:49:36,428 INFO  (main)
[org.apache.geronimo.commands.StartServerCommand.geronimo- 
commands:start-server]

Executing w/args: []
08:49:36,522 DEBUG (main)
[org.apache.geronimo.commands.StartServerCommand.geronimo- 
commands:start-server]

Geronimo home: C:\geronimo-jetty7-minimal-2.2
08:49:36,647 DEBUG (main)
[org.apache.geronimo.commands.StartServerCommand.geronimo- 
commands:start-server]

Evaluating script:
C:\geronimo-jetty7-minimal-2.2\etc\rc.d\start-server,default.groovy
08:49:36,975 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Initialized with URL:
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector,
environment: {jmx.remote.credentials=[Ljava.lang.String;@1ce1bea}
08:49:36,991 DEBUG (main)
[org.apache.geronimo.commands.StartServerCommand.geronimo- 
commands:start-server]

Waiting for Geronimo Server...
08:49:36,991 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Connecting to:
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
08:49:38,100 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Connection failure; ignoring: java.io.IOException: Failed to retrieve
RMIServer stub: javax.naming.ServiceUnavailableException [Root  
exception is
java.rmi.ConnectException: Connection refused to host: localhost;  
nested

exception is:
java.net.ConnectException: Connection refused: connect]
08:49:39,100 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Connecting to:
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
08:49:39,131 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Connection failure; ignoring: java.io.IOException: Failed to retrieve
RMIServer stub: javax.naming.NameNotFoundException: JMXConnector
08:49:40,131 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Connecting to:
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
08:49:40,178 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Connected
08:49:42,272 DEBUG (main)
[org.apache.geronimo.commands.StartServerCommand.geronimo- 
commands:start-server]

Waiting for Geronimo Server to shutdown...

--
View this message in context: 
http://old.nabble.com/-DISCUSS--geronimo-2.2-release-%282nd-try%29-tp26694501s134p26723414.html
Sent from the Apache Geronimo - Dev mailing list archive at  
Nabble.com.

Re: Some spec API changes while compiling Tomcat 7 with Geronimo Servlet/JSP API

2009-12-10 Thread David Jencks

This probably won't be backward compatible so we should probably copy/ 
rename the project to geronimo-jsp_2.1MR2009_spec (with the actual MR  
number :-)


thanks
david jencks

On Dec 9, 2009, at 11:58 PM, Ivan wrote:

After googled, in Java EE 6, there is a maintence release for JSP  
2.1, I will update our JSP spec dependency to 1.0.2-SNAPSHOT. I  
guess that there are other changes needed except for the generic  
types.


2009/12/10 Ivan 
Thanks, David.
I do have svn access to those spec codes, but just not sure whether  
the methods signatures are really changed in the new spec 3.0. So ...
For JSP, it seems that there is no new 2.2 version in Java EE 6.  
Yes, I am also curious about the parameter change, or just a new MR  
for 2.1? I am checking it now.
BTW, once JSP/Servlet compilation errors disappeared, I would update  
the Tomcat to 7.0.


2009/12/10 David Jencks 

Hi Ivan,

I fixed the servlet sig problems and am pushing a snapshot.
I don't think we've tried to update the jsp spec yet.  Is there a  
new spec version (2.2?) or a MR that introduces these changes?


BTW you should have no problems fixing these problems yourself, the  
specs are at e.g.


https://svn.apache.org/repos/asf/geronimo/specs/trunk/geronimo-servlet_3.0_spec

thanks
david jencks



On Dec 9, 2009, at 6:58 PM, Ivan wrote:

Hi,
   While compiling Tomcat 7 with our own Servlet/JSP API, there are  
some errors about method signature changes. So far, I have no access  
to the new specs, if anyone could, please help to check it.

   javax.servlet.jsp.elExpressionEvaluator
   1. The parameter expectedType in all the methods are changed to  
generic type Class

   2. javax.servlet.ServletContext
   Map getServletRegistrations() ->  
Map getServletRegistrations();
   Map getFilterRegistrations(); ->  
Map getFilterRegistrations();
  void setSessionTrackingModes(Set  
sessionTrackingModes); -> void  
setSessionTrackingModes(EnumSet  
sessionTrackingModes);

 Thanks !
--
Ivan




--
Ivan



--
Ivan

Re: Move dependencyManagment segment in framework/pom.xml to the root pom.xml

2009-12-10 Thread David Jencks



On Dec 9, 2009, at 10:53 PM, Jarek Gawor wrote:


I'm +1 for moving some shared dependencies into root pom. If some
dependency is not shared then it can live in some plugin's root pom.


To me it depends on "how shared".  Something like xmlbeans is used  
independently in a lot of builders.  On the other hand there are a lot  
of console-related dependencies that are used only in console plugins,  
and for these I am inclined to think they should be specified in the  
base console plugins pom and that imported for the other console  
plugins.




I do have problems with import imports or at least with
how maven handles them. During a build, Maven might initially
download/use a snapshot of that imported pom with one set of
dependencies but later build the same pom with another set of
dependencies. So I never know which dependencies are really used at
build time with scope imports.


I haven't seen this myself.  IIUC it seems like a really serious maven  
bug.  Is it reported?


Because of that I've been trying to avoid import
imports and wanted to make sure we don't over abuse them.


I forgot to mention that my overriding goal is to make it easier to  
build and release the plugins independently, and then assemble servers  
even more independently.  In this model the idea of a root pom sort of  
disappears.


thanks
david jencks



Jarek

On Thu, Dec 10, 2009 at 1:03 AM, Ivan  wrote:

Thanks for the clarification for the two solutions, David.
But I do not think that it is better to move all the dependencies  
out from
the root pom.xml file. It makes sense that define them in the  
plugin's pom

file for Tomcat or Jetty. But for those tool packages, like xmlbeans,
xmlresovle, etc, I still think it is better to put them in the root  
pom
file. For example, it will make it strange to import pluginA just  
for using
a xmlbean package, although it would not a problem from technical  
side.

Any comments ?

2009/12/10 David Jencks 


On Dec 9, 2009, at 6:51 PM, Ivan wrote:


Hi,
   I found some third-party bundle defintions are in the
framework/pom.xml, Is there any reason to keep them there ? If  
not, I would
suggest to move them to the root pom.xml file, so that all the  
plugins could

refer to them.


To me this is a difficult question.  There are two plausible  
alternatives:


1. move all dependency management for the entire project to the  
root pom.


2. move all dependency management to either framework root pom or  
the
plugins root pom that introduces them, and use the importscope> in
dependency management for other plugins that need the dependency  
to import

the pom that sets up the dependencyManagement..

2 depends on the very recent import scope feature, we could not  
have done

it for any 2.1 or earlier releases.

Arguments can definitely be made on both sides of this  
discussion.  At the

moment my thinking is that (1) promotes a monolithic project that is
difficult to split into independent modules that are assembled,  
and that (2)
promotes more modularity at the possible cost of making dependency  
tracking
slightly harder.  So, over the last few months I've been moving  
towards (2),
putting dependency management for e.g. the imported jetty jars in  
the jetty8

root pom.

So, I'm in favor of gradually moving all the dependency management  
out of

the root pom.

thanks
david jencks


   Thanks !
--
Ivan






--
Ivan

[jira] Created: (GERONIMO-4982) ccpp (jsr 188) spec bundle

2009-12-10 Thread David Jencks (JIRA)

ccpp (jsr 188) spec bundle
--

 Key: GERONIMO-4982
 URL: https://issues.apache.org/jira/browse/GERONIMO-4982
 Project: Geronimo
  Issue Type: Bug
  Security Level: public (Regular issues)
  Components: console, osgi-bundles, specs
Affects Versions: 3.0
Reporter: David Jencks
Assignee: David Jencks
 Fix For: 3.0


Pluto 2 requires a ccpp spec jar.  They are using the sun one in the build.  
I'm not sure if we can redistribute that or distribute a bundlized version of 
it so I wrote a new implementation from the javadoc while we figure this out.

Sun download page:

http://jcp.org/aboutJava/communityprocess/final/jsr188/index.html

license page:

https://cds.sun.com/is-bin/INTERSHOP.enfinity/WFS/CDS-CDS_JCP-Site/en_US/-/USD/ViewLicense-Start

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

[jira] Commented: (GERONIMO-4980) Use Tomcat 7 in Geronimo 3.0

2009-12-10 Thread Ivan (JIRA)


[ 
https://issues.apache.org/jira/browse/GERONIMO-4980?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12788589#action_12788589
 ] 

Ivan commented on GERONIMO-4980:


Commit first step changes to trunk At revision: 889135
Next step :
1. Implement those methods added in Tomcat 7 in the integration codes.
2. Try to run the Tomcat server.
3. Check those failed testcases.


> Use Tomcat 7 in Geronimo 3.0
> 
>
> Key: GERONIMO-4980
> URL: https://issues.apache.org/jira/browse/GERONIMO-4980
> Project: Geronimo
>  Issue Type: Task
>  Security Level: public(Regular issues) 
>  Components: Tomcat
>Affects Versions: 3.0
>Reporter: Ivan
> Fix For: 3.0
>
>
> Use Tomcat 7 in Geronimo 3.0.

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

Re: [DISCUSS] geronimo 2.2 release (2nd try)

2009-12-10 Thread frapien

Joe Bohn wrote:
> 
> 
>>> It is not clear to me the purpose of the new assembly -
>>> geronimo-plugin-farm-node-2.2.  Is this discussed someplace and will it
>>> be made available as an individual download on from our download page?
>> 
>> https://issues.apache.org/jira/browse/GERONIMO-4284
> 
It would be nice to have more infos on the Plugin based Farming
http://cwiki.apache.org/GMOxDOC22/plugin-based-farming.html
also in the RC the GShell deploy/farm command seems not available and
documented
gsh/> deploy/farm --help
ERROR NotFoundException: deploy/farm
any ideas on that

The file gshell.log of the RC contains lot of DEBUG-Messages (Jetyy, Tomcat)
How to disable these debugs in the Release 2.2?

08:49:36,116 DEBUG (main) [org.apache.geronimo.gshell.GShell] Initialized in
0:00:00.641
08:49:36,116 INFO  (main)
[org.apache.geronimo.gshell.DefaultCommandExecutor] Executing (String):
geronimo/start-server 
08:49:36,116 DEBUG (main)
[org.apache.geronimo.gshell.parser.CommandLineParser] Parsing from reader:
java.io.stringrea...@1e845c2
08:49:36,131 DEBUG (main)
[org.apache.geronimo.gshell.DefaultCommandLineBuilder] CommandLine
(org.apache.geronimo.gshell.parser.ASTCommandLine)
08:49:36,131 DEBUG (main)
[org.apache.geronimo.gshell.DefaultCommandLineBuilder]  Expression
(org.apache.geronimo.gshell.parser.ASTExpression)
08:49:36,131 DEBUG (main)
[org.apache.geronimo.gshell.DefaultCommandLineBuilder]   PlainString(
geronimo/start-server ) (org.apache.geronimo.gshell.parser.ASTPlainString)
08:49:36,131 INFO  (main)
[org.apache.geronimo.gshell.DefaultCommandExecutor] Executing
(geronimo/start-server): []
08:49:36,209 DEBUG (main)
[org.apache.geronimo.gshell.plugin.PlexusCommandWrapper] Child container
realm: gshell:e4ca5a52-2134-48b7-8968-15a38ac7c33b
08:49:36,241 DEBUG (main) [org.codehaus.plexus.PlexusContainer] Found 0
components to load on start
08:49:36,428 INFO  (main)
[org.apache.geronimo.commands.StartServerCommand.geronimo-commands:start-server]
Executing w/args: []
08:49:36,522 DEBUG (main)
[org.apache.geronimo.commands.StartServerCommand.geronimo-commands:start-server]
Geronimo home: C:\geronimo-jetty7-minimal-2.2
08:49:36,647 DEBUG (main)
[org.apache.geronimo.commands.StartServerCommand.geronimo-commands:start-server]
Evaluating script:
C:\geronimo-jetty7-minimal-2.2\etc\rc.d\start-server,default.groovy
08:49:36,975 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Initialized with URL:
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector,
environment: {jmx.remote.credentials=[Ljava.lang.String;@1ce1bea}
08:49:36,991 DEBUG (main)
[org.apache.geronimo.commands.StartServerCommand.geronimo-commands:start-server]
Waiting for Geronimo Server...
08:49:36,991 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Connecting to:
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
08:49:38,100 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Connection failure; ignoring: java.io.IOException: Failed to retrieve
RMIServer stub: javax.naming.ServiceUnavailableException [Root exception is
java.rmi.ConnectException: Connection refused to host: localhost; nested
exception is: 
java.net.ConnectException: Connection refused: connect]
08:49:39,100 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Connecting to:
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
08:49:39,131 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Connection failure; ignoring: java.io.IOException: Failed to retrieve
RMIServer stub: javax.naming.NameNotFoundException: JMXConnector
08:49:40,131 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Connecting to:
service:jmx:rmi://localhost/jndi/rmi://localhost:1099/JMXConnector
08:49:40,178 DEBUG (main) [org.apache.geronimo.commands.ServerProxy]
Connected
08:49:42,272 DEBUG (main)
[org.apache.geronimo.commands.StartServerCommand.geronimo-commands:start-server]
Waiting for Geronimo Server to shutdown...

-- 
View this message in context: 
http://old.nabble.com/-DISCUSS--geronimo-2.2-release-%282nd-try%29-tp26694501s134p26723414.html
Sent from the Apache Geronimo - Dev mailing list archive at Nabble.com.

Re: Help to apply patch to 2.1 branch for JIRA 3003

Help to apply patch to 2.1 branch for JIRA 3003

[BUILD] trunk: Failed for Revision: 889487

Re: [VOTE] geronimo 2.2 release (2nd try)

Re: [VOTE] geronimo 2.2 release (2nd try)

Re: [VOTE] geronimo 2.2 release (2nd try)

Re: Understanding the "partial=true; mandatory:=partial" trick

[BUILD] trunk: Failed for Revision: 889400

Re: Let's keep trunk easy to build

Re: [VOTE] geronimo 2.2 release (2nd try)

Let's keep trunk easy to build

Re: Some spec API changes while compiling Tomcat 7 with Geronimo Servlet/JSP API

Re: Some spec API changes while compiling Tomcat 7 with Geronimo Servlet/JSP API

[BUILD] trunk: Failed for Revision: 889265

[BUILD] branches/2.2: Failed for Revision: 889245

Re: [VOTE] geronimo 2.2 release (2nd try)

Pluto 2 in geronimo

Re: [DISCUSS] geronimo 2.2 release (2nd try)

Re: Some spec API changes while compiling Tomcat 7 with Geronimo Servlet/JSP API

[jira] Commented: (GERONIMO-4982) ccpp (jsr 188) spec bundle

[BUILD] trunk: Failed for Revision: 889128

Re: [DISCUSS] geronimo 2.2 release (2nd try)

Re: Some spec API changes while compiling Tomcat 7 with Geronimo Servlet/JSP API

Re: Move dependencyManagment segment in framework/pom.xml to the root pom.xml

[jira] Created: (GERONIMO-4982) ccpp (jsr 188) spec bundle

[jira] Commented: (GERONIMO-4980) Use Tomcat 7 in Geronimo 3.0

Re: [DISCUSS] geronimo 2.2 release (2nd try)

27 matches

Site Navigation

Mail list logo

Footer information