[jira] Reopened: (MAVENUPLOAD-2620) rsync_ssh request for org.coosproject
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Morten Versvik reopened MAVENUPLOAD-2620: - I can't find org.coosproject in https://svn.apache.org/repos/asf/maven/repository-tools/trunk/src/bin/synchronize/m2-sync/sync.csv or http://repo1.maven.org/maven2/org/coosproject/ Sorry if this is normal and we should give it some time.. > rsync_ssh request for org.coosproject > -- > > Key: MAVENUPLOAD-2620 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2620 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Morten Versvik >Assignee: Carlos Sanchez > > "org.coosproject","mavens...@web.sourceforge.net:/home/groups/c/co/coos/htdocs/m2repo","rsync_ssh","Morten > Versvik","morten.vers...@tellu.no",, > I am a developer: https://sourceforge.net/users/versvik or > http://www.coosproject.org/maven-site/1.0.0/team-list.html (redirects to sf) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2622) dnsjava 2.0.7
dnsjava 2.0.7 - Key: MAVENUPLOAD-2622 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2622 Project: Maven Upload Requests Issue Type: Wish Reporter: Stefano Bagnara dnsjava 2.0.7 I'm not the author of dnsjava, but I already uploaded the 2.0.1 bundle, so here we are with newer bundles. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2623) dnsjava 2.0.6
dnsjava 2.0.6 - Key: MAVENUPLOAD-2623 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2623 Project: Maven Upload Requests Issue Type: Wish Reporter: Stefano Bagnara dnsjava 2.0.6 I'm not the author of dnsjava, but I already uploaded the 2.0.1 bundle, so here we are with newer bundles. PS: this is my second bundle in a row. THe Repository Upload tells me to use a single issue but it was not clear what I'm supposed to insert in the "Bundle URL" (it speaks about an empty line somewhere, but I don't understand it), so I did 2 separate issues. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2624) Sun's javax.activation 1.1.1
Sun's javax.activation 1.1.1 Key: MAVENUPLOAD-2624 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2624 Project: Maven Upload Requests Issue Type: Wish Reporter: Stefano Bagnara central only includes the 1.1 release. This is the updated 1.1.1 release. The jar is distributed under the CDDL license. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-502) checking out a tag from a remote repository fails if the tag was not on the current branch
checking out a tag from a remote repository fails if the tag was not on the current branch -- Key: SCM-502 URL: http://jira.codehaus.org/browse/SCM-502 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.2 Reporter: Mark Struberg Calling scm:checkout for a tag often results in a merge failure. This is caused by the fact that we do a git-pull prior to the checkout, but in fact for tags, we only shall do a git-fetch. This is due to the fact that the tag may be on a different branch, so merging this branch into the current branch in the local repository would destroy the local repository. Instead we should first do a git-fetch [fetchUrl] followed by a git-checkout tagname. This will create a 'detached HEAD' in the local repo which is exactly the way it should be in git. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-503) create a native Java GIT provider using JGit
create a native Java GIT provider using JGit Key: SCM-503 URL: http://jira.codehaus.org/browse/SCM-503 Project: Maven SCM Issue Type: Bug Components: maven-scm-provider-git Affects Versions: 1.2 Reporter: Mark Struberg JGit is a BSD implementation of GIT in pure Java. maven-scm-provider-jgit makes use of JGit so we have a Java only stack which will be a great help on non POSIX conform platforms. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (SCM-498) git providers should use the fetch and push URLs instead of 'origin'
[ http://jira.codehaus.org/browse/SCM-498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed SCM-498. - Resolution: Fixed Fix Version/s: 1.3 > git providers should use the fetch and push URLs instead of 'origin' > - > > Key: SCM-498 > URL: http://jira.codehaus.org/browse/SCM-498 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.3 > > > Currently we use 'origin' and the configuration behind it in .git/config > [remotes] when e.g. pushing to the upstream repo. > This causes problems if a -Dusername or -Dpassword is supplied, because > 'origin' still doesn't reflect those settings. > solution: > we should use the dynamically created URL (with applied username and > password) for each and every location reference in the > maven-scm-providers-git. > While doing this, we should also consider to maintain 2 separate URLs for > fetching and pushing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (SCM-502) checking out a tag from a remote repository fails if the tag was not on the current branch
[ http://jira.codehaus.org/browse/SCM-502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194002#action_194002 ] Mark Struberg commented on SCM-502: --- fixed in Revision 823147 > checking out a tag from a remote repository fails if the tag was not on the > current branch > -- > > Key: SCM-502 > URL: http://jira.codehaus.org/browse/SCM-502 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.3 > > > Calling scm:checkout for a tag often results in a merge failure. > This is caused by the fact that we do a git-pull prior to the checkout, but > in fact for tags, we only shall do a git-fetch. > This is due to the fact that the tag may be on a different branch, so merging > this branch into the current branch in the local repository would destroy the > local repository. > Instead we should first do a git-fetch [fetchUrl] followed by a git-checkout > tagname. > This will create a 'detached HEAD' in the local repo which is exactly the way > it should be in git. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (SCM-502) checking out a tag from a remote repository fails if the tag was not on the current branch
[ http://jira.codehaus.org/browse/SCM-502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed SCM-502. - Resolution: Fixed Fix Version/s: 1.3 > checking out a tag from a remote repository fails if the tag was not on the > current branch > -- > > Key: SCM-502 > URL: http://jira.codehaus.org/browse/SCM-502 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.3 > > > Calling scm:checkout for a tag often results in a merge failure. > This is caused by the fact that we do a git-pull prior to the checkout, but > in fact for tags, we only shall do a git-fetch. > This is due to the fact that the tag may be on a different branch, so merging > this branch into the current branch in the local repository would destroy the > local repository. > Instead we should first do a git-fetch [fetchUrl] followed by a git-checkout > tagname. > This will create a 'detached HEAD' in the local repo which is exactly the way > it should be in git. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (SCM-498) git providers should use the fetch and push URLs instead of 'origin'
[ http://jira.codehaus.org/browse/SCM-498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194004#action_194004 ] Mark Struberg commented on SCM-498: --- fixed in Revision 823147 > git providers should use the fetch and push URLs instead of 'origin' > - > > Key: SCM-498 > URL: http://jira.codehaus.org/browse/SCM-498 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Affects Versions: 1.2 >Reporter: Mark Struberg >Assignee: Mark Struberg > Fix For: 1.3 > > > Currently we use 'origin' and the configuration behind it in .git/config > [remotes] when e.g. pushing to the upstream repo. > This causes problems if a -Dusername or -Dpassword is supplied, because > 'origin' still doesn't reflect those settings. > solution: > we should use the dynamically created URL (with applied username and > password) for each and every location reference in the > maven-scm-providers-git. > While doing this, we should also consider to maintain 2 separate URLs for > fetching and pushing. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (SCM-488) Git provider fails to support 'release:perform' if not releasing from remote HEAD
[ http://jira.codehaus.org/browse/SCM-488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Struberg closed SCM-488. - Resolution: Fixed Fix Version/s: 1.3 fixed in Revision 823147 > Git provider fails to support 'release:perform' if not releasing from remote > HEAD > - > > Key: SCM-488 > URL: http://jira.codehaus.org/browse/SCM-488 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-git >Reporter: Petter Måhlén >Assignee: Mark Struberg > Fix For: 1.3 > > > During the 'release:perform' phase using Git provider the following commands > are issued: > [INFO] Checking out the project to perform the release ... > [INFO] Executing: /bin/sh -c cd /Users/pettermahlen/git/sas-client/target && > git clone git://git.shopzilla.com/site/client/sas-client > /Users/pettermahlen/git/sas-client/target/checkout > [INFO] Working directory: /Users/pettermahlen/git/sas-client/target > [INFO] Executing: /bin/sh -c cd > /Users/pettermahlen/git/sas-client/target/checkout && git pull > git://git.shopzilla.com/site/client/sas-client tag root-5.18-uk > [INFO] Working directory: /Users/pettermahlen/git/sas-client/target/checkout > If the branch that is being released has conflicts (that cannot be > automatically resolved) with the current HEAD at the remote server, the > 'pull' with fail due to merge conflicts. A manual execution can look like: > [pettermah...@petters-macbook-pro target (uk-release)]$ git clone > git://git.shopzilla.com/site/client/sas-client > /Users/pettermahlen/git/sas-client/target/checkout > Initialized empty Git repository in > /Users/pettermahlen/git/sas-client/target/checkout/.git/ > remote: Counting objects: 72993, done. > remote: Compressing objects: 100% (18392/18392), done. > remote: Total 72993 (delta 40752), reused 71454 (delta 39845) > Receiving objects: 100% (72993/72993), 38.22 MiB | 2724 KiB/s, done. > Resolving deltas: 100% (40752/40752), done. > [pettermah...@petters-macbook-pro target (uk-release)]$ cd checkout/ > [pettermah...@petters-macbook-pro checkout (master)]$ git pull > git://git.shopzilla.com/site/client/sas-client tag root-5.18-uk > Auto-merging client/pom.xml > CONFLICT (content): Merge conflict in client/pom.xml > Auto-merging core/pom.xml > CONFLICT (content): Merge conflict in core/pom.xml > Auto-merging model/pom.xml > Pull does a fetch and a merge with what is currently checked out. A potential > fix would be to rather than the 'git pull' command issue the following: > git checkout > That's what I did to get past this situation, and I believe that should work > as a general solution. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-492) Maven Eclipse Plugin does not take dependencyManagement excludes into account when building eclipse CP configuration.
[
http://jira.codehaus.org/browse/MECLIPSE-492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194008#action_194008
]
Arnaud Heritier commented on MECLIPSE-492:
--
FYI exclusions tags are ... and
not ...
> Maven Eclipse Plugin does not take dependencyManagement excludes into account
> when building eclipse CP configuration.
> -
>
> Key: MECLIPSE-492
> URL: http://jira.codehaus.org/browse/MECLIPSE-492
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.5.1
>Reporter: Maarten Billemont
>Assignee: Arnaud Heritier
> Fix For: 2.8
>
>
> I have a parent pom that excludes xml-apis:xml-apis from dom4j:dom4j in the
> dependencyManagement section. To make certain that as the project
> development progresses no artifacts depend on xml-apis:xml-apis (it is
> superseded by org.apache.xerces:xml-apis) I've forced the version of
> xml-apis:xml-apis in the same dependencyManagement section to be -1. No
> artifact should depend on it since I'm excluding all dependencies on it
> manually and adding org.apache.xerces:xml-apis as a manual dependency. In
> Maven this works fine. When I run maven-eclipse-plugin in a child module of
> this pom artifact which depends on dom4j:dom4j however, it tries to download
> xml-apis:xml-apis:jar:-1 and after failing it adds it to the project's
> classpath configuration (which obviously causes eclipse to throw errors not
> being able to find xml-apis:xml-apis:jar:-1 in my local repository.
>
>
>
> dom4j
> dom4j
> ${dom4j.version}
>
>
> xml-apis
> xml-apis
>
>
>
>
> xml-apis
> xml-apis
> -1
>
>
>
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4383) Uninterpolated expressions should cause an error for dependency versions
[
http://jira.codehaus.org/browse/MNG-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194047#action_194047
]
Paul Benedict commented on MNG-4383:
Benjamin, could this also be expanded for plugin versions?
> Uninterpolated expressions should cause an error for dependency versions
>
>
> Key: MNG-4383
> URL: http://jira.codehaus.org/browse/MNG-4383
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.2.1, 3.0-alpha-2
>Reporter: Paul Benedict
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
>
> I declared a dependency as such:
> {noformat}
> org.slf4j
> slf4j-api
> ${slf4j.version}
> {noformat}
> But did not define the *slf4j.version* property. Obviously ${...} is an
> expression and if the expression is not resolved, why allow it? Here was the
> output:
> {noformat} Downloading:
> http://repo1.maven.org/maven2/org/slf4j/slf4j-api/${slf4j.version}/slf4j-api-${slf4j.version}.pom{noformat}
>
> In terms of usability, an obvious expression should be interpolated. If it
> cannot, it should be a runtime error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (SUREFIRE-576) Have the abiltiy to remove a dependency from the test classpath (at least optional ones
Have the abiltiy to remove a dependency from the test classpath (at least optional ones --- Key: SUREFIRE-576 URL: http://jira.codehaus.org/browse/SUREFIRE-576 Project: Maven Surefire Issue Type: New Feature Components: classloading Reporter: Hardy Ferentschik -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-576) Have the abiltiy to remove a dependency from the test classpath (at least optional ones
[ http://jira.codehaus.org/browse/SUREFIRE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194059#action_194059 ] Hardy Ferentschik commented on SUREFIRE-576: Forgot to describe a usecase. Say you are developing a library and you have an optional dependency to another library. Depending on whether this optional library is used at runtime your own library behaves differently. In this scenario I would like to have two test sets. One where the tests are run with the optional dependency on the classpath and one without. It is already possible two configure two executions of the surefire plugin, but I cannot remove a dependency. Basically optional dependencies should be removable via some excludes configuration. > Have the abiltiy to remove a dependency from the test classpath (at least > optional ones > --- > > Key: SUREFIRE-576 > URL: http://jira.codehaus.org/browse/SUREFIRE-576 > Project: Maven Surefire > Issue Type: New Feature > Components: classloading >Reporter: Hardy Ferentschik > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-576) Have the abiltiy to remove a dependency from the test classpath (at least optional ones
[ http://jira.codehaus.org/browse/SUREFIRE-576?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194061#action_194061 ] Hardy Ferentschik commented on SUREFIRE-576: BTW, I know that I can get it working to a certain degree unsing profiles, but the resulting pom just looks terrible. > Have the abiltiy to remove a dependency from the test classpath (at least > optional ones > --- > > Key: SUREFIRE-576 > URL: http://jira.codehaus.org/browse/SUREFIRE-576 > Project: Maven Surefire > Issue Type: New Feature > Components: classloading >Reporter: Hardy Ferentschik > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-4383) Uninterpolated expressions should cause an error for dependency versions
[
http://jira.codehaus.org/browse/MNG-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194047#action_194047
]
Paul Benedict edited comment on MNG-4383 at 10/8/09 12:35 PM:
--
Benjamin, could this also be expanded for plugin versions and distrubution
management URLs? My team just ran into the latter today.
was (Author: paul4christ79):
Benjamin, could this also be expanded for plugin versions?
> Uninterpolated expressions should cause an error for dependency versions
>
>
> Key: MNG-4383
> URL: http://jira.codehaus.org/browse/MNG-4383
> Project: Maven 2
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 2.2.1, 3.0-alpha-2
>Reporter: Paul Benedict
>Assignee: Benjamin Bentmann
> Fix For: 3.0-alpha-3
>
>
> I declared a dependency as such:
> {noformat}
> org.slf4j
> slf4j-api
> ${slf4j.version}
> {noformat}
> But did not define the *slf4j.version* property. Obviously ${...} is an
> expression and if the expression is not resolved, why allow it? Here was the
> output:
> {noformat} Downloading:
> http://repo1.maven.org/maven2/org/slf4j/slf4j-api/${slf4j.version}/slf4j-api-${slf4j.version}.pom{noformat}
>
> In terms of usability, an obvious expression should be interpolated. If it
> cannot, it should be a runtime error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2620) rsync_ssh request for org.coosproject
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2620. --- Resolution: Fixed added now, sorry > rsync_ssh request for org.coosproject > -- > > Key: MAVENUPLOAD-2620 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2620 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Morten Versvik >Assignee: Carlos Sanchez > > "org.coosproject","mavens...@web.sourceforge.net:/home/groups/c/co/coos/htdocs/m2repo","rsync_ssh","Morten > Versvik","morten.vers...@tellu.no",, > I am a developer: https://sourceforge.net/users/versvik or > http://www.coosproject.org/maven-site/1.0.0/team-list.html (redirects to sf) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-597) Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a different version from that in dependency management)
[
http://jira.codehaus.org/browse/MECLIPSE-597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=194102#action_194102
]
Kathy Hale commented on MECLIPSE-597:
-
I'm not sure if I'm having the same problem or not, but I'll comment in case.
Project A and Project B are both being migrated to Maven. I migrated A, except
for the dependency of Project B. Then migrated Project B, installed a snapshot
from B, and then added the coordinates as a dependency to Project A. While both
projects are open, Project A will not resolve the dependency (the files are
"red" in Navigator). But if I close Project B, you can see the snapshot jar
show up in the Maven library. As soon as I open the Project B again, the
snapshot is removed and is not being replaced with the open project (which is
what usually happened before).
In my other projects, I've seen this feature work sometimes, but not always.
Usually when I had problems, it was just out of sync for some reason, but this
is the first time where I've seen it completely fail. It's odd because calling
"Update Maven dependencies" is not having problems, I can do a mvn compile
while its in the broken state, but I cannot resolve that "red" without closing
the child project.
> Workspace dependencies not resolved for SNAPSHOT dependencies (artifact has a
> different version from that in dependency management)
> ---
>
> Key: MECLIPSE-597
> URL: http://jira.codehaus.org/browse/MECLIPSE-597
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: Core : Dependencies resolution and build path
> (.classpath)
>Affects Versions: 2.7
> Environment: Nexus 1.3.6, Eclipse 3.4, Windows XP
>Reporter: Michal Galet
>Priority: Critical
> Attachments: maven-eclipse-plugin-2.7.patch
>
>
> When generating eclipse project with "mvn eclipse:eclipse
> -Declipse.workspace=d:/eclipse-ws" the SNAPSHOT dependencies are not resolved
> from workspace correctly. See console output below. This is probably caused
> by the way how Nexus handles the SNAPSHOTs. The artifact is resolved by
> ArtifactResolver and the version is changed from 1.1.0-SNAPSHOT to
> 1.1.0-20090819.145009-4.
> The comparison should be performed against {{artifact.getBaseVersion()}}
> instead of {{artifact.getVersion()}}. A simple fix is attached as a patch.
> Console output:
> [INFO] Artifact com.test:sample:jar:4.0.0.B02-SNAPSHOT already available a
> s a workspace project, but with different version. Expected:
> 4.0.0.B02-20090819.145009-4, found
> : 4.0.0.B02-SNAPSHOT
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MSHADE-64) Relocating does not work, when an annotation references an enum
Relocating does not work, when an annotation references an enum --- Key: MSHADE-64 URL: http://jira.codehaus.org/browse/MSHADE-64 Project: Maven 2.x Shade Plugin Issue Type: Bug Affects Versions: 1.2.1 Reporter: Alexander von Zitzewitz Priority: Critical Attachments: pom.xml You could reproduce the problem with the attached pom. The enum class javax.xml.bind.annotation.XmlAccessOrder is referenced by the annotation javax.xml.bind.annotation.XmlAccessorType. While the enum itself is moved correctly the reference from annotation to enum is not. This makes the relocation of this package impossible. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
