[jira] Commented: (MSITE-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165410#action_165410
]
Per Lindfors commented on MSITE-129:
??The structure you have drawn as 'what it should be' is stating that the
submodules inherit from myproj, which they dont. And thats why in the generated
site they dont live under it.??
bq. Yes I know. What I'm trying to say is that it would be nice if the
site-plugin could handle the modules of myproj the same way it does when the
modules inherit from myproj.
??You did deploy the projects to check that the module links were woerking
didnt you? They will never work in an undeployed state.??
bq. Yes.
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Dennis Lundberg
>Priority: Minor
> Fix For: 2.0
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
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-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165421#action_165421
]
John Allen commented on MSITE-129:
--
module != child
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Dennis Lundberg
>Priority: Minor
> Fix For: 2.0
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRELEASE-413) Branch goal should not insert version information for child modules which do not already have it
Branch goal should not insert version information for child modules which do not already have it Key: MRELEASE-413 URL: http://jira.codehaus.org/browse/MRELEASE-413 Project: Maven 2.x Release Plugin Issue Type: Bug Components: branch Affects Versions: 2.0-beta-8 Environment: windows Reporter: Andrius Kurtinaitis Attachments: pavyzdys.zip When performing a release:branch on a project which have several child modules, the branch plugin updates versions in the parent and also all child pom.xml files. Even in those files having no information, i.e. those inheriting the version from the parent. IMO branch plugin should leave those pom.xml files versionless and only change those pom.xml files that have their own version. I attach one such multimodule project. You will have to edit the scm and deployment info to try it. What is the preferred form of test cases for plugin issues? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-413) Branch goal should not insert version information for child modules which do not already have it
[ http://jira.codehaus.org/browse/MRELEASE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165441#action_165441 ] Andrius Kurtinaitis commented on MRELEASE-413: -- I looked at the code and found that in fact it leaves the children versionless if you give them the same versions as the parent when asked. Anyway I think it is annoying to type the same version many times ant try not to make any typo... > Branch goal should not insert version information for child modules which do > not already have it > > > Key: MRELEASE-413 > URL: http://jira.codehaus.org/browse/MRELEASE-413 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Components: branch >Affects Versions: 2.0-beta-8 > Environment: windows >Reporter: Andrius Kurtinaitis > Attachments: pavyzdys.zip > > > When performing a release:branch on a project which have several child > modules, the branch plugin updates versions in the parent and also all child > pom.xml files. > Even in those files having no information, i.e. those inheriting > the version from the parent. > IMO branch plugin should leave those pom.xml files versionless and only > change those pom.xml files that have their own version. > I attach one such multimodule project. You will have to edit the scm and > deployment info to try it. > What is the preferred form of test cases for plugin issues? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MASSEMBLY-360) When using mulitple Spring dependencies, the files from META-INF (from the Spring jars) overwrite each other in an executable jar-with-dependencies.
[
http://jira.codehaus.org/browse/MASSEMBLY-360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165459#action_165459
]
Renan Huanca commented on MASSEMBLY-360:
I have the same problem this is the code i used:
ApplicationContext pathXmlApplicationContext = new
ClassPathXmlApplicationContext("applicationContext.xml");
I build a jar using the maven assembly plugin.
When I try to execute de jar i get the following error:
BeanDefinitionParsingException: Configuration problem: Unable to locate Spring
NamespaceHandler for XML schema namespace
[http://www.springframework.org/schema/context]
I hope too, that is bug can be solved.
Best regards.
> When using mulitple Spring dependencies, the files from META-INF (from the
> Spring jars) overwrite each other in an executable jar-with-dependencies.
>
>
> Key: MASSEMBLY-360
> URL: http://jira.codehaus.org/browse/MASSEMBLY-360
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-2
> Environment: Windows XP, Java 5
>Reporter: Marielle Enderman
>
> I'm working on a Java 5 project with maven 2 and I need to deliver an
> executable jar file. In this project I'm using different Spring dependencies:
>
>org.springframework
> spring-beans
> 2.5.5
>
>
> org.springframework
> spring-context
> 2.5.5
>
> For maven packaging I'm using the maven-assembly plugin to create an
> executable jar with dependencies (using the jar-with-dependencies
> descriptor). Everything works fine, except that Spring's XSD files can't be
> found. At least: not all of them. The fact is: Every Spring JAR file contains
> a META-INF directory with files like spring.handlers and spring.schemas which
> contain list of locations of respectively namespace handlers and schemas.
> Unfortunately these files aren't merged during packaging so the META_INF of
> the executable JAR file only contains the last one added.
> This can result in errors like this:
> Example 1: The spring-context-2.5.xsd can't be found:
> WARN org.springframework.beans.factory.xml.XmlBeanDefinitionReader - Ignored
> XML validation warning org.xml.sax.SAXParseException: schema_reference.4:
> Failed to read schema document
> 'http://www.springframework.org/schema/context/spring-context-2.5.xsd',
> because 1) could not find the document; 2) the document could not be read; 3)
> the root element of the document is not .
> Example 2: The NamespaceHandler for the spring context namespace can't be
> located:
> Exception in thread "main"
> org.springframework.beans.factory.parsing.BeanDefinitionParsingException:
> Configuration problem: Unable to locate Spring NamespaceHandler for XML
> schema namespace [http://www.springframework.org/schema/context]
> When I manually merge the files, the executable JAR file works fine.
> I hope this problem can be solved.
--
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: (MEJB-28) outputDirectory is not created before packaging
[
http://jira.codehaus.org/browse/MEJB-28?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165468#action_165468
]
Dennis Lundberg commented on MEJB-28:
-
I had a look at this and I get the following error message:
{noformat}
Error assembling EJB: META-INF/ejb-jar.xml is required for ejbVersion 2.x
{noformat}
Here's the configuration snippet I used:
{code:xml}
org.apache.maven.plugins
maven-ejb-plugin
2.1
${project.build.directory}/jar
{code}
The reason for the error is that the EJB Plugin searches for resources (in this
case the exb-jar.xml) in . But the file is not there. It is in
the outputDirectory specified for the Resources Plugin. This needs to be
rewritten in order to fix this issue.
> outputDirectory is not created before packaging
> ---
>
> Key: MEJB-28
> URL: http://jira.codehaus.org/browse/MEJB-28
> Project: Maven 2.x Ejb Plugin
> Issue Type: Bug
>Affects Versions: 2.0
>Reporter: Ron Piterman
>Priority: Minor
>
> When using the jar plugin, outputDirectory is being cerated prior to creating
> the jar.
> The ejb plugin however fails if specifying an outputDirectory which does not
> exist -
> So, specifying something like ${project.build.directory}/jar will always fail
> after a clean.
--
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-3631) Introduce new MavenEmbedder.getPluginConfiguration method
[ http://jira.codehaus.org/browse/MNG-3631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165480#action_165480 ] Shane Isbell commented on MNG-3631: --- I have this checked into trunk. Once verified that it works as expected, I'll close out this issue. > Introduce new MavenEmbedder.getPluginConfiguration method > - > > Key: MNG-3631 > URL: http://jira.codehaus.org/browse/MNG-3631 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Igor Fedorenko >Assignee: Shane Isbell > Fix For: 3.0-alpha-3 > > > There are five sources for maven plugin configuration -- build/plugins, > parent build/plugins, build/pluginManagement, parent build/pluginManagement > and plugin default configuration. Currently, > MavenEmbedder.readProjectWithDependencies never considers default plugin > configuration. Also, lifecycle-included plugins and configuration are not > considered during readProjectWithDependencies (see MNGECLIPSE-627). > It would be nice to have new method MavenEmbedder.getPluginConfiguration( > MavenProject project, String pluginKey ): PlexusConfiguration (or similar) > which would calculate and return fully inherited/interpolated plugin > configuration. -- 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-129) modules list empty if modules don't use this project as parent in reactor build
[
http://jira.codehaus.org/browse/MSITE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165489#action_165489
]
Per Lindfors commented on MSITE-129:
now I got it!
??When a project deploys itself into the URL space, it uses its distro.site.url
to work out where it should go.??
By defining the distribution url for each module and the multimodule project I
got the correct directory layout for the deployed site with correct limks to
the modules.
Thanx!
> modules list empty if modules don't use this project as parent in reactor
> build
> ---
>
> Key: MSITE-129
> URL: http://jira.codehaus.org/browse/MSITE-129
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: multi module
>Affects Versions: 2.0-beta-5
>Reporter: Kenney Westerhof
>Assignee: Dennis Lundberg
>Priority: Minor
> Fix For: 2.0
>
>
> The code in the AbstractSiteRenderingMojo does the following:
> - if it's running in a reactor build (i.e. more than 1 project in the reactor
> projects) it scans all
> projects to see if it's parent project equals the current project. If so,
> it's marked as a module.
> - if it's running on a single project, the project.build.modules is consulted
> and those modules
> are marked as modules.
> I've got a 'fake' root pom, for utility purposes: it lists all projects as
> modules so that I can easily
> built everything and generate a site. However, this fake root pom is never
> used as a parent - there's
> a /pom/pom.xml project for that.
> The result of this is that the modules list is empty.
> A workaround is to first run 'mvn site' and then 'mvn site -N'.
> I'm not sure what the correct solution should be - basically now 2 site
> layouts are implemented:
> - a physical layout where the modules match the section of the pom,
> reflecting filesystem layout,
> - a project hierarchy layout based on
> and one or the other is used depending on wheter the build contains more than
> 1 project or not.
> My first feeling is that since the tag is called ${modules} (or ref="modules"/>) that
> the site should use the , not the .
> It should also take into consideration, that IF a reactor build is running,
> it should only use the modules that are also
> in the reactor (so you can use -r -Dmaven.reactor.excludes=.. to generate a
> site with not all projects in it).
> Thoughts?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4033) Introduce password encryption to the trunk
[ http://jira.codehaus.org/browse/MNG-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-4033: --- Description: Removing "2.1" from summary description since it is a 3.0 feature. Summary: Introduce password encryption to the trunk (was: Introduce 2.1.x password encryption to the trunk) > Introduce password encryption to the trunk > -- > > Key: MNG-4033 > URL: http://jira.codehaus.org/browse/MNG-4033 > Project: Maven 2 > Issue Type: New Feature > Components: Settings >Affects Versions: 3.0-alpha-2 >Reporter: Oleg Gusakov >Assignee: Oleg Gusakov > Fix For: 3.0-alpha-3 > > > Removing "2.1" from summary description since it is a 3.0 feature. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4033) Introduce password encryption to the trunk
[ http://jira.codehaus.org/browse/MNG-4033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Paul Benedict updated MNG-4033: --- Description: (was: Removing "2.1" from summary description since it is a 3.0 feature.) Removing "2.1" from summary description since it is a 3.0 feature. > Introduce password encryption to the trunk > -- > > Key: MNG-4033 > URL: http://jira.codehaus.org/browse/MNG-4033 > Project: Maven 2 > Issue Type: New Feature > Components: Settings >Affects Versions: 3.0-alpha-2 >Reporter: Oleg Gusakov >Assignee: Oleg Gusakov > Fix For: 3.0-alpha-3 > > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2323) Upload of FDS-API 1.04
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165499#action_165499 ] Rémy Sanlaville commented on MAVENUPLOAD-2323: -- It works now ! Thanks > Upload of FDS-API 1.04 > -- > > Key: MAVENUPLOAD-2323 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2323 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Edouard Hue >Assignee: Carlos Sanchez > Attachments: fdsapi-1.0.4-bundle.jar, fdsapi-1.0.4-bundle.jar > > > This is not a Maven project. The author (Steve Souza) isn't currently > intersted in migrating fdsapi to Maven. This bundle was generated from the > 1_04 release available at > http://sourceforge.net/project/showfiles.php?group_id=87044&package_id=90549&release_id=317647 > using the repository plugin. > Thanks for uploading ! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2334) Upload beansbinding-1.2.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2334?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2334. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload beansbinding-1.2.1 > - > > Key: MAVENUPLOAD-2334 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2334 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Alexandre Navarro >Assignee: Carlos Sanchez > Attachments: beansbinding-1.2.1-bundle.jar, > beansbinding-1.2.1-bundle.jar > > > Thanks to upload beansbinding. > Alexandre Navarro, Brian Beck and Shannon Hickey -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2354) Synchronize templateIt repository with repo1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165510#action_165510 ] Carlos Sanchez commented on MAVENUPLOAD-2354: - you have both in the repo http://templateit.sourceforge.net/m2repo/org/templateit/ > Synchronize templateIt repository with repo1 > > > Key: MAVENUPLOAD-2354 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2354 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Dmitriy Kumshayev >Assignee: Carlos Sanchez > > "org.templateit","mavens...@web.sourceforge.net:/home/groups/t/te/templateit/htdocs/m2repo","rsync_ssh","Dmitriy > Kumshayev","d...@mail.com",, > Proof of Domain Ownership: > http://www.networksolutions.com/whois-search/templateit.org -- 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: (MERCURY-95) embedd password encryption into mercury-ant
embedd password encryption into mercury-ant --- Key: MERCURY-95 URL: http://jira.codehaus.org/browse/MERCURY-95 Project: Mercury Issue Type: New Feature Components: Ant tasks Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov port password decryption from maven 3.0 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: (MERCURY-95) embedd password encryption into mercury-ant
[ http://jira.codehaus.org/browse/MERCURY-95?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-95: Fix Version/s: 1.0-alpha-6 > embedd password encryption into mercury-ant > --- > > Key: MERCURY-95 > URL: http://jira.codehaus.org/browse/MERCURY-95 > Project: Mercury > Issue Type: New Feature > Components: Ant tasks >Affects Versions: 1.0-alpha-5 >Reporter: Oleg Gusakov >Assignee: Oleg Gusakov > Fix For: 1.0-alpha-6 > > > port password decryption from maven 3.0 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: (MAVENUPLOAD-2354) Synchronize templateIt repository with repo1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165519#action_165519 ] Dmitriy Kumshayev commented on MAVENUPLOAD-2354: I temporarily created both. I will remove the NOT capitalized one. > Synchronize templateIt repository with repo1 > > > Key: MAVENUPLOAD-2354 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2354 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Dmitriy Kumshayev >Assignee: Carlos Sanchez > > "org.templateit","mavens...@web.sourceforge.net:/home/groups/t/te/templateit/htdocs/m2repo","rsync_ssh","Dmitriy > Kumshayev","d...@mail.com",, > Proof of Domain Ownership: > http://www.networksolutions.com/whois-search/templateit.org -- 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: (MCOMPILER-91) source and output directories should be configurable
[ http://jira.codehaus.org/browse/MCOMPILER-91?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Janes updated MCOMPILER-91: - Attachment: maven-compiler-plugin.patch I have a similar need for test trees (separating strict unit tests from project-level integration tests). The attached patch changes the existing compileSourceRoots and outputDirectory parameters from read-only to read-write, so that you can configure them on a per-execution basis, e.g.: maven-compiler-plugin it pre-integration-test testCompile src/it/java target/it-classes You could probably apply a similar patch to CompilerMojo.java. There are no new phases required, and maven-surefire-plugin can already be configured to use different source/class/output directories, which means this could also be applied to [integration tests|http://docs.codehaus.org/display/MAVEN/best+practices+-+testing+strategies] without modifying either plugin. > source and output directories should be configurable > > > Key: MCOMPILER-91 > URL: http://jira.codehaus.org/browse/MCOMPILER-91 > Project: Maven 2.x Compiler Plugin > Issue Type: New Feature >Reporter: Paul Gier > Attachments: maven-compiler-plugin.patch > > > I have a project with two test source trees. These sources are kept separate > from each other because they need to be compiled and processed with different > parameters. > Currently there is no way in maven to have two separate source trees for the > tests other than using a profile. > It should be possible to configure the source and output directories in the > plugin so that each source tree can be compiled with different parameters. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2354) Synchronize templateIt repository with repo1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165525#action_165525 ] Carlos Sanchez commented on MAVENUPLOAD-2354: - 99.9% of the groups (if not all) are not capitalized. You are aware how confusing is going to be for the users, right? > Synchronize templateIt repository with repo1 > > > Key: MAVENUPLOAD-2354 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2354 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Dmitriy Kumshayev >Assignee: Carlos Sanchez > > "org.templateit","mavens...@web.sourceforge.net:/home/groups/t/te/templateit/htdocs/m2repo","rsync_ssh","Dmitriy > Kumshayev","d...@mail.com",, > Proof of Domain Ownership: > http://www.networksolutions.com/whois-search/templateit.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-2354) Synchronize templateIt repository with repo1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165527#action_165527 ] Dmitriy Kumshayev commented on MAVENUPLOAD-2354: If this is the case, let us leave it not capitalized. I will put appropriate artifact to my repo (I have already removed it) Thanks > Synchronize templateIt repository with repo1 > > > Key: MAVENUPLOAD-2354 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2354 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Dmitriy Kumshayev >Assignee: Carlos Sanchez > > "org.templateit","mavens...@web.sourceforge.net:/home/groups/t/te/templateit/htdocs/m2repo","rsync_ssh","Dmitriy > Kumshayev","d...@mail.com",, > Proof of Domain Ownership: > http://www.networksolutions.com/whois-search/templateit.org -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-413) Ctrl-C during tests won't kill forked subprocesses
[ http://jira.codehaus.org/browse/SUREFIRE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165528#action_165528 ] Peter Janes commented on SUREFIRE-413: -- The same thing happens if the test times out. > Ctrl-C during tests won't kill forked subprocesses > -- > > Key: SUREFIRE-413 > URL: http://jira.codehaus.org/browse/SUREFIRE-413 > Project: Maven Surefire > Issue Type: Bug > Components: process forking > Environment: Windows XP >Reporter: Dan Fabulich > Fix For: 2.x > > > Run a test that forks a subprocess, then press Ctrl-C. The forked grandchild > process won't die. > We should use killableprocess to gracefully kill the entire process tree on > Windows > http://darkforge.blogspot.com/2007/09/windows-killableprocess-and-case-of.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-413) Ctrl-C during tests won't kill forked subprocesses
[ http://jira.codehaus.org/browse/SUREFIRE-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165528#action_165528 ] Peter Janes edited comment on SUREFIRE-413 at 2/13/09 1:42 PM: --- The same thing happens if the test times out (in Linux at least). was (Author: peterj): The same thing happens if the test times out. > Ctrl-C during tests won't kill forked subprocesses > -- > > Key: SUREFIRE-413 > URL: http://jira.codehaus.org/browse/SUREFIRE-413 > Project: Maven Surefire > Issue Type: Bug > Components: process forking > Environment: Windows XP >Reporter: Dan Fabulich > Fix For: 2.x > > > Run a test that forks a subprocess, then press Ctrl-C. The forked grandchild > process won't die. > We should use killableprocess to gracefully kill the entire process tree on > Windows > http://darkforge.blogspot.com/2007/09/windows-killableprocess-and-case-of.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2354) Synchronize templateIt repository with repo1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-2354. --- Resolution: Fixed > Synchronize templateIt repository with repo1 > > > Key: MAVENUPLOAD-2354 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2354 > Project: Maven Upload Requests > Issue Type: Wish >Reporter: Dmitriy Kumshayev >Assignee: Carlos Sanchez > > "org.templateit","mavens...@web.sourceforge.net:/home/groups/t/te/templateit/htdocs/m2repo","rsync_ssh","Dmitriy > Kumshayev","d...@mail.com",, > Proof of Domain Ownership: > http://www.networksolutions.com/whois-search/templateit.org -- 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-3018) pluginManagement configurations are not honoured when plugin is silently included
[ http://jira.codehaus.org/browse/MNG-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165542#action_165542 ] Benjamin Bentmann commented on MNG-3018: This issue resembles MNG-522. The corresponding core IT passes with alpha-1, alpha-2 and trunk. So, if the Maven CLI uses the same code path as the embedder, this should be fixed. > pluginManagement configurations are not honoured when plugin is silently > included > - > > Key: MNG-3018 > URL: http://jira.codehaus.org/browse/MNG-3018 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 3.0-alpha-1 >Reporter: Michael Semb Wever > Fix For: 3.0-alpha-4 > > > Read http://jira.codehaus.org/browse/MEVENIDE-532 > In my top parent pom.xml i've define the maven-compiler-plugin configuration > like: > > > > > maven-compiler-plugin > > 1.5 > 1.5 > UTF-8 > > ... > since not all my subprojects require the plugin, and when they do they > silently include the plugin, it makes more sense to define it within the > tag. > But when i use mevenide-netbeans all my projects are marked uncompilable > since the maven embedder does not report the above defined configuration for > the maven-compiler-plugin. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MASSEMBLY-386) Creation of tar.gz fails with "java.io.IOException: Corrupt GZIP trailer"
[
http://jira.codehaus.org/browse/MASSEMBLY-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Thomas Dudziak closed MASSEMBLY-386.
Resolution: Not A Bug
In turned out that the tar.gz that the assembly depended upon, was in fact
broken in one repo.
> Creation of tar.gz fails with "java.io.IOException: Corrupt GZIP trailer"
> -
>
> Key: MASSEMBLY-386
> URL: http://jira.codehaus.org/browse/MASSEMBLY-386
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.2-beta-3
> Environment: mvn -version:
> Maven version: 2.0.9
> Java version: 1.6.0_10
> OS name: "linux" version: "2.6.27-9-generic" arch: "amd64" Family: "unix"
> OS is Ubuntu 8.10 Intrepid 64bit.
> java -version:
> java version "1.6.0_10"
> Java(TM) SE Runtime Environment (build 1.6.0_10-b33)
> Java HotSpot(TM) 64-Bit Server VM (build 11.0-b15, mixed mode)
>Reporter: Thomas Dudziak
>Priority: Critical
>
> For a build of mine
> [INFO] [assembly:single {execution: assemble}]
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] null
> Corrupt GZIP trailer
> [INFO]
>
> [DEBUG] Trace
> java.lang.reflect.UndeclaredThrowableException
> at
> org.codehaus.plexus.archiver.tar.TarFile$1.hasMoreElements(TarFile.java:75)
> at
> org.codehaus.plexus.archiver.tar.PlexusIoTarFileResourceCollection$1.hasNext(PlexusIoTarFileResourceCollection.java:34)
> at
> org.codehaus.plexus.components.io.resources.AbstractPlexusIoArchiveResourceCollection.getResources(AbstractPlexusIoArchiveResourceCollection.java:58)
> at
> org.codehaus.plexus.components.io.resources.PlexusIoProxyResourceCollection.getResources(PlexusIoProxyResourceCollection.java:67)
> at
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:362)
> at
> org.codehaus.plexus.archiver.AbstractArchiver$1.hasNext(AbstractArchiver.java:392)
> at
> org.apache.maven.plugin.assembly.filter.ComponentsXmlArchiverFileFilter.finalizeArchiveCreation(ComponentsXmlArchiverFileFilter.java:166)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.runArchiveFinalizers(AbstractArchiver.java:760)
> at
> org.codehaus.plexus.archiver.AbstractArchiver.createArchive(AbstractArchiver.java:784)
> at
> org.apache.maven.plugin.assembly.archive.archiver.AssemblyProxyArchiver.createArchive(AssemblyProxyArchiver.java:496)
> at
> org.apache.maven.plugin.assembly.archive.DefaultAssemblyArchiver.createArchive(DefaultAssemblyArchiver.java:190)
> at
> org.apache.maven.plugin.assembly.mojos.AbstractAssemblyMojo.execute(AbstractAssemblyMojo.java:354)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:478)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:597)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: java.io.IOException: Corrupt GZIP trailer
> at java.util.zip.GZIPInputStream.readTrailer(GZIPInputStream.java:182)
> at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:94)
> at
> org.codehaus.plexus.archive
[jira] Commented: (MINVOKER-77) Add a invoker report mojo which display invoker its result
[ http://jira.codehaus.org/browse/MINVOKER-77?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165547#action_165547 ] Olivier Lamy commented on MINVOKER-77: -- work started in rev 744276. Don't close the issue now as I'd like to review some trouble with failed its which are not marked as failed in the report. > Add a invoker report mojo which display invoker its result > --- > > Key: MINVOKER-77 > URL: http://jira.codehaus.org/browse/MINVOKER-77 > Project: Maven 2.x Invoker Plugin > Issue Type: New Feature >Reporter: Olivier Lamy >Assignee: Olivier Lamy > Fix For: 1.4 > > > The result will displayed by parsing the result generated with new feature > from MINVOKER-76 -- 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-307) Site generation broken with multi-module property inheritence
[
http://jira.codehaus.org/browse/MSITE-307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=165560#action_165560
]
Hamid Ben Malek commented on MSITE-307:
---
There are many problems with the site plugin:
1) The first issue is that it tries to build the whole project again (and even
many times because some reports need to do the buid again). This is a very bad
thing. Even if you run mvn package first, and then run the site generation, the
build process repeats all over again which takes long time for big and complex
projects consisting of multi-modules. This needs to be fixed: if the project is
already built, none of the reports and site plugin should attempt to build
again.
2) The second issue is that the sites generated in the sub-modules are not
copied to the top level (the parent site). The consequence of this is that when
you click on a sub-module link on the left navigation of the parent site, you
get an empty page (does not take you to the site of the sub-module). And this
happens whether you have run mvn site or mvn site:stage or mvn site:deploy (the
various sites of the sub-modules are never aggregated together with the top
level site to form a complete one site). This needs to be fixed. I blieve the
the designers of this plugin thought that the sub-modules projects may not be
on the same server as the parent project and therefore it would not make sense
to copy the sites of the submodules to the parent, but this is a very lame
execuse. It is very inappropriate for a developer to manually copy the sites of
the submodules to the top level before distributing the final whole and
complete site.
> Site generation broken with multi-module property inheritence
> -
>
> Key: MSITE-307
> URL: http://jira.codehaus.org/browse/MSITE-307
> Project: Maven 2.x Site Plugin
> Issue Type: Bug
> Components: inheritance
>Affects Versions: 2.0-beta-6
> Environment: Ubuntu 7.10, Maven 2.0.8
>Reporter: Eric Ryan
> Attachments: module_project.zip, mvn_output.txt
>
>
> Maven2 site plugin inheritence
> I have a multi-module project with the following directory structure:
> my-app
> |
> |---my-client-ui
> | |
> | |---pom.xml
> |
> |---my-core
> | |
> | |---pom.xml
> |
> |---my-common
> | |
> | |---pom.xml
> |
> |---pom.xml
> I define properties such as ${myVersion}, ${myArtifactId}, ${myGroupId} in
> the parent pom. These properties are used by the child poms to resolve the
> parent pom (they are used in the tags). These properties are
> inherited by the children (as expected) when running goals such as clean,
> package, or install.
> I start to see problems when I try to use the site plugin. I first run the
> install goal to install my project's jars and poms into my local
> repo(~/.m2/repository/). I then verify that the jars and poms are in my
> local repo. When I try to run the site plugin it seems as though maven is
> unable to interpret the properties defined in the parent pom. I receive the
> following output for each module:
> [INFO]
>
> [INFO] Building my-client-ui
> [INFO]task-segment: [site]
> [INFO]
>
> [INFO] [site:site]
> Downloading:
> http://repo1.maven.org/maven2/${myGroupId}/${myArtifactId}/${myVersion}/${myArtifactId}-${myVersion}.pom
> [WARNING] Unable to load parent project from repository: Failed to validate
> POM for project ${myGroupId}:${myArtifactId} at Artifact
> [${myGroupId}:${myArtifactId}:pom:${myVersion}]
> [INFO] Generating "Continuous Integration" report...
> I've tried using site:deploy, site:run, and site:stage. In all cases I
> recieve a sucessful build, but all sites generated contain broken links.
> (Note. parent pom's distributionManagement site url=file:///home/eric/tmp)
> When using site:deploy, there are two issues with the site. The first is
> that none of the modules are listed for the project on the left hand side of
> the screen. The second is that when I go to the Dependence Convergence
> section, the links to my project's modules are broken. In example, the link
> to my-client-ui incorrectly points to http://www.mycompany.com/my-client-ui
> when it is in fact located at file:///home/eric/tmp/my-client-ui (Note.
> http://www.mycompany.com is defined in the parent pom as the project's url).
> site:run demonstrates the same problems as site:deploy.
> When using site:stage -DstagingDirectory=/home/eric/tmp, there are again two
> issues w/ the site. The first is the same, none of the modules are listed on
> the left hand side of the screen. The second is also the same, except that
> the links in the Dependency Conve
[jira] Created: (MERCURY-96) reduce # of modules, merge when possible
reduce # of modules, merge when possible Key: MERCURY-96 URL: http://jira.codehaus.org/browse/MERCURY-96 Project: Mercury Issue Type: Improvement Affects Versions: 1.0-alpha-5 Reporter: Oleg Gusakov Assignee: Oleg Gusakov -- 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: (MERCURY-96) reduce # of modules, merge when possible
[ http://jira.codehaus.org/browse/MERCURY-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Gusakov updated MERCURY-96: Fix Version/s: 1.0-alpha-6 > reduce # of modules, merge when possible > > > Key: MERCURY-96 > URL: http://jira.codehaus.org/browse/MERCURY-96 > Project: Mercury > Issue Type: Improvement >Affects Versions: 1.0-alpha-5 >Reporter: Oleg Gusakov >Assignee: Oleg Gusakov > Fix For: 1.0-alpha-6 > > -- 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
