[jira] [Created] (MASSEMBLY-838) Assembly descriptor schemas are missing from web site
William Ferguson created MASSEMBLY-838: -- Summary: Assembly descriptor schemas are missing from web site Key: MASSEMBLY-838 URL: https://issues.apache.org/jira/browse/MASSEMBLY-838 Project: Maven Assembly Plugin Issue Type: Bug Components: site Affects Versions: 3.0.0 Reporter: William Ferguson The assembly descriptor schemas listed at http://maven.apache.org/plugins/maven-assembly-plugin/ (eg http://maven.apache.org/xsd/assembly-2.0.0.xsd) are missing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] (MASSEMBLY-671) Cryptic debug warning message needs improvement and/or documentation
[
https://jira.codehaus.org/browse/MASSEMBLY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344701#comment-344701
]
William Ferguson commented on MASSEMBLY-671:
NB I would open the issue again if I could, but I don't seem to have that
capability
> Cryptic debug warning message needs improvement and/or documentation
>
>
> Key: MASSEMBLY-671
> URL: https://jira.codehaus.org/browse/MASSEMBLY-671
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor
>Affects Versions: 2.2.1, 2.4
> Environment: irrelevant
>Reporter: Steve Cohen
>
> I have used the assembly plugin both versions 2.4 and 2.2.1. While the
> plugin basically works, I have some problems with it, (see MASSEMBLY-670),
> which I suspect may be related to the following message that shows up when
> running Maven in debug mode (-X):
> {noformat}
> [DEBUG] All known ContainerDescriptorHandler components: [plexus,
> metaInf-spring, metaInf-services, file-aggregator]
> [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> java.util.NoSuchElementException
> role: org.apache.maven.artifact.resolver.ArtifactResolver
> roleHint: project-cache-aware
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:257)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:233)
> at
> org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.contextualize(PlexusLifecycleManager.java:317)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.manageLifecycle(PlexusLifecycleManager.java:292)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:148)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> at
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at
> com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
> at
> com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
> at
> org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83)
> at
> org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49)
> at
> org.sonatype.guice.bean.locators.EntryListAdapter$ValueIterator.next(EntryListAdapter.java:112)
> at
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>at or
[jira] (MASSEMBLY-671) Cryptic debug warning message needs improvement and/or documentation
[
https://jira.codehaus.org/browse/MASSEMBLY-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=344699#comment-344699
]
William Ferguson commented on MASSEMBLY-671:
Sent pull request containing a simple modification of the assembly descriptor
that shows 671.
> Cryptic debug warning message needs improvement and/or documentation
>
>
> Key: MASSEMBLY-671
> URL: https://jira.codehaus.org/browse/MASSEMBLY-671
> Project: Maven Assembly Plugin
> Issue Type: Bug
> Components: component descriptor
>Affects Versions: 2.2.1, 2.4
> Environment: irrelevant
>Reporter: Steve Cohen
>
> I have used the assembly plugin both versions 2.4 and 2.2.1. While the
> plugin basically works, I have some problems with it, (see MASSEMBLY-670),
> which I suspect may be related to the following message that shows up when
> running Maven in debug mode (-X):
> {noformat}
> [DEBUG] All known ContainerDescriptorHandler components: [plexus,
> metaInf-spring, metaInf-services, file-aggregator]
> [DEBUG] Cannot find ArtifactResolver with hint: project-cache-aware
> org.codehaus.plexus.component.repository.exception.ComponentLookupException:
> java.util.NoSuchElementException
> role: org.apache.maven.artifact.resolver.ArtifactResolver
> roleHint: project-cache-aware
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:257)
> at
> org.codehaus.plexus.DefaultPlexusContainer.lookup(DefaultPlexusContainer.java:233)
> at
> org.apache.maven.shared.repository.DefaultRepositoryAssembler.contextualize(DefaultRepositoryAssembler.java:721)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.contextualize(PlexusLifecycleManager.java:317)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.manageLifecycle(PlexusLifecycleManager.java:292)
> at
> org.sonatype.guice.plexus.lifecycles.PlexusLifecycleManager.onProvision(PlexusLifecycleManager.java:148)
> at
> com.google.inject.internal.ProvisionListenerStackCallback$Provision.provision(ProvisionListenerStackCallback.java:108)
> at
> com.google.inject.internal.ProvisionListenerStackCallback.provision(ProvisionListenerStackCallback.java:55)
> at
> com.google.inject.internal.ProviderInternalFactory.circularGet(ProviderInternalFactory.java:68)
> at
> com.google.inject.internal.InternalFactoryToInitializableAdapter.get(InternalFactoryToInitializableAdapter.java:45)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1018)
> at
> com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)
> at com.google.inject.Scopes$1$1.get(Scopes.java:59)
> at
> com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:41)
> at
> com.google.inject.internal.InjectorImpl$3$1.call(InjectorImpl.java:965)
> at
> com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1011)
> at
> com.google.inject.internal.InjectorImpl$3.get(InjectorImpl.java:961)
> at
> org.sonatype.guice.bean.locators.LazyBeanEntry.getValue(LazyBeanEntry.java:83)
> at
> org.sonatype.guice.plexus.locators.LazyPlexusBean.getValue(LazyPlexusBean.java:49)
> at
> org.sonatype.guice.bean.locators.EntryListAdapter$ValueIterator.next(EntryListAdapter.java:112)
> at
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:181)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:436)
> at
> org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:101)
> at
> org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:209)
> 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.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:59)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.singleThreadedBuild(LifecycleStarter.java:183)
> at
> org.apache.maven.lifecycle.internal.LifecycleStarter.execute(LifecycleStarter.java:161)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:320)
>
[jira] (MSHARED-326) Patch that enables all maven-dependency-tree ITs
[ https://jira.codehaus.org/browse/MSHARED-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343754#comment-343754 ] William Ferguson commented on MSHARED-326: -- Thanks Herve. And thanks for the pointer to the git repos. > Patch that enables all maven-dependency-tree ITs > > > Key: MSHARED-326 > URL: https://jira.codehaus.org/browse/MSHARED-326 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree >Reporter: William Ferguson >Assignee: Herve Boutemy > Fix For: maven-dependency-tree-2.2 > > Attachments: enabled-all-ITs.patch > > > Two of the three maven-dep-tree integrated tests were commented out because > they didn't work. The attached patch enables them to run successfully. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-326) Patch that enables all maven-dependency-tree ITs
[ https://jira.codehaus.org/browse/MSHARED-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343713#comment-343713 ] William Ferguson commented on MSHARED-326: -- Wish we had a GIT repo to submit too instead of subversion. I'd really like to be able to commit these changes and then move on. > Patch that enables all maven-dependency-tree ITs > > > Key: MSHARED-326 > URL: https://jira.codehaus.org/browse/MSHARED-326 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree >Reporter: William Ferguson > Attachments: enabled-all-ITs.patch > > > Two of the three maven-dep-tree integrated tests were commented out because > they didn't work. The attached patch enables them to run successfully. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-326) Patch that enables all maven-dependency-tree ITs
[ https://jira.codehaus.org/browse/MSHARED-326?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Ferguson updated MSHARED-326: - Patch Submitted: Yes Issue Type: Bug (was: Improvement) > Patch that enables all maven-dependency-tree ITs > > > Key: MSHARED-326 > URL: https://jira.codehaus.org/browse/MSHARED-326 > Project: Maven Shared Components > Issue Type: Bug > Components: maven-dependency-tree >Reporter: William Ferguson > Attachments: enabled-all-ITs.patch > > > Two of the three maven-dep-tree integrated tests were commented out because > they didn't work. The attached patch enables them to run successfully. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-326) Patch that enables all maven-dependency-tree ITs
[ https://jira.codehaus.org/browse/MSHARED-326?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=343662#comment-343662 ] William Ferguson commented on MSHARED-326: -- These changes work find for Maven 3.0 and 3.1 ,3.2 But the verbose/tree-default IT fails for Maven 2.2.1 - but looking at the relevant POMs it seems clear that Maven-2.2.1 dependency resolution is at fault. Since Maven 2 is long deprecated I would be inclined to look past that and move on. > Patch that enables all maven-dependency-tree ITs > > > Key: MSHARED-326 > URL: https://jira.codehaus.org/browse/MSHARED-326 > Project: Maven Shared Components > Issue Type: Improvement > Components: maven-dependency-tree >Reporter: William Ferguson > Attachments: enabled-all-ITs.patch > > > Two of the three maven-dep-tree integrated tests were commented out because > they didn't work. The attached patch enables them to run successfully. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] (MSHARED-326) Patch that enables all maven-dependency-tree ITs
William Ferguson created MSHARED-326: Summary: Patch that enables all maven-dependency-tree ITs Key: MSHARED-326 URL: https://jira.codehaus.org/browse/MSHARED-326 Project: Maven Shared Components Issue Type: Improvement Components: maven-dependency-tree Reporter: William Ferguson Attachments: enabled-all-ITs.patch Two of the three maven-dep-tree integrated tests were commented out because they didn't work. The attached patch enables them to run successfully. -- This message was sent by Atlassian JIRA (v6.1.6#6162)
[jira] Created: (MSITE-485) Add a DateBuilt field to the Build Information section of the Project Summary page
Add a DateBuilt field to the Build Information section of the Project Summary page -- Key: MSITE-485 URL: http://jira.codehaus.org/browse/MSITE-485 Project: Maven 2.x Site Plugin Issue Type: Improvement Affects Versions: 2.1 Reporter: William Ferguson One of the biggest problems (IMHO) when looking at project documentation is the inability to readily determine the age of a component or the age age of the documentation. Such information is often sued to make a decision on how relevant a new component might be. The Project Summary page generated by the Site plugin contains a Build Information section. This section identifies the GroupId, ArtifactId, Version, and Type. If it also published the DateTime at which a component was built then it solve the problem above. -- 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: (MAVENUPLOAD-2312) Please copy over hibernate-entitymanager 3.4.0GA from jboss repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Ferguson updated MAVENUPLOAD-2312: -- Attachment: hibernate-entitymanager-3.4.0.GA.pom There seems to be a problem with the POM for hibernate-entitymanager 3.4.0.GA at http://repository.jboss.org/maven2 The POM states that it has a packaging of type 'pom' when it should be 'jar'. Packaging of type pom means that only the POM is downloaded, not the jar file for the component. NB the last version of entitymanager with the correct packaging was 3.3.1.ga Maybe this is behind the reason behind this component not being copied over to Central. I've attached a good POM. It just has the packaging switched from POM to JAR. > Please copy over hibernate-entitymanager 3.4.0GA from jboss repo > > > Key: MAVENUPLOAD-2312 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2312 > Project: Maven Upload Requests > Issue Type: Bug >Reporter: Dan Tran >Assignee: Carlos Sanchez > Attachments: hibernate-entitymanager-3.4.0.GA.pom > > > the jboss repo is at > > http://repository.jboss.com/maven2/org/hibernate/hibernate-entitymanager/3.4.0.GA/ > This is needed to get hibernate3-maven-plugin to pickup the latest hibernate > artifact > Hope it is ok not ot provide the bundle -- 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: (MDEP-123) dependency:tree to optionally display all instances of a transitive dependency, not just the first one found
[
http://jira.codehaus.org/browse/MDEP-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Ferguson closed MDEP-123.
-
Resolution: Fixed
Fix Version/s: 2.0
It appears that an excellent solution for this was provide in 2.0-alpha-6.
Great stuff!
> dependency:tree to optionally display all instances of a transitive
> dependency, not just the first one found
>
>
> Key: MDEP-123
> URL: http://jira.codehaus.org/browse/MDEP-123
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
> Components: tree
>Affects Versions: 2.0
>Reporter: William Ferguson
>Assignee: Brian Fox
> Fix For: 2.0
>
> Attachments: pom.xml
>
>
> dependency:tree is *really* useful for tracking down how a particular
> transitive dependency has been introduced, but it only lists the first
> occurrence, not all occurrences. So it can be frustrating game attempting to
> remove a dep only to find it introduced by another component. A parameter to
> dependency:tree to show all occurences of a transitive dep would be *really*
> helpful.
> Eg the attached POM has a direct dep on commons-beanutils and
> commons-digester, which both have a dep on commons-logging. But executing
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-5-SNAPSHOT:tree
> {code}
> only shows commons-logging listed as a transitive dep for commons-beanutils,
> not commons-digester, Ie
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] | \- commons-logging:commons-logging:jar:1.0.3:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
> but if an exclusion is added to commons-beanutils for for commons-logging,
> then the other transitive dep instance is revealed. Ie
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-logging:commons-logging:jar:1.0:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
> An option to show both instance would be fantastic, Eg
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] | \- commons-logging:commons-logging:jar:1.0.3:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-logging:commons-logging:jar:1.0:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
--
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: (MCHANGES-78) Build a changes report by parsing svn comments
[ http://jira.codehaus.org/browse/MCHANGES-78?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121209 ] William Ferguson commented on MCHANGES-78: -- JIRA already has a plugin that integrates with SVN and its grammar is: - [JIRA_ID] Commit comments How does that match against the grammar(s) provided? > Build a changes report by parsing svn comments > -- > > Key: MCHANGES-78 > URL: http://jira.codehaus.org/browse/MCHANGES-78 > Project: Maven 2.x Changes Plugin > Issue Type: Improvement >Reporter: Emmanuel Hugonnet >Priority: Minor > Attachments: svn-changelog-plugin-jdk1.4.tar.gz, > svn-changelog-plugin.tar.gz, svnchangelog-plugin-jdk1.4.tar.gz > > > Builds a changes report by parsing svn comments. > You can configure this plugin as any reporting plugin. But it has specific > configuration parameters : > * grammar : this allows you to specify the grammar used to parse the svn > logs. > Currently it supports two grammars : > o "MANU" which uses @operation:issue; > o "REMY" with [operation:issue] > * trackerType : this allows you to specify the issue tracker used. > Currently it supports two trackers : > o codex > o jira > * trackerUrlPattern : this allows you to specify a pattern to link an > issue to any tracker. -- 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-123) dependency:tree to optionally display all instances of a transitive dependency, not just the first one found
dependency:tree to optionally display all instances of a transitive dependency,
not just the first one found
Key: MDEP-123
URL: http://jira.codehaus.org/browse/MDEP-123
Project: Maven 2.x Dependency Plugin
Issue Type: New Feature
Components: tree
Affects Versions: 2.0-alpha-5
Reporter: William Ferguson
Assignee: Brian Fox
Attachments: pom.xml
dependency:tree is *really* useful for tracking down how a particular
transitive dependency has been introduced, but it only lists the first
occurrence, not all occurrences. So it can be frustrating game attempting to
remove a dep only to find it introduced by another component. A parameter to
dependency:tree to show all occurences of a transitive dep would be *really*
helpful.
Eg the attached POM has a direct dep on commons-beanutils and commons-digester,
which both have a dep on commons-logging. But executing
{code}
mvn org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-5-SNAPSHOT:tree
{code}
only shows commons-logging listed as a transitive dep for commons-beanutils,
not commons-digester, Ie
{code}
[INFO] [dependency:tree]
[INFO]
maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
[INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
[INFO] | \- commons-logging:commons-logging:jar:1.0.3:compile
[INFO] \- commons-digester:commons-digester:jar:1.7:compile
[INFO]+- commons-collections:commons-collections:jar:2.1:compile
[INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
{code}
but if an exclusion is added to commons-beanutils for for commons-logging, then
the other transitive dep instance is revealed. Ie
{code}
[INFO] [dependency:tree]
[INFO]
maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
[INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
[INFO] \- commons-digester:commons-digester:jar:1.7:compile
[INFO]+- commons-logging:commons-logging:jar:1.0:compile
[INFO]+- commons-collections:commons-collections:jar:2.1:compile
[INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
{code}
An option to show both instance would be fantastic, Eg
{code}
[INFO] [dependency:tree]
[INFO]
maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
[INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
[INFO] | \- commons-logging:commons-logging:jar:1.0.3:compile
[INFO] \- commons-digester:commons-digester:jar:1.7:compile
[INFO]+- commons-logging:commons-logging:jar:1.0:compile
[INFO]+- commons-collections:commons-collections:jar:2.1:compile
[INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
{code}
--
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: (MDEP-123) dependency:tree to optionally display all instances of a transitive dependency, not just the first one found
[
http://jira.codehaus.org/browse/MDEP-123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Ferguson updated MDEP-123:
--
Attachment: pom.xml
> dependency:tree to optionally display all instances of a transitive
> dependency, not just the first one found
>
>
> Key: MDEP-123
> URL: http://jira.codehaus.org/browse/MDEP-123
> Project: Maven 2.x Dependency Plugin
> Issue Type: New Feature
> Components: tree
>Affects Versions: 2.0-alpha-5
>Reporter: William Ferguson
>Assignee: Brian Fox
> Attachments: pom.xml
>
>
> dependency:tree is *really* useful for tracking down how a particular
> transitive dependency has been introduced, but it only lists the first
> occurrence, not all occurrences. So it can be frustrating game attempting to
> remove a dep only to find it introduced by another component. A parameter to
> dependency:tree to show all occurences of a transitive dep would be *really*
> helpful.
> Eg the attached POM has a direct dep on commons-beanutils and
> commons-digester, which both have a dep on commons-logging. But executing
> {code}
> mvn org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-5-SNAPSHOT:tree
> {code}
> only shows commons-logging listed as a transitive dep for commons-beanutils,
> not commons-digester, Ie
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] | \- commons-logging:commons-logging:jar:1.0.3:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
> but if an exclusion is added to commons-beanutils for for commons-logging,
> then the other transitive dep instance is revealed. Ie
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-logging:commons-logging:jar:1.0:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
> An option to show both instance would be fantastic, Eg
> {code}
> [INFO] [dependency:tree]
> [INFO]
> maven-dependency-plugin-tree-all-deps:maven-dependency-plugin-tree-all-deps:jar:0.0.1
> [INFO] +- commons-beanutils:commons-beanutils:jar:1.7.0:compile
> [INFO] | \- commons-logging:commons-logging:jar:1.0.3:compile
> [INFO] \- commons-digester:commons-digester:jar:1.7:compile
> [INFO]+- commons-logging:commons-logging:jar:1.0:compile
> [INFO]+- commons-collections:commons-collections:jar:2.1:compile
> [INFO]\- xml-apis:xml-apis:jar:1.0.b2:compile
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> {code}
--
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-121) UnsupportedOperationException on depdendency:analyze
UnsupportedOperationException on depdendency:analyze
Key: MDEP-121
URL: http://jira.codehaus.org/browse/MDEP-121
Project: Maven 2.x Dependency Plugin
Issue Type: Bug
Components: analyze
Affects Versions: 2.0-alpha-5
Environment: maven-2.0.7
JDK 1.5.0_06
Windows XP
Reporter: William Ferguson
Assignee: Brian Fox
Executing:
{code}
mvn
org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-5-SNAPSHOT:analyze
{code}
on 3-DEC-2007 (ie 2.0-alpha-5-20070703.005757) produced:
{code}
[INFO] snapshot org.codehaus.plexus:plexus-archiver:1.0-alpha-9-SNAPSHOT:
checking for updates from snapshot
[INFO] snapshot
org.apache.maven.shared:maven-dependency-analyzer:1.0-alpha-3-SNAPSHOT:
checking for updates from snapshot
[INFO] [dependency:analyze]
[INFO] Used undeclared dependencies:
[WARNING]commons-logging:commons-logging:jar:1.0:compile
[INFO] Unused declared dependencies:
[INFO]
[ERROR] FATAL ERROR
[INFO]
[INFO] null
[INFO]
[INFO] Trace
java.lang.UnsupportedOperationException
at
java.util.Collections$UnmodifiableCollection$1.remove(Collections.java:1012)
at
org.apache.maven.plugin.dependency.AnalyzeMojo.checkDependencies(AnalyzeMojo.java:213)
at
org.apache.maven.plugin.dependency.AnalyzeMojo.execute(AnalyzeMojo.java:162)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
[INFO] Total time: 58 seconds
[INFO] Finished at: Mon Dec 03 12:33:25 EST 2007
[INFO] Final Memory: 14M/28M
[INFO]
{code}
NB I was using the snapshot because I had just run dependency:tree
Executing
{code}
mvn org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4:analyze
{code}
does not cause the UnsupportedOperationException to occur.
But the error doesn't occur in the trunk, so maybe time to release a new
snapshot or even a new 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] Created: (MSITE-272) Too much irrelevant information generated at INFOduring execution of Site goal
Too much irrelevant information generated at INFOduring execution of Site goal
--
Key: MSITE-272
URL: http://jira.codehaus.org/browse/MSITE-272
Project: Maven 2.x Site Plugin
Issue Type: Improvement
Affects Versions: 2.0-beta-5, 2.0-beta-6
Reporter: William Ferguson
Executing 'mvn site:site' generates a lot of noise, much of it internal
Velocity engine debug which is output at INFO level in the plugin.
Example (taken from the staging of 2.0-beta-6):
{code}
D:\Modules\hubbub-log4j>mvn site
[INFO] Scanning for projects...
[INFO]
[INFO] Building hubbub-log4j
[INFO]task-segment: [site]
[INFO]
[INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for
updates from maven-staging
[INFO] artifact org.apache.maven.plugins:maven-site-plugin: checking for
updates from central
Downloading:
http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-site-plugin/2.0-beta-6/maven-site-plugin-2.0-beta-6.pom
Downloading:
http://people.apache.org/~dennisl/staging-repository-site-plugin//org/apache/maven/plugins/maven-site-plugin/2.0-beta-6/maven-site-plugin-2.0
-beta-6.jar
118K downloaded
[INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] **
[INFO] Starting Jakarta Velocity v1.4
[INFO] RuntimeInstance initializing.
[INFO] Default Properties File:
org\apache\velocity\runtime\defaults\velocity.properties
[INFO] Default ResourceManager initializing. (class
org.apache.velocity.runtime.resource.ResourceManagerImpl)
[INFO] Resource Loader Instantiated:
org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
[INFO] ClasspathResourceLoader : initialization starting.
[INFO] ClasspathResourceLoader : initialization complete.
[INFO] ResourceCache : initialized. (class
org.apache.velocity.runtime.resource.ResourceCacheImpl)
[INFO] Default ResourceManager initialization complete.
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Include
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Foreach
[INFO] Created: 20 parsers.
[INFO] Velocimacro : initialization starting.
[INFO] Velocimacro : adding VMs from VM library template : VM_global_library.vm
[ERROR] ResourceManager : unable to find resource 'VM_global_library.vm' in any
resource loader.
[INFO] Velocimacro : error using VM library template VM_global_library.vm :
org.apache.velocity.exception.ResourceNotFoundException: Unable to find resou
rce 'VM_global_library.vm'
[INFO] Velocimacro : VM library template macro registration complete.
[INFO] Velocimacro : allowInline = true : VMs can be defined inline in templates
[INFO] Velocimacro : allowInlineToOverride = false : VMs defined inline may NOT
replace previous VM definitions
[INFO] Velocimacro : allowInlineLocal = false : VMs defined inline will be
global in scope if allowed.
[INFO] Velocimacro : initialization complete.
[INFO] Velocity successfully started.
[INFO] Setting property: classpath.resource.loader.class =>
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.
[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] **
[INFO] Starting Jakarta Velocity v1.4
[INFO] RuntimeInstance initializing.
[INFO] Default Properties File:
org\apache\velocity\runtime\defaults\velocity.properties
[INFO] Default ResourceManager initializing. (class
org.apache.velocity.runtime.resource.ResourceManagerImpl)
[INFO] Resource Loader Instantiated:
org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader
[INFO] ClasspathResourceLoader : initialization starting.
[INFO] ClasspathResourceLoader : initialization complete.
[INFO] ResourceCache : initialized. (class
org.apache.velocity.runtime.resource.ResourceCacheImpl)
[INFO] Default ResourceManager initialization complete.
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Literal
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Macro
[INFO] Loaded System Directive: org.apache.velocity.runtime.directive.Parse
[INFO] Loaded Sy
[jira] Commented: (MSITE-255) Executing the site-site goal fails prior to executing the site-deploy goal on a clean maven install (Could be due to dependencies)
[
http://jira.codehaus.org/browse/MSITE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_114274
]
William Ferguson commented on MSITE-255:
Forgot to mention, the above failure can be seen when executing the following
commands on the attached project.
{code}
mvn clean site
{code}
or
{code}
mvn clean
mvn site
{code}
> Executing the site-site goal fails prior to executing the site-deploy goal on
> a clean maven install (Could be due to dependencies)
> --
>
> Key: MSITE-255
> URL: http://jira.codehaus.org/browse/MSITE-255
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
> Environment: Windows XP, Java 1.5, Intel Pentium 4
>Reporter: Sahand
> Attachments: dev-200.zip
>
>
> When running {{mvn site:site}} from a clean maven install I get FATAL ERROR
> caused by a NullPointerException. (*Trace log below*)
> This was resolved by running {{mvn site:deploy}} which seemed to retrieve a
> series of dependent libraries. After which, running {{mvn site:site}} would
> execute successfully.
> I will test it again when I get the time to narrow down the dependency that
> is required for execution and is not being retrieved.
> {quote}
> [ERROR] FATAL ERROR
> [INFO]
> -
> ---
> [INFO] null
> [INFO]
> -
> ---
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.doxia.module.fml.FmlParser.createSink(FmlParser.java
> :270)
> at
> org.apache.maven.doxia.module.fml.FmlParser.parse(FmlParser.java:61)
> at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:52)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocumen
> t(DefaultSiteRenderer.java:264)
> at
> org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocum
> ent(DoxiaDocumentRenderer.java:43)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(
> DefaultSiteRenderer.java:239)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(Defaul
> tSiteRenderer.java:115)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124
> )
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi
> nManager.java:443)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa
> ultLifecycleExecutor.java:539)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLi
> fecycle(DefaultLifecycleExecutor.java:480)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau
> ltLifecycleExecutor.java:459)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan
> dleFailures(DefaultLifecycleExecutor.java:311)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen
> ts(DefaultLifecycleExecutor.java:278)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi
> fecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.
> java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces
> sorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> 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)
> [INFO]
> -
> ---
> [INFO] Total time: 26 seconds
> [INFO] Finished at: Wed Aug 29 12:49:50 EST 2007
> [INFO] Final Memory: 25M/44M
> [INFO]
> -
> {quote}
--
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-255) Executing the site-site goal fails prior to executing the site-deploy goal on a clean maven install (Could be due to dependencies)
[
http://jira.codehaus.org/browse/MSITE-255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Ferguson updated MSITE-255:
---
Attachment: dev-200.zip
Dennis, its caused by the faq.fml not having any faq elements within the part
element, which causes the Part class in doxia-1.0-alpha-8 to be incompletely
formed.
We typically have such an entry for new projects for which there are no FAQ
entries yet. Eg
{code}
{code}
It manifests like so:
{code}
[INFO] Trace
java.lang.NullPointerException
at
org.apache.maven.doxia.module.fml.FmlParser.createSink(FmlParser.java:270)
at org.apache.maven.doxia.module.fml.FmlParser.parse(FmlParser.java:61)
at org.apache.maven.doxia.DefaultDoxia.parse(DefaultDoxia.java:52)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderDocument(DefaultSiteRenderer.java:264)
at
org.apache.maven.doxia.siterenderer.DoxiaDocumentRenderer.renderDocument(DoxiaDocumentRenderer.java:43)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:239)
at
org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:115)
at
org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:124)
at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92)
at
org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:480)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:459)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
at
org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:280)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
[INFO]
{code}
This was fixed in doxia-1.0-alpha-10 (which is used by the
maven-site-plugin-2.0-beta-6-SNAPSHOT) and I have verified that the site gets
successfully generated with it.
So you can mark it as fixed for 2.0-beta-6.
Must be almost time for a release?
> Executing the site-site goal fails prior to executing the site-deploy goal on
> a clean maven install (Could be due to dependencies)
> --
>
> Key: MSITE-255
> URL: http://jira.codehaus.org/browse/MSITE-255
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-5
> Environment: Windows XP, Java 1.5, Intel Pentium 4
>Reporter: Sahand
> Attachments: dev-200.zip
>
>
> When running {{mvn site:site}} from a clean maven install I get FATAL ERROR
> caused by a NullPointerException. (*Trace log below*)
> This was resolved by running {{mvn site:deploy}} which seemed to retrieve a
> series of dependent libraries. After which, running {{mvn site:site}} would
> execute successfully.
> I will test it again when I get the time to narrow down the dependency that
> is required for execution and is not being retrieved.
> {quote}
> [ERROR] FATAL ERROR
> [INFO]
> -
> ---
> [INFO] null
> [INFO]
> -
> ---
> [INFO] Trace
> java.lang.NullPointerException
> at
> org.apache.maven.doxia.module.fml.FmlParser.createSink(FmlParser.java
> :270)
> at
> org.apache.maven.doxia.module.fml.FmlParser.parse(FmlParser.java:61)
> at org.apache.maven.doxia.DefaultDoxia.parse(Default
[jira] Commented: (MRELEASE-280) AIOBE on release:perform
[ http://jira.codehaus.org/browse/MRELEASE-280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113615 ] William Ferguson commented on MRELEASE-280: --- According to the stacktrace you are getting this on release:prepare not release:perform. Looking at the code, I would hazard a guess that the distributionManagement element in your POM either - does not list patsh to the trunk of your code - Does not have anything in common with the tagBase specified for your maven-release-plugin config. Hope this helps. I don't think this is a bug, but a better error message would be useful. > AIOBE on release:perform > > > Key: MRELEASE-280 > URL: http://jira.codehaus.org/browse/MRELEASE-280 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: Milos Kleint > > got this on current nbm-maven-plugin source at mojo.codehaus.org when doinga > release. > java.lang.ArrayIndexOutOfBoundsException: 42 > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateUrlPath(RewritePomsForReleasePhase.java:249) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.translateScm(RewritePomsForReleasePhase.java:124) > at > org.apache.maven.shared.release.phase.RewritePomsForReleasePhase.transformScm(RewritePomsForReleasePhase.java:79) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformDocument(AbstractRewritePomsPhase.java:271) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transformProject(AbstractRewritePomsPhase.java:180) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.transform(AbstractRewritePomsPhase.java:116) > at > org.apache.maven.shared.release.phase.AbstractRewritePomsPhase.execute(AbstractRewritePomsPhase.java:99) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:131) > at > org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:94) > at > org.apache.maven.plugins.release.PrepareReleaseMojo.execute(PrepareReleaseMojo.java:127) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:443) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:224) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:280) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) -- 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-3244) inherited site url not properly handling parameters
[
http://jira.codehaus.org/browse/MNG-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_113267
]
William Ferguson commented on MNG-3244:
---
Brian, we all seem to want this fix, but don't want to break existing behaviour
(however bizarre it may be).
The proper solution seems to be to add a POM attribute/element like either:
- use-inherited-urls with a default of false
- append-artifactId-to-parent-urls with a default of true
But this requires a change to the POM schema which I suspect will be much
harder to organise..
A temporary solution might be to do the same thing using well-documented POM
properties, eg
- mng-3244-use-inherited-urls with a default of false
- mng-3244-append-artifactId-to-parent-urls with a default of true
And when (hopefully not if) the POM schema is changed to accomodate the proper
solution the implementation can be readily switched from one to the other and
even handle fallback and notification of the appropriate configuration.
> inherited site url not properly handling parameters
> ---
>
> Key: MNG-3244
> URL: http://jira.codehaus.org/browse/MNG-3244
> Project: Maven 2
> Issue Type: Bug
> Components: Inheritance and Interpolation, Sites & Reporting
>Affects Versions: 2.0.7
>Reporter: Jacob Robertson
>Assignee: Brian Fox
> Fix For: 2.0.8
>
> Attachments: fix-inherited-site-url.patch
>
>
> Here is the test case to reroduce this problem. Take the following two
> pom.xml files
>
>
> org.bar
> foo
> foo
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
>
> foo-site
> file://C:/Documents and
> Settings/foo/.m2/site/${project.artifactId}
>
>
>
>
>
> org.bar
> baz
> baz
> 1.0-SNAPSHOT
> pom
> 4.0.0
>
> foo
> org.bar
> 1.0-SNAPSHOT
>
>
> And run the site-deploy goal on each. What you get under the site directory
> is this
> - site
> /- foo
> ---/site docs
> /- baz
> ---/- baz (extra directory)
> --- ---/site docs
> This is the simplest test case. In the case where I have a "grandparent"
> pom, the site directory uses the grandparent/parent as the path to the site,
> and doesn't use the actual artifactId of the artifact I'm creating the site
> for.
--
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-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110709
]
William Ferguson commented on MNG-2290:
---
Joerg, I'm satisfied that all my concerns raised with this issue have been
resolved by http://jira.codehaus.org/browse/MNG-3244.
Did you still want to keep it open?
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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: (MRESOURCES-47) POM properties cannot be accessed within a filter file
[
http://jira.codehaus.org/browse/MRESOURCES-47?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110137
]
William Ferguson commented on MRESOURCES-47:
Thanks Mauro, 2.3-20071013.152223-3 is good.
> POM properties cannot be accessed within a filter file
> --
>
> Key: MRESOURCES-47
> URL: http://jira.codehaus.org/browse/MRESOURCES-47
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: William Ferguson
>Assignee: Mauro Talevi
> Fix For: 2.3
>
> Attachments: MRESOURCES-47-maven-resources-plugin.patch, project.zip
>
>
> Before applying a filter, the maven-resources-plugin evaluates
> 1) POM structural elements such as ${project.version}
> 2) System properties such as ${my.system.property}
> that are referred to within *filter* files.
> However, it does *not* evaluate any POM (or profile) property such as
> ${my.pom.property} at the same time.
> Consequently it is not possible to define filter tokens that use POM
> properties.
> Without this patch we would either need to have many more POM properties or
> would have lots of fine grained and typically non-intuitive tokens
> distributed amongst our resources.
> IMHO this patch will bring the resolution mechanism for filter files in line
> with property resolution mechanism in general.
> I have attached a zipped project containing :
> SomeResource.txt
> my.filter
> Look at SomeResource.txt after being processed with filtering. Note the
> unresolved tokens for ${projectProperty} and ${profileProperty} for the
> "filter resolution" cases. Ie the POM property values of the filter tokens
> were never evaluated.
--
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: (MJAR-83) addClasspath is not respected for runtime dependencies
[
http://jira.codehaus.org/browse/MJAR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_110124
]
William Ferguson commented on MJAR-83:
--
Thanks Mauro, the maven-jar-plugin-2.2-20071013.140436-2 snapshot works like
dream.
> addClasspath is not respected for runtime dependencies
> --
>
> Key: MJAR-83
> URL: http://jira.codehaus.org/browse/MJAR-83
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1, 2.2
>Reporter: William Ferguson
>Assignee: Mauro Talevi
> Fix For: 2.2
>
> Attachments: patch.txt, pom.xml
>
>
> maven-jar-plugin does not resolve dependencies itself, so specifying
> {code}
>
>
>
> true
>
>
>
> {code}
> will add no dependencies for
> {noformat}
> mvn jar:jar
> {noformat}
> And even
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> will only add compile time dependencies, not runtime dependencies, presumably
> because the maven-compiler-plugin causes resolution of the compile time
> dependencies.
> See the attached POM.
> There is *no* manifest classpath generated by
> {noformat}
> mvn jar:jar
> {noformat}
> The manifest classpath generated by
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> only contains commons-codec which is the compile time dependency.
> There needs to be a way to add runtime dependences to the manifest classpath
> of the jar.
> And preferably not requiring some other plugin to resolve the dependencies
> first.
--
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: (MRM-545) Documentation for configuring for Tomcat is invalid
Documentation for configuring for Tomcat is invalid
---
Key: MRM-545
URL: http://jira.codehaus.org/browse/MRM-545
Project: Archiva
Issue Type: Bug
Components: documentation
Affects Versions: 1.0-beta-2
Environment: Windows XP, Tomcat-5.5.17/Tomcat-5.5.20, JDK-1.5.0_06
Reporter: William Ferguson
Priority: Critical
Attachments: bad-log-filename.log, mail-auth-class-not-found.log
Following http://maven.apache.org/archiva/guides/getting-started.html for
Tomcat didn't get me started.
I'll go through it point by point
# Create a directory in tomcat called archiva, at the same level as bin, conf,
logs and the others.
# Copy the war file from apps/archiva/lib into the new directory
There is not apps/archiva/lib in the 1.0-beta-2 distribution.
apps contains a single file : archiva-plexus-application-1.0-beta-2.jar which
does itself contain a war file, so I extracted that file and copied it to the
TOMCAT_HOME/archiva folder.
NB IMHO modifying TOMCAT in this manner smells all wrong.
# Create a conf/Catalina/localhost/archiva.xml file with the following data:
yadda, yadda
The docBase attribute refers to archiva-webapp-1.0-SNAPSHOT.war instead of
archiva-webapp-1.0-beta-2.war
No idea why a javax.mail.Session needs to be configured here, haven't seen any
documentation in Archiva that suggests it send, receives email. But this was a
slight pain when configuring for Tomcat-5.5.20 as I needed to follow the extra
steps for the missing classes. If the MailSession is not required it would be
better to avoid this pain by simplifying the config.
Again modifying TOMCAT like this does not feel right. Surely this config could
be contained within the webapp.
# Copy $HOME/.m2/org/apache/derby/derby/10.1.3.1/derby-10.1.3.1.jar (or from
the remote repository) into the Tomcat common/lib
I am *really* against this as I have now introduced Derby-10.1.3.1 into the
classpath of 8all* my other applications running on that Tomcat instance.
Surely this library could be packaged up into the webapp.
# To deal with a current bug, you'll also need to add the following to your
$catalina.home/conf/web.xml in the relevant section (search for jspx):
Again, surely this could be included in the config for the Archiva webapp
instead of introduced into Tomcat generally. This heavy handed approach makes
maintenance difficult, eg upgrading to a new version of Tomcat is now extremely
onerous.
OK, so having followed the instructions above, when I try to startup Tomcat
the first thin I get is a failure with the logging sub system. see attached
bad-log-filename.log. I believe this is due to the fact that ${appserver.base}
in log4j.xml has never been set:
{code}
{code}
Next, it fails as it can't find javax.mail.Authenticator (this is
Tomcat-5.5.17).
NB I never saw any indication that "schema SA does not exist" as the final note
suggests. But perhaps this was because Archiva never got that far. Certainly no
application is available at http://localhost:8080/archiva/
Anyway, by this stage I became discouraged enough that I gave up.
Its a shame really as I would have liked to be able to compare Archiva against
Proximity and Artifactory, both of which I managed to get setup in under 10
mins including vastly restructuring the default repository config that they
ship with.
Brett, hope that helps.
Further notes:
I really don't like modifying the contents of TOMCAT_HOME other than to deploy
a WAR to TOMCAT_HOME/webapps.
And the infrastructure team weren't impressed either and its makes maintenance
high cost.
Better to keep all config solely within the confines of the webapp or use a
environment variable to declare a separate proxy_home where all the config is
contained (like Artifactory does).
--
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-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109252
]
William Ferguson commented on MNG-2290:
---
Joerg,
I've come to the conclusion that while this is definitely an issue that should
be resolved, we are going to deal with it by always exlicitly declaring url and
site#url properties in our POMs to avoid the aberrant childPathAdjustment
mechanism. And I don't believe that anyone else rates it highly enough to be
bothered about fixing it.
So if you still want to close it, no argument from me.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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: (MRELEASE-211) set version in batch mode
[
http://jira.codehaus.org/browse/MRELEASE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107800
]
William Ferguson commented on MRELEASE-211:
---
Um, correct me if I'm wrong, but isn't this what the *useReleaseProfile*
parameter on release:perform it there for?
Ie
{code}
maven-release-plugin
false
{code}
will give you exactly what you want.
> set version in batch mode
> -
>
> Key: MRELEASE-211
> URL: http://jira.codehaus.org/browse/MRELEASE-211
> Project: Maven 2.x Release Plugin
> Issue Type: New Feature
>Affects Versions: 2.0-beta-5
> Environment: win XP pro SP2, maven 2.0.5, maven release plugin
> 2.0-beta-5
>Reporter: Andrew Chikvaidze
>
> I think a lot of developer teams often don't need generate javadoc for their
> project every time when running release:perform.
> I think it's very useful to add an option to disable javadoc creation.
> When I tried to pass to maven "-DperformRelease=false" this haven't effect.
> Later I saw in function
> private void perform( ReleaseDescriptor releaseDescriptor, Settings
> settings, List reactorProjects,
> File checkoutDirectory, String goals, boolean
> useReleaseProfile,
> ReleaseManagerListener listener, ReleaseResult
> result )
> the code:
> if ( useReleaseProfile )
> {
> if ( !StringUtils.isEmpty( additionalArguments ) )
> {
> /*
> evil hack (we don't need javadoc)
> additionalArguments = additionalArguments + "
> -DperformRelease=true";
> */
> additionalArguments = additionalArguments + "
> -DperformRelease=false";
> }
> else
> {
> /*
> evil hack (we don't need javadoc)
> additionalArguments = "-DperformRelease=true";
> */
> additionalArguments = "-DperformRelease=false";
> }
> }
> so, unfortunately now I cannot set -DperformRelease=false..
--
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: (MRELEASE-270) release:prepare doesn't fail when the project it is building fails to compile
[ http://jira.codehaus.org/browse/MRELEASE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107334 ] William Ferguson commented on MRELEASE-270: --- I have validated that the fix for http://jira.codehaus.org/browse/MNG-3084 in 2.0.8 resolves this issue. So could someone please close this issue as fixed in Maven 2.0.8 > release:prepare doesn't fail when the project it is building fails to compile > - > > Key: MRELEASE-270 > URL: http://jira.codehaus.org/browse/MRELEASE-270 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson > Attachments: MRELEASE-XXX.zip > > > Unusual situation on our build server, where one of the dependent libraries > had been corrupted in its local repository. > 'mvn compile' would fail with compilation errors - it couldn't find the > classes from the corrupt jar. > 'mvn release:prepare' would note compilation errors and indicate build > failure, but would continue on with the release, modify the POMs, tag the > source and finally complete indicating success. > I noted that the same thing can happen if uncompilable source is checked in, > though at least then you would get the compilation failure on your local > machine too. > I think release:prepare should clearly fail (it wasn't clear in this instance > unless you scrolled back through the build output) if any part of the > release:prepare fails. > To replicate either > a) Attempt top release uncompilable code. > b) Replace a dependent jar with a renamed text file and attempt to 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] Issue Comment Edited: (MNG-3099) Profiles ignored when working with non-projects (such as archetype:create)
[
http://jira.codehaus.org/browse/MNG-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107214
]
William Ferguson edited comment on MNG-3099 at 9/13/07 12:57 AM:
-
Invoking a Mojo that doesn't require a project (ie [EMAIL PROTECTED] false* in
your Mojo) doesn't load the Profiles defined in LOCAL_HOME settings or
MAVEN_HOME settings.
In an effort to make this issue as explicit as possible, I have attached
Plugin-showing-MNG3099.zip
It contains a plugin project (with a Mojo conigured with [EMAIL PROTECTED]
false*) and local and global settings files.
Put the local and global settings files in the normal place and build and
install the plugin.
Then from the plugin project folder execute:
{quote}
D:\Modules\maven-test-plugin>mvn
com.yarris.maven.plugins:maven-test-plugin:profile-props
[INFO] Scanning for projects...
[INFO] snapshot com.yarris.maven.plugins:maven-test-plugin:1.0-SNAPSHOT:
checking for updates from snapshot
[INFO]
[INFO] Building maven-test-plugin
[INFO]task-segment:
[com.yarris.maven.plugins:maven-test-plugin:profile-props] (aggregator-style)
[INFO]
[INFO] [test:profile-props]
[INFO] local-profile-prop=local-profile-prop-value
[INFO] global-profile-prop=global-profile-prop-value
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Thu Sep 13 15:47:18 EST 2007
[INFO] Final Memory: 2M/4M
[INFO]
{quote}
Note that the local-profile-prop and global-profile-prop have resolved to the
expected values.
Now execute:
{quote}
D:\Modules\maven-test-plugin>mvn
com.yarris.maven.plugins:maven-test-plugin:profile-props -f no-pom.xml
[INFO] Scanning for projects...
[INFO]
[INFO] Building Maven Default Project
[INFO]task-segment:
[com.yarris.maven.plugins:maven-test-plugin:profile-props] (aggregator-style)
[INFO]
[INFO] [test:profile-props]
[INFO] local-profile-prop=null
[INFO] global-profile-prop=null
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Thu Sep 13 15:48:56 EST 2007
[INFO] Final Memory: 2M/4M
[INFO]
{quote}
Note how local-profile-prop and global-profile-prop no longer have values.
As has been noted the most common example of this is archetype:create which
requires the remote repository to be explicitly provided on the command line
via the remoteRepositories System property if you are pulling an archetype from
somewhere other than central. Eg
{code}
mvn archetype:create -DgroupId=com.yarris -DartifactId=foo-project
-DarchetypeGroupId=com.yarris.maven.archetype \
-DarchetypeArtifactId=archetype-standard
-DremoteRepositories=http://somewhere.com.au:8080/proximity/repository/release
{code}
It should be possible to define an active Profile in either local or global
settings.xml that defines a remote repository, and have the archetype pulled
from that repository.
It should also be possible to refer to a property provided by an active Profile
But it occurs for any Mojo that does not require a project.
was:
Invoking a Mojo that doesn't require a project (ie [EMAIL PROTECTED] false* in
your Mojo) doesn't load the Profiles defined in LOCAL_HOME settings or
MAVEN_HOME settings.
In an effort to make this issue as explicit as possible, I have attached
Plugin-showing-MNG3099.zip
It contains a plugin project (with a Mojo conigured with *requiresProject
false*) and local and global settings files.
Put the local and global settings files in the normal place and build and
install the plugin.
Then from the plugin project folder execute:
{code}
D:\Modules\maven-test-plugin>mvn
com.yarris.maven.plugins:maven-test-plugin:profile-props
[INFO] Scanning for projects...
[INFO] snapshot com.yarris.maven.plugins:maven-test-plugin:1.0-SNAPSHOT:
checking for updates from snapshot
[INFO]
[INFO] Building maven-test-plugin
[INFO]task-segment:
[com.yarris.maven.plugins:maven-test-plugin:profile-props] (aggregator-style)
[INFO]
[INFO] [test:profile-props]
[INFO] local-profile-prop=local-profile-prop-value
[INFO] globa
[jira] Updated: (MNG-3099) Profiles ignored when working with non-projects (such as archetype:create)
[
http://jira.codehaus.org/browse/MNG-3099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Ferguson updated MNG-3099:
--
Attachment: Plugin-showing-MNG3099.zip
Invoking a Mojo that doesn't require a project (ie [EMAIL PROTECTED] false* in
your Mojo) doesn't load the Profiles defined in LOCAL_HOME settings or
MAVEN_HOME settings.
In an effort to make this issue as explicit as possible, I have attached
Plugin-showing-MNG3099.zip
It contains a plugin project (with a Mojo conigured with *requiresProject
false*) and local and global settings files.
Put the local and global settings files in the normal place and build and
install the plugin.
Then from the plugin project folder execute:
{code}
D:\Modules\maven-test-plugin>mvn
com.yarris.maven.plugins:maven-test-plugin:profile-props
[INFO] Scanning for projects...
[INFO] snapshot com.yarris.maven.plugins:maven-test-plugin:1.0-SNAPSHOT:
checking for updates from snapshot
[INFO]
[INFO] Building maven-test-plugin
[INFO]task-segment:
[com.yarris.maven.plugins:maven-test-plugin:profile-props] (aggregator-style)
[INFO]
[INFO] [test:profile-props]
[INFO] local-profile-prop=local-profile-prop-value
[INFO] global-profile-prop=global-profile-prop-value
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Thu Sep 13 15:47:18 EST 2007
[INFO] Final Memory: 2M/4M
[INFO]
{code}
Note that the local-profile-prop and global-profile-prop have resolved to the
expected values.
Now execute:
{code}
D:\Modules\maven-test-plugin>mvn
com.yarris.maven.plugins:maven-test-plugin:profile-props -f no-pom.xml
[INFO] Scanning for projects...
[INFO]
[INFO] Building Maven Default Project
[INFO]task-segment:
[com.yarris.maven.plugins:maven-test-plugin:profile-props] (aggregator-style)
[INFO]
[INFO] [test:profile-props]
[INFO] local-profile-prop=null
[INFO] global-profile-prop=null
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
[INFO] Total time: 1 second
[INFO] Finished at: Thu Sep 13 15:48:56 EST 2007
[INFO] Final Memory: 2M/4M
[INFO]
{code}
Note how local-profile-prop and global-profile-prop no longer have values.
As has been noted the most common example of this is archetype:create which
requires the remote repository to be explicitly provided on the command line
via the remoteRepositories System property if you are pulling an archetype from
somewhere other than central. Eg
{code}
mvn archetype:create -DgroupId=com.yarris -DartifactId=foo-project
-DarchetypeGroupId=com.yarris.maven.archetype \
-DarchetypeArtifactId=archetype-standard
-DremoteRepositories=http://somewhere.com.au:8080/proximity/repository/release
{code}
It should be possible to define an active Profile in either local or global
settings.xml that defines a remote repository, and have the archetype pulled
from that repository.
It should also be possible to refer to a property provided by an active Profile
But it occurs for any Mojo that does not require a project.
> Profiles ignored when working with non-projects (such as archetype:create)
> --
>
> Key: MNG-3099
> URL: http://jira.codehaus.org/browse/MNG-3099
> Project: Maven 2
> Issue Type: Bug
>Reporter: Joakim Erdfelt
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.1
>
> Attachments: MNG-2261-2.patch, MNG-2261.patch,
> Plugin-showing-MNG3099.zip
>
>
> Several conditions have to be met to show this bug.
> 1) Be in an environment that does not have access to repo1.maven.org, (such
> as a corporate environment)
> 2) Have no content in your local repository (a fresh install of maven 2.0.4)
> 3) Attempt to use a plugin that has no project requirement (such as
> archetype:create)
> The plugin fails because access to repo1.maven.org cannot be accessed.
> Recommended solution:
> Create a settings.xml profile that changes the location of the 'central'
> repository to point to an internal resource (such as a maven-proxy
> installation).
>
>
>
> use_internal
>
>
> central
> Internal
[jira] Updated: (MJAR-83) addClasspath is not respected for runtime dependencies
[
http://jira.codehaus.org/browse/MJAR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Ferguson updated MJAR-83:
-
Attachment: patch.txt
The patch adds @requiresDependencyResolution tags of *runtime* to
* JarMojo
* JarSignMojo
* JarSignVerifyMojo
And a @requiresDependencyResolution tag of *test* to
* TestJarMojo
I tried to put together a test case, but the existing test cases were not
particualrly helpful as a starting point. To test you need to ensure that with
the dependency list shown below, only commons-code and commons-io appear in
the manifest classpath for jar:jar etc.
{code}
commons-codec
commons-codec
compile
1.3
commons-io
commons-io
runtime
1.2
commons-lang
commons-lang
provided
2.1
commons-logging
commons-logging
test
1.0.4
{code}
> addClasspath is not respected for runtime dependencies
> --
>
> Key: MJAR-83
> URL: http://jira.codehaus.org/browse/MJAR-83
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1, 2.2
>Reporter: William Ferguson
> Attachments: patch.txt, pom.xml
>
>
> maven-jar-plugin does not resolve dependencies itself, so specifying
> {code}
>
>
>
> true
>
>
>
> {code}
> will add no dependencies for
> {noformat}
> mvn jar:jar
> {noformat}
> And even
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> will only add compile time dependencies, not runtime dependencies, presumably
> because the maven-compiler-plugin causes resolution of the compile time
> dependencies.
> See the attached POM.
> There is *no* manifest classpath generated by
> {noformat}
> mvn jar:jar
> {noformat}
> The manifest classpath generated by
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> only contains commons-codec which is the compile time dependency.
> There needs to be a way to add runtime dependences to the manifest classpath
> of the jar.
> And preferably not requiring some other plugin to resolve the dependencies
> first.
--
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] Issue Comment Edited: (MJAR-83) addClasspath is not respected for runtime dependencies
[
http://jira.codehaus.org/browse/MJAR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106350
]
William Ferguson edited comment on MJAR-83 at 9/3/07 10:29 PM:
---
The patch adds @requiresDependencyResolution tags of *runtime* to
* JarMojo
* JarSignMojo
* JarSignVerifyMojo
And a @requiresDependencyResolution tag of *test* to
* TestJarMojo
I tried to put together a test case, but the existing test cases were not
particualrly helpful as a starting point. To test you need to ensure that with
the dependency list shown below, only commons-code and commons-io appear in
the manifest classpath for jar:jar etc.
{code}
commons-codec
commons-codec
compile
1.3
commons-io
commons-io
runtime
1.2
commons-lang
commons-lang
provided
2.1
commons-logging
commons-logging
test
1.0.4
{code}
was:
The patch adds @requiresDependencyResolution tags of *runtime* to
* JarMojo
* JarSignMojo
* JarSignVerifyMojo
And a @requiresDependencyResolution tag of *test* to
* TestJarMojo
I tried to put together a test case, but the existing test cases were not
particualrly helpful as a starting point. To test you need to ensure that with
the dependency list shown below, only commons-code and commons-io appear in
the manifest classpath for jar:jar etc.
{code}
commons-codec
commons-codec
compile
1.3
commons-io
commons-io
runtime
1.2
commons-lang
commons-lang
provided
2.1
commons-logging
commons-logging
test
1.0.4
{code}
> addClasspath is not respected for runtime dependencies
> --
>
> Key: MJAR-83
> URL: http://jira.codehaus.org/browse/MJAR-83
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1, 2.2
>Reporter: William Ferguson
> Attachments: patch.txt, pom.xml
>
>
> maven-jar-plugin does not resolve dependencies itself, so specifying
> {code}
>
>
>
> true
>
>
>
> {code}
> will add no dependencies for
> {noformat}
> mvn jar:jar
> {noformat}
> And even
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> will only add compile time dependencies, not runtime dependencies, presumably
> because the maven-compiler-plugin causes resolution of the compile time
> dependencies.
> See the attached POM.
> There is *no* manifest classpath generated by
> {noformat}
> mvn jar:jar
> {noformat}
> The manifest classpath generated by
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> only contains commons-codec which is the compile time dependency.
> There needs to be a way to add runtime dependences to the manifest classpath
> of the jar.
> And preferably not requiring some other plugin to resolve the dependencies
> first.
--
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: (MJAR-83) addClasspath is not respected for runtime dependencies
[
http://jira.codehaus.org/browse/MJAR-83?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_106345
]
William Ferguson commented on MJAR-83:
--
The workaround for this is to
* List all deps with a scope of compile
* Execute *mvn* *compiler:compile* *jar:jar*
Neither of is nice and both of which is required.
NB I forgot to say why we need to create a Jar with no content other than a
manifest classpath.
Its because the Windows line length limit precludes classpaths that are too
long, so we generate a Jar with a manifest classpath that includes all the
target libraries and just include it.
But its seems like a problem in the general sense in any case.
> addClasspath is not respected for runtime dependencies
> --
>
> Key: MJAR-83
> URL: http://jira.codehaus.org/browse/MJAR-83
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1, 2.2
>Reporter: William Ferguson
> Attachments: pom.xml
>
>
> maven-jar-plugin does not resolve dependencies itself, so specifying
> {code}
>
>
>
> true
>
>
>
> {code}
> will add no dependencies for
> {noformat}
> mvn jar:jar
> {noformat}
> And even
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> will only add compile time dependencies, not runtime dependencies, presumably
> because the maven-compiler-plugin causes resolution of the compile time
> dependencies.
> See the attached POM.
> There is *no* manifest classpath generated by
> {noformat}
> mvn jar:jar
> {noformat}
> The manifest classpath generated by
> {noformat}
> mvn compiler:compile jar:jar
> {noformat}
> only contains commons-codec which is the compile time dependency.
> There needs to be a way to add runtime dependences to the manifest classpath
> of the jar.
> And preferably not requiring some other plugin to resolve the dependencies
> first.
--
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: (MJAR-83) addClasspath is not respected for runtime dependencies
addClasspath is not respected for runtime dependencies
--
Key: MJAR-83
URL: http://jira.codehaus.org/browse/MJAR-83
Project: Maven 2.x Jar Plugin
Issue Type: Bug
Affects Versions: 2.1, 2.2
Reporter: William Ferguson
Attachments: pom.xml
maven-jar-plugin does not resolve dependencies itself, so specifying
{code}
true
{code}
will add no dependencies for
{noformat}
mvn jar:jar
{noformat}
And even
{noformat}
mvn compiler:compile jar:jar
{noformat}
will only add compile time dependencies, not runtime dependencies, presumably
because the maven-compiler-plugin causes resolution of the compile time
dependencies.
See the attached POM.
There is *no* manifest classpath generated by
{noformat}
mvn jar:jar
{noformat}
The manifest classpath generated by
{noformat}
mvn compiler:compile jar:jar
{noformat}
only contains commons-codec which is the compile time dependency.
There needs to be a way to add runtime dependences to the manifest classpath of
the jar.
And preferably not requiring some other plugin to resolve the dependencies
first.
--
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-107) Output the dependencies in a consistent and natural order
Output the dependencies in a consistent and natural order - Key: MDEP-107 URL: http://jira.codehaus.org/browse/MDEP-107 Project: Maven 2.x Dependency Plugin Issue Type: Improvement Affects Versions: 2.0-alpha-5 Reporter: William Ferguson Assignee: Brian Fox As of 2.0-alpha-5-SNAPSHOT 31-AUG-2007 the dependencies when output are in random order as I suspect they come straight form a Set. This makes it really difficult for a human to parse the dependencies. Ordering them using the natural artifact order before output would be a great improvement. In particular dependency:tree is very hard to read when they are not ordered. But if each level were ordered using the natural artifact ordering it would be much easier to read and to work out where the dep problems lay. [INFO] [dependency:tree] [INFO] com.yarris.consol:consol-web:war:1.0-SNAPSHOT [INFO]com.yarris:cielo:jar:1.5:compile [INFO]javax.j2ee:j2ee:jar:1.3.1:compile [INFO]commons-digester:commons-digester:jar:1.7:compile [INFO]opensymphony:sitemesh:jar:2.2.1:compile [INFO]commons-lang:commons-lang:jar:2.1:compile [INFO]com.yarris.consol:consol-ejb:ejb:1.0-SNAPSHOT:compile [INFO] org.apache.axis:axis:jar:1.4:compile [INFO] backport-util-concurrent:backport-util-concurrent:jar:3.0:compile [INFO] commons-discovery:commons-discovery:jar:0.2:compile [INFO] commons-httpclient:commons-httpclient:jar:3.0:compile [INFO] commons-codec:commons-codec:jar:1.3:compile [INFO] commons-javaflow:commons-javaflow:jar:20060411:compile [INFO] commons-pool:commons-pool:jar:1.1:compile [INFO] xerces:xercesImpl:jar:2.0.2:compile [INFO] com.yarris:hubbub-mail:jar:2.1:compile [INFO] jasperreports:jasperreports:jar:1.3.0:compile [INFO] xml-apis:xml-apis:jar:1.0.b2:compile [INFO] eclipse:jdtcore:jar:3.1.0:compile [INFO] org.apache.axis:axis-jaxrpc:jar:1.4:compile [INFO] eclipse:jdt-compiler:jar:3.1.1:compile [INFO] net.sourceforge.jexcelapi:jxl:jar:2.6.3:compile [INFO] com.yarris:kapri:jar:1.0.1:compile [INFO] org.ostermiller:ostermiller-utils:jar:1.04.00:compile [INFO] com.pd4ml:pd4ml:jar:1.2.4:compile [INFO] poi:poi-2.5.1-final:jar:20040804:compile [INFO] javax.xml.soap:saaj-api:jar:1.2:compile [INFO] com.yarris:samurai:jar:1.19:compile [INFO] com.yarris:hubbub-log4j:jar:1.8:compile [INFO] org.acegisecurity:acegi-security:jar:1.0.3:compile [INFO] org.springframework:spring-remoting:jar:1.2.8:compile [INFO]org.springframework:spring-dao:jar:1.2.8:compile [INFO] org.springframework:spring-context:jar:1.2.8:compile [INFO] org.springframework:spring-aop:jar:1.2.8:compile [INFO]org.springframework:spring-webmvc:jar:1.2.8:compile [INFO] org.springframework:spring-web:jar:1.2.8:compile [INFO] org.springframework:spring-jdbc:jar:1.2.8:compile [INFO]org.springframework:spring-beans:jar:1.2.8:compile [INFO] org.springframework:spring-core:jar:1.2.8:compile [INFO] org.springframework:spring-support:jar:1.2.8:runtime [INFO] org.apache.velocity:velocity:jar:1.5:compile [INFO] axis:axis-wsdl4j:jar:1.3:compile [INFO] org.apache.ws:wss4j:jar:1.5.0:compile [INFO] com.yarris:yarris-jms:jar:1.0:compile [INFO] commons-io:commons-io:jar:1.2:compile [INFO] opensymphony:oscache:jar:2.0.2:compile [INFO] com.yarris.consol:consol-interfaces:jar:1.1:compile [INFO] xmlbeans:xbean:jar:2.2.0:compile [INFO]struts:struts-el:jar:1.1:compile [INFO]com.yarris:sopho:jar:1.6:compile [INFO] jdom:jdom:jar:1.0:compile [INFO] log4j:log4j:jar:1.2.14:compile [INFO] velocity:velocity-dep:jar:1.4:compile [INFO]struts:struts:jar:1.1:compile [INFO] struts:struts-legacy:jar:1.1:compile [INFO] commons-validator:commons-validator:jar:1.0.2:compile [INFO] oro:oro:jar:2.0.6:compile [INFO] javax.sql:jdbc-stdext:jar:2.0:compile [INFO]com.yarris:hubbub-web:jar:1.3:compile [INFO]javax.servlet:jstl:jar:1.0.2:compile [INFO]commons-fileupload:commons-fileupload:jar:1.0:compile [INFO]jfree:jfreechart:jar:1.0.2:compile [INFO] jfree:jcommon:jar:1.0.0:compile [INFO] junit:junit:jar:3.7:compile [INFO]taglibs:standard:jar:1.0.4:compile [INFO] xalan:xalan:jar:2.6.0:compile [INFO]displaytag:displaytag:jar:1.1:compile [INFO] com.lowagie:itext:jar:2.0.0:compile [INFO] commons-beanutils:commons-beanutils:jar:1.6:compile [INFO] commons-logging:commons-logging:jar:1.0:compile -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://ji
[jira] Commented: (MNG-3112) Maven2 issues with Filter
[ http://jira.codehaus.org/browse/MNG-3112?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_105594 ] William Ferguson commented on MNG-3112: --- Deepal, your description of the problem is a little vague. But perhaps this issue sums up what you need? http://jira.codehaus.org/browse/MRESOURCES-47 If so, please vote for it. > Maven2 issues with Filter > -- > > Key: MNG-3112 > URL: http://jira.codehaus.org/browse/MNG-3112 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7 >Reporter: Deepal Jayasinghe >Priority: Critical > > Apache Axis2 moved to maven2 completely and now we have faced few issues with > maven2. Axis2 is a multi modules bit complex projects and we had no issues > with maven1 other than the performance. But once we moved to maven2 we > realized that we have issues with filters and we uses a number of filters as > well. Specially we have filters in the top most pom.xml and others extend > form that , once we change the filter value others get changed but the > uploaded one has the filter name not the value. > It will be great we can get a fix or path for this since this is bit critical > for us. We can edit them manually and do the release but that is not that > good. -- 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: (MRESOURCES-47) POM properties cannot be accessed within a filter file
[
http://jira.codehaus.org/browse/MRESOURCES-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Ferguson updated MRESOURCES-47:
---
Attachment: MRESOURCES-47-maven-resources-plugin.patch
Here's the patch for this issue, including several test cases.
NB I have changed as little as possible to make the patch as clear as possible.
IMO applying the patch would then allow for substantial refactoring.
> POM properties cannot be accessed within a filter file
> --
>
> Key: MRESOURCES-47
> URL: http://jira.codehaus.org/browse/MRESOURCES-47
> Project: Maven 2.x Resources Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: William Ferguson
> Fix For: 2.3
>
> Attachments: MRESOURCES-47-maven-resources-plugin.patch, project.zip
>
>
> Before applying a filter, the maven-resources-plugin evaluates
> 1) POM structural elements such as ${project.version}
> 2) System properties such as ${my.system.property}
> that are referred to within *filter* files.
> However, it does *not* evaluate any POM (or profile) property such as
> ${my.pom.property} at the same time.
> Consequently it is not possible to define filter tokens that use POM
> properties.
> Without this patch we would either need to have many more POM properties or
> would have lots of fine grained and typically non-intuitive tokens
> distributed amongst our resources.
> IMHO this patch will bring the resolution mechanism for filter files in line
> with property resolution mechanism in general.
> I have attached a zipped project containing :
> SomeResource.txt
> my.filter
> Look at SomeResource.txt after being processed with filtering. Note the
> unresolved tokens for ${projectProperty} and ${profileProperty} for the
> "filter resolution" cases. Ie the POM property values of the filter tokens
> were never evaluated.
--
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: (MRESOURCES-47) POM properties cannot be accessed within a filter file
POM properties cannot be accessed within a filter file
--
Key: MRESOURCES-47
URL: http://jira.codehaus.org/browse/MRESOURCES-47
Project: Maven 2.x Resources Plugin
Issue Type: Bug
Affects Versions: 2.2
Reporter: William Ferguson
Fix For: 2.3
Attachments: project.zip
Before applying a filter, the maven-resources-plugin evaluates
1) POM structural elements such as ${project.version}
2) System properties such as ${my.system.property}
that are referred to within *filter* files.
However, it does *not* evaluate any POM (or profile) property such as
${my.pom.property} at the same time.
Consequently it is not possible to define filter tokens that use POM properties.
Without this patch we would either need to have many more POM properties or
would have lots of fine grained and typically non-intuitive tokens distributed
amongst our resources.
IMHO this patch will bring the resolution mechanism for filter files in line
with property resolution mechanism in general.
I have attached a zipped project containing :
SomeResource.txt
my.filter
Look at SomeResource.txt after being processed with filtering. Note the
unresolved tokens for ${projectProperty} and ${profileProperty} for the "filter
resolution" cases. Ie the POM property values of the filter tokens were never
evaluated.
--
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: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104150
]
William Ferguson commented on WAGON-73:
---
Ah good. I'd just realised that my cursory investigation from before was a
little off as the actual time is read from the 'lastUpdated' element of the
Metadata and won't be resolved until it is requested. But I did wonder about
time zone.
I wish #assertEquals printed the full content for the expected and actual
values. It would have been useful.
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch,
> WAGON-73-ConnectAndGetTest.patch, WagonManagerTest.java.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104148
]
William Ferguson commented on WAGON-73:
---
I can't checkout the all the code necessary to fully inspect this right now,
but it looks like an error in the testcase.
Line #215 of MavenIT0108SnapshotUpdateTest calls #assertLocalMetadataIsToday
but passes in the localMetadata (File) that it resolved *before* the install
goal is run instead of after. Otherwise it will be comparing the localMetadata
File from a previous run (perhaps yesterday) which would explain the failure.
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch,
> WAGON-73-ConnectAndGetTest.patch, WagonManagerTest.java.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_104043
]
William Ferguson commented on MNG-2290:
---
Yes, but that doesn't solve this issue.
Essentially the whole childPathAdjustment aware mechanism *is* the root cause
of the problem being described here.
If there really is a need to deploy the project web sites in a structure that
mirrors the structure of a project and its child modules (and I'm struggling to
justify that) then I think there needs to be a distinction made between the URL
generates for projects that are contained modules and those that are not but
do use a URL form an inherited POM.
Unless there is someway to defined what ChildPathAdjustment aware strategy is
to be used (and in this case it would be need to be NONE) it will continue to
thwart the ability to define inherited URLs that resolve in the child to
anything other than /${artifactId} or
/${artifactid}/${ChildPathAdjustment}.
At no point can I specify an inheritable URL explicitly in the parent using
resolvable project properties.
At no point can I introduce the ${version} into the URL using inheritance.
But I think its good that your patch should at least make all the URLs behave
in the same (albeit poor IMHO) way.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103905
]
William Ferguson commented on MNG-2290:
---
Well if you do, I'll have to create another issue with the same title and copy
all of my comments (and some of yours) over there.
The auto append of ${artifactId} in child POMs is a *real* problem for url and
site#url.
But if you do close I suppose I can probably represent the problem again in a
much clearer form.
Its up to you.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103904
]
William Ferguson commented on ARCHETYPE-39:
---
Thanks Wendy, though I think you meant
\ ${artifactId}
(without the spaces), ie backslash before the $ and not after.
Though in the end I found using ${dollar} to be clearer in the template.
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity configuration.
--
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: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103900
]
William Ferguson commented on WAGON-73:
---
OK, our workaround to this bug (overriding the central repository in
settings.xml instead of creating a mirror for it). Ie
central
Overrride of Central (not
mirror)
http://zosma.oz.hubbub.com.au:8080/proximity/repository/release
true
false
central
Override of Central
http://zosma.oz.hubbub.com.au:8080/proximity/repository/release
true
false
appears to work for all maven components except when there is a dependency on
the maven-archetype-plugin.
For some reason 'mvn archetype:create ..' causes all Maven artifacts to be
retrieved from the *real* central and not the one we have overridden in
settings.xml. Whereas 'mvn clean compile' retrieves the Maven components from
the overridden location.
We are currently stuck in a situation, where either
a) 'mvn archetype:create' works
b) Eclipse can download Maven dependencies
But not both.
So can we please get the patch applied?
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Assignee: Joakim Erdfelt
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch,
> WAGON-73-ConnectAndGetTest.patch, WagonManagerTest.java.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103841
]
William Ferguson commented on MNG-2290:
---
Sorry Jorge, you lost me.
The URL *is* inherited (if it is not specified in the child POM), but at
execution time (in the child) it becomes the inherited URL with the
${artifactId} specified in the child POM appended to it.
So deployment of the site for the parent POM is to an entirely different
location (the root of the projects website) than for any children.
Ie there is no consistent site deployment location available to the parent POM
and child projects.
IMHO it is not useful to attempt to inherit the SCM settings as the
release-plugin needs to rewrite them in the child POM during release in any
case. I think thats what you are referring to in your last 2 sentences. Correct
me if I'm wrong.
But the thing thats a real killer (for us) is that because ${artifactId} is
appended to the URLs we cannot craft an inheritable URL that includes the child
project's version.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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: (ARCHETYPE-59) archetype plugin doesn't use private plugin repository configured in /conf/settings.xml
[ http://jira.codehaus.org/browse/ARCHETYPE-59?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103839 ] William Ferguson commented on ARCHETYPE-59: --- The workaround for this is to specify a 'remoteRepositories' property on the command line pointing to your internal Repository. Eg mvn archetype:create -DgroupId=com.yarris -DartifactId=foo-project -DarchetypeGroupId=com.yarris.maven -DarchetypeArtifactId=archetype-standard -DremoteRepositories=http://zosma.oz.hubbub.com.au:8080/proximity/repository/release This issues appears to be a duplicate of : http://jira.codehaus.org/browse/ARCHETYPE-1 http://jira.codehaus.org/browse/ARCHETYPE-81 What I don't understand is that http://jira.codehaus.org/browse/ARCHETYPE-1 is marked as closed fixed (with no version), but the issue still clearly exists in maven-2.0.7, maven-archetype-1.0-alpha-4 Without a real fix for this issue creating projects using archetypes is not really viable. Ie it becomes almost as easy to copy and paste an existing project and modify ts details that to use an archetype. Which is what I thought we are trying to get away from. > archetype plugin doesn't use private plugin repository configured in > /conf/settings.xml > --- > > Key: ARCHETYPE-59 > URL: http://jira.codehaus.org/browse/ARCHETYPE-59 > Project: Maven Archetype > Issue Type: Bug > Components: Archetypes >Affects Versions: 1.0-alpha-4 > Environment: windows xp > jdk 1.5.0_09-b01 >Reporter: Martin Testrot > > I configured the file /conf/settings to use a local, private > plugin repository to prevent uncontrolled download from the official central > repository at http://repo1.maven.org/maven2. This works fine except in the > case I call the archetype plugin (archetype:create). In this case the > settings.xml is ignored and all plugins are downloaded from the central > repository at maven.org. > I observed the same when calling mvn help:active-profiles in a directory that > doesn't contain a pom.xml file. > If I place a dummy pom.xml file in this directory the settings.xml are used > and everything is fine. But if I use this trick with the archetype plugin the > newly created project (creation via archetype) is configured as a child of my > dummy pom (pom.xml contains parent section with dummy pom). I the case of a > dummy pom this is not intended. > So i would be nice if you can fix the archtype plugin to use the configured > settings.xml. I really would like to use this plugin, because it would help a > lot to standardize a common project layout for our developers. This is a > majour reason for choosing maven2. > Greetings, > Martin > Here is the relevant section of my settings.xml: > ... > > > > private-repo > > > > central > private plugin repository > > http://localserver/mvn-repos/maven-plugin > > true > > daily > > > false > > > > > > > > private-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] Commented: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103824
]
William Ferguson commented on ARCHETYPE-39:
---
For those interested in a solution, specify
#set($dollar = '$')
at the head of the archetype Velocity template in which you need the unescaped
dollar signs.
Then to get ${artifactId} in the output, specify
${dollar}{artifactId}
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity configuration.
--
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: (ARCHETYPE-39) Add tool for working with escaping in Velocity templates
[
http://jira.codehaus.org/browse/ARCHETYPE-39?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103823
]
William Ferguson commented on ARCHETYPE-39:
---
OK, I'm confused.
The issue is marked as WON'T FIX, but the comment seem to imply that a change
was made.
Was a change made and if so which version of the archetype-plugin?
Also, what is the syntax that is required to get it to work?
Wendy's comment on 2-JUN-07 seem to imply that ${artifactId} in the archetype
will produce ${artifactId} in the new project, but that doesn't work for me
with maven-2.0.7 and maven-archetype-1.0-alpha-4.
Tokens of the form ${artifactId} are converted to actual values when creating
the new project.
Just like Guillaume, I need ${artifactId} in the output.
How do I get it?
> Add tool for working with escaping in Velocity templates
>
>
> Key: ARCHETYPE-39
> URL: http://jira.codehaus.org/browse/ARCHETYPE-39
> Project: Maven Archetype
> Issue Type: Improvement
> Components: Plugin
>Affects Versions: 1.0-alpha-4
>Reporter: Willie Vu
> Attachments: ARCHETYPE-39-velocity-escape-tool.patch,
> ARCHETYPE-39.patch
>
>
> e.g. I need to put ${archifactId} (without parameter replacement) into an
> assembly descriptor. I need to escape the dollar sign.
> This is the Escape Tool of Velocity -
> http://jakarta.apache.org/velocity/tools/javadoc/org/apache/velocity/tools/generic/EscapeTool.html.
> The embedded Velocity engine will be configured to use it, or archetype
> plugin allows further Velocity configuration.
--
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-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103822
]
William Ferguson commented on MNG-2290:
---
The work around for this is top specify the project#url and
project#distributionManangement#site#url in *every* POM.
Failure to do so means that :
If your parent POM defines its URLs as http://MyMachine/projects then the child
projects will be published to reachable (but unversioned) locations such as
http://MyMachine/projects/SomeProject on the projects site, but the site for
the parent POM will be published to the root of your projects site, generally
overwriting any general welcome page that might direct you to the other
projects.
If your parent POM defines its URLs as http://MyMachine/projects/${artifactId}
then the child projects will be published to locations such as
http://MyMachine/projects/SomeProject/SomeProject but the parent POM will get
published to an expected location like http://MyMachine/projects/MyPom.
So there is also inconsistency between a URL defined in a POM and one defined
in a parent POM.
Please, please make it consistent, preferably by having no automatic appending
of the artifactId for URLs defined in a parent POM and instead let us specify
the location using build properties like
http://MyMachine/projects/${artifactId}/${version} which are evaluated just
like every other build property. The current behaviour is inconsistent with
every other aspect of a Maven build.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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] Issue Comment Edited: (MNG-2290) Generated URLs in POMs of child modules
[ http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92415 ] William Ferguson edited comment on MNG-2290 at 8/1/07 6:35 PM: --- It doesn't need to be a complex project structure for this to cause pain. I would like to set up a parent POM that can be inherited by all my projects so that I can specify common paths for them. But if the scm.connection for my head of each of my projects is : http://MyMachine/svn/MyProject/trunk (which follows the Subversion convention) How do I specify this in the parent POM? It will always append the artifactId to my Url causing it to fail. Same goes for most of the other Urls. If the auto replacement was switched off, then we could use explicit property replacement in the parent POM to clearly define our needs. was: It doesn't need to be a complex project structure for this to cause pain. I would like to set up a parent POM that can be inherited by all my projects so that I can specify common paths for them. But if the scm.connection for my head of each of my projects is : http:///svn/ /trunk (which follows the Subversion convention) How do I specify this in the parent POM? It will always append the artifactId to my Url causing it to fail. Same goes for most of the other Urls. If the auto replacement was switched off, then we could use explicit property replacement in the parent POM to clearly define our needs. > Generated URLs in POMs of child modules > --- > > Key: MNG-2290 > URL: http://jira.codehaus.org/browse/MNG-2290 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Affects Versions: 2.0.4 >Reporter: Joerg Schaible > Fix For: 2.0.x > > > Maven has quite some elements where a URL or a path is modified automatically > for child POMs (the ones I am currently aware of): > - url > - scm/connection > - scm/developerConnection > - scm/url > - distributionManagement/site/url > While expanding this path with "/${pom.artifactId}" sounds reasonable, this > approach fails badly for complex projects with more hierarchy levels. Suppose > we have a directory structure like: > * project > ** core > *** provider > commons > impl1 > In this hierarchy all POMs for _project_, _core_ and _provider_ are of > package type _pom_, while _commons_ and _impl1_ is of type _jar_. The > "artifactId" approach now simply assumes that all POMs in the hierarchy are > named like the current directory. This does simply not match. Suppose those > jar artifacts are used in an enterprise or web app. Then every artifact is > located in one single directory and therefore the names have to be unique. > But if you decide to take an artifact name different to the directory name, > you have to add the definition in every POM, because the scm elements are > simply wrong. > An even worse scenario are components that can be provided using different > technologies. We have a lot of such structures: > * component > ** jar > ** war > ** ear > * *_jar_:* the core functionality > * *_war_:* the core functionality integrated and eccessible with a web > application > * *_ear_:* the complete component as enterprise app, if it makes sense to > deploy the functionality on a different app server > _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs > with the according package type. All of the three POMs use the same > artifactId though. In this case not only the scm elements break, but also the > URLs for the site, since they are all the same for all three artifacts. > All of this could have been avoided, if the expanded part is not the > artifactId, but the basename of the current directory. Especially for the scm > elements, this is IMHO the only valid assumption. > It would already help us, if this auto-expansion could be turned off to allow > the definition of a single property in each POM for a correct interpolation > of those values, but there seems no such option ^1^. So you *have to* add > those elements under all circumstances into every POM. > 1) The _tagBase_ of the release plugin does no such auto-expansion, which > makes it quite easy to use a property for it, that can be set individually in > every POM without adding any plugin configuration. -- 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] Issue Comment Edited: (MNG-2290) Generated URLs in POMs of child modules
[ http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92415 ] William Ferguson edited comment on MNG-2290 at 8/1/07 6:35 PM: --- It doesn't need to be a complex project structure for this to cause pain. I would like to set up a parent POM that can be inherited by all my projects so that I can specify common paths for them. But if the scm.connection for my head of each of my projects is : http:///svn/ /trunk (which follows the Subversion convention) How do I specify this in the parent POM? It will always append the artifactId to my Url causing it to fail. Same goes for most of the other Urls. If the auto replacement was switched off, then we could use explicit property replacement in the parent POM to clearly define our needs. was: It doesn't need to be a complex project structure for this to cause pain. I would like to set up a parent POM that can be inherited by all my projects so that I can specify common paths for them. But if the scm.connection for my head of each of my projects is : http:///svn//trunk (which follows the Subversion convention) How do I specify this in the parent POM? It will always append the artifactId to my Url causing it to fail. Same goes for most of the other Urls. If the auto replacement was switched off, then we could use explicit property replacement in the parent POM to clearly define our needs. > Generated URLs in POMs of child modules > --- > > Key: MNG-2290 > URL: http://jira.codehaus.org/browse/MNG-2290 > Project: Maven 2 > Issue Type: Improvement > Components: Inheritance and Interpolation >Affects Versions: 2.0.4 >Reporter: Joerg Schaible > Fix For: 2.0.x > > > Maven has quite some elements where a URL or a path is modified automatically > for child POMs (the ones I am currently aware of): > - url > - scm/connection > - scm/developerConnection > - scm/url > - distributionManagement/site/url > While expanding this path with "/${pom.artifactId}" sounds reasonable, this > approach fails badly for complex projects with more hierarchy levels. Suppose > we have a directory structure like: > * project > ** core > *** provider > commons > impl1 > In this hierarchy all POMs for _project_, _core_ and _provider_ are of > package type _pom_, while _commons_ and _impl1_ is of type _jar_. The > "artifactId" approach now simply assumes that all POMs in the hierarchy are > named like the current directory. This does simply not match. Suppose those > jar artifacts are used in an enterprise or web app. Then every artifact is > located in one single directory and therefore the names have to be unique. > But if you decide to take an artifact name different to the directory name, > you have to add the definition in every POM, because the scm elements are > simply wrong. > An even worse scenario are components that can be provided using different > technologies. We have a lot of such structures: > * component > ** jar > ** war > ** ear > * *_jar_:* the core functionality > * *_war_:* the core functionality integrated and eccessible with a web > application > * *_ear_:* the complete component as enterprise app, if it makes sense to > deploy the functionality on a different app server > _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs > with the according package type. All of the three POMs use the same > artifactId though. In this case not only the scm elements break, but also the > URLs for the site, since they are all the same for all three artifacts. > All of this could have been avoided, if the expanded part is not the > artifactId, but the basename of the current directory. Especially for the scm > elements, this is IMHO the only valid assumption. > It would already help us, if this auto-expansion could be turned off to allow > the definition of a single property in each POM for a correct interpolation > of those values, but there seems no such option ^1^. So you *have to* add > those elements under all circumstances into every POM. > 1) The _tagBase_ of the release plugin does no such auto-expansion, which > makes it quite easy to use a property for it, that can be set individually in > every POM without adding any plugin configuration. -- 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] Issue Comment Edited: (MNG-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103820
]
William Ferguson edited comment on MNG-2290 at 8/1/07 6:34 PM:
---
I realise I wasn't as clear in my comment above as I could have been. So I'll
try again.
I want to be able to deploy the sites for my projects in a versioned manner.
Ie I want to retain the sites of all previously released versions of my
components.
I imagine the structure for the web site to look something like :
/SomeProject/1.0
/SomeProject/1.1
/Anotherproject/1.0
/Anotherproject/2.0
etc
I also want to keep my POMs as clear and simple as possible, so I try and put
as much common configuration in the common parent POM.
But the values for project#url and project#distributionManagement#site#url
specified in the parent (and not overridden in the child) will automatically
have the artifactId of the child appended to them. So there is no way to
achieve the folder structure specified above using any kind of url statement in
the parent POM.
I think Maven needs to *stop* automatically appending ${artifactId} to the url
and site#url of the parent POM and instead encourage specification use of the
actual url that is required, eg
http://myhost/maven-projects/${artifactId}/${version}
or whatever is required.
Now I believe versioned sites is something that the Maven group as a whole was
planning on doing themselves, so this looks like an area that needs to be
resolved.
was:
I realise I wasn't as clear in my comment above as I could have been. So I'll
try again.
I want to be able to deploy the sites for my projects in a versioned manner.
Ie I want to retain the sites of all previously released versions of my
components.
I imgaine the structure for the web site to look something like :
/SomeProject/1.0
/SomeProject/1.1
/Anotherproject/1.0
/Anotherproject/2.0
etc
I also want to keep my POMs as clear and simple as possible, so I try and put
as much common configuration in the common parent POM.
But the values for project#url and project#distributionManagement#site#url
specified in the parent (and not overridden in the child) will automatically
have the artifactId of the child appended to them. So there is no way to
achieve the folder structure specified above using any kind of url statement in
the parent POM.
I think Maven needs to *stop* automatically appending ${artifactId} to the url
and site#url of the parent POM and instead encourage specification use of the
actual url that is required, eh
http://myhost/maven-projects/${artifactId}/${version} or whatever is required.
Now I believe versioned sites is something that the Maven group as a whole was
planning on doing themselves, so this looks like an area that needs to be
resolved.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId t
[jira] Commented: (MNG-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103820
]
William Ferguson commented on MNG-2290:
---
I realise I wasn't as clear in my comment above as I could have been. So I'll
try again.
I want to be able to deploy the sites for my projects in a versioned manner.
Ie I want to retain the sites of all previously released versions of my
components.
I imgaine the structure for the web site to look something like :
/SomeProject/1.0
/SomeProject/1.1
/Anotherproject/1.0
/Anotherproject/2.0
etc
I also want to keep my POMs as clear and simple as possible, so I try and put
as much common configuration in the common parent POM.
But the values for project#url and project#distributionManagement#site#url
specified in the parent (and not overridden in the child) will automatically
have the artifactId of the child appended to them. So there is no way to
achieve the folder structure specified above using any kind of url statement in
the parent POM.
I think Maven needs to *stop* automatically appending ${artifactId} to the url
and site#url of the parent POM and instead encourage specification use of the
actual url that is required, eh
http://myhost/maven-projects/${artifactId}/${version} or whatever is required.
Now I believe versioned sites is something that the Maven group as a whole was
planning on doing themselves, so this looks like an area that needs to be
resolved.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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: (MRELEASE-270) release:prepare doesn't fail when the project it is building fails to compile
[ http://jira.codehaus.org/browse/MRELEASE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_103062 ] William Ferguson commented on MRELEASE-270: --- NB the attached zip contains a project with uncompilable source. > release:prepare doesn't fail when the project it is building fails to compile > - > > Key: MRELEASE-270 > URL: http://jira.codehaus.org/browse/MRELEASE-270 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson > Attachments: MRELEASE-XXX.zip > > > Unusual situation on our build server, where one of the dependent libraries > had been corrupted in its local repository. > 'mvn compile' would fail with compilation errors - it couldn't find the > classes from the corrupt jar. > 'mvn release:prepare' would note compilation errors and indicate build > failure, but would continue on with the release, modify the POMs, tag the > source and finally complete indicating success. > I noted that the same thing can happen if uncompilable source is checked in, > though at least then you would get the compilation failure on your local > machine too. > I think release:prepare should clearly fail (it wasn't clear in this instance > unless you scrolled back through the build output) if any part of the > release:prepare fails. > To replicate either > a) Attempt top release uncompilable code. > b) Replace a dependent jar with a renamed text file and attempt to 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] Created: (MRELEASE-270) release:prepare doesn't fail when the project it is building fails to compile
release:prepare doesn't fail when the project it is building fails to compile - Key: MRELEASE-270 URL: http://jira.codehaus.org/browse/MRELEASE-270 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: William Ferguson Attachments: MRELEASE-XXX.zip Unusual situation on our build server, where one of the dependent libraries had been corrupted in its local repository. 'mvn compile' would fail with compilation errors - it couldn't find the classes from the corrupt jar. 'mvn release:prepare' would note compilation errors and indicate build failure, but would continue on with the release, modify the POMs, tag the source and finally complete indicating success. I noted that the same thing can happen if uncompilable source is checked in, though at least then you would get the compilation failure on your local machine too. I think release:prepare should clearly fail (it wasn't clear in this instance unless you scrolled back through the build output) if any part of the release:prepare fails. To replicate either a) Attempt top release uncompilable code. b) Replace a dependent jar with a renamed text file and attempt to 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] Closed: (MRELEASE-212) Mojo executed using preparationGoals does not get its parameters populated on execution
[
http://jira.codehaus.org/browse/MRELEASE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Ferguson closed MRELEASE-212.
-
Resolution: Won't Fix
I got around this issue by retrieving the information from Subversion directly.
But this has meant that the plugin which does so needs to be executed as a
precise point in the release which is NOT the
prepareGoals phase - which makes http://jira.codehaus.org/browse/MRELEASE-213
all the more important.
> Mojo executed using preparationGoals does not get its parameters populated on
> execution
> ---
>
> Key: MRELEASE-212
> URL: http://jira.codehaus.org/browse/MRELEASE-212
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: William Ferguson
>
> I have a Mojo with a single String parameter
> /**
>* @parameter expression="${myProp}"
>*/
> private String myProp;
> If this Mojo is executed directly, eg
> mvn myplugin:mygoal -DmyProp=foo
> then the Mojo receives the value of myProp at runtime.
> If my Mojo is executed via maven-release-plugin preparationGoals eg
>
> org.apache.maven.plugins
> maven-release-plugin
>
>
> clean integration-test
> myplugin:mygoal
>
>
>
> the the Mojo is not injected with the value of MyProp at runtime.
> Now this could just be because there is some extra config that I need to do
> that I have missed. I am a Maven newbie.
> But I've followed all the doco for maven-release-plugin as well as anything I
> could find on building plugins.
> So if its my bad, please point me in the right direction.
--
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: (MRELEASE-213) Need ability to access values gathered by maven-release-plugin in Mojos executed as part of preparationGoals element
[ http://jira.codehaus.org/browse/MRELEASE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Ferguson closed MRELEASE-213. - Resolution: Won't Fix I got around this issue by retrieving the information from Subversion directly. But this has meant that the plugin which does so needs to be executed as a precise point in the release which is NOT the prepareGoals phase - which makes http://jira.codehaus.org/browse/MRELEASE-213 all the more important. > Need ability to access values gathered by maven-release-plugin in Mojos > executed as part of preparationGoals element > > > Key: MRELEASE-213 > URL: http://jira.codehaus.org/browse/MRELEASE-213 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-4 >Reporter: William Ferguson > > I have a plugin containing a Mojo that needs to be executed as part of the > maven-release-plugin's preparationGoals phase. > The Mojo needs access to some of the information gathered by the > maven-release-plugin. > Namely it needs access to the SCM release tag specified by the user. > The aim of the plugin is to update the subclipse:tags property of the project > being released in a similar manner that the Eclipse/Subversion Subclipse > plugin does. So the information that I need to gather from the > maven-release-plugin is > 1) SCM release tag specified by the user. > 2) Any other SCM details that have been modified for the release plugin. -- 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: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
William Ferguson updated WAGON-73:
--
Attachment: WAGON-73-ConnectAndGetTest.patch
OK, can we get this issued reopened now?
The test case that Phil has provided certainly seemed OK and definitely results
in an infinite loop on #connect. The patch that I have just provided also shows
#get failing.
Applying Phil's patch resolves the issue.
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Assignee: Joakim Erdfelt
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch,
> WAGON-73-ConnectAndGetTest.patch, WagonManagerTest.java.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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: (WAGON-75) m2eclipse is having issues with wagon
[ http://jira.codehaus.org/browse/WAGON-75?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97452 ] William Ferguson commented on WAGON-75: --- Sorry about that, managed to attach the patch to the wrong issue twice in a row. > m2eclipse is having issues with wagon > - > > Key: WAGON-75 > URL: http://jira.codehaus.org/browse/WAGON-75 > Project: wagon > Issue Type: Bug >Reporter: Joakim Erdfelt > Attachments: WAGON-73-ConnectAndGetTest.patch, > WAGON-73-ConnectAndGetTest.patch > > > the m2eclipse project is having issues with wagon. > This is just a tracking jira to link in those tickets from the m2eclipse > project that show the problems. -- 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: (WAGON-75) m2eclipse is having issues with wagon
[ http://jira.codehaus.org/browse/WAGON-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Ferguson updated WAGON-75: -- Attachment: WAGON-73-ConnectAndGetTest.patch OK, can we get this issued reopened now? The test case that Phil has provided certainly seemed OK and definitely results in an infinite loop on #connect. The patch that I have just provided also shows #get failing. Applying Phil's patch resolves the issue. > m2eclipse is having issues with wagon > - > > Key: WAGON-75 > URL: http://jira.codehaus.org/browse/WAGON-75 > Project: wagon > Issue Type: Bug >Reporter: Joakim Erdfelt > Attachments: WAGON-73-ConnectAndGetTest.patch, > WAGON-73-ConnectAndGetTest.patch > > > the m2eclipse project is having issues with wagon. > This is just a tracking jira to link in those tickets from the m2eclipse > project that show the problems. -- 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: (WAGON-75) m2eclipse is having issues with wagon
[ http://jira.codehaus.org/browse/WAGON-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Ferguson updated WAGON-75: -- Attachment: WAGON-73-ConnectAndGetTest.patch OK, can we get this issued reopened now? The test case that Phil has provided certainly seemed OK and definitely results in an infinite loop on #connect. The patch that I have just provided also shows #get failing. Applying Phil's patch resolves the issue. > m2eclipse is having issues with wagon > - > > Key: WAGON-75 > URL: http://jira.codehaus.org/browse/WAGON-75 > Project: wagon > Issue Type: Bug >Reporter: Joakim Erdfelt > Attachments: WAGON-73-ConnectAndGetTest.patch, > WAGON-73-ConnectAndGetTest.patch > > > the m2eclipse project is having issues with wagon. > This is just a tracking jira to link in those tickets from the m2eclipse > project that show the problems. -- 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: (MRELEASE-236) ArrayindexoutofBoundsException rewriting the Poms for release
[ http://jira.codehaus.org/browse/MRELEASE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97112 ] William Ferguson commented on MRELEASE-236: --- >From recollection it was originally scm:svn:http://iago.oz.hubbub.com.au/svn/test-project/trunk but the release-plugin rewrote it during a prior release (which I have always found very confusing and frustrating). I'll change all the Pom Urls so they point back to the trunk. Are they no longer being rewritten? > ArrayindexoutofBoundsException rewriting the Poms for release > - > > Key: MRELEASE-236 > URL: http://jira.codehaus.org/browse/MRELEASE-236 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson >Priority: Blocker > Attachments: MRELEASE-236-patch.txt, pom.xml, Stacktrace.txt > > > Just testing out maven-release-plugin-2.0-beta-6 prior to release and noticed > that it always fails on release:prepare when it is rewriting the Poms. > Looking at the source code, the while loop at lines 249:252 of > RewritePomsForReleasePhase class will always iterate past the end of the char > arrays. > I'm not sure, but I suspect the appropriate soltuion is to check to ensure > that i < tagPathChars.length and i < trunkPathChars.length within the loop > and if so to break. -- 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: (WAGON-73) MirroredWagon infinite loop
[
http://jira.codehaus.org/browse/WAGON-73?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_97032
]
William Ferguson commented on WAGON-73:
---
Can we get this reopened please.
Phil's patch has not been applied and AFAICT #connect() will still loop
indefinitely if the connect succeeds, likewise for #get(String, File)
> MirroredWagon infinite loop
> ---
>
> Key: WAGON-73
> URL: http://jira.codehaus.org/browse/WAGON-73
> Project: wagon
> Issue Type: Bug
>Reporter: Phillip Webb
>Assignee: Joakim Erdfelt
>Priority: Critical
> Fix For: 2.0
>
> Attachments: returnsonmirroredwagon.patch
>
>
> The MirroredWagon class includes a get method that runs into an infinite loop.
> I think a return is required after this.impl.get( resource, destination );
> public void get( String resource, File destination )
> throws TransferFailedException, ResourceDoesNotExistException,
> AuthorizationException
> {
> try
> {
> while ( true )
> {
> try
> {
> this.impl.get( resource, destination );
> }
> catch ( TransferFailedException e )
> {
> nextMirror();
> }
> }
> }
> catch ( ExhaustedMirrorsException e )
> {
> }
> }
--
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-235) Need ability to execute goals during prepare after scm-tag but before scm-commit-development phase
[ http://jira.codehaus.org/browse/MRELEASE-235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Ferguson updated MRELEASE-235: -- Attachment: MRELEASE-235-patch.txt This patch adds another preparation phase (run-post-preparation-goals) that runs like so: scm-commit-development run-post-preparation-goals end-release It allows execution of user-defined goals during the release:prepare but after the project has been released. Eg updating of SCM properties to refer to new tag - subclipse:tags property. I have added test case for it which is essentially a copy of the RunPreparationGoalsPhaseTest. Any chance it can be included with 2.0-beta-6 since another build is going to be required anyway (due to http://jira.codehaus.org/browse/MRELEASE-236) ? > Need ability to execute goals during prepare after scm-tag but before > scm-commit-development phase > -- > > Key: MRELEASE-235 > URL: http://jira.codehaus.org/browse/MRELEASE-235 > Project: Maven 2.x Release Plugin > Issue Type: New Feature > Components: scm >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson > Attachments: MRELEASE-235-patch.txt > > > During release:prepare I have a plugin that needs to be called after the > scm-tag phase but before the scm-commit-development phase. > My plugin updates the subclipse-tags property trunk folder so that Subclipse > (Eclipse plugin for SVN) can provide good visual clues on the history tab > showing which revisions were released and a what. > My plugin needs to be able to > 1) read release.properties to get the scm.tag > 2) use SVN to retrieve the SVN Revision for the scm.tag (hence need to > execute after scm-tag phase) > 3) use SVN to retrieve the subclipse-tags property from the trunk > 4) Append the appropriate tag lines to the retrieve property. > 5) use SVN to update the subclipse-tags property on the trunk > 6) Either use SVN to commit or be comfortable that an SVN commit will occur > by other means (hence need to execute before scm-commit-development-phase) > I'm not sure of the best approach to take. A new phase needs to available in > which to execute. Either > a) after scm-tag but before scm-commit-development in which case I leave the > commit to the scm-commit-development phase. Perhaps a little too coupled and > hides a little too much meaning, but only generates 2 commits for a release > instead of 3. > b) after scm-commit-development (eg run-post-preparation-goals) which is self > contained as it needs to commit. It will generate an extra commit each > release, but the commit message can at least clearly relate to update of the > subclipse-tags property. I think I'll attempt this. > I thought I could take the easy approach and run the goal during > release:perform, but the basedir during run-perform-goals is > project.basedir/target/checkout and points to the Tag not the trunk. So my > plugin would become highly coupled to being executed during release:perform > as well as having intimate knowledge of expecting execution folders. > Unless someone interjects I intend on having a go at this and providing it as > a patch. > So if I'm way off base please provide feedback to guide me. > What's the expected release date for 2.0-beta-6 ? -- 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-236) ArrayindexoutofBoundsException rewriting the Poms for release
ArrayindexoutofBoundsException rewriting the Poms for release - Key: MRELEASE-236 URL: http://jira.codehaus.org/browse/MRELEASE-236 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-6 Reporter: William Ferguson Priority: Blocker Attachments: Stacktrace.txt Just testing out maven-release-plugin-2.0-beta-6 prior to release and noticed that it always fails on release:prepare when it is rewriting the Poms. Looking at the source code, the while loop at lines 249:252 of RewritePomsForReleasePhase class will always iterate past the end of the char arrays. I'm not sure, but I suspect the appropriate soltuion is to check to ensure that i < tagPathChars.length and i < trunkPathChars.length within the loop and if so to break. -- 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-236) ArrayindexoutofBoundsException rewriting the Poms for release
[ http://jira.codehaus.org/browse/MRELEASE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Ferguson updated MRELEASE-236: -- Attachment: MRELEASE-236-patch.txt I believe this patch fixes the issue. > ArrayindexoutofBoundsException rewriting the Poms for release > - > > Key: MRELEASE-236 > URL: http://jira.codehaus.org/browse/MRELEASE-236 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson >Priority: Blocker > Attachments: MRELEASE-236-patch.txt, pom.xml, Stacktrace.txt > > > Just testing out maven-release-plugin-2.0-beta-6 prior to release and noticed > that it always fails on release:prepare when it is rewriting the Poms. > Looking at the source code, the while loop at lines 249:252 of > RewritePomsForReleasePhase class will always iterate past the end of the char > arrays. > I'm not sure, but I suspect the appropriate soltuion is to check to ensure > that i < tagPathChars.length and i < trunkPathChars.length within the loop > and if so to break. -- 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-236) ArrayindexoutofBoundsException rewriting the Poms for release
[ http://jira.codehaus.org/browse/MRELEASE-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] William Ferguson updated MRELEASE-236: -- Attachment: pom.xml I've attached the POM that was causing the problem. Though I think its self evident from the code what the problem is. > ArrayindexoutofBoundsException rewriting the Poms for release > - > > Key: MRELEASE-236 > URL: http://jira.codehaus.org/browse/MRELEASE-236 > Project: Maven 2.x Release Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-6 >Reporter: William Ferguson >Priority: Blocker > Attachments: pom.xml, Stacktrace.txt > > > Just testing out maven-release-plugin-2.0-beta-6 prior to release and noticed > that it always fails on release:prepare when it is rewriting the Poms. > Looking at the source code, the while loop at lines 249:252 of > RewritePomsForReleasePhase class will always iterate past the end of the char > arrays. > I'm not sure, but I suspect the appropriate soltuion is to check to ensure > that i < tagPathChars.length and i < trunkPathChars.length within the loop > and if so to break. -- 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-235) Need ability to execute goals during prepare after scm-tag but before scm-commit-development phase
Need ability to execute goals during prepare after scm-tag but before scm-commit-development phase -- Key: MRELEASE-235 URL: http://jira.codehaus.org/browse/MRELEASE-235 Project: Maven 2.x Release Plugin Issue Type: New Feature Components: scm Affects Versions: 2.0-beta-6 Reporter: William Ferguson During release:prepare I have a plugin that needs to be called after the scm-tag phase but before the scm-commit-development phase. My plugin updates the subclipse-tags property trunk folder so that Subclipse (Eclipse plugin for SVN) can provide good visual clues on the history tab showing which revisions were released and a what. My plugin needs to be able to 1) read release.properties to get the scm.tag 2) use SVN to retrieve the SVN Revision for the scm.tag (hence need to execute after scm-tag phase) 3) use SVN to retrieve the subclipse-tags property from the trunk 4) Append the appropriate tag lines to the retrieve property. 5) use SVN to update the subclipse-tags property on the trunk 6) Either use SVN to commit or be comfortable that an SVN commit will occur by other means (hence need to execute before scm-commit-development-phase) I'm not sure of the best approach to take. A new phase needs to available in which to execute. Either a) after scm-tag but before scm-commit-development in which case I leave the commit to the scm-commit-development phase. Perhaps a little too coupled and hides a little too much meaning, but only generates 2 commits for a release instead of 3. b) after scm-commit-development (eg run-post-preparation-goals) which is self contained as it needs to commit. It will generate an extra commit each release, but the commit message can at least clearly relate to update of the subclipse-tags property. I think I'll attempt this. I thought I could take the easy approach and run the goal during release:perform, but the basedir during run-perform-goals is project.basedir/target/checkout and points to the Tag not the trunk. So my plugin would become highly coupled to being executed during release:perform as well as having intimate knowledge of expecting execution folders. Unless someone interjects I intend on having a go at this and providing it as a patch. So if I'm way off base please provide feedback to guide me. What's the expected release date for 2.0-beta-6 ? -- 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-234) RewritePomsForReleasePhase requires JDK 5.0
RewritePomsForReleasePhase requires JDK 5.0 --- Key: MRELEASE-234 URL: http://jira.codehaus.org/browse/MRELEASE-234 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Environment: JDK1.4 Reporter: William Ferguson If JAVA_HOME is set to JDK-1.4 you cannot build the maven-release-manager as the RewritePomsForReleasePhase class uses 2 JDK-5 APIs on lines 254 urlPath.contains(CharSequence) 260 urlPath.replace(CharSequence, CharSequence) If JDK-5 is required for the build environment then the POM needs to be modified to maven-compiler-plugin 1.5 1.4 Note that specifying 1.4 does not seem to ensure that only 1.4 APIs are used. Just try setting JAVA_HOME to JDK-1.4 and build Alternatively RewritePomsForReleasePhase should not used JDK-1.4 APIs. -- 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-2290) Generated URLs in POMs of child modules
[
http://jira.codehaus.org/browse/MNG-2290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_92415
]
William Ferguson commented on MNG-2290:
---
It doesn't need to be a complex project structure for this to cause pain.
I would like to set up a parent POM that can be inherited by all my projects so
that I can specify common paths for them.
But if the scm.connection for my head of each of my projects is :
http:///svn//trunk (which follows the Subversion convention)
How do I specify this in the parent POM?
It will always append the artifactId to my Url causing it to fail.
Same goes for most of the other Urls.
If the auto replacement was switched off, then we could use explicit property
replacement in the parent POM to clearly define our needs.
> Generated URLs in POMs of child modules
> ---
>
> Key: MNG-2290
> URL: http://jira.codehaus.org/browse/MNG-2290
> Project: Maven 2
> Issue Type: Improvement
> Components: Inheritance and Interpolation
>Affects Versions: 2.0.4
>Reporter: Joerg Schaible
> Fix For: 2.0.x
>
>
> Maven has quite some elements where a URL or a path is modified automatically
> for child POMs (the ones I am currently aware of):
> - url
> - scm/connection
> - scm/developerConnection
> - scm/url
> - distributionManagement/site/url
> While expanding this path with "/${pom.artifactId}" sounds reasonable, this
> approach fails badly for complex projects with more hierarchy levels. Suppose
> we have a directory structure like:
> * project
> ** core
> *** provider
> commons
> impl1
> In this hierarchy all POMs for _project_, _core_ and _provider_ are of
> package type _pom_, while _commons_ and _impl1_ is of type _jar_. The
> "artifactId" approach now simply assumes that all POMs in the hierarchy are
> named like the current directory. This does simply not match. Suppose those
> jar artifacts are used in an enterprise or web app. Then every artifact is
> located in one single directory and therefore the names have to be unique.
> But if you decide to take an artifact name different to the directory name,
> you have to add the definition in every POM, because the scm elements are
> simply wrong.
> An even worse scenario are components that can be provided using different
> technologies. We have a lot of such structures:
> * component
> ** jar
> ** war
> ** ear
> * *_jar_:* the core functionality
> * *_war_:* the core functionality integrated and eccessible with a web
> application
> * *_ear_:* the complete component as enterprise app, if it makes sense to
> deploy the functionality on a different app server
> _component_ has a POM of package type _pom_; _jar_, _war_ and _ear_ have POMs
> with the according package type. All of the three POMs use the same
> artifactId though. In this case not only the scm elements break, but also the
> URLs for the site, since they are all the same for all three artifacts.
> All of this could have been avoided, if the expanded part is not the
> artifactId, but the basename of the current directory. Especially for the scm
> elements, this is IMHO the only valid assumption.
> It would already help us, if this auto-expansion could be turned off to allow
> the definition of a single property in each POM for a correct interpolation
> of those values, but there seems no such option ^1^. So you *have to* add
> those elements under all circumstances into every POM.
> 1) The _tagBase_ of the release plugin does no such auto-expansion, which
> makes it quite easy to use a property for it, that can be set individually in
> every POM without adding any plugin configuration.
--
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: (MRELEASE-213) Need ability to access values gathered by maven-release-plugin in Mojos executed as part of preparationGoals element
[ http://jira.codehaus.org/browse/MRELEASE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91996 ] William Ferguson commented on MRELEASE-213: --- Loks like I also need access to the SCM version that has been checked out by the maven-release-plugin for safety. > Need ability to access values gathered by maven-release-plugin in Mojos > executed as part of preparationGoals element > > > Key: MRELEASE-213 > URL: http://jira.codehaus.org/browse/MRELEASE-213 > Project: Maven 2.x Release Plugin > Issue Type: Improvement >Affects Versions: 2.0-beta-4 >Reporter: William Ferguson > > I have a plugin containing a Mojo that needs to be executed as part of the > maven-release-plugin's preparationGoals phase. > The Mojo needs access to some of the information gathered by the > maven-release-plugin. > Namely it needs access to the SCM release tag specified by the user. > The aim of the plugin is to update the subclipse:tags property of the project > being released in a similar manner that the Eclipse/Subversion Subclipse > plugin does. So the information that I need to gather from the > maven-release-plugin is > 1) SCM release tag specified by the user. > 2) Any other SCM details that have been modified for the release plugin. -- 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: (MRELEASE-212) Mojo executed using preparationGoals does not get its parameters populated on execution
[
http://jira.codehaus.org/browse/MRELEASE-212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_91963
]
William Ferguson commented on MRELEASE-212:
---
Thanks Emmanuel - that does allow the property to get passed in.
I was trying to get hold of the value of the dryRun parameter that can be
passed to the maven-release-plugin as I will need to perform different
behaviour depending on whether its a dry run or not - which I expect is typical.
But I think development of my plugin will have to go on hold until
http://jira.codehaus.org/browse/MRELEASE-213 is resolved in some form. I really
need access to the SCM Release tag specified by the user. Is there no way to
retrieve this value via a MavenProject property?
> Mojo executed using preparationGoals does not get its parameters populated on
> execution
> ---
>
> Key: MRELEASE-212
> URL: http://jira.codehaus.org/browse/MRELEASE-212
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
>Affects Versions: 2.0-beta-4
>Reporter: William Ferguson
>
> I have a Mojo with a single String parameter
> /**
>* @parameter expression="${myProp}"
>*/
> private String myProp;
> If this Mojo is executed directly, eg
> mvn myplugin:mygoal -DmyProp=foo
> then the Mojo receives the value of myProp at runtime.
> If my Mojo is executed via maven-release-plugin preparationGoals eg
>
> org.apache.maven.plugins
> maven-release-plugin
>
>
> clean integration-test
> myplugin:mygoal
>
>
>
> the the Mojo is not injected with the value of MyProp at runtime.
> Now this could just be because there is some extra config that I need to do
> that I have missed. I am a Maven newbie.
> But I've followed all the doco for maven-release-plugin as well as anything I
> could find on building plugins.
> So if its my bad, please point me in the right direction.
--
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-213) Need ability to access values gathered by maven-release-plugin in Mojos executed as part of preparationGoals element
Need ability to access values gathered by maven-release-plugin in Mojos executed as part of preparationGoals element Key: MRELEASE-213 URL: http://jira.codehaus.org/browse/MRELEASE-213 Project: Maven 2.x Release Plugin Issue Type: Improvement Affects Versions: 2.0-beta-4 Reporter: William Ferguson I have a plugin containing a Mojo that needs to be executed as part of the maven-release-plugin's preparationGoals phase. The Mojo needs access to some of the information gathered by the maven-release-plugin. Namely it needs access to the SCM release tag specified by the user. The aim of the plugin is to update the subclipse:tags property of the project being released in a similar manner that the Eclipse/Subversion Subclipse plugin does. So the information that I need to gather from the maven-release-plugin is 1) SCM release tag specified by the user. 2) Any other SCM details that have been modified for the release plugin. -- 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-212) Mojo executed using preparationGoals does not get its parameters populated on execution
Mojo executed using preparationGoals does not get its parameters populated on
execution
---
Key: MRELEASE-212
URL: http://jira.codehaus.org/browse/MRELEASE-212
Project: Maven 2.x Release Plugin
Issue Type: Bug
Affects Versions: 2.0-beta-4
Reporter: William Ferguson
I have a Mojo with a single String parameter
/**
* @parameter expression="${myProp}"
*/
private String myProp;
If this Mojo is executed directly, eg
mvn myplugin:mygoal -DmyProp=foo
then the Mojo receives the value of myProp at runtime.
If my Mojo is executed via maven-release-plugin preparationGoals eg
org.apache.maven.plugins
maven-release-plugin
clean integration-test
myplugin:mygoal
the the Mojo is not injected with the value of MyProp at runtime.
Now this could just be because there is some extra config that I need to do
that I have missed. I am a Maven newbie.
But I've followed all the doco for maven-release-plugin as well as anything I
could find on building plugins.
So if its my bad, please point me in the right direction.
--
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: (MNGECLIPSE-124) Plugin fail to initialize when default maven repository folder is not available
[ http://jira.codehaus.org/browse/MNGECLIPSE-124?page=comments#action_78147 ] William Ferguson commented on MNGECLIPSE-124: - Sorry, to be clear - I still the issue in version 0.0.9 > Plugin fail to initialize when default maven repository folder is not > available > --- > > Key: MNGECLIPSE-124 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-124 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.7 > Environment: Windows XP Professional SP2 > JSE v1.5.0-06 > Eclipse 3.2RC4 >Reporter: Douglas WF Acheson > Attachments: .log > > > This is this error when I try to go to the Maven2 preferences : > Plug-in org.maven.ide.eclipse was unable to load class > org.maven.ide.eclipse.preferences.Maven2PreferencePage. > As well, I an not able to associate a project with maven2 when using the RMB > context menu for a project . I get a popup window with the following > The chosen operation is not currently available -- 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: (MNGECLIPSE-124) Plugin fail to initialize when default maven repository folder is not available
[ http://jira.codehaus.org/browse/MNGECLIPSE-124?page=comments#action_78146
]
William Ferguson commented on MNGECLIPSE-124:
-
I still see the issue relating to the embedder not reading the location of the
local repository from the M2_HOME/conf/settings.xml (I have a non-default local
repository to work around a bug in verison 2.2 of the maven-surefire-plugin).
Is any one planning on fixing it?
I've read the discussion in http://jira.codehaus.org/browse/MNGECLIPSE-116 and
there seems to be some confusion over how the local repository should be
determined and/or configured for the plugin.
For mine its
1) If M2_HOME env variable exists, read the values from
M2_HOME/conf/settings.xml
2) Else look for ${user.home}/.m2 (create if necessary) and read from
${user.home}/.m2/settngs.xml
Alternately respect the value of the 'Local Repsotiory Folder' specified in The
Eclipse preferences page for 'Maven2'. Because at the moment this is ignored
too. But I think it would be better to read it from the actual Maven config.
> Plugin fail to initialize when default maven repository folder is not
> available
> ---
>
> Key: MNGECLIPSE-124
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-124
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
>Affects Versions: 0.0.7
> Environment: Windows XP Professional SP2
> JSE v1.5.0-06
> Eclipse 3.2RC4
>Reporter: Douglas WF Acheson
> Attachments: .log
>
>
> This is this error when I try to go to the Maven2 preferences :
> Plug-in org.maven.ide.eclipse was unable to load class
> org.maven.ide.eclipse.preferences.Maven2PreferencePage.
> As well, I an not able to associate a project with maven2 when using the RMB
> context menu for a project . I get a popup window with the following
> The chosen operation is not currently available
--
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: (MSUREFIRE-148) SurefireBooter can initialize classloader with badly formed URLs
[ http://jira.codehaus.org/browse/MSUREFIRE-148?page=comments#action_76940 ] William Ferguson commented on MSUREFIRE-148: I presume that the appropriate work around for this is to move your local repository to somewhere that doesn't have spaces in its path and to change the attributes in settings.xml to point to the new Repository location? That seems to work, but being a Maven newbie I'm not 100% confident. Twoother questions 1) Whats the latest release of the surefire plugin? 2.0 is what is being downloaded to my local repository, but I see references to 2.1 and 2.2 on the mailing list, but I can't seem to get them to download : [INFO] Failed to resolve artifact. GroupId: org.apache.maven.surefire ArtifactId: surefire Version: 2.2 Reason: Unable to download the artifact from any repository org.apache.maven.surefire:surefire:pom:2.2 from the specified remote repositories: central (http://repo1.maven.org/maven2) 2) Whats the estimate for a release of 2.3? > SurefireBooter can initialize classloader with badly formed URLs > > > Key: MSUREFIRE-148 > URL: http://jira.codehaus.org/browse/MSUREFIRE-148 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug >Reporter: Jeremy Boynes > Assigned To: Brett Porter > Fix For: 2.3 > > Attachments: urlEncode.patch > > > In SurefireBooter.createClassLoader() the path is converted to a URL using > File f = new File( url ); > urls.add( f.toURL() ); > File.toURL does not perform URL encoding so the resulting URL may contain > invalid characters. This is an issue on Windows machines where the default > maven repository is in "C:\Documents and Settings\user\.m2\..." (the filename > contains spaces). If a test accesses a resource that is loaded from a > dependency jar then the URL returned to that test is malformed. > With JDK 1.4 this can be fixed using > urls.add( f.toURI().toURL() ); > as toURI() does encode the path. If surefire still needs to run under pre-1.4 > JVMs this would need to be explicitly encoded. I'm willing to supply a patch > for that if wanted. -- 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
