date:20130524


 [ 
https://jira.codehaus.org/browse/MSITE-501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Herve Boutemy updated MSITE-501:


Description: 
Our Parent has a url defined by

{code:xml}url${site.access.url}/url{code}

where 
{code:xml}properties
site.access.urlhttp://testdoku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url
/properties{code}

this site.access-url is overwritten by settings.xml on our production server to 
the production-server:
{code:xml}site.access.urlhttp://doku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url{code}

(this is for security reasons to avoid productive-changes on misconfigured 
testing-systems)

Unfortunately on our production-server links to the parentPom are generated 
only by the properties of the parentPom ignoring the settings.xml (which is 
used everywhere else). Therefore the parent-links are pointing to the testing 
system and not to production system!

As we are not generating releasePoms (as we need some properties to be present 
in order to allow changing by children) we have no chance to generate correct 
links without putting them directly in the pom :-(


Steps to Reproduce:


Generate a parentPom:

{code:xml}properties
site.access.urlhttp://testdoku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url
/properties
url${site.access.url}/url{code}


Generate a second project using the parent


put in your settings.xml: 
{code:xml}site.access.urlhttp://doku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url{code}


an run site for the child - the parentLink is wrong!

  was:
Our Parent has a url defined by

url${site.access.url}/url

where 
properties
site.access.urlhttp://testdoku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url
/properties

this site.access-url is overwritten by settings.xml on our production server to 
the production-server:
site.access.urlhttp://doku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url

(this is for security reasons to avoid productive-changes on misconfigured 
testing-systems)

Unfortunately on our production-server links to the parentPom are generated 
only by the properties of the parentPom ignoring the settings.xml (which is 
used everywhere else). Therefore the parent-links are pointing to the testing 
system and not to production system!

As we are not generating releasePoms (as we need some properties to be present 
in order to allow changing by children) we have no chance to generate correct 
links without putting them directly in the pom :-(


Steps to Reproduce:


Generate a parentPom:

properties
site.access.urlhttp://testdoku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url
/properties
url${site.access.url}/url


Generate a second project using the parent


put in your settings.xml: 
site.access.urlhttp://doku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url


an run site for the child - the parentLink is wrong!


 Properties overwritten by settings.xml are ignored when creating parent-links
 -

 Key: MSITE-501
 URL: https://jira.codehaus.org/browse/MSITE-501
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: property interpolation
Affects Versions: 2.1.1
 Environment: Maven 2.2.1, Site-Plugin 2.1.1, Linux x86_64
Reporter: Michael Wenig

 Our Parent has a url defined by
 {code:xml}url${site.access.url}/url{code}
 where 
 {code:xml}properties
 site.access.urlhttp://testdoku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url
 /properties{code}
 this site.access-url is overwritten by settings.xml on our production server 
 to the production-server:
 {code:xml}site.access.urlhttp://doku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url{code}
 (this is for security reasons to avoid productive-changes on misconfigured 
 testing-systems)
 Unfortunately on our production-server links to the parentPom are generated 
 only by the properties of the parentPom ignoring the settings.xml (which is 
 used everywhere else). Therefore the parent-links are pointing to the testing 
 system and not to production system!
 As we are not generating releasePoms (as we need some properties to be 
 present in order to allow changing by children) we have no chance to generate 
 correct links without putting them directly in the pom :-(
 Steps to Reproduce:
 Generate a parentPom:
 {code:xml}properties
 site.access.urlhttp://testdoku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url
 /properties
 url${site.access.url}/url{code}
 Generate a second project using the parent
 put in your settings.xml:

[jira] (MSITE-604) Properties from settings.xml are not recognized in site distribution management


[ 
https://jira.codehaus.org/browse/MSITE-604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=325583#comment-325583
 ] 

Herve Boutemy commented on MSITE-604:
-

MSITE-604 IT in maven-site-plugin is working perfectly: property defined in 
settings.xml is overriding value defined in pom.xml (even if I didn't expect it)

see 
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-site-plugin/src/it/MSITE-604/

I don't understand what is not working for you: if you can patch the actual IT 
to show something that is not working, I can work on it

 Properties from settings.xml are not recognized in site distribution 
 management 
 

 Key: MSITE-604
 URL: https://jira.codehaus.org/browse/MSITE-604
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: site:deploy
Affects Versions: 3.0
 Environment: Apache Maven 2.2.1 and 3.0.3
Reporter: Marcin Kuthan
 Fix For: backlog

 Attachments: MSITE-604-it.patch, MSITE-604-maven3-2.patch, 
 MSITE-604-maven3.patch, MSITE-604.tgz


 My distribution management section looks like:
 {code}
 distributionManagement
site
id${acme-corporate-pom.siteRepositoryId}/id
url${acme-corporate-pom.siteRepositoryUrl}/url
/site
 /distributionManagement
 {code}
 Where the default property values are defined in the pom:
 {code}
 properties
 
 acme-corporate-pom.siteRepositoryIdacme-site/acme-corporate-pom.siteRepositoryId
 
 acme-corporate-pom.siteRepositoryUrlscp://sites.intranet.acme.com/var/www/acme-corporate-pom.siteRepositoryUrl
 /properties
 {code}
 I'm able redefine properties from command line, the provided repository is 
 used instead default one:
 {code}
 mvn site:site site:deploy 
 -Dacme-corporate-pom.siteRepositoryUrl=scp://somehost/var/www/sites 
 -Dacme-corporate-pom.siteRepositoryId=somehost
 {code}
 But when I redefine properties in the profile in {{settings.xml}}, they are 
 ignored. The profile is activated in {{activeProfiles}} element. 
 It looks, than only m-site-p ignores properties defined in the 
 {{settings.xml}} file. m-deploy-p recognizes properties as I expected 
 (distribution management section for articats deployment is configured in 
 similar way to site deployment). 
 --
 Marcin Kuthan
 Maven For Enterprise - http://code.google.com/p/m4enterprise/

--
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-501) Properties overwritten by settings.xml are ignored when creating parent-links


[ 
https://jira.codehaus.org/browse/MSITE-501?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=325584#comment-325584
 ] 

Herve Boutemy commented on MSITE-501:
-

can you provide a test zip?
I can't reproduce (and will be forced to close the issue as cannot reproduce)

 Properties overwritten by settings.xml are ignored when creating parent-links
 -

 Key: MSITE-501
 URL: https://jira.codehaus.org/browse/MSITE-501
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: property interpolation
Affects Versions: 2.1.1
 Environment: Maven 2.2.1, Site-Plugin 2.1.1, Linux x86_64
Reporter: Michael Wenig

 Our Parent has a url defined by
 {code:xml}url${site.access.url}/url{code}
 where 
 {code:xml}properties
 site.access.urlhttp://testdoku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url
 /properties{code}
 this site.access-url is overwritten by settings.xml on our production server 
 to the production-server:
 {code:xml}site.access.urlhttp://doku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url{code}
 (this is for security reasons to avoid productive-changes on misconfigured 
 testing-systems)
 Unfortunately on our production-server links to the parentPom are generated 
 only by the properties of the parentPom ignoring the settings.xml (which is 
 used everywhere else). Therefore the parent-links are pointing to the testing 
 system and not to production system!
 As we are not generating releasePoms (as we need some properties to be 
 present in order to allow changing by children) we have no chance to generate 
 correct links without putting them directly in the pom :-(
 Steps to Reproduce:
 Generate a parentPom:
 {code:xml}properties
 site.access.urlhttp://testdoku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url
 /properties
 url${site.access.url}/url{code}
 Generate a second project using the parent
 put in your settings.xml: 
 {code:xml}site.access.urlhttp://doku.ourdomain.de/mvn-sites/${groupId}/${artifactId}/${version}/site.access.url{code}
 an run site for the child - the parentLink is wrong!

--
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:all-tabpanel
 ]

Herve Boutemy closed MSITE-672.
---

Resolution: Cannot Reproduce
  Assignee: Herve Boutemy

 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:
 {{urlscp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}//url}}
 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-632) site from child module ignored


[ 
https://jira.codehaus.org/browse/MSITE-632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=325585#comment-325585
 ] 

Herve Boutemy commented on MSITE-632:
-

I don't understand the issue, I can't reproduce: can you attach a sample zip, 
effective result and expected result?

 site from child module ignored
 

 Key: MSITE-632
 URL: https://jira.codehaus.org/browse/MSITE-632
 Project: Maven 2.x and 3.x Site Plugin
  Issue Type: Bug
  Components: site:deploy
Affects Versions: 3.0
Reporter: Kohsuke Kawaguchi

 In trying to deploy 
 https://github.com/kohsuke/windows-package-checker/tree/4658075119d6ce9e4d6b9975342bbbef477d5f50
  , I noticed that the site I specified in this POM is ignored and the one 
 specified in the parent is used instead. The same site deploys as expected 
 with Maven2 with the site plugin 2.0-beta-7.
 Looking at the source code, I see that 
 {{SiteDeployMojo.getDeployRepositoryURL()}} uses {{getRootSite}} to determine 
 the site to deploy, which explains why my site definition is getting 
 ignored.
 I believe the fix is to use the nearest site definition, not the one that's 
 closest to the root of the inheritance chain. That is, the {{getRootSite()}} 
 should be changed from:
 {code}
 protected Site getRootSite( MavenProject project )
 throws MojoExecutionException
 {
 Site site = getSite( project );
 MavenProject parent = project;
 while ( parent.getParent() != null )
 {
 // MSITE-585, MNG-1943
 parent = siteTool.getParentProject( parent, reactorProjects, 
 localRepository );
 try
 {
 site = getSite( parent );
 }
 catch ( MojoExecutionException e )
 {
 break;
 }
 }
 return site;
 }
 {code}
 to
 {code}
 protected Site getRootSite( MavenProject project )
 throws MojoExecutionException
 {
 Site site = getSite( project );
 MavenProject parent = project;
 while ( site ==null  parent.getParent() != null )
 {
 // MSITE-585, MNG-1943
 parent = siteTool.getParentProject( parent, reactorProjects, 
 localRepository );
 try
 {
 site = getSite( parent );
 }
 catch ( MojoExecutionException e )
 {
 break;
 }
 }
 return site;
 }
 {code}

--
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

2013-05-24 Thread Fred Cooke (JIRA)

[
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:
{{urlscp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}//url}}
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.

[jira] (MSHARED-270) Add Implementation-URL to DefaultImplementationEntries


[ 
https://jira.codehaus.org/browse/MSHARED-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=325588#comment-325588
 ] 

Michael Osipov commented on MSHARED-270:


Fixed with http://svn.apache.org/r1486160

 Add Implementation-URL to DefaultImplementationEntries
 --

 Key: MSHARED-270
 URL: https://jira.codehaus.org/browse/MSHARED-270
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-archiver
Affects Versions: maven-archiver-2.5
Reporter: Michael Osipov
Assignee: Michael Osipov
   Original Estimate: 0 minutes
  Remaining Estimate: 0 minutes

 Add {{Implementation-URL}} to {{DefaultImplementationEntries}} section. By 
 default this is also specified by Oracle: 
 http://docs.oracle.com/javase/1.5.0/docs/guide/jar/jar.html
 The value could default to {{$\{project.url\}}}. This would be one-liner in 
 http://maven.apache.org/shared/maven-archiver/xref/org/apache/maven/archiver/MavenArchiver.html#373

--
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] (MSHARED-270) Add Implementation-URL to DefaultImplementationEntries


 [ 
https://jira.codehaus.org/browse/MSHARED-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov closed MSHARED-270.
--

Resolution: Fixed

 Add Implementation-URL to DefaultImplementationEntries
 --

 Key: MSHARED-270
 URL: https://jira.codehaus.org/browse/MSHARED-270
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-archiver
Affects Versions: maven-archiver-2.5
Reporter: Michael Osipov
Assignee: Michael Osipov
   Original Estimate: 0 minutes
  Remaining Estimate: 0 minutes

 Add {{Implementation-URL}} to {{DefaultImplementationEntries}} section. By 
 default this is also specified by Oracle: 
 http://docs.oracle.com/javase/1.5.0/docs/guide/jar/jar.html
 The value could default to {{$\{project.url\}}}. This would be one-liner in 
 http://maven.apache.org/shared/maven-archiver/xref/org/apache/maven/archiver/MavenArchiver.html#373

--
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] (MSHARED-270) Add Implementation-URL to DefaultImplementationEntries


 [ 
https://jira.codehaus.org/browse/MSHARED-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MSHARED-270:
---

  Assignee: Michael Osipov
Remaining Estimate: 0 minutes
 Original Estimate: 0 minutes

 Add Implementation-URL to DefaultImplementationEntries
 --

 Key: MSHARED-270
 URL: https://jira.codehaus.org/browse/MSHARED-270
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-archiver
Affects Versions: maven-archiver-2.5
Reporter: Michael Osipov
Assignee: Michael Osipov
   Original Estimate: 0 minutes
  Remaining Estimate: 0 minutes

 Add {{Implementation-URL}} to {{DefaultImplementationEntries}} section. By 
 default this is also specified by Oracle: 
 http://docs.oracle.com/javase/1.5.0/docs/guide/jar/jar.html
 The value could default to {{$\{project.url\}}}. This would be one-liner in 
 http://maven.apache.org/shared/maven-archiver/xref/org/apache/maven/archiver/MavenArchiver.html#373

--
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] (MSHARED-270) Add Implementation-URL to DefaultImplementationEntries


 [ 
https://jira.codehaus.org/browse/MSHARED-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Michael Osipov updated MSHARED-270:
---

Fix Version/s: maven-archiver-2.6

 Add Implementation-URL to DefaultImplementationEntries
 --

 Key: MSHARED-270
 URL: https://jira.codehaus.org/browse/MSHARED-270
 Project: Maven Shared Components
  Issue Type: Improvement
  Components: maven-archiver
Affects Versions: maven-archiver-2.5
Reporter: Michael Osipov
Assignee: Michael Osipov
 Fix For: maven-archiver-2.6

   Original Estimate: 0 minutes
  Remaining Estimate: 0 minutes

 Add {{Implementation-URL}} to {{DefaultImplementationEntries}} section. By 
 default this is also specified by Oracle: 
 http://docs.oracle.com/javase/1.5.0/docs/guide/jar/jar.html
 The value could default to {{$\{project.url\}}}. This would be one-liner in 
 http://maven.apache.org/shared/maven-archiver/xref/org/apache/maven/archiver/MavenArchiver.html#373

--
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] (MSKINS-80) Upgrade to Bootstrap 2.3 breaks design


[ 
https://jira.codehaus.org/browse/MSKINS-80?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=325589#comment-325589
 ] 

Michael Osipov commented on MSKINS-80:
--

I'd like to propose to revert back to Bootstrap 2.2 because

1. no one has updated the site.vm and custom.css to Bootstrap 2.3 or does not 
yet knows the real changes in the model
2. such a change must not happen in a patch version

This should be moved to a branch where changes can be safely examined.

 Upgrade to Bootstrap 2.3 breaks design
 --

 Key: MSKINS-80
 URL: https://jira.codehaus.org/browse/MSKINS-80
 Project: Maven Skins
  Issue Type: Improvement
  Components: Fluido Skin
Affects Versions: fluido-1.3.1
Reporter: Michael Osipov
 Attachments: bootstrap 2.2.png, bootstrap-2.2-to-2.3.patch, bootstrap 
 2.3.png


 Tried 1.3.1-SNAPSHOT from trunk. Bootstrap 2.3 is so different from 2.2 that 
 many CSS styles aren't applied anymore because site.vm hasn't been adjusted 
 for. Either go back to 2.2 or update site.vm accordingly.
 One example is li.divider, class is not applied due to changes. See attached 
 screenshots. I guess there are more cases, this is one I have found on the 
 first sight.
 At least for the given example it might be a bug in Bootstrap 2.3.

--
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] (MNG-3525) Settings.xml allowing mirror definitions inside profiles

2013-05-24 Thread Mariusz Smykula (JIRA)


[ 
https://jira.codehaus.org/browse/MNG-3525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=325590#comment-325590
 ] 

Mariusz Smykula commented on MNG-3525:
--

Very useful option...

 Settings.xml allowing mirror definitions inside profiles
 

 Key: MNG-3525
 URL: https://jira.codehaus.org/browse/MNG-3525
 Project: Maven 2  3
  Issue Type: Improvement
  Components: Profiles
Affects Versions: 2.0.9
 Environment: N/A
Reporter: Paul Grove
 Fix For: Issues to be reviewed for 3.x


 I currently use Maven in 2 places 
 1. At work 
 2. Not at work
 At work we have a repository manager thus we have mirror properties in the 
 settings.xml for the whole teams global settings. We also have a defined a 
 number of repositories in our work profile so we can mirror these to 
 different repo's managed by Archiva. Now when I work from home I have to 
 comment out the mirror definitions and activate a home profile which does not 
 define any repos so Maven just goes out to the WWW as normal. So the pain is 
 having to comment out and un-comment the mirror settings every time I go from 
 work to home and visa-versa.
 Can we not have the option to add mirrors inside profiles?  

--
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-tabpanelfocusedCommentId=325598#comment-325598
 ] 

Herve Boutemy edited comment on MSITE-672 at 5/24/13 7:29 PM:
--

bq. 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?
not blind, it has been published yesterday (notice the LATEST in the link, the 
content varies in time)

bq. 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.
You make a difference between a value that's an effective URL and a value 
that's a variable, but Maven model-builder doesn't make such difference: it 
works at String-level, the fact that parent value contains ${} doesn't change 
the fact that the actual artifactId is added during inheritance assembly (and 
before model interpolation, ie replacement of ${} with actual value)

IIUC, we would require to be able to avoid default child urls calculation, 
consistently in project.url and project.distributionManagement.site.url, but 
probably not project.scm.[connection+developerConnection+url] (AFAIK, but 
perhaps someone will find a case where something similar in project.scm is 
useful: there was a discussion in case of git, if I remember correctly)

Notice that it would be a Maven core change (to track with a MNG Jira issue): 
we need to be extremely clear before changing core, because it will be harder 
to change in time (not a plugin version, that can be different in every project)

Notice that I understand the need to avoid copy/paste too: we're facing the 
exact same issue in Maven components since we introduced svnpubsub. The 
solution we found in Maven is:
1. introduce a maven.site.path property, that can contain references to 
artifactId property if needed, or fixed value if we don't want its value to 
change in child pom
2. copy/paste fixed url+project.distributionManagement.site.url value in every 
pom

I know it's not ideal, but for the moment, I didn't find any solution that 
would be general, only hack


  was (Author: hboutemy):
bq. 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?
not blind, it has been published yesterday (notice the LATEST in the link, the 
content varies in time)

bq. 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.
You make a difference between a value that's an effective URL and a value 
that's a variable, but Maven model-builder doesn't make such difference: it 
works at String-level, the fact that parent value contains ${} doesn't change 
the fact that the actual artifactId is added during inheritance assembly (and 
before model interpolation, ie replacement of ${...} with actual value)

IIUC, we would require to be able to avoid default child urls calculation, 
consistently in project.url and project.distributionManagement.site.url, but 
probably not project.scm.[connection+developerConnection+url] (AFAIK, but 
perhaps someone will find a case where something similar in project.scm is 
useful: there was a discussion in case of git, if I remember correctly)

Notice that it would be a Maven core change (to track with a MNG Jira issue): 
we need to be extremely clear before changing core, because it will be harder 
to change in time (not a plugin version, that can be different in every project)

Notice that I understand the need to avoid copy/paste too: we're facing the 
exact same issue in Maven components since we introduced svnpubsub. The 
solution we found in Maven is:
1. introduce a maven.site.path property, that can contain references to 
artifactId property if needed, or fixed value if we don't want its value to 
change in child pom
2. copy/paste fixed url+project.distributionManagement.site.url value in every 
pom

I know it's not ideal, but for the moment, I didn't find any solution that 
would be general, only hack

  
 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:
 {{urlscp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}//url}}
 When the child tries to

[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-tabpanelfocusedCommentId=325598#comment-325598
 ] 

Herve Boutemy commented on MSITE-672:
-

bq. 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?
not blind, it has been published yesterday (notice the LATEST in the link, the 
content varies in time)

bq. 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.
You make a difference between a value that's an effective URL and a value 
that's a variable, but Maven model-builder doesn't make such difference: it 
works at String-level, the fact that parent value contains ${} doesn't change 
the fact that the actual artifactId is added during inheritance assembly (and 
before model interpolation, ie replacement of ${...} with actual value)

IIUC, we would require to be able to avoid default child urls calculation, 
consistently in project.url and project.distributionManagement.site.url, but 
probably not project.scm.[connection+developerConnection+url] (AFAIK, but 
perhaps someone will find a case where something similar in project.scm is 
useful: there was a discussion in case of git, if I remember correctly)

Notice that it would be a Maven core change (to track with a MNG Jira issue): 
we need to be extremely clear before changing core, because it will be harder 
to change in time (not a plugin version, that can be different in every project)

Notice that I understand the need to avoid copy/paste too: we're facing the 
exact same issue in Maven components since we introduced svnpubsub. The 
solution we found in Maven is:
1. introduce a maven.site.path property, that can contain references to 
artifactId property if needed, or fixed value if we don't want its value to 
change in child pom
2. copy/paste fixed url+project.distributionManagement.site.url value in every 
pom

I know it's not ideal, but for the moment, I didn't find any solution that 
would be general, only hack


 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:
 {{urlscp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}//url}}
 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:all-tabpanel
 ]

Herve Boutemy updated MSITE-672:


Issue Type: Wish  (was: Bug)

 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: Wish
  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:
 {{urlscp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}//url}}
 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-tabpanelfocusedCommentId=325599#comment-325599
 ] 

Herve Boutemy commented on MSITE-672:
-

changed the issue type from bug to wish

 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: Wish
  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:
 {{urlscp://private-site/home/private/site/releases/$\{project.groupId}/$\{project.artifactId}/$\{project.version}//url}}
 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-tabpanelfocusedCommentId=325598#comment-325598
 ] 

Herve Boutemy edited comment on MSITE-672 at 5/24/13 7:33 PM:
--

bq. 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?
not blind, it has been published yesterday (notice the LATEST in the link, the 
content varies in time)

bq. 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.
You make a difference between a value that's an effective URL and a value 
that's a variable, but Maven model-builder doesn't make such difference: it 
works at String-level, the fact that parent value contains ${} doesn't change 
the fact that the actual artifactId is added during inheritance assembly (and 
before model interpolation, ie replacement of ${} with actual value)

IIUC, we would require to be able to avoid default child urls calculation, 
consistently in project.url and project.distributionManagement.site.url, but 
probably not project.scm.[connection+developerConnection+url] (AFAIK, but 
perhaps someone will find a case where something similar in project.scm is 
useful: there was a discussion in case of git, if I remember correctly)

Notice that it would be a Maven core change (to track with a MNG Jira issue): 
we need to be extremely clear before changing core, because it will be harder 
to change in time (not a plugin version, that can be different in every project)

Notice that I understand the need to avoid copy/paste too: we're facing the 
exact same issue in Maven components since we introduced svnpubsub. The 
solution we found in Maven is:
1. introduce a maven.site.path property, that can contain references to 
artifactId property if needed, or fixed value if we don't want its value to 
change in child pom
2. copy/paste fixed url+project.distributionManagement.site.url value in every 
pom, with fixed value that references previous maven.site.path property

I know it's not ideal, but for the moment, I didn't find any solution that 
would be general, only hack


  was (Author: hboutemy):
bq. 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?
not blind, it has been published yesterday (notice the LATEST in the link, the 
content varies in time)

bq. 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.
You make a difference between a value that's an effective URL and a value 
that's a variable, but Maven model-builder doesn't make such difference: it 
works at String-level, the fact that parent value contains ${} doesn't change 
the fact that the actual artifactId is added during inheritance assembly (and 
before model interpolation, ie replacement of ${} with actual value)

IIUC, we would require to be able to avoid default child urls calculation, 
consistently in project.url and project.distributionManagement.site.url, but 
probably not project.scm.[connection+developerConnection+url] (AFAIK, but 
perhaps someone will find a case where something similar in project.scm is 
useful: there was a discussion in case of git, if I remember correctly)

Notice that it would be a Maven core change (to track with a MNG Jira issue): 
we need to be extremely clear before changing core, because it will be harder 
to change in time (not a plugin version, that can be different in every project)

Notice that I understand the need to avoid copy/paste too: we're facing the 
exact same issue in Maven components since we introduced svnpubsub. The 
solution we found in Maven is:
1. introduce a maven.site.path property, that can contain references to 
artifactId property if needed, or fixed value if we don't want its value to 
change in child pom
2. copy/paste fixed url+project.distributionManagement.site.url value in every 
pom

I know it's not ideal, but for the moment, I didn't find any solution that 
would be general, only hack

  
 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: Wish
  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:

[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-tabpanelfocusedCommentId=325598#comment-325598
 ] 

Herve Boutemy edited comment on MSITE-672 at 5/24/13 7:36 PM:
--

bq. 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?
not blind, it has been published yesterday (notice the LATEST in the link, the 
content varies in time)

bq. 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.
You make a difference between a value that's an effective URL and a value 
that's a variable, but Maven model-builder doesn't make such difference: it 
works at String-level, the fact that parent value contains ${} doesn't change 
the fact that the actual artifactId is added during inheritance assembly (and 
before model interpolation, ie replacement of ${} with actual value)

IIUC, we would require to be able to avoid default child urls calculation, 
consistently in project.url and project.distributionManagement.site.url, but 
probably not project.scm.[connection+developerConnection+url] (AFAIK, but 
perhaps someone will find a case where something similar in project.scm is 
useful: there was a discussion in case of git, if I remember correctly)

Notice that it would be a Maven core change (to track with a MNG Jira issue): 
we need to be extremely clear before changing core, because it will be harder 
to change in time (not a plugin version, that can be different in every project)

Notice that I understand the need to avoid copy/paste too: we're facing the 
exact same issue in Maven components since we introduced svnpubsub. The 
solution we found in Maven is:
1. introduce a maven.site.path property, that can contain references to 
artifactId property if needed, or fixed value if we don't want its value to 
change in child pom
2. copy/paste fixed url+project.distributionManagement.site.url value in every 
pom, with fixed value that references previous maven.site.path property (see 
[maven-site-plugin 
pom|http://svn.apache.org/viewvc/maven/plugins/tags/maven-site-plugin-3.3/pom.xml?revision=1480826view=markup#l185]
 for example)

I know it's not ideal, but for the moment, I didn't find any solution that 
would be general, only hack

  was (Author: hboutemy):
bq. 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?
not blind, it has been published yesterday (notice the LATEST in the link, the 
content varies in time)

bq. 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.
You make a difference between a value that's an effective URL and a value 
that's a variable, but Maven model-builder doesn't make such difference: it 
works at String-level, the fact that parent value contains ${} doesn't change 
the fact that the actual artifactId is added during inheritance assembly (and 
before model interpolation, ie replacement of ${} with actual value)

IIUC, we would require to be able to avoid default child urls calculation, 
consistently in project.url and project.distributionManagement.site.url, but 
probably not project.scm.[connection+developerConnection+url] (AFAIK, but 
perhaps someone will find a case where something similar in project.scm is 
useful: there was a discussion in case of git, if I remember correctly)

Notice that it would be a Maven core change (to track with a MNG Jira issue): 
we need to be extremely clear before changing core, because it will be harder 
to change in time (not a plugin version, that can be different in every project)

Notice that I understand the need to avoid copy/paste too: we're facing the 
exact same issue in Maven components since we introduced svnpubsub. The 
solution we found in Maven is:
1. introduce a maven.site.path property, that can contain references to 
artifactId property if needed, or fixed value if we don't want its value to 
change in child pom
2. copy/paste fixed url+project.distributionManagement.site.url value in every 
pom, with fixed value that references previous maven.site.path property

I know it's not ideal, but for the moment, I didn't find any solution that 
would be general, only hack

  
 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: Wish
  Components: site:deploy
Affects Versions: 3.0
 Environment: Debian Linux OpenJDK 7 mvn 3.0.4

[jira] [Closed] (MPOM-43) Prevent dependency with too recent bytecode from creeping in unnoticed


 [ 
https://issues.apache.org/jira/browse/MPOM-43?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hervé Boutemy closed MPOM-43.
-

   Resolution: Fixed
Fix Version/s: MAVEN-24
 Assignee: Hervé Boutemy

 Prevent dependency with too recent bytecode from creeping in unnoticed
 --

 Key: MPOM-43
 URL: https://issues.apache.org/jira/browse/MPOM-43
 Project: Maven POMs
  Issue Type: Improvement
  Components: maven
Affects Versions: MAVEN-23
Reporter: Hervé Boutemy
Assignee: Hervé Boutemy
 Fix For: MAVEN-24


 As a followup to 
 http://www.mail-archive.com/dev@maven.apache.org/msg96659.html here's a patch 
 that configures an additional enforcer rule to prevent using dependencies 
 that were compiled with a compiler more recent than the maximum allowed.
 see https://jira.codehaus.org/browse/MNG-5481

--
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] [Resolved] (MPOM-42) prepare svnpubsub documentation publication to /plugins-archives/artifactId-LATEST


 [ 
https://issues.apache.org/jira/browse/MPOM-42?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hervé Boutemy resolved MPOM-42.
---

Resolution: Fixed

 prepare svnpubsub documentation publication to 
 /plugins-archives/artifactId-LATEST
 

 Key: MPOM-42
 URL: https://issues.apache.org/jira/browse/MPOM-42
 Project: Maven POMs
  Issue Type: Improvement
  Components: maven-plugins
Affects Versions: MAVEN-PLUGINS-24
Reporter: Hervé Boutemy
Assignee: Hervé Boutemy
 Fix For: MAVEN-PLUGINS-25


 site staging for each plugin will simply be done with
   mvn -Preporting site-deploy
 if a svn commit issue happens, restarting svnpubsub publication:
   mvn scm-publish:publish-scm
 then release staging:
   svn cp 
 https://svn.apache.org/repos/infra/websites/production/maven/content/plugins-archives/[artifactId]-LATEST
  
 https://svn.apache.org/repos/infra/websites/production/maven/content/plugins-archives/[artifactId]-[version]
  -m 'staging [artifactId] [version] documentation'
 then final release documentation publication:
   svnmucc -U 
 https://svn.apache.org/repos/infra/websites/production/maven/content rm 
 plugins/[artifactId] cp HEAD plugins-archives/[artifactId]-[version] 
 plugins/[artifactId] -m 'publishing [artifactId] [version] documentation'

--
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] [Resolved] (MPOM-41) add run-its profile to release plugin execution


 [ 
https://issues.apache.org/jira/browse/MPOM-41?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hervé Boutemy resolved MPOM-41.
---

Resolution: Fixed

 add run-its profile to release plugin execution
 ---

 Key: MPOM-41
 URL: https://issues.apache.org/jira/browse/MPOM-41
 Project: Maven POMs
  Issue Type: Improvement
  Components: maven-plugins
Affects Versions: MAVEN-PLUGINS-24
Reporter: Hervé Boutemy
Assignee: Hervé Boutemy
 Fix For: MAVEN-PLUGINS-25


 actually, ITs are not run during release, then invoker report is empty (not 
 shown at all)
 I tested this configuration during maven-site-plugin 3.3, 
 maven-dependency-plugin 2.8 and maven-project-info-reports 2.7 releases with 
 success

--
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] [Closed] (MPOM-36) Declare maven-dependency-plugin in pluginManagement


 [ 
https://issues.apache.org/jira/browse/MPOM-36?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hervé Boutemy closed MPOM-36.
-

   Resolution: Fixed
Fix Version/s: ASF-14
 Assignee: Hervé Boutemy

done in r1484062

 Declare maven-dependency-plugin in pluginManagement
 ---

 Key: MPOM-36
 URL: https://issues.apache.org/jira/browse/MPOM-36
 Project: Maven POMs
  Issue Type: Improvement
  Components: asf
Affects Versions: ASF-10
Reporter: Stevo Slavic
Assignee: Hervé Boutemy
Priority: Minor
 Fix For: ASF-14

 Attachments: MPOM-36.patch


 [Apache v10 
 pom|http://repo1.maven.org/maven2/org/apache/apache/10/apache-10.pom] 
 declares common plugins and their versions in pluginManagement for 
 reproducibility, but not 
 [maven-dependency-plugin|http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-dependency-plugin/].

--
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] [Commented] (MPOM-10) Apache Parent POM 9 apache-release profile issues