[jira] Created: (MNG-3604) when team member installs after deploy, snapshot is not updated
when team member installs after deploy, snapshot is not updated --- Key: MNG-3604 URL: http://jira.codehaus.org/browse/MNG-3604 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.x Environment: Win XP Reporter: bartvdc Priority: Minor I deployed a project A with a snapshot version and a team member did not get the update when he builds another project B that has this project A as dependency, not even with -U . We found out that it was because he did an install of the same project A after I deployed it. He had not changed anything, so the version part did not change. On the repo we had a -20080516... and in his local repo there was a -20080514... file. Apparently Maven does not look at the file names(the -20080516... part) but keeps the install time elsewhere. If the deployed file comes before the the install time, no update is done. The project must be deleted in his local repo to get the latest version. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (NMAVEN-132) VS Addin 'Configure Maven Repository' breaks command line builds
VS Addin 'Configure Maven Repository' breaks command line builds
Key: NMAVEN-132
URL: http://jira.codehaus.org/browse/NMAVEN-132
Project: NMaven
Issue Type: Bug
Affects Versions: 0.14 (Unreleased)
Reporter: Allan G. Ramirez
The VS Addin's 'Configure Maven Repository' option adds a profile to
settings.xml with the repository url you supply.
This change breaks command-line builds:
{code}
C:\svn\examples\NMaven.Sample>mvn clean
...
java.lang.ClassCastException: Settings.addActiveProfiles(string) parameter must
be instanceof java.lang.String
at org.apache.maven.settings.Settings.addActiveProfile(Settings.java:91)
at
org.apache.maven.settings.DefaultMavenSettingsBuilder.activateDefaultProfiles(DefaultMavenSettingsBuilder.java:197)
at
org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:177)
at
org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:153)
at
org.apache.maven.settings.DefaultMavenSettingsBuilder.buildSettings(DefaultMavenSettingsBuilder.java:141)
at org.apache.maven.cli.MavenCli.buildSettings(MavenCli.java:315)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:176)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
{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] Closed: (MENFORCER-43) RequireReleaseDeps - allow to execute "onlyWhenRelease"
[
http://jira.codehaus.org/browse/MENFORCER-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MENFORCER-43.
--
Resolution: Fixed
> RequireReleaseDeps - allow to execute "onlyWhenRelease"
> ---
>
> Key: MENFORCER-43
> URL: http://jira.codehaus.org/browse/MENFORCER-43
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Improvement
> Components: Standard Rules
>Affects Versions: 1.0-alpha-3
>Reporter: Jacob Robertson
>Assignee: Brian Fox
>Priority: Minor
> Fix For: 1.0
>
> Attachments: onlyWhenRelease.patch.txt
>
>
> When I setup a project to use the enforcer plugin, I would like to setup the
> requireReleaseDeps rule. However, while I am in "snapshot" mode with my
> project, I'm not that concerned about whether that project depends on
> snapshots. For example, I may have a small suite of projects which are being
> developed at the same time. They may also share a common parent. (Just like
> the maven enforcer projects do) Especially in the case where I place the
> maven enforcer plugin configuration in that parent pom, it wouldn't make
> sense for me to have to "comment out" the requireReleaseDeps rule during my
> snapshot development, only to have to switch it back at release time.
> Rather, what I want to express is "enforce the requireReleaseDeps rule, but
> only when I'm a release".
> The pom snippet would look like
> {code}
>
> true
> true
>
> {code}
> I have attached a patch that shows what I'm thinking, and the updated test
> case to show that it works as expected.
--
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-38) Enforcer rules for AlwaysPass and AlwaysFail
[ http://jira.codehaus.org/browse/MENFORCER-38?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-38. -- Resolution: Fixed Applied, thanks. > Enforcer rules for AlwaysPass and AlwaysFail > > > Key: MENFORCER-38 > URL: http://jira.codehaus.org/browse/MENFORCER-38 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Reporter: Ben Lidgey >Assignee: Brian Fox > Fix For: 1.0 > > Attachments: MavenEnforcerAlwaysRules.zip > > > As discussed on email, here is my first attempt at submitting some code! > It implements two rules: one always passes and the other always fails. They > are useful for checking the Enforcer rules config and possible failing the > build if a certain profile is used by setting the AlwaysFail rule in that > profile. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-350) Option '0' for "specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ):" is broken
Option '0' for "specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ):" is broken -- Key: MRELEASE-350 URL: http://jira.codehaus.org/browse/MRELEASE-350 Project: Maven 2.x Release Plugin Issue Type: Bug Affects Versions: 2.0-beta-8 Reporter: Craig Priority: Minor CheckDependencySnapshotsPhase.java has a bug when processing this prompt with the 0 option selected: specify the selection number ( 0:All 1:Project Dependencies 2:Plugins 3:Reports 4:Extensions ): 0 When choosing 0: All, the plugin goes through the motions of asking to resolve snapshot dependencies, but after resolving them, fails saying there are still snapshot dependencies. This bug lies with the function resolveSnapshots relying on the function processSnapshot to remove resolved dependencies from the set. This works for all cases except 0, which creates a new dependency set -- 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-46) include feature of sizewatch-plugin into enforcer plugin
[ http://jira.codehaus.org/browse/MENFORCER-46?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136592#action_136592 ] Brian Fox commented on MENFORCER-46: rule converted and committed. I need to make some unit tests and ITs > include feature of sizewatch-plugin into enforcer plugin > > > Key: MENFORCER-46 > URL: http://jira.codehaus.org/browse/MENFORCER-46 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement >Reporter: Roman Stumm >Assignee: Brian Fox > Attachments: verifysize.zip > > > As discussed in the last days, here is the project and source of the > verifysize plugin that allows to check an artifact for max./min. size. > Use it / include it into the enforcer plugin. > For more information, refer to : > http://code.google.com/p/agimatec-maven-plugins/ > Roman -- 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: (MDEPLOY-79) Deploy fails when there is no primary artifact
[ http://jira.codehaus.org/browse/MDEPLOY-79?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed MDEPLOY-79. -- Resolution: Duplicate Duplicate of MDEPLOY-45, and already fixed in trunk > Deploy fails when there is no primary artifact > -- > > Key: MDEPLOY-79 > URL: http://jira.codehaus.org/browse/MDEPLOY-79 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Wendy Smoak > > If the jar or war plugin has been configured to append a classifier, then > "mvn deploy" fails with: > [INFO] [deploy:deploy] > altDeploymentRepository = null > [INFO] Retrieving previous build number from repo > [INFO] repository metadata for: 'snapshot > com.example:jar-with-classifier:1.0-SNAPSHOT' could not be found on > repository: repo, so will be created > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error deploying artifact: > /private/tmp/jar-with-classifier/target/classes (No such file or directory) > In contrast, the install plugin works fine: > [INFO] [install:install] > [INFO] No primary artifact to install, installing attached artifacts instead. > [INFO] Installing > /private/tmp/jar-with-classifier/target/jar-with-classifier-1.0-SNAPSHOT-SDK.jar > to > /Users/wsmoak/.m2/repository/com/example/jar-with-classifier/1.0-SNAPSHOT/jar-with-classifier-1.0-SNAPSHOT-SDK.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDEPLOY-79) Deploy fails when there is no primary artifact
Deploy fails when there is no primary artifact -- Key: MDEPLOY-79 URL: http://jira.codehaus.org/browse/MDEPLOY-79 Project: Maven 2.x Deploy Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Wendy Smoak If the jar or war plugin has been configured to append a classifier, then "mvn deploy" fails with: [INFO] [deploy:deploy] altDeploymentRepository = null [INFO] Retrieving previous build number from repo [INFO] repository metadata for: 'snapshot com.example:jar-with-classifier:1.0-SNAPSHOT' could not be found on repository: repo, so will be created [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error deploying artifact: /private/tmp/jar-with-classifier/target/classes (No such file or directory) In contrast, the install plugin works fine: [INFO] [install:install] [INFO] No primary artifact to install, installing attached artifacts instead. [INFO] Installing /private/tmp/jar-with-classifier/target/jar-with-classifier-1.0-SNAPSHOT-SDK.jar to /Users/wsmoak/.m2/repository/com/example/jar-with-classifier/1.0-SNAPSHOT/jar-with-classifier-1.0-SNAPSHOT-SDK.jar -- 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: (WAGON-171) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGON-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed WAGON-171. -- Resolution: Fixed fixed as specified by Benjamin > Cannot deploy files over existing files if someone else originally uploaded > them. > - > > Key: WAGON-171 > URL: http://jira.codehaus.org/browse/WAGON-171 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh > Environment: Desktop OS is Windows XP. Deploying to Solaris server > using Tectia SSH2 Client. >Reporter: Frank Russo >Assignee: Brett Porter >Priority: Critical > Fix For: 1.0-beta-3 > > Attachments: File sharing issue with maven-deploy using wagon.txt > > > On first deploy, everything works fine. On next deploy, if a different > developer runs the command, the attached error occurs(see attached the > original email posted to the Maven Users Mailing List.) > The file is owned by the first developer, but has full rwx access (777). If > developer 2 directly connects to the machine, they can do anything to the > file, so it's not a Unix permissions issue... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-171) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGON-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136588#action_136588 ] Brett Porter commented on WAGON-171: you're right again, I misunderstood what you were saying. Thanks. So I'll check for chmod failures in both scp and sftp. I agree on the error level too, that's consistent with the behaviour for directories. > Cannot deploy files over existing files if someone else originally uploaded > them. > - > > Key: WAGON-171 > URL: http://jira.codehaus.org/browse/WAGON-171 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh > Environment: Desktop OS is Windows XP. Deploying to Solaris server > using Tectia SSH2 Client. >Reporter: Frank Russo >Assignee: Brett Porter >Priority: Critical > Fix For: 1.0-beta-3 > > Attachments: File sharing issue with maven-deploy using wagon.txt > > > On first deploy, everything works fine. On next deploy, if a different > developer runs the command, the attached error occurs(see attached the > original email posted to the Maven Users Mailing List.) > The file is owned by the first developer, but has full rwx access (777). If > developer 2 directly connects to the machine, they can do anything to the > file, so it's not a Unix permissions issue... -- 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: (MECLIPSE-387) download source should accept exclusion of artifact
[ http://jira.codehaus.org/browse/MECLIPSE-387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julien Renaut updated MECLIPSE-387: --- Attachment: configurable-source-cache-dir-diff Hi, i've slightly modified the AbstractIdeSupportMojo for our use here at work. A "preferredSourceCacheDir" parameter has been added (defaults to null). This way the user can specify a location of choice for the source status cache. If none is provided it falls back to the default location (target dir). I've attached a patch for it if anyone's interested in that particular solution. > download source should accept exclusion of artifact > --- > > Key: MECLIPSE-387 > URL: http://jira.codehaus.org/browse/MECLIPSE-387 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: Core : Dependencies resolution and build path >Affects Versions: 2.4 >Reporter: Dominique Jean-Prost > Attachments: configurable-source-cache-dir-diff > > > It would be nice to be possible to exclude specific group/artifact when > downloadSources is to true (in pom.xml for instance). > As the sources jar or the javadoc jar will never be available in repo, for > specific artifact, mvn eclipse:eclipse keep on trying to download them, and > it slows the process. -- 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-3603) Incomplete set of transitive dependencies resolved when transitive dependencies repository is not listed.
Incomplete set of transitive dependencies resolved when transitive dependencies repository is not listed. - Key: MNG-3603 URL: http://jira.codehaus.org/browse/MNG-3603 Project: Maven 2 Issue Type: Bug Components: Artifacts and Repositories, Dependencies Affects Versions: 2.0.9 Environment: windows vista jdk 1.5.0_11 Reporter: Micah Whitacre Attachments: maven_testcase.zip I have project D which is dependent on project C. Project D lists the repository that the latest snapshot or release project C resides in. Project C depends on project B which depends on project A. Both projects B and A reside in a different repository than Project C and D. Project C properly lists the repository A and B reside in. All dependency scopes are compile so therefore transitively project D has a compile time dependency on A. The issue arises in that when building project D with a clean local maven repository project A is never resolved, no error is given but errors will occur later when actually trying to run tests. I have attached a testcase of this situation with projects A,B,C,and D. To duplicate this issue: 1. Unzip the attachment to a folder on your machine. 2. At the root of that folder run "mvn deploy". This will deploy projects A and B to fake-remote-repo2 and project C to fake-remote-repo1. One note is the URL of the repositories is windows based to this will need to be adjusted in the POMs and in the projectD pom if you are *nix based. 3. Clear your local maven repository. 4. Navigate to the "projectD" folder and run "mvn compile". After step 4 completes browse your local maven repo and you will notice that project A is not present. In the actual situation I'm encountering this it not only fails to resolve dependencies but also parent 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: (WAGON-171) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGON-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136578#action_136578 ] Benjamin Bentmann commented on WAGON-171: - bq. I think it will succeed if the permission is the same as before No, to my knowledge, it will - by design - always fail if the user executing chmod is not the owner. bq. but it makes sense to convert this failure to a warning. Not sure about whether "warning" is really the appropriate log level. I mean in general, warnings indicate conditions that should most probably be fixed. But in this case, there is nothing to fix. The user simply doesn't own the file, that's not bad state. So I believe the warning would be another line of noise from Maven that users will learn to ignore. Hence I suggest to use "debug" level in case chmod failed. If there is something wrong with the permissions, a user will simply notice by failing to update the contents of the actual file being deployed. > Cannot deploy files over existing files if someone else originally uploaded > them. > - > > Key: WAGON-171 > URL: http://jira.codehaus.org/browse/WAGON-171 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh > Environment: Desktop OS is Windows XP. Deploying to Solaris server > using Tectia SSH2 Client. >Reporter: Frank Russo >Assignee: Brett Porter >Priority: Critical > Fix For: 1.0-beta-3 > > Attachments: File sharing issue with maven-deploy using wagon.txt > > > On first deploy, everything works fine. On next deploy, if a different > developer runs the command, the attached error occurs(see attached the > original email posted to the Maven Users Mailing List.) > The file is owned by the first developer, but has full rwx access (777). If > developer 2 directly connects to the machine, they can do anything to the > file, so it's not a Unix permissions issue... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (WAGON-171) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGON-171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened WAGON-171: you're right. I think it will succeed if the permission is the same as before, but it makes sense to convert this failure to a warning. > Cannot deploy files over existing files if someone else originally uploaded > them. > - > > Key: WAGON-171 > URL: http://jira.codehaus.org/browse/WAGON-171 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh > Environment: Desktop OS is Windows XP. Deploying to Solaris server > using Tectia SSH2 Client. >Reporter: Frank Russo >Assignee: Brett Porter >Priority: Critical > Fix For: 1.0-beta-3 > > Attachments: File sharing issue with maven-deploy using wagon.txt > > > On first deploy, everything works fine. On next deploy, if a different > developer runs the command, the attached error occurs(see attached the > original email posted to the Maven Users Mailing List.) > The file is owned by the first developer, but has full rwx access (777). If > developer 2 directly connects to the machine, they can do anything to the > file, so it's not a Unix permissions issue... -- 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: (MPIR-102) Locale should be taken from maven-site-plugin
[ http://jira.codehaus.org/browse/MPIR-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136572#action_136572 ] Dennis Lundberg commented on MPIR-102: -- Czeck translations for project-info-reports has not been released yet, but are available in version 2.1-SNAPSHOT if you'd like to try them. So this is working. > Locale should be taken from maven-site-plugin > - > > Key: MPIR-102 > URL: http://jira.codehaus.org/browse/MPIR-102 > Project: Maven 2.x Project Info Reports Plugin > Issue Type: Improvement >Reporter: Petr Ferschmann > > In my pom.xml I have this configuration for site plugin: > > org.apache.maven.plugins > maven-site-plugin > > cs > > > But project-info-reports are still in english. It would be great if the > locale is taken from site plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-171) Cannot deploy files over existing files if someone else originally uploaded them.
[
http://jira.codehaus.org/browse/WAGON-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136570#action_136570
]
Benjamin Bentmann commented on WAGON-171:
-
I assume a scenario where all developers of the project have the permissions
configured in their {{settings.xml}} (e.g. because people don't like updating
their umask which would affect their entire account and not just Maven
deployments). This in turn will make Wagon *always* try to set permissions, not
just on first deployment, wouldn't it? In this case, any deployment by somebody
other than the file owner will fail, because the {{SftpWagon}} is emitting a
chmod on the command channel in line 178. It doesn't matter if the permissions
were previously set to 777 or something else granting write permissions to the
group, only the file owner is allowed to issue chmod on the files. Hence I
would have expected {{SftpWagon.setFileMode()}} to guard against an exception
of the failed chmod and simply continue deployment. Do I miss something here?
> Cannot deploy files over existing files if someone else originally uploaded
> them.
> -
>
> Key: WAGON-171
> URL: http://jira.codehaus.org/browse/WAGON-171
> Project: Maven Wagon
> Issue Type: Bug
> Components: wagon-ssh
> Environment: Desktop OS is Windows XP. Deploying to Solaris server
> using Tectia SSH2 Client.
>Reporter: Frank Russo
>Assignee: Brett Porter
>Priority: Critical
> Fix For: 1.0-beta-3
>
> Attachments: File sharing issue with maven-deploy using wagon.txt
>
>
> On first deploy, everything works fine. On next deploy, if a different
> developer runs the command, the attached error occurs(see attached the
> original email posted to the Maven Users Mailing List.)
> The file is owned by the first developer, but has full rwx access (777). If
> developer 2 directly connects to the machine, they can do anything to the
> file, so it's not a Unix permissions issue...
--
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: (MEV-586) Maven 1.x POM in repository for flatpack - specifies pomVersion 3
[ http://jira.codehaus.org/browse/MEV-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MEV-586. -- Assignee: John Casey Resolution: Fixed > Maven 1.x POM in repository for flatpack - specifies pomVersion 3 > - > > Key: MEV-586 > URL: http://jira.codehaus.org/browse/MEV-586 > Project: Maven Evangelism > Issue Type: Bug > Components: Invalid POM >Reporter: Trevor L. Torrez >Assignee: John Casey > > "flatpack" is a maven 1.x project. The pom in the maven2 repository specifies > pomVersion as 3 instead of 4.0.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-349) how you make the release:perform working while it complains No sources to compile
how you make the release:perform working while it complains No sources to compile - Key: MRELEASE-349 URL: http://jira.codehaus.org/browse/MRELEASE-349 Project: Maven 2.x Release Plugin Issue Type: Bug Components: scm Affects Versions: 2.0-beta-7 Environment: cvs and unix Reporter: Michael Meng I can not make the release:perform work at all, since it checked out the source to one location and compile it on other location, which giving me the "No sources to compile" error. Does anyone have a detail log on how you make the release:perform to work on cvs ? The Working directory keep changing, any thing need to define in pom ? The check out source location is: /approot/cc/cruisecontrol-bin-2.7.1/checkout/projects/service/target/checkout but it try to compile the source code on: /approot/cc/cruisecontrol-bin-2.7.1/checkout/projects/service/target/checkout/target/checkout/ Thanks [INFO] Executing: cvs -z3 -f -d :ext:[EMAIL PROTECTED]:/home/cvs_arch -q checkout -r v88-01 -d checkout projects/service [INFO] Working directory: /approot/cc/cruisecontrol-bin-2.7.1/checkout/projects/service/target [INFO] Executing goals 'deploy site-deploy'... [INFO] Executing: mvn deploy site-deploy --no-plugin-updates -DperformRelease=true -f pom.xml [INFO] Scanning for projects... [INFO] [INFO] [compiler:compile] [INFO] No sources to compile [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:testCompile] [INFO] Not compiling test sources [INFO] [surefire:test] [INFO] Tests are skipped. [INFO] [jar:jar] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-348) how you make the release:prepare working without checking out the source ?
how you make the release:prepare working without checking out the source ?
--
Key: MRELEASE-348
URL: http://jira.codehaus.org/browse/MRELEASE-348
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: scm
Affects Versions: 2.0-beta-7
Environment: cvs
Reporter: Michael Meng
I wonder if some one can show me one detail example how to make the prepare
working ?
The default task is [clean, verify], after the clean, it did not checkout the
source
The verify do not make sense to me at all, does any one know I need to make
some config/pom file changes
to make the verify works as desired ? Thanks
[INFO] [clean:clean]
[INFO] Deleting directory
/approot/cc/cruisecontrol-bin-2.7.1/checkout/projects/service/target
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
Downloading:
http://bhdvweb4.uhc.com:8109/repo2//ubhsc/ant-contrib/1.0/ant-contrib-1.0.pom
Downloading:
http://repo1.maven.org/maven2/ubhsc/ant-contrib/1.0/ant-contrib-1.0.pom
Downloading:
http://bhdvweb4.uhc.com:8109/repo2//ubhsc/ant-contrib/1.0/ant-contrib-1.0.pom
Downloading:
http://repo1.maven.org/maven2/ubhsc/ant-contrib/1.0/ant-contrib-1.0.pom
[INFO] [compiler:compile]
[INFO] No sources to compile
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [compiler:testCompile]
[INFO] Not compiling test sources
[INFO] [surefire:test]
[INFO] Tests are skipped.
[INFO] [jar:jar]
[WARNING] JAR will be empty - no content was marked for inclusion!
[INFO] Building jar:
/approot/cc/cruisecontrol-bin-2.7.1/checkout/projects/service/target/service-88.01.jar
[INFO] Preparing source:jar
[WARNING] Removing: jar from forked lifecycle, to prevent recursive
invocation.
[INFO] No goals needed for project - skipping
[INFO] [source:jar {execution: default}]
[INFO] Building jar:
/approot/cc/cruisecontrol-bin-2.7.1/checkout/projects/service/target/service-88.01-sources.jar
[INFO]
[INFO] BUILD SUCCESSFUL
[INFO]
--
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-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution
[ http://jira.codehaus.org/browse/MNG-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136560#action_136560 ] Jerome Lacoste commented on MNG-3595: - #maven yo ! Is there anything I can do in exchange for some comments regarding MNG-3595 ? :) at least to know if this problem is something that is worth addressing. Thanks lacostej, i don't think we should make that change in 2.0.x, but perhaps 2.1 it's a little scary to make changes in this area anymore because it will inevitably break someone's build Brian: OK. I am willing to provide a cleaner patch for 2.1, I just need some comments on what approach to follow. the current patch cannot build any existing build as it provides a new hook for adding the functionality. But I don't like changing MavenProject jdcasey, wdyt? looking lacostej: I'm not sure I get it, the clover plugin would register a post-processor for dependencies? or, would it attach a post-processor to the project for use ahead of successive plugin executions? lacostej, Brian: why not simply remember when/what scope we've resolved to for a given project, and avoid re-resolving? then swizzled artifacts would remain intact for the forked project instance jdcasey, that would be the preferred technique performance wise also, but i'm afraid of consequences in 2.0.x jdcasey: the way I solved the problem was just the quickest solution I found. The problem is that successive plugin executions affect the list of transitive dependencies, because of the requireDependencyResolution tag. The idea was then to post process this dependency resolution operation, if it is to happen again. Another solution would be to prevent from the re-resolution to happen again,... ...but I wasn't sure if it is possible to achieve this without locking maven into one corner. I wasn't sure why we were not already re-resolving for each plugin that required it Brian: I understand, but this _should_ be relatively tame lacostej: I think as long as we never prune the list of transitive artifacts (i.e. going from test scope to compile scope only) in the project instance, we should be able to avoid re-resolving pretty safely there's a lot of sketchy stuff in there, like you may still get artifacts even if you didn't request resolution, depending on what plugin(s) ran before IIRC, there is another long-standing issue with re-resolving the artifacts...jesse filed it, but I'd have to dig around to find it again jdcasey: what happens if we start adding a new scope ? Brian: true, we'd almost need a masked project instance for things that didn't request dependency resolution yeah which is why this scares me in 2.o yeah Brian: you don't think we could hem it in with a bunch of tests and get the possible pathways covered? I mean, it'd be a lot of work, and this is sort of an edge case (if you don't mind my saying so), but still... 2.1 is definitely safest i'm risk averse after the mess we went through with .9 we're trying to reduce regressions not make more ;-) it's probably worth mentioning in connection that we ought to do a full audit of the mutability of the MavenProject instance, to make sure things are intuitive across the board...fwiw heh jdcasey: that's a good think. In fact what I was missing when developing is a contract between the plugins and maven core Brian: that pretty much means just shoring up the behavior and adopting a sunset clause for 2.0.x asap, then? :) think->thing lacostej: yeah, the formal contract thing keeps coming up e.g. what should a plugin expect after using setArtifacts() I started looking at that awhile back, something outside the core that was fluent in both the 2.0.x core and the 2.1 core, but ran out of time sure jdcasey, that's essentially what i had in mind, continue to fix bugs and regressions only that's cool Brian: maybe it's worth talking about a less scary 2.1, then? something that will do a new feature-set in between the current plan and the 2.0.x features? I mean, we have enough code now to talk about killing bugs and doing a release * jdcasey shrugs yes but 2.1 hardly works without the artifact stuff i've been pushing to close the scope on 2.1 for a while now what's the rough idea behind 2.1 ? E.g. do you plan on enforcing maximum compatibility or can new features be favored over compatiblity ? B
[jira] Commented: (WAGON-171) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGON-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136557#action_136557 ] Brett Porter commented on WAGON-171: if the permissions are set on the first deployment such that the second user has permission (which is the case in this report), then not attempting to change the permissions will make deployment succeed, as you said in your comment above. It will simply overwrite the file, retaining the original user and permissions. > Cannot deploy files over existing files if someone else originally uploaded > them. > - > > Key: WAGON-171 > URL: http://jira.codehaus.org/browse/WAGON-171 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh > Environment: Desktop OS is Windows XP. Deploying to Solaris server > using Tectia SSH2 Client. >Reporter: Frank Russo >Assignee: Brett Porter >Priority: Critical > Fix For: 1.0-beta-3 > > Attachments: File sharing issue with maven-deploy using wagon.txt > > > On first deploy, everything works fine. On next deploy, if a different > developer runs the command, the attached error occurs(see attached the > original email posted to the Maven Users Mailing List.) > The file is owned by the first developer, but has full rwx access (777). If > developer 2 directly connects to the machine, they can do anything to the > file, so it's not a Unix permissions issue... -- 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: (MEV-585) Broken checksum for biz.aQute:bndlib 0.0.255 pom
[ http://jira.codehaus.org/browse/MEV-585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MEV-585. -- Assignee: John Casey Resolution: Fixed Replaced with the original from aQute.biz repository. I verified that the checksums are from the original POM, and that the two POMs don't differ except in line endings. > Broken checksum for biz.aQute:bndlib 0.0.255 pom > > > Key: MEV-585 > URL: http://jira.codehaus.org/browse/MEV-585 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher >Assignee: John Casey > > md5 and sha1 are incorrect for biz.aQute:bndlib 0.0.255 pom -- 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-3595) Changes made to project resolved artifacts are overriden when a plugin uses @requiresDependencyResolution
[ http://jira.codehaus.org/browse/MNG-3595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136554#action_136554 ] John Casey commented on MNG-3595: - I'd prefer to see this as preventing re-resolution of project dependencies, unless the scope changes upward (compile to test, NOT test to compile)...then, you could impose a rule saying that any pre-existing dependency artifacts in the project are preferred over those new ones just resolved...that way, you'd preserve any swizzled artifacts for the duration of your forked execution. This does get into some interesting side effects for plugins that don't use @requiresDependencyResolution, probably, so it's probably not appropriate for 2.0.x (who knows what sort of regressions this sort of change could introduce). I'd prefer to do a full audit of the mutability of MavenProject for 2.1 from a plugin's point of view, to make sure that modifications like this are preserved for successive plugin-executions. > Changes made to project resolved artifacts are overriden when a plugin uses > @requiresDependencyResolution > - > > Key: MNG-3595 > URL: http://jira.codehaus.org/browse/MNG-3595 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: Jerome Lacoste > Attachments: MNG-3595-test-project.tar.bz2, MNG-3595.diff, > MNG-3595.diff > > > clover:instrument mojo creates instrumented artifacts and attaches them with > a 'clover' classifier. > It forks a lifecycle [1][2] and which triggers clover:intrumentInternal which > tries to change the project direct and transitive dependencies after > 'swizzling' them [3] (replacing normal artifacts with their clovered ones). > This in theory would allow to build clovered WAR and EAR, i.e. WAR/EAR > containing all available clovered dependencies. > Unfortunately maven handles direct and transitive dependencies differently > [4]. While direct dependencies are somewhat preserved (the code comments > references clover), transitive dependencies are re-resolved, and thus the > results of the swizzling operation are lost as soon as a plugin > requiresDependencyResolution in a further part of the lifecycle. > I've managed to hack maven and clover:instrument to work together by allowing > a plugin to attach some sort of "dependency resolution post processing" > operation [5]. > In the case of clover:instrument, the swizzling is then registered in the > maven project and re-performed each time the artifacts are re-resolved. > I am not very fond of this solution, but it seems to work for us on the > attached example. I will further test the patch this week on a large scale > project. > I would like to discuss ways to solve this interaction, whether the clover > plugin should be implemented differently or if maven should have some sort of > support for this use case. > [1] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentMojo.java > [2] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/resources/META-INF/maven/lifecycle.xml > [3] > http://svn.atlassian.com/svn/public/contrib/clover/maven-clover-plugin/trunk/src/main/java/com/atlassian/maven/plugin/clover/CloverInstrumentInternalMojo.java > [4] > http://maven.apache.org/ref/2.0.9/maven-core/xref/org/apache/maven/plugin/DefaultPluginManager.html#1406 > [5] http://www.mail-archive.com/[EMAIL PROTECTED]/msg74636.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-3598) trivial patch to enable custom depepndeny resolution mechanism
[ http://jira.codehaus.org/browse/MNG-3598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136555#action_136555 ] Paul Benedict commented on MNG-3598: Unless you actually want those methods overridden (have a particular use case in mind?), they should be marked as final. > trivial patch to enable custom depepndeny resolution mechanism > -- > > Key: MNG-3598 > URL: http://jira.codehaus.org/browse/MNG-3598 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.1 >Reporter: Igor Fedorenko >Assignee: Jason van Zyl > Attachments: tychohacks.diff > > > In order to make OSGi dependency information available during maven build, > Tyhco needs a way to participate in how Maven reads and resolves project > dependencies. Maven 2.1 almost provides this capabilities, except for > unfortunate "private" modifier. Attached is a trivial patch that allows > subclasses override relevant methods. -- 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-456) Allow for manifest customization
Allow for manifest customization Key: MECLIPSE-456 URL: http://jira.codehaus.org/browse/MECLIPSE-456 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Affects Versions: 2.5.1 Reporter: Michael Johns Priority: Minor It would be nice to have the ability to customize the manifest, much the same way the maven-jar-plugin and maven-war-plugin allow. They use the maven-archiver. See http://maven.apache.org/shared/maven-archiver/examples/manifest.html for some ideas of what can be accomplished. Our application reads some information from the manifest dynamically to let us know what version of the code we've deployed, and while it works great when built and deployed on the server, we can't make it work in our dev environments due to how the plugin limits what we can put in the manifest. -- 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: (MEV-572) http://repo1.maven.org/maven/batik/jars/ has bad MD5 entry
[ http://jira.codehaus.org/browse/MEV-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MEV-572. -- Resolution: Fixed Corrected the rewrite rules for what I could find (in addition to batik, listed here)...not sure whether I got everything. > http://repo1.maven.org/maven/batik/jars/ has bad MD5 entry > -- > > Key: MEV-572 > URL: http://jira.codehaus.org/browse/MEV-572 > Project: Maven Evangelism > Issue Type: Bug >Reporter: SebbASF >Assignee: John Casey > > The directory of http://repo1.maven.org/maven/batik/jars/ looks like this to > me: > ... > batik-1.5-fop-0.20-5.jar 22-Jan-2004 08:37 2.0M > batik-1.5-fop-0.20-5.jar.md5 22-Jan-2004 08:37 33 > ... > However, when the md5 is downloaded, it is exactly the same as the jar > - i.e. not the 33 bytes of hash+EOL expected. > Looks like there is a bad link or perhaps a bad htaccess file which is > causing the wrong file to be downloaded. > The equivalent ibiblio entry seems OK: > http://mirrors.ibiblio.org/pub/mirrors/maven/batik/jars/ -- 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: (MEAR-76) This resolution resolves the Clover defect MCLOVER-77
[ http://jira.codehaus.org/browse/MEAR-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136547#action_136547 ] Jerome Lacoste commented on MEAR-76: For information I've fixed MCLOVER-70 (in fact http://developer.atlassian.com/jira/browse/CLMVN-6) by fixing MNG-3595. I wonder if by fixing MNG-3595, this issue would disappear as well. > This resolution resolves the Clover defect MCLOVER-77 > - > > Key: MEAR-76 > URL: http://jira.codehaus.org/browse/MEAR-76 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3.1 > Environment: windows/jdk1.5/cloer plugin 2.3.1 and above >Reporter: Martin Franklin >Assignee: Stephane Nicoll > Attachments: cloverclassifier.diff > > > The clover plugin 'swizzles' the dependencies of an artifact when the > clover:instrument goal is executed. This adds the classifier 'clover' to > those dependencies of the ear which can be resolved as clovered artifacts. > However due to some assumptions made in constructing the ear the problem > detailed in http://jira.codehaus.org/browse/MCLOVER-77 can be created. > The cause turns out to be multiple problems - first after clover 'swizzles' > the dependencies the list gets new versions added during ear processing. I > suspect this is due to the classifier being different so the dependencies of > the dependencies are not found and so they get added again. Thus the same > dependency is listed in the project.getArtifacts() Set. Once with the clover > classifier and once with null. The second problem is the application.xml > generation which adds a second set of dependencies. This can be resolved by > specifying the classifier for the specific module listed in the Modules > section. However this is awkward to use if you wish to use the same pom for > both clovered and unclovered ear generation. This patch supports this. > This patch will always select an artifact with a classifier rather than one > with null set. The matching is only done at the groupid/artifactid level, but > I believe that should be sufficient. > Duplicate EarModules are also removed so that only the most specific > gorupid/artifactid/classifier is used for both inclusion in the ear and > inclusion in the application.xml > One last point about the patch - I could not get test 42 to run before I > started work on the patch, so this test is commented out in the patch. All > the other tests worked fine. > As creating a test would require creating a linkage with the clover plugin, > and the fact that the clover plugin itself needs a patch MCLOVER-82, in order > to fully display these effects easily, I haven't created a test case for it. > I have tested this with my own projects which show that MCLOVER-77 is now > resolved with this patch. -- 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: (MECLIPSE-270) Add support for classpathentry attributes
[ http://jira.codehaus.org/browse/MECLIPSE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136541#action_136541 ] ericeberry edited comment on MECLIPSE-270 at 5/28/08 2:16 PM: -- I have created a patch that includes tests and examples that implement ajdt. Someone please take a look and see if it can be incorporated. was (Author: ericeberry): I have created a patch that includes tests and examples that implements ajdt. Someone please take a look and see if it can be incorporated. > Add support for classpathentry attributes > - > > Key: MECLIPSE-270 > URL: http://jira.codehaus.org/browse/MECLIPSE-270 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: AJDT support >Affects Versions: 2.3 >Reporter: Mike Youngstrom > > With eclipse 3.3 and AJDT 1.5 aspect jars are now configured as an attribute > nested inside of the .classpath file's element Like so: > path="M2_REPO/org/springframework/spring-aspects/2.0.5/spring-aspects-2.0.5.jar" > > sourcepath="M2_REPO/org/springframework/spring-aspects/2.0.5/spring-aspects-2.0.5-sources.jar"> > > > > > It would be nice if it were possible to add attributes to classpathentry's > with some kind of configuration syntax where maybe the dependency artifact > and group are specified and then the attributes for that dependency. > Mike -- 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: (MECLIPSE-313) AJDT feature
[ http://jira.codehaus.org/browse/MECLIPSE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136544#action_136544 ] ericeberry edited comment on MECLIPSE-313 at 5/28/08 2:16 PM: -- I have created a patch that includes tests and examples that implement ajdt. Someone please take a look and see if it can be incorporated. The patch is in MECLIPSE-200. was (Author: ericeberry): I have created a patch that includes tests and examples that implements ajdt. Someone please take a look and see if it can be incorporated. The patch is in MECLIPSE-200. > AJDT feature > > > Key: MECLIPSE-313 > URL: http://jira.codehaus.org/browse/MECLIPSE-313 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: AJDT support > Environment: Windows / Linux >Reporter: Cyril JOUI >Priority: Minor > Attachments: EclipsePlugin.java > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > This feature adds configuration parameters for project which use AspectJ > Compiler. > It is a current preview version. I will go on my work this week ... > To use it, add -Dajdtversion=1.5 (currently tested version of this plugin). > Changes made on EclipsePlugin.java -- 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: (MECLIPSE-200) Please add support for the AJDT plugin
[ http://jira.codehaus.org/browse/MECLIPSE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136539#action_136539 ] ericeberry edited comment on MECLIPSE-200 at 5/28/08 2:16 PM: -- This has been updated for maven-eclipse-plugin 2.5.1 and also ajdt version 1.5.3. I have also included tests and updates to the site build to show how to use it. Hopefully one of the commiters will be willing to look at this and incorporate it. was (Author: ericeberry): This has been updated for mavn-eclipse-plugin 2.5.1 and also ajdt version 1.5.3. I have also included tests and updates to the site build to show how to use it. Hopefully one of the commiters will be willing to look at this and incorporate it. > Please add support for the AJDT plugin > -- > > Key: MECLIPSE-200 > URL: http://jira.codehaus.org/browse/MECLIPSE-200 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: AJDT support >Affects Versions: 2.2 >Reporter: Eric Berry > Attachments: ajdt.patch, maven-eclipse-plugin.zip, > maven-eclipse-plugin.zip > > > Please add support for the AJDT plugin. > I have modified the eclipse plugin for our site with the needed changes. I > have attached the modifications that I made for someone to look at and > incorporate into the plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-313) AJDT feature
[ http://jira.codehaus.org/browse/MECLIPSE-313?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136544#action_136544 ] Eric Berry commented on MECLIPSE-313: - I have created a patch that includes tests and examples that implements ajdt. Someone please take a look and see if it can be incorporated. The patch is in MECLIPSE-200. > AJDT feature > > > Key: MECLIPSE-313 > URL: http://jira.codehaus.org/browse/MECLIPSE-313 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: AJDT support > Environment: Windows / Linux >Reporter: Cyril JOUI >Priority: Minor > Attachments: EclipsePlugin.java > > Original Estimate: 2 hours > Remaining Estimate: 2 hours > > This feature adds configuration parameters for project which use AspectJ > Compiler. > It is a current preview version. I will go on my work this week ... > To use it, add -Dajdtversion=1.5 (currently tested version of this plugin). > Changes made on EclipsePlugin.java -- 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-270) Add support for classpathentry attributes
[ http://jira.codehaus.org/browse/MECLIPSE-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136542#action_136542 ] Eric Berry commented on MECLIPSE-270: - The patch is included in MECLIPSE-200 > Add support for classpathentry attributes > - > > Key: MECLIPSE-270 > URL: http://jira.codehaus.org/browse/MECLIPSE-270 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: AJDT support >Affects Versions: 2.3 >Reporter: Mike Youngstrom > > With eclipse 3.3 and AJDT 1.5 aspect jars are now configured as an attribute > nested inside of the .classpath file's element Like so: > path="M2_REPO/org/springframework/spring-aspects/2.0.5/spring-aspects-2.0.5.jar" > > sourcepath="M2_REPO/org/springframework/spring-aspects/2.0.5/spring-aspects-2.0.5-sources.jar"> > > > > > It would be nice if it were possible to add attributes to classpathentry's > with some kind of configuration syntax where maybe the dependency artifact > and group are specified and then the attributes for that dependency. > Mike -- 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-200) Please add support for the AJDT plugin
[ http://jira.codehaus.org/browse/MECLIPSE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136540#action_136540 ] Eric Berry commented on MECLIPSE-200: - Look at the 122kb maven-eclipse-plugin.zip. > Please add support for the AJDT plugin > -- > > Key: MECLIPSE-200 > URL: http://jira.codehaus.org/browse/MECLIPSE-200 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: AJDT support >Affects Versions: 2.2 >Reporter: Eric Berry > Attachments: ajdt.patch, maven-eclipse-plugin.zip, > maven-eclipse-plugin.zip > > > Please add support for the AJDT plugin. > I have modified the eclipse plugin for our site with the needed changes. I > have attached the modifications that I made for someone to look at and > incorporate into the plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MECLIPSE-200) Please add support for the AJDT plugin
[ http://jira.codehaus.org/browse/MECLIPSE-200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Berry updated MECLIPSE-200: Attachment: maven-eclipse-plugin.zip This has been updated for mavn-eclipse-plugin 2.5.1 and also ajdt version 1.5.3. I have also included tests and updates to the site build to show how to use it. Hopefully one of the commiters will be willing to look at this and incorporate it. > Please add support for the AJDT plugin > -- > > Key: MECLIPSE-200 > URL: http://jira.codehaus.org/browse/MECLIPSE-200 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: AJDT support >Affects Versions: 2.2 >Reporter: Eric Berry > Attachments: ajdt.patch, maven-eclipse-plugin.zip, > maven-eclipse-plugin.zip > > > Please add support for the AJDT plugin. > I have modified the eclipse plugin for our site with the needed changes. I > have attached the modifications that I made for someone to look at and > incorporate into the plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MEV-469) jaxb-api available with two different groupIds
[ http://jira.codehaus.org/browse/MEV-469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MEV-469. -- Assignee: John Casey (was: Carlos Sanchez) Resolution: Fixed added a relocation to javax.xml:jaxb-api:2.0 pointing at javax.xml.bind:jaxb-api:2.0 > jaxb-api available with two different groupIds > -- > > Key: MEV-469 > URL: http://jira.codehaus.org/browse/MEV-469 > Project: Maven Evangelism > Issue Type: Bug > Components: Relocation >Reporter: fabrizio giustina >Assignee: John Casey > Attachments: javax.xml.zip > > > jaxb has been uploaded twice with different groupIds: javax.xml and > javax.xml.bind. > See for example: > http://repo1.maven.org/maven2/javax/xml/jaxb-api/2.0/ > http://repo1.maven.org/maven2/javax/xml/bind/jaxb-api/2.0/ > one of those should be removed and replaced with a relocation. The > dev.java.net repository actually list these jars with the "javax.xml.bind" > groupId so probably that should be the right one. -- 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: (MEV-585) Broken checksum for biz.aQute:bndlib 0.0.255 pom
[ http://jira.codehaus.org/browse/MEV-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136532#action_136532 ] Max Bowsher commented on MEV-585: - I found an upstream Maven repository at http://www.aqute.biz/repo/biz/aQute/bndlib/0.0.255/, and determined that the POM in repo1 fails the checksums because it has had *some but not all* of its line-endings changed from LF to CRLF, which is rather odd. > Broken checksum for biz.aQute:bndlib 0.0.255 pom > > > Key: MEV-585 > URL: http://jira.codehaus.org/browse/MEV-585 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher > > md5 and sha1 are incorrect for biz.aQute:bndlib 0.0.255 pom -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-586) Maven 1.x POM in repository for flatpack - specifies pomVersion 3
Maven 1.x POM in repository for flatpack - specifies pomVersion 3 - Key: MEV-586 URL: http://jira.codehaus.org/browse/MEV-586 Project: Maven Evangelism Issue Type: Bug Components: Invalid POM Reporter: Trevor L. Torrez "flatpack" is a maven 1.x project. The pom in the maven2 repository specifies pomVersion as 3 instead of 4.0.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Reopened: (MEV-572) http://repo1.maven.org/maven/batik/jars/ has bad MD5 entry
[ http://jira.codehaus.org/browse/MEV-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] SebbASF reopened MEV-572: - The original report was about: http://repo1.maven.org/maven/batik/jars/batik-1.5-fop-0.20-5.jar.md5 and other files in that directory, not: http://repo1.maven.org/maven2/batik/batik-1.5-fop/0.20-5/batik-1.5-fop-0.20-5.jar.md5 which is in a different repository tree... > http://repo1.maven.org/maven/batik/jars/ has bad MD5 entry > -- > > Key: MEV-572 > URL: http://jira.codehaus.org/browse/MEV-572 > Project: Maven Evangelism > Issue Type: Bug >Reporter: SebbASF >Assignee: John Casey > > The directory of http://repo1.maven.org/maven/batik/jars/ looks like this to > me: > ... > batik-1.5-fop-0.20-5.jar 22-Jan-2004 08:37 2.0M > batik-1.5-fop-0.20-5.jar.md5 22-Jan-2004 08:37 33 > ... > However, when the md5 is downloaded, it is exactly the same as the jar > - i.e. not the 33 bytes of hash+EOL expected. > Looks like there is a bad link or perhaps a bad htaccess file which is > causing the wrong file to be downloaded. > The equivalent ibiblio entry seems OK: > http://mirrors.ibiblio.org/pub/mirrors/maven/batik/jars/ -- 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: (MEV-585) Broken checksum for biz.aQute:bndlib 0.0.255 pom
[ http://jira.codehaus.org/browse/MEV-585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136517#action_136517 ] John Casey commented on MEV-585: Do you know where I might get at a tag for this POM, or have some way to verify that it hasn't changed (or that the changes haven't broken it)? > Broken checksum for biz.aQute:bndlib 0.0.255 pom > > > Key: MEV-585 > URL: http://jira.codehaus.org/browse/MEV-585 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher > > md5 and sha1 are incorrect for biz.aQute:bndlib 0.0.255 pom -- 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: (MEV-582) Provide AspectJ 1.6 jars/poms/javadocs/sources
[ http://jira.codehaus.org/browse/MEV-582?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MEV-582. -- Assignee: John Casey Resolution: Fixed javadocs + checksums added. > Provide AspectJ 1.6 jars/poms/javadocs/sources > -- > > Key: MEV-582 > URL: http://jira.codehaus.org/browse/MEV-582 > Project: Maven Evangelism > Issue Type: Wish >Reporter: David J. M. Karlsen >Assignee: John Casey > Attachments: aspectjrt.tar, aspectjtools.tar, aspectjweaver.tar > > > Provide AspectJ 1.6 jars/poms/javadocs/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] Created: (MEV-585) Broken checksum for biz.aQute:bndlib 0.0.255 pom
Broken checksum for biz.aQute:bndlib 0.0.255 pom Key: MEV-585 URL: http://jira.codehaus.org/browse/MEV-585 Project: Maven Evangelism Issue Type: Bug Reporter: Max Bowsher md5 and sha1 are incorrect for biz.aQute:bndlib 0.0.255 pom -- 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: (MEV-572) http://repo1.maven.org/maven/batik/jars/ has bad MD5 entry
[ http://jira.codehaus.org/browse/MEV-572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MEV-572. -- Assignee: John Casey Resolution: Fixed Just verified that the MD5 checksum file found when browsing to http://repo1.maven.org/maven2/batik/batik-1.5-fop/0.20-5/batik-1.5-fop-0.20-5.jar.md5 looks like a valid MD5 digest. It seems that the problem has been fixed. Reopen with more detail if this issue is not corrected. > http://repo1.maven.org/maven/batik/jars/ has bad MD5 entry > -- > > Key: MEV-572 > URL: http://jira.codehaus.org/browse/MEV-572 > Project: Maven Evangelism > Issue Type: Bug >Reporter: SebbASF >Assignee: John Casey > > The directory of http://repo1.maven.org/maven/batik/jars/ looks like this to > me: > ... > batik-1.5-fop-0.20-5.jar 22-Jan-2004 08:37 2.0M > batik-1.5-fop-0.20-5.jar.md5 22-Jan-2004 08:37 33 > ... > However, when the md5 is downloaded, it is exactly the same as the jar > - i.e. not the 33 bytes of hash+EOL expected. > Looks like there is a bad link or perhaps a bad htaccess file which is > causing the wrong file to be downloaded. > The equivalent ibiblio entry seems OK: > http://mirrors.ibiblio.org/pub/mirrors/maven/batik/jars/ -- 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: (MEV-583) com.Ostermiller.util in maven repo has some classes compiled for 1.6, for no reason
[ http://jira.codehaus.org/browse/MEV-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MEV-583. -- Assignee: John Casey Resolution: Fixed downloaded the jar from the link provided, then uploaded to central and regenerated the checksums. > com.Ostermiller.util in maven repo has some classes compiled for 1.6, for no > reason > --- > > Key: MEV-583 > URL: http://jira.codehaus.org/browse/MEV-583 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Andrew Lombardi >Assignee: John Casey > > Jar has some classes compiled for 1.6, this causes unnecessary dependency on > 1.6 for using this jar. Would suggest that we get a deployable jar that is > 1.5 only, similar to what is already on the Ostermiller website: > http://ostermiller.org/utils/download.html > Link to 1.5 jar: http://ostermiller.org/utils/ostermillerutils_1_07_00.jar -- 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: (MEV-536) Broken checksums and signature for maven-2.0.7.pom
[ http://jira.codehaus.org/browse/MEV-536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey closed MEV-536. -- Assignee: John Casey (was: Jason van Zyl) Resolution: Fixed I removed the signatures from the repository, since I they're bad, we've moved on to 2.0.9+ now, and I cannot verify that those binaries are correct. It shouldn't be much of an issue at this point anyway, I wouldn't guess. > Broken checksums and signature for maven-2.0.7.pom > -- > > Key: MEV-536 > URL: http://jira.codehaus.org/browse/MEV-536 > Project: Maven Evangelism > Issue Type: Bug >Reporter: Max Bowsher >Assignee: John Casey > > http://repo1.maven.org/maven2/org/apache/maven/maven/2.0.7/maven-2.0.7.pom > .md5 and .sha1 are broken due to being in incorrect format (generated by BSD > checksum tools?) > .asc is bad signature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (WAGON-171) Cannot deploy files over existing files if someone else originally uploaded them.
[ http://jira.codehaus.org/browse/WAGON-171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136493#action_136493 ] Benjamin Bentmann commented on WAGON-171: - bq. fixed so the permissions are not set unless you ask them to be in wagon. Brett, how will this fix the issue? If the permissions are specified and two different people upload the same file, wouldn't it still crash for the later deployment? Admittedly, I am not very familar with Wagon but your commit in [r660818|http://svn.apache.org/viewvc?view=rev&revision=660818] doesn't seem to handle this case so I just wonder. > Cannot deploy files over existing files if someone else originally uploaded > them. > - > > Key: WAGON-171 > URL: http://jira.codehaus.org/browse/WAGON-171 > Project: Maven Wagon > Issue Type: Bug > Components: wagon-ssh > Environment: Desktop OS is Windows XP. Deploying to Solaris server > using Tectia SSH2 Client. >Reporter: Frank Russo >Assignee: Brett Porter >Priority: Critical > Fix For: 1.0-beta-3 > > Attachments: File sharing issue with maven-deploy using wagon.txt > > > On first deploy, everything works fine. On next deploy, if a different > developer runs the command, the attached error occurs(see attached the > original email posted to the Maven Users Mailing List.) > The file is owned by the first developer, but has full rwx access (777). If > developer 2 directly connects to the machine, they can do anything to the > file, so it's not a Unix permissions issue... -- 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-3602) Schedule and release Doxia-1.0-beta-1
[ http://jira.codehaus.org/browse/MNG-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MNG-3602: --- Description: See http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan Fix Version/s: 2.0.10 > Schedule and release Doxia-1.0-beta-1 > - > > Key: MNG-3602 > URL: http://jira.codehaus.org/browse/MNG-3602 > Project: Maven 2 > Issue Type: Task >Affects Versions: 2.0.10 >Reporter: Lukas Theussl > Fix For: 2.0.10 > > > See http://docs.codehaus.org/display/MAVEN/Doxia+Release+Plan -- 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-3602) Schedule and release Doxia-1.0-beta-1
Schedule and release Doxia-1.0-beta-1 - Key: MNG-3602 URL: http://jira.codehaus.org/browse/MNG-3602 Project: Maven 2 Issue Type: Task Affects Versions: 2.0.10 Reporter: Lukas Theussl Fix For: 2.0.10 -- 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: (MPDASHBOARD-39) How to hide the subtsk portal
[ http://jira.codehaus.org/browse/MPDASHBOARD-39?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPDASHBOARD-39. Resolution: Incomplete Fix Version/s: (was: 1.8) > How to hide the subtsk portal > - > > Key: MPDASHBOARD-39 > URL: http://jira.codehaus.org/browse/MPDASHBOARD-39 > Project: Maven 1.x Dashboard Plugin > Issue Type: Bug >Affects Versions: 1.8 >Reporter: Uma mahesh > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > How to hide the subtsk portal -- 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] Deleted: (MPDASHBOARD-40) How to hide the subtsk portal
[ http://jira.codehaus.org/browse/MPDASHBOARD-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl deleted MPDASHBOARD-40: - > How to hide the subtsk portal > - > > Key: MPDASHBOARD-40 > URL: http://jira.codehaus.org/browse/MPDASHBOARD-40 > Project: Maven 1.x Dashboard Plugin > Issue Type: Task >Reporter: Uma mahesh > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > How to hide the subtsk portal -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MJAR-61) Manifest classpath ignores the "real" JAR filenames specified in
[
http://jira.codehaus.org/browse/MJAR-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136490#action_136490
]
darbois tomas commented on MJAR-61:
---
The problem on Maven Jar plugin is still existing. maven Jar plugin is
currently on version 2.2
Does anyone have an update on the problem ? Or a patch /workaround :p
Thanks
> Manifest classpath ignores the "real" JAR filenames specified in
>
>
> Key: MJAR-61
> URL: http://jira.codehaus.org/browse/MJAR-61
> Project: Maven 2.x Jar Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Martin Desruisseaux
>
> The manifest classpath generated by Maven ignores the "real" JAR name as
> specified in {{}}. For example the Geotools project tried the
> following configuration:
> {code:xml}
>
> gt-${artifactId}-${version}
> {code}
> but the manifest classpath generated by Maven contains only
> {{${artifactId}-${version}.jar}} entries, which are non-existent JARs.
> *Note:* this problem happen only when the JAR dependencis come from the
> repository. The manifest classpath is correct if all dependencies were
> compiled in the same "{{mvn install}}" cycle. However this workaround is
> applicable only to Geotools developpers (in our case), because users of the
> Geotools library usually download the dependencies from a repository.
> This bug may be related to MJAR-28.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[
http://jira.codehaus.org/browse/MNG-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136485#action_136485
]
darboist edited comment on MNG-2456 at 5/28/08 9:49 AM:
-
Error :p
was (Author: darboist):
The problem on Archiver is still existing. maven archiver is currently on
version 2.3 so the patch is no longer working for last version of plugins. (I
ve looked at the code and the changes on the code are on part of what the patch
is changing).
For example maven-jar-plugin is now using maven archiver 2.3.
Does anyone have an update on the problem ? Or a new patch flly fonctionning
with last version of archiver :p
Thanks
> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
> snapshots
>
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Barrie Treloar
>Assignee: Kenney Westerhof
> Fix For: 2.0.x
>
> Attachments: MNG-2456-maxb.patch, MNG-2456-patch.txt,
> MNG-2456-step1-refactoring-patch.txt,
> MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar will fail because of the differing names.
--
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-3601) Question about maven profiles.xml
[ http://jira.codehaus.org/browse/MNG-3601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-3601. -- Assignee: Benjamin Bentmann Resolution: Not A Bug Please understand that the issue tracker is not intended to answer questions about Maven's usage, its purpose is to track bugs and feature requests. Please raise your question on the [user mailing list|http://maven.apache.org/mail-lists.html]. > Question about maven profiles.xml > - > > Key: MNG-3601 > URL: http://jira.codehaus.org/browse/MNG-3601 > Project: Maven 2 > Issue Type: Task >Reporter: Arturs Kirsis >Assignee: Benjamin Bentmann > > I have a question about profiles.xml > i have there 1 or more profiles. > Example: > - > > > localhost > > false > > > localhost > localhost > ok > > > > localhost2 > > false > > > localhost2 > localhost2 > > > > - > And in pom.xml have profile witch start with: > - > > whls > > > integration > ok > > > > > .. > - > I know that the activation is phase of lifecycle and it should not get the > variables from profiles.xml but maybe there is a way to get them from there? > Thanks and sorry for my bad 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] Commented: (MNG-2456) Maven Archiver creates incorrect Class-Path entry in Manifest for deployed snapshots
[
http://jira.codehaus.org/browse/MNG-2456?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136485#action_136485
]
darbois tomas commented on MNG-2456:
The problem on Archiver is still existing. maven archiver is currently on
version 2.3 so the patch is no longer working for last version of plugins. (I
ve looked at the code and the changes on the code are on part of what the patch
is changing).
For example maven-jar-plugin is now using maven archiver 2.3.
Does anyone have an update on the problem ? Or a new patch flly fonctionning
with last version of archiver :p
Thanks
> Maven Archiver creates incorrect Class-Path entry in Manifest for deployed
> snapshots
>
>
> Key: MNG-2456
> URL: http://jira.codehaus.org/browse/MNG-2456
> Project: Maven 2
> Issue Type: Bug
> Components: maven-archiver
>Affects Versions: 2.0.4
>Reporter: Barrie Treloar
>Assignee: Kenney Westerhof
> Fix For: 2.0.x
>
> Attachments: MNG-2456-maxb.patch, MNG-2456-patch.txt,
> MNG-2456-step1-refactoring-patch.txt,
> MNG-2456-step2-add-test-cases-patch.txt, MNG-2456-step3-fix-bug-patch.txt
>
>
> See related problems MJAR-28 and MASSEMBLY-67.
> Summary:
> The Maven-Archiver uses the file part of the artifact's filename to create
> the Class-Path entries in the Manifest.
> This works fine for released artifacts and non-deployed snapshot.
> The problem occurs when using a deployed snapshot as the assembly plugin will
> copy the dependency as ${artifactId}-${version}-timestampedversion.jar and
> the entry in the Class-Path will be ${artifactId}-${version}-SNAPSHOT
> thus use of java -jar will fail because of the differing names.
--
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: (SCM-379) SCM URL with query transformed incorrectly on release:prepare
SCM URL with query transformed incorrectly on release:prepare - Key: SCM-379 URL: http://jira.codehaus.org/browse/SCM-379 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-svn Affects Versions: 1.0 Reporter: Doron Solomon Attachments: SvnTagBranchUtils.java Given the following scm definition: scm:svn:https://myserver/svn/myproj/pom/trunk scm:svn:https://myserver/svn/myproj/pom/trunk https://myserver/plugins/scmsvn/viewcvs.php/pom/trunk?root=myproj Running the release:prepare goal transforms this to the following (in the POM associated to the tag): scm:svn:https://myserver/svn/myproj/pom/tags/mytag-1 scm:svn:https://myserver/svn/myproj/pom/tags/mytag-1 https://myserver/plugins/scmsvn/viewcvs.php/pom/trunk?root=myproj/tags/mytag-1?root=myproj The element is incorrect, as it is adding the query "?root=myproj" twice. The desired url tag is: https://myserver/plugins/scmsvn/viewcvs.php/pom/tags/mytag-1?root=myproj The problem is in the class org.apache.maven.scm.provider.svn.SvnTagBranchUtils (in artifact org.apache.maven.scm:maven-scm-providers-svn). The method resolveUrl is considering the case where the URL contains a query string, but is not removing the query part of the URL before transforming it. The attached java file contains the patched version of this class that I have tested. -- 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-2071) rsync_ssh request for seleniumdsl.sourceforge.net
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136469#action_136469 ] Cauê Haucke Porta Guerra commented on MAVENUPLOAD-2071: --- Hey guys, Is there anything wrong? Do you have an idea about when the project will be updated? > rsync_ssh request for seleniumdsl.sourceforge.net > - > > Key: MAVENUPLOAD-2071 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2071 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Cauê Haucke Porta Guerra >Assignee: Carlos Sanchez > > "net.sf.seleniumdsl","[EMAIL > PROTECTED]:/home/groups/s/se/seleniumdsl/htdocs/m2repo","rsync_ssh","Caue > Guerra","[EMAIL PROTECTED]",, > Project page generated by maven hosted at project domain: > http://seleniumdsl.sourceforge.net/team-list.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2070) rsync_ssh request for caelum-stella.sourceforge.net
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136468#action_136468 ] Cauê Haucke Porta Guerra commented on MAVENUPLOAD-2070: --- Hey guys, Is there anything wrong? Do you have an idea about when the project will be updated? Project page generated by maven hosted at project domain: http://stella.caelum.com.br/dev/team-list.html > rsync_ssh request for caelum-stella.sourceforge.net > --- > > Key: MAVENUPLOAD-2070 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2070 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Cauê Haucke Porta Guerra >Assignee: Carlos Sanchez > > "net.sf.caelum-stella","[EMAIL > PROTECTED]:/home/groups/c/ca/caelum-stella/htdocs/m2repo","rsync_ssh","Caue > Guerra","[EMAIL PROTECTED]",, > Project page generated by maven hosted at project domain: > http://stella.caelum.com.br/dev/team-list.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MPIR-102) Locale should be taken from maven-site-plugin
Locale should be taken from maven-site-plugin - Key: MPIR-102 URL: http://jira.codehaus.org/browse/MPIR-102 Project: Maven 2.x Project Info Reports Plugin Issue Type: Improvement Reporter: Petr Ferschmann In my pom.xml I have this configuration for site plugin: org.apache.maven.plugins maven-site-plugin cs But project-info-reports are still in english. It would be great if the locale is taken from site plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (DOXIA-244) Upgrade to fop 0.94
Upgrade to fop 0.94 --- Key: DOXIA-244 URL: http://jira.codehaus.org/browse/DOXIA-244 Project: Maven Doxia Issue Type: Improvement Components: Module - FO Affects Versions: 1.0-beta-1 Reporter: Lukas Theussl Attachments: fo-0.94.log Fop 0.94 fixes several bugs [1], I think it's worth upgrading. Unfortunately just bumping the dependency I get an obscure build failure (see attached log) when converting to pdf, apparently because of multiple fo:page-sequence elements, which is not a problem with 0.93. Needs investigation. [1] http://xmlgraphics.apache.org/fop/0.94/changes_0.94.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MECLIPSE-455) Invalid dependent module archive name for EJB artifact
Invalid dependent module archive name for EJB artifact -- Key: MECLIPSE-455 URL: http://jira.codehaus.org/browse/MECLIPSE-455 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: WTP support Affects Versions: 2.5.1 Environment: Maven 2.0.8, JDK 1.5.0_14, Win XP SP3, Version: 3.3.2 Reporter: M.-Leander Reimer For an EAR WTP module the file org.eclipse.wst.common.component is not being generated correctly if there are dependent EJB modules. The suffix of the arhcive name is set to .ejb instead of .jar The problem is in the class AbstractWtpResourceWriter.addDependency(...) line 182 archiveName = dep.getEclipseProjectName() + "." + dep.getType(); so for EJB modules this will produce for example: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-183) Remove xhtml specific events from xdoc parser
[ http://jira.codehaus.org/browse/DOXIA-183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed DOXIA-183. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: (was: 1.0) 1.0-beta-1 Fixed with DOXIA-243. > Remove xhtml specific events from xdoc parser > - > > Key: DOXIA-183 > URL: http://jira.codehaus.org/browse/DOXIA-183 > Project: Maven Doxia > Issue Type: Bug > Components: Module - Xdoc >Affects Versions: 1.0-alpha-9 >Reporter: Lukas Theussl >Assignee: Lukas Theussl > Fix For: 1.0-beta-1 > > > If the current xdoc parser does not recognize an element, it gets emitted as > rawText. This is ok if the output goes to html but it makes the parser > unusable for other sinks, in particular the fo sink (I had a \ element > in an xdoc which made the pdf generation fail). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (DOXIA-243) Add an 'unknown' element to Sink API
[
http://jira.codehaus.org/browse/DOXIA-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed DOXIA-243.
---
Resolution: Fixed
Done in r660885.
> Add an 'unknown' element to Sink API
>
>
> Key: DOXIA-243
> URL: http://jira.codehaus.org/browse/DOXIA-243
> Project: Maven Doxia
> Issue Type: Improvement
> Components: Sink API
>Reporter: Lukas Theussl
>Assignee: Lukas Theussl
> Fix For: 1.0-beta-1
>
>
> In order to solve the problem of rawText emission in the XdocParser (see
> DOXIA-183) I propose to add an "unknown" event to the Sink API:
> {code}
> void unknown( String name, Object[] requiredParams, SinkEventAttributes atts
> );
> {code}
> This would avoid to make assumptions about the receiving sink in the parser
> and allow the specific sinks to deal with the event.
--
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-3601) Question about maven profiles.xml
Question about maven profiles.xml - Key: MNG-3601 URL: http://jira.codehaus.org/browse/MNG-3601 Project: Maven 2 Issue Type: Task Reporter: Arturs Kirsis I have a question about profiles.xml i have there 1 or more profiles. Example: - localhost false localhost localhost ok localhost2 false localhost2 localhost2 - And in pom.xml have profile witch start with: - whls integration ok .. - I know that the activation is phase of lifecycle and it should not get the variables from profiles.xml but maybe there is a way to get them from there? Thanks and sorry for my bad 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] Created: (MSTAGE-5) support non-command execution wagons for deployment
support non-command execution wagons for deployment --- Key: MSTAGE-5 URL: http://jira.codehaus.org/browse/MSTAGE-5 Project: Maven 2.x Stage Plugin Issue Type: Bug Affects Versions: 1.0 Reporter: Maria Odea Ching -- 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: (MSTAGE-3) The stage plugin only supports copying from http(s) to scp urls
[ http://jira.codehaus.org/browse/MSTAGE-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MSTAGE-3. - Assignee: Brett Porter Resolution: Fixed Fix Version/s: 1.0 applied, thanks. This only genericises to command executors - opened MSTAGE-5 to make it work with others > The stage plugin only supports copying from http(s) to scp urls > --- > > Key: MSTAGE-3 > URL: http://jira.codehaus.org/browse/MSTAGE-3 > Project: Maven 2.x Stage Plugin > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Maria Odea Ching >Assignee: Brett Porter > Fix For: 1.0 > > Attachments: MSTAGE-3.patch > > -- 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: (ARCHETYPE-178) omitting the package in the prompts leaves an unhelpful error message
omitting the package in the prompts leaves an unhelpful error message - Key: ARCHETYPE-178 URL: http://jira.codehaus.org/browse/ARCHETYPE-178 Project: Maven Archetype Issue Type: Bug Components: Generator Affects Versions: 2.0-alpha-3 Reporter: Brett Porter Define value for package: : [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] : org.apache.maven.archetype.exception.ArchetypeGenerationConfigurationFailure: The archetype generation must be configured here The archetype generation must be configured here The archetype generation must be configured here I believe - the error message should be better, and prompt again - the package should be defaulting to groupId? -- 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: (ARCHETYPE-135) add a variabl containing package in a path format
[ http://jira.codehaus.org/browse/ARCHETYPE-135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated ARCHETYPE-135: --- Fix Version/s: (was: 2.0-alpha-3) > add a variabl containing package in a path format > - > > Key: ARCHETYPE-135 > URL: http://jira.codehaus.org/browse/ARCHETYPE-135 > Project: Maven Archetype > Issue Type: Improvement >Affects Versions: 2.0-alpha-2 >Reporter: Dominique Jean-Prost > > Actually, there is a variable "package" than can be used in the file during > generation. > It could be great if there was another variable than contained the package in > a path format. Example : > package = com.foo > packageInPathFormat=com/foo > This new variable could be used in resources path. -- 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: (ARCHETYPE-168) CLONE -Unable to locate custom archetypes : archetype repository not resolved.
[ http://jira.codehaus.org/browse/ARCHETYPE-168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated ARCHETYPE-168: --- Fix Version/s: (was: 2.0-alpha-2) > CLONE -Unable to locate custom archetypes : archetype repository not resolved. > -- > > Key: ARCHETYPE-168 > URL: http://jira.codehaus.org/browse/ARCHETYPE-168 > Project: Maven Archetype > Issue Type: Bug > Components: Creator >Affects Versions: 2.0-alpha-1 > Environment: Linux Fedora 8, JDK 1.5, Maven 2.0.7 >Reporter: Francois Le Droff >Assignee: Milos Kleint > > When the following command is issued: > mvn archetype:create -DarchetypeGroupId=org.apache.cocoon > -DarchetypeArtifactId=cocoon-22-archetype-block > -DarchetypeVersion=1.0.0-RC2 -DgroupId=org.cocoondev -DartifactId=geoid-core > Maven 2.0.7 reports this error: > [INFO] [archetype:create] > [WARNING] No archetype repository found. > [WARNING] Specified archetype not found. > Choose archetype: > 1: internal -> appfuse-basic-jsf (AppFuse archetype for creating a web > application with Hibernate, Spring and JSF) > ... > This was solved by specifying use of the 1.0-alpha-7 archetype version in > command line: > org.apache.maven.plugins:maven-archetype-plugin:1.0-alpha-7:create .. -- 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-2433) Maven looks for snapshots in offline mode
[ http://jira.codehaus.org/browse/MNG-2433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136426#action_136426 ] Alphonse Bendt commented on MNG-2433: - we're also seeing the problem with maven 2.0.9. so please re-open the issue! Note we're using a company wide maven repository (artifactory) $ mvn --version Maven version: 2.0.9 Java version: 1.5.0_13 OS name: "mac os x" version: "10.5.2" arch: "i386" Family: "unix" $ mvn -o test [INFO] NOTE: Maven is executing in offline mode. Any artifacts not already in your local repository will be inaccessible. [INFO] Scanning for projects... [INFO] [INFO] Building Embedded JBoss Tests [INFO]task-segment: [test] [INFO] [INFO] [resources:resources] [INFO] Using default encoding to copy filtered resources. [INFO] [compiler:compile] [INFO] Nothing to compile - all classes are up to date [INFO] [resources:testResources] [INFO] Using default encoding to copy filtered resources. [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Failed to resolve artifact. Missing: -- 1) org.jboss.embedded:jboss-embedded:jar:beta3-SNAPSHOT Try downloading the file manually from the project website. Then, install it using the command: mvn install:install-file -DgroupId=org.jboss.embedded -DartifactId=jboss-embedded -Dversion=beta3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file Alternatively, if you host your own repository you can deploy the file there: mvn deploy:deploy-file -DgroupId=org.jboss.embedded -DartifactId=jboss-embedded -Dversion=beta3-SNAPSHOT -Dpackaging=jar -Dfile=/path/to/file -Durl=[url] -DrepositoryId=[id] Path to dependency: 1) akquinet:embedded-tests:jar:1.7-SNAPSHOT 2) org.jboss.embedded:jboss-embedded-all:jar:beta3 3) org.jboss.embedded:jboss-embedded:jar:beta3-SNAPSHOT -- 1 required artifact is missing. for artifact: akquinet:embedded-tests:jar:1.7-SNAPSHOT from the specified remote repositories: akquinet (http://192.168.1.1:8080/artifactory/akquinet), akquinet.snapshots (http://192.168.1.1:8080/artifactory/libs-snapshots) NOTE: Maven is executing in offline mode. Any artifacts not already in your local repository will be inaccessible. [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 2 seconds [INFO] Finished at: Wed May 28 10:13:47 CEST 2008 [INFO] Final Memory: 7M/13M [INFO] the artifact maven complains about seems to be existing in the local repository: $ ls ~/.m2/repository/org/jboss/embedded/jboss-embedded/beta3-SNAPSHOT/ jboss-embedded-beta3-SNAPSHOT.jar jboss-embedded-beta3-SNAPSHOT.pom.sha1 maven-metadata-repository.jboss.org.xml jboss-embedded-beta3-SNAPSHOT.jar.sha1 maven-metadata-cellactive.snapshots.xml maven-metadata-snapshots.jboss.org.xml jboss-embedded-beta3-SNAPSHOT.pom maven-metadata-cellactive.snapshots.xml.sha1 maven-metadata-snapshots.jboss.org.xml.sha1 > Maven looks for snapshots in offline mode > - > > Key: MNG-2433 > URL: http://jira.codehaus.org/browse/MNG-2433 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.5 >Reporter: Carsten Ziegeler >Assignee: Jason van Zyl >Priority: Critical > Fix For: 2.0.6 > > > It seems that sometimes Maven2 is looking for snapshots in offline mode (this > happens for example in the Cocoon project). here is an output that might help: > :\dev\workspace\cocoon-2.2\core\cocoon-webapp>mvn -o -Dmaven.test.skip=true > coc > oon:deploy > [INFO] > NOTE: Maven is executing in offline mode. Any artifacts not already in your > loca > l > repository will be inaccessible. > [INFO] Scanning for projects... > [INFO] Searching repository for plugin with prefix: 'cocoon'. > [INFO] org.apache.maven.plugins: checking for updates from snapshots > [INFO] org.apache.maven.plugins: checking for updates from mortbay-repo > [INFO] org.codehaus.mojo: checking for updates from snapshots > [INFO] org.codehaus.mojo: checking for updates from mortbay-repo > [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: > checkin > g for updates from snapshots > [INFO] snapshot org.apache.cocoon:cocoon-deployer-plugin:1.0.0-SNAPSHOT: > checkin > g for updates from mortbay-repo > [INFO] snapshot or
[jira] Created: (ARCHETYPE-177) NullPointerException generating archetype when mirrors are in settings.xml
NullPointerException generating archetype when mirrors are in settings.xml -- Key: ARCHETYPE-177 URL: http://jira.codehaus.org/browse/ARCHETYPE-177 Project: Maven Archetype Issue Type: Bug Components: Archetypes, Generator Environment: Windows XP Pro Reporter: Frank Adcock When attempting to generate any archetype from the mvn archetype:generate command I get a null pointer exception thrown if I have mirrors defined in my settings.xml file. I believe there is a related issue where mvn package will also get a null pointer exception if a repository specified in the project pom does not have a matching mirror id in the settings.xml. However, the stack trace for the archetype generation is: Choose a number: (1/2/3/4/5/6/7/8/9/10/11/12/13/14/15/16/17/18/19/20/21/22/23/2 4/25/26/27/28/29/30/31/32/33/34/35/36/37/38/39/40/41/42/43/44) 15: : 6 [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] : java.lang.NullPointerException null [INFO] [INFO] Trace org.apache.maven.BuildFailureException at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:579) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandalone Goal(DefaultLifecycleExecutor.java:512) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(Defau ltLifecycleExecutor.java:482) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHan dleFailures(DefaultLifecycleExecutor.java:330) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmen ts(DefaultLifecycleExecutor.java:227) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLi fecycleExecutor.java:142) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl. java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAcces sorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.MojoFailureException at org.apache.maven.archetype.mojos.CreateProjectFromArchetypeMojo.execu te(CreateProjectFromArchetypeMojo.java:202) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPlugi nManager.java:451) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(Defa ultLifecycleExecutor.java:558) ... 16 more [INFO] [INFO] Total time: 7 seconds [INFO] Finished at: Wed May 28 17:49:39 EST 2008 [INFO] Final Memory: 8M/14M [INFO] C:\Documents and Settings\frank\My Documents\Development\Sandbox>mvn -v Maven version: 2.0.9 Java version: 1.5.0_08 OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" The mirrored settings from the settings.xml file are: public-snapshots public-snapshots http://maven.ho.bushlife.com.au:8081/nexus/content/groups/public-snapshots nexus-central http://maven.ho.bushlife.com.au:8081/nexus/content/groups/public central nexus-maven-repo http://maven.ho.bushlife.com.au:8081/nexus/content/groups/public maven-repo nexus-apache-m2-incubator http://maven.ho.bushlife.com.au:8081/nexus/content/groups/public apache.m2.incubator nexus-eclipse-repository http://maven.ho.bushlife.com.au:8081/nexus/content/groups/public eclipse-repository nexus-safehaus-repository http://maven.ho.bushlife.c
[jira] Reopened: (MPDASHBOARD-40) How to hide the subtsk portal
[ http://jira.codehaus.org/browse/MPDASHBOARD-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uma mahesh reopened MPDASHBOARD-40: --- efwffwff > How to hide the subtsk portal > - > > Key: MPDASHBOARD-40 > URL: http://jira.codehaus.org/browse/MPDASHBOARD-40 > Project: Maven 1.x Dashboard Plugin > Issue Type: Task >Reporter: Uma mahesh > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > How to hide the subtsk portal -- 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: (MPDASHBOARD-40) How to hide the subtsk portal
[ http://jira.codehaus.org/browse/MPDASHBOARD-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uma mahesh closed MPDASHBOARD-40. - Resolution: Fixed e > How to hide the subtsk portal > - > > Key: MPDASHBOARD-40 > URL: http://jira.codehaus.org/browse/MPDASHBOARD-40 > Project: Maven 1.x Dashboard Plugin > Issue Type: Task >Reporter: Uma mahesh > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > How to hide the subtsk portal -- 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] Resolved: (MPDASHBOARD-40) How to hide the subtsk portal
[ http://jira.codehaus.org/browse/MPDASHBOARD-40?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uma mahesh resolved MPDASHBOARD-40. --- Resolution: Fixed wfewr > How to hide the subtsk portal > - > > Key: MPDASHBOARD-40 > URL: http://jira.codehaus.org/browse/MPDASHBOARD-40 > Project: Maven 1.x Dashboard Plugin > Issue Type: Task >Reporter: Uma mahesh > Original Estimate: 30 minutes > Remaining Estimate: 30 minutes > > How to hide the subtsk portal -- 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: (MPDASHBOARD-40) How to hide the subtsk portal
How to hide the subtsk portal - Key: MPDASHBOARD-40 URL: http://jira.codehaus.org/browse/MPDASHBOARD-40 Project: Maven 1.x Dashboard Plugin Issue Type: Task Reporter: Uma mahesh How to hide the subtsk portal -- 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: (MPDASHBOARD-39) How to hide the subtsk portal
How to hide the subtsk portal - Key: MPDASHBOARD-39 URL: http://jira.codehaus.org/browse/MPDASHBOARD-39 Project: Maven 1.x Dashboard Plugin Issue Type: Bug Affects Versions: 1.8 Reporter: Uma mahesh Fix For: 1.8 How to hide the subtsk portal -- 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-19) DefaultArtifactInstaller should only overwrite files if timestamp has changed
DefaultArtifactInstaller should only overwrite files if timestamp has changed - Key: MARTIFACT-19 URL: http://jira.codehaus.org/browse/MARTIFACT-19 Project: Maven Artifact Issue Type: Improvement Environment: Linux, JDK 1.5 Reporter: Johannes Martin install:install (from maven-install-plugin) by default uses DefaultArtifactInstaller to install artifacts. DefaultArtifactInstaller in turn uses FileUtils.copyFile(), thereby overwriting destination files even if they are unchanged. It would be helpful if DefaultArtifactInstaller used FileUtils.copyFileIfModified() instead, at least as an option, to speed up the build process. -- 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: (MEAR-76) This resolution resolves the Clover defect MCLOVER-77
[ http://jira.codehaus.org/browse/MEAR-76?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=136413#action_136413 ] Sami Nieminen commented on MEAR-76: --- Is there any plan to add this patch or resolve the classifier bug in other way? We are experiencing the same problem with our ear, which needs to add dependency to 2 artifacts with same group/artifact id but different classifiers. > This resolution resolves the Clover defect MCLOVER-77 > - > > Key: MEAR-76 > URL: http://jira.codehaus.org/browse/MEAR-76 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3.1 > Environment: windows/jdk1.5/cloer plugin 2.3.1 and above >Reporter: Martin Franklin >Assignee: Stephane Nicoll > Attachments: cloverclassifier.diff > > > The clover plugin 'swizzles' the dependencies of an artifact when the > clover:instrument goal is executed. This adds the classifier 'clover' to > those dependencies of the ear which can be resolved as clovered artifacts. > However due to some assumptions made in constructing the ear the problem > detailed in http://jira.codehaus.org/browse/MCLOVER-77 can be created. > The cause turns out to be multiple problems - first after clover 'swizzles' > the dependencies the list gets new versions added during ear processing. I > suspect this is due to the classifier being different so the dependencies of > the dependencies are not found and so they get added again. Thus the same > dependency is listed in the project.getArtifacts() Set. Once with the clover > classifier and once with null. The second problem is the application.xml > generation which adds a second set of dependencies. This can be resolved by > specifying the classifier for the specific module listed in the Modules > section. However this is awkward to use if you wish to use the same pom for > both clovered and unclovered ear generation. This patch supports this. > This patch will always select an artifact with a classifier rather than one > with null set. The matching is only done at the groupid/artifactid level, but > I believe that should be sufficient. > Duplicate EarModules are also removed so that only the most specific > gorupid/artifactid/classifier is used for both inclusion in the ear and > inclusion in the application.xml > One last point about the patch - I could not get test 42 to run before I > started work on the patch, so this test is commented out in the patch. All > the other tests worked fine. > As creating a test would require creating a linkage with the clover plugin, > and the fact that the clover plugin itself needs a patch MCLOVER-82, in order > to fully display these effects easily, I haven't created a test case for it. > I have tested this with my own projects which show that MCLOVER-77 is now > resolved with this patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRESOURCES-68) resources:resources overwrites filtered resources in target directory even if unchanged
resources:resources overwrites filtered resources in target directory even if unchanged --- Key: MRESOURCES-68 URL: http://jira.codehaus.org/browse/MRESOURCES-68 Project: Maven 2.x Resources Plugin Issue Type: Improvement Affects Versions: 2.2 Environment: Linux, JDK 1.5 Reporter: Johannes Martin When processing filtered resources, resources:resources overwrites existing files in the target directory even if they are unchanged. It would be helpful if the plugin would write to a temporary file, then compare the contents of old and new, and overwrite only if the contents have changed. That way, the jar plugin won't have to repackage the whole jar (assuming forced=false) and so on. -- 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
