[jira] Updated: (MRM-578) unfinished scanning after NPE
[ http://jira.codehaus.org/browse/MRM-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Milos Kleint updated MRM-578: - Attachment: error2.txt yet another attempt to index repository > unfinished scanning after NPE > - > > Key: MRM-578 > URL: http://jira.codehaus.org/browse/MRM-578 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 1.0-beta-3 > Environment: macosx 1.4, jdk 1.5, archiva beta3 >Reporter: Milos Kleint > Fix For: 1.0-beta-4 > > Attachments: error.txt, error2.txt > > > I repeatedly tried to index a mirror of central repository. In previous > attempts, usually got "Too many files opened" kind of errors. This time it's > a NPE, see attached console output -- 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] Work started: (MRM-576) behaviour of "delete released snapshots" is incorrect
[ http://jira.codehaus.org/browse/MRM-576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-576 started by Maria Odea Ching. > behaviour of "delete released snapshots" is incorrect > - > > Key: MRM-576 > URL: http://jira.codehaus.org/browse/MRM-576 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 1.0-beta-3 >Reporter: Brett Porter >Assignee: Maria Odea Ching > Fix For: 1.0-beta-4 > > > problem 1) - it looks at "allVersions" instead of "releasedVersions" to get > the highest released version. This means the existence of 2.1-SNAPSHOT will > delete 2.0.8-SNAPSHOT, even if they are in concurrent development > problem 2) - even the above change may not be correct - 2.0.8-SNAPSHOT may be > developed after 2.1 is released. > The logic should instead delete 2.0.8-SNAPSHOT only if 2.0.8 exists (and so > on for each snapshot). -- 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: (MRM-556) not possible to configure purge by retention count
[ http://jira.codehaus.org/browse/MRM-556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maria Odea Ching closed MRM-556. Resolution: Fixed Fixed in -r592297. Changes: - respect set retention count when purging by number of days old (used same logic for purging by retention count) - updated edit managed repository validation for the number of days old minimum range - adjusted DaysOldRepositoryPurgeTest for the changes > not possible to configure purge by retention count > -- > > Key: MRM-556 > URL: http://jira.codehaus.org/browse/MRM-556 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Maria Odea Ching >Priority: Critical > Fix For: 1.0-beta-4 > > > currently, this is activated by a 0 value in the # days field, but the > validation prevents that from happening. > I believe the behaviour should be as follows: > - the retention count is the *minimum* number to retain - this many are > guaranteed. Valid values are >= 1 > - the # of days is the actual filter applied. Valid values are >= 0 > So, the retained snapshots is the union of the two sets of results. > However, the retention count still does not apply to something that is > handled by "delete released snapshots", these should always be deleted in > their entirety. -- 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: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
[ http://jira.codehaus.org/browse/MARTIFACT-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MARTIFACT-6. - Resolution: Fixed Fix Version/s: 3.0-alpha-1 No more redeploy. > The deployer should detect previous deployments of the same version and die > if that's the case. > --- > > Key: MARTIFACT-6 > URL: http://jira.codehaus.org/browse/MARTIFACT-6 > Project: Maven Artifact > Issue Type: Improvement >Affects Versions: 3.0-alpha-1 >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 3.0-alpha-1 > > > We simply have to die because giving people an option is just going to let > them continue with their bad practices. If you let the redeployment of > released binaries then it will happen, and it will cause problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MARTIFACT-6) The deployer should detect previous deployments of the same version and die if that's the case.
The deployer should detect previous deployments of the same version and die if that's the case. --- Key: MARTIFACT-6 URL: http://jira.codehaus.org/browse/MARTIFACT-6 Project: Maven Artifact Issue Type: Improvement Affects Versions: 3.0-alpha-1 Reporter: Jason van Zyl We simply have to die because giving people an option is just going to let them continue with their bad practices. If you let the redeployment of released binaries then it will happen, and it will cause problems. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-3250) Changes to maven-artifact didn't made it into new artifact location
[ http://jira.codehaus.org/browse/MNG-3250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3250. -- Resolution: Fixed Carlos, I assume from your comment you fixed it. > Changes to maven-artifact didn't made it into new artifact location > --- > > Key: MNG-3250 > URL: http://jira.codehaus.org/browse/MNG-3250 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.8, 2.1-alpha-1 >Reporter: Carlos Sanchez > Fix For: 2.1-alpha-1 > > > Changes to http://svn.apache.org/viewvc/maven/components/trunk/maven-artifact > in rev# 565824 > http://svn.apache.org/viewvc?view=rev&revision=565824 > were merged to the 2.0.x branch > http://svn.apache.org/viewvc?view=rev&revision=565828 > but don't show up in http://svn.apache.org/viewvc/maven/artifact/trunk > And a related issue is that those changes break backwards > compatibility in the 2.0.x branch > [ERROR] org.apache.maven.artifact.versioning.ArtifactVersion: Method > 'public boolean equals(java.lang.Object)' has been added to an > interface > [ERROR] org.apache.maven.artifact.versioning.ArtifactVersion: Method > 'public int hashCode()' has been added to an interface -- 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-2909) zero length files can be created for metadata
[ http://jira.codehaus.org/browse/MNG-2909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-2909. -- Resolution: Fixed > zero length files can be created for metadata > - > > Key: MNG-2909 > URL: http://jira.codehaus.org/browse/MNG-2909 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.x, 2.1 >Reporter: Brett Porter >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > I was getting build fails because of this: > Caused by: java.io.EOFException: input contained no data > at > org.codehaus.plexus.util.xml.pull.MXParser.fillBuf(MXParser.java:2979) > at org.codehaus.plexus.util.xml.pull.MXParser.more(MXParser.java:3022) > at > org.codehaus.plexus.util.xml.pull.MXParser.parseProlog(MXParser.java:1407) > at > org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1392) > at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1090) > at > org.apache.maven.artifact.repository.metadata.io.xpp3.MetadataXpp3Reader.read(MetadataXpp3Reader.java:863) > at > org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.updateRepositoryMetadata(AbstractRepositoryMetadata.java:98) > at > org.apache.maven.artifact.repository.metadata.AbstractRepositoryMetadata.storeInLocalRepository(AbstractRepositoryMetadata.java:68) > ... 21 more > It happened after cancelling a previous build, presumably mid-update of the > metadata. > Probably 2 things to do here: > a) This error should be handled when reading back the metadata to merge, and > treated as a non-existent file instead of an error. > b) use an atomic rename instead of overwriting an existing file to prevent > dataloss in the even of a cancelled build -- 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-2377) maven-metadata not re-read after failure
[
http://jira.codehaus.org/browse/MNG-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl closed MNG-2377.
--
Resolution: Fixed
> maven-metadata not re-read after failure
>
>
> Key: MNG-2377
> URL: http://jira.codehaus.org/browse/MNG-2377
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0-alpha-1
>Reporter: Kenney Westerhof
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 2.1-alpha-1
>
>
> A bug in deploy (not setting filePermissions correctly on deploy) caused the
> maven-metadata...xml and the artifacts/poms
> to be unreadable.
> When building a project with a dep on a SNAPSHOT artifact on the faulty
> remote repository, the maven-metadata can not be read.
> Maven creates a maven-metadata...xml with the following content (sample):
> {noformat}
>
> com.neonics.container
> bundle-factory-maven
> 1.0-SNAPSHOT
>
> {noformat}
> After fixing the permissions I restart the build, but the metadata file is
> not re-read, resulting in Maven thinking
> 1.0-SNAPSHOT is the actual version and trying to get
> ...artifact/1.0-SNAPSHOT/artifact-1.0-SNAPSHOT.pom
> which does not exist.
> Touching the files on the remote repo doesn't help either.
> Only when running with -U the metadata file is retrieved (another solution is
> to purge files from
> the local repository).
> I think Maven should not create the metadata file if it can't be retrieved
> AND if the non-timestamped
> SNAPSHOT version doesn't exist.
> I can see why the placeholder metadata files reduces future requests for this
> file,
> but that's only useful if there _are_ future requests. There are indeed
> repeated requests for the pom
> and artifact, even though they also don't exist. I think that only when the
> artifact 1.0-SNAPSHOT exists
> and the metadata file doesn't, it's safe to put a placeholder metadata file
> in the local repository.
--
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-2377) maven-metadata not re-read after failure
[
http://jira.codehaus.org/browse/MNG-2377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112912
]
Jason van Zyl commented on MNG-2377:
The correct thing should be done first. The case that causes the user the least
amount of pain. If some messages fly by again and again it's an annoyance, but
having a non-functional system because some file is sitting around is not good.
This one is in the repository metadata manager so I'll take a look in here as I
was just here.
> maven-metadata not re-read after failure
>
>
> Key: MNG-2377
> URL: http://jira.codehaus.org/browse/MNG-2377
> Project: Maven 2
> Issue Type: Bug
> Components: Artifacts and Repositories
>Affects Versions: 2.0-alpha-1
>Reporter: Kenney Westerhof
>Assignee: Jason van Zyl
>Priority: Minor
> Fix For: 2.1-alpha-1
>
>
> A bug in deploy (not setting filePermissions correctly on deploy) caused the
> maven-metadata...xml and the artifacts/poms
> to be unreadable.
> When building a project with a dep on a SNAPSHOT artifact on the faulty
> remote repository, the maven-metadata can not be read.
> Maven creates a maven-metadata...xml with the following content (sample):
> {noformat}
>
> com.neonics.container
> bundle-factory-maven
> 1.0-SNAPSHOT
>
> {noformat}
> After fixing the permissions I restart the build, but the metadata file is
> not re-read, resulting in Maven thinking
> 1.0-SNAPSHOT is the actual version and trying to get
> ...artifact/1.0-SNAPSHOT/artifact-1.0-SNAPSHOT.pom
> which does not exist.
> Touching the files on the remote repo doesn't help either.
> Only when running with -U the metadata file is retrieved (another solution is
> to purge files from
> the local repository).
> I think Maven should not create the metadata file if it can't be retrieved
> AND if the non-timestamped
> SNAPSHOT version doesn't exist.
> I can see why the placeholder metadata files reduces future requests for this
> file,
> but that's only useful if there _are_ future requests. There are indeed
> repeated requests for the pom
> and artifact, even though they also don't exist. I think that only when the
> artifact 1.0-SNAPSHOT exists
> and the metadata file doesn't, it's safe to put a placeholder metadata file
> in the local repository.
--
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-3274) Have a clear flag to allow a POM or not
[ http://jira.codehaus.org/browse/MNG-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3274: -- Fix Version/s: 2.1-alpha-1 > Have a clear flag to allow a POM or not > --- > > Key: MNG-3274 > URL: http://jira.codehaus.org/browse/MNG-3274 > Project: Maven 2 > Issue Type: Improvement >Reporter: Jason van Zyl >Assignee: Jason van Zyl > Fix For: 2.1-alpha-1 > > > I have changed the MavenMetadataSource to have a flag which will determine if > we blow up when a POM isn't present. It will not blow up but it's still > pathetic that we get projects that don't give us POMs. -- 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-3274) Have a clear flag to allow a POM or not
[ http://jira.codehaus.org/browse/MNG-3274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl closed MNG-3274. -- Resolution: Fixed The MavenMetadataSource has been updated. > Have a clear flag to allow a POM or not > --- > > Key: MNG-3274 > URL: http://jira.codehaus.org/browse/MNG-3274 > Project: Maven 2 > Issue Type: Improvement >Reporter: Jason van Zyl >Assignee: Jason van Zyl > > I have changed the MavenMetadataSource to have a flag which will determine if > we blow up when a POM isn't present. It will not blow up but it's still > pathetic that we get projects that don't give us POMs. -- 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-3274) Have a clear flag to allow a POM or not
Have a clear flag to allow a POM or not --- Key: MNG-3274 URL: http://jira.codehaus.org/browse/MNG-3274 Project: Maven 2 Issue Type: Improvement Reporter: Jason van Zyl I have changed the MavenMetadataSource to have a flag which will determine if we blow up when a POM isn't present. It will not blow up but it's still pathetic that we get projects that don't give us POMs. -- 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-3272) new URI( url.toString() ) when using a jar path with a space in it results in error
[ http://jira.codehaus.org/browse/MNG-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112908 ] Carlos Sanchez commented on MNG-3272: - For more info I was using the URL.toURI method but it's only available in java 5 http://java.sun.com/javase/6/docs/api/java/net/URL.html#toURI() "This method functions in the same way as new URI (this.toString()). Note, any URL instance that complies with RFC 2396 can be converted to a URI. However, some URLs that are not strictly in compliance can not be converted to a URI." > new URI( url.toString() ) when using a jar path with a space in it results in > error > --- > > Key: MNG-3272 > URL: http://jira.codehaus.org/browse/MNG-3272 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > Fix For: 2.1-alpha-1 > > > When maven.home contains a space, reading the super-POM from the > maven-project jar results in: > Error stacktrace: > org.apache.maven.reactor.MavenExecutionException: Error scanning for > extensions: Error building super-POM for retrieving the default remote > repository list: Failed build model from URL 'jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' > Error: 'Illegal character in opaque part at index 20: jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' > for project org.apache.maven:super-pom > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:286) > at > org.apache.maven.DefaultMaven.createReactorManager(DefaultMaven.java:109) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:166) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:784) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:179) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:71) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) > Caused by: org.apache.maven.extension.ExtensionScanningException: Error > building super-POM for retrieving the default remote repository list: Failed > build model from URL 'jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' > Error: 'Illegal character in opaque part at index 20: jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' > for project org.apache.maven:super-pom > at > org.apache.maven.extension.DefaultBuildExtensionScanner.getInitialRemoteRepositories(DefaultBuildExtensionScanner.java:357) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:109) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanForBuildExtensions(DefaultBuildExtensionScanner.java:81) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:282) > ... 13 more > Caused by: org.apache.maven.project.ProjectBuildingException: Failed build > model from URL 'jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' > Error: 'Illegal character in opaque part at index 20: jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' > for project org.apache.maven:super-pom > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1073) > at > org.apache.maven.project.DefaultMavenProjectBuilder.getSuperModel(DefaultMavenProjectBuilder.java:1281) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildStandaloneSuperProject(DefaultMavenProjectBuilder.java:228) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.getInitialRemoteRepositories(DefaultBuildExtensionScanner.java:353) > ... 16 more > Caused by: java.net.URISyntaxException: Illegal character in opaque part at > index 20: jar
[jira] Updated: (MRM-578) unfinished scanning after NPE
[ http://jira.codehaus.org/browse/MRM-578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-578: - Fix Version/s: 1.0-beta-4 > unfinished scanning after NPE > - > > Key: MRM-578 > URL: http://jira.codehaus.org/browse/MRM-578 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 1.0-beta-3 > Environment: macosx 1.4, jdk 1.5, archiva beta3 >Reporter: Milos Kleint > Fix For: 1.0-beta-4 > > Attachments: error.txt > > > I repeatedly tried to index a mirror of central repository. In previous > attempts, usually got "Too many files opened" kind of errors. This time it's > a NPE, see attached console output -- 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-3273) Point out known pitfalls when developing plugins
Point out known pitfalls when developing plugins
Key: MNG-3273
URL: http://jira.codehaus.org/browse/MNG-3273
Project: Maven 2
Issue Type: Improvement
Components: Documentation: Guides
Reporter: Benjamin Bentmann
Priority: Minor
Writing a simple Maven plugin is quite easy but getting it wrong is also quite
easy. I am just a novice but have so far noticed two subtle anti-patterns that
plugin developers should avoid. I would expect that the Maven core team knows
some more aspects about mojo programming that plugin developers should be aware
of to fight bugs right from the beginning. All those pitfalls would fit nicely
into [Plugin
Development|http://maven.apache.org/guides/plugin/guide-java-plugin-development.html].
Some examples: It is a bad idea to code something like
{code:java}
public MyMojo {
private Log log = getLog();
public void execute() throws MojoExecutionException {
log.debug("...");
}
}
{code}
Getting the logger this way will retrieve some default logger instead of the
logger that is injected into the mojo (by the plexus container?). This is
easily noticed by the different output styles of the log messages and the fact
that one gets [debug] message without having "-X" enabled.
Not bad but rather dangerous is something like
{code:java}
public MyMojo {
/**
* This parameter will take a file path (file paths are
platform-dependent...)
* @parameter
*/
private String outputDirectory;
public void execute() throws MojoExecutionException {
File outputDir = new File(outputDirectory).getAbsoluteFile();
outputDir.mkdirs();
}
}
{code}
java.io.File resolves relative paths like "target/something" that users might
provide in the plugin configuration against the current directory which needs
not be the project base directory. Therefore, path parameters should be
declared of type java.io.File rather than simple strings as Maven seems to
automatically push in properly resolved paths into the mojo. If one really
needs the parameter to be of type String (i.e. to try resource lookup from
class path), the best practice to properly get an absolute path should be
documented.
How to get a plugin ready for reactor builds might also be worth some warning
words. What does one need to know about aggregator-style execution, execution
project, forking ... ?
A further improvement might be links to recommended libraries like plexus-utils
or plexus-components. This would point peoply to existing code and prevent to
error-prone reinvention of the wheel (only a few things on earth are that
simple that people get them reliably right...)
--
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: (CONTINUUM-1548) NPE in IRC Notifier
[ http://jira.codehaus.org/browse/CONTINUUM-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy closed CONTINUUM-1548. --- Resolution: Fixed fix in rev 592180 > NPE in IRC Notifier > --- > > Key: CONTINUUM-1548 > URL: http://jira.codehaus.org/browse/CONTINUUM-1548 > Project: Continuum > Issue Type: Bug > Components: Notifier - IRC >Affects Versions: 1.1-beta-4 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.1 > > > Using the IRC Notifier generate an NPE. -- 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: (CONTINUUM-1548) NPE in IRC Notifier
[ http://jira.codehaus.org/browse/CONTINUUM-1548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-1548: Assignee: Olivier Lamy Fix Version/s: 1.1 > NPE in IRC Notifier > --- > > Key: CONTINUUM-1548 > URL: http://jira.codehaus.org/browse/CONTINUUM-1548 > Project: Continuum > Issue Type: Bug > Components: Notifier - IRC >Affects Versions: 1.1-beta-4 >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.1 > > > Using the IRC Notifier generate an NPE. -- 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: (CONTINUUM-1548) NPE in IRC Notifier
NPE in IRC Notifier --- Key: CONTINUUM-1548 URL: http://jira.codehaus.org/browse/CONTINUUM-1548 Project: Continuum Issue Type: Bug Components: Notifier - IRC Affects Versions: 1.1-beta-4 Reporter: Olivier Lamy Using the IRC Notifier generate an NPE. -- 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: (CONTINUUM-1543) Email Subject line templates support only 3 name variables.
[
http://jira.codehaus.org/browse/CONTINUUM-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112898
]
Olivier Lamy commented on CONTINUUM-1543:
-
Emmanuel,
No way to have continuum-model javadoc here
http://maven.apache.org/continuum/ref/latest/apidocs/index.html ?
> Email Subject line templates support only 3 name variables.
> ---
>
> Key: CONTINUUM-1543
> URL: http://jira.codehaus.org/browse/CONTINUUM-1543
> Project: Continuum
> Issue Type: Bug
>Affects Versions: 1.1-beta-4
>Reporter: Bryan Madsen
>Priority: Trivial
> Fix For: 1.1
>
>
> This format results in the following subject line.
> [MSVC Doc] BUILD ${state}: ${project.name} -
> ${project.version} - ${project.scmTag}
> [MSVC Doc] BUILD SUCCESSFUL: dataobject-allergy - 1.0-SNAPSHOT -
> ${project.scmTag}
> This seems to occur with any combination where the 4th variable is treated as
> a literal.
--
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-3266) maven-model RepositoryBase overrides equals() but not hashCode()
[ http://jira.codehaus.org/browse/MNG-3266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jared Roberts updated MNG-3266: --- Attachment: MNG-3266-maven-model-v2.patch The first version of this patch had a NPE in hashCode() since "217 + null != null". I opted to just use the tag instead of implementing these methods. > maven-model RepositoryBase overrides equals() but not hashCode() > > > Key: MNG-3266 > URL: http://jira.codehaus.org/browse/MNG-3266 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.7 >Reporter: Jared Roberts >Priority: Minor > Attachments: MNG-3266-maven-model-v2.patch, MNG-3266-maven-model.patch > > > Overriding equals and not hashCode is considered bad practice. Also, while > looking around, I noticed the two subclasses (Repository and > PluginRepository) both override equals and just call "super.equals()". There > is a cryptic comment nearby that leads me to believe this is a temporary fix > for an old problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSOURCES-17) Source plugin packages each module with *all* module's sources, in multi-module build
[ http://jira.codehaus.org/browse/MSOURCES-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dennis Lundberg closed MSOURCES-17. --- Resolution: Cannot Reproduce > Source plugin packages each module with *all* module's sources, in > multi-module build > - > > Key: MSOURCES-17 > URL: http://jira.codehaus.org/browse/MSOURCES-17 > Project: Maven 2.x Source Plugin > Issue Type: Bug >Reporter: Howard M. Lewis Ship > > Just upgraded from 2.0.4 to 2.0.5. > Performed a mvn clean install on my project. > Everything built correctly, but the source plugin: > > > org.apache.maven.plugins > > maven-source-plugin > > > > jar > > > > > Packaged each sub-module's -sources.jar with all the sources from all the > modules. -- 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: (MECLIPSE-213) more jee support for wtp
[ http://jira.codehaus.org/browse/MECLIPSE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112891 ] Richard van Nieuwenhoven commented on MECLIPSE-213: --- The NPE is fixed (with tests) in the patch for MECLIPSE-333. I am looking into a way to detect current projects / artifacts in the workspace, but for now use the multi module builds for them. If they are not an option for your case, use a "build" pom that references all projects in your workspace (this way they will be linked together) . > more jee support for wtp > > > Key: MECLIPSE-213 > URL: http://jira.codehaus.org/browse/MECLIPSE-213 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: linux suse 10.0 eclipse 3.2.1 and wtp 1.5.1 java 1.5.0_8 >Reporter: Richard van Nieuwenhoven >Assignee: Brian Fox > Fix For: 2.5 > > Attachments: maven-eclipse-plugin-2.3-CFC-2007-03-08.patch, > maven-eclipse-plugin-2.3-PATCH-2007-03-08.tgz, > maven-eclipse-plugin-R494407.patch, maven-eclipse-plugin.patch > > > I tried the new release 2.3 of the eclipse plugin and noteted that not alle > of my paches where included. > I re-pached the 2.3 version again this time i made my changes configurable so > they can be turned on and off. > my changes: > - prohibit dupicate entries in the classpath > provided system paths in combination with log4j/commons-logging/xerces > can easely create such problems > - system paths are only included in ears and war when they are inside the > project >bether behavior would be to exclude all system paths because the war and > ear plugin also ignore these > - an application.xml specialy for eclipse-wtp >this makes wtp ears function correctly it includes the eclipse project > modules instead of the maven generated jars > - manifest generation for wtp >wtp needs manifest files, but not the ones maven creates because they have > version names for all modules etc >this generates a wtp manifest that will be in a ons eclipse source > directory that is ignored my maven itself > use the parameters -Declipse.wtpmanifest=true > -Declipse.wtpapplicationxml=true to acivate the patch. > The manifest generator could be combined with the RadManifestWriter in the > future, they are almost the same. > regards, > Ritchie -- 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: (MANTTASKS-22) artifact:dependencies does not respect in the generated classpath the order of the dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy closed MANTTASKS-22. -- Assignee: Herve Boutemy Resolution: Fixed Fix Version/s: 2.0.8 fixed in r you can test it using latest SNAPSHOT in http://maven.zones.apache.org/continuum/workingCopy.action?projectId=524&projectName=Maven+Ant+Task&userDirectory=target > artifact:dependencies does not respect in the generated classpath the order > of the dependencies > --- > > Key: MANTTASKS-22 > URL: http://jira.codehaus.org/browse/MANTTASKS-22 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: dependencies task >Affects Versions: 2.0.4 > Environment: Windows 2005 > Ant 1.6.5 > JDK 1.4.2_10 >Reporter: Aurélien Lacenaire >Assignee: Herve Boutemy > Fix For: 2.0.8 > > Attachments: mavenTestClasspath.tgz > > > For example, if I put the dependencies in this order, in the generated > classpath (dependency.classpath) the order of the jars seems to be different : > filesetId="dependency.fileset" useScope="runtime"> > > > > > > the order in the generated classpath dependency.classpath is not the same as : > > > > > > And my projects have to use those jars in a specific order, otherwhise the > build fails. -- 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-3272) new URI( url.toString() ) when using a jar path with a space in it results in error
[ http://jira.codehaus.org/browse/MNG-3272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3272. --- Assignee: John Casey Resolution: Fixed Fix Version/s: 2.1-alpha-1 Changed: new URI( url.toString() ); to: new URI( url.toString().replaceAll( " ", "%20" ); which should fix the most common problem related to paths (i.e. paths with spaces in them) > new URI( url.toString() ) when using a jar path with a space in it results in > error > --- > > Key: MNG-3272 > URL: http://jira.codehaus.org/browse/MNG-3272 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > Fix For: 2.1-alpha-1 > > > When maven.home contains a space, reading the super-POM from the > maven-project jar results in: > Error stacktrace: > org.apache.maven.reactor.MavenExecutionException: Error scanning for > extensions: Error building super-POM for retrieving the default remote > repository list: Failed build model from URL 'jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' > Error: 'Illegal character in opaque part at index 20: jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' > for project org.apache.maven:super-pom > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:286) > at > org.apache.maven.DefaultMaven.createReactorManager(DefaultMaven.java:109) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:166) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:784) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:179) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:71) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:597) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) > Caused by: org.apache.maven.extension.ExtensionScanningException: Error > building super-POM for retrieving the default remote repository list: Failed > build model from URL 'jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' > Error: 'Illegal character in opaque part at index 20: jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' > for project org.apache.maven:super-pom > at > org.apache.maven.extension.DefaultBuildExtensionScanner.getInitialRemoteRepositories(DefaultBuildExtensionScanner.java:357) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:109) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.scanForBuildExtensions(DefaultBuildExtensionScanner.java:81) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:282) > ... 13 more > Caused by: org.apache.maven.project.ProjectBuildingException: Failed build > model from URL 'jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' > Error: 'Illegal character in opaque part at index 20: jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' > for project org.apache.maven:super-pom > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1073) > at > org.apache.maven.project.DefaultMavenProjectBuilder.getSuperModel(DefaultMavenProjectBuilder.java:1281) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildStandaloneSuperProject(DefaultMavenProjectBuilder.java:228) > at > org.apache.maven.extension.DefaultBuildExtensionScanner.getInitialRemoteRepositories(DefaultBuildExtensionScanner.java:353) > ... 16 more > Caused by: java.net.URISyntaxException: Illegal character in opaque part at > index 20: jar:file:/c:/Program > Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml > at java.net.URI$Parser
[jira] Issue Comment Edited: (MECLIPSE-213) more jee support for wtp
[ http://jira.codehaus.org/browse/MECLIPSE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112885 ] Shelley Baker edited comment on MECLIPSE-213 at 11/5/07 3:20 PM: - I've grabbed the snapshot and have done some preliminary testing of this bug. It looks good so far. I have one comment which _may_ be outside the scope of this particular bug, but is very closely related to better JEE support with maven and wtp -- when generating the wtp-friendly projects (eclipseEar, etc.), is it possible to reference the available projects from the workspace rather than maven repository? For example, referencing an EAR's modules from the local repo instead of the workspace nearly defeats the purpose of developing JEE apps within the IDE. It would be nice if all Eclipse-generated configuration files would have the ability to reference projects within the workspace when desired, but in particular, the .component file within an EAR should reference the modules available within the workspace. This bug fix will resolve several maven/wtp woes, but the lack of workspace references is one major outstanding issue. (This comment is also related to MECLIPSE-74.) was: I've grabbed the snapshot and have done some preliminary testing of this bug. It looks good so far. I have one comment which *may* be outside the scope of this particular bug, but is very closely related to better JEE support with maven and wtp -- when generating the wtp-friendly projects (eclipseEar, etc.), is it possible to reference the available projects from the workspace rather than maven repository? For example, referencing an EAR's modules from the local repo instead of the workspace nearly defeats the purpose of developing JEE apps within the IDE. It would be nice if all Eclipse-generated configuration files would have the ability to reference projects within the workspace when desired, but in particular, the .component file within an EAR should reference the modules available within the workspace. This bug fix will resolve several maven/wtp woes, but the lack of workspace references is one major outstanding issue. (This comment is also related to MECLIPSE-74.) > more jee support for wtp > > > Key: MECLIPSE-213 > URL: http://jira.codehaus.org/browse/MECLIPSE-213 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: linux suse 10.0 eclipse 3.2.1 and wtp 1.5.1 java 1.5.0_8 >Reporter: Richard van Nieuwenhoven >Assignee: Brian Fox > Fix For: 2.5 > > Attachments: maven-eclipse-plugin-2.3-CFC-2007-03-08.patch, > maven-eclipse-plugin-2.3-PATCH-2007-03-08.tgz, > maven-eclipse-plugin-R494407.patch, maven-eclipse-plugin.patch > > > I tried the new release 2.3 of the eclipse plugin and noteted that not alle > of my paches where included. > I re-pached the 2.3 version again this time i made my changes configurable so > they can be turned on and off. > my changes: > - prohibit dupicate entries in the classpath > provided system paths in combination with log4j/commons-logging/xerces > can easely create such problems > - system paths are only included in ears and war when they are inside the > project >bether behavior would be to exclude all system paths because the war and > ear plugin also ignore these > - an application.xml specialy for eclipse-wtp >this makes wtp ears function correctly it includes the eclipse project > modules instead of the maven generated jars > - manifest generation for wtp >wtp needs manifest files, but not the ones maven creates because they have > version names for all modules etc >this generates a wtp manifest that will be in a ons eclipse source > directory that is ignored my maven itself > use the parameters -Declipse.wtpmanifest=true > -Declipse.wtpapplicationxml=true to acivate the patch. > The manifest generator could be combined with the RadManifestWriter in the > future, they are almost the same. > regards, > Ritchie -- 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: (MECLIPSE-213) more jee support for wtp
[ http://jira.codehaus.org/browse/MECLIPSE-213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112885 ] Shelley Baker commented on MECLIPSE-213: I've grabbed the snapshot and have done some preliminary testing of this bug. It looks good so far. I have one comment which *may* be outside the scope of this particular bug, but is very closely related to better JEE support with maven and wtp -- when generating the wtp-friendly projects (eclipseEar, etc.), is it possible to reference the available projects from the workspace rather than maven repository? For example, referencing an EAR's modules from the local repo instead of the workspace nearly defeats the purpose of developing JEE apps within the IDE. It would be nice if all Eclipse-generated configuration files would have the ability to reference projects within the workspace when desired, but in particular, the .component file within an EAR should reference the modules available within the workspace. This bug fix will resolve several maven/wtp woes, but the lack of workspace references is one major outstanding issue. (This comment is also related to MECLIPSE-74.) > more jee support for wtp > > > Key: MECLIPSE-213 > URL: http://jira.codehaus.org/browse/MECLIPSE-213 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.3 > Environment: linux suse 10.0 eclipse 3.2.1 and wtp 1.5.1 java 1.5.0_8 >Reporter: Richard van Nieuwenhoven >Assignee: Brian Fox > Fix For: 2.5 > > Attachments: maven-eclipse-plugin-2.3-CFC-2007-03-08.patch, > maven-eclipse-plugin-2.3-PATCH-2007-03-08.tgz, > maven-eclipse-plugin-R494407.patch, maven-eclipse-plugin.patch > > > I tried the new release 2.3 of the eclipse plugin and noteted that not alle > of my paches where included. > I re-pached the 2.3 version again this time i made my changes configurable so > they can be turned on and off. > my changes: > - prohibit dupicate entries in the classpath > provided system paths in combination with log4j/commons-logging/xerces > can easely create such problems > - system paths are only included in ears and war when they are inside the > project >bether behavior would be to exclude all system paths because the war and > ear plugin also ignore these > - an application.xml specialy for eclipse-wtp >this makes wtp ears function correctly it includes the eclipse project > modules instead of the maven generated jars > - manifest generation for wtp >wtp needs manifest files, but not the ones maven creates because they have > version names for all modules etc >this generates a wtp manifest that will be in a ons eclipse source > directory that is ignored my maven itself > use the parameters -Declipse.wtpmanifest=true > -Declipse.wtpapplicationxml=true to acivate the patch. > The manifest generator could be combined with the RadManifestWriter in the > future, they are almost the same. > regards, > Ritchie -- 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: (MAVENUPLOAD-1790) jline 0.9.92
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112880 ] Jason Dillon commented on MAVENUPLOAD-1790: --- Can we please get this uploaded? > jline 0.9.92 > > > Key: MAVENUPLOAD-1790 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1790 > Project: maven-upload-requests > Issue Type: Task >Reporter: Marc Prud'hommeaux > > JLine is a popular Java library for handling console input. It is similar in > functionality to BSD editline and GNU readline. People familiar with the > readline/editline capabilities for modern shells (such as bash and tcsh) will > find most of the command editing features of JLine to be familiar. > See also: http://jira.codehaus.org/browse/MAVENUPLOAD-1003 -- 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: (MANTTASKS-22) artifact:dependencies does not respect in the generated classpath the order of the dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-22: --- Affects Version/s: 2.0.4 > artifact:dependencies does not respect in the generated classpath the order > of the dependencies > --- > > Key: MANTTASKS-22 > URL: http://jira.codehaus.org/browse/MANTTASKS-22 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Components: dependencies task >Affects Versions: 2.0.4 > Environment: Windows 2005 > Ant 1.6.5 > JDK 1.4.2_10 >Reporter: Aurélien Lacenaire > Attachments: mavenTestClasspath.tgz > > > For example, if I put the dependencies in this order, in the generated > classpath (dependency.classpath) the order of the jars seems to be different : > filesetId="dependency.fileset" useScope="runtime"> > > > > > > the order in the generated classpath dependency.classpath is not the same as : > > > > > > And my projects have to use those jars in a specific order, otherwhise the > build fails. -- 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: (MANTTASKS-86) Resolution of java.net dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112877 ] Herve Boutemy commented on MANTTASKS-86: ok, I understand I didn't have any problems when trying it, but I was using Maven Ant Tasks 2.0.8-SNAPSHOT, and I think you were hit by MANTTASKS-78: you define mutliple remote repositories, which is not well supported in 2.0.7 can you check that you don't have any problem now with 2.0.8-SNAPSHOT (available in http://maven.zones.apache.org/continuum/workingCopy.action?projectId=524&projectName=Maven+Ant+Task&userDirectory=target) > Resolution of java.net dependencies > --- > > Key: MANTTASKS-86 > URL: http://jira.codehaus.org/browse/MANTTASKS-86 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Werner Guttmann > Attachments: build.bat, build.xml, pom.xml > > > I am trying to use the Ant task for Maven with the root Maven POM for > the Castor project for download the dependencies and place them into a > lib directory. > What I have observed is that there's a few dependencies missing when I > run the corresponding Ant target. But if I use Maven for the build > process, the missing JARs are downloaded as well and placed into my > local repository. > I have tried to define remoteRepository entries for the java.net and the > Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B > resides), but this does not make a difference. > Any idea what I could try in addition ? Having said that, all other > dependencies are resolved and copied without any problems. It looks like > it's just the dependencies that are not synced globally that create a > problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-339) Add facet version configuration parameters
[ http://jira.codehaus.org/browse/MECLIPSE-339?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112872 ] Shelley B commented on MECLIPSE-339: It looks like there already are some dependencies between the maven-eclipse-plugin and other plugin configuration. For example, the resolution for MECLIPSE-213 involves dependencies on the maven-ear-plugin configuration. If some tight coupling is allowed and is already used between the maven-eclipse-plugin and maven-ear-plugin, probably the most logical resolution for this issue is to simply read the ear version from the maven-ear-plugin if it exists. The ear facet version may be determined in the following order: (1) maven-eclipse-plugin jst.ear facet configuration (2) maven-ear-plugin version parameter, (3) j2ee dependency version. > Add facet version configuration parameters > -- > > Key: MECLIPSE-339 > URL: http://jira.codehaus.org/browse/MECLIPSE-339 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: WTP support >Affects Versions: 2.4 >Reporter: Shelley B > > The maven-eclipse-plugin uses the declared dependencies within the POM to > determine the facet versions in an EAR project, however, there may be a > better approach. > The JEE jar is rarely, if ever, actually required by the EAR since it is > provided by the container. Requiring an unnecessary dependency to be > configured for the project, only to satisfy the maven-eclipse-plugin's > configuration seems to violate Maven's principle of separation of concerns. > (Further, due to licensing, the j2ee jars are not available in the central > repository, so an install of this jar may be required just to allow for > successful execution of the maven-eclipse-plugin.) If these jars are already > declared in the POM, it makes sense to take advantage of them (to minimize > configuration), however, in most cases, when the JEE jar is not a true > dependency, it seems like an invalid workaround for determining the project > facets in an EAR. > Adding an "earVersion" configuration parameter, or simply allowing project > facets to be configured (overridden) in configuration might be a better > approach. (Currently, the maven-eclipse-plugin allows > "additionalProjectFacets" but does not allow the versions to be overridden.) -- 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: (CONTINUUM-1543) Email Subject line templates support only 3 name variables.
[
http://jira.codehaus.org/browse/CONTINUUM-1543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112870
]
Bryan Madsen commented on CONTINUUM-1543:
-
${project.scmUrl} does work. This may be more of a documentation issue. I
thought "project" referred to the pom "project". What are the possible values
for the Continuum "project" and "build" attributes? Is there documentation that
describes this?
> Email Subject line templates support only 3 name variables.
> ---
>
> Key: CONTINUUM-1543
> URL: http://jira.codehaus.org/browse/CONTINUUM-1543
> Project: Continuum
> Issue Type: Bug
>Affects Versions: 1.1-beta-4
>Reporter: Bryan Madsen
>Priority: Trivial
> Fix For: 1.1
>
>
> This format results in the following subject line.
> [MSVC Doc] BUILD ${state}: ${project.name} -
> ${project.version} - ${project.scmTag}
> [MSVC Doc] BUILD SUCCESSFUL: dataobject-allergy - 1.0-SNAPSHOT -
> ${project.scmTag}
> This seems to occur with any combination where the 4th variable is treated as
> a literal.
--
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: (MANTTASKS-86) Resolution of java.net dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112866 ] Werner Guttmann commented on MANTTASKS-86: -- I am talking about the case where the JTA JAR is *not* installed into your local Maven repository, but where the given java.net repository should be used for dependency resolution. Given that the JAR eventually has been made available publically, we prefer that option. My problem is that Maven itself does not have any problems resolving that dependency and downloades the JAR into my local repo just fine. Whereas the Ant tasks for Maven only download the JARs that are available in standard public Maven 2 repos. > Resolution of java.net dependencies > --- > > Key: MANTTASKS-86 > URL: http://jira.codehaus.org/browse/MANTTASKS-86 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Werner Guttmann > Attachments: build.bat, build.xml, pom.xml > > > I am trying to use the Ant task for Maven with the root Maven POM for > the Castor project for download the dependencies and place them into a > lib directory. > What I have observed is that there's a few dependencies missing when I > run the corresponding Ant target. But if I use Maven for the build > process, the missing JARs are downloaded as well and placed into my > local repository. > I have tried to define remoteRepository entries for the java.net and the > Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B > resides), but this does not make a difference. > Any idea what I could try in addition ? Having said that, all other > dependencies are resolved and copied without any problems. It looks like > it's just the dependencies that are not synced globally that create a > problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-339) Add facet version configuration parameters
Add facet version configuration parameters -- Key: MECLIPSE-339 URL: http://jira.codehaus.org/browse/MECLIPSE-339 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: WTP support Affects Versions: 2.4 Reporter: Shelley B The maven-eclipse-plugin uses the declared dependencies within the POM to determine the facet versions in an EAR project, however, there may be a better approach. The JEE jar is rarely, if ever, actually required by the EAR since it is provided by the container. Requiring an unnecessary dependency to be configured for the project, only to satisfy the maven-eclipse-plugin's configuration seems to violate Maven's principle of separation of concerns. (Further, due to licensing, the j2ee jars are not available in the central repository, so an install of this jar may be required just to allow for successful execution of the maven-eclipse-plugin.) If these jars are already declared in the POM, it makes sense to take advantage of them (to minimize configuration), however, in most cases, when the JEE jar is not a true dependency, it seems like an invalid workaround for determining the project facets in an EAR. Adding an "earVersion" configuration parameter, or simply allowing project facets to be configured (overridden) in configuration might be a better approach. (Currently, the maven-eclipse-plugin allows "additionalProjectFacets" but does not allow the versions to be overridden.) -- 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-3272) new URI( url.toString() ) when using a jar path with a space in it results in error
new URI( url.toString() ) when using a jar path with a space in it results in error --- Key: MNG-3272 URL: http://jira.codehaus.org/browse/MNG-3272 Project: Maven 2 Issue Type: Bug Components: POM Affects Versions: 2.1-alpha-1 Reporter: John Casey Priority: Blocker When maven.home contains a space, reading the super-POM from the maven-project jar results in: Error stacktrace: org.apache.maven.reactor.MavenExecutionException: Error scanning for extensions: Error building super-POM for retrieving the default remote repository list: Failed build model from URL 'jar:file:/c:/Program Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' Error: 'Illegal character in opaque part at index 20: jar:file:/c:/Program Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' for project org.apache.maven:super-pom at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:286) at org.apache.maven.DefaultMaven.createReactorManager(DefaultMaven.java:109) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:166) at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:784) at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:179) at org.apache.maven.cli.MavenCli.main(MavenCli.java:71) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) at org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) at org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) at org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) Caused by: org.apache.maven.extension.ExtensionScanningException: Error building super-POM for retrieving the default remote repository list: Failed build model from URL 'jar:file:/c:/Program Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' Error: 'Illegal character in opaque part at index 20: jar:file:/c:/Program Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' for project org.apache.maven:super-pom at org.apache.maven.extension.DefaultBuildExtensionScanner.getInitialRemoteRepositories(DefaultBuildExtensionScanner.java:357) at org.apache.maven.extension.DefaultBuildExtensionScanner.scanInternal(DefaultBuildExtensionScanner.java:109) at org.apache.maven.extension.DefaultBuildExtensionScanner.scanForBuildExtensions(DefaultBuildExtensionScanner.java:81) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:282) ... 13 more Caused by: org.apache.maven.project.ProjectBuildingException: Failed build model from URL 'jar:file:/c:/Program Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' Error: 'Illegal character in opaque part at index 20: jar:file:/c:/Program Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml' for project org.apache.maven:super-pom at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1073) at org.apache.maven.project.DefaultMavenProjectBuilder.getSuperModel(DefaultMavenProjectBuilder.java:1281) at org.apache.maven.project.DefaultMavenProjectBuilder.buildStandaloneSuperProject(DefaultMavenProjectBuilder.java:228) at org.apache.maven.extension.DefaultBuildExtensionScanner.getInitialRemoteRepositories(DefaultBuildExtensionScanner.java:353) ... 16 more Caused by: java.net.URISyntaxException: Illegal character in opaque part at index 20: jar:file:/c:/Program Files/maven2.1/bin/../lib/maven-project-2.1-SNAPSHOT.jar!/org/apache/maven/project/pom-4.0.0.xml at java.net.URI$Parser.fail(URI.java:2809) at java.net.URI$Parser.checkChars(URI.java:2982) at java.net.URI$Parser.parse(URI.java:3019) at java.net.URI.(URI.java:578) at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1062) ... 19 more This is because URI instances cannot contain spaces, and the following code is used to translate this jar path into a URI: uri = new URI( url.toString() ); //DefaultMavenProjectBuilder.readModel(String, URL, boolean): Model (revId: 58) -- This message is automatically generated by JIRA. - If
[jira] Commented: (CONTINUUM-1547) data-management-cli import cannot handle testResult entities in build.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112850 ] Bastiaan Bakker commented on CONTINUUM-1547: as a workaround, the attached XSLT removes all entities. usage (on Linux): xsltproc copy.xsl builds.xml > fixed-builds.xml > data-management-cli import cannot handle testResult entities in build.xml > - > > Key: CONTINUUM-1547 > URL: http://jira.codehaus.org/browse/CONTINUUM-1547 > Project: Continuum > Issue Type: Bug > Components: Data Management >Affects Versions: 1.1-beta-4 >Reporter: Bastiaan Bakker >Priority: Minor > Attachments: copy.xsl > > > According to the upgrade docs one needs to filter out all > entities from the export builds.xml. > The import job should be able to handle or ignore these instead. -- 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: (CONTINUUM-1547) data-management-cli import cannot handle testResult entities in build.xml
data-management-cli import cannot handle testResult entities in build.xml - Key: CONTINUUM-1547 URL: http://jira.codehaus.org/browse/CONTINUUM-1547 Project: Continuum Issue Type: Bug Components: Data Management Affects Versions: 1.1-beta-4 Reporter: Bastiaan Bakker Priority: Minor Attachments: copy.xsl According to the upgrade docs one needs to filter out all entities from the export builds.xml. The import job should be able to handle or ignore these instead. -- 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: (CONTINUUM-1547) data-management-cli import cannot handle testResult entities in build.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bastiaan Bakker updated CONTINUUM-1547: --- Attachment: copy.xsl XSLT scriptlet that removes testResult entities > data-management-cli import cannot handle testResult entities in build.xml > - > > Key: CONTINUUM-1547 > URL: http://jira.codehaus.org/browse/CONTINUUM-1547 > Project: Continuum > Issue Type: Bug > Components: Data Management >Affects Versions: 1.1-beta-4 >Reporter: Bastiaan Bakker >Priority: Minor > Attachments: copy.xsl > > > According to the upgrade docs one needs to filter out all > entities from the export builds.xml. > The import job should be able to handle or ignore these instead. -- 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-3097) Build extension not working if not placed in the pom.xml where a reactor build is initiated
[ http://jira.codehaus.org/browse/MNG-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112848 ] Vincent Massol commented on MNG-3097: - John/Brett, This has never worked in 2.0.7 to my knowledge. I guess the "affects version" should be 2.0.7 then and not alpha-1. Thanks -Vincent > Build extension not working if not placed in the pom.xml where a reactor > build is initiated > --- > > Key: MNG-3097 > URL: http://jira.codehaus.org/browse/MNG-3097 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1-alpha-1 >Reporter: Vincent Massol > Fix For: 2.1-alpha-1 > > > If I have a multi module build and if the build extension is located in one > of the sub modules being built it's ignored. It has to be placed in the > pom.xml where the multi module build is initiated to be taken into account. -- 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-3097) Build extension not working if not placed in the pom.xml where a reactor build is initiated
[ http://jira.codehaus.org/browse/MNG-3097?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112847 ] John Casey commented on MNG-3097: - This has never worked, to my knowledge. Or at least, I can't see how we could guarantee that any but a handful of things in that extension would be usable in that build. This is because the lifecycle executor (and, in 2.1, the extension scanner) pushes extensions into the core realm. When it does this, I don't think it's particularly sensitive to artfiacts that come from within the existing build process. I haven't looked back at the 2.0.x code on this yet, but I'm pretty sure active artifacts are not in use, and that extensions are all loaded up front when the lifecycle executor runs...which means that if the extension project hasn't been built yet, and no previous artifact for that extension is in the repository, it won't load. Vincent, are you certain this works in 2.0.7? > Build extension not working if not placed in the pom.xml where a reactor > build is initiated > --- > > Key: MNG-3097 > URL: http://jira.codehaus.org/browse/MNG-3097 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.1-alpha-1 >Reporter: Vincent Massol > Fix For: 2.1-alpha-1 > > > If I have a multi module build and if the build extension is located in one > of the sub modules being built it's ignored. It has to be placed in the > pom.xml where the multi module build is initiated to be taken into account. -- 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-3206) Changes to MavenSettingsBuilder breaks backward compatibility
[ http://jira.codehaus.org/browse/MNG-3206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MNG-3206. --- Assignee: John Casey Resolution: Fixed handled by the backward compat aspect now. > Changes to MavenSettingsBuilder breaks backward compatibility > - > > Key: MNG-3206 > URL: http://jira.codehaus.org/browse/MNG-3206 > Project: Maven 2 > Issue Type: Bug > Components: Settings >Affects Versions: 2.1-alpha-1 >Reporter: John Casey >Assignee: John Casey >Priority: Blocker > Fix For: 2.1-alpha-1 > > > When I tried to run a the component-it-plugin from maven sandbox during an > integration-test run on the assembly plugin with a Maven build from Sept. 10, > 2007, I got the following: > Exception in thread "main" java.lang.NoSuchMethodError: > org.apache.maven.settings.MavenSettingsBuilder.buildSettings()Lorg/apache/maven/settings/Settings; > at > org.apache.maven.shared.test.plugin.RepositoryTool.findLocalRepositoryDirectory(RepositoryTool.java:100) > at > org.apache.maven.shared.test.plugin.ProjectTool.manglePomForTesting(ProjectTool.java:301) > at > org.apache.maven.shared.test.plugin.ProjectTool.packageProjectArtifact(ProjectTool.java:168) > at > org.apache.maven.shared.test.plugin.ComponentTestTool.prepareForTesting(ComponentTestTool.java:180) > at > org.apache.maven.shared.test.plugin.ComponentTestTool.prepareComponentForUnitTestingWithMavenBuilds(ComponentTestTool.java:121) > at > org.apache.maven.plugin.componentit.StagingBuildMojo.execute(StagingBuildMojo.java:90) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:650) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:419) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:293) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:150) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:219) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:819) > at org.apache.maven.cli.MavenCli.doMain(MavenCli.java:418) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:85) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launchEnhanced(Launcher.java:289) > at > org.codehaus.plexus.classworlds.launcher.Launcher.launch(Launcher.java:229) > at > org.codehaus.plexus.classworlds.launcher.Launcher.mainWithExitCode(Launcher.java:408) > at > org.codehaus.plexus.classworlds.launcher.Launcher.main(Launcher.java:351) > This is a backward compatibility issue, and should be addressed in order to > ensure smooth migrations from 2.0.x to 2.1-alpha-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: (MRM-578) unfinished scanning after NPE
unfinished scanning after NPE - Key: MRM-578 URL: http://jira.codehaus.org/browse/MRM-578 Project: Archiva Issue Type: Bug Components: repository scanning Affects Versions: 1.0-beta-3 Environment: macosx 1.4, jdk 1.5, archiva beta3 Reporter: Milos Kleint Attachments: error.txt I repeatedly tried to index a mirror of central repository. In previous attempts, usually got "Too many files opened" kind of errors. This time it's a NPE, see attached console output -- 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: (CONTINUUM-1546) There should be a way to simply create a project group without having to add a project
There should be a way to simply create a project group without having to add a project -- Key: CONTINUUM-1546 URL: http://jira.codehaus.org/browse/CONTINUUM-1546 Project: Continuum Issue Type: Improvement Components: XMLRPC Interface Affects Versions: 1.1-beta-4 Reporter: Steven Cummings Currently, there is no way to create a project group on it's own. The only way is to add a project without passing a project group id and get the new project group summary from the add-project results, and modify it if I need to. This means that initially, the name of the project group is based on the groupId of the project that was added. That means that I can't do an automated add of one project to two different groups that don't yet exist. -- 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-3262) Problem accessing dependency resource via reflection in maven 2 plugin
[
http://jira.codehaus.org/browse/MNG-3262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112832
]
Gary S. Weaver commented on MNG-3262:
-
Just curious... wouldn't everyone think that you could load properties from one
of the "provided" scoped dependencies within a maven 2 plugin, or am I smoking
crack?
> Problem accessing dependency resource via reflection in maven 2 plugin
> --
>
> Key: MNG-3262
> URL: http://jira.codehaus.org/browse/MNG-3262
> Project: Maven 2
> Issue Type: Bug
> Components: Plugins and Lifecycle
>Affects Versions: 2.0.7
>Reporter: Gary S. Weaver
> Fix For: 2.0.x
>
> Attachments: trunk-exampleproject.tgz, trunk-i18nsanity-pt.tgz
>
>
> I've written a Maven 2 mojo that is having trouble instantiating (via
> reflection) a properties resource of dependency that is included as a
> "compile"-scope dependency in the project (pom.xml) that is utilizing my
> plugin.
> (Even though I need the plugin to access a dependency that is in "provided"
> scope, for now I'm using compile scope since the maven documentation states
> that @requiresDependencyResolution doesn't support provided scope.)
> Here are the details:
> 1) I have the following dependency:
> ---start---
>
>
> com.atlassian.confluence
> confluence
> 2.6.0
> compile
>
>
> ---end---
> 2) In the pom.xml of the project that utilizes my plugin, the mojo of the
> plugin I wrote is configured with the execution:
> ---start---
>
> get_ConfluenceActionSupport.properties
> compile
>
> extractProperties
>
>
>
> com.atlassian.confluence.core.ConfluenceActionSupport.properties
>
> target/classes/com/atlassian/confluence/core/ConfluenceActionSupport.properties
>
>
> ---end---
> 3) In the Maven 2 mojo it calls the following code (just copied/pasted the
> relevant portion):
> ---start---
> // load properties with reflection and save to file
> InputStream in = null;
> OutputStream out = null;
> boolean foundFile = false;
> try {
> String resource = cleanResourceName(fullyQualifiedProperties);
> System.out.println("Getting " + resource);
> in = getClass().getResourceAsStream (resource);
> if (in != null)
> {
> Properties result = new Properties();
> result.load (in); // Can throw IOException
> out = new BufferedOutputStream(new
> FileOutputStream(outputPathname));
> result.store(out, "");
> foundFile = true;
> }
> }
> ---end---
> When executed, it can't find the properties file in the classloader. As you
> can see from the following output, I'm putting the resource string together
> correctly as
> "/com/atlassian/confluence/core/ConfluenceActionSupport.properties" which if
> you interrogate the above confluence dependency, you should be able to find.
> ---start---
> [INFO] [i18nsanity-pt:extractProperties {execution:
> get_ConfluenceActionSupport.properties}]
> [INFO] Extracting properties file from classpath...
> fullyQualifiedProperties=com.atlassian.confluence.core.ConfluenceActionSupport.properties
>
> outputFile=/usr/svn/community/confluence/plugins/americanenglishlanguagepack/trunk/target/classes/com/atlassian/confluence/core/ConfluenceActionSupport.properties
> Getting /com/atlassian/confluence/core/ConfluenceActionSupport.properties
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed properties extraction!
> Embedded error: Could not find properties file on classpath:
> com.atlassian.confluence.core.ConfluenceActionSupport.properties
> ---end---
> Thanks!
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-261) release:prepare shouls support flat directory multimodule projects
[ http://jira.codehaus.org/browse/MRELEASE-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112827 ] Henrik Dohlmann commented on MRELEASE-261: -- Hi John, Any news on the patch? I have browsed the repository, but it doesn't look like any fixes has been applied regarding this issue. > release:prepare shouls support flat directory multimodule projects > -- > > Key: MRELEASE-261 > URL: http://jira.codehaus.org/browse/MRELEASE-261 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: linux / maven2 / svn >Reporter: [EMAIL PROTECTED] > > What I mean by flat file structure firstly. > parent/pom.xml > module1/pom.xml > module2/pom.xml > . > . > . > module15/pom.xml > the parent references the modules like so > > ../module1 > ../module2 > . > . > . > ../module15 > > When i release:prepare only the parent project is tagged the modules > projects versions are incremented etc but the modules are not tagged in svn. > I use this structure as i use eclipse as my IDE. > I would love to see a fix for the issue marked as closed here > http://jira.codehaus.org/browse/MRELEASE-138. I am currenrly tagging by hand > each submodule of the projects but it would be so nice to have the release > plugin do this for me. > forgive my english. -- 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: (MRM-312) ConcurrentModificationException
[ http://jira.codehaus.org/browse/MRM-312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] amouche habiba updated MRM-312: --- Attachment: esup-commons-formation-support.pdf rien > ConcurrentModificationException > --- > > Key: MRM-312 > URL: http://jira.codehaus.org/browse/MRM-312 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-alpha-1 > Environment: tomcat 5.5 windows 2000 jdk SUN 1.5 archiva SNAPSHOT >Reporter: nicolas de loof >Priority: Critical > Fix For: 1.x > > Attachments: esup-commons-formation-support.pdf > > > Archiva is deployed as maven repository proxy for my company > I get ConcurrentModificationExceptions in logs, that looks from maven-side as > HTTP 500. > This is related to WAGON-79. > Solving this issue requires to upgrade dependency to Wagon-2.0-SNAPSHOT. The > 2.0 branch introduces some new methods on Wagon interface that requires some > simple changes in archiva code, like adding delegates methods in > org.apache.maven.archiva.proxy.WagonDelegate -- 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: (MRM-540) [regression] reports now show 0 results as a paged result that is empty
[ http://jira.codehaus.org/browse/MRM-540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-540. Resolution: Fixed > [regression] reports now show 0 results as a paged result that is empty > --- > > Key: MRM-540 > URL: http://jira.codehaus.org/browse/MRM-540 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-beta-2 >Reporter: Brett Porter >Assignee: Brett Porter > Fix For: 1.0-beta-4 > > > in the past, I remember getting a good error message when the reports > returned 0 results, but now I just get: > Page: 1 >> > The links do nothing. > Also, I'm not sure why the text in the menu was changed to "pick report"? > It's not like one is being selected for later use, and the other menu items > under that menu are not verbs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (ARCHETYPE-70) Add project description as a mojo parameter
[
http://jira.codehaus.org/browse/ARCHETYPE-70?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112810
]
Viktor Nordling commented on ARCHETYPE-70:
--
In the mailing list, Jeff Black wrote that "If there is interest in this
functionality, let me know at the filed issue". So hereby I am letting you know
that there is interest. : )
Cheers,
Viktor Nordling
> Add project description as a mojo parameter
> ---
>
> Key: ARCHETYPE-70
> URL: http://jira.codehaus.org/browse/ARCHETYPE-70
> Project: Maven Archetype
> Issue Type: New Feature
> Components: Plugin
>Reporter: Michael Heuer
>Priority: Minor
> Attachments: patch.txt
>
>
> For my archetype bundle, I require the project description as a parameter.
> I use it in the pom.xml
> ${description}
> in a license HEADER.txt
> /*
> ${artifactId} ${description}
> Copyright ...
> in a package.html
>
>
> ${description}
>
>
> and so on.
> The attached patch to MavenArchetypeMojo.java provides a project description
> parameter in addition to project groupId, artifactId, and version:
> $ mvn -X archetype:create
> -DgroupId=foo
> -DartifactId=bar
> -Dversion=1.0-SNAPSHOT
> -Ddescription="bar description." ...
--
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: (CONTINUUM-884) svn metadata not properly shown in Build Result or Email Notification
[ http://jira.codehaus.org/browse/CONTINUUM-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112807 ] Emmanuel Venisse commented on CONTINUUM-884: weird, on our projects, we have empty committer/date/comment only when the scm url have 2 slashes like http://[our subversion server]/repos/stingray/trunk//sub-module Can you set the maven-scm log level to debug and attach the continuum logs? > svn metadata not properly shown in Build Result or Email Notification > - > > Key: CONTINUUM-884 > URL: http://jira.codehaus.org/browse/CONTINUUM-884 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1-alpha-1 > Environment: Windows >Reporter: David Schwartz > Fix For: Future > > > When you do a build the webpage and the email that is sent show what files > have been changed. The correct file(s) are shown but the following info is > missing for each file: author, date, comment, revision > Here is an example from an email: > > Changes: > > Changed: no author @ no date > Comment: no comment > Files changed: > src\main\java\org\codehaus\mojo\websphere\tasks\utils\ValidationUtils.java > ( no revision ) > > Also, on the webpage for that shows the Build Result there is a table called > "Changes" that is missing Author, Date, Comment -- 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: (CONTINUUM-1545) ability to not include build result should be a per-notifier configuration, not system wide
ability to not include build result should be a per-notifier configuration, not system wide --- Key: CONTINUUM-1545 URL: http://jira.codehaus.org/browse/CONTINUUM-1545 Project: Continuum Issue Type: Bug Components: Notification Subsystem Affects Versions: 1.1-beta-4 Reporter: Brett Porter -- 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: (MANTTASKS-88) Add the ability to download javadoc dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Hartmann updated MANTTASKS-88: --- Attachment: patch2.txt Here is a patch containing the test in sample.build.xml and the correction when there is no dependency to prevent the copy of all files. > Add the ability to download javadoc dependencies > - > > Key: MANTTASKS-88 > URL: http://jira.codehaus.org/browse/MANTTASKS-88 > Project: Maven 2.x Ant Tasks > Issue Type: Improvement > Components: dependencies task >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.6, 2.0.7 > Environment: Linux JDK 1.5 >Reporter: Eric Hartmann >Assignee: Herve Boutemy >Priority: Minor > Attachments: patch.txt, patch2.txt > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > The ant task cannot download the javadocs files of dependencies. > Here a small patch to add this enhancement the same way of downloading > sources. -- 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: (MANTTASKS-88) Add the ability to download javadoc dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112799 ] Eric Hartmann commented on MANTTASKS-88: Hi Herve, Sorry, I did not see your comment before today. I've just checked out the sources, applied the patch then deployed the jar to the lib directory of apache-ant. Then I added this target to sample.build.xml : Then : $ ant -f sample.build.xml test-javadoc-deps Buildfile: sample.build.xml initTaskDefs: test-javadoc-deps: [artifact:dependencies] Downloading: junit/junit/3.8.1/junit-3.8.1-javadoc.jar [artifact:dependencies] Downloading: classworlds/classworlds/1.1-alpha-2/classworlds-1.1-alpha-2-javadoc.jar [artifact:dependencies] Downloading: jtidy/jtidy/4aug2000r7-dev/jtidy-4aug2000r7-dev-javadoc.jar [artifact:dependencies] Downloading: ant/ant/1.6.2/ant-1.6.2-javadoc.jar [artifact:dependencies] Downloading: xml-apis/xml-apis/1.0.b2/xml-apis-1.0.b2-javadoc.jar BUILD SUCCESSFUL Total time: 3 seconds It seems to work for me. I've experienced such behaviour working with maven-ant tasks when there is no dependencies (as there is no includes everythings in the repository is copied). I did not have test this case. I will do it right now and submit another patch if it's the problem. > Add the ability to download javadoc dependencies > - > > Key: MANTTASKS-88 > URL: http://jira.codehaus.org/browse/MANTTASKS-88 > Project: Maven 2.x Ant Tasks > Issue Type: Improvement > Components: dependencies task >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.6, 2.0.7 > Environment: Linux JDK 1.5 >Reporter: Eric Hartmann >Assignee: Herve Boutemy >Priority: Minor > Attachments: patch.txt > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > The ant task cannot download the javadocs files of dependencies. > Here a small patch to add this enhancement the same way of downloading > sources. -- 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: (CONTINUUM-884) svn metadata not properly shown in Build Result or Email Notification
[ http://jira.codehaus.org/browse/CONTINUUM-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112798 ] Ionut S commented on CONTINUUM-884: --- No, I don't have.. Or maybe I don't know where to look. Anyway, the page I'm looking at is: http://[ourServer]:8080/continuum/projectView.action?projectId=1 The only 2 slashes are for the http protocol in SCM Url: scm:svn:http://[our subversion server]/repos/stingray/trunk/ > svn metadata not properly shown in Build Result or Email Notification > - > > Key: CONTINUUM-884 > URL: http://jira.codehaus.org/browse/CONTINUUM-884 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1-alpha-1 > Environment: Windows >Reporter: David Schwartz > Fix For: Future > > > When you do a build the webpage and the email that is sent show what files > have been changed. The correct file(s) are shown but the following info is > missing for each file: author, date, comment, revision > Here is an example from an email: > > Changes: > > Changed: no author @ no date > Comment: no comment > Files changed: > src\main\java\org\codehaus\mojo\websphere\tasks\utils\ValidationUtils.java > ( no revision ) > > Also, on the webpage for that shows the Build Result there is a table called > "Changes" that is missing Author, Date, Comment -- 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: (MENFORCER-12) enforce-once still runs in each child pom
[ http://jira.codehaus.org/browse/MENFORCER-12?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112797 ] Brian Fox commented on MENFORCER-12: This is a problem in the way maven handles @aggregator. It still executes on each child. The rules need to declare if they are cacheable and the plugin will need to remember the results to speed things up. > enforce-once still runs in each child pom > - > > Key: MENFORCER-12 > URL: http://jira.codehaus.org/browse/MENFORCER-12 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Plugin >Affects Versions: 1.0-alpha-3 >Reporter: Brian Fox >Assignee: Brian Fox > -- 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: (MENFORCER-11) enforce-once causes MNG-2277 to be expressed in reactor builds. Find a way to work around it.
[ http://jira.codehaus.org/browse/MENFORCER-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-11. -- Resolution: Fixed Fix Version/s: 1.0 Enforce-once has the @aggregator removed and is now deprecated. Unfortunately, in Maven, the @aggregator only applies to command line invocation and has no real effect when bound to a pom (at least not the run once desired effect). In the future, I may add caching to the rules to allow things to run once, but the plugin will still execute for all children. A rule will need to declare if it is safe to cache or not. > enforce-once causes MNG-2277 to be expressed in reactor builds. Find a way to > work around it. > - > > Key: MENFORCER-11 > URL: http://jira.codehaus.org/browse/MENFORCER-11 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Plugin >Affects Versions: 1.0-alpha-3 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 1.0 > > > In 1.0-alpha-3, the enforce goal now requires dependency resolution to > support the new dependency rules (noSnapshots, noBannedDependencies). Because > enforce-once extends and adds as an aggregator, this causes the maven bug > MNG-2277 to appear. The work around for now is to use enforce not the > enforce-once goal (the aggregator part of enforce-once doesn't work anyway). > The fix would be to resolve the dependencies manually in the plugin or to > make a new mojo that requires dependency resolution and put enforce and > enforce-once back the way they where. -- 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: (MENFORCER-21) allow includes to fine tune excludes in bannedDependencies
[ http://jira.codehaus.org/browse/MENFORCER-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-21. -- Resolution: Fixed Fix Version/s: 1.0 > allow includes to fine tune excludes in bannedDependencies > -- > > Key: MENFORCER-21 > URL: http://jira.codehaus.org/browse/MENFORCER-21 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0-alpha-3 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 1.0 > > > We need to ban a large set but allow a subset through. This can be done by > adding include patterns that "save" things from being excluded. -- 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: (MENFORCER-21) allow includes to fine tune excludes in bannedDependencies
allow includes to fine tune excludes in bannedDependencies -- Key: MENFORCER-21 URL: http://jira.codehaus.org/browse/MENFORCER-21 Project: Maven 2.x Enforcer Plugin Issue Type: Improvement Components: Standard Rules Affects Versions: 1.0-alpha-3 Reporter: Brian Fox Assignee: Brian Fox We need to ban a large set but allow a subset through. This can be done by adding include patterns that "save" things from being excluded. -- 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: (MANTTASKS-93) variables not interpolated while reading settings.xml
[
http://jira.codehaus.org/browse/MANTTASKS-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MANTTASKS-93.
--
Assignee: Herve Boutemy
Resolution: Duplicate
this is a duplicate of MANTTASKS-82
> variables not interpolated while reading settings.xml
> --
>
> Key: MANTTASKS-93
> URL: http://jira.codehaus.org/browse/MANTTASKS-93
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
>Affects Versions: 2.0.7
>Reporter: Richard Ziegler
>Assignee: Herve Boutemy
>
> I suspect that variables are not interpolated while reading settings.xml.
> For instance, I have set the environment variable REPO_DIR=c:/.m2repo.
> However, my setting is not respected if i use a
> $\{env.variable\} for the localRepository. I also tried adding
> -DREPO_DIR=c:/.m2repo to ANT_OPTS and using $\{variable\}, but still no luck.
> I was only able to test this in ~/.m2/settings.xml , and ~/.ant/settings.xml,
> because of MANTTASKS-92
> {code:xml|title=~/.m2/settings.xml}
>
>
> c:/.m2repo
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTTASKS-88) Add the ability to download javadoc dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-88?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112793 ] Herve Boutemy commented on MANTTASKS-88: can you provide a working testcase to add to sample.build.xml? > Add the ability to download javadoc dependencies > - > > Key: MANTTASKS-88 > URL: http://jira.codehaus.org/browse/MANTTASKS-88 > Project: Maven 2.x Ant Tasks > Issue Type: Improvement > Components: dependencies task >Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3, 2.0.4, 2.0.6, 2.0.7 > Environment: Linux JDK 1.5 >Reporter: Eric Hartmann >Assignee: Herve Boutemy >Priority: Minor > Attachments: patch.txt > > Original Estimate: 0 minutes > Remaining Estimate: 0 minutes > > The ant task cannot download the javadocs files of dependencies. > Here a small patch to add this enhancement the same way of downloading > sources. -- 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: (MANTTASKS-90) classifier not supported
[ http://jira.codehaus.org/browse/MANTTASKS-90?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112792 ] Herve Boutemy commented on MANTTASKS-90: can you provide a sample use case of the feature you'd like to see, pointing to a public artifact for example to be able to test it while developping? > classifier not supported > > > Key: MANTTASKS-90 > URL: http://jira.codehaus.org/browse/MANTTASKS-90 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.7 > Environment: na >Reporter: t redeske >Priority: Minor > > while the ant tasks support groupId, artifactId, type, and version, they do > not support classifier. -- 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: (MRM-502) Error 500 when searching an artifact by the checksum
[
http://jira.codehaus.org/browse/MRM-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MRM-502.
Assignee: Brett Porter
Resolution: Cannot Reproduce
Fix Version/s: (was: 1.0-beta-4)
1.0-beta-3
can't reproduce this with 1.0-beta-3
> Error 500 when searching an artifact by the checksum
>
>
> Key: MRM-502
> URL: http://jira.codehaus.org/browse/MRM-502
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-beta-2
>Reporter: Arnaud Heritier
>Assignee: Brett Porter
> Fix For: 1.0-beta-3
>
>
> Trying to search some artifacts with their checksum I receive this error :
> {code}
> HTTP ERROR: 500
> Exception in JSP: /WEB-INF/jsp/results.jsp:95
> 92:
> version="${artifactModel.version}"/>
> 93:
> 94:
> 95: groupId="${artifactModel.groupId}" artifactId="${artifactModel.artifactId}"
> 96:
> version="${artifactModel.version}" versions="${artifactModel.versions}"/>
> 97:
> 98:
> Stacktrace:
> RequestURI=/archiva/checksumSearch.action
> Powered by Jetty://
> {code}
> 4a61c9f221ebed45e4006f2f8fa0 *bsf-2.3.0.jar
> No results found
> 8d4a9cf34eb4e374b41b6b98960028d0 *jsp-api-2.0.jar
> No results found ?
> db561232e47050e15572fa0b01e08569 *jstl-2.3.jar
> No results found ?
> c2ced5f8505fe9d1cae685201e9cba07 *jstl-2.4.jar
> No results found ?
> f6cf3fde0b992589ed3d87fa9674015f *servletapi-2.4.jar
> No results found
--
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: (MRM-354) reimplement Show Artifact Reports tab
[ http://jira.codehaus.org/browse/MRM-354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-354: - Summary: reimplement Show Artifact Reports tab (was: Show Artifact Reports results to HTTP ERROR: 500) > reimplement Show Artifact Reports tab > - > > Key: MRM-354 > URL: http://jira.codehaus.org/browse/MRM-354 > Project: Archiva > Issue Type: Bug > Components: reporting >Affects Versions: 1.0-alpha-1 >Reporter: Dawn Angelito >Assignee: Maria Odea Ching > Fix For: Future > > > Clicking the Reports tab of an artifact will result to: > HTTP ERROR: 500 > Internal Server Error > RequestURI=/archiva/showArtifactReports.action -- 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: (MRM-141) clean up design documentation
[ http://jira.codehaus.org/browse/MRM-141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MRM-141. Assignee: Brett Porter Resolution: Fixed Fix Version/s: (was: 1.0-beta-4) got rid of old docs - will leave other docs in wiki and set them up over time > clean up design documentation > - > > Key: MRM-141 > URL: http://jira.codehaus.org/browse/MRM-141 > Project: Archiva > Issue Type: Task > Components: design >Reporter: Brett Porter >Assignee: Brett Porter > > - the indexing design docs don't indicate how to use the indexer from an API > perspective > - there needs to be a more general "this is the architecture" design document -- 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: (MANTTASKS-86) Resolution of java.net dependencies
[ http://jira.codehaus.org/browse/MANTTASKS-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112783 ] Herve Boutemy commented on MANTTASKS-86: surprisingly, I don't have any problem with this library: historically, this library was not in any public repo, due to old licencing restrictions: this was a classical problem, explained here http://maven.apache.org/reference/standard-sun-jar-names.html to be able to use this version, you had to install it to your local repo by hand, or to a private repository, like explained in a lot of places, for example http://www.jugpadova.it/articles/2005/11/26/maven-2-spring-and-jta-depencies but it seems that it has been added to java.net repo lately: http://download.java.net/maven/2/javax/transaction/jta/1.0.1B/ then I can reproduce any problems with your testcase can you check it, please? > Resolution of java.net dependencies > --- > > Key: MANTTASKS-86 > URL: http://jira.codehaus.org/browse/MANTTASKS-86 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 >Reporter: Werner Guttmann > Attachments: build.bat, build.xml, pom.xml > > > I am trying to use the Ant task for Maven with the root Maven POM for > the Castor project for download the dependencies and place them into a > lib directory. > What I have observed is that there's a few dependencies missing when I > run the corresponding Ant target. But if I use Maven for the build > process, the missing JARs are downloaded as well and placed into my > local repository. > I have tried to define remoteRepository entries for the java.net and the > Maven 2 java.net repositories (where e.g. java.transaction:jta:1.1.1B > resides), but this does not make a difference. > Any idea what I could try in addition ? Having said that, all other > dependencies are resolved and copied without any problems. It looks like > it's just the dependencies that are not synced globally that create a > problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-884) svn metadata not properly shown in Build Result or Email Notification
[ http://jira.codehaus.org/browse/CONTINUUM-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112779 ] Emmanuel Venisse commented on CONTINUUM-884: Do you have a double slash somewhere in your svn url? Look in the project page to see the svn url used by Continuum > svn metadata not properly shown in Build Result or Email Notification > - > > Key: CONTINUUM-884 > URL: http://jira.codehaus.org/browse/CONTINUUM-884 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1-alpha-1 > Environment: Windows >Reporter: David Schwartz > Fix For: Future > > > When you do a build the webpage and the email that is sent show what files > have been changed. The correct file(s) are shown but the following info is > missing for each file: author, date, comment, revision > Here is an example from an email: > > Changes: > > Changed: no author @ no date > Comment: no comment > Files changed: > src\main\java\org\codehaus\mojo\websphere\tasks\utils\ValidationUtils.java > ( no revision ) > > Also, on the webpage for that shows the Build Result there is a table called > "Changes" that is missing Author, Date, Comment -- 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: (CONTINUUM-884) svn metadata not properly shown in Build Result or Email Notification
[ http://jira.codehaus.org/browse/CONTINUUM-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112777 ] Ionut S commented on CONTINUUM-884: --- I was able to see this issue in 1.1 Beta 4 (and this is happening not only in the emails sent to the list but to the build page as well - you can't figure out who broke the build from this information. > svn metadata not properly shown in Build Result or Email Notification > - > > Key: CONTINUUM-884 > URL: http://jira.codehaus.org/browse/CONTINUUM-884 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1-alpha-1 > Environment: Windows >Reporter: David Schwartz > Fix For: Future > > > When you do a build the webpage and the email that is sent show what files > have been changed. The correct file(s) are shown but the following info is > missing for each file: author, date, comment, revision > Here is an example from an email: > > Changes: > > Changed: no author @ no date > Comment: no comment > Files changed: > src\main\java\org\codehaus\mojo\websphere\tasks\utils\ValidationUtils.java > ( no revision ) > > Also, on the webpage for that shows the Build Result there is a table called > "Changes" that is missing Author, Date, Comment -- 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-2443) Don't download pom if artifact is already in the local repository
[ http://jira.codehaus.org/browse/MNG-2443?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112776 ] Carsten Ziegeler commented on MNG-2443: --- I totally agree that it would be much better/correct if everything in the repository is deployed correctly (including a *correct* pom). The main problem with the current behaviour is: a) too many messages for the user who is just a client of the artifact. The message is send to the wrong people. The maintainers of the lib should get these messages (which is of course not really feasable) b) It takes time during build, especially if you have configured several repositories as each repo is tried for the pom Now, I see your point that checking the availability of poms allows to add the pom later on - but I'm not sure if this is a good argument :) Following this line I could argue that updating/correcting the pom at a future time should be possible - and this is not done today. Once a pom is in the local repository this one is used. So I think for symmetrie it makes more sense to not check the availability of the pom once the artifact is in the local repository. I can imagine that adding a pom later on might create build problems as people have used the artifact without a pom for some time and from one day to another a pom with possible new (transitive) dependencies arrives. Not a big deal perhaps, but it can cause trouble. > Don't download pom if artifact is already in the local repository > - > > Key: MNG-2443 > URL: http://jira.codehaus.org/browse/MNG-2443 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0.4 >Reporter: Carsten Ziegeler >Assignee: Jason van Zyl > Fix For: 2.1 > > > There are many projects out there just providing their artifact without a pom > (whether this is good or not is a different question). Now in this case m2 > always tries to download a pom for those artifacts, even if the artifact > itself is already in the local repository. And if you have several of those > artifacts combined with more than one repository configured, then there are a > lot of unnecessary download attempts. > I think this falls into the same category as changing a pom in the repository > (which should be forbidden) - so if for the first time the artifact is > downloaded no pom available, then there will never be a pom for this specific > artifact. -- 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: (CONTINUUM-884) svn metadata not properly shown in Build Result or Email Notification
[ http://jira.codehaus.org/browse/CONTINUUM-884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112775 ] Ionut S commented on CONTINUUM-884: --- Guys, This issue is very important for us !! Please take this issue into consideration as soon as possible !! > svn metadata not properly shown in Build Result or Email Notification > - > > Key: CONTINUUM-884 > URL: http://jira.codehaus.org/browse/CONTINUUM-884 > Project: Continuum > Issue Type: Bug > Components: Notifier - Mail >Affects Versions: 1.1-alpha-1 > Environment: Windows >Reporter: David Schwartz > Fix For: Future > > > When you do a build the webpage and the email that is sent show what files > have been changed. The correct file(s) are shown but the following info is > missing for each file: author, date, comment, revision > Here is an example from an email: > > Changes: > > Changed: no author @ no date > Comment: no comment > Files changed: > src\main\java\org\codehaus\mojo\websphere\tasks\utils\ValidationUtils.java > ( no revision ) > > Also, on the webpage for that shows the Build Result there is a table called > "Changes" that is missing Author, Date, Comment -- 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: (MSITE-258) Deployment on network drive for multi-modules fails for modules sites
[ http://jira.codehaus.org/browse/MSITE-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112773 ] Romain Linsolas edited comment on MSITE-258 at 11/5/07 3:00 AM: Duplicate of bug MSITE-232. was: Duplicate of bug MSITE-232 (http://jira.codehaus.org/browse/MSITE-232). > Deployment on network drive for multi-modules fails for modules sites > - > > Key: MSITE-258 > URL: http://jira.codehaus.org/browse/MSITE-258 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance, multi module, site:deploy >Affects Versions: 2.0-beta-5 > Environment: Windows, Maven 2.0.5, site plugin version 2.0-beta-5 >Reporter: Romain Linsolas >Priority: Minor > > I work on a project with several modules, for example : > myproject > + commons > + business > + ... > (myproject is also the parent project for all modules) > In the parent pom.xml, I define the distribution management in order to > deploy my whole site on a network drive (which is not mapped): > > > website > file://yyy/sites/my-site > > > When I deploy the whole site (command mvn site-deploy run on the parent > directory), the "core" site is correctly deployed on my network drive, but > all modules are deployed on my C: drive (in the directory > C:\\y\sites\my-site\...). > As the core site is correctly deployed, I think the problem is that the > deployment URL is not correctly given to all project children. Maybe it is a > Maven bug, not a Site Plugin problem? > The only way to make the deployment works correctly is to redefine, for each > modules, the distributionManagement! > Note that this problem does not occur if the network drive is mapped (for > example if the distribution URL is something like "F:/sites/my-site/"). -- 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: (MSITE-258) Deployment on network drive for multi-modules fails for modules sites
[ http://jira.codehaus.org/browse/MSITE-258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Romain Linsolas closed MSITE-258. - Resolution: Duplicate Duplicate of bug MSITE-232 (http://jira.codehaus.org/browse/MSITE-232). > Deployment on network drive for multi-modules fails for modules sites > - > > Key: MSITE-258 > URL: http://jira.codehaus.org/browse/MSITE-258 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance, multi module, site:deploy >Affects Versions: 2.0-beta-5 > Environment: Windows, Maven 2.0.5, site plugin version 2.0-beta-5 >Reporter: Romain Linsolas >Priority: Minor > > I work on a project with several modules, for example : > myproject > + commons > + business > + ... > (myproject is also the parent project for all modules) > In the parent pom.xml, I define the distribution management in order to > deploy my whole site on a network drive (which is not mapped): > > > website > file://yyy/sites/my-site > > > When I deploy the whole site (command mvn site-deploy run on the parent > directory), the "core" site is correctly deployed on my network drive, but > all modules are deployed on my C: drive (in the directory > C:\\y\sites\my-site\...). > As the core site is correctly deployed, I think the problem is that the > deployment URL is not correctly given to all project children. Maybe it is a > Maven bug, not a Site Plugin problem? > The only way to make the deployment works correctly is to redefine, for each > modules, the distributionManagement! > Note that this problem does not occur if the network drive is mapped (for > example if the distribution URL is something like "F:/sites/my-site/"). -- 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: (MSITE-258) Deployment on network drive for multi-modules fails for modules sites
[ http://jira.codehaus.org/browse/MSITE-258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_112772 ] Romain Linsolas commented on MSITE-258: --- Hi Dennis, Thanks for the link to the bug 232. Indeed, using the URL file:///\\xxx resolved my problem. > Deployment on network drive for multi-modules fails for modules sites > - > > Key: MSITE-258 > URL: http://jira.codehaus.org/browse/MSITE-258 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance, multi module, site:deploy >Affects Versions: 2.0-beta-5 > Environment: Windows, Maven 2.0.5, site plugin version 2.0-beta-5 >Reporter: Romain Linsolas >Priority: Minor > > I work on a project with several modules, for example : > myproject > + commons > + business > + ... > (myproject is also the parent project for all modules) > In the parent pom.xml, I define the distribution management in order to > deploy my whole site on a network drive (which is not mapped): > > > website > file://yyy/sites/my-site > > > When I deploy the whole site (command mvn site-deploy run on the parent > directory), the "core" site is correctly deployed on my network drive, but > all modules are deployed on my C: drive (in the directory > C:\\y\sites\my-site\...). > As the core site is correctly deployed, I think the problem is that the > deployment URL is not correctly given to all project children. Maybe it is a > Maven bug, not a Site Plugin problem? > The only way to make the deployment works correctly is to redefine, for each > modules, the distributionManagement! > Note that this problem does not occur if the network drive is mapped (for > example if the distribution URL is something like "F:/sites/my-site/"). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1797) please upload JsLint
please upload JsLint Key: MAVENUPLOAD-1797 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1797 Project: maven-upload-requests Issue Type: Wish Reporter: nicolas de loof JsLint is a Javascript code verifier, written itself in javascript -- 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
