[jira] (MSITE-672) Interpolation of site deploy URL not done in child
[
https://jira.codehaus.org/browse/MSITE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fred Cooke reopened MSITE-672:
--
Sorry for the delay in replying, but closing this is absolutely not acceptable
to me. Marking it as "cannot reproduce" is just plain inaccurate. "Won't fix"
might be appropriate, but would still have resulted in my reopening with en
emphatic "Then I will!" comment.
*Some* solution *must* be found for this.
My previous comment was written after a few glasses of wine, which may have
been a contributing factor to me confusing the behaviour of m-site-p with that
of m-release-p, which does in fact screw with the variable and differ from the
effective-pom output.
Your first link mentions nothing about such arbitrary transformations as far as
I can tell, and I note that it's been updated today, and as such looked extra
hard. Blind?
Your second link states that "Default value is: parent value [+ path
adjustment] + artifactId " for the site URL. If the parent does NOT contain a
value, but ONLY a variable, then you should honour that variable being
interpolated in the child as with all others. Variables, in Maven, as you well
know, being a core committer, and infinitely more important than I, are
universally interpolated at the lowest level. Trying to do otherwise is
difficult in most cases.
Here it's *impossible" to get the right result without wholesale duplication of
configuration. If my parent had an actual URL, then I'd be quite happy for the
process you describe to take place, BUT IT DOESN'T have a URL, only a variable,
intended to be determined in the child.
> Interpolation of site deploy URL not done in child
> --
>
> Key: MSITE-672
> URL: https://jira.codehaus.org/browse/MSITE-672
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Assignee: Herve Boutemy
>
> I have my parent distribution site config filled out like so:
> {{scp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}/}}
> When the child tries to release:perform or {{site:deploy}} it tries to upload
> with the parent arifactId, groupId and version instead of the current project
> values. These should be interpolated like any other variables in the POM to
> prevent needless duplication in all children.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-672) Interpolation of site deploy URL not done in child
[
https://jira.codehaus.org/browse/MSITE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=324292#comment-324292
]
Fred Cooke commented on MSITE-672:
--
Herve, it certainly can be different! It could honour the effective pom! If it
did that, even if we were forced to *configure* it to do that, due to backward
compatibility with 28340986098 SVN projects, then that would be adequate. The
expectation of any user of maven is that variables will trickle down and end up
defined at the lowest level. Injecting "random" hard coded behaviour into the
middle of this just creates confusion and chaos. A lower level plugin could
explore the tree to find specific details if it so wished, however a lower
level user is SOL if it's all hard coded above them. No where in any maven docs
does it state that these fields will be abused and manipulated in bizarre ways
out side of the usual effective-pom contract. At least give us the power to
have that fundamental functionality in these fields. Thanks in advance :-)
> Interpolation of site deploy URL not done in child
> --
>
> Key: MSITE-672
> URL: https://jira.codehaus.org/browse/MSITE-672
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>
> I have my parent distribution site config filled out like so:
> {{scp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}/}}
> When the child tries to release:perform or {{site:deploy}} it tries to upload
> with the parent arifactId, groupId and version instead of the current project
> values. These should be interpolated like any other variables in the POM to
> prevent needless duplication in all children.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319932#comment-319932 ] Fred Cooke commented on MRELEASE-777: - Wait, you're talking about target/checkout? A minute ago it seemed like you didn't want to use such a thing and wanted to just build in the basedir. I re-read your original post, and I can see what you meant, however it wasn't clear, and was made less clear with your list. What exactly do you want, in which directories, and when? > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319929#comment-319929 ] Fred Cooke edited comment on MRELEASE-777 at 2/18/13 2:56 PM: -- Your usecase is just one. I have ignored pngs/ and tmp/ which devs are allowed/encouraged to put their screenies, WIPs and other random files in. Running git clean -dfx destroys everything, which is a BIG surprise and VERY unwelcome as a default. It's a maven build, maven clean should be sufficient. If it is not, there are project structure problems to resolve (build output outside of target/). was (Author: fredcooke): Your usecase is just one. I have ignored pngs/ and tmp/ which devs are allowed/encouraged to put their screenies, WIPs and other random files in. Running git clean -dfx destroys everything, which is a BIG surprise and VERY unwelcome as a default. It's a maven build, maven clean should be sfufficient. If it is not, there are project structure problems to resolve (build output outside of target/). > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319929#comment-319929 ] Fred Cooke commented on MRELEASE-777: - Your usecase is just one. I have ignored pngs/ and tmp/ which devs are allowed/encouraged to put their screenies, WIPs and other random files in. Running git clean -dfx destroys everything, which is a BIG surprise and VERY unwelcome as a default. It's a maven build, maven clean should be sfufficient. If it is not, there are project structure problems to resolve (build output outside of target/). > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319911#comment-319911 ] Fred Cooke commented on MRELEASE-777: - Building twice seems to me to be necessary. The first pass is a "will it build OK" pass BEFORE committing the pom modifications. Without this you have to chance it, and roll back the commit if broken, which seems messy, even if done manually. I can see the chancing it thing being useful on a huge project, but I can't see any reason to have such a huge project in the first place, to be honest ;-) However it's certainly possible for it to be legit, whether yours is or not, and that should be enough to better support it. So my vote is for chancing it to be optional if at all possible. I agree with your flow with one exception, clean -dxf, this is extremely dangerous and simply has to be an optional thing, if used at all. mvn clean should be sufficient, if not, your project seems to me to be broken. If you execute clean -dxf in some non-git sub-directory and have either your home dir or your root dir under git control with lots of stuff ignored, you're going to potentially nuke your entire account. Use with extreme caution. This IS a maven build, afterall. > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=319897#comment-319897 ] Fred Cooke commented on MRELEASE-777: - My solution to this using variables wouldn't help you, however is likely correct from a historical point of view for most and would be a fraction faster than the hard-link clone. The trouble with your repo is that the hard links apply to the git objects, not the checked out tree, so merely creating a second copy is not acceptable for you, no matter how it's done. I've never understood why it's deemed necessary to create a second copy anyway. The system already checks to ensure that the original copy is clean before proceeding, why not just use it? +1 for an option to not do anything at all and just build in place. > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-672) Interpolation of site deploy URL not done in child
[
https://jira.codehaus.org/browse/MSITE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318445#comment-318445
]
Fred Cooke commented on MSITE-672:
--
That issue seems, at a glance, to be about site.xml, which I don't use at all.
It could be related, though.
> Interpolation of site deploy URL not done in child
> --
>
> Key: MSITE-672
> URL: https://jira.codehaus.org/browse/MSITE-672
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>
> I have my parent distribution site config filled out like so:
> {{scp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}/}}
> When the child tries to release:perform or {{site:deploy}} it tries to upload
> with the parent arifactId, groupId and version instead of the current project
> values. These should be interpolated like any other variables in the POM to
> prevent needless duplication in all children.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-672) Interpolation of site deploy URL not done in child
[
https://jira.codehaus.org/browse/MSITE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=318425#comment-318425
]
Fred Cooke commented on MSITE-672:
--
Thanks for the insight! I have to say, I'm quite surprised to find that the
interpolation is done almost manually on a per field basis. That just seems
insane.
For reference:
https://maven.apache.org/ref/3.0.4/xref/org/apache/maven/model/merge/MavenModelMerger.html#419
Your possible fix around would work for me, I think.
Currently my work around is to declare the property with vars in the parent
with a short name, and just fill out the site distribution with that variable
in the children, but I strongly dislike the duplication of it. My goal is an
empty pom for simple library builds.
> Interpolation of site deploy URL not done in child
> --
>
> Key: MSITE-672
> URL: https://jira.codehaus.org/browse/MSITE-672
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>
> I have my parent distribution site config filled out like so:
> {{scp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}/}}
> When the child tries to release:perform or {{site:deploy}} it tries to upload
> with the parent arifactId, groupId and version instead of the current project
> values. These should be interpolated like any other variables in the POM to
> prevent needless duplication in all children.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-251) Artifact ###### has no file error regression.
[
https://jira.codehaus.org/browse/MPIR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317931#comment-317931
]
Fred Cooke commented on MPIR-251:
-
One additional note which may help, the oracle jars do not *appear* to have
manifests in them, output from one-jar:
{noformat}
JarClassLoader: Warning: Null manifest from input stream associated with:
lib/xmlcomp-1.0.jar
JarClassLoader: Warning: Null manifest from input stream associated with:
lib/xdb-1.0.jar
JarClassLoader: Warning: Null manifest from input stream associated with:
lib/xmlparserv2-1.0.jar
{noformat}
Which doesn't appear to be true, but could be related:
{noformat}
fred@:~/.m2/repository/com/oracle/xmlcomp/1.0$ cat META-INF/MANIFEST.MF
Manifest-Version: 1.0
Sealed: true
Created-By: 1.4.2_08 (Sun Microsystems Inc.)
Name: oracle/xml/async/
Sealed: false
Name: oracle/xml/transviewer/
Sealed: false
Name: oracle/xml/schemavalidator/
Sealed: false
Name: oracle/xml/differ/
Sealed: false
Name: oracle/xml/dbaccess/
Sealed: false
{noformat}
> Artifact ## has no file error regression.
> -
>
> Key: MPIR-251
> URL: https://jira.codehaus.org/browse/MPIR-251
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Ian Brandt
>Priority: Minor
> Attachments: pom.xml
>
>
> It appears that MPIR-158 has regressed. I'm seeing the same exact issue in
> 2.5 with Maven 3.0.4:
> {noformat}
> [INFO] Generating "Dependencies" report---
> maven-project-info-reports-plugin:2.5
> [ERROR] Artifact: com.sun:tools:jar:1.5.0 has no file.
> [ERROR] Artifact: com.thoughtworks.xstream:xstream:jar:1.3 has no file.
> [ERROR] Artifact: commons-beanutils:commons-beanutils:jar:1.8.0 has no file.
> [ERROR] Artifact: commons-cli:commons-cli:jar:1.1 has no file.
> [ERROR] Artifact: commons-codec:commons-codec:jar:1.3 has no file.
> [ERROR] Artifact: commons-collections:commons-collections:jar:3.2.1 has no
> file.
> [ERROR] Artifact: commons-digester:commons-digester:jar:2.0 has no file.
> [ERROR] Artifact: commons-fileupload:commons-fileupload:jar:1.2.2 has no file.
> ...{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317647#comment-317647 ] Fred Cooke commented on MRELEASE-777: - That's not my repo, it's from the (fairly recent) link in the body of the issue. The original reporter is going to do some tests with the latest m-rel-p version. Can you explain how the GIT_DIR GIT_WORK_TREE git checkout method is not portable (across mac/win/lin at least)? I know it's fine on Linux and Mac, and likely any other *nix, but I don't know if non-cygwin Windows would be affected, or not. In fact, if the code is calling for an 'scm *checkout*', as you say, then this seems the only honest thing to do, no matter how fast a local hard-link based clone is. How fast is that on NTFS, btw? Does git clone local use hardlinks on NTFS? It'd not be very nice to shaft Win users, even if it is a broken OS :-) > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317645#comment-317645 ] Fred Cooke commented on MRELEASE-777: - I understand local clones, but the m-rel-p output in question is this: [INFO] Executing: /bin/sh -c cd /home/fg/src/json-schema-validator/target && git clone g...@github.com:fge/json-schema-validator /home/fg/src/json-schema-validator/target/checkout That ain't using hard links ;-) Maybe it's from an old plugin version? > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317643#comment-317643 ] Fred Cooke commented on MRELEASE-777: - Hi Mark! I saw those options, however IMO the clone concept is completely and utterly broken. You already have the repo with a checkout, and the POM from that, in order to even think about doing a release. You also already have the entire history already already, because we're talking Git, not dinosaur stuff ;-) so if you want to do a clone at all, which is brain dead, even locally, then you'd do it from the existing repo. If you don't want to do a clone, and I assure you, you definitely do not ever want to do that, then you simply set GIT_DIR and GIT_WORK_TREE and do a checkout of a hash. Simple as that. Long time no see, too :-) > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317638#comment-317638 ] Fred Cooke commented on MRELEASE-777: - A telling link from Robert, for context here: http://maven.apache.org/scm/maven-scm-providers/maven-scm-providers-git/maven-scm-provider-gitexe/xref/org/apache/maven/scm/provider/git/gitexe/command/checkout/GitCheckOutCommand.html Thanks! > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-777) release plugin shouldn't git clone if the SCM is git
[ https://jira.codehaus.org/browse/MRELEASE-777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317637#comment-317637 ] Fred Cooke commented on MRELEASE-777: - Guys, I see this is closed, however even if those options fix this guy's situation, doing a git clone is absolutely not an acceptable thing to do under any circumstances, is NOT analogous to an SVN checkout, and is for sure a "bug" or at least poor implementation. The *entire* repo is already local. The only sane things to do might be fetch or pull to ensure you're up to date, and do a checkout with GIT_DIR and GIT_WORK_TREE variables set appropriately. Can we reopen this until that's resolved? I had no idea that it was doing this during my releases, and am slightly disturbed to have read this. I only stumbled across it having a chat to the reporter in the freenode channel about some enhancements that he and I would both love to see, but that's another topic for some other issues :-) > release plugin shouldn't git clone if the SCM is git > > > Key: MRELEASE-777 > URL: https://jira.codehaus.org/browse/MRELEASE-777 > Project: Maven 2.x Release Plugin > Issue Type: Improvement > Environment: Linux x86_64, maven 2.2.1 >Reporter: Joel Orlina >Assignee: Mark Struberg > > See here for original issue: > https://issues.sonatype.org/browse/MVNCENTRAL-202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
[
https://jira.codehaus.org/browse/MRELEASE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317380#comment-317380
]
Fred Cooke commented on MRELEASE-814:
-
OK, so we're on the same page completely, now, then :-)
> Property interpolation of developerConnection broken when inheritting from
> parent
> -
>
> Key: MRELEASE-814
> URL: https://jira.codehaus.org/browse/MRELEASE-814
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare
>Affects Versions: 2.0, 2.3.2, 2.4
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Priority: Critical
> Attachments: demo.project.git.release.bug.tgz
>
>
> If {{developerConnection}} is setup like this in a parent and inherited:
> {code:xml}
> scm:git:git:${project.groupId}/${project.artifactId}.git
> {code}
> Then the Git SCM URL is incorrect when attempting to do a {{release:prepare}}
> (and perhaps other operations)
> In the example project that I've included this is what it tries to do:
> {noformat}
> [INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly &&
> git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
> master:master
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
> project ShouldSeeThisOnceOnly: Unable to commit files
> [ERROR] W access for
> com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
> {noformat}
> I've used this same method with the property directly in the project POM with
> success. It seems that having it in the parent is the issue.
> Note, .ssh/config setup is required for a URL of this nature:
> {noformat}
> host git
> user git
> hostname localhost
> port 22
> identityfile ~/.ssh/id_rsa
> {noformat}
> Change these, and the deploy details to suit yourself.
> I sincerely hope that I'm doing something stupid and that this is not a bug
> as I desperately need to do some releases and waiting for a fix wouldn't be
> ideal, nor would hacking what should be inherited into each POM. Sadly, I
> doubt that I'm wrong this time, as I copy pasted the exact contents from my
> bogus parent into my pom, removed the parent ref, and it works as expected.
> This seems like an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
[
https://jira.codehaus.org/browse/MRELEASE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317319#comment-317319
]
Fred Cooke commented on MRELEASE-814:
-
It just occurred to me that this is wrong EVEN for SVN, because the parent is
NOT an aggregator, it's JUST a parent. The behaviour would make sense for a
default MM project only. If a module was nested 2 dirs deep it would be broken
then too. I assume that you must know that you're not a child in an aggregator
while you're executing? How about:
"if not child of aggregator, don't mess with path" and also "if parent relative
path is set to empty to override default of ../pom.xml, don't mess with path"
either of those alone would solve my issue and not depend on hard coding of "if
git" or similar.
> Property interpolation of developerConnection broken when inheritting from
> parent
> -
>
> Key: MRELEASE-814
> URL: https://jira.codehaus.org/browse/MRELEASE-814
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare
>Affects Versions: 2.0, 2.3.2, 2.4
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Priority: Critical
> Attachments: demo.project.git.release.bug.tgz
>
>
> If {{developerConnection}} is setup like this in a parent and inherited:
> {code:xml}
> scm:git:git:${project.groupId}/${project.artifactId}.git
> {code}
> Then the Git SCM URL is incorrect when attempting to do a {{release:prepare}}
> (and perhaps other operations)
> In the example project that I've included this is what it tries to do:
> {noformat}
> [INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly &&
> git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
> master:master
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
> project ShouldSeeThisOnceOnly: Unable to commit files
> [ERROR] W access for
> com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
> {noformat}
> I've used this same method with the property directly in the project POM with
> success. It seems that having it in the parent is the issue.
> Note, .ssh/config setup is required for a URL of this nature:
> {noformat}
> host git
> user git
> hostname localhost
> port 22
> identityfile ~/.ssh/id_rsa
> {noformat}
> Change these, and the deploy details to suit yourself.
> I sincerely hope that I'm doing something stupid and that this is not a bug
> as I desperately need to do some releases and waiting for a fix wouldn't be
> ideal, nor would hacking what should be inherited into each POM. Sadly, I
> doubt that I'm wrong this time, as I copy pasted the exact contents from my
> bogus parent into my pom, removed the parent ref, and it works as expected.
> This seems like an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
[
https://jira.codehaus.org/browse/MRELEASE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317241#comment-317241
]
Fred Cooke commented on MRELEASE-814:
-
You could have each module in a git repo (nested within the root one) and need
to push to and tag each of them, however I'm unsure if anyone would actually do
that. If you were using a pure aggregator (not used as parent) to release the
"module" projects, then you could absolutely expect that they have a URL each.
It would, however, never have a random path-segment dumped onto it.
Solving this properly probably means an independent per-SCM-provider
implementation. And basing each off of a thorough use-case analysis of that SCM
system. Solving it quickly and acceptably can be done with a simple fix that
won't affect existing users of hierarchicle legacy SCMs such as SVN.
Re my earlier question, does the release plugin commit each module separately?
Seems very non-atomic/dangerous/ugly to do so. I'd expect it to be committed
from above, and only committed/tagged separately from below if using an
override in the module.
> Property interpolation of developerConnection broken when inheritting from
> parent
> -
>
> Key: MRELEASE-814
> URL: https://jira.codehaus.org/browse/MRELEASE-814
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare
>Affects Versions: 2.0, 2.3.2, 2.4
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Priority: Critical
> Attachments: demo.project.git.release.bug.tgz
>
>
> If {{developerConnection}} is setup like this in a parent and inherited:
> {code:xml}
> scm:git:git:${project.groupId}/${project.artifactId}.git
> {code}
> Then the Git SCM URL is incorrect when attempting to do a {{release:prepare}}
> (and perhaps other operations)
> In the example project that I've included this is what it tries to do:
> {noformat}
> [INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly &&
> git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
> master:master
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
> project ShouldSeeThisOnceOnly: Unable to commit files
> [ERROR] W access for
> com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
> {noformat}
> I've used this same method with the property directly in the project POM with
> success. It seems that having it in the parent is the issue.
> Note, .ssh/config setup is required for a URL of this nature:
> {noformat}
> host git
> user git
> hostname localhost
> port 22
> identityfile ~/.ssh/id_rsa
> {noformat}
> Change these, and the deploy details to suit yourself.
> I sincerely hope that I'm doing something stupid and that this is not a bug
> as I desperately need to do some releases and waiting for a fix wouldn't be
> ideal, nor would hacking what should be inherited into each POM. Sadly, I
> doubt that I'm wrong this time, as I copy pasted the exact contents from my
> bogus parent into my pom, removed the parent ref, and it works as expected.
> This seems like an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
[
https://jira.codehaus.org/browse/MRELEASE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=317133#comment-317133
]
Fred Cooke commented on MRELEASE-814:
-
What exactly do you mean by "extend"? I don't understand. Usually an MM project
tags all at once, right? And uses SCM config from the aggregator, if the
release is running from there. Or are you talking about releasing a single
module? Does that even make sense/Is that even supported?
Other than that, I'm not sure changing the behaviour in the general case (the
assumed SVN case) is a good idea. It will probably break existing SVN users,
even fif they are a dying breed. Why not simply check for git and don't do
crazy things if git. Maybe mercurial too? Or maybe check for SVN and do crazy
things only then? Or some other similar scheme.
> Property interpolation of developerConnection broken when inheritting from
> parent
> -
>
> Key: MRELEASE-814
> URL: https://jira.codehaus.org/browse/MRELEASE-814
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare
>Affects Versions: 2.0, 2.3.2, 2.4
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Priority: Blocker
> Attachments: demo.project.git.release.bug.tgz
>
>
> If {{developerConnection}} is setup like this in a parent and inherited:
> {code:xml}
> scm:git:git:${project.groupId}/${project.artifactId}.git
> {code}
> Then the Git SCM URL is incorrect when attempting to do a {{release:prepare}}
> (and perhaps other operations)
> In the example project that I've included this is what it tries to do:
> {noformat}
> [INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly &&
> git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
> master:master
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
> project ShouldSeeThisOnceOnly: Unable to commit files
> [ERROR] W access for
> com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
> {noformat}
> I've used this same method with the property directly in the project POM with
> success. It seems that having it in the parent is the issue.
> Note, .ssh/config setup is required for a URL of this nature:
> {noformat}
> host git
> user git
> hostname localhost
> port 22
> identityfile ~/.ssh/id_rsa
> {noformat}
> Change these, and the deploy details to suit yourself.
> I sincerely hope that I'm doing something stupid and that this is not a bug
> as I desperately need to do some releases and waiting for a fix wouldn't be
> ideal, nor would hacking what should be inherited into each POM. Sadly, I
> doubt that I'm wrong this time, as I copy pasted the exact contents from my
> bogus parent into my pom, removed the parent ref, and it works as expected.
> This seems like an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-600) site plugin 3.0 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316606#comment-316606 ] Fred Cooke commented on MSITE-600: -- Thanks for following this up, Dan! Much appreciated. I have a sample project from another issue that can illustrate the issue. Maybe I'll adapt it for this issue/and/or a new issue (if whomever prefers) later today. Maybe :-) > site plugin 3.0 does not permit a child to fully override parent site > deployment URL > > > Key: MSITE-600 > URL: https://jira.codehaus.org/browse/MSITE-600 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.3, 3.0 >Reporter: Benson Margulies >Assignee: Lukas Theussl > Fix For: 2.4, 3.1 > > Attachments: child-pom.xml, muddle.tar, parent-pom.xml > > > The test cases here has a parent with a a distributionManagement/site/url, > and then a child which overrides it with an absolute URL. Except that the > override does not work ... or, at least, looks quite peculiar. > the parent is file:///tmp/bloop > the child is scp://localhost:/tmp/blop > and the result is > [INFO] Error uploading site > Embedded error: Could not make directory > '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. > [INFO] --- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-817) When tagging using git give an appropriate message
Fred Cooke created MRELEASE-817: --- Summary: When tagging using git give an appropriate message Key: MRELEASE-817 URL: https://jira.codehaus.org/browse/MRELEASE-817 Project: Maven 2.x Release Plugin Issue Type: Improvement Components: prepare Affects Versions: 2.4, 2.3.2 Environment: All Reporter: Fred Cooke Priority: Minor "copy for tag 0.4" is plain wrong for git. The message should be more like "Version X.Y.Z tagged by m-rel-p" or something to that effect. Perhaps configurable, or maybe even prompt for it, or pull it from a defined file. This is what I do in my GNU-Make-maven-release-clone such that I can enter a meaningful description of what is in the release, as part of the tag object. I open a new temp file with vim and use the saved file as the tag message. Maven could optionally prompt for it just as it does for the versions itself. In git these are known as annotated tags, and are something that SVN simply does not have. The plugin is already using annotated tags, it's just that the annotation itself is poor. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-812) "prepare" does not commit before tagging and therefore deploys snapshot instead of release
[
https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316541#comment-316541
]
Fred Cooke commented on MRELEASE-812:
-
I just tried to reproduce this behaviour on a simple git-maven project locally
and couldn't:
{noformat}
commit c658aaec37369f040ba77deb05382bbe5284ee1c
Author: Fred Cooke
Date: Thu Jan 3 10:46:21 2013 +0100
Update to 2.4 to assist testing MRELEASE-812.
diff --git a/pom.xml b/pom.xml
index ec5cfe2..9271b8d 100644
--- a/pom.xml
+++ b/pom.xml
@@ -49,7 +49,7 @@
- 2.3.2
+ 2.4
{noformat}
{noformat}
[INFO] --- maven-release-plugin:2.4:prepare (default-cli) @ parent ---
{noformat}
{noformat}
fred@dauntless:~/workspace/parent$ git show 0.4
tag 0.4
Tagger: Fred Cooke
Date: Thu Jan 3 10:47:08 2013 +0100
[maven-release-plugin] copy for tag 0.4
commit bf9e44d196c5735cb4fc585ed33e76496064f2a4
Author: Fred Cooke
Date: Thu Jan 3 10:47:08 2013 +0100
[maven-release-plugin] prepare release 0.4
diff --git a/pom.xml b/pom.xml
index 9271b8d..d413c19 100644
--- a/pom.xml
+++ b/pom.xml
@@ -3,7 +3,7 @@
com.?
parent
- 0.4-SNAPSHOT
+ 0.4
pom
Parent Project
@@ -16,7 +16,7 @@
scm:git:?:parent.git
- HEAD
+ 0.4
{noformat}
> "prepare" does not commit before tagging and therefore deploys snapshot
> instead of release
> --
>
> Key: MRELEASE-812
> URL: https://jira.codehaus.org/browse/MRELEASE-812
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git
>Affects Versions: 2.4
>Reporter: Andrei Pozolotin
> Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt
>
>
> thank you very much for new release!
> http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E
> it seems we need an emergency fix:
> attached are 2 logs:
> 1) mvn-2.3.2.txt invocation that works fine with 2.3.2
> 2) mvn-2.4.0.txt invocation that fails with 2.4
> problem:
> "perform" does not commit tags, deploys snapshot instead of release
> here is project parent:
> http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom
> build is invoked both times with this:
> mvn --define resume=false release:prepare
> mvn --define resume=false release:perform
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-812) "perform" does not commit tags, deploys snapshot instead of release
[ https://jira.codehaus.org/browse/MRELEASE-812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316539#comment-316539 ] Fred Cooke commented on MRELEASE-812: - Additionally, in git a tag is not a commit as such, it's a label on an existing commit. So: "perform" does not commit tags, deploys snapshot instead of release Should be changed to "prepare" does not commit before tagging and therefore deploys snapshot instead of release, as this is what the tag points at. > "perform" does not commit tags, deploys snapshot instead of release > --- > > Key: MRELEASE-812 > URL: https://jira.codehaus.org/browse/MRELEASE-812 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: Git >Affects Versions: 2.4 >Reporter: Andrei Pozolotin > Attachments: mvn-2.3.2.txt, mvn-2.4.0.txt > > > thank you very much for new release! > http://mail-archives.apache.org/mod_mbox/maven-announce/201212.mbox/%3Cop.wpjbptp1kdkhrr@columbia%3E > it seems we need an emergency fix: > attached are 2 logs: > 1) mvn-2.3.2.txt invocation that works fine with 2.3.2 > 2) mvn-2.4.0.txt invocation that fails with 2.4 > problem: > "perform" does not commit tags, deploys snapshot instead of release > here is project parent: > http://search.maven.org/remotecontent?filepath=com/barchart/base/barchart-archon/2.3.6/barchart-archon-2.3.6.pom > build is invoked both times with this: > mvn --define resume=false release:prepare > mvn --define resume=false release:perform -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-671) Regression: site:stage no longer functions for MM projects.
[
https://jira.codehaus.org/browse/MSITE-671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316454#comment-316454
]
Fred Cooke commented on MSITE-671:
--
OK, I did some further playing and my results are as follows:
3.0 just works, with baseDir or basedir, equally.
3.1 and 3.2 behave identically (for my purposes) in that they first report the
correct path, and then fail, with both baseDir and basedir, but differently.
baseDir is not expanded, however basedir is expanded, to an absolute path, and
then complains that it's not an absolute path when it actually IS! I hope this
helps track it down.
Also, my original report, done from memory (like Swiss cheese!) is wrong, links
weren't broken, build was.
{noformat}
3.0 baseDir
[INFO] --- maven-site-plugin:3.0:stage (default-cli) @ reporting-parent ---
[INFO] Using this base directory for staging:
/home/fred/workspace/tara/target/staging/
works
3.0 basedir
[INFO] --- maven-site-plugin:3.0:stage (default-cli) @ reporting-parent ---
[INFO] Using this base directory for staging:
/home/fred/workspace/tara/target/staging/
works
3.1 baseDir
[INFO] --- maven-site-plugin:3.1:stage (default-cli) @ reporting-application ---
[INFO] Using this base directory for staging:
/home/fred/workspace/tara/target/staging/
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.1:stage (default-cli) on project
reporting-application: Execution default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.1:stage failed: Base URI is not
absolute: $%7bproject.baseDir%7d/target/staging/ -> [Help 1]
3.1 basedir
[INFO] --- maven-site-plugin:3.1:stage (default-cli) @ reporting-application ---
[INFO] Using this base directory for staging:
/home/fred/workspace/tara/target/staging/
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.1:stage (default-cli) on project
reporting-application: Execution default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.1:stage failed: Base URI is not
absolute: /home/fred/workspace/tara/target/staging/ -> [Help 1]
3.2 baseDir
[INFO] --- maven-site-plugin:3.2:stage (default-cli) @ reporting-application ---
[INFO] Using this base directory for staging:
/home/fred/workspace/tara/target/staging/
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.2:stage (default-cli) on project
reporting-application: Execution default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.2:stage failed: Base URI is not
absolute: $%7bproject.baseDir%7d/target/staging/ -> [Help 1]
3.2 basedir
[INFO] --- maven-site-plugin:3.2:stage (default-cli) @ reporting-application ---
[INFO] Using this base directory for staging:
/home/fred/workspace/tara/target/staging/
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.2:stage (default-cli) on project
reporting-application: Execution default-cli of goal
org.apache.maven.plugins:maven-site-plugin:3.2:stage failed: Base URI is not
absolute: /home/fred/workspace/tara/target/staging/ -> [Help 1]
{noformat}
> Regression: site:stage no longer functions for MM projects.
> ---
>
> Key: MSITE-671
> URL: https://jira.codehaus.org/browse/MSITE-671
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:stage(-deploy)
>Affects Versions: 3.2
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>
> With site 3.0 I could run mvn site:site site:stage from the top of my
> multi-module project, and it would accumulate a working site in my chosen
> directory exactly as per the instructions here:
> https://maven.apache.org/plugins/maven-site-plugin/stage-mojo.html
> "Deploys the generated site to a local staging or mock directory based on the
> site URL specified in the {{}} section of the POM.
> It can be used to test that links between module sites in a multi-module
> build works."
> I didn't try 3.1, but with 3.2 the links from the parent site to the children
> did not function. I didn't investigate further, though I could if required.
> More info, this is what I have in my parent/aggregator:
> {code:xml}
>
>
> local-viewing
> ${project.baseDir}/target/staging/
>
> {code}
> It was suggested (by Robert) that it may work with this variable used
> instead: ${project.executionProject.basedir} however the staging directory is
> only relevant at the top level anyway, so I don't see why that should be
> necessary. Again, I didn't try it, but can if this is considered intentional
> behaviour change, as opposed to a regression.
> These issues may (or may not) be related:
> http://jira.codehaus.org/browse/MSITE-600
> http://jira.codehaus
[jira] (MRELEASE-816) Various issues with scmCommentPrefix value
[
https://jira.codehaus.org/browse/MRELEASE-816?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fred Cooke reopened MRELEASE-816:
-
See previous comment re consistency. There are at least two possible fixes:
1) Remove space from first commit
2) Add space to second commit
Clearly the latter is preferred as it works around the inability to add space
yourself and is something that pretty much everyone would always want.
> Various issues with scmCommentPrefix value
> --
>
> Key: MRELEASE-816
> URL: https://jira.codehaus.org/browse/MRELEASE-816
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3.2
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Assignee: Robert Scholte
>Priority: Minor
>
> When the {{ }} property is specified the trailing space is
> ignored/trimmed for one of the steps and used for the other. When not
> specified the [maven-release-plugin] has a trailing space for both commit
> messages. For example:
> Releasing sticky-deployer-embedded at 0.8-SNAPSHOTprepare for next
> development iteration
> Releasing sticky-deployer-embedded at 0.8-SNAPSHOT copy for tag
> sticky-deployer-embedded-0.8
> Versus:
> [maven-release-plugin] prepare for next development iteration
> [maven-release-plugin] prepare release 0.1
> Additionally, the version substituted into ${project.version} in this config
> is the SNAPSHOT version from before the release. The tagNameFormat value uses
> the @{project.version} variant to get around this, however if you try to use
> that in the scmCommentPrefix field you get an error.
> Ideally I'd like to set it up like this and have the trailing space respected
> for both commits, and the release version used:
> Releasing ${project.artifactId} version @{project.version}:
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-816) Various issues with scmCommentPrefix value
[
https://jira.codehaus.org/browse/MRELEASE-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316434#comment-316434
]
Fred Cooke commented on MRELEASE-816:
-
And in any case, a space IS inserted for one operation, and not the other, so
they should be consistent.
> Various issues with scmCommentPrefix value
> --
>
> Key: MRELEASE-816
> URL: https://jira.codehaus.org/browse/MRELEASE-816
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3.2
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Assignee: Robert Scholte
>Priority: Minor
>
> When the {{ }} property is specified the trailing space is
> ignored/trimmed for one of the steps and used for the other. When not
> specified the [maven-release-plugin] has a trailing space for both commit
> messages. For example:
> Releasing sticky-deployer-embedded at 0.8-SNAPSHOTprepare for next
> development iteration
> Releasing sticky-deployer-embedded at 0.8-SNAPSHOT copy for tag
> sticky-deployer-embedded-0.8
> Versus:
> [maven-release-plugin] prepare for next development iteration
> [maven-release-plugin] prepare release 0.1
> Additionally, the version substituted into ${project.version} in this config
> is the SNAPSHOT version from before the release. The tagNameFormat value uses
> the @{project.version} variant to get around this, however if you try to use
> that in the scmCommentPrefix field you get an error.
> Ideally I'd like to set it up like this and have the trailing space respected
> for both commits, and the release version used:
> Releasing ${project.artifactId} version @{project.version}:
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-816) Various issues with scmCommentPrefix value
[
https://jira.codehaus.org/browse/MRELEASE-816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316433#comment-316433
]
Fred Cooke commented on MRELEASE-816:
-
In the mean time, how about inserting a space, just as you clearly do for the
standard [maven-release-plugin] value. If that value includes a space, remove
it and insert it by default elsewhere. Thanks for the link to 696, I added a
watch to it.
> Various issues with scmCommentPrefix value
> --
>
> Key: MRELEASE-816
> URL: https://jira.codehaus.org/browse/MRELEASE-816
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.3.2
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Assignee: Robert Scholte
>Priority: Minor
>
> When the {{ }} property is specified the trailing space is
> ignored/trimmed for one of the steps and used for the other. When not
> specified the [maven-release-plugin] has a trailing space for both commit
> messages. For example:
> Releasing sticky-deployer-embedded at 0.8-SNAPSHOTprepare for next
> development iteration
> Releasing sticky-deployer-embedded at 0.8-SNAPSHOT copy for tag
> sticky-deployer-embedded-0.8
> Versus:
> [maven-release-plugin] prepare for next development iteration
> [maven-release-plugin] prepare release 0.1
> Additionally, the version substituted into ${project.version} in this config
> is the SNAPSHOT version from before the release. The tagNameFormat value uses
> the @{project.version} variant to get around this, however if you try to use
> that in the scmCommentPrefix field you get an error.
> Ideally I'd like to set it up like this and have the trailing space respected
> for both commits, and the release version used:
> Releasing ${project.artifactId} version @{project.version}:
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-816) Various issues with scmCommentPrefix value
Fred Cooke created MRELEASE-816:
---
Summary: Various issues with scmCommentPrefix value
Key: MRELEASE-816
URL: https://jira.codehaus.org/browse/MRELEASE-816
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: prepare
Affects Versions: 2.3.2
Environment: Debian Linux OpenJDK 7 mvn 3.0.4
Reporter: Fred Cooke
Priority: Minor
When the {{ }} property is specified the trailing space is
ignored/trimmed for one of the steps and used for the other. When not specified
the [maven-release-plugin] has a trailing space for both commit messages. For
example:
Releasing sticky-deployer-embedded at 0.8-SNAPSHOTprepare for next development
iteration
Releasing sticky-deployer-embedded at 0.8-SNAPSHOT copy for tag
sticky-deployer-embedded-0.8
Versus:
[maven-release-plugin] prepare for next development iteration
[maven-release-plugin] prepare release 0.1
Additionally, the version substituted into ${project.version} in this config is
the SNAPSHOT version from before the release. The tagNameFormat value uses the
@{project.version} variant to get around this, however if you try to use that
in the scmCommentPrefix field you get an error.
Ideally I'd like to set it up like this and have the trailing space respected
for both commits, and the release version used:
Releasing ${project.artifactId} version @{project.version}:
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-672) Interpolation of site deploy URL not done in child
[
https://jira.codehaus.org/browse/MSITE-672?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316425#comment-316425
]
Fred Cooke commented on MSITE-672:
--
Three combos:
declared in parent only - as above
declared in parent and child identically - as above, no change
NOT declared in parent, only in child, identically to before - works as expected
Due to this I and an SCM issue I have an extra 13 lines in every single child
project. I don't like it at all, but it works for now. I'm happy to work with
whoever to help resolve this properly. As far as I'm concernted when mvn
help:effective-pom reports a certain set of values for a property, that is what
I expect to be used. This is in violation of the basic principal of maven pom
properties and late/final evaluation.
> Interpolation of site deploy URL not done in child
> --
>
> Key: MSITE-672
> URL: https://jira.codehaus.org/browse/MSITE-672
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>
> I have my parent distribution site config filled out like so:
> {{scp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}/}}
> When the child tries to release:perform or {{site:deploy}} it tries to upload
> with the parent arifactId, groupId and version instead of the current project
> values. These should be interpolated like any other variables in the POM to
> prevent needless duplication in all children.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-673) site:deploy ignores .ssh/config details and throws exception/error
[
https://jira.codehaus.org/browse/MSITE-673?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316424#comment-316424
]
Fred Cooke commented on MSITE-673:
--
Definitely still an issue with 3.2. After working around MSITE-600 and friends
I'm not back to here. I fooled it by adding "private-site" to my /etc/hosts
file, however the port is wrong, so connection refused. I can't change the port
of my server (obviously) and I don't want something so specific in the pom file
when I may have to change it in future. I want the details externalised. I
guess I have to work around this too by including the port in the url
somewhere. No, the work around is to use scpexe: and the external ssh extension.
{{
org.apache.maven.wagon
wagon-ssh-external
${extension.version.wagon}
}}
Out of all of today's workarounds and issues, this one is the least bad. I
don't like it, and native support should be present, but this works, for me,
for now, on this box, though likely not on winblows.
> site:deploy ignores .ssh/config details and throws exception/error
> --
>
> Key: MSITE-673
> URL: https://jira.codehaus.org/browse/MSITE-673
> Project: Maven 2.x and 3.x Site Plugin
> Issue Type: Bug
> Components: site:deploy
>Affects Versions: 3.0
>Reporter: Fred Cooke
>
> This is certainly not an issue with m-site-p, however it may well not be an
> issue in wagon-provider-api either, as it's on 2.2 and site is still using
> 1.0.
> I have my site distribution URL configured like so:
> {{
> scp://private-site/home/private/site/releases/${project.groupId}/${project.artifactId}/${project.version}/
> }}
> Where "private-site" is an ssh configuration like this output from cat
> ~/.ssh/config:
> {noformat}
> Host private-site
> Hostname real.domain.name
> Port 1234
> {noformat}
> However site:deploy (presumably using wagon) ignores this and throws the
> following:
> {noformat}
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-site-plugin:3.0:deploy (default-cli) on
> project myProject: Error uploading site: Cannot connect. Reason:
> java.net.UnknownHostException: private-site -> [Help 1]
> {noformat}
> I believe this is still an issue with site 3.2, however will check upon
> request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-600) site plugin 3.0 does not permit a child to fully override parent site deployment URL
[ https://jira.codehaus.org/browse/MSITE-600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316421#comment-316421 ] Fred Cooke commented on MSITE-600: -- Firstly, did Dan file another issue on this matter? If so, number/link? Secondly: As far as I can tell this is not at all fixed in 3.2. I opened MSITE-672 earlier, and having seen that this existed, and was closed, updated to 3.2 and put a spec into my child POM expecting a workaround. Same situation as Benson mentions above, IE, global parent used for everything. In my case, I'm *trying* to be smarter, and being thwarted by m-site-p. What I want is my variable-filled url in the parent, and the values from each child used to give a unique path on the server. In lieu of that, and because it works for the SCM connection ONLY when done in the child (MRELEASE-814 filed for that...), I am trying to work around it by overriding with the exact same variable value in my child, and yet it resolves to the parent values with no relationship. In my case, I want the server to be the same, and specify it in the parent. Just the path varies, however this just isn't working, no matter what I try. I can only assume that I have to release yet another parent (5th today...) setup without the site distribution at all and then specify it in the child. The duplication is just getting ridiculous. In response to any claim that fiddling with a global convention is justified, the "effective pom" shows the correct values in all cases. > site plugin 3.0 does not permit a child to fully override parent site > deployment URL > > > Key: MSITE-600 > URL: https://jira.codehaus.org/browse/MSITE-600 > Project: Maven 2.x and 3.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.3, 3.0 >Reporter: Benson Margulies >Assignee: Lukas Theussl > Fix For: 2.4, 3.1 > > Attachments: child-pom.xml, muddle.tar, parent-pom.xml > > > The test cases here has a parent with a a distributionManagement/site/url, > and then a child which overrides it with an absolute URL. Except that the > override does not work ... or, at least, looks quite peculiar. > the parent is file:///tmp/bloop > the child is scp://localhost:/tmp/blop > and the result is > [INFO] Error uploading site > Embedded error: Could not make directory > '/tmp/bloop/../../Users/benson/asf/mvn/site-interp-muddle/child/scp:/localhost:/tmp/blop'. > [INFO] --- -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-815) Local ref for remote not updated by git scm during release
[ https://jira.codehaus.org/browse/MRELEASE-815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316420#comment-316420 ] Fred Cooke commented on MRELEASE-815: - If, instead of pushing, you fetch, it shows the update to the remote. Likewise, a git status shows this: Your branch is ahead of 'remotes/origin/master' by 2 commits. > Local ref for remote not updated by git scm during release > -- > > Key: MRELEASE-815 > URL: https://jira.codehaus.org/browse/MRELEASE-815 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: Git, prepare >Affects Versions: 2.3.2 > Environment: Debian Linux OpenJDK 7 mvn 3.0.4 >Reporter: Fred Cooke >Priority: Trivial > Attachments: mvn.release.fails.to.update.local.ref.for.remote.png > > > When pushing the pom changes during a release prepare the remote itself is > updated correctly, however the local repositories ref for the remote is not. > Simply running "git push" on the command line and getting "Everything up to > date." back remedies the situation, however it'd be nice if mvn didn't leave > the local git repo "dirty" in this way. > Screen shot of gitg showing how it LOOKS attached. Reality is not the same. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-607) release:prepare messes up line wrapping in pom.xml
[
https://jira.codehaus.org/browse/MRELEASE-607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316404#comment-316404
]
Fred Cooke commented on MRELEASE-607:
-
I agree with the above, however I only wrap the first tag over two similarly
long lines. In addition the release:prepare step modifies the SCM section
changing indentation in some cases. It may do other bad things too, but
MRELEASE-814 is blocking me from finding out at this time.
> release:prepare messes up line wrapping in pom.xml
> --
>
> Key: MRELEASE-607
> URL: https://jira.codehaus.org/browse/MRELEASE-607
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: prepare
>Affects Versions: 2.1
>Reporter: Felix H. Dahlke
>
> After invoking {{release:prepare}}, the first lines of my pom.xml file are
> changed from this:
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> {code}
> To this:
> {code:xml}
> http://maven.apache.org/POM/4.0.0";
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
> xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
> http://maven.apache.org/maven-v4_0_0.xsd";>
> {code}
> I'd prefer it if the release plugin would leave the file's line wrapping
> alone.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-673) site:deploy ignores .ssh/config details and throws exception/error
Fred Cooke created MSITE-673:
Summary: site:deploy ignores .ssh/config details and throws
exception/error
Key: MSITE-673
URL: https://jira.codehaus.org/browse/MSITE-673
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.0
Reporter: Fred Cooke
This is certainly not an issue with m-site-p, however it may well not be an
issue in wagon-provider-api either, as it's on 2.2 and site is still using 1.0.
I have my site distribution URL configured like so:
{{
scp://private-site/home/private/site/releases/${project.groupId}/${project.artifactId}/${project.version}/
}}
Where "private-site" is an ssh configuration like this output from cat
~/.ssh/config:
{noformat}
Host private-site
Hostname real.domain.name
Port 1234
{noformat}
However site:deploy (presumably using wagon) ignores this and throws the
following:
{noformat}
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0:deploy (default-cli) on project
myProject: Error uploading site: Cannot connect. Reason:
java.net.UnknownHostException: private-site -> [Help 1]
{noformat}
I believe this is still an issue with site 3.2, however will check upon request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-672) Interpolation of site deploy URL not done in child
Fred Cooke created MSITE-672:
Summary: Interpolation of site deploy URL not done in child
Key: MSITE-672
URL: https://jira.codehaus.org/browse/MSITE-672
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:deploy
Affects Versions: 3.0
Environment: Debian Linux OpenJDK 7 mvn 3.0.4
Reporter: Fred Cooke
I have my parent distribution site config filled out like so:
{{scp://private-site/home/private/site/releases/${project.groupId}/${project.artifactId}/${project.version}/}}
When the child tries to release:perform or site:deploy it tries to upload with
the parent arifactId, groupId and version instead of the current project
values. These should be interpolated like any other variables in the POM to
prevent needless duplication in all children.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MSITE-671) Regression: site:stage no longer functions for MM projects.
Fred Cooke created MSITE-671:
Summary: Regression: site:stage no longer functions for MM
projects.
Key: MSITE-671
URL: https://jira.codehaus.org/browse/MSITE-671
Project: Maven 2.x and 3.x Site Plugin
Issue Type: Bug
Components: site:stage(-deploy)
Affects Versions: 3.2
Environment: Debian Linux OpenJDK 7 mvn 3.0.4
Reporter: Fred Cooke
With site 3.0 I could run mvn site:site site:stage from the top of my
multi-module project, and it would accumulate a working site in my chosen
directory exactly as per the instructions here:
https://maven.apache.org/plugins/maven-site-plugin/stage-mojo.html
"Deploys the generated site to a local staging or mock directory based on the
site URL specified in the {{}} section of the POM. It
can be used to test that links between module sites in a multi-module build
works."
I didn't try 3.1, but with 3.2 the links from the parent site to the children
did not function. I didn't investigate further, though I could if required.
More info, this is what I have in my parent/aggregator:
{code:xml}
local-viewing
${project.baseDir}/target/staging/
{code}
It was suggested (by Robert) that it may work with this variable used instead:
${project.executionProject.basedir} however the staging directory is only
relevant at the top level anyway, so I don't see why that should be necessary.
Again, I didn't try it, but can if this is considered intentional behaviour
change, as opposed to a regression.
These issues may (or may not) be related:
http://jira.codehaus.org/browse/MSITE-600
http://jira.codehaus.org/browse/MSITE-602
http://jira.codehaus.org/browse/MSITE-649
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-815) Local ref for remote not updated by git scm during release
Fred Cooke created MRELEASE-815: --- Summary: Local ref for remote not updated by git scm during release Key: MRELEASE-815 URL: https://jira.codehaus.org/browse/MRELEASE-815 Project: Maven 2.x Release Plugin Issue Type: Bug Components: Git, prepare Affects Versions: 2.3.2 Environment: Debian Linux OpenJDK 7 mvn 3.0.4 Reporter: Fred Cooke Priority: Trivial Attachments: mvn.release.fails.to.update.local.ref.for.remote.png When pushing the pom changes during a release prepare the remote itself is updated correctly, however the local repositories ref for the remote is not. Simply running "git push" on the command line and getting "Everything up to date." back remedies the situation, however it'd be nice if mvn didn't leave the local git repo "dirty" in this way. Screen shot of gitg showing how it LOOKS attached. Reality is not the same. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://jira.codehaus.org/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
[
https://jira.codehaus.org/browse/MRELEASE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316397#comment-316397
]
Fred Cooke edited comment on MRELEASE-814 at 12/31/12 5:48 AM:
---
Having the EXACT same property in the parent and the child project results in
success too. I think it should be clear that this is inconsistent/hard-coded
behaviour given the fact that the field contents are identical and the results
different.
http://maven.apache.org/pom.html#SCM No contract of arbitrary modifications
mentioned here.
I guess MVN + Git is still pretty new. :-(
As a temporary workaround I'm going to add the (exact same identical) SCM
information to each child POM. I hope I can revert this needless duplication at
some point in the not too distant future.
Maven itself seems to be under git now, when are the various plugins scheduled
for migration? And/or how does one gain SVN commit access to something like the
maven release plugin?
was (Author: fredcooke):
Having the EXACT same property in the parent and the child project results
in success too. I think it should be clear that this is inconsistent/hard-coded
behaviour given the fact that the field contents are identical and the results
different.
http://maven.apache.org/pom.html#SCM No contact of arbitrary modifications
mentioned here.
I guess MVN + Git is still pretty new. :-(
As a temporary workaround I'm going to add the (exact same identical) SCM
information to each child POM. I hope I can revert this needless duplication at
some point in the not too distant future.
Maven itself seems to be under git now, when are the various plugins scheduled
for migration? And/or how does one gain SVN commit access to something like the
maven release plugin?
> Property interpolation of developerConnection broken when inheritting from
> parent
> -
>
> Key: MRELEASE-814
> URL: https://jira.codehaus.org/browse/MRELEASE-814
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare
>Affects Versions: 2.0, 2.3.2, 2.4
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Priority: Blocker
> Attachments: demo.project.git.release.bug.tgz
>
>
> If {{developerConnection}} is setup like this in a parent and inherited:
> {code:xml}
> scm:git:git:${project.groupId}/${project.artifactId}.git
> {code}
> Then the Git SCM URL is incorrect when attempting to do a {{release:prepare}}
> (and perhaps other operations)
> In the example project that I've included this is what it tries to do:
> {noformat}
> [INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly &&
> git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
> master:master
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
> project ShouldSeeThisOnceOnly: Unable to commit files
> [ERROR] W access for
> com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
> {noformat}
> I've used this same method with the property directly in the project POM with
> success. It seems that having it in the parent is the issue.
> Note, .ssh/config setup is required for a URL of this nature:
> {noformat}
> host git
> user git
> hostname localhost
> port 22
> identityfile ~/.ssh/id_rsa
> {noformat}
> Change these, and the deploy details to suit yourself.
> I sincerely hope that I'm doing something stupid and that this is not a bug
> as I desperately need to do some releases and waiting for a fix wouldn't be
> ideal, nor would hacking what should be inherited into each POM. Sadly, I
> doubt that I'm wrong this time, as I copy pasted the exact contents from my
> bogus parent into my pom, removed the parent ref, and it works as expected.
> This seems like an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
[
https://jira.codehaus.org/browse/MRELEASE-814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=316397#comment-316397
]
Fred Cooke commented on MRELEASE-814:
-
Having the EXACT same property in the parent and the child project results in
success too. I think it should be clear that this is inconsistent/hard-coded
behaviour given the fact that the field contents are identical and the results
different.
http://maven.apache.org/pom.html#SCM No contact of arbitrary modifications
mentioned here.
I guess MVN + Git is still pretty new. :-(
As a temporary workaround I'm going to add the (exact same identical) SCM
information to each child POM. I hope I can revert this needless duplication at
some point in the not too distant future.
Maven itself seems to be under git now, when are the various plugins scheduled
for migration? And/or how does one gain SVN commit access to something like the
maven release plugin?
> Property interpolation of developerConnection broken when inheritting from
> parent
> -
>
> Key: MRELEASE-814
> URL: https://jira.codehaus.org/browse/MRELEASE-814
> Project: Maven 2.x Release Plugin
> Issue Type: Bug
> Components: Git, prepare
>Affects Versions: 2.0, 2.3.2, 2.4
> Environment: Debian Linux OpenJDK 7 mvn 3.0.4
>Reporter: Fred Cooke
>Priority: Blocker
> Attachments: demo.project.git.release.bug.tgz
>
>
> If developerConnection is setup like this in a parent and inherited:
> scm:git:git:${project.groupId}/${project.artifactId}.git
> Then the Git SCM URL is incorrect when attempting to do a release:prepare
> (and perhaps other operations)
> In the example project that I've included this is what it tries to do:
> [INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly &&
> git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
> master:master
> [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
> project ShouldSeeThisOnceOnly: Unable to commit files
> [ERROR] W access for
> com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
> I've used this same method with the property directly in the project POM with
> success. It seems that having it in the parent is the issue.
> Note, .ssh/config setup is required for a URL of this nature:
> host git
> user git
> hostname localhost
> port 22
> identityfile ~/.ssh/id_rsa
> Change these, and the deploy details to suit yourself.
> I sincerely hope that I'm doing something stupid and that this is not a bug
> as I desperately need to do some releases and waiting for a fix wouldn't be
> ideal, nor would hacking what should be inherited into each POM. Sadly, I
> doubt that I'm wrong this time, as I copy pasted the exact contents from my
> bogus parent into my pom, removed the parent ref, and it works as expected.
> This seems like an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MRELEASE-814) Property interpolation of developerConnection broken when inheritting from parent
Fred Cooke created MRELEASE-814:
---
Summary: Property interpolation of developerConnection broken when
inheritting from parent
Key: MRELEASE-814
URL: https://jira.codehaus.org/browse/MRELEASE-814
Project: Maven 2.x Release Plugin
Issue Type: Bug
Components: Git, prepare
Affects Versions: 2.4, 2.3.2, 2.0
Environment: Debian Linux OpenJDK 7 mvn 3.0.4
Reporter: Fred Cooke
Priority: Blocker
Attachments: demo.project.git.release.bug.tgz
If developerConnection is setup like this in a parent and inherited:
scm:git:git:${project.groupId}/${project.artifactId}.git
Then the Git SCM URL is incorrect when attempting to do a release:prepare (and
perhaps other operations)
In the example project that I've included this is what it tries to do:
[INFO] Executing: /bin/sh -c cd /home/fred/workspace/ShouldSeeThisOnceOnly &&
git push git:com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly
master:master
[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-release-plugin:2.4:prepare (default-cli) on
project ShouldSeeThisOnceOnly: Unable to commit files
[ERROR] W access for
com.example/ShouldSeeThisOnceOnly.git/ShouldSeeThisOnceOnly DENIED to fred
I've used this same method with the property directly in the project POM with
success. It seems that having it in the parent is the issue.
Note, .ssh/config setup is required for a URL of this nature:
host git
user git
hostname localhost
port 22
identityfile ~/.ssh/id_rsa
Change these, and the deploy details to suit yourself.
I sincerely hope that I'm doing something stupid and that this is not a bug as
I desperately need to do some releases and waiting for a fix wouldn't be ideal,
nor would hacking what should be inherited into each POM. Sadly, I doubt that
I'm wrong this time, as I copy pasted the exact contents from my bogus parent
into my pom, removed the parent ref, and it works as expected. This seems like
an ugly hangover from SVN usage to me.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MPIR-251) Artifact ###### has no file error regression.
[
https://jira.codehaus.org/browse/MPIR-251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=314461#comment-314461
]
Fred Cooke commented on MPIR-251:
-
I also get this with Maven 3.0.4, maven-project-info-reports-plugin 2.6 and
oracle artifacts in the dependency tree. Additionally, I noticed that my CPU
usage went low for a while while Dependencies report just hung waiting for
something. Through the rest of the build it hogged a core (which is fine). If I
can help by testing snapshots of the plugin, I'll gladly do so.
> Artifact ## has no file error regression.
> -
>
> Key: MPIR-251
> URL: https://jira.codehaus.org/browse/MPIR-251
> Project: Maven 2.x Project Info Reports Plugin
> Issue Type: Bug
> Components: dependencies
>Affects Versions: 2.5
>Reporter: Ian Brandt
>Priority: Minor
> Attachments: pom.xml
>
>
> It appears that MPIR-158 has regressed. I'm seeing the same exact issue in
> 2.5 with Maven 3.0.4:
> {noformat}
> [INFO] Generating "Dependencies" report---
> maven-project-info-reports-plugin:2.5
> [ERROR] Artifact: com.sun:tools:jar:1.5.0 has no file.
> [ERROR] Artifact: com.thoughtworks.xstream:xstream:jar:1.3 has no file.
> [ERROR] Artifact: commons-beanutils:commons-beanutils:jar:1.8.0 has no file.
> [ERROR] Artifact: commons-cli:commons-cli:jar:1.1 has no file.
> [ERROR] Artifact: commons-codec:commons-codec:jar:1.3 has no file.
> [ERROR] Artifact: commons-collections:commons-collections:jar:3.2.1 has no
> file.
> [ERROR] Artifact: commons-digester:commons-digester:jar:2.0 has no file.
> [ERROR] Artifact: commons-fileupload:commons-fileupload:jar:1.2.2 has no file.
> ...{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
