[jira] Closed: (MNG-4991) LegacyRepositorySystem#injectProxy(repositories, proxies) doesn't evaluate non-proxy hosts
[
http://jira.codehaus.org/browse/MNG-4991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4991.
--
Resolution: Fixed
Fix Version/s: 3.0.3
Assignee: Benjamin Bentmann
Fixed in [r1073990|http://svn.apache.org/viewvc?view=revision&revision=1073990].
> LegacyRepositorySystem#injectProxy(repositories, proxies) doesn't evaluate
> non-proxy hosts
> --
>
> Key: MNG-4991
> URL: http://jira.codehaus.org/browse/MNG-4991
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.2
> Environment: Win7 64bit, JDK 1.6 64bit, Maven 3.0.2
>Reporter: Bernd Vogt
>Assignee: Benjamin Bentmann
> Fix For: 3.0.3
>
>
> The method {{LegacyRepositorySystem#injectProxy(List,
> List)}} doesn't evaluate non-proxy host settings.
> Effect: When using this mehtod, each repository will be configured with a
> proxy, even if the related host is excluded via the {{}} tag
> in the _settings.xml_.
--
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: (MDOAP-36) DoapUtil.EMAIL_REGEX too strict (hyphens and underscores in domain components not accepted)
DoapUtil.EMAIL_REGEX too strict (hyphens and underscores in domain components
not accepted)
---
Key: MDOAP-36
URL: http://jira.codehaus.org/browse/MDOAP-36
Project: Maven 2.x DOAP Plugin
Issue Type: Bug
Affects Versions: 1.1
Reporter: Andreas Sewe
Valid email addresses (see http://tools.ietf.org/html/rfc5322#section-3.4.1)
containing underscores or hyphens raise an error:
{quote}
[ERROR] The POM
value is not a valid email.
{quote}
While the RDF is still generated, it doesn't include the email address in
question.
--
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: (MASSEMBLY-510) leading period ('.') added to directory names
[
http://jira.codehaus.org/browse/MASSEMBLY-510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
John Casey closed MASSEMBLY-510.
Resolution: Fixed
Fixed. Unit tests in place to verify that handling of . and .. are handled
correctly. See AssemblyFormatUtilsTest.testFixRelativePathRefs_*
> leading period ('.') added to directory names
> -
>
> Key: MASSEMBLY-510
> URL: http://jira.codehaus.org/browse/MASSEMBLY-510
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP, SP3
> Maven 2.2.1
> Maven Assembly 2.2
>Reporter: KP
>Assignee: John Casey
> Fix For: 2.2.1
>
> Attachments: dist.xml, pom.xml
>
>
> $ cat dist.xml
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
> http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
> dist
>
> zip
>
>
>
>
>
> ${project.basedir}/../paper
>
>
> ${project.basedir}/../boots
>
>
>
>
> $ mvn clean assembly:assembly
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building oracle-sql-assembly
> [INFO]task-segment: [clean]
> [INFO]
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] Deleting directory F:\test-assembly\target
> [INFO]
>
> [INFO] Building oracle-sql-assembly
> [INFO]task-segment: [assembly:assembly] (aggregator-style)
> [INFO]
>
> [INFO] Preparing assembly:assembly
> [INFO]
>
> [INFO] Building oracle-sql-assembly
> [INFO]
>
> [INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
> [INFO] [assembly:assembly {execution: default-cli}]
> [INFO] Reading assembly descriptor: src/main/assembly/dist.xml
> [INFO] Building zip:
> F:\test-assembly\target\test-assembly-3.1-SNAPSHOT-dist.zip
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Mon Oct 11 15:34:37 EDT 2010
> [INFO] Final Memory: 18M/45M
> [INFO]
>
> $ unzip -l target/test-assembly-dist.zip
> Archive: target/test-assembly-dist.zip
> Length DateTimeName
> - -- -
> 0 10-11-2010 15:34 test-assembly/
> 0 10-11-2010 15:27 test-assembly/.paper/
> 0 10-11-2010 15:27 test-assembly/.paper/random.txt
> 0 10-11-2010 15:27 test-assembly/.boots/
> 0 10-11-2010 15:27 test-assembly/.boots/boots.txt
> - ---
> 0 5 files
> Do you notice the '.paper' and '.boots' directories? It should just be
> 'paper' and 'boots', if I'm understanding it correctly.
> I tried other versions of the plugin (e.g., beta-4), I tried removing
> "${project.basedir}/".
> No go. :(
> P.S. If someone points me in the right direction, like a class name, I'll
> write a test case.
--
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: (MASSEMBLY-510) leading period ('.') added to directory names
[
http://jira.codehaus.org/browse/MASSEMBLY-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257513#action_257513
]
John Casey commented on MASSEMBLY-510:
--
working on it right now. Hopefully, it's fixed, but the ITs will tell... :-)
> leading period ('.') added to directory names
> -
>
> Key: MASSEMBLY-510
> URL: http://jira.codehaus.org/browse/MASSEMBLY-510
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP, SP3
> Maven 2.2.1
> Maven Assembly 2.2
>Reporter: KP
>Assignee: John Casey
> Fix For: 2.2.1
>
> Attachments: dist.xml, pom.xml
>
>
> $ cat dist.xml
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
> http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
> dist
>
> zip
>
>
>
>
>
> ${project.basedir}/../paper
>
>
> ${project.basedir}/../boots
>
>
>
>
> $ mvn clean assembly:assembly
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building oracle-sql-assembly
> [INFO]task-segment: [clean]
> [INFO]
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] Deleting directory F:\test-assembly\target
> [INFO]
>
> [INFO] Building oracle-sql-assembly
> [INFO]task-segment: [assembly:assembly] (aggregator-style)
> [INFO]
>
> [INFO] Preparing assembly:assembly
> [INFO]
>
> [INFO] Building oracle-sql-assembly
> [INFO]
>
> [INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
> [INFO] [assembly:assembly {execution: default-cli}]
> [INFO] Reading assembly descriptor: src/main/assembly/dist.xml
> [INFO] Building zip:
> F:\test-assembly\target\test-assembly-3.1-SNAPSHOT-dist.zip
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Mon Oct 11 15:34:37 EDT 2010
> [INFO] Final Memory: 18M/45M
> [INFO]
>
> $ unzip -l target/test-assembly-dist.zip
> Archive: target/test-assembly-dist.zip
> Length DateTimeName
> - -- -
> 0 10-11-2010 15:34 test-assembly/
> 0 10-11-2010 15:27 test-assembly/.paper/
> 0 10-11-2010 15:27 test-assembly/.paper/random.txt
> 0 10-11-2010 15:27 test-assembly/.boots/
> 0 10-11-2010 15:27 test-assembly/.boots/boots.txt
> - ---
> 0 5 files
> Do you notice the '.paper' and '.boots' directories? It should just be
> 'paper' and 'boots', if I'm understanding it correctly.
> I tried other versions of the plugin (e.g., beta-4), I tried removing
> "${project.basedir}/".
> No go. :(
> P.S. If someone points me in the right direction, like a class name, I'll
> write a test case.
--
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: (MNG-4990) RepositorySystem#resolve(request) uses two different local repositories
[
http://jira.codehaus.org/browse/MNG-4990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4990.
--
Resolution: Fixed
Fix Version/s: 3.0.3
Assignee: Benjamin Bentmann
Fixed in [r1073928|http://svn.apache.org/viewvc?view=revision&revision=1073928].
> RepositorySystem#resolve(request) uses two different local repositories
> ---
>
> Key: MNG-4990
> URL: http://jira.codehaus.org/browse/MNG-4990
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.2
> Environment: Win7 64bit, JDK 1.6.0_21 64bit, Maven 3.0.2
>Reporter: Bernd Vogt
>Assignee: Benjamin Bentmann
> Fix For: 3.0.3
>
>
> {{RepositorySystem#resolve(ArtifactResolutionRequest)}} doesn't use the local
> repository passed in via the resolution request as target for metadata
> downloads (pom.xml). It uses the local repository from the settings.xml
> instead.
> Current behaviour:
> After the resolution process there are only the jar file (and their
> checksums) contained in the "custom" local repository that was set via the
> resolution request. The pom and parent pom files (and their checksums) could
> be found in the "global" local repository (configured via settings.xml).
> Expected:
> After the resolution process the whole stuff is contained in the "custom"
> local repository, the "global" one wasn't touched.
--
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: (MASSEMBLY-510) leading period ('.') added to directory names
[
http://jira.codehaus.org/browse/MASSEMBLY-510?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257497#action_257497
]
Dennis Lundberg commented on MASSEMBLY-510:
---
John, do you think you have time to fix this?
It's the last issue left in the 2.2.1 release.
If you don't have time right now, I'll just push it to the next release.
> leading period ('.') added to directory names
> -
>
> Key: MASSEMBLY-510
> URL: http://jira.codehaus.org/browse/MASSEMBLY-510
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP, SP3
> Maven 2.2.1
> Maven Assembly 2.2
>Reporter: KP
>Assignee: John Casey
> Fix For: 2.2.1
>
> Attachments: dist.xml, pom.xml
>
>
> $ cat dist.xml
> xmlns="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/plugins/maven-assembly-plugin/assembly/1.1.0
> http://maven.apache.org/xsd/assembly-1.1.0.xsd";>
> dist
>
> zip
>
>
>
>
>
> ${project.basedir}/../paper
>
>
> ${project.basedir}/../boots
>
>
>
>
> $ mvn clean assembly:assembly
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building oracle-sql-assembly
> [INFO]task-segment: [clean]
> [INFO]
>
> [INFO] [clean:clean {execution: default-clean}]
> [INFO] Deleting directory F:\test-assembly\target
> [INFO]
>
> [INFO] Building oracle-sql-assembly
> [INFO]task-segment: [assembly:assembly] (aggregator-style)
> [INFO]
>
> [INFO] Preparing assembly:assembly
> [INFO]
>
> [INFO] Building oracle-sql-assembly
> [INFO]
>
> [INFO] [site:attach-descriptor {execution: default-attach-descriptor}]
> [INFO] [assembly:assembly {execution: default-cli}]
> [INFO] Reading assembly descriptor: src/main/assembly/dist.xml
> [INFO] Building zip:
> F:\test-assembly\target\test-assembly-3.1-SNAPSHOT-dist.zip
> [INFO]
>
> [INFO] BUILD SUCCESSFUL
> [INFO]
>
> [INFO] Total time: 2 seconds
> [INFO] Finished at: Mon Oct 11 15:34:37 EDT 2010
> [INFO] Final Memory: 18M/45M
> [INFO]
>
> $ unzip -l target/test-assembly-dist.zip
> Archive: target/test-assembly-dist.zip
> Length DateTimeName
> - -- -
> 0 10-11-2010 15:34 test-assembly/
> 0 10-11-2010 15:27 test-assembly/.paper/
> 0 10-11-2010 15:27 test-assembly/.paper/random.txt
> 0 10-11-2010 15:27 test-assembly/.boots/
> 0 10-11-2010 15:27 test-assembly/.boots/boots.txt
> - ---
> 0 5 files
> Do you notice the '.paper' and '.boots' directories? It should just be
> 'paper' and 'boots', if I'm understanding it correctly.
> I tried other versions of the plugin (e.g., beta-4), I tried removing
> "${project.basedir}/".
> No go. :(
> P.S. If someone points me in the right direction, like a class name, I'll
> write a test case.
--
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: (SUREFIRE-577) running only some method of a unit class (with -Dtest=MyClass#myMethod)
[ http://jira.codehaus.org/browse/SUREFIRE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257470#action_257470 ] Olivier Lamy edited comment on SUREFIRE-577 at 2/23/11 12:19 PM: - some stuff started here : https://github.com/olamy/maven-surefire works with junit 4.x was (Author: olamy): some stuff started here : https://github.com/olamy/maven-surefire > running only some method of a unit class (with -Dtest=MyClass#myMethod) > --- > > Key: SUREFIRE-577 > URL: http://jira.codehaus.org/browse/SUREFIRE-577 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Olivier Lamy >Assignee: Olivier Lamy > > I definitely don't know if it's possible with junit. > But it's an idea, I have now :-). -- 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: (SUREFIRE-577) running only some method of a unit class (with -Dtest=MyClass#myMethod)
[ http://jira.codehaus.org/browse/SUREFIRE-577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257470#action_257470 ] Olivier Lamy commented on SUREFIRE-577: --- some stuff started here : https://github.com/olamy/maven-surefire > running only some method of a unit class (with -Dtest=MyClass#myMethod) > --- > > Key: SUREFIRE-577 > URL: http://jira.codehaus.org/browse/SUREFIRE-577 > Project: Maven Surefire > Issue Type: New Feature > Components: Maven Surefire Plugin >Reporter: Olivier Lamy >Assignee: Olivier Lamy > > I definitely don't know if it's possible with junit. > But it's an idea, I have now :-). -- 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: (MNG-5008) resolution of concurrent SNAPSHOT artifacts from multiple repositories should use timestamp instead of buildNumber
[ http://jira.codehaus.org/browse/MNG-5008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-5008. -- Resolution: Incomplete Assignee: Benjamin Bentmann SNAPSHOTs are already resolved based on the metadata timestamp and this report does not include enough information to isolate a faulty code path. Feel free to reopen with an example project that actually shows the defect you describe. > resolution of concurrent SNAPSHOT artifacts from multiple repositories should > use timestamp instead of buildNumber > --- > > Key: MNG-5008 > URL: http://jira.codehaus.org/browse/MNG-5008 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.2.1, 3.0.1 >Reporter: Julien CARSIQUE >Assignee: Benjamin Bentmann > > When getting a SNAPSHOT artifact from multiple repositories, Maven must > choose the more recent one. Using buildNumber is useless and meaningless as > the two repositories have separate incrementation of their buildNumber. > For example, retrieving the two following metadata: > > org.nuxeo.runtime > nuxeo-runtime-parent > 5.4.1-SNAPSHOT > > > 20110202.045408 > 48 > > 20110202045420 > > > > org.nuxeo.runtime > nuxeo-runtime-parent > 5.4.1-SNAPSHOT > > > 20110206.141840 > 18 > > 20110206141840 > > > As you can see, the snapshot artifact with timestamp 20110206.141840 is more > recent than the one with timestamp 20110202.045408. > But when parsing the POM, comparing metadata, the oldest artifact will be > downloaded. > I saw that issue raised on Jenkins which uses Maven API. Last year, I've > encountered the same issue with Nexus (also using Maven API) for which a > workaround was easily done as Nexus aggregates information from multiple > repositories. Such workaround may not be possible in Jenkins, or when > directly building with Maven. That need to be fixed in the Maven API. > I guess it comes from > http://svn.apache.org/viewvc/maven/maven-3/tags/maven-3.0.2/maven-artifact/src/main/java/org/apache/maven/artifact/versioning/DefaultArtifactVersion.java?view=markup -- 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: (MNG-4987) [regression] LATEST, RELEASE or SNAPSHOT version picked from wrong repository when resolution order does not match timestamp order
[
http://jira.codehaus.org/browse/MNG-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4987.
--
Resolution: Fixed
Fix Version/s: 3.0.3
Assignee: Benjamin Bentmann
Good catch, fixed in
[1073807|http://svn.apache.org/viewvc?view=revision&revision=1073807], and
given SNAPSHOT resolution is also affected, we can safely call this a major bug.
> [regression] LATEST, RELEASE or SNAPSHOT version picked from wrong repository
> when resolution order does not match timestamp order
> --
>
> Key: MNG-4987
> URL: http://jira.codehaus.org/browse/MNG-4987
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.2
> Environment: Ubuntu 10.10
>Reporter: Michael Hartmeier
>Assignee: Benjamin Bentmann
> Fix For: 3.0.3
>
>
> In maven-aether-provider 3.0.2, DefaultVersionResolver, line 378ff says
> {noformat}
> private void merge( String key, Map infos, String
> timestamp, String version,
> ArtifactRepository repository )
> {
> VersionInfo info = infos.get( key );
> if ( info == null )
> {
> info = new VersionInfo( timestamp, version, repository );
> infos.put( key, info );
> }
> else if ( info.isOutdated( timestamp ) )
> {
> info.version = version;
> info.repository = repository;
> }
> }
> {noformat}
> If I understand correctly, you should add
>
> {noformat}
> info.timestamp = timestamp
> {noformat}
> to the else part. Otherwise, you'll use a wrong timestamp in future calls to
> this method.
--
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: (MNG-4987) [regression] LATEST, RELEASE or SNAPSHOT version picked from wrong repository when resolution order does not match timestamp order
[
http://jira.codehaus.org/browse/MNG-4987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4987:
---
Summary: [regression] LATEST, RELEASE or SNAPSHOT version picked from wrong
repository when resolution order does not match timestamp order (was: LATEST
or RELEASE version picked from wrong repository metadata.xml)
> [regression] LATEST, RELEASE or SNAPSHOT version picked from wrong repository
> when resolution order does not match timestamp order
> --
>
> Key: MNG-4987
> URL: http://jira.codehaus.org/browse/MNG-4987
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 3.0.2
> Environment: Ubuntu 10.10
>Reporter: Michael Hartmeier
>
> In maven-aether-provider 3.0.2, DefaultVersionResolver, line 378ff says
> {noformat}
> private void merge( String key, Map infos, String
> timestamp, String version,
> ArtifactRepository repository )
> {
> VersionInfo info = infos.get( key );
> if ( info == null )
> {
> info = new VersionInfo( timestamp, version, repository );
> infos.put( key, info );
> }
> else if ( info.isOutdated( timestamp ) )
> {
> info.version = version;
> info.repository = repository;
> }
> }
> {noformat}
> If I understand correctly, you should add
>
> {noformat}
> info.timestamp = timestamp
> {noformat}
> to the else part. Otherwise, you'll use a wrong timestamp in future calls to
> this method.
--
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: (MDEPLOY-129) Need a way to specify repository credentials securely for deploy operations
[ http://jira.codehaus.org/browse/MDEPLOY-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257460#action_257460 ] Benjamin Bentmann commented on MDEPLOY-129: --- http://maven.apache.org/guides/mini/guide-encryption.html > Need a way to specify repository credentials securely for deploy operations > --- > > Key: MDEPLOY-129 > URL: http://jira.codehaus.org/browse/MDEPLOY-129 > Project: Maven 2.x Deploy Plugin > Issue Type: New Feature > Components: deploy:deploy-file >Affects Versions: 2.4, 2.5 > Environment: All >Reporter: Rick Herrick > > Currently, credentials for performing a deployment must be specified in the > settings.xml. However, if a Maven repository is set to use LDAP for its > authentication mechanism, this means exposing domain security credentials in > plaintext in a static file on the hard drive and is _extremely_ insecure (as > specified in the documentation: "Unfortunately, Maven doesn't currently > support hashed or encrypted passwords in the settings.xml"). This is simply > not workable in a secure environment, e.g. government, defense, financial, > etc. > Instead there should be an option to provide these credentials on the command > line or using hash or encryption algorithms. -- 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: (MDEPLOY-129) Need a way to specify repository credentials securely for deploy operations
Need a way to specify repository credentials securely for deploy operations --- Key: MDEPLOY-129 URL: http://jira.codehaus.org/browse/MDEPLOY-129 Project: Maven 2.x Deploy Plugin Issue Type: New Feature Components: deploy:deploy-file Affects Versions: 2.5, 2.4 Environment: All Reporter: Rick Herrick Currently, credentials for performing a deployment must be specified in the settings.xml. However, if a Maven repository is set to use LDAP for its authentication mechanism, this means exposing domain security credentials in plaintext in a static file on the hard drive and is _extremely_ insecure (as specified in the documentation: "Unfortunately, Maven doesn't currently support hashed or encrypted passwords in the settings.xml"). This is simply not workable in a secure environment, e.g. government, defense, financial, etc. Instead there should be an option to provide these credentials on the command line or using hash or encryption algorithms. -- 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: (SUREFIRE-705) Setting both "forkedProcessTimeoutInSeconds" and "parallel" fails with an exception
Setting both "forkedProcessTimeoutInSeconds" and "parallel" fails with an
exception
---
Key: SUREFIRE-705
URL: http://jira.codehaus.org/browse/SUREFIRE-705
Project: Maven Surefire
Issue Type: Bug
Components: Junit 4.7+ (parallel) support, process forking
Affects Versions: 2.7.2
Environment: OS X
Reporter: Jari Aarniala
Setting forkedProcessTimeoutInSeconds to a non-zero value and having parallel
set throws an exception. Is this not supported?
Reproducible with a minimal pom.xml:
{code}
http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/xsd/maven-4.0.0.xsd";>
4.0.0
my.groupId
my-archetype-id
1.0-SNAPSHOT
jar
junit
junit
4.8.2
test
org.apache.maven.plugins
maven-surefire-plugin
2.7.2
1
classes
10
{code}
Stack trace:
{code}
---
T E S T S
---
Concurrency config is parallel='classes', perCoreThreadCount=true,
threadCount=10, useUnlimitedThreads=false
java.lang.reflect.UndeclaredThrowableException
at $Proxy0.invoke(Unknown Source)
at
org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:150)
at
org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcess(SurefireStarter.java:91)
at
org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:69)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at
org.apache.maven.surefire.booter.ProviderFactory$ClassLoaderProxy.invoke(ProviderFactory.java:103)
... 4 more
Caused by: java.lang.IllegalStateException: Task already scheduled or cancelled
at java.util.Timer.sched(Timer.java:358)
at java.util.Timer.schedule(Timer.java:170)
at
org.apache.maven.surefire.report.ReporterManagerFactory.startTimer(ReporterManagerFactory.java:206)
at
org.apache.maven.surefire.report.ReporterManagerFactory.createReporter(ReporterManagerFactory.java:105)
at
org.apache.maven.surefire.junitcore.ConcurrentReporterManager.(ConcurrentReporterManager.java:64)
at
org.apache.maven.surefire.junitcore.ClassesParallelRunListener.(ClassesParallelRunListener.java:38)
at
org.apache.maven.surefire.junitcore.ConcurrentReporterManager.createInstance(ConcurrentReporterManager.java:209)
at
org.apache.maven.surefire.junitcore.JUnitCoreProvider.invoke(JUnitCoreProvider.java:101)
... 9 more
{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] Reopened: (MDEPLOY-48) deploy:deploy-file does not support deploying sources jars too
[ http://jira.codehaus.org/browse/MDEPLOY-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Gier reopened MDEPLOY-48: -- Reopening for some additional changes > deploy:deploy-file does not support deploying sources jars too > -- > > Key: MDEPLOY-48 > URL: http://jira.codehaus.org/browse/MDEPLOY-48 > Project: Maven 2.x Deploy Plugin > Issue Type: Improvement >Affects Versions: 2.3 >Reporter: Geoffrey De Smet >Assignee: Paul Gier > Fix For: 2.6 > > > deploy:deploy does, but deploy:deploy-file doesn't have a parameter to tell > him where the sources jar is: > mvn deploy:deploy-file -Dfile=$artifactFile -DpomFile=$pomFile -Durl=$toRepo -- 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: (MNG-5024) Update default plugin versions
[ http://jira.codehaus.org/browse/MNG-5024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-5024. -- Resolution: Fixed Fix Version/s: 3.0.3 Assignee: Benjamin Bentmann Updated to maven-surefire-plugin:2.7.2, maven-plugin-plugin:2.7 and maven-ear-plugin:2.5 in [r1073753|http://svn.apache.org/viewvc?view=revision&revision=1073753]. > Update default plugin versions > -- > > Key: MNG-5024 > URL: http://jira.codehaus.org/browse/MNG-5024 > Project: Maven 2 & 3 > Issue Type: Task > Components: Plugins and Lifecycle >Affects Versions: 3.0.2 >Reporter: Benjamin Bentmann >Assignee: Benjamin Bentmann >Priority: Trivial > Fix For: 3.0.3 > > > Maven 3.0.2 currently defaults to surefire:2.7.1. Since then, surefire:2.7.2 > has been released by Kristian and is the better default version. -- 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-4792) Preemptive authentication doesn't work
[
http://jira.codehaus.org/browse/MNG-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257442#action_257442
]
Tarjei Skorgenes edited comment on MNG-4792 at 2/23/11 8:14 AM:
Having hit the same problem as you I've come to the conclusion that there are
multiple layers of problems here that hinders preemptive authentication from
working:
1) The configuration listed in [1] is never injected into the
HttpMethodConfiguration-objects created by Plexus during configuration of
HttpWagon. This is caused by the fact that the params-field in
HttpMethodConfiguration is of type Properties and PropertiesConverter does not
recognize the param-element. Replacing param with property fixes this part of
the problem:
{code:xml}
httpclient
http.authentication.preemptive
%b,true
{code}
2) Once properly configured Http Client ignores the preemptive-parameter
completely. This is caused by the fact that the check for preemptive
authentication in HTTP Client's HttpMethodDirector (line 158) is not performed
on the PutMethod-object. The check is done one the HttpClientParams-object and
this one has not been configured by HttpWagon to include any information about
preemptive-auth.
was (Author: lothor):
Having hit the same problem as you I've come to the conclusion that there
are multiple layers of problems here that hinders preemptive authentication
from working:
1) The configuration listed in [1] is never injected into the
HttpMethodConfiguration-objects created by Plexus during configuration of
HttpWagon. This is caused by the fact that the params-field in
HttpMethodConfiguration is of type Properties and PropertiesConverter does not
recognize the param-element. Replacing param with property fixes this part of
the problem:
{code:xml}
httpclienthttp.authentication.preemptive%b,true
{code}
2) Once properly configured Http Client ignores the preemptive-parameter
completely. This is caused by the fact that the check for preemptive
authentication in HTTP Client's HttpMethodDirector (line 158) is not performed
on the PutMethod-object. The check is done one the HttpClientParams-object and
this one has not been configured by HttpWagon to include any information about
preemptive-auth.
> Preemptive authentication doesn't work
> --
>
> Key: MNG-4792
> URL: http://jira.codehaus.org/browse/MNG-4792
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.2.1
> Environment: Sun Java 1.6.0_21, Windows 7
>Reporter: Marcin Zajaczkowski
>
> It seems preemptive authentication in Maven using httpclient wagon provider
> doesn't work. With configuration taken form [1] Maven knock to repository
> (tested with Artifactory 2.2.5) as anonymous user.
>
> repo-id
> user
> pass
>
> httpclient
>
>
>
>
> http.authentication.preemptive
> %b,true
>
>
>
>
>
>
> Confirmed by independent party also with Maven 2.2.1. I can sniff http
> traffic if needed.
> [1] - http://maven.apache.org/guides/mini/guide-http-settings.html
--
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-4792) Preemptive authentication doesn't work
[
http://jira.codehaus.org/browse/MNG-4792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257442#action_257442
]
Tarjei Skorgenes commented on MNG-4792:
---
Having hit the same problem as you I've come to the conclusion that there are
multiple layers of problems here that hinders preemptive authentication from
working:
1) The configuration listed in [1] is never injected into the
HttpMethodConfiguration-objects created by Plexus during configuration of
HttpWagon. This is caused by the fact that the params-field in
HttpMethodConfiguration is of type Properties and PropertiesConverter does not
recognize the param-element. Replacing param with property fixes this part of
the problem:
{code:xml}
httpclienthttp.authentication.preemptive%b,true
{code}
2) Once properly configured Http Client ignores the preemptive-parameter
completely. This is caused by the fact that the check for preemptive
authentication in HTTP Client's HttpMethodDirector (line 158) is not performed
on the PutMethod-object. The check is done one the HttpClientParams-object and
this one has not been configured by HttpWagon to include any information about
preemptive-auth.
> Preemptive authentication doesn't work
> --
>
> Key: MNG-4792
> URL: http://jira.codehaus.org/browse/MNG-4792
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.2.1
> Environment: Sun Java 1.6.0_21, Windows 7
>Reporter: Marcin Zajaczkowski
>
> It seems preemptive authentication in Maven using httpclient wagon provider
> doesn't work. With configuration taken form [1] Maven knock to repository
> (tested with Artifactory 2.2.5) as anonymous user.
>
> repo-id
> user
> pass
>
> httpclient
>
>
>
>
> http.authentication.preemptive
> %b,true
>
>
>
>
>
>
> Confirmed by independent party also with Maven 2.2.1. I can sniff http
> traffic if needed.
> [1] - http://maven.apache.org/guides/mini/guide-http-settings.html
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5024) Update default plugin versions
Update default plugin versions -- Key: MNG-5024 URL: http://jira.codehaus.org/browse/MNG-5024 Project: Maven 2 & 3 Issue Type: Task Components: Plugins and Lifecycle Affects Versions: 3.0.2 Reporter: Benjamin Bentmann Priority: Trivial Maven 3.0.2 currently defaults to surefire:2.7.1. Since then, surefire:2.7.2 has been released by Kristian and is the better default version. -- 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: (MCHANGELOG-119) Add possibility to disable displaying file and file revision information on report
Add possibility to disable displaying file and file revision information on report -- Key: MCHANGELOG-119 URL: http://jira.codehaus.org/browse/MCHANGELOG-119 Project: Maven 2.x Changelog Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Ivan Mrva Attachments: changelog-disable-file-and-rev-info.diff, sample-report-with-disabled-file-and-rev-info.png Sometimes, it is better to not display all the information on the HTML report, such as file and file revision information, which makes the report unnecessarily long and less readable. For example, in our company, we would like to use this report as a changelog not only for developers, but also for testers, etc., who really don't care about concrete changed files and their revisions. This feature is especially useful, if used in connection with feature described in MCHANGELOG-118. I am submitting a very simple patch that implements this feature by providing one new configuration parameter: * *displayFileAndRevInfo* - If true, file and file revision information is displayed for each SCM entry. ** default value: true - so current behavior of report generation will not be changed, unless explicitly specified in configuration Patch also contains integration tests that test if report is created, if this param is used. Example report without file and file revision information is displayed on attached screenshot. -- 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: (MNG-4982) [regression] Cycle between transitive dependencies causes bad effective dependency scope
[
http://jira.codehaus.org/browse/MNG-4982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4982:
---
Fix Version/s: 3.0.3
> [regression] Cycle between transitive dependencies causes bad effective
> dependency scope
>
>
> Key: MNG-4982
> URL: http://jira.codehaus.org/browse/MNG-4982
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
> Environment: Apache Maven 3.0.2 (r1056850; 2011-01-09 10:58:10+1000)
> Java version: 1.6.0_17, vendor: Sun Microsystems Inc.
> Java home: D:\Program Files\Java\jdk1.6.0_17\jre
> Default locale: en_AU, platform encoding: Cp1252
> OS name: "windows 7", version: "6.1", arch: "x86", family: "windows"
> Apache Maven 2.2.1 (r801777; 2009-08-07 05:16:01+1000)
> Java version: 1.6.0_17
> Java home: D:\Program Files\Java\jdk1.6.0_17\jre
> Default locale: en_AU, platform encoding: Cp1252
> OS name: "windows 7" version: "6.1" arch: "x86" Family: "windows"
>Reporter: Renato Garcia
> Fix For: 3.0.3
>
> Attachments: test-projects.zip
>
>
> I'm getting different transitive dependency scope resolution when building
> with Maven 3. Transitive dependencies from a *provided* scope should be
> resolved to *provided* according to the
> [docs|http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html#Dependency_Scope],
> but it is resolving to *compile* as shown below. When building with Maven 2
> it works correctly.
> I tried to isolate the problem with a simpler scenario, but could only
> reproduce using the *org.apache.xmlgraphics:fop:jar:1.0* dependency.
> Maven 3 dependency output snippet:
> {noformat}
> [DEBUG] test:a:jar:1
> [DEBUG]test:a-deps:pom:1:provided
> [DEBUG] org.apache.xmlgraphics:fop:jar:1.0:provided
> [DEBUG] org.apache.xmlgraphics:xmlgraphics-commons:jar:1.4:provided
> [DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-anim:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-css:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-dom:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-parser:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-util:jar:1.7:compile
> [DEBUG] xml-apis:xml-apis:jar:1.3.04:compile
> [DEBUG] xml-apis:xml-apis-ext:jar:1.3.04:compile
> [DEBUG] org.apache.xmlgraphics:batik-bridge:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-script:jar:1.7:provided
> [DEBUG]org.apache.xmlgraphics:batik-js:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-xml:jar:1.7:compile
> [DEBUG] xalan:xalan:jar:2.6.0:compile
> [DEBUG] org.apache.xmlgraphics:batik-awt-util:jar:1.7:compile
> [DEBUG] org.apache.xmlgraphics:batik-gvt:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-transcoder:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-svggen:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-extension:jar:1.7:provided
> [DEBUG] org.apache.xmlgraphics:batik-ext:jar:1.7:compile
> [DEBUG] commons-logging:commons-logging:jar:1.0.4:provided
> [DEBUG] commons-io:commons-io:jar:1.3.1:provided
> [DEBUG]
> org.apache.avalon.framework:avalon-framework-api:jar:4.3.1:provided
> [DEBUG]
> org.apache.avalon.framework:avalon-framework-impl:jar:4.3.1:provided
> {noformat}
> Maven 2 dependency output:
> {noformat}
> [DEBUG] test:a:jar:1 (selected for null)
> [DEBUG] test:a-deps:pom:1:provided (selected for provided)
> [DEBUG] org.apache.xmlgraphics:fop:jar:1.0:provided (selected for
> provided)
> [DEBUG] org.apache.xmlgraphics:xmlgraphics-commons:jar:1.4:provided
> (selected for provided)
> [DEBUG] commons-io:commons-io:jar:1.3.1:provided (selected for
> provided)
> [DEBUG] commons-logging:commons-logging:jar:1.0.4:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-svg-dom:jar:1.7:provided
> (removed - causes a cycle in the graph)
> [DEBUG] org.apache.xmlgraphics:batik-anim:jar:1.7:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-awt-util:jar:1.7:provided
> (selected for provided)
> [DEBUG] org.apache.xmlgraphics:batik-util:jar:1.7:provided
> (selected for provided)
> [DEBUG] org.apache.xmlgraphics:batik-dom:jar:1.7:provided (selected
> for provided)
> [DEBUG] org.apache.xmlgraphics:batik-css:jar:1.7:provided
> (selected for provided)
> [DE
[jira] Updated: (MNG-5006) [regression] Resolution of parent POMs for dependency using version range does not consider all configured repositories
[ http://jira.codehaus.org/browse/MNG-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-5006: --- Fix Version/s: 3.0.3 > [regression] Resolution of parent POMs for dependency using version range > does not consider all configured repositories > --- > > Key: MNG-5006 > URL: http://jira.codehaus.org/browse/MNG-5006 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: WinXP SP3, Java 6u20 >Reporter: Kristoffer Peterhansel > Fix For: 3.0.3 > > Attachments: maven-version-range-test.zip, > maven-version-range-test2.zip, mvn-verify-fixed-version.log, > mvn-verify-offline.log, mvn-verify-range-version.log > > > I have a bit of a strange issue. When running under Maven 3.0.2 I am getting > build errors when I try to build one of our projects when one of their > dependencies have a range version. But when setting it to a specific version > it seems to work. The same project works without a hitch in Maven 2.2.1. > As can be seen from the first included verbose trace > (mvn-verify-range-version.log). Maven attempts to get the pom from our > snapshot repository. That will, obviously, not work for a released artefact. > Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems > to skip that step completely. Even though it resolves to the same version in > the end. As seen in the other verbose trace (mvn-verify-fixed-version.log) -- 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: (MNG-5006) [regression] Resolution of parent POMs for dependency using version range does not consider all configured repositories
[ http://jira.codehaus.org/browse/MNG-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann updated MNG-5006: --- Summary: [regression] Resolution of parent POMs for dependency using version range does not consider all configured repositories (was: M3 attempts to get released parent pom from snapshot repository when a dependency has range) > [regression] Resolution of parent POMs for dependency using version range > does not consider all configured repositories > --- > > Key: MNG-5006 > URL: http://jira.codehaus.org/browse/MNG-5006 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: WinXP SP3, Java 6u20 >Reporter: Kristoffer Peterhansel > Attachments: maven-version-range-test.zip, > maven-version-range-test2.zip, mvn-verify-fixed-version.log, > mvn-verify-offline.log, mvn-verify-range-version.log > > > I have a bit of a strange issue. When running under Maven 3.0.2 I am getting > build errors when I try to build one of our projects when one of their > dependencies have a range version. But when setting it to a specific version > it seems to work. The same project works without a hitch in Maven 2.2.1. > As can be seen from the first included verbose trace > (mvn-verify-range-version.log). Maven attempts to get the pom from our > snapshot repository. That will, obviously, not work for a released artefact. > Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems > to skip that step completely. Even though it resolves to the same version in > the end. As seen in the other verbose trace (mvn-verify-fixed-version.log) -- 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: (MCHANGELOG-118) Provide simple sorting based on the content of SCM commit messages on the HTML report.
[ http://jira.codehaus.org/browse/MCHANGELOG-118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Mrva updated MCHANGELOG-118: - Attachment: changelog-sorting-without-file-and-rev-links.png This feature could be more powerful in connection with 'disabled file and revision links' on the HTML report. That would lead to even more readable change log report (see how would it look like: attached sample "*changelog-without-file-and-rev-links.png*" file). For us, this another feature is also required, because we would like to use this report also for our testers, who really don't care about exact set of changed files. I will provide another patch for this kind of functionality (disabling file and revision links) in another JIRA issue in a while... > Provide simple sorting based on the content of SCM commit messages on the > HTML report. > -- > > Key: MCHANGELOG-118 > URL: http://jira.codehaus.org/browse/MCHANGELOG-118 > Project: Maven 2.x Changelog Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Ivan Mrva >Priority: Minor > Attachments: changelog-sorting-comment.diff, > changelog-sorting-without-file-and-rev-links.png, sample-sorted-report.png > > > Purpose: > In our company we have a 'pre-commit' hook script set up for all projects, > that requires from developers to fulfill some formatting rules of SCM commit > message. We would like to leverage from this rules and reflect them also on > the HTML change log to have a more comprendious and well-arranged change log > report. We would like to have commit messages sorted and placed in several > additional columns (instead of having them all in one 'Detail' column) in a > table on HTML report based on their format and content. > Example: > Suppose you want to divide SCM entries displayed on HTML report into four > columns labeled as "Bug fixes", "Features", "Improvements" and "Other > changes" in this order. Commit messages that contain at the beginning of the > line string "[B]" shall be placed in the "Bug fixes" column, messages with > "[F]" at the beginning shall come in the "Features" column, and messages with > "[I]" shall come in the "Improvements" column. All other messages shall > reside in the last "Other changes" column. > To see an example of how can such customized report look like, see screenshot > added as attachment (*sample-sorted-report.png*). > I implemented a patch (see *changelog-sorting-comment.diff*) that contains > logic that performs sorting of SCM entries as described above and I did it in > a general way, so that other users of changelog-plugin can define their own > rules for sorting messages. So, with my implementation, you can customize > report layout as described in above example by providing three new plugin > configuration parameters: > * *commentSortRegexPattern*=^[[BFI]] > ** Standard java regex pattern that is used for searching a match in commit > messages. > ** In this case, it matches commit messages that begin with "[B]", "[F]" or > "[I]" string > * *commentSortMatchValues*=[B],[F],[I] > ** Possible values of result of matches found by above pattern. > ** Used to determine number and order of newly created columns. Also defines > which message is placed into which column (messages with [B] at the beginning > will be placed in the first column, [F] in the second column, and so on ...). > * *commentSortColumnHeaders*=Bug fixes,Features,Improvements,Other changes > ** Header titles for newly created columns. > ** They matches the order and number of 'commentSortMatchValues' values, but > with one last additional value that is used as a header title for last > column, where all 'unsorted' messages will be placed. > Complete documentation of these parameters is included in my implementation > as javadoc. > What I did in the patch: > * 1. I modified 'ChangeLogReport" class as follows: > ** a) I added three new plugin parameters: > *** commentSortRegexPattern > *** commentSortMatchedValues > *** commentSortColumnHeaders > *** including comprehensive documentation - see source code in the patch. > ** b) I added call to newly created method "validateCommentSortParams()" to > main "executeReport" method. As it is obvious from its name, this method > performs validation of above mentioned three parameters (including different > combinations of parameters configuration). > ** c) I slightly modified method "doChangedSetTable" to support creation of > new additional column headers used for sorting SCM commit messages. These > headers are created only if above mentioned plugin parameters are specified. > Otherwise code behaves exactly as it behaved before my change. > ** d) Original method "doChangeSetDetail" was extended with little bit of ne
[jira] Commented: (MCHANGELOG-118) Provide simple sorting based on the content of SCM commit messages on the HTML report.
[ http://jira.codehaus.org/browse/MCHANGELOG-118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257429#action_257429 ] Ivan Mrva commented on MCHANGELOG-118: -- In my opinion, integration tests included in this patch (and also currently existing tests) could be better, if they would include also parsing the resultant output HTML file. I did not want to do it like this, because that would mean a definition of new dependency to project (some HTML parser library). But in this moment, all my tests are at least on the same level as another currently existing tests are (I did them by analogy). > Provide simple sorting based on the content of SCM commit messages on the > HTML report. > -- > > Key: MCHANGELOG-118 > URL: http://jira.codehaus.org/browse/MCHANGELOG-118 > Project: Maven 2.x Changelog Plugin > Issue Type: New Feature >Affects Versions: 2.2 >Reporter: Ivan Mrva >Priority: Minor > Attachments: changelog-sorting-comment.diff, sample-sorted-report.png > > > Purpose: > In our company we have a 'pre-commit' hook script set up for all projects, > that requires from developers to fulfill some formatting rules of SCM commit > message. We would like to leverage from this rules and reflect them also on > the HTML change log to have a more comprendious and well-arranged change log > report. We would like to have commit messages sorted and placed in several > additional columns (instead of having them all in one 'Detail' column) in a > table on HTML report based on their format and content. > Example: > Suppose you want to divide SCM entries displayed on HTML report into four > columns labeled as "Bug fixes", "Features", "Improvements" and "Other > changes" in this order. Commit messages that contain at the beginning of the > line string "[B]" shall be placed in the "Bug fixes" column, messages with > "[F]" at the beginning shall come in the "Features" column, and messages with > "[I]" shall come in the "Improvements" column. All other messages shall > reside in the last "Other changes" column. > To see an example of how can such customized report look like, see screenshot > added as attachment (*sample-sorted-report.png*). > I implemented a patch (see *changelog-sorting-comment.diff*) that contains > logic that performs sorting of SCM entries as described above and I did it in > a general way, so that other users of changelog-plugin can define their own > rules for sorting messages. So, with my implementation, you can customize > report layout as described in above example by providing three new plugin > configuration parameters: > * *commentSortRegexPattern*=^[[BFI]] > ** Standard java regex pattern that is used for searching a match in commit > messages. > ** In this case, it matches commit messages that begin with "[B]", "[F]" or > "[I]" string > * *commentSortMatchValues*=[B],[F],[I] > ** Possible values of result of matches found by above pattern. > ** Used to determine number and order of newly created columns. Also defines > which message is placed into which column (messages with [B] at the beginning > will be placed in the first column, [F] in the second column, and so on ...). > * *commentSortColumnHeaders*=Bug fixes,Features,Improvements,Other changes > ** Header titles for newly created columns. > ** They matches the order and number of 'commentSortMatchValues' values, but > with one last additional value that is used as a header title for last > column, where all 'unsorted' messages will be placed. > Complete documentation of these parameters is included in my implementation > as javadoc. > What I did in the patch: > * 1. I modified 'ChangeLogReport" class as follows: > ** a) I added three new plugin parameters: > *** commentSortRegexPattern > *** commentSortMatchedValues > *** commentSortColumnHeaders > *** including comprehensive documentation - see source code in the patch. > ** b) I added call to newly created method "validateCommentSortParams()" to > main "executeReport" method. As it is obvious from its name, this method > performs validation of above mentioned three parameters (including different > combinations of parameters configuration). > ** c) I slightly modified method "doChangedSetTable" to support creation of > new additional column headers used for sorting SCM commit messages. These > headers are created only if above mentioned plugin parameters are specified. > Otherwise code behaves exactly as it behaved before my change. > ** d) Original method "doChangeSetDetail" was extended with little bit of new > logic that distributes SCM messages together with changed files into new > columns - if comment sorting functionality is enabled. Because of that, I > needed to extract code that deals only
[jira] Commented: (MASSEMBLY-337) dependencySet with unpack=true cannot be used to make file permissions executable
[
http://jira.codehaus.org/browse/MASSEMBLY-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257428#action_257428
]
Paul Gribben commented on MASSEMBLY-337:
Apologies - it is in the release note for 2.2. In my case I'm trying to unpack
a jar file (not zip) and then apply permissions. Should this work ok in 2.2?
> dependencySet with unpack=true cannot be used to make file permissions
> executable
> -
>
> Key: MASSEMBLY-337
> URL: http://jira.codehaus.org/browse/MASSEMBLY-337
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: Maven 2.0.9, Java 1.6_04, tested on both Windows XP and
> CentOS 4.1
>Reporter: John Crim
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.2
>
> Attachments: massembly-bug.tar.gz
>
>
> The attached tar.gz contains 2 simple test projects which exhibit this bug:
> # Project scripts-assembly generates
> {{scripts-assembly-1.0-SNAPSHOT-scripts.zip}}, which contains a single file,
> {{script.sh}}, with permissions {{-rwxr-xr-x}}
> # Project assembly-filemode-bug depends on project scripts-assembly. It
> extracts the scripts.zip file into its {{/bin}} directory when creating its
> assembly.
> {code:xml}
>
>
>
>
> bin
> true
>
> maven-bugs:scripts-assembly:zip:scripts
>
> 0755
>
>
> {code}
> The {{fileMode}} element does not have the desired effect. I'm not able to
> find a workaround with 2.2-beta-2 that enables me to set the executable bit
> on the scripts. From looking at other bugs in MASSEMBLY, I did try
> configuring the scripts-assembly project to output a zip (also tried tar.gz)
> containing the files with the executable bit set. This didn't change the
> outcome - the files in package #2 are still not executable.
> I consider this a highest priority bug, b/c I can find no way to get around
> this limitation and make script files from a dependency executable within an
> installable package. If I change to assembly plugin version 2.2-beta-1
> (which admittedly has a significant list of bugs I'd like to avoid), this
> works. I've also tried using other tar.gz for the assembly output of both
> projects, but it didn't affect the outcome.
> At this point I think my best path forward is to use assembly plugin version
> 2.2-beta-1.
--
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: (MASSEMBLY-337) dependencySet with unpack=true cannot be used to make file permissions executable
[
http://jira.codehaus.org/browse/MASSEMBLY-337?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257425#action_257425
]
Paul Gribben commented on MASSEMBLY-337:
Hi. This bug is marked as fixed in 2.2 in the summary above. (but is not on the
fixed list for 2.2). I've tried it out in 2.2 and it doesn't appear to be
fixed. Is the fix available?
> dependencySet with unpack=true cannot be used to make file permissions
> executable
> -
>
> Key: MASSEMBLY-337
> URL: http://jira.codehaus.org/browse/MASSEMBLY-337
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: Maven 2.0.9, Java 1.6_04, tested on both Windows XP and
> CentOS 4.1
>Reporter: John Crim
>Assignee: John Casey
>Priority: Blocker
> Fix For: 2.2
>
> Attachments: massembly-bug.tar.gz
>
>
> The attached tar.gz contains 2 simple test projects which exhibit this bug:
> # Project scripts-assembly generates
> {{scripts-assembly-1.0-SNAPSHOT-scripts.zip}}, which contains a single file,
> {{script.sh}}, with permissions {{-rwxr-xr-x}}
> # Project assembly-filemode-bug depends on project scripts-assembly. It
> extracts the scripts.zip file into its {{/bin}} directory when creating its
> assembly.
> {code:xml}
>
>
>
>
> bin
> true
>
> maven-bugs:scripts-assembly:zip:scripts
>
> 0755
>
>
> {code}
> The {{fileMode}} element does not have the desired effect. I'm not able to
> find a workaround with 2.2-beta-2 that enables me to set the executable bit
> on the scripts. From looking at other bugs in MASSEMBLY, I did try
> configuring the scripts-assembly project to output a zip (also tried tar.gz)
> containing the files with the executable bit set. This didn't change the
> outcome - the files in package #2 are still not executable.
> I consider this a highest priority bug, b/c I can find no way to get around
> this limitation and make script files from a dependency executable within an
> installable package. If I change to assembly plugin version 2.2-beta-1
> (which admittedly has a significant list of bugs I'd like to avoid), this
> works. I've also tried using other tar.gz for the assembly output of both
> projects, but it didn't affect the outcome.
> At this point I think my best path forward is to use assembly plugin version
> 2.2-beta-1.
--
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: (MCHANGELOG-118) Provide simple sorting based on the content of SCM commit messages on the HTML report.
Provide simple sorting based on the content of SCM commit messages on the HTML report. -- Key: MCHANGELOG-118 URL: http://jira.codehaus.org/browse/MCHANGELOG-118 Project: Maven 2.x Changelog Plugin Issue Type: New Feature Affects Versions: 2.2 Reporter: Ivan Mrva Priority: Minor Attachments: changelog-sorting-comment.diff, sample-sorted-report.png Purpose: In our company we have a 'pre-commit' hook script set up for all projects, that requires from developers to fulfill some formatting rules of SCM commit message. We would like to leverage from this rules and reflect them also on the HTML change log to have a more comprendious and well-arranged change log report. We would like to have commit messages sorted and placed in several additional columns (instead of having them all in one 'Detail' column) in a table on HTML report based on their format and content. Example: Suppose you want to divide SCM entries displayed on HTML report into four columns labeled as "Bug fixes", "Features", "Improvements" and "Other changes" in this order. Commit messages that contain at the beginning of the line string "[B]" shall be placed in the "Bug fixes" column, messages with "[F]" at the beginning shall come in the "Features" column, and messages with "[I]" shall come in the "Improvements" column. All other messages shall reside in the last "Other changes" column. To see an example of how can such customized report look like, see screenshot added as attachment (*sample-sorted-report.png*). I implemented a patch (see *changelog-sorting-comment.diff*) that contains logic that performs sorting of SCM entries as described above and I did it in a general way, so that other users of changelog-plugin can define their own rules for sorting messages. So, with my implementation, you can customize report layout as described in above example by providing three new plugin configuration parameters: * *commentSortRegexPattern*=^[[BFI]] ** Standard java regex pattern that is used for searching a match in commit messages. ** In this case, it matches commit messages that begin with "[B]", "[F]" or "[I]" string * *commentSortMatchValues*=[B],[F],[I] ** Possible values of result of matches found by above pattern. ** Used to determine number and order of newly created columns. Also defines which message is placed into which column (messages with [B] at the beginning will be placed in the first column, [F] in the second column, and so on ...). * *commentSortColumnHeaders*=Bug fixes,Features,Improvements,Other changes ** Header titles for newly created columns. ** They matches the order and number of 'commentSortMatchValues' values, but with one last additional value that is used as a header title for last column, where all 'unsorted' messages will be placed. Complete documentation of these parameters is included in my implementation as javadoc. What I did in the patch: * 1. I modified 'ChangeLogReport" class as follows: ** a) I added three new plugin parameters: *** commentSortRegexPattern *** commentSortMatchedValues *** commentSortColumnHeaders *** including comprehensive documentation - see source code in the patch. ** b) I added call to newly created method "validateCommentSortParams()" to main "executeReport" method. As it is obvious from its name, this method performs validation of above mentioned three parameters (including different combinations of parameters configuration). ** c) I slightly modified method "doChangedSetTable" to support creation of new additional column headers used for sorting SCM commit messages. These headers are created only if above mentioned plugin parameters are specified. Otherwise code behaves exactly as it behaved before my change. ** d) Original method "doChangeSetDetail" was extended with little bit of new logic that distributes SCM messages together with changed files into new columns - if comment sorting functionality is enabled. Because of that, I needed to extract code that deals only with 'detail' column to a separate method - now called "doChangeSetEntryDetail". Finally, I renamed original "doChangeSetDetail" method to "doChangeSetEntry" name, because it deals with whole entry (one row in HTML table including timestamp and author columns) and not only 'detail' part - just to improve a readability of code. * 2. I modifies "ChangeLogReportTest" class: ** f) I add some integration tests that tests both correct and wrong combination of configuration parameters to "ChangeLogReportTest" class. If there is something else to do in connection with this patch, please let me know and I can do it. If this patch could be accepted and included in official release of plugin, I would be grateful and I am also willing to provide any following required bug fixes to this functionality. -- This
[jira] Closed: (MNG-4986) After "mvn deploy" an SNAPSHOT artifact to company central repo(artifactory-2.3.1), Could not download the artifact in other machines.
[ http://jira.codehaus.org/browse/MNG-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4986. -- Resolution: Cannot Reproduce > After "mvn deploy" an SNAPSHOT artifact to company central > repo(artifactory-2.3.1), Could not download the artifact in other machines. > -- > > Key: MNG-4986 > URL: http://jira.codehaus.org/browse/MNG-4986 > Project: Maven 2 & 3 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 3.0, 3.0.1, 3.0.2 > Environment: Windows XP SP3, Oracle JDK 1.6.0_22, MAVEN > 3.0/3.0.1/3.0.2 >Reporter: Isaac Qu >Assignee: Benjamin Bentmann > Attachments: buffer-1.0.1-SNAPSHOT.zip, local-repo-contents.zip, > maven-debug-inf.txt > > > After "mvn deploy" an SNAPSHOT artifact to company central > repo(artifactory-2.3.1), Could not download the artifact in other machines. > MAVEN 2.2.1 has no this problem. > Following is detailed error info. > D:\work_p2p\tcpip>mvn install > [INFO] Scanning for projects... > [INFO] > [INFO] > > [INFO] Building Wacube Mebula TCP/IP Service 1.1.0-SNAPSHOT > [INFO] > > Downloading: > http://192.168.0.2:8080/artifactory/repo/com/wacube/mebula/com.wacube.mebula.buffer/maven-metadata.xml > Downloading: > http://192.168.0.2:8080/artifactory/repo/com/wacube/mebula/com.wacube.mebula.buffer/maven-metadata.xml > Downloaded: > http://192.168.0.2:8080/artifactory/repo/com/wacube/mebula/com.wacube.mebula.buffer/maven-metadata.xml > (337 > B at 2.3 KB/sec) > Downloaded: > http://192.168.0.2:8080/artifactory/repo/com/wacube/mebula/com.wacube.mebula.buffer/maven-metadata.xml > (337 > B at 1.9 KB/sec) > [WARNING] The POM for > com.wacube.mebula:com.wacube.mebula.buffer:jar:1.0.1-SNAPSHOT is missing, no > dependency informatio > n available > Downloading: > http://192.168.0.2:8080/artifactory/repo/com/wacube/mebula/com.wacube.mebula.core/maven-metadata.xml > Downloading: > http://192.168.0.2:8080/artifactory/repo/com/wacube/mebula/com.wacube.mebula.core/maven-metadata.xml > Downloaded: > http://192.168.0.2:8080/artifactory/repo/com/wacube/mebula/com.wacube.mebula.core/maven-metadata.xml > (375 B > at 3.4 KB/sec) > Downloaded: > http://192.168.0.2:8080/artifactory/repo/com/wacube/mebula/com.wacube.mebula.core/maven-metadata.xml > (375 B > at 2.9 KB/sec) > [WARNING] The POM for > com.wacube.mebula:com.wacube.mebula.core:jar:1.1.1-SNAPSHOT is missing, no > dependency information > available > [WARNING] The POM for > com.wacube.mebula:com.wacube.mebula.core:jar:1.1.2-SNAPSHOT is missing, no > dependency information > 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: (MNG-5006) M3 attempts to get released parent pom from snapshot repository when a dependency has range
[ http://jira.codehaus.org/browse/MNG-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257422#action_257422 ] Kristoffer Peterhansel commented on MNG-5006: - Nice work. Didn't think it would be so easy to reproduce =) Instead of cleaning the repo you can just use another one. Running Maven on these projects with an option like "-Dmaven.repo.local=..\repo" will do it for me. > M3 attempts to get released parent pom from snapshot repository when a > dependency has range > --- > > Key: MNG-5006 > URL: http://jira.codehaus.org/browse/MNG-5006 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: WinXP SP3, Java 6u20 >Reporter: Kristoffer Peterhansel > Attachments: maven-version-range-test.zip, > maven-version-range-test2.zip, mvn-verify-fixed-version.log, > mvn-verify-offline.log, mvn-verify-range-version.log > > > I have a bit of a strange issue. When running under Maven 3.0.2 I am getting > build errors when I try to build one of our projects when one of their > dependencies have a range version. But when setting it to a specific version > it seems to work. The same project works without a hitch in Maven 2.2.1. > As can be seen from the first included verbose trace > (mvn-verify-range-version.log). Maven attempts to get the pom from our > snapshot repository. That will, obviously, not work for a released artefact. > Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems > to skip that step completely. Even though it resolves to the same version in > the end. As seen in the other verbose trace (mvn-verify-fixed-version.log) -- 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: (MNG-4963) [regression] Parent POM not downloaded when settings define global mirror and one snapshot repo but no other release repository
[
http://jira.codehaus.org/browse/MNG-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann closed MNG-4963.
--
Resolution: Fixed
Fix Version/s: 3.0.3
Assignee: Benjamin Bentmann
Fixed in [r1073714|http://svn.apache.org/viewvc?view=revision&revision=1073714].
> [regression] Parent POM not downloaded when settings define global mirror and
> one snapshot repo but no other release repository
> ---
>
> Key: MNG-4963
> URL: http://jira.codehaus.org/browse/MNG-4963
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.0, 3.0.1
>Reporter: Stephan Pauxberger
>Assignee: Benjamin Bentmann
> Fix For: 3.0.3
>
> Attachments: parent-projects.zip
>
>
> Given the following two projects:
> {{parent}}, released as organization POM
> {{child}}, uses parent as its parent
> parent pom is *NOT* in the local repository (i.e. new developer machine or
> build node of the CI)
> settings.xml defines:
> a) a global mirror for all repositories
> (http://local-nexus.srv/content/groups/public)
> {code:xml}
>
>
> Nexus
> Coporate Nexus
> http://local-nexus.srv/content/groups/public
> *
>
>
> {code}
> b) a profile "repos" including a snapshot repository and an active-profiles
> entry activating this profile
> {code:xml}
>
>
> repos
>
>
> nexus-snapshots
> Projektserver Snapshots
> http://local-nexus.srv/content/repositories/snapshots
>
> false
>
>
> true
> fail
> always
>
>
>
>
>
>
> repos
>
> {code}
> This is a fairly standard setup for copporate development.
> now, when trying to compile the project, the following error is thrown:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project de.eucodos.bugs.maven:child:0.1-SNAPSHOT
> (X:\ACM\test\child\pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM: Could not find artifact
> de.eucodos.bugs.maven:parent:pom:0.1 and 'parent.relative
> Path' points at wrong local POM @ line 3, column 11 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> {noformat}
> Without maven trying to download the parent from the corp-repo.
> Sidenote: with Maven 2.x, this works without problems.
> If an additional *release*-repository is included in profile "repos",
> everything works as expected:
> {code:xml}
>
>
> repos
>
>
> nexus
> Projektserver
> http://msgs722i.msg.de:8080/nexus/content/groups/public
>
> true
>
>
>
> nexus-snapshots
> ...
> {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: (MNG-4963) [regression] Parent POM not downloaded when settings define global mirror and one snapshot repo but no other release repository
[
http://jira.codehaus.org/browse/MNG-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4963:
---
Summary: [regression] Parent POM not downloaded when settings define global
mirror and one snapshot repo but no other release repository (was: Parent
Artifact ist not downloaded from repository with certain settings)
> [regression] Parent POM not downloaded when settings define global mirror and
> one snapshot repo but no other release repository
> ---
>
> Key: MNG-4963
> URL: http://jira.codehaus.org/browse/MNG-4963
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Artifacts and Repositories, POM
>Affects Versions: 3.0, 3.0.1
>Reporter: Stephan Pauxberger
> Attachments: parent-projects.zip
>
>
> Given the following two projects:
> {{parent}}, released as organization POM
> {{child}}, uses parent as its parent
> parent pom is *NOT* in the local repository (i.e. new developer machine or
> build node of the CI)
> settings.xml defines:
> a) a global mirror for all repositories
> (http://local-nexus.srv/content/groups/public)
> {code:xml}
>
>
> Nexus
> Coporate Nexus
> http://local-nexus.srv/content/groups/public
> *
>
>
> {code}
> b) a profile "repos" including a snapshot repository and an active-profiles
> entry activating this profile
> {code:xml}
>
>
> repos
>
>
> nexus-snapshots
> Projektserver Snapshots
> http://local-nexus.srv/content/repositories/snapshots
>
> false
>
>
> true
> fail
> always
>
>
>
>
>
>
> repos
>
> {code}
> This is a fairly standard setup for copporate development.
> now, when trying to compile the project, the following error is thrown:
> {noformat}
> [INFO] Scanning for projects...
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR] The project de.eucodos.bugs.maven:child:0.1-SNAPSHOT
> (X:\ACM\test\child\pom.xml) has 1 error
> [ERROR] Non-resolvable parent POM: Could not find artifact
> de.eucodos.bugs.maven:parent:pom:0.1 and 'parent.relative
> Path' points at wrong local POM @ line 3, column 11 -> [Help 2]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please
> read the following articles:
> [ERROR] [Help 1]
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2]
> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> {noformat}
> Without maven trying to download the parent from the corp-repo.
> Sidenote: with Maven 2.x, this works without problems.
> If an additional *release*-repository is included in profile "repos",
> everything works as expected:
> {code:xml}
>
>
> repos
>
>
> nexus
> Projektserver
> http://msgs722i.msg.de:8080/nexus/content/groups/public
>
> true
>
>
>
> nexus-snapshots
> ...
> {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: (MNG-4963) Parent Artifact ist not downloaded from repository with certain settings
[
http://jira.codehaus.org/browse/MNG-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Bentmann updated MNG-4963:
---
Description:
Given the following two projects:
{{parent}}, released as organization POM
{{child}}, uses parent as its parent
parent pom is *NOT* in the local repository (i.e. new developer machine or
build node of the CI)
settings.xml defines:
a) a global mirror for all repositories
(http://local-nexus.srv/content/groups/public)
{code:xml}
Nexus
Coporate Nexus
http://local-nexus.srv/content/groups/public
*
{code}
b) a profile "repos" including a snapshot repository and an active-profiles
entry activating this profile
{code:xml}
repos
nexus-snapshots
Projektserver Snapshots
http://local-nexus.srv/content/repositories/snapshots
false
true
fail
always
repos
{code}
This is a fairly standard setup for copporate development.
now, when trying to compile the project, the following error is thrown:
{noformat}
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project de.eucodos.bugs.maven:child:0.1-SNAPSHOT
(X:\ACM\test\child\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact
de.eucodos.bugs.maven:parent:pom:0.1 and 'parent.relative
Path' points at wrong local POM @ line 3, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
{noformat}
Without maven trying to download the parent from the corp-repo.
Sidenote: with Maven 2.x, this works without problems.
If an additional *release*-repository is included in profile "repos",
everything works as expected:
{code:xml}
repos
nexus
Projektserver
http://msgs722i.msg.de:8080/nexus/content/groups/public
true
nexus-snapshots
...
{code}
was:
Given the following two projects:
{{parent}}, released as organization POM
{{child}}, uses parent as its parent
parent pom is *NOT* in the local repository (i.e. new developer machine or
build node of the CI)
settings.xml defines:
a) a global mirror for all repositories
(http://local-nexus.srv/content/groups/public)
{{
Nexus
Coporate Nexus
http://local-nexus.srv/content/groups/public
*
}}
b) a profile "repos" including a snapshot repository and an active-profiles
entry activating this profile
{{
repos
nexus-snapshots
Projektserver Snapshots
http://local-nexus.srv/content/repositories/snapshots
false
true
fail
always
repos
}}
This is a fairly standard setup for copporate development.
now, when trying to compile the project, the following error is thrown:
{{
[INFO] Scanning for projects...
[ERROR] The build could not read 1 project -> [Help 1]
[ERROR]
[ERROR] The project de.eucodos.bugs.maven:child:0.1-SNAPSHOT
(X:\ACM\test\child\pom.xml) has 1 error
[ERROR] Non-resolvable parent POM: Could not find artifact
de.eucodos.bugs.maven:parent:pom:0.1 and 'parent.relative
Path' points at wrong local POM @ line 3, column 11 -> [Help 2]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e
switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please
read the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
[ERROR] [Help 2]
http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
}}
Without maven trying to download the parent from the corp-repo.
Sidenote: with Maven 2.x, this works without problems.
If an additional *release*-repository is included in profile "repos",
everything works as expected:
{{
repos
nexus
Projektserver
http://msgs722i.msg.de:8080/nexus/content/groups/p
[jira] Updated: (MNG-5006) M3 attempts to get released parent pom from snapshot repository when a dependency has range
[ http://jira.codehaus.org/browse/MNG-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sei Syvalta updated MNG-5006: - Attachment: maven-version-range-test2.zip Previous version didn't work with a clean repo. Needed to change the range from [1.0,2.0) to [1.0-SNAPSHOT,2.0). > M3 attempts to get released parent pom from snapshot repository when a > dependency has range > --- > > Key: MNG-5006 > URL: http://jira.codehaus.org/browse/MNG-5006 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: WinXP SP3, Java 6u20 >Reporter: Kristoffer Peterhansel > Attachments: maven-version-range-test.zip, > maven-version-range-test2.zip, mvn-verify-fixed-version.log, > mvn-verify-offline.log, mvn-verify-range-version.log > > > I have a bit of a strange issue. When running under Maven 3.0.2 I am getting > build errors when I try to build one of our projects when one of their > dependencies have a range version. But when setting it to a specific version > it seems to work. The same project works without a hitch in Maven 2.2.1. > As can be seen from the first included verbose trace > (mvn-verify-range-version.log). Maven attempts to get the pom from our > snapshot repository. That will, obviously, not work for a released artefact. > Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems > to skip that step completely. Even though it resolves to the same version in > the end. As seen in the other verbose trace (mvn-verify-fixed-version.log) -- 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-5006) M3 attempts to get released parent pom from snapshot repository when a dependency has range
[ http://jira.codehaus.org/browse/MNG-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257417#action_257417 ] Sei Syvalta edited comment on MNG-5006 at 2/23/11 5:32 AM: --- Very simple test to reproduce the error. Build module a first and then b. Building b should fail. If not try cleaning local repo and try again. was (Author: bugittaa): Very simple test to reproduce the error. Build module a first and then b. Building b should fail. > M3 attempts to get released parent pom from snapshot repository when a > dependency has range > --- > > Key: MNG-5006 > URL: http://jira.codehaus.org/browse/MNG-5006 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: WinXP SP3, Java 6u20 >Reporter: Kristoffer Peterhansel > Attachments: maven-version-range-test.zip, > mvn-verify-fixed-version.log, mvn-verify-offline.log, > mvn-verify-range-version.log > > > I have a bit of a strange issue. When running under Maven 3.0.2 I am getting > build errors when I try to build one of our projects when one of their > dependencies have a range version. But when setting it to a specific version > it seems to work. The same project works without a hitch in Maven 2.2.1. > As can be seen from the first included verbose trace > (mvn-verify-range-version.log). Maven attempts to get the pom from our > snapshot repository. That will, obviously, not work for a released artefact. > Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems > to skip that step completely. Even though it resolves to the same version in > the end. As seen in the other verbose trace (mvn-verify-fixed-version.log) -- 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: (MNG-5006) M3 attempts to get released parent pom from snapshot repository when a dependency has range
[ http://jira.codehaus.org/browse/MNG-5006?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sei Syvalta updated MNG-5006: - Attachment: maven-version-range-test.zip Very simple test to reproduce the error. Build module a first and then b. Building b should fail. > M3 attempts to get released parent pom from snapshot repository when a > dependency has range > --- > > Key: MNG-5006 > URL: http://jira.codehaus.org/browse/MNG-5006 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: WinXP SP3, Java 6u20 >Reporter: Kristoffer Peterhansel > Attachments: maven-version-range-test.zip, > mvn-verify-fixed-version.log, mvn-verify-offline.log, > mvn-verify-range-version.log > > > I have a bit of a strange issue. When running under Maven 3.0.2 I am getting > build errors when I try to build one of our projects when one of their > dependencies have a range version. But when setting it to a specific version > it seems to work. The same project works without a hitch in Maven 2.2.1. > As can be seen from the first included verbose trace > (mvn-verify-range-version.log). Maven attempts to get the pom from our > snapshot repository. That will, obviously, not work for a released artefact. > Changing the dependency version from the [1,2) range to 1.0.1-SNAPSHOT seems > to skip that step completely. Even though it resolves to the same version in > the end. As seen in the other verbose trace (mvn-verify-fixed-version.log) -- 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-5000) [regression] child distributionManagment.site.url not correct in a flat directory layout when child's artifactId doesn't match its module name
[ http://jira.codehaus.org/browse/MNG-5000?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257415#action_257415 ] Benjamin Bentmann commented on MNG-5000: bq. I don't understand why this should be the case, are there any docs or examples you could point me to? http://svn.apache.org/repos/asf/maven/maven-2/tags/maven-2.2.1/maven-project/src/main/java/org/apache/maven/project/MavenProject.java, getModulePathAdjustment() starts with two nice FIXME comments that outline the design flaw. bq. The state of a pom should be uniquely specified by its maven coordinates and those of its parent, not by the module structure of the build Yes this would be the ideal but the bug raised here demands to consider the directory name in the local project structure which is lost once the POMs got installed/deployed to a repo. When I investigated the bug, I was originally tempted to close it as won't fix because of the irreproducibility it drags in but then again, this entire URL inheritance/adjustment feature is broken itself so I stopped bothering and just restored the status quo as in 2.x. > [regression] child distributionManagment.site.url not correct in a flat > directory layout when child's artifactId doesn't match its module name > -- > > Key: MNG-5000 > URL: http://jira.codehaus.org/browse/MNG-5000 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: windows >Reporter: Stefan Hansel >Assignee: Benjamin Bentmann > Fix For: 3.0.3 > > Attachments: artifact-id-testcase.zip > > > There is a multimodule flat project structure: > root > module1 > module2 > module1 has an artifactID of 'module1' (same as directory name) > modulu2 has an artifactID of 'module-2' (different to directory name) > After a 'mvn site-deploy' the generated report has the folder structure: > /root > /root/module-2 > /module1 > So based on the artifactID the submodules are created as a child of the root > - or not. > This is at least inconsistent and should be changed to be handled always the > same - independent of the artifactID. > This is also important for other plugins (i.e. the dashboard plugin). > They seem to have some hardcoded directory structure (preferring submodules > as childs of the root report). > Due to this bug (see http://jira.codehaus.org/browse/MOJO-1630) the links > between reports there still don't work as long as artifactID=module's > directory. > Attached you will find a testcase (based on maven3, but can also be used with > maven2 when the version of the site-plugin is changed). -- 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-5023) Wrong calculation of Build Total time
[ http://jira.codehaus.org/browse/MNG-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257395#action_257395 ] Ignat Alexeyenko commented on MNG-5023: --- The best way to reproduce, probably, is create a unit-tests that sleeps > 24 hours. > Wrong calculation of Build Total time > - > > Key: MNG-5023 > URL: http://jira.codehaus.org/browse/MNG-5023 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: mvn -version > Apache Maven 3.0.2 (r1056850; 2011-01-09 02:58:10+0200) > Java version: 1.6.0_20, vendor: Sun Microsystems Inc. > Java home: /usr/lib/jvm/java-1.6.0-sun-1.6.0.20/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "2.6.18-194.17.1.el5", arch: "i386", family: "unix" >Reporter: Ignat Alexeyenko >Priority: Minor > > If build duration exceeds 24h, the Total Time is not displayed properly: > [INFO] Total time: 0:00:02.511s > [INFO] Finished at: Wed Feb 23 09:37:46 EET 2011 > [INFO] Final Memory: 93M/739M > Build duration was 24 hours and 2 minutes: build launched sonar inspections > via maven. > Expected Total Time is: > [INFO] Total time: 24:00:02.511s > [INFO] Finished at: Wed Feb 23 09:37:46 EET 2011 > [INFO] Final Memory: 93M/739M -- 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-5023) Wrong calculation of Build Total time
[ http://jira.codehaus.org/browse/MNG-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=257395#action_257395 ] Ignat Alexeyenko edited comment on MNG-5023 at 2/23/11 2:37 AM: The best way to reproduce, probably, is to create a unit-tests that sleeps > 24 hours. was (Author: ignatalexeyenko): The best way to reproduce, probably, is create a unit-tests that sleeps > 24 hours. > Wrong calculation of Build Total time > - > > Key: MNG-5023 > URL: http://jira.codehaus.org/browse/MNG-5023 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0.2 > Environment: mvn -version > Apache Maven 3.0.2 (r1056850; 2011-01-09 02:58:10+0200) > Java version: 1.6.0_20, vendor: Sun Microsystems Inc. > Java home: /usr/lib/jvm/java-1.6.0-sun-1.6.0.20/jre > Default locale: en_US, platform encoding: UTF-8 > OS name: "linux", version: "2.6.18-194.17.1.el5", arch: "i386", family: "unix" >Reporter: Ignat Alexeyenko >Priority: Minor > > If build duration exceeds 24h, the Total Time is not displayed properly: > [INFO] Total time: 0:00:02.511s > [INFO] Finished at: Wed Feb 23 09:37:46 EET 2011 > [INFO] Final Memory: 93M/739M > Build duration was 24 hours and 2 minutes: build launched sonar inspections > via maven. > Expected Total Time is: > [INFO] Total time: 24:00:02.511s > [INFO] Finished at: Wed Feb 23 09:37:46 EET 2011 > [INFO] Final Memory: 93M/739M -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5023) Wrong calculation of Build Total time
Wrong calculation of Build Total time - Key: MNG-5023 URL: http://jira.codehaus.org/browse/MNG-5023 Project: Maven 2 & 3 Issue Type: Bug Affects Versions: 3.0.2 Environment: mvn -version Apache Maven 3.0.2 (r1056850; 2011-01-09 02:58:10+0200) Java version: 1.6.0_20, vendor: Sun Microsystems Inc. Java home: /usr/lib/jvm/java-1.6.0-sun-1.6.0.20/jre Default locale: en_US, platform encoding: UTF-8 OS name: "linux", version: "2.6.18-194.17.1.el5", arch: "i386", family: "unix" Reporter: Ignat Alexeyenko Priority: Minor If build duration exceeds 24h, the Total Time is not displayed properly: [INFO] Total time: 0:00:02.511s [INFO] Finished at: Wed Feb 23 09:37:46 EET 2011 [INFO] Final Memory: 93M/739M Build duration was 24 hours and 2 minutes: build launched sonar inspections via maven. Expected Total Time is: [INFO] Total time: 24:00:02.511s [INFO] Finished at: Wed Feb 23 09:37:46 EET 2011 [INFO] Final Memory: 93M/739M -- 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
