[jira] Commented: (MSITE-176) AbstractSiteRenderingMojo causes a NPE if url of current project is not set
[ http://jira.codehaus.org/browse/MSITE-176?page=comments#action_72998 ] Martin Zeltner commented on MSITE-176: -- Checkout my project: https://svn.sourceforge.net/svnroot/el4j/branches/el4j_1.1-alpha-m2/el4j Execute the following in checked out dir: mvn -N cd skin mvn cd ../framework mvn -N cd site mvn site:site On problem just ask. BTW take a look at http://svn.apache.org/viewvc/maven/doxia/trunk/doxia-decoration-model/src/main/java/org/apache/maven/doxia/site/decoration/inheritance/DefaultDecorationModelInheritanceAssembler.java?revision=367102&view=mark and you will see that an invocation of method "assembleModelInheritance" with null param "childBaseUrl" will produce a NPE. This occurs when the url of the current project is not set in pom.xml. Cheers, Martin > AbstractSiteRenderingMojo causes a NPE if url of current project is not set > --- > > Key: MSITE-176 > URL: http://jira.codehaus.org/browse/MSITE-176 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: WinXP, Java5 >Reporter: Martin Zeltner >Priority: Blocker > Attachments: patch_maven-site-plugin.txt > > > AbstractSiteRenderingMojo causes a NullPointerException in > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler > if url of current project is not set. > $ mvn site:site > ... > [INFO] [site:site] > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] null > [INFO] > > [INFO] Trace > java.lang.NullPointerException > at > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.getParentPrefix > (DefaultDecorationModelInheritanceAssembler.java:340) > at > org.apache.maven.doxia.site.decoration.inheritance.DefaultDecorationModelInheritanceAssembler.assembleModelIn > heritance(DefaultDecorationModelInheritanceAssembler.java:46) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:225 > ) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:217 > ) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.getDecorationModel(AbstractSiteRenderingMojo.java:492 > ) > at > org.apache.maven.plugins.site.AbstractSiteRenderingMojo.createSiteRenderingContext(AbstractSiteRenderingMojo. > java:431) > at > org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:108) > at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:92) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:417) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:488) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:458) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.jav > a:306) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:393) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:182) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:690) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:380) > 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:585) > 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) > This url is mostly not set, anyway not for each child module. To solve this > issue I did the following in method *getDecorationModel* of > *org.apache.maven.plugins.site.AbstractSiteRenderingMojo*: > If the parent mo
[jira] Created: (MSITE-177) Docs are not updated if only site.xml changed
Docs are not updated if only site.xml changed - Key: MSITE-177 URL: http://jira.codehaus.org/browse/MSITE-177 Project: Maven 2.x Site Plugin Issue Type: Bug Affects Versions: 2.0-beta-5 Reporter: Jörg Hohwiller If I update site.xml (e.g. add new menu-items) and regenerate my existing site, the index gets updated but other existing pages are not rebuild and therefore show the menus in the state before the site.xml has changed (so new menus are missing). This causes a confusing site where menus appear and disappear while surfing. I only use xdos (and they are in a subfolder) so I can not tell if this happens with apt as well. I reproduced the problem with "mvn site" and "mvn site:stage". As a workaround I can delete the old site before building. Since I stage the site directly to the final destination on the local machine where it is served this is not very suitable because then the site is broken until it is completely rebuild. If you consider to fix this issue please beware that site.xml can inherit stuff in multiproject envronments. So it is unclear if the optimization to only re-generate if something has changed makes sense at all. It might be quite complicated to determine this - the question is how much time is saved by this at all. -- 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: (MAVENUPLOAD-1072) Please upload ldaptemplate-1.0.1
Please upload ldaptemplate-1.0.1 Key: MAVENUPLOAD-1072 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1072 Project: maven-upload-requests Issue Type: Task Reporter: Ulrik Sandberg LdapTemplate is a Java framework to simplify LDAP operations, based on the pattern of Spring's JdbcTemplate. It has become quite popular, with downloads now reaching 500-600 per month. The framework has recently been added as a Spring sub-project, and future releases will be under the name Spring LDAP. A previous upload request (MAVENUPLOAD-1070) was denied because 1.0.1 supposedly was already in ibiblio, but that does not seem to be the case. The pom and the license files are there, but no jar and no sources. -- 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: (MWAR-70) If property archiveClasses is set to true then war plugin should use this jar instead of creating a new one
If property archiveClasses is set to true then war plugin should use this jar instead of creating a new one --- Key: MWAR-70 URL: http://jira.codehaus.org/browse/MWAR-70 Project: Maven 2.x War Plugin Issue Type: Improvement Affects Versions: 2.1 Environment: WinXp, Java5 Reporter: Martin Zeltner I had a look at the source code of today's svn trunk and saw that the jar is created individually. I suggest to check first if there is already a created jar (created by maven-jar-plugin) and use this if it exists. In this case you can benefit from the power of the maven-jar-plugin (edit manifest for example). Cheers, Martin -- 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: (MCHANGELOG-45) All reports generated links point to the trunk of the svn module
All reports generated links point to the trunk of the svn module Key: MCHANGELOG-45 URL: http://jira.codehaus.org/browse/MCHANGELOG-45 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Environment: Windows Reporter: Rob MavenUser Priority: Minor Hello, *all* my generated links (changelog reports, 2.0-SNAPSHOT, Maven 2.0.4) point to the trunk of my svn module. For example, for mypage.jsp, the link should be : http://my.svn.com:/rep/prj/modname/trunk/src/www/webmodname/jsp/mypage.jsp but it is : http://my.svn.com:/rep/prj/modname/trunk/ The same for all my files. Is it a bug or do I miss anything in my configuration ? Thanks in advance Best Regards Rob Here my settings : ... org.apache.maven.plugins maven-changelog-plugin 2.0-SNAPSHOT dual-report range 90 changelog file-activity dev-activity scm:svn:http://my.svn.com:/rep/prj/modname/trunk scm:svn:http://my.svn.com:/rep/prj/modname/trunk http://my.svn.com:/rep/prj/modname/trunk/ src/java src/www -- 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-130) Create a model for a release
[ http://jira.codehaus.org/browse/MRELEASE-130?page=comments#action_73004 ] Edwin Punzalan commented on MRELEASE-130: - Hi, Jeremy. Can I ask your progress on this? > Create a model for a release > > > Key: MRELEASE-130 > URL: http://jira.codehaus.org/browse/MRELEASE-130 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Reporter: Jason van Zyl > Assigned To: Jeremy Whitlock > > Use modello to create a model for a release. Something that could be sent to > a release mechanism for an official release. -- 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: (CONTINUUM-755) Add field validations with webwork field validator
[ http://jira.codehaus.org/browse/CONTINUUM-755?page=comments#action_73007 ] Maria Odea Ching commented on CONTINUUM-755: Should the validation for the cron expression in the schedule form include the allowed characters per field? eg. for the Month field in the cron expression, the allowable values are 1-12 or JAN-DEC and a few special characters only, and so on. > Add field validations with webwork field validator > -- > > Key: CONTINUUM-755 > URL: http://jira.codehaus.org/browse/CONTINUUM-755 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.1 >Reporter: Emmanuel Venisse > Assigned To: Maria Odea Ching > Fix For: 1.1 > > Original Estimate: 1 day, 6 hours > Time Spent: 11 hours, 30 minutes > Remaining Estimate: 18 hours, 30 minutes > -- 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: (CONTINUUM-755) Add field validations with webwork field validator
[ http://jira.codehaus.org/browse/CONTINUUM-755?page=comments#action_73008 ] Emmanuel Venisse commented on CONTINUUM-755: A CronExpressionValidator is available in continuum-web. It must be copied to continuum-webapp. This class must be used to validate a cron expression in your webwork filed validator > Add field validations with webwork field validator > -- > > Key: CONTINUUM-755 > URL: http://jira.codehaus.org/browse/CONTINUUM-755 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.1 >Reporter: Emmanuel Venisse > Assigned To: Maria Odea Ching > Fix For: 1.1 > > Original Estimate: 1 day, 6 hours > Time Spent: 11 hours, 30 minutes > Remaining Estimate: 18 hours, 30 minutes > -- 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: (CONTINUUM-755) Add field validations with webwork field validator
[ http://jira.codehaus.org/browse/CONTINUUM-755?page=comments#action_73012 ] Maria Odea Ching commented on CONTINUUM-755: Okay, thanks so much :) > Add field validations with webwork field validator > -- > > Key: CONTINUUM-755 > URL: http://jira.codehaus.org/browse/CONTINUUM-755 > Project: Continuum > Issue Type: Task > Components: Web interface >Affects Versions: 1.1 >Reporter: Emmanuel Venisse > Assigned To: Maria Odea Ching > Fix For: 1.1 > > Original Estimate: 1 day, 6 hours > Time Spent: 11 hours, 30 minutes > Remaining Estimate: 18 hours, 30 minutes > -- 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: (MSUREFIREREP-6) surefire-report reruns tests
[ http://jira.codehaus.org/browse/MSUREFIREREP-6?page=comments#action_73016 ] Martin Brunninger commented on MSUREFIREREP-6: -- I encountered this too. I my eyes, running the test during site generation is no good idea as it modifies content outside the "/target/site" folder. If I run "mvn clean package site" there should be no problem with having no test results. If I run "mvn site" with no test results available, well for me it's ok to have no (or an empty) report in this case. If others like to have the tests done during site generation, I'd see this as an optional configuration as it modifies content outside the "/target/site" folder and is a time issue (especially for larger projects). According to Kenny's problem, I assume he is using the surefire, surefire-report and clover plugin (like me). In this case I can explain why the tests are run four times. If you enable the debug output, you will see that clover does something like running a second lifecycle with goal install. So the first time the test are executed, it is done with instrumented code. The second time (in the original) lifecycle the test are run with non-instrumented code. To be honest, from some point of view this makes sense as instrumentation does not influence your tests (especially when making performance tests), but I would like to decide this myself. The second two executions are simple to explain. This is because surefire-report reruns the test (including all prior phases) and this includes instrumentation too. Hope this helps. > surefire-report reruns tests > > > Key: MSUREFIREREP-6 > URL: http://jira.codehaus.org/browse/MSUREFIREREP-6 > Project: Maven 2.x Surefire report Plugin > Issue Type: Bug > Environment: maven 2.0 >Reporter: Dirk Sturzebecher > > surefire-report reruns the tests. In my case this is not just annoying, but > leads to a failure, as the VM (probably) is reused and leftovers from the > first tests are (definitly) still present. > I run maven with: clean package site -- 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
Maven is unable to download mentioned artifacts.
Hi, I am using Maven 2.0 version with Eclipse (3.1.2) as IDE. I have included the following artifacts in my pom.xml as dependencies. For jcommon:jar:1.0.0-pre2, jfree jcommon 1.0.0-pre2 For junit:junit:jar:3.7, junit junit 3.7 For xstream:xstream:jar:1.1, xstream xstream 1.1 For rome:rome:jar:0.8, rome rome 0.8 But Maven is unable to download these artifacts and the build FAILS. Also observed that Maven is trying to download from a different URL. Downloading from http://www.ibiblio.org/maven2/rome/poms/rome-0.8.pom instead at the URL: http://www.ibiblio.org/maven2/rome/rome/0.8/rome-0.8.pom Downloading from http://www.ibiblio.org/maven2/xstream/poms/xstream-1.1.pom instead at the URL: http://www.ibiblio.org/maven2/xstream/xstream/1.1/xstream-1.1.pom Downloading from http://www.ibiblio.org/maven2/jfree/poms/jcommon-1.0.0-pre2.pom instead at the URL: http://www.ibiblio.org/maven2/jfree/jcommon/1.0.0-pre2/jcommon-1.0.0-pre2.pom Downloading from http://www.ibiblio.org/maven2/junit/poms/junit-3.7.pom instead at the URL: http://www.ibiblio.org/maven2/junit/junit/3.7/ And Maven is downloading junit 3.8 version automatically. Please let me know what changes need to be done so that specified artifacts are downloaded into the local Maven repo. PS: Currently these artifacts are copied manually into the local Maven repo. Thanks Pavan. -- View this message in context: http://www.nabble.com/Maven-is-unable-to-download-mentioned-artifacts.-tf2145824.html#a5924030 Sent from the Maven - Issues forum at Nabble.com.
[jira] Created: (MNG-2523) OS name activation does not work for Mac OS X
OS name activation does not work for Mac OS X - Key: MNG-2523 URL: http://jira.codehaus.org/browse/MNG-2523 Project: Maven 2 Issue Type: Bug Reporter: Jason van Zyl Using something like: macosx mac os x Mac OS X Does not work on Mac OS X. The profile is never activated. -- 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: (MJAR-25) Do not rejar when not necessary
[ http://jira.codehaus.org/browse/MJAR-25?page=all ] Jason van Zyl closed MJAR-25. - Resolution: Duplicate > Do not rejar when not necessary > --- > > Key: MJAR-25 > URL: http://jira.codehaus.org/browse/MJAR-25 > Project: Maven 2.x Jar Plugin > Issue Type: Improvement >Reporter: Jerome Lacoste >Priority: Critical > Attachments: jar-perf_improvements.diff > > > This is a very needed improvement. Just that this patch only addresses the > jar code while it could be made into the archiver pretty easily (we just need > to look into what to do with the pom. Maybe just disable the speed up > improvements if the pom has changed?). > I will let you comment on that. > Patch by Richard Allen <[EMAIL PROTECTED]> > Slightly cleaned up by Jerome Lacoste ([EMAIL PROTECTED]) -- 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: (MPTEST-66) 1.8 version introduces bug in other plugins
[ http://jira.codehaus.org/browse/MPTEST-66?page=comments#action_73022 ] nicolas de loof commented on MPTEST-66: --- Lot's of code generation plugin are attached to java:compile as preGoals... I can suggest two options : 1. keep previous behaviour and assume test:* allways depends on java:compile, even if this is not clean. 2. make ONLY the "test" goal (not the "test:test") depend on java:compile, so that a - "maven test" compiles project and run the tests, as any user may expect it - any plugin depending on test:test will NOT force a twice compilation. This 2d solution requires update to other plugins. Any 3d solution would be welcome as both seems not very cool... > 1.8 version introduces bug in other plugins > --- > > Key: MPTEST-66 > URL: http://jira.codehaus.org/browse/MPTEST-66 > Project: maven-test-plugin > Issue Type: Bug >Affects Versions: 1.8 >Reporter: nicolas de loof > Assigned To: Lukas Theussl > Fix For: 1.8.1 > > Attachments: MPTEST-66.patch > > > When maven-war-plugin is run with maven.test.skip=true, the sources are not > compiled. > Latest version of test-plugin has removed prereqs on java:compile & > java:jar-resources. > Assuming other plugins themself run the java:compile goal may have impact on > lots of plugin and can break many application builds. I think the "test:test" > goal may have a prereqs="java:compile,java:jar-resources", and the > "test:compile" goal only prereqs="test:prepare-filesystem,test:test-resources" -- 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: (MSUREFIRE-139) Argline splits on spaces, should not when quoted
[ http://jira.codehaus.org/browse/MSUREFIRE-139?page=comments#action_73025
]
Timmo Gierke commented on MSUREFIRE-139:
We have exactly the same problem. Blocker!
Instead of splitting a quoted argline we would prefer to specify each argument
in a seprate xml tag "".
Thank's in advance.
Timmo
> Argline splits on spaces, should not when quoted
>
>
> Key: MSUREFIRE-139
> URL: http://jira.codehaus.org/browse/MSUREFIRE-139
> Project: Maven 2.x Surefire Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrea Aime
>Priority: Blocker
> Fix For: 2.3
>
>
> I need to run surefire with the following argline:
> -javaagent:\"${user.home}\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar\"
> -javaagent:\"C:\Documents
> Settings\wolf\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar\"
> The problem is, ForkConfiguration splits the arguments blindly with
> StringUtils.split and the above turns into three
> separate arguments:
> -javaagent:"C:\Documents
> and
> Settings\wolf\.m2\repository\aspectj\aspectjweaver\1.5.0\aspectjweaver-1.5.0.jar"
> And the the vm complains it cannot find the jar C:\Documents.
> When quoted, the split should not happen!
> The following method proved to support quoting properly when splitting on
> spaces (I'm using it in UmlGraph):
> public static String[] tokenize(String s) {
> ArrayList r = new ArrayList();
> String remain = s;
> int n = 0, pos;
> remain = remain.trim();
> while (remain.length() > 0) {
> if (remain.startsWith("\"")) {
> // Field in quotes
> pos = remain.indexOf('"', 1);
> if (pos == -1)
> break;
> r.add(remain.substring(1, pos));
> if (pos + 1 < remain.length())
> pos++;
> } else {
> // Space-separated field
> pos = remain.indexOf(' ', 0);
> if (pos == -1) {
> r.add(remain);
> remain = "";
> } else
> r.add(remain.substring(0, pos));
> }
> remain = remain.substring(pos + 1);
> remain = remain.trim();
> // - is used as a placeholder for empy fields
> if (r.get(n).equals("-"))
> r.set(n, "");
> n++;
> }
> return r.toArray(new String[0]);
> }
--
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: (MCLOVER-50) Test failure during Site goal should not stop the Clover build
[ http://jira.codehaus.org/browse/MCLOVER-50?page=comments#action_73027 ] Vincent Massol commented on MCLOVER-50: --- Hi Andrew, Yes this would be a nice feature but the problem is that it means the Clover plugin needs to know all the plugins that can fail. The surefire plugin is only one plugin but there are other plugins that fail the build in case of errors. For example checkstyle, PMD, etc can fail the build in case of violations. Anyone can develop a custom testing plugin too. It's not possible for the clover plugin to know about all plugins that can exist. Thus the only real solution would be for Maven core to have a flag to tell not to stop the build till the end. Feel free to create a JIRA issue for this or discuss it on the Maven list. Let me know if you have some ideas. Thanks -Vincent > Test failure during Site goal should not stop the Clover build > -- > > Key: MCLOVER-50 > URL: http://jira.codehaus.org/browse/MCLOVER-50 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Andrew Perepelytsya > Assigned To: Vincent Massol >Priority: Critical > > This problem is similar to whatever surefire-report plugin experienced up > until recently. Clover plugin runs tests in its own lifecycle. If there was a > test failure, the build should continue and site be generated with failure > reports. At the moment the build is stopped with a failure completely, and > site *not* generated. -- 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: (CONTINUUM-825) make AclInitializer read SQL statements from classpath
[ http://jira.codehaus.org/browse/CONTINUUM-825?page=all ] Napoleon Esmundo C. Ramirez updated CONTINUUM-825: -- Attachment: CONTINUUM-825.patch This patch can locate the sql file in the jar's context but not in the webapps. I get the following error: org.apache.maven.plugin.MojoExecutionException: file:/tmp/Jetty__continuum-webapp-1_1-SNAPSHOT/webapp/WEB-INF/lib/continuum-security-acegi-1.1-SNAPSHOT.jar!/org/apache/maven/continuum/security/acegi/acl/acegi-acl-derby.sql not found. > make AclInitializer read SQL statements from classpath > -- > > Key: CONTINUUM-825 > URL: http://jira.codehaus.org/browse/CONTINUUM-825 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Napoleon Esmundo C. Ramirez > Fix For: 1.1 > > Attachments: CONTINUUM-825.patch > > > AclInitializer in continuum-acegi-security reads and executes SQL from a file. > To make it work in the webapp needs to read from classpath. -- 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: (MCLOVER-50) Test failure during Site goal should not stop the Clover build
[ http://jira.codehaus.org/browse/MCLOVER-50?page=comments#action_73030 ] Andrew Perepelytsya commented on MCLOVER-50: Vincent, Thanks for taking a look. I think site goal is very different from, e.g. install. Does it make sense to ignore all failures during site generation then? The interesting point Cobertura plugin does work as requested even with test failures, maybe there's some interesting stuff in their code? Anyway, that is the only thing stopping us from using Clover plugin, though I like those polished coverage reports it produces. > Test failure during Site goal should not stop the Clover build > -- > > Key: MCLOVER-50 > URL: http://jira.codehaus.org/browse/MCLOVER-50 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Andrew Perepelytsya > Assigned To: Vincent Massol >Priority: Critical > > This problem is similar to whatever surefire-report plugin experienced up > until recently. Clover plugin runs tests in its own lifecycle. If there was a > test failure, the build should continue and site be generated with failure > reports. At the moment the build is stopped with a failure completely, and > site *not* generated. -- 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: (MCLOVER-50) Test failure during Site goal should not stop the Clover build
[ http://jira.codehaus.org/browse/MCLOVER-50?page=comments#action_73031 ]
Vincent Massol commented on MCLOVER-50:
---
Hi Andrew,
I've checked how they did it for covertura and that's the same way I've been
trying to do it for Clover when I posted my answer above. However I believe
this way is flawed. They've done it by introducing the following in the custom
lifecycle.xml file:
{code:xml}
test
${project.build.directory}/generated-classes/cobertura
true
once
{code}
There are 3 issues here:
* It won't work if the user has bound the surefire test goal to some other
phase. For example it won't work for integration tests running in the
integration-test phase.
* It's dangerous. Any plugin using the configuration
property will find it modified to true even if that's not the expected
behavior. We need some namespace here (I've just sent an email to the dev list
on this topic)
* It'll only work for the surefire plugin but not for any other plugin such as
checkstyle, pmd or any other custom plugin not known by the cobertura plugin.
Thus it can only be a limited solution.
I'm open to ideas.
> Test failure during Site goal should not stop the Clover build
> --
>
> Key: MCLOVER-50
> URL: http://jira.codehaus.org/browse/MCLOVER-50
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.2
>Reporter: Andrew Perepelytsya
> Assigned To: Vincent Massol
>Priority: Critical
>
> This problem is similar to whatever surefire-report plugin experienced up
> until recently. Clover plugin runs tests in its own lifecycle. If there was a
> test failure, the build should continue and site be generated with failure
> reports. At the moment the build is stopped with a failure completely, and
> site *not* generated.
--
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: (MCLOVER-50) Test failure during Site goal should not stop the Clover build
[ http://jira.codehaus.org/browse/MCLOVER-50?page=comments#action_73032 ] Vincent Massol commented on MCLOVER-50: --- Ok, for lack of a better solution I'm going to commit it but beware that it's only a very limited solution to more global problem and it has lots of potential issues... > Test failure during Site goal should not stop the Clover build > -- > > Key: MCLOVER-50 > URL: http://jira.codehaus.org/browse/MCLOVER-50 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Andrew Perepelytsya > Assigned To: Vincent Massol >Priority: Critical > > This problem is similar to whatever surefire-report plugin experienced up > until recently. Clover plugin runs tests in its own lifecycle. If there was a > test failure, the build should continue and site be generated with failure > reports. At the moment the build is stopped with a failure completely, and > site *not* generated. -- 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: (MCLOVER-50) Test failure during Site goal should not stop the Clover build
[ http://jira.codehaus.org/browse/MCLOVER-50?page=all ] Vincent Massol updated MCLOVER-50: -- Fix Version/s: 2.3 Issue Type: Improvement (was: Bug) > Test failure during Site goal should not stop the Clover build > -- > > Key: MCLOVER-50 > URL: http://jira.codehaus.org/browse/MCLOVER-50 > Project: Maven 2.x Clover Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Andrew Perepelytsya > Assigned To: Vincent Massol >Priority: Critical > Fix For: 2.3 > > > This problem is similar to whatever surefire-report plugin experienced up > until recently. Clover plugin runs tests in its own lifecycle. If there was a > test failure, the build should continue and site be generated with failure > reports. At the moment the build is stopped with a failure completely, and > site *not* generated. -- 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: (MCLOVER-50) Test failure during Site goal should not stop the Clover build
[ http://jira.codehaus.org/browse/MCLOVER-50?page=all ] Vincent Massol closed MCLOVER-50. - Resolution: Fixed Fixed with caveats listed in comments above. > Test failure during Site goal should not stop the Clover build > -- > > Key: MCLOVER-50 > URL: http://jira.codehaus.org/browse/MCLOVER-50 > Project: Maven 2.x Clover Plugin > Issue Type: Improvement >Affects Versions: 2.2 >Reporter: Andrew Perepelytsya > Assigned To: Vincent Massol >Priority: Critical > Fix For: 2.3 > > > This problem is similar to whatever surefire-report plugin experienced up > until recently. Clover plugin runs tests in its own lifecycle. If there was a > test failure, the build should continue and site be generated with failure > reports. At the moment the build is stopped with a failure completely, and > site *not* generated. -- 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-130) Create a model for a release
[ http://jira.codehaus.org/browse/MRELEASE-130?page=comments#action_73035 ] Jeremy Whitlock commented on MRELEASE-130: -- Edwin, I just got back from travels and discussed this with Jason and Brett. Development starts on this today. Are you interested in helping? Take care, Jeremy > Create a model for a release > > > Key: MRELEASE-130 > URL: http://jira.codehaus.org/browse/MRELEASE-130 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Reporter: Jason van Zyl > Assigned To: Jeremy Whitlock > > Use modello to create a model for a release. Something that could be sent to > a release mechanism for an official release. -- 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: (CONTINUUM-826) Need report on disk space usage for continuum growth calculations.
Need report on disk space usage for continuum growth calculations. -- Key: CONTINUUM-826 URL: http://jira.codehaus.org/browse/CONTINUUM-826 Project: Continuum Issue Type: New Feature Components: Core system, Web interface Reporter: Joakim Erdfelt Need a report that show disk space utilization from a current and historical point of view, in order to estimate the growth (past, present, and future) of a large Continuum installation. The report should contain ... # Total disk/partition size. # Total disk utilzation by Continuum and projects managed by Continuum. # Historical graph of Total disk utilization. # Total disk space per project. # Historical graph of disk space per project. # Total number of Projects. # Average project disk space utilization. # Estimated number of projects remaining disk space can assigned to. (Remaining Disk Space) / ((Average project size) + 1) = (Room for X more projects) -- 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: (MPA-77) Process Jeff Jensen
[ http://jira.codehaus.org/browse/MPA-77?page=comments#action_73037 ] Lukas Theussl commented on MPA-77: -- CLA received, a/c requested. > Process Jeff Jensen > --- > > Key: MPA-77 > URL: http://jira.codehaus.org/browse/MPA-77 > Project: Maven Project Administration > Issue Type: Task > Components: New Committers >Reporter: Lukas Theussl > Assigned To: Jason van Zyl > Fix For: 2006-q3 > > -- 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: (MWAR-71) 2.0 works, 2.0-beta-2 does not
2.0 works, 2.0-beta-2 does not -- Key: MWAR-71 URL: http://jira.codehaus.org/browse/MWAR-71 Project: Maven 2.x War Plugin Issue Type: Bug Environment: Mac OS X Reporter: Ed Burns Attachments: code.bugreport.tar.gz I have a multi-module build. This is present in the build output when I do mvn from within the submodule [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-war-plugin:2.0:war' --> [DEBUG] (s) classesDirectory = /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/classes [DEBUG] (f) filters = [] [DEBUG] (f) outputDirectory = /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target [DEBUG] (f) primaryArtifact = true [DEBUG] (s) project = [EMAIL PROTECTED] [DEBUG] (f) warName = jsf-simple-partial-update [DEBUG] (s) warSourceDirectory = /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/src/main/webapp [DEBUG] (s) directory = src/main/java [DEBUG] (s) targetPath = WEB-INF [DEBUG] (s) directory = /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/../sunbrand/src/main/webapp [DEBUG] (f) webResources = [Lorg.apache.maven.model.Resource;@392356 [DEBUG] (s) webappDirectory = /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/jsf-simple-partial-update [DEBUG] (f) workDirectory = /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/war/work [DEBUG] -- end configuration -- but this present when I run the build from the top level [DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-war-plugin:2.0-beta-2:war' --> [DEBUG] (s) classesDirectory = /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/classes [DEBUG] (f) outputDirectory = /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target [DEBUG] (s) project = [EMAIL PROTECTED] [DEBUG] (f) warName = jsf-simple-partial-update [DEBUG] (s) warSourceDirectory = /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/src/main/webapp [DEBUG] (s) webappDirectory = /Users/edburns/Projects/J2EE/workareas/jsf-extensions-trunk/code/run-time/samples/simple-partial-update/target/jsf-simple-partial-update [DEBUG] -- end configuration -- I would think the behaviour would be the same regardless of which version of the maven-war-plugin is pulled in. -- 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-1019) downloads not rejected when a proxy returns 302; repository gets corrupted
[ http://jira.codehaus.org/browse/MNG-1019?page=comments#action_73039 ] Natalie Burdick commented on MNG-1019: -- one other item, if the error-handling/resolution is not all happening 'behind the scenes' - i.e., the user is seeing these errors, it would be great to provide a much descriptive information around the error numbers as possible, vs. the usual limited content that's shown > downloads not rejected when a proxy returns 302; repository gets corrupted > -- > > Key: MNG-1019 > URL: http://jira.codehaus.org/browse/MNG-1019 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0-beta-1 > Environment: WinxP laptop, running on a WLAN that has one of those > restricted-access-login pages; all HTTP requests are turned into a 302 > responses redirecting to the login page. >Reporter: Steve Loughran > Fix For: 2.0.5 > > Attachments: MNG-1019-wagon-http-lightweight.patch > > > I was trying to do a build in a meeting, but site IT have just changed their > security policy for guests; instead of a transparent proxy, we have a > transparent proxy that 302s all requests from an unknown client to their > login page. > Here is a bit of the log: > [m2:libraries] Downloading: servletapi/servletapi/2.3/servletapi-2.3.pom > [m2:libraries] [WARNING] Unable to get resource from repository remote > (file:/// > C:/Projects/SmartFrog/core/antbuild/repository/) > [m2:libraries] Downloading: servletapi/servletapi/2.3/servletapi-2.3.pom > [m2:libraries] [WARNING] Unable to get resource from repository remote > (file:/// > C:/Projects/SmartFrog/core/components/lib/) > [m2:libraries] Downloading: servletapi/servletapi/2.3/servletapi-2.3.pom > [m2:libraries] Transferring 0K > [m2:libraries] [WARNING] *** CHECKSUM FAILED - Checksum failed on download: > loca > l = '46b0527200bcc179e835380eb454b48f6cc16e81'; remote = ' > [m2:libraries] > [m2:libraries] 302' - RETRYING > [m2:libraries] Downloading: servletapi/servletapi/2.3/servletapi-2.3.pom > [m2:libraries] Transferring 0K > [m2:libraries] [WARNING] *** CHECKSUM FAILED - Checksum failed on download: > loca > l = '46b0527200bcc179e835380eb454b48f6cc16e81'; remote = ' > [m2:libraries] > [m2:libraries] 302' - IGNORING > [m2:libraries] [WARNING] POM for: 'servletapi:servletapi:pom:2.3' does not > appea > r to be valid. Its will be ignored for artifact resolution. > this is going to be a dog to test. -- 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: (MAVEN-1704) artifactId is used as groupId when the latest is not defined
[ http://jira.codehaus.org/browse/MAVEN-1704?page=all ] Lukas Theussl closed MAVEN-1704. Assignee: Lukas Theussl Resolution: Fixed > artifactId is used as groupId when the latest is not defined > > > Key: MAVEN-1704 > URL: http://jira.codehaus.org/browse/MAVEN-1704 > Project: Maven > Issue Type: Bug > Components: inheritance >Affects Versions: 1.1-beta-2 >Reporter: Carlos Sanchez > Assigned To: Lukas Theussl > Fix For: 1.1-rc1 > > Attachments: MAVEN-1704.tar.gz > > > artifactId is used as groupId when the latest is not defined (using extends > at least), both in 1.0.2 and 1.1b2, which I believe it's a problem, maven > should complain. > Which is really a problem is that if pom a extends pom b, and no groupId is > defined in any of both, in 1.0.2 the artifactId of a is chosen as groupId, > while in 1.1 artifactId of b is the chosen one. -- 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: (MAVEN-1781) Upgrade maven-changes-plugin to v. 1.6.1
Upgrade maven-changes-plugin to v. 1.6.1 Key: MAVEN-1781 URL: http://jira.codehaus.org/browse/MAVEN-1781 Project: Maven Issue Type: Sub-task Reporter: Lukas Theussl -- 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: (MAVEN-1782) Upgrade maven-jdiff-plugin to v. 1.5.1
Upgrade maven-jdiff-plugin to v. 1.5.1 -- Key: MAVEN-1782 URL: http://jira.codehaus.org/browse/MAVEN-1782 Project: Maven Issue Type: Sub-task Reporter: Lukas Theussl Fix For: 1.1-rc1 -- 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: (MAVEN-1782) Upgrade maven-jdiff-plugin to v. 1.5.1
[ http://jira.codehaus.org/browse/MAVEN-1782?page=all ] Lukas Theussl updated MAVEN-1782: - Description: http://jira.codehaus.org/browse/MPJDIFF?report=com.atlassian.jira.plugin.system.project:roadmap-panel Fix Version/s: 1.1-rc1 > Upgrade maven-jdiff-plugin to v. 1.5.1 > -- > > Key: MAVEN-1782 > URL: http://jira.codehaus.org/browse/MAVEN-1782 > Project: Maven > Issue Type: Sub-task >Reporter: Lukas Theussl > Fix For: 1.1-rc1 > > > http://jira.codehaus.org/browse/MPJDIFF?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- 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: (MAVEN-1781) Upgrade maven-changes-plugin to v. 1.6.1
[ http://jira.codehaus.org/browse/MAVEN-1781?page=all ] Lukas Theussl updated MAVEN-1781: - Description: http://jira.codehaus.org/browse/MPCHANGES?report=com.atlassian.jira.plugin.system.project:roadmap-panel Fix Version/s: 1.1-rc1 > Upgrade maven-changes-plugin to v. 1.6.1 > > > Key: MAVEN-1781 > URL: http://jira.codehaus.org/browse/MAVEN-1781 > Project: Maven > Issue Type: Sub-task >Reporter: Lukas Theussl > Fix For: 1.1-rc1 > > > http://jira.codehaus.org/browse/MPCHANGES?report=com.atlassian.jira.plugin.system.project:roadmap-panel -- 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: (MPXDOC-199) Improve stylus.css
Improve stylus.css -- Key: MPXDOC-199 URL: http://jira.codehaus.org/browse/MPXDOC-199 Project: maven-xdoc-plugin Issue Type: Bug Affects Versions: 1.10 Reporter: Lukas Theussl Fix For: 1.10.1 Currently there are some font-size and background issues, notably in tables and definition-lists, that affect the maven site, see eg http://maven.apache.org/maven-1.x/reference/project-descriptor.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] Created: (MPECLIPSE-124) Use wagon instead of deprecated HttpUtils
Use wagon instead of deprecated HttpUtils - Key: MPECLIPSE-124 URL: http://jira.codehaus.org/browse/MPECLIPSE-124 Project: maven-eclipse-plugin Issue Type: Improvement Affects Versions: 1.11 Reporter: Lukas Theussl -- 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: (MPSOURCE-2) Use wagon instead of deprecated HttpUtils
Use wagon instead of deprecated HttpUtils - Key: MPSOURCE-2 URL: http://jira.codehaus.org/browse/MPSOURCE-2 Project: maven-source-plugin Issue Type: Improvement Affects Versions: 1.0 Reporter: Lukas Theussl Fix For: 1.1 -- 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: (CONTINUUM-827) notification emails missing svn information
notification emails missing svn information --- Key: CONTINUUM-827 URL: http://jira.codehaus.org/browse/CONTINUUM-827 Project: Continuum Issue Type: Bug Components: SCM Affects Versions: 1.0.3 Reporter: Brian Fox I'm using 1.0.3 and svn 1.3.2. 99% of the time, the notifications do not list the developer or the commit message. I just get a list of changed files. I have seen it in the past occasionally but almost always the info isn't there. This includes times when there was only 1 commit since the last build. -- 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: (MPSITE-54) APT format needs some "macros" for common constructs such as links to JavaDoc
APT format needs some "macros" for common constructs such as links to JavaDoc
-
Key: MPSITE-54
URL: http://jira.codehaus.org/browse/MPSITE-54
Project: maven-site-plugin
Issue Type: New Feature
Components: plugin
Reporter: Howard M. Lewis Ship
Priority: Minor
Some form of macro processing for APT format files would be nice.
I often find myself writing very verbose links form APT to documentation, i.e.
{{{apidocs/org/package/MyClass.html}MyClass}}
(Not that I ever get to use something that terse, more like
org.apache.tapestry.internal.ioc.RegistryImpl, etc.).
I would love some alternate link forms, maybe something like:
{{{api:MyClass}}}
or
{{{api:org.package.MyClass}}}
and let Maven build the links for me.
I also do some copious cross-linking of my documentation, so something akin to
the Forrest site: prefix would be great (a way to reference another document by
a logical id rather than a relative path).
--
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: (MECLIPSE-76) Projects containing war's as dependency will not include war-reference
[ http://jira.codehaus.org/browse/MECLIPSE-76?page=comments#action_73044 ]
mark struberg commented on MECLIPSE-76:
---
Let's spot the light onto this issue from another side:
If an artifact is depending on a WAR, all resources are beeing unpacked and
afterwards merged with the actual build results.
For example if i'm building an artifact MY-B.war which has a dependency on
MY-A.war, then MY-A.war is beeing unpacked and overlayed with the build results
of MY-B.war by the maven-war-plugin.
To get to the point: We end up with ONE single WAR file which has all classes
in the same directory 'WEB-INF/classes' and with ALL jars in 'WEB-INF/lib'.
This means that the produced classes from MY-B.war may access the classes from
MY-A.war and also their jars.
So why should we not set the classpath into the embedded classes and jars of
the dependant WAR artifact?
In my case, i have a product war artifact which is beeing used as baseline for
multiple customisation war artifacts. This works perfectly for JSPs but not for
java files.
> Projects containing war's as dependency will not include war-reference
> --
>
> Key: MECLIPSE-76
> URL: http://jira.codehaus.org/browse/MECLIPSE-76
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
>Reporter: Tom Spengler
>
> if you have a dependency like
>
> j-core
> j-core-webapp-axx
> 0.0.1
> war
>
> it will not included int .classpath
> Resolution could be
> EclipseClasspathWriter
> --old--
> Artifact artifact = (Artifact) it.next();
> if ( artifact.getArtifactHandler().isAddedToClasspath() )
> --new --
> Artifact artifact = (Artifact) it.next();
> if ( artifact.getArtifactHandler().isAddedToClasspath()
> ||artifact.getArtifactHandler().isIncludesDependencies() )
>
> and
> EclipsePlugin.prepareArtifacts()
> --old--
> Collection artifacts = project.getTestArtifacts();
> --new--
> Collection artifacts = project.getTestArtifacts();
> Set artifact_2 = project.getArtifacts();
> for (Iterator at = artifact_2.iterator(); at.hasNext();){
> Artifact arti = (Artifact) at.next();
> if (! artifacts.contains(arti))
> artifacts.add(arti);
> }
--
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: (MECLIPSE-76) Projects containing war's as dependency will not include war-reference
[ http://jira.codehaus.org/browse/MECLIPSE-76?page=comments#action_73045 ]
mark struberg commented on MECLIPSE-76:
---
one additional comment: for me this is not only a problem with the eclipse
plugin, but mostly a problem while packaging manually, so maybe it better fits
to another area than MECLIPSE?
> Projects containing war's as dependency will not include war-reference
> --
>
> Key: MECLIPSE-76
> URL: http://jira.codehaus.org/browse/MECLIPSE-76
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
>Reporter: Tom Spengler
>
> if you have a dependency like
>
> j-core
> j-core-webapp-axx
> 0.0.1
> war
>
> it will not included int .classpath
> Resolution could be
> EclipseClasspathWriter
> --old--
> Artifact artifact = (Artifact) it.next();
> if ( artifact.getArtifactHandler().isAddedToClasspath() )
> --new --
> Artifact artifact = (Artifact) it.next();
> if ( artifact.getArtifactHandler().isAddedToClasspath()
> ||artifact.getArtifactHandler().isIncludesDependencies() )
>
> and
> EclipsePlugin.prepareArtifacts()
> --old--
> Collection artifacts = project.getTestArtifacts();
> --new--
> Collection artifacts = project.getTestArtifacts();
> Set artifact_2 = project.getArtifacts();
> for (Iterator at = artifact_2.iterator(); at.hasNext();){
> Artifact arti = (Artifact) at.next();
> if (! artifacts.contains(arti))
> artifacts.add(arti);
> }
--
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] Moved: (MSITE-178) APT format needs some "macros" for common constructs such as links to JavaDoc
[ http://jira.codehaus.org/browse/MSITE-178?page=all ]
Lukas Theussl moved MPSITE-54 to MSITE-178:
---
Component/s: (was: plugin)
Workflow: Maven New (was: jira)
Key: MSITE-178 (was: MPSITE-54)
Project: Maven 2.x Site Plugin (was: maven-site-plugin)
> APT format needs some "macros" for common constructs such as links to JavaDoc
> -
>
> Key: MSITE-178
> URL: http://jira.codehaus.org/browse/MSITE-178
> Project: Maven 2.x Site Plugin
> Issue Type: New Feature
>Reporter: Howard M. Lewis Ship
>Priority: Minor
>
> Some form of macro processing for APT format files would be nice.
> I often find myself writing very verbose links form APT to documentation, i.e.
> {{{apidocs/org/package/MyClass.html}MyClass}}
> (Not that I ever get to use something that terse, more like
> org.apache.tapestry.internal.ioc.RegistryImpl, etc.).
> I would love some alternate link forms, maybe something like:
> {{{api:MyClass}}}
> or
> {{{api:org.package.MyClass}}}
> and let Maven build the links for me.
> I also do some copious cross-linking of my documentation, so something akin
> to the Forrest site: prefix would be great (a way to reference another
> document by a logical id rather than a relative path).
--
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: (MAVENUPLOAD-1073) saxon 7.9.1
saxon 7.9.1 --- Key: MAVENUPLOAD-1073 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1073 Project: maven-upload-requests Issue Type: Task Reporter: Jorg Heymans please upload saxon 7.9.1 to ibiblio and mirrors. -- 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: (MAVENUPLOAD-1075) saxon-sql 7.9.1
saxon-sql 7.9.1 --- Key: MAVENUPLOAD-1075 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1075 Project: maven-upload-requests Issue Type: Task Reporter: Jorg Heymans -- 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: (MAVENUPLOAD-1074) saxon-jdom 7.9.1
saxon-jdom 7.9.1 Key: MAVENUPLOAD-1074 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1074 Project: maven-upload-requests Issue Type: Task Reporter: Jorg Heymans -- 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: (CONTINUUM-825) make AclInitializer read SQL statements from classpath
[ http://jira.codehaus.org/browse/CONTINUUM-825?page=all ] Carlos Sanchez updated CONTINUUM-825: - Attachment: CONTINUUM-825-2.patch Improved patch that reads from classpath. Nap: it's not possible to get a File object from a classpath resource. > make AclInitializer read SQL statements from classpath > -- > > Key: CONTINUUM-825 > URL: http://jira.codehaus.org/browse/CONTINUUM-825 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Napoleon Esmundo C. Ramirez > Fix For: 1.1 > > Attachments: CONTINUUM-825-2.patch, CONTINUUM-825.patch > > > AclInitializer in continuum-acegi-security reads and executes SQL from a file. > To make it work in the webapp needs to read from classpath. -- 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: (CONTINUUM-827) notification emails missing svn information
[ http://jira.codehaus.org/browse/CONTINUUM-827?page=all ] Emmanuel Venisse updated CONTINUUM-827: --- Fix Version/s: 1.1 > notification emails missing svn information > --- > > Key: CONTINUUM-827 > URL: http://jira.codehaus.org/browse/CONTINUUM-827 > Project: Continuum > Issue Type: Bug > Components: SCM >Affects Versions: 1.0.3 >Reporter: Brian Fox > Fix For: 1.1 > > > I'm using 1.0.3 and svn 1.3.2. 99% of the time, the notifications do not list > the developer or the commit message. I just get a list of changed files. I > have seen it in the past occasionally but almost always the info isn't there. > This includes times when there was only 1 commit since the last build. -- 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-2522) Regression for the Eclipse codestyle
[ http://jira.codehaus.org/browse/MNG-2522?page=all ]
Vincent Siveton updated MNG-2522:
-
Attachment: MNG-2522.patch
I can apply the patch but I would like to hear inputs from Eclipse users about
it.
> Regression for the Eclipse codestyle
>
>
> Key: MNG-2522
> URL: http://jira.codehaus.org/browse/MNG-2522
> Project: Maven 2
> Issue Type: Bug
> Components: Documentation: Guides, IDEs
>Affects Versions: 2.1
> Environment: trunk
>Reporter: Vincent Siveton
> Attachments: MNG-2522.patch
>
>
> For instance, with the old codestyle (rev 397213), the Eclipse formatter
> formats like this:
> {noformat}
> public class SiteRunMojo
> extends AbstractSiteRenderingMojo
> {noformat}
> With the new one (rev 431101), we have
> {noformat}
> public class SiteRunMojo extends AbstractSiteRenderingMojo
> {noformat}
> Other problems exist.
--
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: (MAVEN-1677) "No directory specified for fileset" when debugging for org.apache.commons.jelly.tags.ant.AntTag on
[ http://jira.codehaus.org/browse/MAVEN-1677?page=all ]
Lukas Theussl closed MAVEN-1677.
Resolution: Won't Fix
Fix Version/s: (was: 1.1-rc1)
It's fixed already but won't be in maven 1.1:
http://issues.apache.org/jira/browse/JELLY-232
> "No directory specified for fileset" when debugging for
> org.apache.commons.jelly.tags.ant.AntTag on
> ---
>
> Key: MAVEN-1677
> URL: http://jira.codehaus.org/browse/MAVEN-1677
> Project: Maven
> Issue Type: Bug
> Components: jelly/ant integration
>Affects Versions: 1.1-beta-1
> Environment: OS X 10.4.2, java version "1.5.0_02"
>Reporter: Scott Lamb
>Priority: Minor
> Attachments: err.log
>
>
> I've been trying to debug problems by specifying an alternate
> log4j.configuration:
> $ MAVEN_OPTS="-Dlog4j.configuration=file:$HOME/log4j.properties" maven
> In the process, I discovered that when the level for
> org.apache.commons.jelly.tags.ant.AntTag is set to DEBUG, maven yields this
> error:
> File.. ${1}
> Element... ant:fileset
> Line.. 49
> Column 45
> No directory specified for fileset.
> When logging for that class is at INFO level, this error does not occur.
> This happens on the "java:compile" goal of even the simplest project. I can
> attach full exception info, the project I used, and the log4j config file I
> used if desired.
> I'd like to figure out what jelly file this occurred in. The file "${1}" is
> not too helpful, though.
--
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: (MAVEN-1677) "No directory specified for fileset" when debugging for org.apache.commons.jelly.tags.ant.AntTag on
[ http://jira.codehaus.org/browse/MAVEN-1677?page=comments#action_73055 ]
Scott Lamb commented on MAVEN-1677:
---
Thanks!
Did the error handling get fixed, too? I.e., with the jelly .toString() NPE bug
in place, does the ${1} in the error message say the actual jelly file now? I
have to confess ignorance as to whether maven or jelly is responsible for this,
but something came up with a line and column number, so it should be able to
come up with a file, too.
> "No directory specified for fileset" when debugging for
> org.apache.commons.jelly.tags.ant.AntTag on
> ---
>
> Key: MAVEN-1677
> URL: http://jira.codehaus.org/browse/MAVEN-1677
> Project: Maven
> Issue Type: Bug
> Components: jelly/ant integration
>Affects Versions: 1.1-beta-1
> Environment: OS X 10.4.2, java version "1.5.0_02"
>Reporter: Scott Lamb
>Priority: Minor
> Attachments: err.log
>
>
> I've been trying to debug problems by specifying an alternate
> log4j.configuration:
> $ MAVEN_OPTS="-Dlog4j.configuration=file:$HOME/log4j.properties" maven
> In the process, I discovered that when the level for
> org.apache.commons.jelly.tags.ant.AntTag is set to DEBUG, maven yields this
> error:
> File.. ${1}
> Element... ant:fileset
> Line.. 49
> Column 45
> No directory specified for fileset.
> When logging for that class is at INFO level, this error does not occur.
> This happens on the "java:compile" goal of even the simplest project. I can
> attach full exception info, the project I used, and the log4j config file I
> used if desired.
> I'd like to figure out what jelly file this occurred in. The file "${1}" is
> not too helpful, though.
--
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: (MAVEN-1677) "No directory specified for fileset" when debugging for org.apache.commons.jelly.tags.ant.AntTag on
[ http://jira.codehaus.org/browse/MAVEN-1677?page=comments#action_73056 ]
Lukas Theussl commented on MAVEN-1677:
--
Have a look at the error log that I attached, you see that the problem was in
maven's driver.jelly.
> "No directory specified for fileset" when debugging for
> org.apache.commons.jelly.tags.ant.AntTag on
> ---
>
> Key: MAVEN-1677
> URL: http://jira.codehaus.org/browse/MAVEN-1677
> Project: Maven
> Issue Type: Bug
> Components: jelly/ant integration
>Affects Versions: 1.1-beta-1
> Environment: OS X 10.4.2, java version "1.5.0_02"
>Reporter: Scott Lamb
>Priority: Minor
> Attachments: err.log
>
>
> I've been trying to debug problems by specifying an alternate
> log4j.configuration:
> $ MAVEN_OPTS="-Dlog4j.configuration=file:$HOME/log4j.properties" maven
> In the process, I discovered that when the level for
> org.apache.commons.jelly.tags.ant.AntTag is set to DEBUG, maven yields this
> error:
> File.. ${1}
> Element... ant:fileset
> Line.. 49
> Column 45
> No directory specified for fileset.
> When logging for that class is at INFO level, this error does not occur.
> This happens on the "java:compile" goal of even the simplest project. I can
> attach full exception info, the project I used, and the log4j config file I
> used if desired.
> I'd like to figure out what jelly file this occurred in. The file "${1}" is
> not too helpful, though.
--
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: (MAVEN-1677) "No directory specified for fileset" when debugging for org.apache.commons.jelly.tags.ant.AntTag on
[ http://jira.codehaus.org/browse/MAVEN-1677?page=comments#action_73057 ]
Scott Lamb commented on MAVEN-1677:
---
Oh, I do indeed. Thanks.
> "No directory specified for fileset" when debugging for
> org.apache.commons.jelly.tags.ant.AntTag on
> ---
>
> Key: MAVEN-1677
> URL: http://jira.codehaus.org/browse/MAVEN-1677
> Project: Maven
> Issue Type: Bug
> Components: jelly/ant integration
>Affects Versions: 1.1-beta-1
> Environment: OS X 10.4.2, java version "1.5.0_02"
>Reporter: Scott Lamb
>Priority: Minor
> Attachments: err.log
>
>
> I've been trying to debug problems by specifying an alternate
> log4j.configuration:
> $ MAVEN_OPTS="-Dlog4j.configuration=file:$HOME/log4j.properties" maven
> In the process, I discovered that when the level for
> org.apache.commons.jelly.tags.ant.AntTag is set to DEBUG, maven yields this
> error:
> File.. ${1}
> Element... ant:fileset
> Line.. 49
> Column 45
> No directory specified for fileset.
> When logging for that class is at INFO level, this error does not occur.
> This happens on the "java:compile" goal of even the simplest project. I can
> attach full exception info, the project I used, and the log4j config file I
> used if desired.
> I'd like to figure out what jelly file this occurred in. The file "${1}" is
> not too helpful, though.
--
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: (MPIDEA-47) Unnecessary request for version number in dependencyManagement section
Unnecessary request for version number in dependencyManagement section -- Key: MPIDEA-47 URL: http://jira.codehaus.org/browse/MPIDEA-47 Project: maven-idea-plugin Issue Type: Bug Affects Versions: 1.7 Reporter: Sébastien Arbogast I have a root POM with a dependencyManagement section that specifies all the version numbers for dependencies. And in an "app" module below, I have another POM where the dependencyManagement section is used to specify dependency exclusions, but none of these dependencies specify a version number as it's supposed to be inherited from the parent (root) POM dependencyManagement section. Yet, when I try to run "mvn idea:idea" on the root project, I get a build failure in the "app" module saying that the version for the dependencies cannot be null. The thing is that it CAN be null: that's what dependencyManagement inheritance is made for. The best proof of that is that "mvn install" on the whole project runs fine. I added version numbers to those dependencies and it fixed the issue, but I shouldn't have to repeat them since they are already specified in the root POM's dependencyManagement section. Moreover, I'm using a project generator (AndroMDA) that generates all the POM's for me and it doesn't include version numbers at this level. I hope I was clear enough :oP -- 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] Moved: (MIDEA-65) Unnecessary request for version number in dependencyManagement section
[ http://jira.codehaus.org/browse/MIDEA-65?page=all ] Lukas Theussl moved MPIDEA-47 to MIDEA-65: -- Affects Version/s: (was: 1.7) Workflow: Maven New (was: jira) Key: MIDEA-65 (was: MPIDEA-47) Project: Maven 2.x Idea Plugin (was: maven-idea-plugin) > Unnecessary request for version number in dependencyManagement section > -- > > Key: MIDEA-65 > URL: http://jira.codehaus.org/browse/MIDEA-65 > Project: Maven 2.x Idea Plugin > Issue Type: Bug >Reporter: Sébastien Arbogast > > I have a root POM with a dependencyManagement section that specifies all the > version numbers for dependencies. And in an "app" module below, I have > another POM where the dependencyManagement section is used to specify > dependency exclusions, but none of these dependencies specify a version > number as it's supposed to be inherited from the parent (root) POM > dependencyManagement section. > Yet, when I try to run "mvn idea:idea" on the root project, I get a build > failure in the "app" module saying that the version for the dependencies > cannot be null. The thing is that it CAN be null: that's what > dependencyManagement inheritance is made for. The best proof of that is that > "mvn install" on the whole project runs fine. > I added version numbers to those dependencies and it fixed the issue, but I > shouldn't have to repeat them since they are already specified in the root > POM's dependencyManagement section. Moreover, I'm using a project generator > (AndroMDA) that generates all the POM's for me and it doesn't include version > numbers at this level. > I hope I was clear enough :oP -- 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: (CONTINUUM-828) Project group error adding project
Project group error adding project -- Key: CONTINUUM-828 URL: http://jira.codehaus.org/browse/CONTINUUM-828 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1 Environment: acegi branch Reporter: Carlos Sanchez I got this exception trying to add maven skins pom http://svn.apache.org/viewvc/maven/skins/trunk/pom.xml?view=co [INFO] 0 errors. [INFO] Creating project group with the group id: 'org.apache.maven.skins'. 16:35:13,562 WARN JPOX.RDBMS.SQL [org.jpox.store.rdbms.request.FetchRequest] Object with id "0" not found ! [INFO] Error ocurred during execution org.apache.maven.continuum.ContinuumException: Unable to find the requested project at org.apache.maven.continuum.DefaultContinuum.getProjectsInGroup_aroundBody196(DefaultContinuum.java:2473) at org.apache.maven.continuum.DefaultContinuum$AjcClosure197.run(DefaultContinuum.java:1) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect$1.proceedWithObject(SecurityAspect.aj:59) at org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor.invoke(AspectJSecurityInterceptor.java:67) at org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:62) at org.apache.maven.continuum.DefaultContinuum.getProjectsInGroup(DefaultContinuum.java:1) at org.apache.maven.continuum.web.action.SummaryAction.execute(SummaryAction.java:55) 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:585) at com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:365) at com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:217) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:191) at com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:137) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:81) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) at com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:81) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:171) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) at com.opensymphony.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:100) at com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189)
[jira] Updated: (CONTINUUM-828) Project group error adding project
[ http://jira.codehaus.org/browse/CONTINUUM-828?page=all ] Carlos Sanchez updated CONTINUUM-828: - Assignee: Jesse McConnell Fix Version/s: 1.1 I get the error page but everything continues fine, and I see the group in the show groups page later > Project group error adding project > -- > > Key: CONTINUUM-828 > URL: http://jira.codehaus.org/browse/CONTINUUM-828 > Project: Continuum > Issue Type: Bug > Components: Core system >Affects Versions: 1.1 > Environment: acegi branch >Reporter: Carlos Sanchez > Assigned To: Jesse McConnell > Fix For: 1.1 > > > I got this exception trying to add maven skins pom > http://svn.apache.org/viewvc/maven/skins/trunk/pom.xml?view=co > [INFO] 0 errors. > [INFO] Creating project group with the group id: 'org.apache.maven.skins'. > 16:35:13,562 WARN JPOX.RDBMS.SQL > [org.jpox.store.rdbms.request.FetchRequest] Object with id "0" not found ! > [INFO] Error ocurred during execution > org.apache.maven.continuum.ContinuumException: Unable to find the requested > project > at > org.apache.maven.continuum.DefaultContinuum.getProjectsInGroup_aroundBody196(DefaultContinuum.java:2473) > at > org.apache.maven.continuum.DefaultContinuum$AjcClosure197.run(DefaultContinuum.java:1) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0cproceed(SecurityAspect.aj) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect$1.proceedWithObject(SecurityAspect.aj:59) > at > org.acegisecurity.intercept.method.aspectj.AspectJSecurityInterceptor.invoke(AspectJSecurityInterceptor.java:67) > at > org.codehaus.plexus.acegi.intercept.method.aspectj.SecurityAspect.ajc$around$org_codehaus_plexus_acegi_intercept_method_aspectj_SecurityAspect$1$6563cc0c(SecurityAspect.aj:62) > at > org.apache.maven.continuum.DefaultContinuum.getProjectsInGroup(DefaultContinuum.java:1) > at > org.apache.maven.continuum.web.action.SummaryAction.execute(SummaryAction.java:55) > 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:585) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:365) > at > com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:217) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:191) > at > com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:137) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:81) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115) > at > com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:81) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:171) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31) > at > com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:189) > at > com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.j
[jira] Created: (MAVEN-1783) Creating one jar for source code in a multiproject using maven.source.plugin
Creating one jar for source code in a multiproject using maven.source.plugin Key: MAVEN-1783 URL: http://jira.codehaus.org/browse/MAVEN-1783 Project: Maven Issue Type: Task Components: model additions Affects Versions: 1.0.2 Environment: sun solaris.. using maven.source.plugin-1.0.jar Reporter: Baher Omar Priority: Minor I'm trying to create one jar for all source code in a multiproject system.. The current impl of maven.source.plugin, only produces one source jar for each project.. I'd like to combine all these jars into only one jar.. I think the same thing could also apply to the actual jars produced from all projects, how can you make one jar of all the compiled classes?! For example, the whole java source code is used distributed in one zipped file (src.zip). Also I noticed some companies (i.e. maverick), they have one jar for a specific feature (i.e. maverick-ssh2.jar, maverick-ssh1.jar, maverick-sftp.jar, ...) and one jar for the whole thing (maverick-all.jar) Thanks.. bo -- 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] Moved: (MPSOURCE-3) Creating one jar for source code in a multiproject using maven.source.plugin
[ http://jira.codehaus.org/browse/MPSOURCE-3?page=all ] Lukas Theussl moved MAVEN-1783 to MPSOURCE-3: - Affects Version/s: (was: 1.0.2) 1.0 Component/s: (was: model additions) Workflow: jira (was: Maven New) Issue Type: Wish (was: Task) Key: MPSOURCE-3 (was: MAVEN-1783) Project: maven-source-plugin (was: Maven) > Creating one jar for source code in a multiproject using maven.source.plugin > > > Key: MPSOURCE-3 > URL: http://jira.codehaus.org/browse/MPSOURCE-3 > Project: maven-source-plugin > Issue Type: Wish >Affects Versions: 1.0 > Environment: sun solaris.. using maven.source.plugin-1.0.jar >Reporter: Baher Omar >Priority: Minor > Original Estimate: 1 day > Remaining Estimate: 1 day > > I'm trying to create one jar for all source code in a multiproject system.. > The current impl of maven.source.plugin, only produces one source jar for > each project.. > I'd like to combine all these jars into only one jar.. > I think the same thing could also apply to the actual jars produced from all > projects, how can you make one jar of all the compiled classes?! > For example, the whole java source code is used distributed in one zipped > file (src.zip). > Also I noticed some companies (i.e. maverick), they have one jar for a > specific feature (i.e. maverick-ssh2.jar, maverick-ssh1.jar, > maverick-sftp.jar, ...) and one jar for the whole thing (maverick-all.jar) > Thanks.. > bo -- 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: (MECLIPSE-151) Incorrect name for test sources jars
Incorrect name for test sources jars Key: MECLIPSE-151 URL: http://jira.codehaus.org/browse/MECLIPSE-151 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Richard van der Hoff The eclipse plugin currently sets the source attachment of dependencies on test-jars (as created by the test-jar goal of the jar plugin) to the same as that of the main jar. To fix, we need to check the classifier of dependencies when finding sources, and if it is "tests", use "test-sources" rather than "sources" for the classifier on the sources jar. -- 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: (CONTINUUM-825) make AclInitializer read SQL statements from classpath
[ http://jira.codehaus.org/browse/CONTINUUM-825?page=all ] Carlos Sanchez closed CONTINUUM-825. Resolution: Fixed > make AclInitializer read SQL statements from classpath > -- > > Key: CONTINUUM-825 > URL: http://jira.codehaus.org/browse/CONTINUUM-825 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez > Fix For: 1.1 > > Attachments: CONTINUUM-825-2.patch, CONTINUUM-825.patch > > > AclInitializer in continuum-acegi-security reads and executes SQL from a file. > To make it work in the webapp needs to read from classpath. -- 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-2524) DefaultArtifactFactory.createDependencyArtifact sets scope to null
DefaultArtifactFactory.createDependencyArtifact sets scope to null
--
Key: MNG-2524
URL: http://jira.codehaus.org/browse/MNG-2524
Project: Maven 2
Issue Type: Bug
Components: Artifacts
Affects Versions: 2.0.4
Reporter: Adrian Sox
Priority: Trivial
There are four createDependencyArtifact methods in DefaultArtifactFactory, all
of which take scope as an argument. One of the four fails to pass the scope
into the createArtifact method.
Specifically,
public Artifact createDependencyArtifact( String groupId, String
artifactId, VersionRange versionRange, String type,
String classifier, String scope )
{
return createArtifact( groupId, artifactId, versionRange, type,
classifier, null, null );
}
should be
public Artifact createDependencyArtifact( String groupId, String
artifactId, VersionRange versionRange, String type,
String classifier, String scope )
{
return createArtifact( groupId, artifactId, versionRange, type,
classifier, scope, null );
}
--
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: (CONTINUUM-822) Create acegi acl tables on database creation
[ http://jira.codehaus.org/browse/CONTINUUM-822?page=all ] Carlos Sanchez closed CONTINUUM-822. Resolution: Fixed > Create acegi acl tables on database creation > > > Key: CONTINUUM-822 > URL: http://jira.codehaus.org/browse/CONTINUUM-822 > Project: Continuum > Issue Type: Sub-task > Components: Web interface >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez > Fix For: 1.1 > > Attachments: CONTINUUM-822.patch > > > The SQL script is in continuum-security-acegi > src/main/resources > org.apache.maven.continuum.security.acegi.acl.acegi-acl-derby.sql > This needs to be run against the db when the database is created. I think > there's a sql plugin for maven somewhere. -- 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: (CONTINUUM-802) Use fine grained permissions per project group
[ http://jira.codehaus.org/browse/CONTINUUM-802?page=all ] Carlos Sanchez updated CONTINUUM-802: - Summary: Use fine grained permissions per project group (was: Use fine grained permissions per project) Added filtering to resoults of getAllProjectGroupsWithProjects, need to check if other operations need them too > Use fine grained permissions per project group > -- > > Key: CONTINUUM-802 > URL: http://jira.codehaus.org/browse/CONTINUUM-802 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez > -- 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: (MWAR-57) Unable to add custom manifest entries to war file via the pom.xml
[ http://jira.codehaus.org/browse/MWAR-57?page=all ]
Brett Porter closed MWAR-57.
Assignee: Brett Porter
Resolution: Fixed
> Unable to add custom manifest entries to war file via the pom.xml
> -
>
> Key: MWAR-57
> URL: http://jira.codehaus.org/browse/MWAR-57
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
> Environment: Windows XP SP2
> Sun JDK 1.5.0_07
> Maven 2.0.4
>Reporter: Mark Reynolds
> Assigned To: Brett Porter
> Fix For: 2.0.2
>
>
> Configure custom manifest entries as in
> http://maven.apache.org/guides/mini/guide-manifest.html:
>
> maven-war-plugin
> 2.0.1
>
>
>
> development
> ${pom.url}
>
>
>
>
> Get error in build:
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error assembling WAR
> Embedded error: The attribute "mode" may not occur more than once in the same
> section
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling WAR
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:475)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:454)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:306)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:273)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:256)
> 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:585)
> 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: org.apache.maven.plugin.MojoExecutionException: Error assembling
> WAR
> at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:135)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> ... 16 more
> Caused by: org.codehaus.plexus.archiver.jar.ManifestException: The attribute
> "mode" may not occur more than once in the same section
> at
> org.codehaus.plexus.archiver.jar.Manifest$Section.addAttributeAndCheck(Manifest.java:727)
> at
> org.codehaus.plexus.archiver.jar.Manifest$Section.addConfiguredAttribute(Manifest.java:658)
> at
> org.codehaus.plexus.archiver.jar.Manifest.addConfiguredAttribute(Manifest.java:1000)
> at
> org.apache.maven.archiver.MavenArchiver.createArchive(MavenArchiver.java:354)
> at
> org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:177)
> at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:127)
> ... 18 more
> The same duplicate attribute exception occurs regardless of the name of the
> manifest entry.
> Works OK in 2.0.
--
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: (CONTINUUM-397) try building a project without setting an build definition show uncatched java exception
[ http://jira.codehaus.org/browse/CONTINUUM-397?page=all ] Jesse McConnell closed CONTINUUM-397. - Assignee: Jesse McConnell Resolution: Fixed this shouldn't be possible on trunk anymore since project group's have default build definitions that should always be available > try building a project without setting an build definition show uncatched > java exception > > > Key: CONTINUUM-397 > URL: http://jira.codehaus.org/browse/CONTINUUM-397 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.0 > Environment: Mac os x >Reporter: yo > Assigned To: Jesse McConnell > Fix For: 1.1 > > > try building a project without setting an build definition show uncatched > java exception > ognl.MethodFailedException: Method "buildProject" failed for object [EMAIL > PROTECTED] [org.apache.maven.continuum.ContinuumException: Project requires a > build definition.] > at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:796) > at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) > at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) > at ognl.ASTMethod.getValueBody(ASTMethod.java:75) > at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) > at ognl.SimpleNode.getValue(SimpleNode.java:210) > at ognl.Ognl.getValue(Ognl.java:333) > at ognl.Ognl.getValue(Ognl.java:378) > at ognl.Ognl.getValue(Ognl.java:357) > at > org.apache.maven.continuum.web.action.CallApplicationModel.execute(CallApplicationModel.java:72) > at > org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) > at > org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) > at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:595) > at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) > at > org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) > at > org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) > at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) > at org.mortbay.http.HttpServer.service(HttpServer.java:879) > at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) > at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) > at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) > at > org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) > at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) > at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) > /-- Encapsulated exception \ > org.apache.maven.continuum.ContinuumException: Project requires a build > definition. > at > org.apache.maven.continuum.DefaultContinuum.getDefaultBuildDefinition(DefaultContinuum.java:804) > at > org.apache.maven.continuum.DefaultContinuum.buildProject(DefaultContinuum.java:319) > 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:324) > at ognl.OgnlRuntime.invokeMethod(OgnlRuntime.java:491) > at ognl.OgnlRuntime.callAppropriateMethod(OgnlRuntime.java:785) > at ognl.ObjectMethodAccessor.callMethod(ObjectMethodAccessor.java:61) > at ognl.OgnlRuntime.callMethod(OgnlRuntime.java:819) > at ognl.ASTMethod.getValueBody(ASTMethod.java:75) > at ognl.SimpleNode.evaluateGetValueBody(SimpleNode.java:170) > at ognl.SimpleNode.getValue(SimpleNode.java:210) > at ognl.Ognl.getValue(Ognl.java:333) > at ognl.Ognl.getValue(Ognl.java:378) > at ognl.Ognl.getValue(Ognl.java:357) > at > org.apache.maven.continuum.web.action.CallApplicationModel.execute(CallApplicationModel.java:72) > at > org.codehaus.plexus.summit.pipeline.valve.ActionValve.invoke(ActionValve.java:68) > at > org.codehaus.plexus.summit.pipeline.AbstractPipeline.invoke(AbstractPipeline.java:70) > at org.codehaus.plexus.summit.Summit.doGet(Summit.java:54) > at javax.servle
[jira] Closed: (MCLEAN-18) Maven 2.x Clean Plugin does not comply with maven's codestyle
[ http://jira.codehaus.org/browse/MCLEAN-18?page=all ] Brett Porter closed MCLEAN-18. -- Assignee: Brett Porter Resolution: Fixed Fix Version/s: 2.1.1 applied, thanks > Maven 2.x Clean Plugin does not comply with maven's codestyle > - > > Key: MCLEAN-18 > URL: http://jira.codehaus.org/browse/MCLEAN-18 > Project: Maven 2.x Clean Plugin > Issue Type: Improvement >Reporter: Franz Allan Valencia See > Assigned To: Brett Porter >Priority: Trivial > Fix For: 2.1.1 > > Attachments: MCLEAN-18-maven-clean-plugin.patch, > MCLEAN18-maven-clean-plugin-2.patch > > > Maven 2.x Clean Plugin does not comply with maven's codestyle > According to maven-checkstyle-plugin, maven-clean-plugin has > 1 Info > 8 Warnings > 1 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] Closed: (MSUREFIRE-110) JUnit test case fails with Maven 2 when looking up an Object in the JBoss using JNDI
[ http://jira.codehaus.org/browse/MSUREFIRE-110?page=all ]
Brett Porter closed MSUREFIRE-110.
--
Assignee: Brett Porter
Resolution: Duplicate
dupe o MSUREFIRE-148
> JUnit test case fails with Maven 2 when looking up an Object in the JBoss
> using JNDI
>
>
> Key: MSUREFIRE-110
> URL: http://jira.codehaus.org/browse/MSUREFIRE-110
> Project: Maven 2.x Surefire Plugin
> Issue Type: Bug
> Environment: JBoss 4.0.1
> JDK 1.5
>Reporter: Snehal Maniar
> Assigned To: Brett Porter
>Priority: Critical
> Attachments: booter-url-patch.txt
>
>
> For a sample JUnit test case trying to lookup an Object in the JBoss registry
> using JNDI as shown below
> import java.util.Properties;
> import javax.naming.Context;
> import javax.naming.InitialContext;
> import junit.framework.TestCase;
> public class TestJBossJNDI extends TestCase {
> public void testBindingCtx() throws Exception {
> Properties p = new Properties();
> p.setProperty(Context.INITIAL_CONTEXT_FACTORY,
> "org.jnp.interfaces.NamingContextFactory");
> p.setProperty(Context.URL_PKG_PREFIXES,
> "org.jboss.naming:org.jnp.interfaces");
> p.setProperty(Context.PROVIDER_URL, "jnp://sdv01:1399");
> try {
> InitialContext ctx = new InitialContext(p);
> Object o = ctx.lookup("ConnectionFactory");
> System.out.println("Found Object = " +
> o.getClass().getName());
> } catch (Exception e) {
> e.printStackTrace();
> fail();
> }
> }
> }
> I get following exception/error
> [INFO]
>
> [INFO] Building Unnamed - middleware:TestMVN:jar:0.0.1
> [INFO]task-segment: [test]
> [INFO]
>
> [INFO] resources:resources
> [INFO] Using default encoding to copy filtered resources.
> [INFO] compiler:compile
> [INFO] Nothing to compile - all classes are up to date
> [INFO] resources:testResources
> [INFO] Using default encoding to copy filtered resources.
> [INFO] compiler:testCompile
> Compiling 1 source file to
> C:\dev_corner\eclipse\workspaceII\TestMVN\target\test-classes
> [INFO] surefire:test
> [INFO] Setting reports dir:
> C:\dev_corner\eclipse\workspaceII\TestMVN\target/surefire-reports
> ---
> T E S T S
> ---
> javax.naming.CommunicationException [Root exception is
> java.rmi.ServerException: RemoteException occurred in server thread; nested
> exception is:
> java.rmi.UnmarshalException: error unmarshalling arguments; nested
> exception is:
> java.net.MalformedURLException: no protocol: and]
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:663)
> at org.jnp.interfaces.NamingContext.lookup(NamingContext.java:520)
> at javax.naming.InitialContext.lookup(InitialContext.java:351)
> at TestJBossJNDI.testBindingCtx(TestJBossJNDI.java:21)
> 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:585)
> at junit.framework.TestCase.runTest(TestCase.java:154)
> at junit.framework.TestCase.runBare(TestCase.java:127)
> at junit.framework.TestResult$1.protect(TestResult.java:106)
> at junit.framework.TestResult.runProtected(TestResult.java:124)
> at junit.framework.TestResult.run(TestResult.java:109)
> at junit.framework.TestCase.run(TestCase.java:118)
> at junit.framework.TestSuite.runTest(TestSuite.java:208)
> at junit.framework.TestSuite.run(TestSuite.java:203)
> 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:585)
> at
> org.apache.maven.surefire.battery.JUnitBattery.executeJUnit(JUnitBattery.java:230)
> at
> org.apache.maven.surefire.battery.JUnitBattery.execute(JUnitBattery.java:204)
> at org.apache.maven.surefire.Surefire.executeBattery(Surefire.java:217)
> at org.apache.maven.surefire.Surefire.run(Surefire.java:165)
> at org.apache.maven.surefire.Surefire.run(Surefir
[jira] Created: (MNG-2525) SNAPSHOT dependencies aren't found when repository has 'release' disabled and a version range is used
SNAPSHOT dependencies aren't found when repository has 'release' disabled and a version range is used - Key: MNG-2525 URL: http://jira.codehaus.org/browse/MNG-2525 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: Windows XP, Sun JDK 5.0 Update 7 Reporter: Nathan Beyer (Apache) Priority: Critical When a repository is configured (POM, profiles, etc), 'releases' is disabled, 'snapshots' is enabled and a dependency uses a version range, the dependency fails to resolve. The dependency is found when an explicit version is used. The following can be used to recreate the issue. Setup the maven snapshot repository in an active profile like this: apache.snapshots Maven Snapshots http://people.apache.org/maven-snapshot-repository false true Check out the maven-install-plugin at revision 427494 (or any revision or other plugin that has a dependency that's a SNAPSHOT). Run a build (mvn package) and all dependencies should download. Modify the dependency in the POM to use a version range, instead of an explict version. For example, change the version "1.0-SNAPSHOT" to "[0,1)", which includes the same version. Run another build (mvn package) and the dependency will fail to download. -- 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-2525) SNAPSHOT dependencies aren't found when repository has 'release' disabled and a version range is used
[ http://jira.codehaus.org/browse/MNG-2525?page=comments#action_73073 ] Brett Porter commented on MNG-2525: --- I'm sure that this has been filed elsewhere - would be worth checking for dupes. > SNAPSHOT dependencies aren't found when repository has 'release' disabled and > a version range is used > - > > Key: MNG-2525 > URL: http://jira.codehaus.org/browse/MNG-2525 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 > Environment: Windows XP, Sun JDK 5.0 Update 7 >Reporter: Nathan Beyer (Apache) >Priority: Critical > > When a repository is configured (POM, profiles, etc), 'releases' is disabled, > 'snapshots' is enabled and a dependency uses a version range, the dependency > fails to resolve. The dependency is found when an explicit version is used. > The following can be used to recreate the issue. > Setup the maven snapshot repository in an active profile like this: > > apache.snapshots > Maven Snapshots > http://people.apache.org/maven-snapshot-repository > > false > > > true > > > Check out the maven-install-plugin at revision 427494 (or any revision or > other plugin that has a dependency that's a SNAPSHOT). Run a build (mvn > package) and all dependencies should download. Modify the dependency in the > POM to use a version range, instead of an explict version. For example, > change the version "1.0-SNAPSHOT" to "[0,1)", which includes the same > version. Run another build (mvn package) and the dependency will fail to > download. -- 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-2525) SNAPSHOT dependencies aren't found when repository has 'release' disabled and a version range is used
[ http://jira.codehaus.org/browse/MNG-2525?page=comments#action_73075 ] Nathan Beyer (Apache) commented on MNG-2525: I scanned and searched the issues under "Dependencies" and didn't find anything that seemed similar. I'll do another search and see if I find something. > SNAPSHOT dependencies aren't found when repository has 'release' disabled and > a version range is used > - > > Key: MNG-2525 > URL: http://jira.codehaus.org/browse/MNG-2525 > Project: Maven 2 > Issue Type: Bug > Components: Dependencies >Affects Versions: 2.0.4 > Environment: Windows XP, Sun JDK 5.0 Update 7 >Reporter: Nathan Beyer (Apache) >Priority: Critical > > When a repository is configured (POM, profiles, etc), 'releases' is disabled, > 'snapshots' is enabled and a dependency uses a version range, the dependency > fails to resolve. The dependency is found when an explicit version is used. > The following can be used to recreate the issue. > Setup the maven snapshot repository in an active profile like this: > > apache.snapshots > Maven Snapshots > http://people.apache.org/maven-snapshot-repository > > false > > > true > > > Check out the maven-install-plugin at revision 427494 (or any revision or > other plugin that has a dependency that's a SNAPSHOT). Run a build (mvn > package) and all dependencies should download. Modify the dependency in the > POM to use a version range, instead of an explict version. For example, > change the version "1.0-SNAPSHOT" to "[0,1)", which includes the same > version. Run another build (mvn package) and the dependency will fail to > download. -- 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-2526) Getting started sample fails several times, then it works suddenly
Getting started sample fails several times, then it works suddenly -- Key: MNG-2526 URL: http://jira.codehaus.org/browse/MNG-2526 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0.4 Environment: Windows XP SP2, local firewall enabled (Windows defaults) Maven 2.0.4 ANT 1.6.5 Sun JDK 1.5.0_08 Company Firewall, opened for HTTP and FTP and some more ports Reporter: Markus KARG When I am trying to follow the samples in the getting started guide, the mvn command will fail two times, but succeed on the third time. Certainly there is no bug in the mvn software, but the problem is the overloaded main repository servers I think. But nevertheless, beginners will have problems with that, also automated processes will crash. So this should be fixed ASAP. Here is the log: Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Dokumente und Einstellungen\Karg>mvn -version Maven version: 2.0.4 C:\Dokumente und Einstellungen\Karg>mvn archetype:create -DgroupId=de.quipsy.fool -DartifactId=TheFoolApp [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] org.apache.maven.plugins: checking for updates from central [INFO] org.codehaus.mojo: checking for updates from central [INFO] artifact org.apache.maven.plugins:maven-archetype-plugin: checking for updates from central Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/1.0-alpha-4/maven-archetype-plugin-1.0-alpha-4.pom 1K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype/1.0-alpha-4/maven-archetype-1.0-alpha-4.pom 2K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'eb9e286b16844e1c5f8f38a9ddd7ee266985c8f6'; remote = '2f4311799239ce76c6c1386bee04988f579d2 6b7' - RETRYING Downloading: http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype/1.0-alpha-4/maven-archetype-1.0-alpha-4.pom 2K downloaded [WARNING] *** CHECKSUM FAILED - Checksum failed on download: local = 'eb9e286b16844e1c5f8f38a9ddd7ee266985c8f6'; remote = '2f4311799239ce76c6c1386bee04988f579d2 6b7' - IGNORING Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-parent/1/maven-parent-1.pom 6K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/apache/1/apache-1.pom 3K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/1.0-alpha-4/maven-archetype-plugin-1.0-alpha-4.jar 9K downloaded [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [archetype:create] (aggregator-style) [INFO] Downloading: http://repo1.maven.org/maven2/org/apache/maven/archetype/maven-archetype-core/1.0-alpha-4/maven-archetype-core-1.0-alpha-4.pom 1K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven-model/2.0/maven-model-2.0.pom 2K downloaded Downloading: http://repo1.maven.org/maven2/org/apache/maven/maven/2.0/maven-2.0.pom 8K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-utils/1.0.4/plexus-utils-1.0.4.pom 6K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-container-default/1.0-alpha-9/plexus-container-default-1.0-alpha-9.pom 1K downloaded Downloading: http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-containers/1.0.3/plexus-containers-1.0.3.pom 492b downloaded [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Error building POM (may not be this project's POM). Project ID: null:plexus-container-default:jar:1.0-alpha-9 Reason: Cannot find parent: org.codehaus.plexus:plexus-containers for project: null:plexus-container-default:jar:1.0-alpha-9 [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 8 seconds [INFO] Finished at: Wed Aug 23 08:01:14 CEST 2006 [INFO] Final Memory: 1M/3M [INFO] C:\Dokumente und Einstellungen\Karg>mvn archetype:create -DgroupId=de.quipsy.fool -DartifactId=TheFoolApp [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'archetype'. [INFO] [INFO] Building Maven Default Project [INFO]task-segment: [archetype:create] (aggregator-style) [INFO] ---
[jira] Commented: (MECLIPSE-76) Projects containing war's as dependency will not include war-reference
[ http://jira.codehaus.org/browse/MECLIPSE-76?page=comments#action_73082 ]
Tom Spengler commented on MECLIPSE-76:
--
I agree, if you wish to develop one war you are right.
but we develop not one war but exploded ear's with containing 10 war's
and now you have 50 ejb-jar's and 10 war's.
the point ist, that it must be possible to debug a ear containig more than war.
ps: The packaging is not the problem.
> Projects containing war's as dependency will not include war-reference
> --
>
> Key: MECLIPSE-76
> URL: http://jira.codehaus.org/browse/MECLIPSE-76
> Project: Maven 2.x Eclipse Plugin
> Issue Type: Bug
> Components: WTP support
>Reporter: Tom Spengler
>
> if you have a dependency like
>
> j-core
> j-core-webapp-axx
> 0.0.1
> war
>
> it will not included int .classpath
> Resolution could be
> EclipseClasspathWriter
> --old--
> Artifact artifact = (Artifact) it.next();
> if ( artifact.getArtifactHandler().isAddedToClasspath() )
> --new --
> Artifact artifact = (Artifact) it.next();
> if ( artifact.getArtifactHandler().isAddedToClasspath()
> ||artifact.getArtifactHandler().isIncludesDependencies() )
>
> and
> EclipsePlugin.prepareArtifacts()
> --old--
> Collection artifacts = project.getTestArtifacts();
> --new--
> Collection artifacts = project.getTestArtifacts();
> Set artifact_2 = project.getArtifacts();
> for (Iterator at = artifact_2.iterator(); at.hasNext();){
> Artifact arti = (Artifact) at.next();
> if (! artifacts.contains(arti))
> artifacts.add(arti);
> }
--
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: (WAGON-61) Wagon File provider doesn't check basedir for existence on connect
Wagon File provider doesn't check basedir for existence on connect -- Key: WAGON-61 URL: http://jira.codehaus.org/browse/WAGON-61 Project: wagon Issue Type: Improvement Components: wagon-file Affects Versions: 1.0-beta-1 Environment: Used in Archiva for "file://" repository proxying Reporter: nicolas de loof Priority: Trivial Attachments: patch.patch The openConnection() in FileWagon does not check the repository baseDir. If the file URL points to an unexisting or read-protected path, it may throw a ConnectionException. Attached patch adds exists and canRead checks for repository baseDir. -- 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
