moving this list to dev
This list is closing down. Please move further discussion to dev@maven.apache.org Roy
[jira] Created: (MNG-318) trigger clean or recompile if pom (including parent and dependencies) has changed
trigger clean or recompile if pom (including parent and dependencies) has changed - Key: MNG-318 URL: http://jira.codehaus.org/browse/MNG-318 Project: m2 Type: Bug Versions: 2.0-alpha-1 Reporter: Brett Porter Priority: Minor -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-319) Add ability to aggregate module jars into a single jar
Add ability to aggregate module jars into a single jar -- Key: MNG-319 URL: http://jira.codehaus.org/browse/MNG-319 Project: m2 Type: New Feature Components: maven-plugins Versions: 2.0-alpha-1 Reporter: Vincent Massol This is for packaging purpose. As discussed with Brett, a sensible place would be in the assembly 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-320) .svn files get copied in the generated WAR file
.svn files get copied in the generated WAR file --- Key: MNG-320 URL: http://jira.codehaus.org/browse/MNG-320 Project: m2 Type: Bug Components: maven-plugins Versions: 2.0-alpha-1 Reporter: Vincent Massol when using m2 install on a war project the .svn files that are in src/main/webapp get copied. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-321) when packaging = pom, the repository should store it in the groupID directory
when packaging = pom, the repository should store it in the groupID directory - Key: MNG-321 URL: http://jira.codehaus.org/browse/MNG-321 Project: m2 Type: Bug Components: repository-tools, maven-artifact Reporter: Brett Porter Priority: Blocker Fix For: 2.0-alpha-2 eliminate the artifactId from the path when packaging is pom, so the repository matches the source tree and is easier to browse, avoiding directories like: org/apache/maven/maven/maven-2.0-alpha-1.pom To allow migration, we should have the repo tools copy these into both locations if found in either, then stop that and clean up at the release of alpha-3 (allowing users to remain a release behind). -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-320) .svn files get copied in the generated WAR file
[ http://jira.codehaus.org/browse/MNG-320?page=history ] Brett Porter updated MNG-320: - Fix Version: 2.0-alpha-2 can be fixed easily enough. slotting into alpha-2 .svn files get copied in the generated WAR file --- Key: MNG-320 URL: http://jira.codehaus.org/browse/MNG-320 Project: m2 Type: Bug Components: maven-plugins Versions: 2.0-alpha-1 Reporter: Vincent Massol Fix For: 2.0-alpha-2 when using m2 install on a war project the .svn files that are in src/main/webapp get copied. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Maven 2 directory structure for Multiple Modules configurable?
Hi all, Good to see all these changes in Maven 2. I use Maven since a long time and actually in a big J2EE project producing a lot of different artifacts with multi-project. We use Eclipse 3 as IDE and the maven-eclipse-plugin to create .project and .classpath files. This works fine for us and thanks to Maven we do not depend to a special IDE. Now I read in the Getting Started section of the new Maven 2 documentation in Subsection Multiple Modules the new plans for creating multiple modules. I want to ask, is the new directory structure configurable? +- pom.xml +- my-app | +- pom.xml +- my-webapp | +- pom.xml I saw this new structure in Vincent Massol's ppt presentations and examples and now in Maven 2 (but not in Cargo ;-). I'm interested because the pitfall with Eclipse is that this kind of directory structure is not supported. The classpath and build properties in Eclipse 3 are only on the project level configurable and not on directories. This means one artifact in Maven is one Project in Eclipe and must reside in the same directory like: +- my-root | +- pom.xml +- my-app | +- pom.xml +- my-webapp | +- pom.xml So my question? Is this directory structure for Eclipse in Maven 2 possible? Thanks! yo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MAVENUPLOAD-355) Upload Jaxen beta 4 to IBiblio repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-355?page=history ] Elliotte Rusty Harold closed MAVENUPLOAD-355: - Resolution: Fixed The repository eventually took care of itself automatically. We're now up to beta 5. Upload Jaxen beta 4 to IBiblio repository - Key: MAVENUPLOAD-355 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-355 Project: maven-upload-requests Type: Task Reporter: Elliotte Rusty Harold This is the official beta 4 release of Jaxen. There's an earlier, unofficial Jaxen beta 4 in the repository that this will replace. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 directory structure for Multiple Modules configurable?
Joachim Schreiber wrote: [...] Now I read in the Getting Started section of the new Maven 2 documentation in Subsection Multiple Modules the new plans for creating multiple modules. I want to ask, is the new directory structure configurable? +- pom.xml +- my-app | +- pom.xml +- my-webapp | +- pom.xml I saw this new structure in Vincent Massol's ppt presentations and examples and now in Maven 2 (but not in Cargo ;-). I'm interested because the pitfall with Eclipse is that this kind of directory structure is not supported. AFAIK the only limitation which exists in eclipse is that project directories cannot overlap. So you should be able to import to eclipse all projects, which contain java sources and are leaves in the directory tree. So in you case you can create eclipse projects for my-app and my-webapp In more complex case +- pom.xml +- my-app | +- pom.xml +- my-webapp | +- pom.xml +- subprojects +- pom.xml +-sub1 +- pom.xml +-sub2 +- pom.xml you can create eclipse projects for my-app, my-webapp sub1 and sub2. But there are other tools which may require (or recommend) other directory layout. For example subversion. I don't know if recommended subversion layout which is already quite frequently used is already supported in m2: maven-plugins/ |_ plugin1/ |_ trunk/ |_ branches/ |_ tags/ |_ pluginN/ |_ trunk/ |_ branches/ |_ tags/ and how to use it with help of modules section in pom. Is something like this going to be supported: modules moduleplugin1/trunk/module ... modulepluginK/tags/3.2/module ... modulepluginN/trunk/module /modules or users will be forced to use svn:externals in such cases (or something else)? Michal Nie dzwon do Londynu... zanim nie sprawdzisz HALO.interia.pl Tutaj: http://link.interia.pl/f1870 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 2 directory structure for Multiple Modules configurable?
From: Michal Maczka [mailto:[EMAIL PROTECTED] AFAIK the only limitation which exists in eclipse is that project directories cannot overlap. Yes So you should be able to import to eclipse all projects, which contain java sources and are leaves in the directory tree. So in you case you can create eclipse projects for my-app and my- webapp Ok I do this and... eclipse_workspcae +- my-app | +- pom.xml +- my-webapp | +- pom.xml ...I have no root project for my root pom.xml because the root is the workspace and there is no possibility to check out something from inside eclipse in the workspace. Do I misunderstand? yo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 directory structure for Multiple Modules configurable?
Joachim Schreiber wrote: From: Michal Maczka [mailto:[EMAIL PROTECTED] AFAIK the only limitation which exists in eclipse is that project directories cannot overlap. Yes So you should be able to import to eclipse all projects, which contain java sources and are leaves in the directory tree. So in you case you can create eclipse projects for my-app and my- webapp Ok I do this and... eclipse_workspcae +- my-app | +- pom.xml +- my-webapp | +- pom.xml ...I have no root project for my root pom.xml because the root is the workspace and there is no possibility to check out something from inside eclipse in the workspace. Do I misunderstand? Last time I did two ~ months ago as I am using different ide more often so sorry if my memory is playing tricks: I used import feature to import existing projects into the workspace. So afaik you can keep your projects where ever you want and just virtually add them to any workspace. I used one of the milestones builds of eclipse 3.1. I don't know if this is something new for eclipse 3.1 or if it works also for 3.0 michal -- Startuj z INTERIA.PL! http://link.interia.pl/f186c - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 2 directory structure for Multiple Modules configurable?
-Original Message- From: Joachim Schreiber [mailto:[EMAIL PROTECTED] Sent: samedi 16 avril 2005 12:27 To: dev@maven.apache.org Subject: Maven 2 directory structure for Multiple Modules configurable? [snip] +- pom.xml +- my-app | +- pom.xml +- my-webapp | +- pom.xml I saw this new structure in Vincent Massol's ppt presentations and examples and now in Maven 2 (but not in Cargo ;-). It's actually there... (unless I've misunderstood what you meant :-)). BTW I've also committed the maven2 pom.xml in Cargo about a week ago (with more modifications done this morning - I'm slowly creating a m2 build but m2 is still missing some plugins like checkstyle, ear, reports, etc). [snip] Personally I still use a single Eclipse project for the master project + all subprojects. That's until I find a better solution... -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r161028 - in maven/maven-1/plugins/trunk/artifact: project.xml src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java
Brett, These dependencies aren't on ibiblio. dependency groupIdmaven/groupId artifactIdwagon-provider-api/artifactId - version1.0-alpha-2-SNAPSHOT/version + version1.0-alpha-3-SNAPSHOT/version /dependency dependency groupIdmaven/groupId artifactIdwagon-http/artifactId - version1.0-alpha-2-SNAPSHOT/version + version1.0-alpha-2/version /dependency dependency groupIdmaven/groupId artifactIdwagon-ftp/artifactId - version1.0-alpha-2-SNAPSHOT/version + version1.0-alpha-2/version /dependency dependency groupIdmaven/groupId artifactIdwagon-ssh/artifactId - version1.0-alpha-2-SNAPSHOT/version + version1.0-alpha-2/version /dependency dependency groupIdmaven/groupId artifactIdwagon-ssh-external/artifactId - version1.0-alpha-2-SNAPSHOT/version + version1.0-alpha-2/version /dependency dependency groupIdmaven/groupId artifactIdwagon-file/artifactId - version1.0-alpha-2-SNAPSHOT/version + version1.0-alpha-2/version /dependency Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Maven 2 directory structure for Multiple Modules configurable?
From: Vincent Massol [mailto:[EMAIL PROTECTED] Sent: Saturday, April 16, 2005 4:07 PM To: 'Maven Developers List' Subject: RE: Maven 2 directory structure for Multiple Modules configurable? [snip] It's actually there... (unless I've misunderstood what you meant :-)). Aahhh I see it now ;-) Personally I still use a single Eclipse project for the master project + all subprojects. That's until I find a better solution... Yes exactly this is the problem in big projects. I have a multi-project build with more than 50 ejbs and 3 different developers. I use binary dependency builds with snapshots. This makes building only of the core or only parts of the modules very fast. Each ejb, jar, war has its own maven project and is part of the multi-project build. When I now check out the complete trunk in the new Maven 2 layout I have all ejbs (sub projects/modules) in one directory and when I start the multi-project build all ejbs are generated with e.g. xdoclet. This takes a long time and no advantage of the binary dependency build is available any longer. The solution is now to delete all ejbs I do not need to develop only for example a few modules. But this is not a fine solution to tell your developers please check out the trunk and after this you're allowed to delete this and this and. It's nicer to say check out this core projects and then the module you want to work with. After a checkout from a project I use in Maven 1 the maven-eclipse-plugin to generate .classpath and .project. Is this working with the new directory structure too? I hope my bad English can explain my prob clear enough?! yo - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPJCOVERAGE-22) jcoverage fails while junit passes?
[ http://jira.codehaus.org/browse/MPJCOVERAGE-22?page=comments#action_32096 ] Nate Chadwick commented on MPJCOVERAGE-22: -- I have the exact same problem with a Spring 1.1.5 unit test. The resource it is unable to load is in my /src/test/resources dir. -n jcoverage fails while junit passes? --- Key: MPJCOVERAGE-22 URL: http://jira.codehaus.org/browse/MPJCOVERAGE-22 Project: maven-jcoverage-plugin Type: Bug Versions: 1.0.9 Environment: Windows XP SP2, JDK 1.4.2_05, Maven 1.0.1, Spring Framework 1.1.3 Reporter: Brian Guan Assignee: Emmanuel Venisse I have written a unit test to test my webapp, which runs fine using maven, but when I try to run maven jcoverage the same unit test case fails with a file not found error. The webapp is developed using Spring MVC framework 1.1.3, and the junit test case is written using Spring Mock 1.1.3. The following is the console output with a successful maven (default goal) run and a failed maven jcoverage run: === D:\yorzdev\trunk\pubweb-sprmvcmaven __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0.1 build:start: yorz-build: war:init: war:war-resources: [copy] Copying 1 file to C:\tomcat-5.0\webapps\pubweb\WEB-INF java:prepare-filesystem: java:compile: [echo] Compiling to D:\yorzdev\trunk\pubweb-sprmvc/target/classes java:jar-resources: test:prepare-filesystem: test:test-resources: test:compile: [javac] Compiling 1 source file to D:\yorzdev\trunk\pubweb-sprmvc\target\test-classes test:test: [junit] Running com.yorz.pubweb.PubWebControllerTest (xml.XmlBeanDefinitionReader 119 ) Loading XML bean definitions from ServletContext resource [/mockContext.xml] (xml.XmlBeanDefinitionReader 119 ) Loading XML bean definitions from ServletContext resource [/WEB-INF/pubweb-servlet.xml] (support.XmlWebApplicationContext90 ) Bean factory for application context [org.springframework.web.context.support.XmlWebApplicationCo ntext;hashCode=18061339]: org.springframework.beans.factory.support.DefaultListableBeanFactory defining beans [txnLogicSvc,messageSource,vie wResolver,exceptionResolver,urlMapping,tilesConfigurer,pubwebController,pubwebControllerResolver,loginForm,loginValidator,selfRegisterForm,s elfRegisterValidator,addListingForm,addReferralForm,addListingValidator,addReferralValidator]; root of BeanFactory hierarchy (support.XmlWebApplicationContext294 ) 16 beans defined in application context [org.springframework.web.context.support.XmlWebApplicatio nContext;hashCode=18061339] (support.DefaultListableBeanFactory 232 ) Creating shared instance of singleton bean 'messageSource' (support.XmlWebApplicationContext395 ) Using MessageSource [org.springframework.context.support.ResourceBundleMessageSource: basenames=[ messages]] (support.XmlWebApplicationContext426 ) Unable to locate ApplicationEventMulticaster with name 'applicationEventMulticaster': using defau lt [EMAIL PROTECTED] (support.UiApplicationContextUtils 67 ) No ThemeSource found for [org.springframework.web.context.support.XmlWebApplicationContext;hashCo de=18061339]: using ResourceBundleThemeSource (support.XmlWebApplicationContext448 ) Refreshing listeners (support.DefaultListableBeanFactory 246 ) Pre-instantiating singletons in factory [org.springframework.beans.factory.support.DefaultListabl eBeanFactory defining beans [txnLogicSvc,messageSource,viewResolver,exceptionResolver,urlMapping,tilesConfigurer,pubwebController,pubwebCont rollerResolver,loginForm,loginValidator,selfRegisterForm,selfRegisterValidator,addListingForm,addReferralForm,addListingValidator,addReferra lValidator]; root of BeanFactory hierarchy] (support.DefaultListableBeanFactory 232 ) Creating shared instance of singleton bean 'txnLogicSvc' (support.DefaultListableBeanFactory 232 ) Creating shared instance of singleton bean 'viewResolver' (support.DefaultListableBeanFactory 232 ) Creating shared instance of singleton bean 'exceptionResolver' (handler.SimpleMappingExceptionResolver 102 ) Default error view is 'generalException' (support.DefaultListableBeanFactory 232 ) Creating shared instance of singleton bean 'urlMapping' (support.DefaultListableBeanFactory 232 ) Creating shared instance of singleton bean 'pubwebController' (pubweb.PubWebController 213 ) Found action method [public org.springframework.web.servlet.ModelAndView com.yorz.pubweb.PubWebCo ntroller.homeHandler(javax.servlet.http.HttpServletRequest,javax.servlet.http.HttpServletResponse) throws javax.servlet.ServletException] (pubweb.PubWebController 213 ) Found action method [public org.springframework.web.servlet.ModelAndView com.yorz.pubweb.PubWebCo
[jira] Created: (MAVENUPLOAD-362) Upload wicket-1.0.0-rc2.jar
Upload wicket-1.0.0-rc2.jar --- Key: MAVENUPLOAD-362 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-362 Project: maven-upload-requests Type: Task Reporter: Martijn Dashorst http://wicket.sourceforge.net/downloads/wicket-1.0.0-rc2-bundle.jar http://wicket.sourceforge.net http://wicket.sourceforge.net/team-list.html Wicket is a Java web application framework that takes simplicity, separation of concerns and ease of development to a whole new level. Wicket pages can be mocked up, previewed and later revised using standard WYSIWYG HTML design tools. Dynamic content processing and form handling is all handled in Java code using a first-class component model backed by POJO data beans that can easily be persisted using your favourite technology. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-363) Upload wicket-extensions-1.0.0-rc2.jar
Upload wicket-extensions-1.0.0-rc2.jar -- Key: MAVENUPLOAD-363 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-363 Project: maven-upload-requests Type: Task Reporter: Martijn Dashorst http://wicket.sourceforge.net/downloads/wicket-extensions-1.0.0-rc2-bundle.jar http://wicket.sourceforge.net http://wicket.sourceforge.net/team-list.html Wicket is a Java web application framework that takes simplicity, separation of concerns and ease of development to a whole new level. Wicket pages can be mocked up, previewed and later revised using standard WYSIWYG HTML design tools. Dynamic content processing and form handling is all handled in Java code using a first-class component model backed by POJO data beans that can easily be persisted using your favourite technology. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Testing a m2 plugin
Yes, I have a JIRA in to turn that into an m2 plugin itself. Not sure that's exactly what you want, as it forks m2 to run the goals. Really, an integration test should not be needed - if the plugin is in Java, you should be able to test with junit. At least up until the point that multiple goals need to occur inside the lifecycle. I think the best thing to do would be to put together the tests you need and single out the things you don't think are covered by juni, and we can all discuss what we can provide for plugin writers - whether it be a way to completely run m2, or a test suite that provides APIs to help test with junit, or testing implementations of some of the m2 components. Just to double check too - you're going to run your ideas for the plugin past here as well? I assume you are planning now, and using test first, so testing was the first thing :) Whether the clover plugin is written as part of the m2 project or not, the plugin API is currently being finalised and any reporting coming out of it should help form the m2 API's for that along with the other plugins getting developed, so I want to make sure everyone is helping each other out :) Thanks, Brett Vincent Massol wrote: Hi, I'm writing a Clover plugin and I'd like to write tests for it as I progress. Obviously most tests will have to be integration tests. I've seen that the m2 team has developed an integration test system in maven-components/maven-core-it-verifier with tests in maven-components/maven-core-it. I was wondering if this tester is made available in the form of a m2 plugin for external plugin writers? Thanks -Vincent - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: svn commit: r161028 - in maven/maven-1/plugins/trunk/artifact: project.xml src/main/org/apache/maven/artifact/deployer/DefaultArtifactDeployer.java
Sorry, I've been pushing them to the maven2 repository because the converter isn't handling m2 projects in the m1 repository yet. I'll copy these across on ibiblio, and we can correct later. - Brett Emmanuel Venisse wrote: Brett, These dependencies aren't on ibiblio. dependency groupIdmaven/groupId artifactIdwagon-provider-api/artifactId - version1.0-alpha-2-SNAPSHOT/version + version1.0-alpha-3-SNAPSHOT/version /dependency dependency groupIdmaven/groupId artifactIdwagon-http/artifactId - version1.0-alpha-2-SNAPSHOT/version + version1.0-alpha-2/version /dependency dependency groupIdmaven/groupId artifactIdwagon-ftp/artifactId - version1.0-alpha-2-SNAPSHOT/version + version1.0-alpha-2/version /dependency dependency groupIdmaven/groupId artifactIdwagon-ssh/artifactId - version1.0-alpha-2-SNAPSHOT/version + version1.0-alpha-2/version /dependency dependency groupIdmaven/groupId artifactIdwagon-ssh-external/artifactId - version1.0-alpha-2-SNAPSHOT/version + version1.0-alpha-2/version /dependency dependency groupIdmaven/groupId artifactIdwagon-file/artifactId - version1.0-alpha-2-SNAPSHOT/version + version1.0-alpha-2/version /dependency Emmanuel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MPTEST-14) Test output always occurs when building
[ http://jira.codehaus.org/browse/MPTEST-14?page=comments#action_32100 ] Cyrille Le Clerc commented on MPTEST-14: This issue seems related to a problem of Jelly that does not redirect System.out and System.err to Ant Task. See http://issues.apache.org/jira/browse/JELLY-209 Test output always occurs when building --- Key: MPTEST-14 URL: http://jira.codehaus.org/browse/MPTEST-14 Project: maven-test-plugin Type: Bug Environment: All Reporter: Kurt Schrader The test output for unit tests always shows up on the screen during the builds. We need a new output muxer for it. -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Maven 2 directory structure for Multiple Modules configurable?
After a checkout from a project I use in Maven 1 the maven-eclipse-plugin to generate .classpath and .project. Is this working with the new directory structure too? I'm sure it should all work the same. I know the m2 eclipse plugin is not yet up to the same functionality as the m1 version. But you should be able to generate .project .classpath for each project and add them as desired to the workspace. Note that the directory layout is just a recommendation, there is nothing that m2 requires about it. - Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Filter definition
I think the following should be added to the resources section: filtering properties keyvalue/key key2value/key2 /properties propertyFiles propertyFile.../propertyFile /propertyFiles /filtering The resource patterns can take care of the includes/excludes. I'm still apprehensive about including filtering at this stage though, without some way of managing the environment differentiation. The above is useful for centrally locating properties, but not changing them through dev - stage - qa - prod. And in particular, rebuilding with different properties through those last 3 environments is a bit risky. I've always seen it as a good practice to push all the environment-specific configuration outside of the artifacts, and use a configuration management tool. So in short, I think I would like to add Kenney's patch to resources to allow filtering through the resource plugin's configuration, with a view to thinking this through more and eventually deprecating this and including it in resources if applicable. Any other thoughts? Cheers, Brett Kenney Westerhof wrote: I got in a discussion with Brett about his comments on http://jira.codehaus.org/browse/MNG-178?page=comments#action_31997 . Short summary: i've created a patch for maven-resources-plugin that allows filtering while copying resources. It is enabled by default when a build.properties file is present, because the POM currently has no means of specifying what to filter and what not to filter. We've discussed the possibility of explicitly excluding resources from filtering (see the link), and explicitly stating filtering needs to take place, like maven 1 does (filteringtrue/filtering). I think at least the filtering/ tag needs to be included in the POM, and possibly a means for excluding too, although this is not strictly necessary since you can split up the resources into filtered and non-filtered. Brett also suggested that the filter file, and possibly the tokens, need to be defined in the POM. Since currently property files are ignored by maven (like build.properties, project.properties), we'll have to see if stating the filter file is going to be necessary. If property files are going to be supported, it's not. But I think it's a good idea to define the tokens in the POM, and avoid multiple files for a project. Comments, anyone? Greetings, Kenney Westerhof - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [M2] Clover plugin ideas and questions
I remember I was going to reply to this :) Vincent Massol wrote: Hi, 2/ Option 2: Generate instrumented sources in target/ somewhere and somehow convince the compile plugin to use those sources rather than the ones in src/main/java. I'd definitely say 2. I don't like the clover:on command - it should be implicit in the clover:report goal. But this option seems less good because how do I get the WAR plugin to incorporate instrumented sources (for example) so that functional tests can be run? Any advice for doing this in m2? Well, if your WAR is going to be used in this way, there is probably a need to modify how the WAR is named as well as inserting the classes in there, so you don't end up with instrumented WARs getting deployed to repositories or worse. I'm still working on the idea of alternate lifecycles (there is a JIRA ticket regarding idea:idea and generated sources that covers the same idea, and this applies to all reporting). What this means is that clover:report would fork a lifecycle instance to run everything under its own parameters. You could choose the appropriate lifecycle goal to execute (just test by default, but maybe integration-tests). The tricky bit is ensuring all the steps: 1) store to new locations where needed 2) not redo things that have already been done So this is tricky. I think it is achievable under the m2 lifecycle model (much more so than under m1 where it was all hacks), but I haven't completely mapped it out. I think as we work through the use cases of clover and some of the other reports, it will fall out nicely, but it might take a bit of time. I'm hoping to get back into lifecycle related issues this week, so we'll see how that pans out. Let me (and the list) know how you are progressing, what features you are intending to implement, how you think it will be invoked, etc. I'll try and spend some time documenting what is already there too. Cheers, Brett - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-275) design and publish the Mojo API
[ http://jira.codehaus.org/browse/MNG-275?page=comments#action_32101 ] Brett Porter commented on MNG-275: -- I'd like to consider making the maven-plugin-api dependency optional, and review the split between maven-monitor and maven-plugin. what is provided by the plugin interface is: - execute() method - setLog(Logger logger) method The execute method can be looked up using reflection if the class does not implement Plugin. While this could be done for setLog, the Logger must be something... I suggest that maven-plugin-api should provider the Logger interface (and only an interface - not an implementation), and a plugin wishing to Log will have to implement the Plugin interface (or extend AbstractPlugin). So anything could use these beans by simply looking up and running the execute() method, and I believe that such means would already be valid Ant tasks as is as well as mojos (with appropriate metadata). Then, if it implements plugin the setLog method can be called with a MavenPluginLogger or AntLogger implementation, etc. This reduces the relevance of maven-monitor, and it may be appropriate to just take the interface from there, and then use plexus logging inside Maven itself (and provide a plexus logging implementation of the plugin's logger interface). design and publish the Mojo API --- Key: MNG-275 URL: http://jira.codehaus.org/browse/MNG-275 Project: m2 Type: Task Components: design Reporter: Brett Porter Fix For: 2.0-alpha-2 we need to solidify the Mojo API so that others can start writing them with confidence. This includes: - strategy for dealing with types - dealing with responses - reviewing logging and events - considering whether extending a class is too cumbersome - what basic types we might want to provide without going overboard anything else? -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-275) design and publish the Mojo API
[ http://jira.codehaus.org/browse/MNG-275?page=history ] Brett Porter updated MNG-275: - Comment: was deleted design and publish the Mojo API --- Key: MNG-275 URL: http://jira.codehaus.org/browse/MNG-275 Project: m2 Type: Task Components: design Reporter: Brett Porter Fix For: 2.0-alpha-2 we need to solidify the Mojo API so that others can start writing them with confidence. This includes: - strategy for dealing with types - dealing with responses - reviewing logging and events - considering whether extending a class is too cumbersome - what basic types we might want to provide without going overboard anything else? -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-275) design and publish the Mojo API
[ http://jira.codehaus.org/browse/MNG-275?page=comments#action_32102 ] Brett Porter commented on MNG-275: -- I'd like to consider making the maven-plugin-api dependency optional, and review the split between maven-monitor and maven-plugin. what is provided by the plugin interface is: - execute() method - setLog(Logger logger) method The execute method can be looked up using reflection if the class does not implement Plugin. While this could be done for setLog, the Logger must be something... I suggest that maven-plugin-api should provider the Logger interface (and only an interface - not an implementation), and a plugin wishing to Log will have to implement the Plugin interface (or extend AbstractPlugin). So anything could use these beans by simply looking up and running the execute() method, and I believe that such means would already be valid Ant tasks as is as well as mojos (with appropriate metadata). Note, however that most Ant tasks don't take this approach - they extend Task, and utilise several Ant types. There is also a difference between addXXX and addConfiguredXXX, the latter we don't support and the former done through setters and private field injection. Then, if it implements plugin the setLog method can be called with a MavenPluginLogger or AntLogger implementation, etc. This reduces the relevance of maven-monitor, and it may be appropriate to just take the interface from there, and then use plexus logging inside Maven itself (and provide a plexus logging implementation of the plugin's logger interface). design and publish the Mojo API --- Key: MNG-275 URL: http://jira.codehaus.org/browse/MNG-275 Project: m2 Type: Task Components: design Reporter: Brett Porter Fix For: 2.0-alpha-2 we need to solidify the Mojo API so that others can start writing them with confidence. This includes: - strategy for dealing with types - dealing with responses - reviewing logging and events - considering whether extending a class is too cumbersome - what basic types we might want to provide without going overboard anything else? -- 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 - If you want more information on JIRA, or have a bug to report see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
