[jira] Created: (MNG-4274) [regression] Plugins with an undeclared but transitive dependency on plexus-utils get wrong version of p-u
[regression] Plugins with an undeclared but transitive dependency on
plexus-utils get wrong version of p-u
--
Key: MNG-4274
URL: http://jira.codehaus.org/browse/MNG-4274
Project: Maven 2
Issue Type: Bug
Components: Class Loading, Plugins and Lifecycle
Affects Versions: 3.0-alpha-2
Reporter: Benjamin Bentmann
An excerpt from a plugin's dependency tree
{noformat}
[INFO] org.apache.maven.plugins:maven-resources-plugin:maven-plugin:2.2
[INFO] +- org.apache.maven:maven-plugin-api:jar:2.0:compile
[INFO] +- org.apache.maven:maven-project:jar:2.0:compile
[INFO] | +- org.codehaus.plexus:plexus-utils:jar:1.0.4:compile
{noformat}
Note that the plugin has an indirect dependency on plexus-utils:1.0.4 via
maven-project.
Maven 3 curently filters out core artifacts and their transitive dependencies
from the plugin realm. This removes plexus-utils from the plugin artifacts,
making the plugin use the plexus-utils version that ships with the core instead
of the one the plugin was compiled/tested with.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4162) Removal of all reporting logic from the core of Maven
[ http://jira.codehaus.org/browse/MNG-4162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185579#action_185579 ] Olivier Lamy commented on MNG-4162: --- branches started : - core : https://svn.apache.org/repos/asf/maven/components/branches/MNG-4162/ - site plugin : https://svn.apache.org/repos/asf/maven/plugins/branches/maven-site-plugin-3.x > Removal of all reporting logic from the core of Maven > - > > Key: MNG-4162 > URL: http://jira.codehaus.org/browse/MNG-4162 > Project: Maven 2 > Issue Type: Improvement >Reporter: Jason van Zyl > Fix For: 3.0 > > > Any reporting implementation will be implemented as a plugin. Maven will > provide any information, APIs, and extension points to make this possible. > But the conflation of building with reporting in the core makes it almost > impossible for anyone two understand the distinction, makes it impossible to > have alternate implementations and couple many tools like Doxia directly to > the core which is unacceptable for Maven 3.x. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-461) Support TFS as SCM Provider
[ http://jira.codehaus.org/browse/SCM-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185572#action_185572 ] Mark Struberg commented on SCM-461: --- short explanation: For the last 2 months we contacted a few developers from within Microsoft and also MVPs from well known 3rd party companies. It looks like TFS simply does not support any kind of 'initialising' to a certain point. The only way to get a specific state into TFS would be stopping the server, doing a SQLServer backup, restart TFS and run a few jobs to recalculate internal data. Another way would be to create a VMware running in snapshot mode (readonly) and restarting the VM for every TCK. All other options we discussed are even more unpracticable. So it looks pretty unrealistic that we will ever get TCKs running for TFS, instead we need to run all the tests manually with little projects. Subhash already did a lot of internal testing this way. For getting it even better, we'd have to make it usable for a lot of people easily. So I'd like to see it in our maven-scm SVN as early as possible. > Support TFS as SCM Provider > --- > > Key: SCM-461 > URL: http://jira.codehaus.org/browse/SCM-461 > Project: Maven SCM > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Subhash > Attachments: scm-461-maven-scm-provider-tfs.patch > > > Support for Microsoft TFS is being added to Maven by a new scm-provider: > maven-scm-provider-tfs. The attached patch file contains the changes made to > http://svn.apache.org/repos/asf/maven/scm/trunk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-461) Support TFS as SCM Provider
[ http://jira.codehaus.org/browse/SCM-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185569#action_185569 ] Olivier Lamy commented on SCM-461: -- No problem for me. Temporary this new provider can be incorporated in scm sandbox until you send your clas. > Support TFS as SCM Provider > --- > > Key: SCM-461 > URL: http://jira.codehaus.org/browse/SCM-461 > Project: Maven SCM > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Subhash > Attachments: scm-461-maven-scm-provider-tfs.patch > > > Support for Microsoft TFS is being added to Maven by a new scm-provider: > maven-scm-provider-tfs. The attached patch file contains the changes made to > http://svn.apache.org/repos/asf/maven/scm/trunk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SCM-461) Support TFS as SCM Provider
[ http://jira.codehaus.org/browse/SCM-461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185568#action_185568 ] Subhash commented on SCM-461: - We are unable to proceed with the TCK testcases as TFS does not support testing against a known fixture. We have incorporated important checks in the unit test cases (http://github.com/subhash/maven-scm-provider-tfs/commits/master). Please let us know if this suffices for the first version of the SCM provider > Support TFS as SCM Provider > --- > > Key: SCM-461 > URL: http://jira.codehaus.org/browse/SCM-461 > Project: Maven SCM > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Subhash > Attachments: scm-461-maven-scm-provider-tfs.patch > > > Support for Microsoft TFS is being added to Maven by a new scm-provider: > maven-scm-provider-tfs. The attached patch file contains the changes made to > http://svn.apache.org/repos/asf/maven/scm/trunk -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-420) Parent project site descriptor menu options always a link back to parent site
[ http://jira.codehaus.org/browse/MSITE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl updated MSITE-420: Attachment: MSITE-420.zip Try the attached test project. Run 'mvn site' in the parent, then check that the files in the child/target/site folder all have links relative to the child (the files are not actually there, but the links are correct). PS as I said above, the inheritAsRef attribute has no effect for menus that are no references > Parent project site descriptor menu options always a link back to parent site > - > > Key: MSITE-420 > URL: http://jira.codehaus.org/browse/MSITE-420 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: doxia integration, inheritance >Affects Versions: 2.0-beta-5, 2.0-beta-6, 2.0-beta-7, 2.0, 2.0.1 > Environment: Using maven 2.0.9 - and all versions of the site plugin > all the way back to 2.0-beta-5. >Reporter: EJ Ciramella > Attachments: MSITE-420.zip > > > I'd like to have a parent project define what items are in a given menu for > all child projects and let the child projects define the contents of those > links (this doesn't work). > In the documentation for the site plugin here: > http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html > There is a bit in there about how to get a parent project site descriptor to > be inherited by a child project by using the following: > > This is great if you want the child project to always link back to the parent > project's links/pages for each menu option. > Doxia however shows this is configurable: > http://maven.apache.org/doxia/doxia-sitetools-1.0.x/doxia-decoration-model/decoration.html#class_menu > inheritAsRef - If this is a reference, setting true means that it will be > populated in the project, whereas if it is false, it is populated in the > parent and then inherited. The default value is false. > This property currently doesn't work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-420) Parent project site descriptor menu options always a link back to parent site
[ http://jira.codehaus.org/browse/MSITE-420?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185563#action_185563 ] EJ Ciramella commented on MSITE-420: I don't understand what you mean by relative then. Here's my "parent" menu structure: When the child project picks up this site descriptor, all the links are pointing to the parent site. What am I missing? I tried prefixing things with "./" but that didn't help. > Parent project site descriptor menu options always a link back to parent site > - > > Key: MSITE-420 > URL: http://jira.codehaus.org/browse/MSITE-420 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: doxia integration, inheritance >Affects Versions: 2.0-beta-5, 2.0-beta-6, 2.0-beta-7, 2.0, 2.0.1 > Environment: Using maven 2.0.9 - and all versions of the site plugin > all the way back to 2.0-beta-5. >Reporter: EJ Ciramella > > I'd like to have a parent project define what items are in a given menu for > all child projects and let the child projects define the contents of those > links (this doesn't work). > In the documentation for the site plugin here: > http://maven.apache.org/plugins/maven-site-plugin/examples/sitedescriptor.html > There is a bit in there about how to get a parent project site descriptor to > be inherited by a child project by using the following: > > This is great if you want the child project to always link back to the parent > project's links/pages for each menu option. > Doxia however shows this is configurable: > http://maven.apache.org/doxia/doxia-sitetools-1.0.x/doxia-decoration-model/decoration.html#class_menu > inheritAsRef - If this is a reference, setting true means that it will be > populated in the project, whereas if it is false, it is populated in the > parent and then inherited. The default value is false. > This property currently doesn't work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4273) [regression] Internal utility classes of core leak into plugin realm
[regression] Internal utility classes of core leak into plugin realm
Key: MNG-4273
URL: http://jira.codehaus.org/browse/MNG-4273
Project: Maven 2
Issue Type: Bug
Components: Class Loading, Plugins and Lifecycle
Affects Versions: 3.0-alpha-2
Reporter: Benjamin Bentmann
The current class loader hierarchy of 3.x looks like:
- {{plexus.core}} as root realm with the contents of {{lib/*.jar}}
- {{plugin: g:a:v}} as child of {{plexus.core}}
This basically makes {{lib/*.jar}} completely available to the plugin realm,
including classes that we don't want/need to share with plugins because they
assist the implementation of the core but not the interop between core and
plugin.
The current design gives rise to errors like the linkage error reported in
[MNGECLIPSE-1487|https://issues.sonatype.org/browse/MNGECLIPSE-1487]:
- a plugin creates a custom URL class loader (with parent delegation) that
contains project dependencies, among others xercesImpl, on top of its plugin
realm
- the plugin sets the new class loader as TCCL and invokes a tool that wants to
employ a SAX parser
- the parser factory of the JRE will search the TCCL for a suitable SAX parser
and will discover xercesImpl in the TCCL
- loading of the xerces parser triggers loading of {{XML11Configuration}} from
the TCCL which inherits from {{ParserConfigurationSettings}}
- due to parent delegation, the {{ParserConfigurationSettings}} will however be
loaded from {{plexus.core}} which holds xercesMinimal
- xercesMinimal provides an incompatbile version of
{{ParserConfigurationSettings}}, which finally crashes the plugin with a
linkage error
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MGPG-9) gpg plugin hangs when it should prompt for the secret key passphrase hangs
[ http://jira.codehaus.org/browse/MGPG-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185560#action_185560 ] Christophe Lallement commented on MGPG-9: - I find a workaround: it seems that mvn:release fork the maven command and additionnal args are not passed to the new command. just add this option on commande line: > mvn -Dgpg.passphrase="xxx" -Darguments="-Dgpg.passphrase=x" > release:perform it works fine for me (same tips for mvn:perform) Regards Christophe > gpg plugin hangs when it should prompt for the secret key passphrase hangs > -- > > Key: MGPG-9 > URL: http://jira.codehaus.org/browse/MGPG-9 > Project: Maven 2.x GPG Plugin > Issue Type: Bug > Environment: Maven 2.0.6, JDK 1.5.0_11, Linux 2.6.x >Reporter: Alex Karasulu > > When used in conjunction with the release plugin the release:perform command > hangs when it should prompt for the secret key passphrase. Interestingly > enough when I put the passphrase into the settings.xml file the plugin does > not hang. I suspect the prompt is failing to show up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MGPG-9) gpg plugin hangs when it should prompt for the secret key passphrase hangs
[ http://jira.codehaus.org/browse/MGPG-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=185559#action_185559 ] Christophe Lallement commented on MGPG-9: - Hi, it's the same thing with mvn:prepare (passprase pass as property) but it seems gpg wait for a pass phrase without prompting. tested with maven 2.2.0. > gpg plugin hangs when it should prompt for the secret key passphrase hangs > -- > > Key: MGPG-9 > URL: http://jira.codehaus.org/browse/MGPG-9 > Project: Maven 2.x GPG Plugin > Issue Type: Bug > Environment: Maven 2.0.6, JDK 1.5.0_11, Linux 2.6.x >Reporter: Alex Karasulu > > When used in conjunction with the release plugin the release:perform command > hangs when it should prompt for the secret key passphrase. Interestingly > enough when I put the passphrase into the settings.xml file the plugin does > not hang. I suspect the prompt is failing to show up. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4272) Error found in code: wrong order of parameters in createRepository for repo in a profile in settings.xml
[ http://jira.codehaus.org/browse/MNG-4272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4272. -- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 3.0-alpha-3 > Error found in code: wrong order of parameters in createRepository for repo > in a profile in settings.xml > > > Key: MNG-4272 > URL: http://jira.codehaus.org/browse/MNG-4272 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 3.0-alpha-2 > Environment: n/a, I've found the bug inside the maven source code >Reporter: Marcel Schutte >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-3 > > > I've spotted an error at line 245in the following method invocation: > class DefaultMavenExecutionRequestPopulator > private void processSettings( MavenExecutionRequest request, Configuration > configuration ) > ... > ArtifactRepository ar = mavenTools.createRepository( *r.getId(), r.getUrl()*, > snapshots, releases ); > The order of *id* and *url* should be reversed: > interface MavenTools > ArtifactRepository createRepository( *String url, String repositoryId*, > ArtifactRepositoryPolicy snapshotsPolicy, ArtifactRepositoryPolicy > releasesPolicy ); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4272) Error found in code: wrong order of parameters in createRepository for repo in a profile in settings.xml
Error found in code: wrong order of parameters in createRepository for repo in a profile in settings.xml Key: MNG-4272 URL: http://jira.codehaus.org/browse/MNG-4272 Project: Maven 2 Issue Type: Bug Components: Embedding Affects Versions: 3.0-alpha-2 Environment: n/a, I've found the bug inside the maven source code Reporter: Marcel Schutte I've spotted an error at line 245in the following method invocation: class DefaultMavenExecutionRequestPopulator private void processSettings( MavenExecutionRequest request, Configuration configuration ) ... ArtifactRepository ar = mavenTools.createRepository( *r.getId(), r.getUrl()*, snapshots, releases ); The order of *id* and *url* should be reversed: interface MavenTools ArtifactRepository createRepository( *String url, String repositoryId*, ArtifactRepositoryPolicy snapshotsPolicy, ArtifactRepositoryPolicy releasesPolicy ); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRESOURCES-98) Set default encoding to UTF-8
Set default encoding to UTF-8 - Key: MRESOURCES-98 URL: http://jira.codehaus.org/browse/MRESOURCES-98 Project: Maven 2.x Resources Plugin Issue Type: Improvement Reporter: James William Dumay Priority: Critical As a best practice it might be wise to set the default encoding of the plugin to UTF-8 so that builds are not platform dependent out of the box. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-396) Site Deployment with scpexe fails because of chmod exit code
[ http://jira.codehaus.org/browse/MSITE-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-396. --- Assignee: Lukas Theussl Resolution: Fixed Fix Version/s: 2.1 The chmod command is now optional and configurable, see MSITE-141. > Site Deployment with scpexe fails because of chmod exit code > > > Key: MSITE-396 > URL: http://jira.codehaus.org/browse/MSITE-396 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0 > Environment: Linux >Reporter: Klaus Reimer >Assignee: Lukas Theussl > Fix For: 2.1 > > Attachments: error.txt > > > When deploying a site via scpexe protocol then Maven executes this command > after uploading the files: > chmod -Rf g+w,a+rX /somepath > The target directory on the server does not belong to the user uploading the > files. The user has write permissions, but he is not the owner. And this > means that chmod fails. It displays no error message because of the -f > parameter but it returns an exit code 1 which is processed by Maven. The > result is the attached error message. > When I change the owner of the target directory then it works but we can't do > this because we have multiple SSH users uploading the files. The permissions > are already correct on the server (They are handled by ACLs) so there is no > need to call chmod at all. So I suggest to let the user configure if chmod is > executed at all or to ignore the return value of chmod (If you already use -f > to hide error messages then you are most likely not interested in errors so > also ignoring the error code smells fine) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-245) parent filesystem site.xml is never be found
[
http://jira.codehaus.org/browse/MSITE-245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lukas Theussl closed MSITE-245.
---
Assignee: Lukas Theussl (was: John Casey)
Resolution: Fixed
Fix Version/s: (was: 2.1)
I believe this has been fixed with MSHARED-18.
> parent filesystem site.xml is never be found
>
>
> Key: MSITE-245
> URL: http://jira.codehaus.org/browse/MSITE-245
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Affects Versions: 2.0-beta-5
> Environment: 2.0.7
>Reporter: John Allen
>Assignee: Lukas Theussl
>Priority: Blocker
> Attachments: site-patch.txt
>
>
> The current approach used by the getSiteDescriptorFile(File, Locale) is wrong
> as the basedir passed in to it is not just the project's own basedir, it's
> potentially a parent project's basedir and thus the previous code makes no
> sense as we would need to add on the parent's site.xml site directory and
> then try and find the relative path to it and as there's no way (that I know
> of) of a) finding that out from the parent project's object model (even if we
> passed it in) and b) the current code does not append anything to the passed
> in basedir so is always looking for a site.xml in the parents root directory.
> What's more the use of a relative path here is pointless too as we simply
> read in the descriptor file, not persist it into links where relativePaths
> are useful.
> Current code:
> {code}
> protected File getSiteDescriptorFile( File basedir, Locale locale )
> {
>String relativePath = getRelativePath(
> siteDirectory.getAbsolutePath(), basedir.getAbsolutePath() );
> File siteDescriptor = new File( relativePath, "site_" +
> locale.getLanguage() + ".xml" );
> if ( !siteDescriptor.exists() )
> {
> siteDescriptor = new File( relativePath, "site.xml" );
> }
> return siteDescriptor;
> }
> {code}
> Fixed code
> {code}
> protected File getSiteDescriptorFile( File basedir, Locale locale )
> {
> String sitePath;
>
> if ( basedir.equals( project.getBasedir() ))
> {
> // it's this project's basedir so use our siteDirectory (allows
> this project
> // to use a custom site location)
>
> sitePath = siteDirectory.getAbsolutePath();
> }
> else
> {
> // it's not this project's basedir so it must be one of our
> parent's,
> // so we'll just have to assume they store their site.xml in the
> // standard location (src/site)
>
> sitePath = basedir.getAbsolutePath() + "/src/site";
> }
>
> File siteDescriptor = new File( sitePath, "site_" +
> locale.getLanguage() + ".xml" );
> if ( !siteDescriptor.exists() )
> {
> siteDescriptor = new File( sitePath, "site.xml" );
> }
> return siteDescriptor;
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MSITE-373) NPE when running site on a module with 3 level of parents
[ http://jira.codehaus.org/browse/MSITE-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MSITE-373. --- Assignee: Lukas Theussl Resolution: Fixed This seems fixed in 2.0.1, I cannot reproduce it anymore. I do get an NPE with 2.0-beta-7 too, but a different one. Please reopen with a specific test project if you still have problems. > NPE when running site on a module with 3 level of parents > - > > Key: MSITE-373 > URL: http://jira.codehaus.org/browse/MSITE-373 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: inheritance, multi module, site:run >Affects Versions: 2.0-beta-7 >Reporter: Bruno Bieth >Assignee: Lukas Theussl > > I've got 3 levels of parents : > ProjectX-Module1 ==> ProjectX ==> Common-Scala-Pom ==> Common-Pom > Common-Scala-Pom and Common-Pom are in my repository. > Running mvn site:run on the module causes : > Caused by: java.lang.NullPointerException > at > org.apache.maven.project.DefaultMavenProjectBuilder.normalizeToArtifactRepositories(DefaultMavenProjectBuilder.java:615) > at > org.apache.maven.project.DefaultMavenProjectBuilder.findModelFromRepository(DefaultMavenProjectBuilder.java:533) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:249) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:262) > at > org.apache.maven.doxia.tools.DefaultSiteTool.getParentProject(DefaultSiteTool.java:750) > at > org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1201) > at > org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1205) > at > org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:1205) > at > org.apache.maven.doxia.tools.DefaultSiteTool.getDecorationModel(DefaultSiteTool.java:511) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo.java:226) > at > org.apache.maven.plugins.site.SiteRunMojo.createWebApplication(SiteRunMojo.java:177) > I've been a bit through the code and at some point the MavenProject returns > null when asked for getRemoteArtifactRepositories() ... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
