Nabble - Apache Geronimo - Dev

[BUILD] trunk: Failed for Revision: 833541

2009-11-06T12:09:39Z

Geronimo Revision: 833541 built with tests included

See the full build-1500.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091106/build-1500.log

See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091106/unit-test-reports

----------
1 required artifact is missing.

for artifact:
org.apache.geronimo.framework:geronimo-cli:bundle: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)

[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Missing:
----------
1) org.apache.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

Try downloading the file manually from the project website.

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

Path to dependency:
1) org.apache.geronimo.framework:geronimo-cli:bundle:3.0-SNAPSHOT
2) org.apache.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

----------
1 required artifact is missing.

for artifact:
org.apache.geronimo.framework:geronimo-cli:bundle: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)

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.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

Try downloading the file manually from the project website.

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

Path to dependency:
1) org.apache.geronimo.framework:geronimo-cli:bundle:3.0-SNAPSHOT
2) org.apache.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

----------
1 required artifact is missing.

for artifact:
org.apache.geronimo.framework:geronimo-cli:bundle: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)

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 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:407)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
... 16 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 56 seconds
[INFO] Finished at: Fri Nov 06 15:06:35 EST 2009
[INFO] Final Memory: 93M/565M
[INFO] ------------------------------------------------------------------------

Re: New profile in trunk

2009-11-06T10:54:58Z

Why not switch the logic and only include the working plugins in the
default builds and move everything else to an "all" profile?

That would allow building framework + Tomcat, but skip all the console
pieces until those are ready....

-Donald

Rick McGuire wrote:

> David Jencks wrote:
>> I couldn't quite figure out what to build to get the tomcat stuff so I
>> added a new profile to trunk that we can put the working plugins into
>>
>> To build...
>>
>> mvn clean install -Pworking
>>
>> The list of plugins for this profile is in plugins/pom.xml. Please
>> update it when you get something to build :-)
>>
>> I think we probably want to add a profile to build our bundleized jars
>> as well...
>>
>> I couldn't get the tomcat plugin to build either, but haven't looked
>> too hard at what might be wrong.
> David, is this granular to handle subprojects too? For example, tomcat
> is dependent upon some of the pieces of the system-database plugin, but
> I've not put any effort into getting the sysdb-console-jetty piece to
> build yet. There are examples of this scattered around the plugins.
>
> Rick
>>
>> thanks
>> david jencks
>>
>
>

Re: svn commit: r833312 - in /geronimo/server/trunk/plugins: activemq/geronimo-activemq/pom.xml connector-1_6/connector-deployer-1_6/pom.xml connector-1_6/geronimo-connector-builder-1_6/pom.xml j2ee/geronimo-naming-builder/pom.xml

2009-11-06T10:45:24Z

David Jencks wrote:
> I don't think we can use require-bundle, it conflicts with our idea of
> using artifact-aliases. Can you explain the problem this is trying to
> solve?

DynamicImport-Package looks like a viable solution here, so I've removed
the Require-Bundle usage.

Rick

>
> thanks
> david jencks
>
> On Nov 6, 2009, at 12:17 AM, xuhaihong@... wrote:
>
>> Author: xuhaihong
>> Date: Fri Nov 6 08:17:00 2009
>> New Revision: 833312
>>
>> URL: http://svn.apache.org/viewvc?rev=833312&view=rev
>> Log:
>> GERONIMO-4931 Enable ActiveMQ plugin in the OSGI environment
>> Update some import/export settings in felix-maven-plugin, also, add
>> the geronimo-naming-builder as the required bundle of
>> connector-deployer-1.6 to avoid the NPE
>>
>> Modified:
>> geronimo/server/trunk/plugins/activemq/geronimo-activemq/pom.xml
>>
>> geronimo/server/trunk/plugins/connector-1_6/connector-deployer-1_6/pom.xml
>>
>>
>> geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/pom.xml
>>
>> geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/pom.xml
>>
>> Modified:
>> geronimo/server/trunk/plugins/activemq/geronimo-activemq/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/activemq/geronimo-activemq/pom.xml?rev=833312&r1=833311&r2=833312&view=diff
>>
>> ==============================================================================
>>
>> --- geronimo/server/trunk/plugins/activemq/geronimo-activemq/pom.xml
>> (original)
>> +++ geronimo/server/trunk/plugins/activemq/geronimo-activemq/pom.xml
>> Fri Nov 6 08:17:00 2009
>> @@ -64,8 +64,9 @@
>> </dependency>
>>
>> <dependency>
>> - <groupId>org.slf4j</groupId>
>> - <artifactId>jcl-over-slf4j</artifactId>
>> + <groupId>org.ops4j.pax.logging</groupId>
>> + <artifactId>pax-logging-api</artifactId>
>> + <version>1.4</version>
>> </dependency>
>>
>> <dependency>
>>
>> Modified:
>> geronimo/server/trunk/plugins/connector-1_6/connector-deployer-1_6/pom.xml
>>
>> URL:
>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/connector-1_6/connector-deployer-1_6/pom.xml?rev=833312&r1=833311&r2=833312&view=diff
>>
>> ==============================================================================
>>
>> ---
>> geronimo/server/trunk/plugins/connector-1_6/connector-deployer-1_6/pom.xml
>> (original)
>> +++
>> geronimo/server/trunk/plugins/connector-1_6/connector-deployer-1_6/pom.xml
>> Fri Nov 6 08:17:00 2009
>> @@ -118,7 +118,7 @@
>> <instructions>
>> 
>>
>> <Import-Package>org.apache.xmlbeans.impl.schema;version="2.4",org.apache.geronimo.deployment.xbeans.impl,org.apache.geronimo.deployment.javabean.xbeans.impl</Import-Package>
>>
>> -
>> <Require-Bundle>org.apache.geronimo.framework.geronimo-service-builder</Require-Bundle>
>>
>> +
>> <Require-Bundle>org.apache.geronimo.framework.geronimo-service-builder,org.apache.geronimo.modules.geronimo-naming-builder</Require-Bundle>
>>
>>
>> 
>>
>> </instructions>
>> <instance>
>>
>> Modified:
>> geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/pom.xml
>>
>> URL:
>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/pom.xml?rev=833312&r1=833311&r2=833312&view=diff
>>
>> ==============================================================================
>>
>> ---
>> geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/pom.xml
>> (original)
>> +++
>> geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/pom.xml
>> Fri Nov 6 08:17:00 2009
>> @@ -100,7 +100,7 @@
>> <instructions>
>> 
>>
>> <Import-Package>org.apache.xmlbeans.impl.schema;version="2.4",org.apache.geronimo.deployment.xbeans.impl,org.apache.geronimo.deployment.javabean.xbeans.impl,*</Import-Package>
>>
>> -
>> <Require-Bundle>org.apache.geronimo.framework.geronimo-service-builder</Require-Bundle>
>>
>> +
>> <Require-Bundle>org.apache.geronimo.framework.geronimo-service-builder,org.apache.geronimo.modules.geronimo-naming-builder</Require-Bundle>
>>
>>
>> 
>>
>> </instructions>
>> </configuration>
>>
>> Modified:
>> geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/pom.xml
>> URL:
>> http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/pom.xml?rev=833312&r1=833311&r2=833312&view=diff
>>
>> ==============================================================================
>>
>> ---
>> geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/pom.xml
>> (original)
>> +++
>> geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/pom.xml
>> Fri Nov 6 08:17:00 2009
>> @@ -73,8 +73,14 @@
>> <artifactId>maven-bundle-plugin</artifactId>
>> <configuration>
>> <instructions>
>> -
>> <Import-Package>org.apache.xmlbeans.impl.schema;version="2.4",*</Import-Package>
>>
>>
>> 
>>
>> +
>> <Import-Package>org.apache.xmlbeans.impl.schema,*</Import-Package>
>> + <Export-Package>
>> + schemaorg_apache_xmlbeans*,
>> +
>> org.apache.geronimo.xbeans.geronimo.naming*,
>> +
>> org.apache.geronimo.xbeans.geronimo.naming.impl,
>> + org.apache.geronimo.naming.deployment*
>> + </Export-Package>
>> </instructions>
>> </configuration>
>> </plugin>
>>
>>
>
>

Re: New profile in trunk

2009-11-06T10:44:03Z

David Jencks wrote:

> I couldn't quite figure out what to build to get the tomcat stuff so I
> added a new profile to trunk that we can put the working plugins into
>
> To build...
>
> mvn clean install -Pworking
>
> The list of plugins for this profile is in plugins/pom.xml. Please
> update it when you get something to build :-)
>
> I think we probably want to add a profile to build our bundleized jars
> as well...
>
> I couldn't get the tomcat plugin to build either, but haven't looked
> too hard at what might be wrong.

David, is this granular to handle subprojects too? For example, tomcat
is dependent upon some of the pieces of the system-database plugin, but
I've not put any effort into getting the sysdb-console-jetty piece to
build yet. There are examples of this scattered around the plugins.

Rick
>
> thanks
> david jencks
>

Re: svn commit: r833312 - in /geronimo/server/trunk/plugins: activemq/geronimo-activemq/pom.xml connector-1_6/connector-deployer-1_6/pom.xml connector-1_6/geronimo-connector-builder-1_6/pom.xml j2ee/geronimo-naming-builder/pom.xml

2009-11-06T10:21:15Z

David Jencks wrote:
> I don't think we can use require-bundle, it conflicts with our idea of
> using artifact-aliases. Can you explain the problem this is trying to
> solve?

This was the problem I highlighted in my email from a couple days ago.
I'm also not particularly happy with using require bundle, but it
currently looks like the best alternative available to us at the time.

The issue here is what is necessary to get the classes generated by xml
beans to function properly from the bundles that are using the classes.
This requires importing all of the packages under the
schemaorg_apache_xmlbeans directory so the xmlbeans runtime can locate
all of the *.xsb files. The export is easy, since bnd will handle this
with just an export of schemaorg_apache_xmlbeans*. However, import is a
bit more difficult. These packages are not directly referenced by the
contained code, so bnd is not able to generate them automatically.
There are also lots of package names involved with very cryptic names
that would be quite error prone to get correct. It would be nice if the
bundle plugin allowed something like "import schemaorg_apache_xmlbeans*
from bundle xyz" so that you can set things up statically at build time.

Require bundle works, but can be problematic. In fact, I've already run
into a situation where using require bundle caused a constraint
violation because the wiring applied to all of the exported classes. I
don't think require-bundle should be the long-term solution here, but it
gets us over the hump on being able to build things.

Another possibility here would be to try using DynamicImport-Package.
This was an option I didn't fully understand at the time I came up with
the require-bundle solution. I'll try giving that a try and see if
things will work correctly.

Rick

New profile in trunk

2009-11-06T09:33:42Z

I couldn't quite figure out what to build to get the tomcat stuff so I
added a new profile to trunk that we can put the working plugins into

To build...

mvn clean install -Pworking

The list of plugins for this profile is in plugins/pom.xml. Please
update it when you get something to build :-)

I think we probably want to add a profile to build our bundleized jars
as well...

I couldn't get the tomcat plugin to build either, but haven't looked
too hard at what might be wrong.

thanks
david jencks

[jira] Updated: (GERONIMO-4946) Add optional OpenJPA2 plugin to server builds, but not the assemblies

2009-11-06T09:29:32Z

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

Donald Woods updated GERONIMO-4946:
-----------------------------------

Component/s: (was: deployment)
(was: core)
Assignee: Donald Woods
Issue Type: New Feature (was: Bug)
Summary: Add optional OpenJPA2 plugin to server builds, but not the assemblies (was: Artifact-alias fails for replacing deployed plugins)

The suggestion from David Jencks to add additional artifact-alias entries that mapped the ${version} to ${version} fixed the problem.
http://article.gmane.org/gmane.comp.java.geronimo.devel/77270

So, now I'm renaming the JIRA to what its original intent was, which was to provide a JPA2 plugin and deployer based on OpenJPA 2.0.0-M3 and the JPA2 2.0-PFD2 spec API.

> Add optional OpenJPA2 plugin to server builds, but not the assemblies
> ---------------------------------------------------------------------
>
> Key: GERONIMO-4946
> URL: https://issues.apache.org/jira/browse/GERONIMO-4946
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: Plugins
> Affects Versions: 2.2
> Reporter: Donald Woods
> Assignee: Donald Woods
> Fix For: 2.2
>
>
> I'm trying to build a openjpa 2.0 plugin for 2.2, which would replace the existing openjpa 1.2 plugin when installed.
> https://svn.apache.org/repos/asf/geronimo/server/branches/2.2/plugins/openjpa2
> The following works as expected:
> 1) when the new openjpa2 plugin and deployer are installed they replace the existing ones via the "obsoletes" directive in config.xml
> 2) the artifact-alias.properties and client-artifact-alias.properties are updated with:
> org.apache.geronimo.configs/openjpa//car=org.apache.geronimo.configs/openjpa2/2.2-SNAPSHOT/car
> org.apache.geronimo.configs/persistence-jpa10-deployer//car=org.apache.geronimo.configs/persistence-jpa20-deployer/2.2-SNAPSHOT/car
> Issues:
> 1) the offline-deployer-config.xml contains entries for the old openjpa and jpa10-deployer modules and the new openjpa2 and jpa20-deployer modules. I would have expected the old ones to be removed, as was done for the server config.xml
> 2) the openjeb module fails to load (even after server restart) using the new plugins, even though entries were added to artifact-alias.properties -
> aused by: org.apache.geronimo.gbean.InvalidConfigurationException: Configuration gbean failed to start org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car
> reason: Missing dependency: org.apache.geronimo.configs/openjpa/2.2-SNAPSHOT/car
> at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:166)

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

Re: svn commit: r833312 - in /geronimo/server/trunk/plugins: activemq/geronimo-activemq/pom.xml connector-1_6/connector-deployer-1_6/pom.xml connector-1_6/geronimo-connector-builder-1_6/pom.xml j2ee/geronimo-naming-builder/pom.xml

2009-11-06T09:27:28Z

I don't think we can use require-bundle, it conflicts with our idea of
using artifact-aliases. Can you explain the problem this is trying to
solve?

thanks
david jencks

On Nov 6, 2009, at 12:17 AM, xuhaihong@... wrote:

> Author: xuhaihong
> Date: Fri Nov 6 08:17:00 2009
> New Revision: 833312
>
> URL: http://svn.apache.org/viewvc?rev=833312&view=rev
> Log:
> GERONIMO-4931 Enable ActiveMQ plugin in the OSGI environment
> Update some import/export settings in felix-maven-plugin, also, add
> the geronimo-naming-builder as the required bundle of connector-
> deployer-1.6 to avoid the NPE
>
> Modified:
> geronimo/server/trunk/plugins/activemq/geronimo-activemq/pom.xml
> geronimo/server/trunk/plugins/connector-1_6/connector-
> deployer-1_6/pom.xml
> geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-
> builder-1_6/pom.xml
> geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/pom.xml
>
> Modified: geronimo/server/trunk/plugins/activemq/geronimo-activemq/
> pom.xml
> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/activemq/geronimo-activemq/pom.xml?rev=833312&r1=833311&r2=833312&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- geronimo/server/trunk/plugins/activemq/geronimo-activemq/pom.xml
> (original)
> +++ geronimo/server/trunk/plugins/activemq/geronimo-activemq/pom.xml
> Fri Nov 6 08:17:00 2009
> @@ -64,8 +64,9 @@
> </dependency>
>
> <dependency>
> - <groupId>org.slf4j</groupId>
> - <artifactId>jcl-over-slf4j</artifactId>
> + <groupId>org.ops4j.pax.logging</groupId>
> + <artifactId>pax-logging-api</artifactId>
> + <version>1.4</version>
> </dependency>
>
> <dependency>
>
> Modified: geronimo/server/trunk/plugins/connector-1_6/connector-
> deployer-1_6/pom.xml
> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/connector-1_6/connector-deployer-1_6/pom.xml?rev=833312&r1=833311&r2=833312&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- geronimo/server/trunk/plugins/connector-1_6/connector-
> deployer-1_6/pom.xml (original)
> +++ geronimo/server/trunk/plugins/connector-1_6/connector-
> deployer-1_6/pom.xml Fri Nov 6 08:17:00 2009
> @@ -118,7 +118,7 @@
> <instructions>
> 
> <Import-
> Package
> >
> org
> .apache
> .xmlbeans
> .impl
> .schema
> ;version
> =
> "2.4
> ",org
> .apache
> .geronimo
> .deployment
> .xbeans.impl,org.apache.geronimo.deployment.javabean.xbeans.impl</
> Import-Package>
> - <Require-
> Bundle>org.apache.geronimo.framework.geronimo-service-builder</
> Require-Bundle>
> + <Require-
> Bundle>org.apache.geronimo.framework.geronimo-service-
> builder,org.apache.geronimo.modules.geronimo-naming-builder</Require-
> Bundle>
> 
> </instructions>
> <instance>
>
> Modified: geronimo/server/trunk/plugins/connector-1_6/geronimo-
> connector-builder-1_6/pom.xml
> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-builder-1_6/pom.xml?rev=833312&r1=833311&r2=833312&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-
> builder-1_6/pom.xml (original)
> +++ geronimo/server/trunk/plugins/connector-1_6/geronimo-connector-
> builder-1_6/pom.xml Fri Nov 6 08:17:00 2009
> @@ -100,7 +100,7 @@
> <instructions>
> 
> <Import-
> Package
> >
> org
> .apache
> .xmlbeans
> .impl
> .schema
> ;version
> =
> "2.4
> ",org
> .apache
> .geronimo
> .deployment
> .xbeans.impl,org.apache.geronimo.deployment.javabean.xbeans.impl,*</
> Import-Package>
> - <Require-
> Bundle>org.apache.geronimo.framework.geronimo-service-builder</
> Require-Bundle>
> + <Require-
> Bundle>org.apache.geronimo.framework.geronimo-service-
> builder,org.apache.geronimo.modules.geronimo-naming-builder</Require-
> Bundle>
> 
> </instructions>
> </configuration>
>
> Modified: geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/
> pom.xml
> URL: http://svn.apache.org/viewvc/geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/pom.xml?rev=833312&r1=833311&r2=833312&view=diff
> =
> =
> =
> =
> =
> =
> =
> =
> ======================================================================
> --- geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/
> pom.xml (original)
> +++ geronimo/server/trunk/plugins/j2ee/geronimo-naming-builder/
> pom.xml Fri Nov 6 08:17:00 2009
> @@ -73,8 +73,14 @@
> <artifactId>maven-bundle-plugin</artifactId>
> <configuration>
> <instructions>
> - <Import-
> Package>org.apache.xmlbeans.impl.schema;version="2.4",*</Import-
> Package>
> 
> + <Import-
> Package>org.apache.xmlbeans.impl.schema,*</Import-Package>
> + <Export-Package>
> + schemaorg_apache_xmlbeans*,
> +
> org.apache.geronimo.xbeans.geronimo.naming*,
> +
> org.apache.geronimo.xbeans.geronimo.naming.impl,
> + org.apache.geronimo.naming.deployment*
> + </Export-Package>
> </instructions>
> </configuration>
> </plugin>
>
>

Re: Artifact-alias issues with 2.2 for plugins

2009-11-06T09:22:03Z

That fixed it. Thanks!

-Donald

David Jencks wrote:

> Normally you should add two artifact aliases for each artifact you are
> replacing, one with and one without the version on the left side. We've
> been moving towards including versions in dependencies, so if you are
> going to try to cheat and use only one, use the one with a version. So
> you should try
>
> org.apache.geronimo.configs/openjpa//car=org.apache.geronimo.configs/openjpa2/2.2-SNAPSHOT/car
>
> org.apache.geronimo.configs/openjpa/2.2-SNAPSHOT/car=org.apache.geronimo.configs/openjpa2/2.2-SNAPSHOT/car
>
> org.apache.geronimo.configs/persistence-jpa10-deployer//car=org.apache.geronimo.configs/persistence-jpa20-deployer/2.2-SNAPSHOT/car
>
> org.apache.geronimo.configs/persistence-jpa10-deployer/2.2-SNAPSHOT/car=org.apache.geronimo.configs/persistence-jpa20-deployer/2.2-SNAPSHOT/car
>
>
> That should get it running properly in the main server.
>
> To get it to modify the offline deployer, you have to deploy it into
> that server as well as into the main server. I don't remember how to do
> that at the moment.
>
> hope this helps
> david jencks
>
>
> On Nov 6, 2009, at 6:35 AM, Donald Woods wrote:
>
>> I also tried creating a copy of the openejb CAR as openejb-jpa2 and
>> updated the pom to depend on the openjpa2 CAR, but then the other
>> openejb plugins fail to load due to the missing openejb.car -
>>
>> Caused by: org.apache.geronimo.gbean.InvalidConfigurationException:
>> Configuration gbean failed to start
>> org.apache.geronimo.configs/openejb-deployer/2.2-SNAPSHOT/car
>> reason: Missing dependency:
>> org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car
>> at
>> org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:166)
>>
>>
>>
>> So does artifact-alias just not work for CAR dependencies on other CARs?
>>
>>
>> -Donald
>>
>>
>> Donald Woods wrote:
>>> I'm trying to build a openjpa 2.0 plugin for 2.2, which would replace
>>> the existing openjpa 1.2 plugin when installed.
>>> https://svn.apache.org/repos/asf/geronimo/server/branches/2.2/plugins/openjpa2 The
>>> following works as expected:
>>> 1) when the new openjpa2 plugin and deployer are installed they
>>> replace the existing ones via the "obsoletes" directive in config.xml
>>> 2) the artifact-alias.properties and client-artifact-alias.properties
>>> are updated with:
>>> org.apache.geronimo.configs/openjpa//car=org.apache.geronimo.configs/openjpa2/2.2-SNAPSHOT/car
>>> org.apache.geronimo.configs/persistence-jpa10-deployer//car=org.apache.geronimo.configs/persistence-jpa20-deployer/2.2-SNAPSHOT/car
>>> Issues:
>>> 1) the offline-deployer-config.xml contains entries for the old
>>> openjpa and jpa10-deployer modules and the new openjpa2 and
>>> jpa20-deployer modules. I would have expected the old ones to be
>>> removed, as was done for the server config.xml
>>> 2) the openjeb module fails to load (even after server restart) using
>>> the new plugins, even though entries were added to
>>> artifact-alias.properties -
>>> aused by: org.apache.geronimo.gbean.InvalidConfigurationException:
>>> Configuration gbean failed to start
>>> org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car
>>> reason: Missing dependency:
>>> org.apache.geronimo.configs/openjpa/2.2-SNAPSHOT/car
>>> at
>>> org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:166)
>>> Any ideas? I've opened GERONIMO-4946 with the above details.
>>> -Donald
>
>

Re: Artifact-alias issues with 2.2 for plugins

2009-11-06T08:40:51Z

Normally you should add two artifact aliases for each artifact you are
replacing, one with and one without the version on the left side.
We've been moving towards including versions in dependencies, so if
you are going to try to cheat and use only one, use the one with a
version. So you should try

org.apache.geronimo.configs/openjpa//car=org.apache.geronimo.configs/
openjpa2/2.2-SNAPSHOT/car
org.apache.geronimo.configs/openjpa/2.2-SNAPSHOT/
car=org.apache.geronimo.configs/openjpa2/2.2-SNAPSHOT/car
org.apache.geronimo.configs/persistence-jpa10-deployer//
car=org.apache.geronimo.configs/persistence-jpa20-deployer/2.2-
SNAPSHOT/car
org.apache.geronimo.configs/persistence-jpa10-deployer/2.2-SNAPSHOT/
car=org.apache.geronimo.configs/persistence-jpa20-deployer/2.2-
SNAPSHOT/car

That should get it running properly in the main server.

To get it to modify the offline deployer, you have to deploy it into
that server as well as into the main server. I don't remember how to
do that at the moment.

hope this helps
david jencks

On Nov 6, 2009, at 6:35 AM, Donald Woods wrote:

> I also tried creating a copy of the openejb CAR as openejb-jpa2 and
> updated the pom to depend on the openjpa2 CAR, but then the other
> openejb plugins fail to load due to the missing openejb.car -
>
> Caused by: org.apache.geronimo.gbean.InvalidConfigurationException:
> Configuration gbean failed to start org.apache.geronimo.configs/
> openejb-deployer/2.2-SNAPSHOT/car
> reason: Missing dependency: org.apache.geronimo.configs/openejb/2.2-
> SNAPSHOT/car
> at
> org
> .apache
> .geronimo
> .kernel
> .config
> .KernelConfigurationManager.load(KernelConfigurationManager.java:166)
>
>
> So does artifact-alias just not work for CAR dependencies on other
> CARs?
>
>
> -Donald
>
>
> Donald Woods wrote:
>> I'm trying to build a openjpa 2.0 plugin for 2.2, which would
>> replace the existing openjpa 1.2 plugin when installed.
>> https://svn.apache.org/repos/asf/geronimo/server/branches/2.2/plugins/openjpa2
>> The following works as expected:
>> 1) when the new openjpa2 plugin and deployer are installed they
>> replace the existing ones via the "obsoletes" directive in config.xml
>> 2) the artifact-alias.properties and client-artifact-
>> alias.properties are updated with:
>> org.apache.geronimo.configs/openjpa//
>> car=org.apache.geronimo.configs/openjpa2/2.2-SNAPSHOT/car
>> org.apache.geronimo.configs/persistence-jpa10-deployer//
>> car=org.apache.geronimo.configs/persistence-jpa20-deployer/2.2-
>> SNAPSHOT/car Issues:
>> 1) the offline-deployer-config.xml contains entries for the old
>> openjpa and jpa10-deployer modules and the new openjpa2 and jpa20-
>> deployer modules. I would have expected the old ones to be
>> removed, as was done for the server config.xml
>> 2) the openjeb module fails to load (even after server restart)
>> using the new plugins, even though entries were added to artifact-
>> alias.properties -
>> aused by: org.apache.geronimo.gbean.InvalidConfigurationException:
>> Configuration gbean failed to start org.apache.geronimo.configs/
>> openejb/2.2-SNAPSHOT/car
>> reason: Missing dependency: org.apache.geronimo.configs/openjpa/2.2-
>> SNAPSHOT/car
>> at
>> org
>> .apache
>> .geronimo
>> .kernel
>> .config
>> .KernelConfigurationManager.load(KernelConfigurationManager.java:
>> 166) Any ideas? I've opened GERONIMO-4946 with the above details.
>> -Donald

Re: [Discussion]Re-org admin console

2009-11-06T06:45:54Z

Agree that we need some usability improvements (I tried in the past but
it was rejected....) but not for 2.2 if it is going to delay work on the
3.0 server.

Also, I wouldn't spend a lot of time rewriting existing portlets until
we decide what the base admin console will be, as I think you'll end up
at different implementation decisions/limitations if we use the Karaf
admin console vs. Pluto 2....

-Donald

Shawn Jiang wrote:

> No matter what technology we might choose to implement console. #1,2,3
> metioned by Jeff are doable without large effort, and could bring a
> considerable improvement on the usability of current console. I even
> think we can get these done in G2.2.X but not only for G3.0.
>
> I suggest to open a JIRA to track the console usability issue while
> keeping the console tech choosing discussion onoging.
>
> Comments ?
>
> On Fri, Nov 6, 2009 at 12:25 AM, Donald Woods <dwoods@...
> <mailto:dwoods@...>> wrote:
>
> I'd like to have the discussion of "Do we use the Felix Admin
> Console vs. Pluto" first....
>
> Personally, I think we need to focus on getting a Little-G minimal
> equivalent working on trunk first (which doesn't include any Admin
> Console) before we worry with all of the Console based plugins.
>
>
> -Donald
>
>
>
> chi runhua wrote:
>
> Hi all,
> Long time ago there was a discussion[1] on whether we could
> re-org admin console to improve user experiences for 2.2, which
> was cancelled for some reason, since we are now in the begining
> of big change of Geronimo architecture, I think it's a good
> opportunity that we bring this up and also for the coming 3.0
> release.
>
> [1]
> http://old.nabble.com/-DISCUSS--Reorg-of-Admin-Console-for-2.2-td20628217s134.html
>
> Here are couples of thoughts in my mind to improve the console:
> 1. re-constructure the navigation tree to make it collapsible,
> the tree level should be less than 3;
> 2. re-orginize the avaliable tree items into new groups, for
> this one I'd like to vote +1 for what Jack had proposed in the
> previous thread;
> + Servers
> + Application Server
> - Geronimo Kernel (put Information, Java System Info, Thread
> Pool and Shutdown portlets in the same page here)
> - Web Server
> - JMS Server
> - EJB Server
> - DB server
> - Repository
> - New server assembly
> + Applications
> - Deploy New (Suggest to merge in the plan creator, so that
> users can either choose to use an existing plan file, or create
> a new one using the wizard)
> - User applications (merge WAR, EAR and Client, maybe bundles
> in the 3.0?)
> - Server plugins
> + Resources
> - DB pools
> - JMS resources
> - JEE Connectors
> - Jar Aliases
> + Security
> - Users and Groups
> - Keystores
> - Certificate Authority
> - Security Realms
> + Monitoring and Troubleshotting
> - Monitoring
> - Logs
> - Debug Views
> 3. re-construct the available portlets to improve embedded
> assistance information, for example, show breadcrum when user is
> working on a task; reduce in-line text on the current UI, and
> use hover-help or pop-up help page only when necessary etc...
> 4. for the long list on the current UI such as system modules,
> only show the most frequently used ones, use locate/find to
> display more....
>
> Any comments?
>
> Jeff C
>
>
>
>
>
>
>
> --
> Shawn

Re: tomcat plugin can build now.

2009-11-06T06:36:39Z

Cool and great progress!

-Donald

Rick McGuire wrote:
> With the batch of changes I just checked in the tomcat plugin will build
> now (although there's a long chain of other plugins you need to build
> first). There are a few test failures I haven't looked into yet, so
> this only works if you build without the tests.
>
> Rick
>

Re: Artifact-alias issues with 2.2 for plugins

2009-11-06T06:35:22Z

I also tried creating a copy of the openejb CAR as openejb-jpa2 and
updated the pom to depend on the openjpa2 CAR, but then the other
openejb plugins fail to load due to the missing openejb.car -

Caused by: org.apache.geronimo.gbean.InvalidConfigurationException:
Configuration gbean failed to start
org.apache.geronimo.configs/openejb-deployer/2.2-SNAPSHOT/car
reason: Missing dependency:
org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:166)

So does artifact-alias just not work for CAR dependencies on other CARs?

-Donald

Donald Woods wrote:

> I'm trying to build a openjpa 2.0 plugin for 2.2, which would replace
> the existing openjpa 1.2 plugin when installed.
> https://svn.apache.org/repos/asf/geronimo/server/branches/2.2/plugins/openjpa2
>
>
> The following works as expected:
> 1) when the new openjpa2 plugin and deployer are installed they replace
> the existing ones via the "obsoletes" directive in config.xml
> 2) the artifact-alias.properties and client-artifact-alias.properties
> are updated with:
> org.apache.geronimo.configs/openjpa//car=org.apache.geronimo.configs/openjpa2/2.2-SNAPSHOT/car
>
> org.apache.geronimo.configs/persistence-jpa10-deployer//car=org.apache.geronimo.configs/persistence-jpa20-deployer/2.2-SNAPSHOT/car
>
>
> Issues:
> 1) the offline-deployer-config.xml contains entries for the old openjpa
> and jpa10-deployer modules and the new openjpa2 and jpa20-deployer
> modules. I would have expected the old ones to be removed, as was done
> for the server config.xml
> 2) the openjeb module fails to load (even after server restart) using
> the new plugins, even though entries were added to
> artifact-alias.properties -
> aused by: org.apache.geronimo.gbean.InvalidConfigurationException:
> Configuration gbean failed to start
> org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car
> reason: Missing dependency:
> org.apache.geronimo.configs/openjpa/2.2-SNAPSHOT/car
> at
> org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:166)
>
>
>
> Any ideas? I've opened GERONIMO-4946 with the above details.
>
>
> -Donald
>

[BUILD] trunk: Failed for Revision: 833401

2009-11-06T06:21:16Z

Geronimo Revision: 833401 built with tests included

See the full build-0900.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091106/build-0900.log

See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091106/unit-test-reports

----------
1 required artifact is missing.

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

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

[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Missing:
----------
1) org.apache.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

Try downloading the file manually from the project website.

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

Path to dependency:
1) org.apache.geronimo.framework:geronimo-cli:bundle:3.0-SNAPSHOT
2) org.apache.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

----------
1 required artifact is missing.

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

from the specified remote repositories:
codehaus.snapshots (http://snapshots.repository.codehaus.org),
ibiblio.org (http://repo.exist.com/maven2),
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.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

Try downloading the file manually from the project website.

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

Path to dependency:
1) org.apache.geronimo.framework:geronimo-cli:bundle:3.0-SNAPSHOT
2) org.apache.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

----------
1 required artifact is missing.

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

from the specified remote repositories:
codehaus.snapshots (http://snapshots.repository.codehaus.org),
ibiblio.org (http://repo.exist.com/maven2),
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 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:407)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
... 16 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2 minutes 20 seconds
[INFO] Finished at: Fri Nov 06 09:18:11 EST 2009
[INFO] Final Memory: 166M/693M
[INFO] ------------------------------------------------------------------------

Artifact-alias issues with 2.2 for plugins

2009-11-06T05:45:02Z

I'm trying to build a openjpa 2.0 plugin for 2.2, which would replace
the existing openjpa 1.2 plugin when installed.
https://svn.apache.org/repos/asf/geronimo/server/branches/2.2/plugins/openjpa2

The following works as expected:
1) when the new openjpa2 plugin and deployer are installed they replace
the existing ones via the "obsoletes" directive in config.xml
2) the artifact-alias.properties and client-artifact-alias.properties
are updated with:
org.apache.geronimo.configs/openjpa//car=org.apache.geronimo.configs/openjpa2/2.2-SNAPSHOT/car
org.apache.geronimo.configs/persistence-jpa10-deployer//car=org.apache.geronimo.configs/persistence-jpa20-deployer/2.2-SNAPSHOT/car

Issues:
1) the offline-deployer-config.xml contains entries for the old openjpa
and jpa10-deployer modules and the new openjpa2 and jpa20-deployer
modules. I would have expected the old ones to be removed, as was done
for the server config.xml
2) the openjeb module fails to load (even after server restart) using
the new plugins, even though entries were added to
artifact-alias.properties -
aused by: org.apache.geronimo.gbean.InvalidConfigurationException:
Configuration gbean failed to start
org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car
reason: Missing dependency:
org.apache.geronimo.configs/openjpa/2.2-SNAPSHOT/car
at
org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:166)

Any ideas? I've opened GERONIMO-4946 with the above details.

-Donald

[jira] Created: (GERONIMO-4946) Artifact-alias fails for replacing deployed plugins

2009-11-06T05:30:32Z

Artifact-alias fails for replacing deployed plugins
---------------------------------------------------

Key: GERONIMO-4946
URL: https://issues.apache.org/jira/browse/GERONIMO-4946
Project: Geronimo
Issue Type: Bug
Security Level: public (Regular issues)
Components: core, deployment, Plugins
Affects Versions: 2.2
Reporter: Donald Woods
Fix For: 2.2

I'm trying to build a openjpa 2.0 plugin for 2.2, which would replace the existing openjpa 1.2 plugin when installed.
https://svn.apache.org/repos/asf/geronimo/server/branches/2.2/plugins/openjpa2

The following works as expected:
1) when the new openjpa2 plugin and deployer are installed they replace the existing ones via the "obsoletes" directive in config.xml
2) the artifact-alias.properties and client-artifact-alias.properties are updated with:
org.apache.geronimo.configs/openjpa//car=org.apache.geronimo.configs/openjpa2/2.2-SNAPSHOT/car
org.apache.geronimo.configs/persistence-jpa10-deployer//car=org.apache.geronimo.configs/persistence-jpa20-deployer/2.2-SNAPSHOT/car

Issues:
1) the offline-deployer-config.xml contains entries for the old openjpa and jpa10-deployer modules and the new openjpa2 and jpa20-deployer modules. I would have expected the old ones to be removed, as was done for the server config.xml
2) the openjeb module fails to load (even after server restart) using the new plugins, even though entries were added to artifact-alias.properties -
aused by: org.apache.geronimo.gbean.InvalidConfigurationException: Configuration gbean failed to start org.apache.geronimo.configs/openejb/2.2-SNAPSHOT/car
reason: Missing dependency: org.apache.geronimo.configs/openjpa/2.2-SNAPSHOT/car
at org.apache.geronimo.kernel.config.KernelConfigurationManager.load(KernelConfigurationManager.java:166)

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

Re: tomcat plugin can build now.

2009-11-06T02:32:59Z

Delos wrote:
> Good news, Rick!
>
> How long do you think will the OSGI Web container start to work in
> Geronimo?
Well, first we need to actually get a server instance running with an
active web container. I suspect it will take a week or two after we
achieve that point. Right now, things just build, but that's a very big
step toward getting things to run given the number of dependencies
involved.

Rick

>
> 2009/11/6 Forrest Xia <forrestxm@... <mailto:forrestxm@...>>
>
> Hi Rick,
>
> Encounter lot of compilation failures when trying to build tomcat
> plugins. Can you help?
>
> plugins/tomcat/geronimo-tomcat6/src/main/java/org/apache/geronimo/tomcat/TomcatContainer.java:[46,47]
> package rg.apache.geronimo.j2ee.j2eeobjectnames does not exist
> plugins/tomcat/geronimo-tomcat6/src/main/java/org/apache/geronimo/tomcat/TomcatContainer.java:[53,38]
> package org.apache.geronimo.webservices does not exist
>
> ...
>
> Thanks,
> Forrest
>
>
>
>
> --
> Best Regards,
>
> Delos

Re: Is there any plan to migrate existing geronimo shell commands from gshell to karaf shell in geronimo 3.0 ?

2009-11-06T02:24:06Z

There is no reason to keep both.

--jason

On Nov 6, 2009, at 10:40 AM, Shawn Jiang wrote:

Currently, here are different opinions on how G3.0 shell should go:

1, Remove gshell completely, migrate all existing commands to karaf console.
      Pros: Minimize the server size. Bring a clean, easy to use command program model.
      Cons: Break users existing shell.

2, Keep gshell as it was, add a gshell-karaf bridge to call karaf commands in gshell.
      Pros: Enlarge the server size. Bring a more complex command infrastructure.
      Cons: Without breaking users existing shell.

Does anyone have another thoughts on this ? Maybe we need a vote for this someday.

On Wed, Nov 4, 2009 at 11:40 AM, Shawn Jiang <genspring@...> wrote:

Now we are using karaf as OSGI runtime. Karaf has its own shell which is based on RFC 139 command service. Karaf shell uses blueprint and a set of util abstract classes to provide a easy to use program model for new commands.

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)
uses classworld to bootstrap itself
uses a serverProxy to provide geronimo server startup/stop commands.

uses JMX to invoke jsr88 implementation to provide applications deploy/undeploy/distribution commands.
uses JMX to get plugin installer GBean instance to provide plugin install and customized assemblely commands.

I found that all the gshell bootstrap files in geronimo_home/etc has been removed in geronimo 3.0 framework.   Is there any plan to migrate existing geronimo shell commands from gshell to karaf shell in geronimo 3.0 ?

--
Shawn

--
Shawn

Re: Is there any plan to migrate existing geronimo shell commands from gshell to karaf shell in geronimo 3.0 ?

2009-11-06T02:23:47Z

Karaf's shell muck is based on gshell, with some of the internals
ripped out and using gogo, so I agree it should not be too difficult.

--jason

On Nov 6, 2009, at 7:51 AM, Jarek Gawor wrote:

> I agree. Also, porting Geronimo GShell commands to whatever Karaf is
> using shouldn't be hard and shouldn't take that long.
>
> Jarek
>
> On Wed, Nov 4, 2009 at 11:22 AM, Donald Woods <dwoods@...>
> wrote:
>> We could also mention that GShell is deprecated (or some better
>> disclaimer/wording) in the 2.2 Release Notes, since it hasn't been
>> released
>> yet.....
>>
>> I'd rather use the GShell offspring in Karaf than bolt yet another
>> set of
>> warts onto the 3.0 server. Also, we need to keep one of the
>> original goals
>> of minimize server install and runtime footprint in mind, which
>> having 2
>> shell environments wouldn't....
>>
>>
>> -Donald
>>
>>
>> Rick McGuire wrote:
>>>
>>> Shawn Jiang wrote:
>>>>
>>>> Now we are using karaf as OSGI runtime. Karaf has its own shell
>>>> which is
>>>> based on RFC 139 command service. Karaf shell uses blueprint and
>>>> a set of
>>>> util abstract classes to provide a easy to use program model for
>>>> new
>>>> commands.
>>>>
>>>>
>>>> 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)
>>>> * uses classworld to bootstrap itself
>>>> * uses a serverProxy to provide geronimo server startup/stop
>>>> commands.
>>>> * uses JMX to invoke jsr88 implementation to provide
>>>> applications
>>>> deploy/undeploy/distribution commands.
>>>> * uses JMX to get plugin installer GBean instance to provide
>>>> plugin install and customized assemblely commands.
>>>>
>>>>
>>>> I found that all the gshell bootstrap files in geronimo_home/etc
>>>> has been
>>>> removed in geronimo 3.0 framework. Is there any plan to
>>>> migrate existing
>>>> geronimo shell commands from gshell to karaf shell in geronimo
>>>> 3.0 ?
>>>
>>> I don't believe there's any plan to migrate away from gshell to
>>> using the
>>> karaf shell (at least yet). I'm a little concerned about breaking
>>> any
>>> custom commands/scripts that may have been written for prior
>>> Geronimo
>>> releases, so there's a bit of a balancing act involved here. I
>>> suspect we
>>> might want to explore keeping the existing geronimo shell, but see
>>> if it is
>>> possible for it to invoke commands built using the Karaf
>>> infrastructure.
>>> This would allow us to reuse existing Karaf commands and allow
>>> new commands
>>> to be written using the Karaf programming model.
>>>
>>> Rick
>>>>
>>>>
>>>> --
>>>> Shawn
>>>
>>>
>>

Re: tomcat plugin can build now.

2009-11-06T00:44:08Z

Good news, Rick!

How long do you think will the OSGI Web container start to work in Geronimo?

2009/11/6 Forrest Xia <forrestxm@...>

Hi Rick,

Encounter lot of compilation failures when trying to build tomcat plugins. Can you help?

plugins/tomcat/geronimo-tomcat6/src/main/java/org/apache/geronimo/tomcat/TomcatContainer.java:[46,47] package rg.apache.geronimo.j2ee.j2eeobjectnames does not exist
plugins/tomcat/geronimo-tomcat6/src/main/java/org/apache/geronimo/tomcat/TomcatContainer.java:[53,38] package org.apache.geronimo.webservices does not exist

...

Thanks,
Forrest

--
Best Regards,

Delos

Re: Eliminate the ConfigurationActivator from geronimo bundles?

2009-11-06T00:30:37Z

Glad to help if you need me:-)
-Rex

2009/11/6 David Jencks <david_jencks@...>

On Nov 5, 2009, at 8:12 AM, David Jencks wrote:

On Nov 5, 2009, at 7:17 AM, Rex Wang wrote:

IIUC, from the current design, the ConfigurationActivator will be imported by *EVERY* geronimo plugin to help de-serialize the config.ser into configurationData while starting. This might not be a best practise in doing such things.
From what I see, the extender model recommended by osgi allaince is a better choice. That is the new Geronimo kernel can be considered as a Geronimo extender to deal with geronimo bundles, which is fairly similar with the relationship between blueprint extender and blueprint bundles. So if we leverage a bundle tracker to track geronimo bundles, the bundle context and resources(i.e. config.ser) can be easily retrieved when the bundle starting. (Just like what dependencyManager does when install bundles. //But why read geronimo-plugin.xml instead of config.ser there?) Then geronimo extender can construct a configurationData from the config.ser of the geronimo bundle and maintain a map of them. That is just the same with the blueprint extender creating a bluepirntContainer object from OSGi-INF/blueprint/*.xml for each blueprint bundle.
Did I miss anything or is there any particular difficulty so that we have to use an activator? if not, I'd like to open a jira against it.

I this would work but I don't see any advantage. With blueprint, you are using plain java classes and don't need any osgi specific classes available to the bundle. On the other hand gbeans are considerably more intrusive, you need either the gbean annotations or a GBeanInfo object, so we have to import a bunch of geronimo classes anyway, so there's no harm in using a geronimo specific bundle activator class too.

I think there is a significant chance we might decide to try to stop using gbeans for geronimo stuff and use blueprint instead so I would rather focus on getting everything working with the existing kernel code unless we find actual problems.

I'm reluctant to combine DependencyManager with the functionality of ConfigurationActivator since it seems to me that DependencyManager is very very similar to karaf features and possibly rfp 121 so we might be able to work towards combining them.

I've been thinking about this some more and am starting to think that turning the ConfigurationManager into an extender might solve some of the problems it has now where the call chain passes through the ConfigurationActivator and loses a bunch of important information. I'll keep thinking :-)

thanks
david jencks

thanks
david jencks

-Rex

Re: tomcat plugin can build now.

2009-11-06T00:21:05Z

Hi Rick,

Encounter lot of compilation failures when trying to build tomcat plugins. Can you help?

plugins/tomcat/geronimo-tomcat6/src/main/java/org/apache/geronimo/tomcat/TomcatContainer.java:[46,47] package rg.apache.geronimo.j2ee.j2eeobjectnames does not exist
plugins/tomcat/geronimo-tomcat6/src/main/java/org/apache/geronimo/tomcat/TomcatContainer.java:[53,38] package org.apache.geronimo.webservices does not exist

...

Thanks,
Forrest

[jira] Commented: (GERONIMO-4931) Enable ActiveMQ plugin in the OSGI environment

2009-11-06T00:18:41Z

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

Ivan commented on GERONIMO-4931:
--------------------------------

Some changes of import/export settings are commit At revision: 833312 to fix NPE for the visibility of xmlbean generated xsb files.

> Enable ActiveMQ plugin in the OSGI environment
> ----------------------------------------------
>
> Key: GERONIMO-4931
> URL: https://issues.apache.org/jira/browse/GERONIMO-4931
> Project: Geronimo
> Issue Type: Task
> Security Level: public(Regular issues)
> Components: ActiveMQ, osgi
> Affects Versions: 3.0
> Reporter: Ivan
> Fix For: 3.0
>
>
> Enable ActiveMQ plugin in the OSGI environment

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

2009-11-06T00:13:07Z

Geronimo Revision: 833311 built with tests included

See the full build-0300.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091106/build-0300.log

See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091106/unit-test-reports

----------
1 required artifact is missing.

for artifact:
org.apache.geronimo.framework:geronimo-cli:bundle: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)

[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Missing:
----------
1) org.apache.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

Try downloading the file manually from the project website.

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

Path to dependency:
1) org.apache.geronimo.framework:geronimo-cli:bundle:3.0-SNAPSHOT
2) org.apache.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

----------
1 required artifact is missing.

for artifact:
org.apache.geronimo.framework:geronimo-cli:bundle: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)

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.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

Try downloading the file manually from the project website.

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

Path to dependency:
1) org.apache.geronimo.framework:geronimo-cli:bundle:3.0-SNAPSHOT
2) org.apache.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

----------
1 required artifact is missing.

for artifact:
org.apache.geronimo.framework:geronimo-cli:bundle: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)

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 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:407)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
... 16 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2 minutes 57 seconds
[INFO] Finished at: Fri Nov 06 03:10:03 EST 2009
[INFO] Final Memory: 165M/566M
[INFO] ------------------------------------------------------------------------

Re: Is there any plan to migrate existing geronimo shell commands from gshell to karaf shell in geronimo 3.0 ?

2009-11-05T22:34:04Z

On Fri, Nov 6, 2009 at 2:12 PM, David Jencks <david_jencks@...> wrote:

On Nov 5, 2009, at 7:40 PM, Shawn Jiang wrote:

Currently, here are different opinions on how G3.0 shell should go:

1, Remove gshell completely, migrate all existing commands to karaf console.
Pros: Minimize the server size. Bring a clean, easy to use command program model.

I'm not sure it's significantly different from gshell

"minimize" here is relative with the second option. I did some investigation. IMO,writing new karaf command is easier than writing new commands with current geronimo shell.

Cons: Break users existing shell.

How? If we give the commands the same name we can provide a unix shell script called gsh and any gshell scripts should still work....

I don't know how to use unix shell to pass parameters to karaf shell to execute tasks for now. I'll do more research on this to figure it out.

2, Keep gshell as it was, add a gshell-karaf bridge to call karaf commands in gshell.
Pros: Enlarge the server size. Bring a more complex command infrastructure.
Cons: Without breaking users existing shell.

Does anyone have another thoughts on this ? Maybe we need a vote for this someday.

On Wed, Nov 4, 2009 at 11:40 AM, Shawn Jiang <genspring@...> wrote:
Now we are using karaf as OSGI runtime. Karaf has its own shell which is based on RFC 139 command service. Karaf shell uses blueprint and a set of util abstract classes to provide a easy to use program model for new commands.

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)
• uses classworld to bootstrap itself

these don't seem important to me

• uses a serverProxy to provide geronimo server startup/stop commands.

• uses JMX to invoke jsr88 implementation to provide applications deploy/undeploy/distribution commands.
• uses JMX to get plugin installer GBean instance to provide plugin install and customized assemblely commands.

I think any replacement will do these the same way

yes, I just listed them here for references.

I found that all the gshell bootstrap files in geronimo_home/etc has been removed in geronimo 3.0 framework. Is there any plan to migrate existing geronimo shell commands from gshell to karaf shell in geronimo 3.0 ?

I figured we'd do it sooner or later....

Thanks, maybe that's why you added shell-base project to provide basic util classes with karaf command.

thanks
david jencks

--
Shawn

thanks
david jencks

--
Shawn

--
Shawn

-Shawn

Re: Is there any plan to migrate existing geronimo shell commands from gshell to karaf shell in geronimo 3.0 ?

2009-11-05T22:15:47Z

On Nov 4, 2009, at 8:22 AM, Donald Woods wrote:

> We could also mention that GShell is deprecated (or some better
> disclaimer/wording) in the 2.2 Release Notes, since it hasn't been
> released yet.....

It isn't? It's not a snapshot release. I certainly consider it the
only reasonable way to start/use 2.2.

thanks
david jencks

>
> I'd rather use the GShell offspring in Karaf than bolt yet another
> set of warts onto the 3.0 server. Also, we need to keep one of the
> original goals of minimize server install and runtime footprint in
> mind, which having 2 shell environments wouldn't....
>
>
> -Donald
>
>
> Rick McGuire wrote:
>> Shawn Jiang wrote:
>>> Now we are using karaf as OSGI runtime. Karaf has its own shell
>>> which is based on RFC 139 command service. Karaf shell uses
>>> blueprint and a set of util abstract classes to provide a easy to
>>> use program model for new commands.
>>>
>>>
>>> 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)
>>> * uses classworld to bootstrap itself
>>> * uses a serverProxy to provide geronimo server startup/stop
>>> commands.
>>> * uses JMX to invoke jsr88 implementation to provide applications
>>> deploy/undeploy/distribution commands.
>>> * uses JMX to get plugin installer GBean instance to provide
>>> plugin install and customized assemblely commands.
>>>
>>>
>>> I found that all the gshell bootstrap files in geronimo_home/etc
>>> has been removed in geronimo 3.0 framework. Is there any plan
>>> to migrate existing geronimo shell commands from gshell to karaf
>>> shell in geronimo 3.0 ?
>> I don't believe there's any plan to migrate away from gshell to
>> using the karaf shell (at least yet). I'm a little concerned about
>> breaking any custom commands/scripts that may have been written for
>> prior Geronimo releases, so there's a bit of a balancing act
>> involved here. I suspect we might want to explore keeping the
>> existing geronimo shell, but see if it is possible for it to invoke
>> commands built using the Karaf infrastructure. This would allow us
>> to reuse existing Karaf commands and allow new commands to be
>> written using the Karaf programming model.
>> Rick
>>>
>>>
>>> --
>>> Shawn

Re: Is there any plan to migrate existing geronimo shell commands from gshell to karaf shell in geronimo 3.0 ?

2009-11-05T22:12:35Z

On Nov 5, 2009, at 7:40 PM, Shawn Jiang wrote:

> Currently, here are different opinions on how G3.0 shell should go:
>
> 1, Remove gshell completely, migrate all existing commands to karaf
> console.
> Pros: Minimize the server size. Bring a clean, easy to use
> command program model.

I'm not sure it's significantly different from gshell
> Cons: Break users existing shell.
How? If we give the commands the same name we can provide a unix
shell script called gsh and any gshell scripts should still work....

>
> 2, Keep gshell as it was, add a gshell-karaf bridge to call karaf
> commands in gshell.
> Pros: Enlarge the server size. Bring a more complex command
> infrastructure.
> Cons: Without breaking users existing shell.
>
> Does anyone have another thoughts on this ? Maybe we need a vote
> for this someday.
>
> On Wed, Nov 4, 2009 at 11:40 AM, Shawn Jiang <genspring@...>
> wrote:
> Now we are using karaf as OSGI runtime. Karaf has its own shell
> which is based on RFC 139 command service. Karaf shell uses
> blueprint and a set of util abstract classes to provide a easy to
> use program model for new commands.
>
>
> 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)
> • uses classworld to bootstrap itself

these don't seem important to me
> • uses a serverProxy to provide geronimo server startup/stop
> commands.
> • uses JMX to invoke jsr88 implementation to provide applications
> deploy/undeploy/distribution commands.
> • uses JMX to get plugin installer GBean instance to provide plugin
> install and customized assemblely commands.

I think any replacement will do these the same way
>
> I found that all the gshell bootstrap files in geronimo_home/etc has
> been removed in geronimo 3.0 framework. Is there any plan to
> migrate existing geronimo shell commands from gshell to karaf shell
> in geronimo 3.0 ?

I figured we'd do it sooner or later....
thanks
david jencks

>
>
> --
> Shawn
>
>
thanks
david jencks

>
> --
> Shawn

[jira] Updated: (GERONIMO-4741) Make a new samples release with G 2.2 server

2009-11-05T20:36:32Z

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

Chi Runhua updated GERONIMO-4741:
---------------------------------

Attachment: G4741_jms-mdb.patch

Patch for jms-mdb sample application to provide missing files.

> Make a new samples release with G 2.2 server
> --------------------------------------------
>
> Key: GERONIMO-4741
> URL: https://issues.apache.org/jira/browse/GERONIMO-4741
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: sample apps
> Affects Versions: 2.2
> Reporter: Forrest Xia
> Assignee: Forrest Xia
> Attachments: G4741_jms-mdb.patch
>
>
> To do list:
> 1. Add one sample which uses popular application framework, such as struts, spring.
> 2. Update and release a new version of daytrader with G 2.2 sample release
> 3. Add or update a sample to configure EJB security via annotation
> 4. Add or update a sample to demo JTA
> 5. Add a new sample to demo the support of using tomcat server.xml directly
> 6. Add a sample to demo how to build a CSA via car-maven-plugin, ActiveMQ server could be the sample.
> 7. Figure out a way to release JEE application ear/war balls of G samples.
> 8. Ensure G 2.1.2 samples plugins installable and functionable on G 2.2 server.
> Check forum thread http://www.nabble.com/The-scope-and-schedule-for-G-2.2-samples-release-td24177645s134.html#a24455766 for details.

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

[jira] Commented: (GERONIMO-4741) Make a new samples release with G 2.2 server

2009-11-05T20:34:34Z

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

Chi Runhua commented on GERONIMO-4741:
--------------------------------------

Provide a patch for jms-mdb sample application in 2.2, which add 3 geronimo specific files to make sure the sample could be deployed on server successfully.

The source code of the jms-mdb sample with this patch can be built successfully..

please help to review the patch. I'll update the document when this patch is committed.

Jeff C

> Make a new samples release with G 2.2 server
> --------------------------------------------
>
> Key: GERONIMO-4741
> URL: https://issues.apache.org/jira/browse/GERONIMO-4741
> Project: Geronimo
> Issue Type: New Feature
> Security Level: public(Regular issues)
> Components: sample apps
> Affects Versions: 2.2
> Reporter: Forrest Xia
> Assignee: Forrest Xia
>
> To do list:
> 1. Add one sample which uses popular application framework, such as struts, spring.
> 2. Update and release a new version of daytrader with G 2.2 sample release
> 3. Add or update a sample to configure EJB security via annotation
> 4. Add or update a sample to demo JTA
> 5. Add a new sample to demo the support of using tomcat server.xml directly
> 6. Add a sample to demo how to build a CSA via car-maven-plugin, ActiveMQ server could be the sample.
> 7. Figure out a way to release JEE application ear/war balls of G samples.
> 8. Ensure G 2.1.2 samples plugins installable and functionable on G 2.2 server.
> Check forum thread http://www.nabble.com/The-scope-and-schedule-for-G-2.2-samples-release-td24177645s134.html#a24455766 for details.

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

Re: Is there any plan to migrate existing geronimo shell commands from gshell to karaf shell in geronimo 3.0 ?

2009-11-05T19:40:34Z

Currently, here are different opinions on how G3.0 shell should go:

1, Remove gshell completely, migrate all existing commands to karaf console.
      Pros: Minimize the server size. Bring a clean, easy to use command program model.
      Cons: Break users existing shell.

2, Keep gshell as it was, add a gshell-karaf bridge to call karaf commands in gshell.
      Pros: Enlarge the server size. Bring a more complex command infrastructure.
      Cons: Without breaking users existing shell.

Does anyone have another thoughts on this ? Maybe we need a vote for this someday.

On Wed, Nov 4, 2009 at 11:40 AM, Shawn Jiang <genspring@...> wrote:

Now we are using karaf as OSGI runtime. Karaf has its own shell which is based on RFC 139 command service. Karaf shell uses blueprint and a set of util abstract classes to provide a easy to use program model for new commands.

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)
uses classworld to bootstrap itself
uses a serverProxy to provide geronimo server startup/stop commands.

uses JMX to invoke jsr88 implementation to provide applications deploy/undeploy/distribution commands.
uses JMX to get plugin installer GBean instance to provide plugin install and customized assemblely commands.

I found that all the gshell bootstrap files in geronimo_home/etc has been removed in geronimo 3.0 framework. Is there any plan to migrate existing geronimo shell commands from gshell to karaf shell in geronimo 3.0 ?

--
Shawn

--
Shawn

-Shawn

Re: [Discussion]Re-org admin console

2009-11-05T19:12:27Z

No matter what technology we might choose to implement console. #1,2,3 metioned by Jeff are doable without large effort, and could bring a considerable improvement on the usability of current console. I even think we can get these done in G2.2.X but not only for G3.0.

I suggest to open a JIRA to track the console usability issue while keeping the console tech choosing discussion onoging.

Comments ?

On Fri, Nov 6, 2009 at 12:25 AM, Donald Woods <dwoods@...> wrote:

I'd like to have the discussion of "Do we use the Felix Admin Console vs. Pluto" first....

Personally, I think we need to focus on getting a Little-G minimal equivalent working on trunk first (which doesn't include any Admin Console) before we worry with all of the Console based plugins.

-Donald

chi runhua wrote:

Hi all,
Long time ago there was a discussion[1] on whether we could re-org admin console to improve user experiences for 2.2, which was cancelled for some reason, since we are now in the begining of big change of Geronimo architecture, I think it's a good opportunity that we bring this up and also for the coming 3.0 release.

[1] http://old.nabble.com/-DISCUSS--Reorg-of-Admin-Console-for-2.2-td20628217s134.html

Here are couples of thoughts in my mind to improve the console:
1. re-constructure the navigation tree to make it collapsible, the tree level should be less than 3;
2. re-orginize the avaliable tree items into new groups, for this one I'd like to vote +1 for what Jack had proposed in the previous thread;
+ Servers
+ Application Server
- Geronimo Kernel (put Information, Java System Info, Thread Pool and Shutdown portlets in the same page here)
- Web Server
- JMS Server
- EJB Server
- DB server
- Repository
- New server assembly
+ Applications
- Deploy New (Suggest to merge in the plan creator, so that users can either choose to use an existing plan file, or create a new one using the wizard)
- User applications (merge WAR, EAR and Client, maybe bundles in the 3.0?)
- Server plugins
+ Resources
- DB pools
- JMS resources
- JEE Connectors
- Jar Aliases
+ Security
- Users and Groups
- Keystores
- Certificate Authority
- Security Realms
+ Monitoring and Troubleshotting
- Monitoring
- Logs
- Debug Views
3. re-construct the available portlets to improve embedded assistance information, for example, show breadcrum when user is working on a task; reduce in-line text on the current UI, and use hover-help or pop-up help page only when necessary etc...
4. for the long list on the current UI such as system modules, only show the most frequently used ones, use locate/find to display more....

Any comments?

Jeff C

--
Shawn

-Shawn

[BUILD] trunk: Failed for Revision: 833273

2009-11-05T18:17:22Z

Geronimo Revision: 833273 built with tests included

See the full build-2100.log file at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091105/build-2100.log

See the unit test reports at http://people.apache.org/builds/geronimo/server/binaries/trunk/20091105/unit-test-reports

----------
1 required artifact is missing.

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

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

[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Missing:
----------
1) org.apache.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

Try downloading the file manually from the project website.

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

Path to dependency:
1) org.apache.geronimo.framework:geronimo-cli:bundle:3.0-SNAPSHOT
2) org.apache.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

----------
1 required artifact is missing.

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

from the specified remote repositories:
codehaus.snapshots (http://snapshots.repository.codehaus.org),
ibiblio.org (http://repo.exist.com/maven2),
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.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

Try downloading the file manually from the project website.

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

Path to dependency:
1) org.apache.geronimo.framework:geronimo-cli:bundle:3.0-SNAPSHOT
2) org.apache.geronimo.bundles:commons-cli:jar:1.0_1-SNAPSHOT

----------
1 required artifact is missing.

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

from the specified remote repositories:
codehaus.snapshots (http://snapshots.repository.codehaus.org),
ibiblio.org (http://repo.exist.com/maven2),
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 org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:407)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
... 16 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2 minutes 26 seconds
[INFO] Finished at: Thu Nov 05 21:14:17 EST 2009
[INFO] Final Memory: 166M/665M
[INFO] ------------------------------------------------------------------------

Re: Is there any plan to migrate existing geronimo shell commands from gshell to karaf shell in geronimo 3.0 ?

2009-11-05T16:51:14Z

I agree. Also, porting Geronimo GShell commands to whatever Karaf is
using shouldn't be hard and shouldn't take that long.

Jarek

On Wed, Nov 4, 2009 at 11:22 AM, Donald Woods <dwoods@...> wrote:

> We could also mention that GShell is deprecated (or some better
> disclaimer/wording) in the 2.2 Release Notes, since it hasn't been released
> yet.....
>
> I'd rather use the GShell offspring in Karaf than bolt yet another set of
> warts onto the 3.0 server. Also, we need to keep one of the original goals
> of minimize server install and runtime footprint in mind, which having 2
> shell environments wouldn't....
>
>
> -Donald
>
>
> Rick McGuire wrote:
>>
>> Shawn Jiang wrote:
>>>
>>> Now we are using karaf as OSGI runtime. Karaf has its own shell which is
>>> based on RFC 139 command service. Karaf shell uses blueprint and a set of
>>> util abstract classes to provide a easy to use program model for new
>>> commands.
>>>
>>>
>>> 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)
>>> * uses classworld to bootstrap itself
>>> * uses a serverProxy to provide geronimo server startup/stop commands.
>>> * uses JMX to invoke jsr88 implementation to provide applications
>>> deploy/undeploy/distribution commands.
>>> * uses JMX to get plugin installer GBean instance to provide
>>> plugin install and customized assemblely commands.
>>>
>>>
>>> I found that all the gshell bootstrap files in geronimo_home/etc has been
>>> removed in geronimo 3.0 framework. Is there any plan to migrate existing
>>> geronimo shell commands from gshell to karaf shell in geronimo 3.0 ?
>>
>> I don't believe there's any plan to migrate away from gshell to using the
>> karaf shell (at least yet). I'm a little concerned about breaking any
>> custom commands/scripts that may have been written for prior Geronimo
>> releases, so there's a bit of a balancing act involved here. I suspect we
>> might want to explore keeping the existing geronimo shell, but see if it is
>> possible for it to invoke commands built using the Karaf infrastructure.
>> This would allow us to reuse existing Karaf commands and allow new commands
>> to be written using the Karaf programming model.
>>
>> Rick
>>>
>>>
>>> --
>>> Shawn
>>
>>
>

tomcat plugin can build now.

2009-11-05T16:25:24Z

With the batch of changes I just checked in the tomcat plugin will build
now (although there's a long chain of other plugins you need to build
first). There are a few test failures I haven't looked into yet, so
this only works if you build without the tests.

Rick

Re: Mapping classloaders back to bundles

2009-11-05T12:36:23Z

On Nov 5, 2009, at 10:36 AM, Rick McGuire wrote:

> I've run into another place where a method that previously use a
> classloader argument now takes a bundle, and I'm not sure what the
> appropriate method for mapping this back to a bundle would be. This
> is in the EJBHelper class, where it's doing this:
>
> attributeStore.setValue(absName.getArtifact(), absName,
> gAttributeInfo, propertyValue,
> Thread.currentThread().getContextClassLoader());
>
>
> the class loader involved is the thread context class loader, which
> we might be able to map to a bundle, but this might be a case where
> it might be appropriate to just take a classloader in this context.
> The classloader passed to the setValue() method is just used to
> resolve a property class from a class name, and this need not
> necessarily be sourced from a bundle instance. If we still feel we
> need to use a bundle, then I think we need to have a utility of some
> sort that can attempt to figure out from a class loader instance
> what the bundle mapping is.

I don't know what the solution for this is. For now I'd suggest
adding back the method that uses a classloader, if the thread context
classloader will still work.

I'd guess that the osgi way of doing this would be to have a
propertyEditor service that bundles register with when they supply
property editors (this is probably the wrong way of thinking about
it-- but it seems similar to what Guillaume does with the spec service
discovery stuff)

Alternatively maybe we want a thread contextBundle?

Does anyone know what Aries does about TCCL?

thanks
david jencks

>
> Rick