[jira] Commented: (MRRESOURCES-54) m-r-r-p 1.2 not actually threadsafe apparently due to antique velocity version
[ http://jira.codehaus.org/browse/MRRESOURCES-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=261790#action_261790 ] David Jencks commented on MRRESOURCES-54: - This change appears to fix the problem I was seeing. Thanks! > m-r-r-p 1.2 not actually threadsafe apparently due to antique velocity version > -- > > Key: MRRESOURCES-54 > URL: http://jira.codehaus.org/browse/MRRESOURCES-54 > Project: Maven 2.x Remote Resources Plugin > Issue Type: Bug >Affects Versions: 1.2 > Environment: maven 3.0.3 > m-r-r-p 1.2 > -T 4 >Reporter: David Jencks >Assignee: Kristian Rosenvold > Fix For: 1.3 > > > I tried a parallel build but ran into this. All three (identical) errors are > from pom projects. > [ERROR] Failed to execute goal > org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) > on project assemblies: Error rendering velocity resource. > NullPointerException -> [Help 1] > org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute > goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process > (default) on project assemblies: Error rendering velocity resource. >at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) >at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) >at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) >at > org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) >at > org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167) >at > org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164) >at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >at java.util.concurrent.FutureTask.run(FutureTask.java:138) >at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) >at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) >at java.util.concurrent.FutureTask.run(FutureTask.java:138) >at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) >at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) >at java.lang.Thread.run(Thread.java:680) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error rendering > velocity resource. >at > org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1212) >at > org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:519) >at > org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) >at > org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) >... 13 more > Caused by: java.lang.NullPointerException >at > org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831) >at > org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:440) >at > org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:419) >at > org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1125) >... 16 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRRESOURCES-54) m-r-r-p 1.2 not actually threadsafe apparently due to antique velocity version
m-r-r-p 1.2 not actually threadsafe apparently due to antique velocity version -- Key: MRRESOURCES-54 URL: http://jira.codehaus.org/browse/MRRESOURCES-54 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Affects Versions: 1.2 Environment: maven 3.0.3 m-r-r-p 1.2 -T 4 Reporter: David Jencks I tried a parallel build but ran into this. All three (identical) errors are from pom projects. [ERROR] Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) on project assemblies: Error rendering velocity resource. NullPointerException -> [Help 1] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.apache.maven.plugins:maven-remote-resources-plugin:1.2:process (default) on project assemblies: Error rendering velocity resource. at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:217) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145) at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:84) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:167) at org.apache.maven.lifecycle.internal.LifecycleThreadedBuilder$1.call(LifecycleThreadedBuilder.java:164) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303) at java.util.concurrent.FutureTask.run(FutureTask.java:138) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:680) Caused by: org.apache.maven.plugin.MojoExecutionException: Error rendering velocity resource. at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1212) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.execute(ProcessRemoteResourcesMojo.java:519) at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101) at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209) ... 13 more Caused by: java.lang.NullPointerException at org.apache.velocity.runtime.RuntimeInstance.getTemplate(RuntimeInstance.java:831) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:440) at org.apache.velocity.app.VelocityEngine.mergeTemplate(VelocityEngine.java:419) at org.apache.maven.plugin.resources.remote.ProcessRemoteResourcesMojo.processResourceBundles(ProcessRemoteResourcesMojo.java:1125) ... 16 more -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-395) Maven site multi module url problem
[
http://jira.codehaus.org/browse/MSITE-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Jencks updated MSITE-395:
---
Attachment: genesis-2.0-SNAPSHOT-source-release.tar.gz
A cleaner project that still shows the same problem.
It appears to be possible to avoid using the site:stage goal and hopefully get
a testable site by using a property for the site location:
UTF-8
genesis
scp://people.apache.org:/www/geronimo.apache.org
apache-website
${site.deploy.url}/maven/${siteId}/${version}
and running
mvn site site:deploy -Dsite.deploy.url=file:///Users/david/tmp/staging
> Maven site multi module url problem
> ---
>
> Key: MSITE-395
> URL: http://jira.codehaus.org/browse/MSITE-395
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0
>Reporter: valsho
>Priority: Blocker
> Attachments: genesis-2.0-SNAPSHOT-source-release.tar.gz,
> genesis-2.0-SNAPSHOT-source-release.tar.gz
>
>
> The generated maven (2.0.10) site for a multi module project is different on
> windows and linux.
> The difference is the relative url for the modules.
> --
> Here's the project structure :
> myProject/
>trunk/
> pom.xml
> module1/
> pom.xml
> src/
> module2/
> pom.xml
> src/
> --
> Here's myProject/trunk/pom.xml definition :
> com.myProject
> modulepom
> pom
> POM myProject
> 1.0-SNAPSHOT
>
>
> module1
> module2
>
>
>
> site
> Maven site
> file://
>
>
>
>
> org.apache.maven.plugins
> maven-site-plugin
> 2.0
>
>
> --
> On module1 and module2 pom, I didn't declare any
> information.
> I've "only" declared the parent
>
> com.myProject
> modulepom
> 1.0-SNAPSHOT
>
>
> com.myProject
> module1
> jar
> 1.0-SNAPSHOT
> module1 name
> --
> Here are the index.html files generated on windows and linux in
> myProject/trunk/target/staging/localhost/ after launching mvn site:stage in
> directory myProject/trunk/
> --> Site deployed on Windows which is correct
>
> Modules
>
> module1 name
>
>
>
> module2 name
>
> ...
> --> Site deployed on Linux which isn't correct
> ...
> Modules
>
>href="../../tmp/testProject/myProject/trunk/../localhost">module1 name
>
>
>
>href="../../tmp/testProject/myProject/trunk/../localhost">module2 name
>
>...
> where /tmp/testProject/ is the absolute path where is stored myProject/ on
> linux
> --
> Any idea ?
> Maybe i should use something different in than
> file://
> Thanks for your help
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-395) Maven site multi module url problem
[ http://jira.codehaus.org/browse/MSITE-395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated MSITE-395: --- Attachment: genesis-2.0-SNAPSHOT-source-release.tar.gz Another really simple example showing the problem. This is an apache project so you can use it in an integration test. It's https://svn.apache.org/repos/asf/geronimo/genesis/trunk rev 782541 A typical link looks like Genesis Maven Plugin I ran mvn site site:stage -DstagingDirectory=/Users/david/tmp/staging The project is checked out locally to /Users/david/geronimo/svn/geronimo/genesis/trunk I'm on os x currently using java 1.6, maven 2.0.10, site plugin 2.0 > Maven site multi module url problem > --- > > Key: MSITE-395 > URL: http://jira.codehaus.org/browse/MSITE-395 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: multi module >Affects Versions: 2.0 >Reporter: valsho >Priority: Blocker > Attachments: genesis-2.0-SNAPSHOT-source-release.tar.gz > > > The generated maven (2.0.10) site for a multi module project is different on > windows and linux. > The difference is the relative url for the modules. > -- > Here's the project structure : > myProject/ >trunk/ > pom.xml > module1/ > pom.xml > src/ > module2/ > pom.xml > src/ > -- > Here's myProject/trunk/pom.xml definition : > com.myProject > modulepom > pom > POM myProject > 1.0-SNAPSHOT > > > module1 > module2 > > > > site > Maven site > file:// > > > > > org.apache.maven.plugins > maven-site-plugin > 2.0 > > > -- > On module1 and module2 pom, I didn't declare any > information. > I've "only" declared the parent > > com.myProject > modulepom > 1.0-SNAPSHOT > > > com.myProject > module1 > jar > 1.0-SNAPSHOT > module1 name > -- > Here are the index.html files generated on windows and linux in > myProject/trunk/target/staging/localhost/ after launching mvn site:stage in > directory myProject/trunk/ > --> Site deployed on Windows which is correct > > Modules > > module1 name > > > > module2 name > > ... > --> Site deployed on Linux which isn't correct > ... > Modules > >href="../../tmp/testProject/myProject/trunk/../localhost">module1 name > > > >href="../../tmp/testProject/myProject/trunk/../localhost">module2 name > >... > where /tmp/testProject/ is the absolute path where is stored myProject/ on > linux > -- > Any idea ? > Maybe i should use something different in than > file:// > Thanks for your help -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MRELEASE-278) release:clean doesn't clean up after release:branch
[ http://jira.codehaus.org/browse/MRELEASE-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated MRELEASE-278: -- Attachment: MRELEASE-278.diff Fixes the problem by including all the branch phases in the list of phase objects to run clean on. Note that this includes updates to the test config so there is a list of branch phases and also includes a test that checks that the branch phase clean is in fact called. To repeat, this includes a test. > release:clean doesn't clean up after release:branch > --- > > Key: MRELEASE-278 > URL: http://jira.codehaus.org/browse/MRELEASE-278 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch, clean >Affects Versions: 2.0-beta-6 > Environment: java version "1.5.0_11" > Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_11-b03) > Java HotSpot(TM) 64-Bit Server VM (build 1.5.0_11-b03, mixed mode) >Reporter: Graham Leggett > Attachments: MRELEASE-278.diff > > > When using release:branch -DdryRun=true to test a branch, some extra files > are left lying around like below. These cause release:branch to fail because > of unchecked-in modifications. > release:clean needs to be taught how to clean up after these files. > bash-3.00$ svn status > ? pom.xml.releaseBackup > ? pom.xml.branch > ? alchemy-cdo-client/pom.xml.releaseBackup > ? alchemy-cdo-client/pom.xml.branch > ? alchemy-transformer/pom.xml.releaseBackup > ? alchemy-transformer/pom.xml.branch > ? alchemy-native-assembly/pom.xml.releaseBackup > ? alchemy-native-assembly/pom.xml.branch > ? alchemy-cdo/pom.xml.releaseBackup > ? alchemy-cdo/pom.xml.branch -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSHADE-51) shade plugin relocate does not play well with maven-bundle-plugin
[ http://jira.codehaus.org/browse/MSHADE-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=178309#action_178309 ] David Jencks commented on MSHADE-51: Also reported as https://issues.apache.org/jira/browse/FELIX-1184 > shade plugin relocate does not play well with maven-bundle-plugin > - > > Key: MSHADE-51 > URL: http://jira.codehaus.org/browse/MSHADE-51 > Project: Maven 2.x Shade Plugin > Issue Type: Bug >Affects Versions: 1.2.1 >Reporter: David Jencks > > maven-bundle-plugin (from felix) v. 2.0.0 > If your build runs shade to relocate some classes from a preexisting jar and > the maven-bundle-plugin to geinerate osgi metadata the bundle plugin refuses > to generate any Export-Package, Import-Package or Private-Package headers. I > assume it doesn't find any classes. > I don't know whose fault this is. > To see this in action check out > https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-asm-shaded rev > 778992 and uncomment the bundle plugin and comment the transformers section > of the shade plugin config. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-51) shade plugin relocate does not play well with maven-bundle-plugin
shade plugin relocate does not play well with maven-bundle-plugin - Key: MSHADE-51 URL: http://jira.codehaus.org/browse/MSHADE-51 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.2.1 Reporter: David Jencks maven-bundle-plugin (from felix) v. 2.0.0 If your build runs shade to relocate some classes from a preexisting jar and the maven-bundle-plugin to geinerate osgi metadata the bundle plugin refuses to generate any Export-Package, Import-Package or Private-Package headers. I assume it doesn't find any classes. I don't know whose fault this is. To see this in action check out https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-asm-shaded rev 778992 and uncomment the bundle plugin and comment the transformers section of the shade plugin config. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-50) Shade relocate output jar not easily available to other modules in multi-module build
Shade relocate output jar not easily available to other modules in multi-module build - Key: MSHADE-50 URL: http://jira.codehaus.org/browse/MSHADE-50 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.2.1 Reporter: David Jencks We discovered this very strange behavior in xbean. check out https://svn.apache.org/repos/asf/geronimo/xbean/trunk rev 778992 The xbean-asm-shaded module is used in the xbean-reflect module. in the xbean-asm-shaded pom, comment out the antrun plugin configuration -- it's the bizarre workaround for this problem. Building xbean-asm-shaded always gets the expected content in the jar however these contents are not visible to xbean-reflect and the build fails. As noted about running the antrun plugin to unjar the output into classes (in xbean-asm-shaded) seems to fix the problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MASSEMBLY-405) "project" predefined dependencyRef really doesn't work in 2.2-beta-3
[ http://jira.codehaus.org/browse/MASSEMBLY-405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Jencks updated MASSEMBLY-405: --- Attachment: massembly-405-sample.jar portals portlet-api_1.0_spec project showing what happens with 2.2-beta-3 "project" descriptorRef. > "project" predefined dependencyRef really doesn't work in 2.2-beta-3 > > > Key: MASSEMBLY-405 > URL: http://jira.codehaus.org/browse/MASSEMBLY-405 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2-beta-3 >Reporter: David Jencks > Attachments: massembly-405-sample.jar > > > "project" dependencyRef uses bizarre paths in the zip etc archives, e.g. > portlet-api_1.0_spec-1.0-SNAPSHOT/Users/david/projects/jetspeed/portlet-spec/trunk/portlet-api-1.0/target/classes/javax/portlet/UnavailableException.class > 2.2-beta-2 seems to work OK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-405) "project" predefined dependencyRef really doesn't work in 2.2-beta-3
"project" predefined dependencyRef really doesn't work in 2.2-beta-3 Key: MASSEMBLY-405 URL: http://jira.codehaus.org/browse/MASSEMBLY-405 Project: Maven 2.x Assembly Plugin Issue Type: Bug Affects Versions: 2.2-beta-3 Reporter: David Jencks "project" dependencyRef uses bizarre paths in the zip etc archives, e.g. portlet-api_1.0_spec-1.0-SNAPSHOT/Users/david/projects/jetspeed/portlet-spec/trunk/portlet-api-1.0/target/classes/javax/portlet/UnavailableException.class 2.2-beta-2 seems to work OK. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4095) Release instructions unclear
Release instructions unclear
Key: MNG-4095
URL: http://jira.codehaus.org/browse/MNG-4095
Project: Maven 2
Issue Type: Improvement
Components: Documentation: General
Reporter: David Jencks
Refers to http://maven.apache.org/developers/release/releasing.html
This is AFAICT the de-facto advice on best practices for apache projects that
want to use maven... if there's more information elsewhere it should be linked
from here. As such it is sorely lacking some basic info such as...
1. It applies to projects using the apache pom version 5 which implies you are
deploying to nexus. This needs to be stated up front and the consequences
outlined (e.g. getting someone (who?) to move old stuff onto nexus, and what
happens to a large collection of projects (e.g. portals or geronimo) that may
not want to move everything at once)
2. if
${deploy.altRepository} in
the release profile is actually recommended please document where the value
actually comes from.
3. In the "Release Process for part of Maven" 1.b it says "Verify that all
pom.xml files have an SCM definition." I think this is wrong. IIUC only root
poms in a multimodule project should define scm.
4. In the note on the settings.xml server definition of apache.snapshots.https
please document that it is used from the apache 5 pom. Also, I think that the
password required is your apache svn password rather than a possible p.a.o
password. There is at least one other reference to logging on to nexus with
"apache credentials" that should be more specifically "apache svn username and
password"
5. If this is the de-facto advice to apache projects wishing to move from the
file based repo to apache's nexus it needs to be findable through google.
Linking it to INFRA-1885 would be good. Linking from the front page of the
maven docs would be good. More generic separate docs would be better.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4052) import scope dependencies prefer to download pom rather than find it in the current project
import scope dependencies prefer to download pom rather than find it in the
current project
---
Key: MNG-4052
URL: http://jira.codehaus.org/browse/MNG-4052
Project: Maven 2
Issue Type: Bug
Components: Reactor and workspace
Affects Versions: 2.0.9
Reporter: David Jencks
I've run into this in geronimo trunk.
Initial project state:
root pom includes dependency A in dependencyManagement.
this dependency is used (in dependencies) in several places including
plugins/clustering/plugin-farm-datasource/
Snapshots for this project are deployed (at apache snapshot repo)
project update:
move A to dependencyManagement of plugins/system-database/pom.xml (also a pom
packaging)
include in plugins/clustering/plugin-farm-datasource/pom.xml
org.apache.geronimo.plugins
system-database
${version}
pom
import
(this is a car packaging project, using the geronimo car-maven-plugin)
now, clean the local repo and try to build the project from root.
we see:
pb:trunk david$ mvn clean install -Pit
[INFO] Scanning for projects...
[INFO] snapshot org.apache.geronimo.plugins:system-database:2.2-SNAPSHOT:
checking for updates from apache.snapshots
[INFO] snapshot org.apache.geronimo.plugins:system-database:2.2-SNAPSHOT:
checking for updates from apache-snapshots
[INFO] snapshot org.apache.geronimo.plugins:system-database:2.2-SNAPSHOT:
checking for updates from codehaus-snapshots
Downloading:
http://people.apache.org/repo/m2-snapshot-repository/org/apache/geronimo/plugins/system-database/2.2-SNAPSHOT/system-database-2.2-SNAPSHOT.pom
rather than using the system-database pom in the local project it is
downloading the obsolete snapshot.
I've worked around this by uploading the system-database pom by hand.
I may try to write a sample project but since seeing the bug depends on having
a deployed snapshot and then changing it locally I have no idea how to write an
automated test.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MWAR-178) war plugin documentation and probably implementation is unaware of javaee 5
war plugin documentation and probably implementation is unaware of javaee 5 --- Key: MWAR-178 URL: http://jira.codehaus.org/browse/MWAR-178 Project: Maven 2.x War Plugin Issue Type: Bug Reporter: David Jencks The example I'm aware of: http://maven.apache.org/plugins/maven-war-plugin/examples/skinny-wars.html talks about using the war's manifest.mf classpath to include jars in the ear in the war module's classloader. In ee5, there's a ear lib directory: everything in that is automatically included in the ear level classloader, which is certainly available to every war, most likely by being a parent classloader to the war classloader. One consequence of this is that using the manifest classpath in a 1.4 container will likely result in each war getting separate copies of the lib jar classes whereas the ee5 lib directory will result in shared classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1977) Global dependency exclusions
[ http://jira.codehaus.org/browse/MNG-1977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=144971#action_144971 ] David Jencks commented on MNG-1977: --- It seems to me that the original problem would be solved better by artifact substitution or aliasing rather than more exclusions. e.g if you want to use something reasonable such as slf4j to imitate commons logging usage you want to replace any dependency on commons-logging with one on jcl-over-slf4j. Similarly you might want to swap spec implementations, say to use the geronimo ones no matter which copies the original projects were built against, or use geronimo's activation implementation instead of sun's. This isn't quite the same as what osgi gives you but is quite powerful. > Global dependency exclusions > > > Key: MNG-1977 > URL: http://jira.codehaus.org/browse/MNG-1977 > Project: Maven 2 > Issue Type: New Feature > Components: POM >Reporter: Kees de Kooter > Fix For: 3.0 > > > I depend on some libraries, which in turn depend on something > (which in turn depend on something) that I don't want, because I declare > some other artifact in my pom.xml. > A concrete example: I don't want that the artifact "xerces" is imported in > my project because I declare to depend on "xercesImpl" which ships newer > libraries but with the same namespaces. > I guess I would need an "exclude transitive dependency at all", either > globally or from this and that artifact. I saw the tag, but it > forces me to be very verbose and have exact control on what is required by a > dependency. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEP-176) excludes not considered in analyze?
excludes not considered in analyze? --- Key: MDEP-176 URL: http://jira.codehaus.org/browse/MDEP-176 Project: Maven 2.x Dependency Plugin Issue Type: Bug Components: analyze Affects Versions: 2.0 Reporter: David Jencks Assignee: Brian Fox in dependencyManagement of parent pom I have: org.apache.xmlbeans xmlbeans 2.3.0 stax stax-api In a child project... org.apache.xmlbeans xmlbeans org.apache.geronimo.specs geronimo-stax-api_1.0_spec dependency:analyze reports [WARNING] Unused declared dependencies found: [WARNING] org.apache.geronimo.specs:geronimo-stax-api_1.0_spec:jar:1.0.1:compile but removing the geronimo stax api makes the build fail. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3516) Make dependencies on javaee artifacts such as war, ear, rar get the contents into the classpath.
Make dependencies on javaee artifacts such as war, ear, rar get the contents into the classpath. Key: MNG-3516 URL: http://jira.codehaus.org/browse/MNG-3516 Project: Maven 2 Issue Type: New Feature Reporter: David Jencks Some javaee servers such as geronimo and IIRC jboss let you construct classloader hierarchies where the classes from one javaee app can be available in another javaee app's classloader. Maven ought to be able to support stuff like this by having a more flexible model of how to get the classes from something more complicated than a jar into a classpath. This is most important for war files where the WEB-INF/classes directory generally contains stuff that won't be available anywhere else in a maven repo. For ear libs and rars presumably the contents are available as independent artifacts in a repo. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-3515) Allow several synonymous main artifacts, e.g. zip and tar.gz, just like you can have with a classifier
Allow several synonymous main artifacts, e.g. zip and tar.gz, just like you can have with a classifier -- Key: MNG-3515 URL: http://jira.codehaus.org/browse/MNG-3515 Project: Maven 2 Issue Type: New Feature Reporter: David Jencks It's possible for a project to generate several synonymous main artifacts that are different packagings of the same content. The specific case I ran across is in https://svn.apache.org/repos/asf/activemq/branches/activemq-4.1 assembly module rev 646965. The build happily constructs apache-activemq-4.1-SNAPSHOT.tar.gz/tar.bz2/zip artifacts in target but does not install or deploy them. However if I add a "bin" classifier all the artifacts are installed/deployed. Another possible example that jdcasey suggested would be a project that constructs both dll and so files. I don't see how this could introduce any ambiguity since any dependency on a non-jar artifact has to AFAIK specify the type explicitly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MASSEMBLY-305) dependencySet includes [groupId]:[artifactId]:[type]:[classifier] syntax doesn't work
dependencySet includes
[groupId]:[artifactId]:[type]:[classifier] syntax doesn't
work
Key: MASSEMBLY-305
URL: http://jira.codehaus.org/browse/MASSEMBLY-305
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-2
Reporter: David Jencks
create a project that generates 2 artifacts, say
org.apache.activemq:activemq-all:4.1-SNAPSHOT:jar and
org.apache.activemq:activemq-all:4.1-SNAPSHOT:jar:run
Then in a descriptor include something like
/bin
false
run.jar
${pom.groupId}:activemq-all:jar:run
The main artifact, not the "run"-classified one, gets copied.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRRESOURCES-32) apache-jar-resource-bundle NOTICE file is not consistent with apache policy
apache-jar-resource-bundle NOTICE file is not consistent with apache policy --- Key: MRRESOURCES-32 URL: http://jira.codehaus.org/browse/MRRESOURCES-32 Project: Maven 2.x Remote Resources Plugin Issue Type: Bug Affects Versions: 1.0-beta-2 Reporter: David Jencks Attachments: apache-jar-resource-bundle.diff Recent discussions on the apache legal-discuss list have made it extremely clear that the generated NOTICE file from the current (1.3) apache-jar-resource-bundle is not consistent with apache policy on contents of NOTICE files. After working hard to clarify what the policy might be I've come up with a bundle whose output has not produced any objections. We're using this currently in geronimo but would like to get this into a more global location for an imminent apacheds release. The main change is that the NOTICE file contains only the apache notice. You can append other notices using the appended-resources directory. This corresponds to the policy that the NOTICE file apply to exactly what is actually in the jar, not at all to any dependencies it may need to actually be used, and that the NOTICE file not have any excess verbiage such as horizontal rules or explanatory text. The dependencies are listed by license in an additional informative DEPENDENCIES file. There are a couple weird things that it would be great if someone could figure out: - I can't get a blank line between the project name and the notice in the NOTICE file - I can't figure out how to configure a projectName so it is used in the NOTICE file project name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRAR-20) Allow specification of where the jars and other files end up in the rar.
Allow specification of where the jars and other files end up in the rar. Key: MRAR-20 URL: http://jira.codehaus.org/browse/MRAR-20 Project: Maven 2.x Rar Plugin Issue Type: Improvement Reporter: David Jencks The connector 1.5 spec section 17.2.0.2 indicates that everything in the rar except the META-INF/ra.xml file can be at an arbitrary location. Possibly this can already be specified somehow in which case we should document it clearly and otherwise implement it. Requested by Bastiaan de Wit in a private email. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRAR-3) Rar should be, or be able to be considered as, attached artifacts
[ http://jira.codehaus.org/browse/MRAR-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114395 ] David Jencks commented on MRAR-3: - I think this is still relevant. The workaround would be to build the jar in a separate project and in the rar packaging project exclude that projects (empty) jar. > Rar should be, or be able to be considered as, attached artifacts > - > > Key: MRAR-3 > URL: http://jira.codehaus.org/browse/MRAR-3 > Project: Maven 2.x Rar Plugin > Issue Type: Bug >Reporter: Guillaume Nodet >Priority: Critical > > ActiveMQ used to deploy both jar and rar. > And both are used. > I do not see any way to do so in m2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRAR-18) Permit creation of client
[ http://jira.codehaus.org/browse/MRAR-18?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114394 ] David Jencks commented on MRAR-18: -- Can you provide some reference for this concept of a rar client module? I have not heard of them previously. Since a rar only works in-vm the main motivation for a client module is lost AFAICT. > Permit creation of client > - > > Key: MRAR-18 > URL: http://jira.codehaus.org/browse/MRAR-18 > Project: Maven 2.x Rar Plugin > Issue Type: Improvement > Environment: Wherever >Reporter: Sebastião Alessandro Linhares dos Santos >Priority: Minor > > RAR, as like EJB needs client module, generally created having same source as > RAR. > So, what about permit that the RAR plugin generates client jar too, like EJB. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-272) Release plugin tags into wrong directory
Release plugin tags into wrong directory Key: MRELEASE-272 URL: http://jira.codehaus.org/browse/MRELEASE-272 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-6, 2.0-beta-4 Environment: osx 10.4, java 5 Reporter: David Jencks I tried to use the release plugin, both beta-6 and beta-4 to release some new geronimo jars, but it kept tagging into a parent poms directory, not the one specified in the scm element OR one specified on the command line via -DtagBase. To see this svn co -r561686 https://svn.apache.org/repos/asf/geronimo/components/txmanager/trunk mvn release:prepare -DdryRun=true -DtagBase=https://svn.apache.org/repos/asf/geronimo/components/txmanager cat pom.xml.tag The parent pom does not have a scm section. Would that help? As I write it is not yet released, for simplicity you may want to check it out from svn co https://svn.apache.org/repos/asf/geronimo/genesis/branches/1.2 the release plugin version specified there is 2.0-beta-4 but changing it to beta-6 has no apparent effect. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2880) dependency plugin has trouble recognizing that a dependency is in the repo when you specify a classifier
dependency plugin has trouble recognizing that a dependency is in the repo when
you specify a classifier
Key: MNG-2880
URL: http://jira.codehaus.org/browse/MNG-2880
Project: Maven 2
Issue Type: Bug
Components: Plugins and Lifecycle
Affects Versions: 2.0.5
Reporter: David Jencks
Brian Fox suggested opening this jira after an irc discussion.
I'm trying to manipulate a zip (or tgz) distribution for my own evil purposes.
I installed it in my local maven repo using the command maven suggested:
mvn install:install-file -DgroupId=org.apache.roller -DartifactId=roller
-Dversion=3.1-rc6 -Dpackaging=zip -Dfile=roller-war/apache-roller-3.1-rc6.zip
it ended up:
$ ls ~/.m2/repository/org/apache/roller/roller/3.1-rc6/roller-3.1-rc6.zip
/Users/david/.m2/repository/org/apache/roller/roller/3.1-rc6/roller-3.1-rc6.zip
I'm trying to unpack it with the dependency plugin:
org.apache.maven.plugins
maven-dependency-plugin
unpack-distribution
generate-resources
unpack
org.apache.roller
roller
bin
zip
3.1-rc6
${project.build.directory}/scratch
and maven complains it can't find it:
[INFO] Failed to resolve artifact.
GroupId: org.apache.roller
ArtifactId: roller
Version: 3.1-rc6
Reason: System is offline.
Try downloading the file manually from the project website.
Then, install it using the command:
mvn install:install-file -DgroupId=org.apache.roller -DartifactId=roller \
-Dversion=3.1-rc6 -Dpackaging=zip -Dfile=/path/to/file
org.apache.roller:roller:zip:3.1-rc6
It turns out that if I remove the bin line from the
dependency plugin config then maven can find the file.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2796) Yet another snapshot/timestamp version resolution problem
Yet another snapshot/timestamp version resolution problem
-
Key: MNG-2796
URL: http://jira.codehaus.org/browse/MNG-2796
Project: Maven 2
Issue Type: Bug
Components: Artifacts and Repositories, Inheritance and Interpolation
Affects Versions: 2.0.4
Reporter: David Jencks
In the geronimo openejb3 integration we've encountered yet another problem with
broken version resolution. It would be great if the maven team could fix these
problems soon: I think that the geronimo and openejb developers have now spent
several weeks trying to understand bizarre version resolution errors and trying
to find workarounds for them.
Here's what we think the relevant project details are. Reproducing this
problem requires deploying snapshots at different revision numbers so I don't
really see how to provide a test project.
openejb project structure:
base openejb pom
openejb container pom, parent is openejb pom. Snapshot deployed with a
timestamped version 3.0-incubating-20070126.103431-21
openejb server pom, parent is openejb pom. Snapshot deployed with a
timestamped version 3.0-incubating-20070126.103431-20
server pom has a dependency on container pom, using this:
org.apache.openejb
container
${pom.version}
pom
compile
Subproject server/openejb-ejbd, parent pom is server.pom. Snapshot deployed at
3.0-incubating-20070126.103431-20
Both container and server are pom-packaged projects, i.e. they have no code of
their own.
Openejb builds and deploys fine by itself, and the timestamped versions are as
indicated above.
geronimo-openejb module has a dependency
org.apache.openejb
openejb-ejbd
whose version is supplied in an ancestor dependencyManagement section:
org.apache.openejb
openejb-ejbd
${openejbVersion}
where
3.0-incubating-SNAPSHOT
When we build the geronimo-openejb module in geronimo the build breaks because
the incorrect version of openejb container is resolved:
This appears to be the relevant section of the -X trace, note that after the
incorrect non-resolution at -20 container is correctly resolved at -21 a few
lines later:
[DEBUG] openejb-client: resolved to version 3.0-incubating-20070126.103431-20
from repository apache.snapshots
[DEBUG] Retrieving parent-POM:
org.apache.openejb:server::3.0-incubating-SNAPSHOT for project:
null:openejb-client:jar:3.0-incubating-20070126.103431-20 from the repository.
[DEBUG] server: resolved to version 3.0-incubating-20070126.103431-20 from
repository apache.snapshots
[DEBUG] Retrieving parent-POM:
org.apache.openejb:openejb::3.0-incubating-SNAPSHOT for project:
null:server:pom:null from the repository.
[DEBUG] openejb: resolved to version 3.0-incubating-20070126.103431-22 from
repository apache.snapshots
[DEBUG] Retrieving parent-POM: org.apache:apache::3 for project:
org.apache.openejb:openejb:pom:3.0-incubating-SNAPSHOT from the repository.
[DEBUG]
org.apache.openejb:openejb-client:jar:3.0-incubating-SNAPSHOT:compile (selected
for compile)
[DEBUG] Retrieving parent-POM: org.apache.geronimo.specs:specs::1.2 for
project: null:geronimo-ejb_3.0_spec:jar:1.0-M1 from the repository.
[DEBUG] Retrieving parent-POM:
org.apache.geronimo.genesis.config:project-config::1.1 for project:
org.apache.geronimo.specs:specs:pom:1.2 from the repository.
[DEBUG] Retrieving parent-POM: org.apache.geronimo.genesis.config:config::1.1
for project: null:project-config:pom:null from the repository.
[DEBUG] Retrieving parent-POM: org.apache.geronimo.genesis:genesis::1.1 for
project: org.apache.geronimo.genesis.config:config:pom:null from the repository.
[DEBUG] Retrieving parent-POM: org.apache:apache::3 for project:
org.apache.geronimo.genesis:genesis:pom:1.1 from the repository.
[DEBUG]
org.apache.geronimo.specs:geronimo-ejb_3.0_spec:jar:1.0-M1:compile (removed -
nearer found: 1.0)
[DEBUG] Artifact not found - using stub model: System is offline.
org.apache.openejb:container:pom:3.0-incubating-20070126.103431-20
[DEBUG] Using defaults for missing POM
org.apache.openejb:container:pom:3.0-incubating-SNAPSHOT:compile
[DEBUG]
org.apache.openejb:container:pom:3.0-incubating-20070126.103431-20:compile
(selected for compile)
[DEBUG] org.apache.geronimo.specs:geronimo-ejb_3.0_spec:jar:1.0-M1:compile
(removed - nearer found: 1.0)
[DEBUG]
org.apache.openejb:container:pom:3.0-incubating-20070126.103431-20:compile
(selected for compile)
[DEBUG] Skipping disabled repository tomcat-m2-repo
[DEBUG] Skipping disabled repository apache-incubator
[DEBUG] Skipping disabled repository codehaus
[DEBUG] Skipping disabled repository central
[DEBUG] openejb-core: resolved to version 3.0-incubating-20070126.103431-20
from repository apa
[jira] Created: (MWAR-61) Document how to set manifest classpath and exclude dependency from WEB-INF/lib
Document how to set manifest classpath and exclude dependency from WEB-INF/lib -- Key: MWAR-61 URL: http://jira.codehaus.org/browse/MWAR-61 Project: Maven 2.x War Plugin Type: Improvement Versions: 2.0.1 Reporter: David Jencks Attachments: war-plugin-manifestcp-doc.patch I had to get some help from evenisse to figure out how to generate the manifest classpath yet not include all the dependencies in WEB-INF/lib. I still don't know how to get a dependency into WEB-INF/lib but not the manifest classpath when generating the manifest classpath, but this should help anyone just trying to use a manifest cp in an ear. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-930) Upload request for objectweb howl logger
[ http://jira.codehaus.org/browse/MAVENUPLOAD-930?page=all ] David Jencks closed MAVENUPLOAD-930: Resolution: Fixed With help from numerous people I succeeded in uploading howl to the objectweb m2 repo, so this upload request should be ignored. Thanks! > Upload request for objectweb howl logger > > > Key: MAVENUPLOAD-930 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-930 > Project: maven-upload-requests > Type: Task > Reporter: David Jencks > Attachments: howl-logger-1.0.1-1-bundle.jar > > > This is a copy of the 1.0.1 howl logger jar built with maven 2 using the pom > in the upload bundle. It differs from the howl-1.0.1.jar distributed from > objectweb in that it is built with jdk 1.4 and it includes the maven pom > files etc. Therefore I'm labelling it version 1.0.1-1 > In accordance with maven 2 usage I've set the groupId to org.objectweb.howl. > Some pre-1.0 releases were put in maven 1 repos under howl, but I do not > think these are in use any longer and would prefer to use the m2 style > groupId. > It may not be obvious that the contributor url is actually for howl. Look > closely and you will find a tab labelled "High-speed ObjectWeb Logger" in the > top tab row at the right. > I'll attach the release bundle as well as it is rather small. > We would appreciate prompt upload as we would like to get this into the > geronimo 1.1 rc release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-45) add config prop to specify webapp classes should be zipped and placed into WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/
[ http://jira.codehaus.org/browse/MWAR-45?page=comments#action_66816 ] David Jencks commented on MWAR-45: -- I think adding this capability is a very good idea. IIUC the only argument against it is that it is possible to get the same effect by putting the classes into a separate project. I think this ignores the different effects and affect of having 2 projects: 1. Having 2 projects forces you to maintain what you are likely to be thinking of as one project in two places: e.g. even without jsps, the web.xml is going to be far away in the file system and IDE from the classes it is the descriptor for. I think breaking the way people think about their project in this way is inadvisable. 2. If you have jsps, you cannot precompile them and include them in the project classes jar without moving them into the classes project. What should be a packaging option requires major svn changes to your project. 3. With 2 projects you are forced to publish the classes jar. You may not want to pollute your repo with this artifact that you may regard as unnecessary. Also, you are apt to want to name both projects with the same name. 4. If you want 2 profiles, one to pack classes into a jar and the other to leave them in WEB-INF/classes, you are forced to unpack the jar if the jar is from a separate project. This is going to be a bit slower than not creating the jar in the first place. I'm sure there are more, this is just what came to mind during a moments consideration. war files are a pretty strange and perhaps inadvisable construction, but I think it is better for maven to try to adapt to what they are and how they are used rather than trying to force everyone to essentially use something else. > add config prop to specify webapp classes should be zipped and placed into > WEB-INF/lib/xxx.jar instead of placed in WEB-INF/classes/ > - > > Key: MWAR-45 > URL: http://jira.codehaus.org/browse/MWAR-45 > Project: Maven 2.x War Plugin > Type: New Feature > Versions: 2.0 > Reporter: Ian Springer > Attachments: mwar-45.patch > > > I think this is a common enough practice that there should be an option > provided for it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-930) Upload request for objectweb howl logger
Upload request for objectweb howl logger Key: MAVENUPLOAD-930 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-930 Project: maven-upload-requests Type: Task Reporter: David Jencks Attachments: howl-logger-1.0.1-1-bundle.jar This is a copy of the 1.0.1 howl logger jar built with maven 2 using the pom in the upload bundle. It differs from the howl-1.0.1.jar distributed from objectweb in that it is built with jdk 1.4 and it includes the maven pom files etc. Therefore I'm labelling it version 1.0.1-1 In accordance with maven 2 usage I've set the groupId to org.objectweb.howl. Some pre-1.0 releases were put in maven 1 repos under howl, but I do not think these are in use any longer and would prefer to use the m2 style groupId. It may not be obvious that the contributor url is actually for howl. Look closely and you will find a tab labelled "High-speed ObjectWeb Logger" in the top tab row at the right. I'll attach the release bundle as well as it is rather small. We would appreciate prompt upload as we would like to get this into the geronimo 1.1 rc release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MEV-406) XMLBeans pom is missing dependency
[ http://jira.codehaus.org/browse/MEV-406?page=all ] David Jencks updated MEV-406: - Attachment: xbean-2.0.0.pom > XMLBeans pom is missing dependency > -- > > Key: MEV-406 > URL: http://jira.codehaus.org/browse/MEV-406 > Project: Maven Evangelism > Type: Bug > Components: Dependencies > Reporter: David Jencks > Attachments: xbean-2.0.0.pom > > > The xmlbeans 2.0.0 pom is missing the one required dependency on the stax > api. xmlbeans seems to ship a jsr-173-api jar that is of AFAICT unknown > provenance. AFAIK everyone has been using the stax-api jar with no problems > for years: certainly geronimo has. > To see that this is the single required dependency, consult > http://xmlbeans.apache.org/documentation/conInstallGuide.html and look at the > bottom of the page at the suggested classpath setup, e.g.: > export > CLASSPATH=$XMLBEANS_HOME/lib/xbean.jar:$XMLBEANS_HOME/lib/jsr173_1.0_api.jar:$CLASSPATH > Here's the pom, the instructions at > http://maven.apache.org/guides/mini/guide-maven-evangelism.html point to > invalid svn locations so I cannot check out the original and supply a patch. > The pom goes at ~/.m2/repository/xmlbeans/xbean/2.0.0/xbean-2.0.0.pom in a > local repo. I'll attach it as well. > > 4.0.0 > xmlbeans > xbean > 2.0.0 > > > stax > stax-api > 1.0 > > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-406) XMLBeans pom is missing dependency
XMLBeans pom is missing dependency -- Key: MEV-406 URL: http://jira.codehaus.org/browse/MEV-406 Project: Maven Evangelism Type: Bug Components: Dependencies Reporter: David Jencks The xmlbeans 2.0.0 pom is missing the one required dependency on the stax api. xmlbeans seems to ship a jsr-173-api jar that is of AFAICT unknown provenance. AFAIK everyone has been using the stax-api jar with no problems for years: certainly geronimo has. To see that this is the single required dependency, consult http://xmlbeans.apache.org/documentation/conInstallGuide.html and look at the bottom of the page at the suggested classpath setup, e.g.: export CLASSPATH=$XMLBEANS_HOME/lib/xbean.jar:$XMLBEANS_HOME/lib/jsr173_1.0_api.jar:$CLASSPATH Here's the pom, the instructions at http://maven.apache.org/guides/mini/guide-maven-evangelism.html point to invalid svn locations so I cannot check out the original and supply a patch. The pom goes at ~/.m2/repository/xmlbeans/xbean/2.0.0/xbean-2.0.0.pom in a local repo. I'll attach it as well. 4.0.0 xmlbeans xbean 2.0.0 stax stax-api 1.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVEN-1751) "A cycle was detected" where no cycle can be found
[ http://jira.codehaus.org/browse/MAVEN-1751?page=comments#action_60908 ] David Jencks commented on MAVEN-1751: - I don't know if it is related to this exact problem, but I have noticed that if I accidentally have 2 subprojects with the same name, maven claims there is a cycle. Changing the name of one project allows the build to proceed. > "A cycle was detected" where no cycle can be found > -- > > Key: MAVEN-1751 > URL: http://jira.codehaus.org/browse/MAVEN-1751 > Project: Maven > Type: Bug > Versions: 1.1-beta-2 > Environment: SUSE Linux 10.0 (kernel 2.6.13-15-smp), J2SDK 1.4.2_10 > Reporter: Anders Heintz > Attachments: proj1_dependencies.xml, proj2_dependencies.xml, > proj3_dependencies.xml > > > I have a quite large multiproject project which I fail to build using Maven > 1.1beta2 (Maven 1.0.2 works fine). I "divided and conquered" a bit and > excluded all but the most basic project, then added one at a time. When I > included my third project, the build fails with the message "A cycle was > detected". The dependencies for these tree projects (except external > dependencies) are: > Project 1 depends on Project 2 and Project 3. Project 2 depends on Project 3. > Project 3 is a base "project" which contains common services and are used by > all other projects. > I'll attach the dependencies part of the three subprojects. > When I run the same goal (any multiproject goal, for example 'maven > -Dgoal=clean multiproject:goal') using Maven 1.0.2 it works fine: > Starting the reactor... > Our processing order: > webSelect Project 3 > webSelect Project 2 > webSelect Project 1 > When I tried commenting out all dependencies apart from the project mentioned > above, it still fails, it even fails when I remove Project 1's dependency to > Project 3. > What is even more confusing is when I replace Project 1 with another > subproject which have the same dependencies it works fine (which however, is > a ejb project instead of being a jar project which Project 1 is). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
