[jira] Commented: (MNGECLIPSE-189) JUnit runner does not process resource filters before running
[ http://jira.codehaus.org/browse/MNGECLIPSE-189?page=comments#action_77000
]
Walco van Loon commented on MNGECLIPSE-189:
---
Eugene: I'm a bit surprised by your POV. Resource filtering is a base Maven
feature. The fact that it's not supported by m2eclipse leads to environmental
differences between maven and eclipse - I thought that eliminating that gap is
all m2eclipse is about. Why would keeping resources in sync any different than
keeping the classpath in sync?
> JUnit runner does not process resource filters before running
> -
>
> Key: MNGECLIPSE-189
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-189
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
>Affects Versions: 0.0.9
> Environment: Eclipse 3.1.2 Linux
>Reporter: Jonathan Share
> Assigned To: Eugene Kuleshov
>Priority: Trivial
> Attachments: filter-test.zip
>
>
> I have a project that uses a resource filter to set the path to some files
> depending on what platform the developer is on. Using maven on the command
> line this is processed correctly and the Unit tests pass. However, I wish to
> use the JUnit runner within eclipse however as my resources do not get
> filtered before the tests try to load them I get exceptions creating URL
> objects with ${news.image.url} in them.
> Desired behaviour
> ===
> This plugin should provide a launcher for the junit runner that first runs
> the process-resources (apologies if this is wrong, writing from memory here)
> target and ensure the classpath is configured correctly so that the non
> processed resources are not available to the JUnit runner before running the
> JUnit tests.
--
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-156) Plugin should support setting file encoding
[ http://jira.codehaus.org/browse/MECLIPSE-156?page=comments#action_77002 ] Kenney Westerhof commented on MECLIPSE-156: --- Ok, option 3 is still a go. In the mean time the workaround is option 1. Option 2 already works for me (Linux Debian). i think that if you set your locale to en_US.UTF-8 (or another UTF-8 enabled charset) then eclipse automatically uses UTF-8. I usually have to spend 15 minutes to set up any new workspace - code formatters, code templates, and other plugin configurations. It would be nice if you could specify a workspace-template in eclipse with default settings, though. Thanks for the information! > Plugin should support setting file encoding > --- > > Key: MECLIPSE-156 > URL: http://jira.codehaus.org/browse/MECLIPSE-156 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: Ralph Poellath > > The plugin should support setting Eclipse's text file encoding on a > per-project basis. -- 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: (MNGECLIPSE-189) JUnit runner does not process resource filters before running
[ http://jira.codehaus.org/browse/MNGECLIPSE-189?page=comments#action_77003
]
Kenney Westerhof commented on MNGECLIPSE-189:
-
I agree - resources should be filtered. Aren't resources automatically copied
after modification (i.e. running the process-resources phase), using filtering
if enabled in the pom?
I thought the m2eclipse plugin keeps the target/ up-to-date continuously, like
eclipse itself does.
If it doesn't, then adding a pre-goal to JUnit that depends on the phase before
'test' (however that's done in eclipse) would be nice..?
> JUnit runner does not process resource filters before running
> -
>
> Key: MNGECLIPSE-189
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-189
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
>Affects Versions: 0.0.9
> Environment: Eclipse 3.1.2 Linux
>Reporter: Jonathan Share
> Assigned To: Eugene Kuleshov
>Priority: Trivial
> Attachments: filter-test.zip
>
>
> I have a project that uses a resource filter to set the path to some files
> depending on what platform the developer is on. Using maven on the command
> line this is processed correctly and the Unit tests pass. However, I wish to
> use the JUnit runner within eclipse however as my resources do not get
> filtered before the tests try to load them I get exceptions creating URL
> objects with ${news.image.url} in them.
> Desired behaviour
> ===
> This plugin should provide a launcher for the junit runner that first runs
> the process-resources (apologies if this is wrong, writing from memory here)
> target and ensure the classpath is configured correctly so that the non
> processed resources are not available to the JUnit runner before running the
> JUnit tests.
--
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-120) Force inter-project dependencies
[ http://jira.codehaus.org/browse/MECLIPSE-120?page=comments#action_77004 ]
Joerg Schaible commented on MECLIPSE-120:
-
bq. Your first problem is another issue (MECLIPSE-152), that I'd like to see
solved there. Forcing snapshot versions only fixes that problem in certain
situations.
IMHO this is strongly related to MNG-1245 (just another issue that starts to
embarass me, since it is fixed for months and 2.0.5 seems not going to happen
anwhere in near time - just a different story)
bq. But you actually mean -forceProjectReference here, right?
Yep.
bq. Second issue: I see that as a good thing - you'll find out soon enough
which artifacts are affected by a change since you can't change them because
they reference jar files, not projects.
?? If your project refer jars, then they are not affected by a refactoring.
This is the point! If you have a central jar with APIs and you change it, none
of the other projects are affected at all. Even worse - Eclipse does not
detect, that some of those are affected. Now the developer has to guess.
bq. Also, when you do a lot of refactoring etc, I get the impression you don't
have multiple release cycles, but just 1, for the entire project tree. If
that's the case, you could use a dependencyManagement section in the root pom,
specifying ${version} for all modules. That way they're always referring to
reactor/workspace projects. This should fix your issue, no?
No. A lot of our ~100 artifacts have an own release cycles and this for good
reason. Nevertheless sometimes you have to refactor something. It's like
changing commons-logging, but with the fortune to get an impression by the
impact a change will have.
bq. Third issue: this is fixing it afterwards, and hoping that the developer
will indeed update the poms. As I mentioned above, if you still have jar
references and not project references, you're forced to update the pom at that
time, or decide not to since it's an unwanted change. Isn't that safer?
Developers are confronted with making a good decision on what to upgrade and
what for.
So you say it is better to run into the problems, when you are actually
building the release? Sorry, *then* you're normally under time constraints and
it is really no fun to sort things out at that level.
bq. What I meant with my third comment is that you see stuff working in
eclipse, but it won't compile on the commandline. That gives the developer
another responsibility - mvn install before a commit, and update the poms. It's
an iterative process and requires more time on big projects. Just updating a
pom and mvn eclipse:eclipse, then refresh in eclipse gives you much faster
feedback on wheter it still works.
Exaclty. It *is* the developers responsibility. The difference to the situation
now is that he actually has a chance to be responsible. And as I said, this is
optional and not the default working mode of the Eclipse plugin. And currently
the situation is even worse, since of MNG-1245 Eclipse *is* using the SNAPSHOT
to compile when invoked from the command line ignoring the POM defining a
released version. Therefore the generated Eclipse projects are often broken
anyway. Currently it took me quite a complete day to get this into sync again
by adding depednencyManagement sections to the POMs that affect the Eclipse
plugin's project generation (and I don't blame the Eclipse plugin here - there
are too may bugs in the reelase core, but the complete situation starts to get
unmanagable).
bg. On the EAR thing: shouldn't that be solved in the dependencyManagement
section? That way it'll work both for eclipse and on the commandline.
No, it won't. We already use a company wide POM with dependencyManagement
section. But if you release an EJB it will refer a special version of it as
parent. Releasing another EJB might refer another parent. Now a project P wants
to build an EAR of those two EJBs and it simply does not work. EJB1 is
depending on artifact X-1.1, EJB2 is depending on artifact X-1.2. Building the
EAR will package one of those X artifacts, but either EJB1 is broken or EJB2,
because they refer X in their manifests. Now the project realizes, that it also
needs an updated EJB1 and then somebody of the core team providing EJB1
recognizes that upgrading EJB1 to dependency X-1.2 will break the code of EJB1
...
This all could have been avoided if team of X would have known that their
change also had impact on EJB1. Therefore they should have been able to see the
results of their refactoring.
bq. Let me know what you think. I feel this change will probably make things
worse because it requires a lot of extra attention from developers, and makes
it much easier for them to commit breaking builds.
IMHO the Eclipse projects cannot really reflect the Maven build anyway. Eclipse
has no means of test scope, you don't use the transitive deps from Eclipse
itself (at least no
[jira] Commented: (MNGECLIPSE-189) JUnit runner does not process resource filters before running
[ http://jira.codehaus.org/browse/MNGECLIPSE-189?page=comments#action_77005
]
Jonathan Share commented on MNGECLIPSE-189:
---
1) This would be a pita when the test suite reaches a particular size.
2) This sounds like what I want, but I have no idea where to start myself. When
the IDEA maven plugin sees a resources directory that has a filter specified it
does not add it as a source directory leaving all of the work to the
process-resources and process-test-resources of maven. This works most of the
time, but occasionaly it seems that the runner doesn't spot that the source
files have been changed.
3) I generate a properties file for a simple test case. The real use case is my
spring config files, currently I have 2 developers on windows, I run on Linux
and the deployment environment is Linux (and I use different paths for some
things depending on whether it is a test deployment or production deployment).
There is no way I want to maintain separate spring config files for all of
these scenarios.
> JUnit runner does not process resource filters before running
> -
>
> Key: MNGECLIPSE-189
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-189
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
>Affects Versions: 0.0.9
> Environment: Eclipse 3.1.2 Linux
>Reporter: Jonathan Share
> Assigned To: Eugene Kuleshov
>Priority: Trivial
> Attachments: filter-test.zip
>
>
> I have a project that uses a resource filter to set the path to some files
> depending on what platform the developer is on. Using maven on the command
> line this is processed correctly and the Unit tests pass. However, I wish to
> use the JUnit runner within eclipse however as my resources do not get
> filtered before the tests try to load them I get exceptions creating URL
> objects with ${news.image.url} in them.
> Desired behaviour
> ===
> This plugin should provide a launcher for the junit runner that first runs
> the process-resources (apologies if this is wrong, writing from memory here)
> target and ensure the classpath is configured correctly so that the non
> processed resources are not available to the JUnit runner before running the
> JUnit tests.
--
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-161) VM Forking manifests itself behind HTTP proxy
[ http://jira.codehaus.org/browse/MSUREFIRE-161?page=comments#action_77006 ] Ben Hood commented on MSUREFIRE-161: Ronny, I'm sorry, I don't understand your question at all. Could you elaborate? Regards, Ben > VM Forking manifests itself behind HTTP proxy > - > > Key: MSUREFIRE-161 > URL: http://jira.codehaus.org/browse/MSUREFIRE-161 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug > Components: classloading >Affects Versions: 2.3 > Environment: win2k, java 1.5 >Reporter: Ben Hood > Fix For: 2.3 > > Attachments: mvn_trace.txt > > > I have reason to believe that the forking behaviour of the surefire execution > has adverse effects when executed behind an HTTP proxy in combination with > DTD resolution (e.g. the loading of Spring beans). > Whilst using surefire to test a project (the acegi module from the mule > project, svn respo : http://svn.codehaus.org/mule/trunk/mule/modules/acegi , > revision 2859) I was getting DTD resolution errors (see attached trace). > I orginally posted this over at Spring: > http://opensource.atlassian.com/projects/spring/browse/SPR-2466. > Trying to get Eclipse to attach to the Maven debug process I set up (i.e. > running maven with MAVEN_OPTS="-Xdebug -Xnoagent > -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8787"), I found out > that this won't work because the plugin executing the code forks a new VM. > After telling the maven surefire-plugin not to fork with this setting: > > > > org.apache.maven.plugins > maven-surefire-plugin > > never > > > > > the problem with the DTD resolution from Spring went away. > Under normal circumstances, the DTD should get resolved from within the > classpath, as it is bundled in the jar. > So therefore I conclude that it is indeed a maven classloading / VM issue and > not a Spring issue as first thought. -- 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: (SCM-239) svn-commons doesn't support svn 1.4 working copy format
[ http://jira.codehaus.org/browse/SCM-239?page=all ] Kenney Westerhof closed SCM-239. Resolution: Fixed Fixed in svn revision 453277, deployed snapshots > svn-commons doesn't support svn 1.4 working copy format > --- > > Key: SCM-239 > URL: http://jira.codehaus.org/browse/SCM-239 > Project: Maven SCM > Issue Type: Bug > Components: maven-scm-provider-svn >Reporter: Brett Porter > Assigned To: Kenney Westerhof > Attachments: entries > > > testSvnFromPath(org.apache.maven.scm.provider.svn.repository.SvnScmProviderRepositoryTest) > Time elapsed: 0.022 sec <<< ERROR! > org.apache.maven.scm.repository.ScmRepositoryException: Can't read > /Users/brett/scm/mergere/maestro/maven-scm/maven-scm-providers/ma > ven-scm-providers-svn/maven-scm-provider-svn-commons/.svn/entries > at > org.codehaus.plexus.util.xml.pull.MXParser.parseProlog(MXParser.java:1516) > at > org.codehaus.plexus.util.xml.pull.MXParser.nextImpl(MXParser.java:1392) > at org.codehaus.plexus.util.xml.pull.MXParser.next(MXParser.java:1090) > at > org.apache.maven.scm.provider.svn.util.EntriesReader.read(EntriesReader.java:57) > at > org.apache.maven.scm.provider.svn.AbstractSvnScmProvider.makeProviderScmRepository(AbstractSvnScmProvider.java:119) > at > org.apache.maven.scm.provider.svn.repository.SvnScmProviderRepositoryTest.testSvnFromPath(SvnScmProviderRepositoryTest.ja > va:134) -- 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-115) Classloading problem for getting a resource
[ http://jira.codehaus.org/browse/MSUREFIRE-115?page=comments#action_77008
]
Kenney Westerhof commented on MSUREFIRE-115:
Taking another look at the unit test, the line to read the resource should be
URL dateResource = getClass().getClassLoader().getResource(
"java/util/Date.betwixt" );
and not
URL dateResource = Date.class.getResource( "/java/util/Date.betwixt" );
// or getResource("Date.betwixt");
Anyway, the Date.class.getResource(..) scheme only works with a flat
classloader: all the resources
should be in the boot classpath (like java -classpath
target/test-classes/:target/classes etc..).
In any classloading scheme where application resources are NOT in the
boot/system classloader
something like this will not work, unless you add the Date.betwixt file to the
JRE's rt.jar.
Since there are a lot of legacy apps out there that wrongly assume that
everything is available in the system
classloader, we could modify the forked mode to use that. It'll still use the 2
classloader approach,
where surefire is in a separate child classloader, but everything else will be
in the app classloader.
Child delegation won't work, since the Date.class classloader doesn't recognize
that option.
It would require a major, probably breaking change, since the test classpath
cannot be specified in the
property file passed to the forked instance, but has to be specified on the
commandline. This can break
execution because the classpath will easily get too long to fit on a
commandline.
> Classloading problem for getting a resource
> ---
>
> Key: MSUREFIRE-115
> URL: http://jira.codehaus.org/browse/MSUREFIRE-115
> Project: Maven 2.x Surefire Plugin
> Issue Type: Bug
>Affects Versions: 2.2, 2.1.3
> Environment: Maven 2.0.4
> Windows XP
>Reporter: Wim Deblauwe
>Priority: Blocker
> Fix For: 2.3
>
> Attachments: surefire-test.zip, workaround-for-fork.zip
>
>
> We are using Betwixt and some of our unit tests fail when run using
> surefire, but run fine in IntelliJ or Maven 1. Betwixt looks for
> descriptors with the name of the class + .betwixt to control how
> something is written out in XML. It uses the construct:
> myClass.getResource() to find the .betwixt file.
> E.g. com.mycomp.MyClass -> com/mycomp/MyClass.betwixt
> We have a betwixt file for the java.util.Date class. However, betwixt
> seems to be unable to pick it up when using surefire. I have created a
> small test that shows the problem and have attached it.
> I tried with version 2.2 using different configurations (never, once,
> pertest) and with version 2.1.3 (default configuration)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSUREFIRE-121) ability to add dependency to jvm's classpath rather in surefirebooter classloader
[ http://jira.codehaus.org/browse/MSUREFIRE-121?page=comments#action_77010 ] Kenney Westerhof commented on MSUREFIRE-121: The main question here is why do you need to add classes to the boot classpath? It uses an -X option, which is JRE specific; it's better not to fiddle with the boot classpath. I'm sure there's a perfectly legal usecase (java.lang.instrument stuff maybe?), but what is it? > ability to add dependency to jvm's classpath rather in surefirebooter > classloader > - > > Key: MSUREFIRE-121 > URL: http://jira.codehaus.org/browse/MSUREFIRE-121 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: xp >Reporter: Dan Tran > Fix For: 2.3 > > Attachments: MSUREFIRE-121-booter.patch, MSUREFIRE-121.plugin.patch, > MSUREFIRE-121.plugin.patch2, MSUREFIRE-121.plugin.patch3 > > > I have a usecase where i have a jar file got loaded by -Xbootclasspath, that > jar file then loads classes from another jar ( my dependency) > expected in the classpath. > The problem is that surefire plugin does not add my dependencies at JVM > commanline thru -classpath option, but after the JVM starts -- 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-156) Plugin should support setting file encoding
[ http://jira.codehaus.org/browse/MECLIPSE-156?page=comments#action_77020 ] Ralph Poellath commented on MECLIPSE-156: - I just got option 2 to work on MacOS by adding -Dfile.encoding=UTF-8 to eclipse.ini. However, I'd still prefer option 3 because it requires no manual configuration once the POM is set up correctly. > Plugin should support setting file encoding > --- > > Key: MECLIPSE-156 > URL: http://jira.codehaus.org/browse/MECLIPSE-156 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature >Reporter: Ralph Poellath > > The plugin should support setting Eclipse's text file encoding on a > per-project basis. -- 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-46) Coverage reports are incorrect for interface only modules.
[ http://jira.codehaus.org/browse/MCLOVER-46?page=comments#action_77021 ]
Andrew Williams commented on MCLOVER-46:
Now that maven-clover-plugin 2.3 has been released I crossed all my fingers,
but now we have a different error:
[ERROR] Total coverage of -100% did not meet target of 1%
[INFO]
[ERROR] BUILD ERROR
[INFO]
[INFO] Build failed to meet Clover coverage targets
[INFO]
> Coverage reports are incorrect for interface only modules.
> ---
>
> Key: MCLOVER-46
> URL: http://jira.codehaus.org/browse/MCLOVER-46
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: ubuntu dapper drake. Maven 2.0, clover maven plugin 2.2
>Reporter: Meghan Claire Pike
> Assigned To: Vincent Massol
>
> Our projects require a coverage of at least 1% in order to force everyone to
> at least think about testing. Unfortunately for interface only packages, (due
> to seperation of concerns) clover just goes into a small spasm and dies. It's
> output is like this:
> Clover Version 1.3.12, built on February 08 2006
> loaded from:
> .m2/repository/com/cenqua/clover/clover/1.3.12/clover-1.3.12.jar
> Academic License registered to EDINA. This license of Clover is provided to
> support coursework at EDINA only.
> You have 29 day(s) before your Academic License expires.
> Updating database at 'target/clover/clover.db'
> Processing files at 1.4 source level.
> Instrumented 12 source files.
> ...
> [INFO] [clover:instrument {execution: default}]
> [INFO] [clover:check {execution: default}]
> [INFO] Checking for coverage of [1%] for database [target/clover/clover.db]
> WARN: No coverage data found for '/target/clover/clover.db'.
> [ERROR] Total coverage of did not meet target of 1%
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Build failed to meet Clover coverage targets
> it doesn't even output 0% or anything like that, which seems to me to be a
> bug. I think clover should maybe understand a little better that testing
> api's doesn't make sense, and is quite difficult to do. I don't have any
> testing classes whatsoever in the project, so it could be from that. But
> clover should have some ability not to enforce coverage on interfaces. (Or
> understand that they can't be tested except indirectly.)
> Thanks!
--
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: (MWAR-79) copy fails in a multi-project build
[ http://jira.codehaus.org/browse/MWAR-79?page=comments#action_77022 ]
Alexander Syedin commented on MWAR-79:
--
As workaround directory could be referenced using ${basedir} property:
${basedir}/src/main/resources
instead of
src/main/resources
> copy fails in a multi-project build
> --
>
> Key: MWAR-79
> URL: http://jira.codehaus.org/browse/MWAR-79
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.2
> Environment: Maven 2.0.4, maven-war-plugin trunk r453448, Sun Java
> 1.5, Ubuntu Linux
>Reporter: Elliot Metsger
> Attachments: MWAR-79.patch, test-project.tar.gz
>
>
> In this example project (attached as test-project.tar.gz)
> |-- foo-bar-webapp
> | |-- pom.xml
> | `-- src
> | `-- main
> | |-- resources
> | | `-- foo.properties
> | `-- webapp
> | |-- WEB-INF
> | | `-- web.xml
> | `-- index.jsp
> `-- pom.xml
> Executing 'mvn package' from the foo-bar-webapp directory succeeds, but
> executing 'mvn package' from the parent project directory fails with:
> java.lang.IllegalStateException: basedir src/main/resources does not exist
> at
> org.codehaus.plexus.util.DirectoryScanner.scan(DirectoryScanner.java:542)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.getWarFiles(AbstractWarMojo.java:821)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.copyResources(AbstractWarMojo.java:405)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildWebapp(AbstractWarMojo.java:515)
> at
> org.apache.maven.plugin.war.AbstractWarMojo.buildExplodedWebapp(AbstractWarMojo.java:344)
> at
> org.apache.maven.plugin.war.WarMojo.performPackaging(WarMojo.java:161)
> at org.apache.maven.plugin.war.WarMojo.execute(WarMojo.java:127)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:534)
> 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)
> The foo-bar-webapp/pom.xml contains:
>
> foo-bar-webapp
>
>
> maven-war-plugin
>
>
>
> src/main/resources
> true
>
>
>
>
>
>
--
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-161) VM Forking manifests itself behind HTTP proxy
[ http://jira.codehaus.org/browse/MSUREFIRE-161?page=comments#action_77025 ] Ronny Naess commented on MSUREFIRE-161: --- I do not blame you :-) It was I that linked the two dependencies on top. I just commented in the comment field, but I had now idea it would come out this way. Ignor may last comment and just look at my previoud post. Anyway, I have simulare problemes like the one you experienced. My test-jars (created in pom) which is to be included when running tests in other artifacts, has test resources to be used at test runtime. If i run install from top level (parent pom) my build is almost never success. My test deps is included and used in the test classpath for the first artifacts, but then it suddenly breaks even it says it is there. It breaks because test resources is not found. This is a random behavior since it later can work, and or a previous successfully built artifact may break the second time. Very frustrating all very random. It is very easy to see that this is a random error. We have resources that is the same for both main and test, that is same filenames for the resources, but different content. I list the content to screen at test runtime. Until the problem is problem is solved we have skipped the testing in maven. Did you ever solve your problems in a useful way? > VM Forking manifests itself behind HTTP proxy > - > > Key: MSUREFIRE-161 > URL: http://jira.codehaus.org/browse/MSUREFIRE-161 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug > Components: classloading >Affects Versions: 2.3 > Environment: win2k, java 1.5 >Reporter: Ben Hood > Fix For: 2.3 > > Attachments: mvn_trace.txt > > > I have reason to believe that the forking behaviour of the surefire execution > has adverse effects when executed behind an HTTP proxy in combination with > DTD resolution (e.g. the loading of Spring beans). > Whilst using surefire to test a project (the acegi module from the mule > project, svn respo : http://svn.codehaus.org/mule/trunk/mule/modules/acegi , > revision 2859) I was getting DTD resolution errors (see attached trace). > I orginally posted this over at Spring: > http://opensource.atlassian.com/projects/spring/browse/SPR-2466. > Trying to get Eclipse to attach to the Maven debug process I set up (i.e. > running maven with MAVEN_OPTS="-Xdebug -Xnoagent > -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8787"), I found out > that this won't work because the plugin executing the code forks a new VM. > After telling the maven surefire-plugin not to fork with this setting: > > > > org.apache.maven.plugins > maven-surefire-plugin > > never > > > > > the problem with the DTD resolution from Spring went away. > Under normal circumstances, the DTD should get resolved from within the > classpath, as it is bundled in the jar. > So therefore I conclude that it is indeed a maven classloading / VM issue and > not a Spring issue as first thought. -- 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-161) VM Forking manifests itself behind HTTP proxy
[ http://jira.codehaus.org/browse/MSUREFIRE-161?page=comments#action_77026 ] Ben Hood commented on MSUREFIRE-161: I just turned the forking off, as indicated above. In my case, it was better to have no forking because of the amount of tests run, but if I did need to fork for some reason, then I couldn't use maven to test (at least from behind an http proxy). I think this just indicates a bug in the resource resolution. > VM Forking manifests itself behind HTTP proxy > - > > Key: MSUREFIRE-161 > URL: http://jira.codehaus.org/browse/MSUREFIRE-161 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug > Components: classloading >Affects Versions: 2.3 > Environment: win2k, java 1.5 >Reporter: Ben Hood > Fix For: 2.3 > > Attachments: mvn_trace.txt > > > I have reason to believe that the forking behaviour of the surefire execution > has adverse effects when executed behind an HTTP proxy in combination with > DTD resolution (e.g. the loading of Spring beans). > Whilst using surefire to test a project (the acegi module from the mule > project, svn respo : http://svn.codehaus.org/mule/trunk/mule/modules/acegi , > revision 2859) I was getting DTD resolution errors (see attached trace). > I orginally posted this over at Spring: > http://opensource.atlassian.com/projects/spring/browse/SPR-2466. > Trying to get Eclipse to attach to the Maven debug process I set up (i.e. > running maven with MAVEN_OPTS="-Xdebug -Xnoagent > -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=8787"), I found out > that this won't work because the plugin executing the code forks a new VM. > After telling the maven surefire-plugin not to fork with this setting: > > > > org.apache.maven.plugins > maven-surefire-plugin > > never > > > > > the problem with the DTD resolution from Spring went away. > Under normal circumstances, the DTD should get resolved from within the > classpath, as it is bundled in the jar. > So therefore I conclude that it is indeed a maven classloading / VM issue and > not a Spring issue as first thought. -- 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-46) Coverage reports are incorrect for interface only modules.
[ http://jira.codehaus.org/browse/MCLOVER-46?page=comments#action_77028 ]
Vincent Massol commented on MCLOVER-46:
---
Everyone,
I've checked the Clover plugin code and we do not perform any check when
there's no Clover database. The problem is that you're generating a clover
database if you run clover:instrument, even if your code only has interfaces.
The Clover plugin has no control on that. Nor does it have any control on the
message output by Clover ("Total coverage of ..."). This comes straight from
the execution of the Clover Check Ant task
(http://cenqua.com/clover/doc/ant/checktask.html).
Andrew,
I have upgraded to a newer version of Clover (1.3.13) in the v2.3 of the
plugin. It seems Clover 1.3.13 is reporting differently where there are no
coverage data in the database. I'd suggest you try running Clover 1.3.13
directly on your code without going through Maven2. You should experience the
same result.
Right now I still don't see of any way to implement this JIRA issue. AFAIK this
has nothing to do with the Clover plugin and this issue shoudl be reported on
the Clover support forums: http://cenqua.com/forums/category.jspa?categoryID=2
Meghan, about your suggestion to be able to turn off some module from executing
Clover, could you please create another JIRA issue.
If everyone agrees, I'm now going to close this issue as "won't fix". Unless
someone has a better idea of course :-)
Thanks
-Vincent
> Coverage reports are incorrect for interface only modules.
> ---
>
> Key: MCLOVER-46
> URL: http://jira.codehaus.org/browse/MCLOVER-46
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: ubuntu dapper drake. Maven 2.0, clover maven plugin 2.2
>Reporter: Meghan Claire Pike
> Assigned To: Vincent Massol
>
> Our projects require a coverage of at least 1% in order to force everyone to
> at least think about testing. Unfortunately for interface only packages, (due
> to seperation of concerns) clover just goes into a small spasm and dies. It's
> output is like this:
> Clover Version 1.3.12, built on February 08 2006
> loaded from:
> .m2/repository/com/cenqua/clover/clover/1.3.12/clover-1.3.12.jar
> Academic License registered to EDINA. This license of Clover is provided to
> support coursework at EDINA only.
> You have 29 day(s) before your Academic License expires.
> Updating database at 'target/clover/clover.db'
> Processing files at 1.4 source level.
> Instrumented 12 source files.
> ...
> [INFO] [clover:instrument {execution: default}]
> [INFO] [clover:check {execution: default}]
> [INFO] Checking for coverage of [1%] for database [target/clover/clover.db]
> WARN: No coverage data found for '/target/clover/clover.db'.
> [ERROR] Total coverage of did not meet target of 1%
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Build failed to meet Clover coverage targets
> it doesn't even output 0% or anything like that, which seems to me to be a
> bug. I think clover should maybe understand a little better that testing
> api's doesn't make sense, and is quite difficult to do. I don't have any
> testing classes whatsoever in the project, so it could be from that. But
> clover should have some ability not to enforce coverage on interfaces. (Or
> understand that they can't be tested except indirectly.)
> Thanks!
--
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-53) Clover plugin installs clover instrumented source in local repository
[ http://jira.codehaus.org/browse/MCLOVER-53?page=all ]
Vincent Massol updated MCLOVER-53:
--
Attachment: usertest.zip
Hi Evan,
I've tried to reproduce your problem unsuccessfully. Please find attached the
test project I've used. When running it by executing "mvn clean verify site" I
got:
{noformat}
[INFO] [install:install]
[INFO] Installing
C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\usertest\target\clover\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-clover.jar
to C:\Documents and
Settings\vmassol\.m2\repository\org\apache\maven\plugins\maven-clover-plugin-sample-usertest\1.0-SNAPSHOT\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-clover.jar
[INFO] Installing
C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\usertest\target\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-sources.jar
to C:\Documents and
Settings\vmassol\.m2\repository\org\apache\maven\plugins\maven-clover-plugin-sample-usertest\1.0-SNAPSHOT\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-sources.jar
{noformat}
Could you please modify this sample project so that it gives the same problem
as you've noticed?
Thanks
-Vincent
> Clover plugin installs clover instrumented source in local repository
> -
>
> Key: MCLOVER-53
> URL: http://jira.codehaus.org/browse/MCLOVER-53
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP Pro, Maven 2.0.4
>Reporter: Evan Tritsch
> Assigned To: Vincent Massol
>Priority: Minor
> Attachments: usertest.zip
>
>
> When I run "clean verify site" on a project that has the clover plugin
> enabled, the clover-sources jar gets installed to the local repository,
> overwriting the real sources jar. The last line of the log snippet below
> shows the problem.
> [INFO] [install:install]
> [INFO] Installing
> C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover.jar
> to C:\Documents and
> Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-clover.jar
> [INFO] Installing
> C:\Workspaces\Cleanroom\myProject\target\myProject-2.0-SNAPSHOT-sources.jar
> to C:\Documents and
> Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar
> [INFO] Installing
> C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover-sources.jar
> to C:\Documents and
> Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar
> It looks like the clover plugin is just using the wrong destination name for
> the 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] Commented: (MCLOVER-53) Clover plugin installs clover instrumented source in local repository
[ http://jira.codehaus.org/browse/MCLOVER-53?page=comments#action_77041 ] Evan Tritsch commented on MCLOVER-53: - I did not make any changes to the test project, and I was able to reproduce the problem. I even deleted my entire local repository to make sure I had the latest and greatest of everything. I checked after all the plugins got downloaded again, and I'm running the 2.3 version of the clover plugin. Even with new copies of everything, I still got the following in the log. [INFO] Installing C:\Temp\usertest\target\clover\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-clover.jar to C:\Documents and Settings\ET012568\.m2\repository\org\apache\maven\plugins\maven-clover-plugin-sample-usertest\1.0-SNAPSHOT\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-clover.jar [INFO] Installing C:\Temp\usertest\target\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-sources.jar to C:\Documents and Settings\ET012568\.m2\repository\org\apache\maven\plugins\maven-clover-plugin-sample-usertest\1.0-SNAPSHOT\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-sources.jar [INFO] Installing C:\Temp\usertest\target\clover\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-clover-sources.jar to C:\Documents and Settings\ET012568\.m2\repository\org\apache\maven\plugins\maven-clover-plugin-sample-usertest\1.0-SNAPSHOT\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-sources.jar The third line shows it overwriting the source jar. > Clover plugin installs clover instrumented source in local repository > - > > Key: MCLOVER-53 > URL: http://jira.codehaus.org/browse/MCLOVER-53 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP Pro, Maven 2.0.4 >Reporter: Evan Tritsch > Assigned To: Vincent Massol >Priority: Minor > Attachments: usertest.zip > > > When I run "clean verify site" on a project that has the clover plugin > enabled, the clover-sources jar gets installed to the local repository, > overwriting the real sources jar. The last line of the log snippet below > shows the problem. > [INFO] [install:install] > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-clover.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\myProject-2.0-SNAPSHOT-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > It looks like the clover plugin is just using the wrong destination name for > the 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] Commented: (MSUREFIRE-121) ability to add dependency to jvm's classpath rather in surefirebooter classloader
[ http://jira.codehaus.org/browse/MSUREFIRE-121?page=comments#action_77046 ] Dan Tran commented on MSUREFIRE-121: It is Borland's Optimizeit memory and cpu profilers > ability to add dependency to jvm's classpath rather in surefirebooter > classloader > - > > Key: MSUREFIRE-121 > URL: http://jira.codehaus.org/browse/MSUREFIRE-121 > Project: Maven 2.x Surefire Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: xp >Reporter: Dan Tran > Fix For: 2.3 > > Attachments: MSUREFIRE-121-booter.patch, MSUREFIRE-121.plugin.patch, > MSUREFIRE-121.plugin.patch2, MSUREFIRE-121.plugin.patch3 > > > I have a usecase where i have a jar file got loaded by -Xbootclasspath, that > jar file then loads classes from another jar ( my dependency) > expected in the classpath. > The problem is that surefire plugin does not add my dependencies at JVM > commanline thru -classpath option, but after the JVM starts -- 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-2594) faq links
faq links - Key: MNG-2594 URL: http://jira.codehaus.org/browse/MNG-2594 Project: Maven 2 Issue Type: Bug Components: Documentation: Faqs Reporter: Luis Parravicini Priority: Minor The links in http://maven.apache.org/faq.html are displayed as "[text|url]" -- 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] Reopened: (MECLIPSE-158) Add the ability to selectively treat a referenced project as a local repository file
[ http://jira.codehaus.org/browse/MECLIPSE-158?page=all ]
Tim O'Brien reopened MECLIPSE-158:
--
Kenney would hate to see skip this configuration for the Maven 2.x eclipse
plugin, but it wouldn't be too difficult to implement a setting to exclude a
project reference from the .classpath file. If we allow a universal
configuration to skip project references, why not just allow the possibility
that someone would want to selectively exclude a project reference. If this
isn't a feature you have a particular itch for, mark it as deferred, but
saying, "Won't Fix" just because you'd rather not see it implemented is not a
reason to close a bug.
The bug is with Eclipse, Eclipse doesn't properly compile source generated by
XMLBeans. And, we need a setting to work around the bug in Eclipse.
> Add the ability to selectively treat a referenced project as a local
> repository file
>
>
> Key: MECLIPSE-158
> URL: http://jira.codehaus.org/browse/MECLIPSE-158
> Project: Maven 2.x Eclipse Plugin
> Issue Type: New Feature
> Components: multiproject
>Affects Versions: 2.2
>Reporter: Tim O'Brien
>
> The issue is that I have a large project with many interdependent submodules.
> One of the submodules uses XML Beans to generate a set of objects from an
> XML Schema. This works perfectly, but Eclipse has a problem with the class
> names used in XMLBeans, and I have to close that particular project for
> Eclipse not to complain. But, if I close that project, all of the projects
> that depend on it directly (through a referenced project), then complain that
> they are missing a referenced project.
> The solution is to relate the project via the local repository (M2_REPO/...)
> not via a project reference, but in EclipseClasspathWriter, all projects
> available via the reactor are treated as referenced projects:
> if ( dep.isReferencedProject() && !config.isPde() )
> {
> path = "/" + dep.getArtifactId(); //$NON-NLS-1$
> kind = ATTR_SRC;
> }
> One solution would be to not use project references, but the problem only
> happens with specific projects, and I want to be able to selectively mark
> dependencies as not being referenced.
> Something as simple as, this:
>
>
> blah
> blah
>
>
> Where the dependency identified by that groupId and artifactId would be
> treated not as a direct project reference but as a link to the local
> repository.
> Does that make any sense?
--
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: (MNGECLIPSE-116) Embedder can't find local repository
[ http://jira.codehaus.org/browse/MNGECLIPSE-116?page=comments#action_77049 ] Ricardo Gladwell commented on MNGECLIPSE-116: - This problem was fixed for me by manually installing M2 on my local machine and executing ./mvn -version. I wasn't aware that the Eclipse plugin also required maven installed on the local machine. It would be nice if the M2 Eclipse plugin would optionally offer to install maven 2 on the update site.xml, and/or set-up the $HOME/.m2 directory automatically. Is it worth raising seperate feature bugs for these points? > Embedder can't find local repository > > > Key: MNGECLIPSE-116 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-116 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.7 > Environment: WinXP, Eclipse 3.1.2, Maven2.0.4 >Reporter: Cliff Resnick > Attachments: 20060526_MNGECLIPSE-116_trunk.patch, > 20060529_MNGECLIPSE-116_trunk.patch, maven-embedder-2.0.4_fixed-dep.jar > > > I upgraded from 0.0.5 to 0.0.7 and the plugin fails to load. > Below is output from the workspace log file: > java.lang.IllegalArgumentException: When not aligning with a user install you > must specify a local repository location using the > setLocalRepositoryDirectory( File ) method. > at > org.apache.maven.embedder.MavenEmbedder.createMavenSettings(MavenEmbedder.java:699) > at org.apache.maven.embedder.MavenEmbedder.start(MavenEmbedder.java:628) > at > org.maven.ide.eclipse.Maven2Plugin.createEmbedder(Maven2Plugin.java:267) > at > org.maven.ide.eclipse.Maven2Plugin.getMavenEmbedder(Maven2Plugin.java:155) > at > org.maven.ide.eclipse.Maven2Plugin.executeInEmbedder(Maven2Plugin.java:165) > at org.maven.ide.eclipse.Maven2Plugin.start(Maven2Plugin.java:112) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:994) > at java.security.AccessController.doPrivileged(Native Method) > -- 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: (MNGECLIPSE-189) JUnit runner does not process resource filters before running
[ http://jira.codehaus.org/browse/MNGECLIPSE-189?page=comments#action_77051
]
Eugene Kuleshov commented on MNGECLIPSE-189:
Folks. Please calm down and reread my last comment. Currently resources are
copied to target directory by Eclipse compiler and there is no way to add any
filtering in there (without altering Eclipse). So, your best bet is to add
Maven builder that would run after Eclipse compiler (Project properties /
Builders / Add / Maven builder).
PS: btw, Spring has its own mechanisms to substitute variables, so you may as
well use it and leave your spring configs unchanged.
PPS: fyi, if you need to run just one test with maven you can use mvn
-Dtest=TestCircle test command. You can even substitute currently selected file
in Maven launch configuration. So, size won't matter.
> JUnit runner does not process resource filters before running
> -
>
> Key: MNGECLIPSE-189
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-189
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
>Affects Versions: 0.0.9
> Environment: Eclipse 3.1.2 Linux
>Reporter: Jonathan Share
> Assigned To: Eugene Kuleshov
>Priority: Trivial
> Attachments: filter-test.zip
>
>
> I have a project that uses a resource filter to set the path to some files
> depending on what platform the developer is on. Using maven on the command
> line this is processed correctly and the Unit tests pass. However, I wish to
> use the JUnit runner within eclipse however as my resources do not get
> filtered before the tests try to load them I get exceptions creating URL
> objects with ${news.image.url} in them.
> Desired behaviour
> ===
> This plugin should provide a launcher for the junit runner that first runs
> the process-resources (apologies if this is wrong, writing from memory here)
> target and ensure the classpath is configured correctly so that the non
> processed resources are not available to the JUnit runner before running the
> JUnit tests.
--
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: (MNGECLIPSE-116) Embedder can't find local repository
[ http://jira.codehaus.org/browse/MNGECLIPSE-116?page=comments#action_77052 ] Eugene Kuleshov commented on MNGECLIPSE-116: Ricardo, all you need to do is to run maven once (even from launch configuration should be enough) or to create that folder manually. As been said this is just a current work around and will be fixed in scope of this issue. > Embedder can't find local repository > > > Key: MNGECLIPSE-116 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-116 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.7 > Environment: WinXP, Eclipse 3.1.2, Maven2.0.4 >Reporter: Cliff Resnick > Attachments: 20060526_MNGECLIPSE-116_trunk.patch, > 20060529_MNGECLIPSE-116_trunk.patch, maven-embedder-2.0.4_fixed-dep.jar > > > I upgraded from 0.0.5 to 0.0.7 and the plugin fails to load. > Below is output from the workspace log file: > java.lang.IllegalArgumentException: When not aligning with a user install you > must specify a local repository location using the > setLocalRepositoryDirectory( File ) method. > at > org.apache.maven.embedder.MavenEmbedder.createMavenSettings(MavenEmbedder.java:699) > at org.apache.maven.embedder.MavenEmbedder.start(MavenEmbedder.java:628) > at > org.maven.ide.eclipse.Maven2Plugin.createEmbedder(Maven2Plugin.java:267) > at > org.maven.ide.eclipse.Maven2Plugin.getMavenEmbedder(Maven2Plugin.java:155) > at > org.maven.ide.eclipse.Maven2Plugin.executeInEmbedder(Maven2Plugin.java:165) > at org.maven.ide.eclipse.Maven2Plugin.start(Maven2Plugin.java:112) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:994) > at java.security.AccessController.doPrivileged(Native Method) > -- 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: (MNGECLIPSE-189) JUnit runner does not process resource filters before running
[ http://jira.codehaus.org/browse/MNGECLIPSE-189?page=comments#action_77053
]
Jonathan Share commented on MNGECLIPSE-189:
---
Thanks for the input on how to add a Builder. This appears to solve my problem.
Is it not possible for the m2eclipse plugin to add this builder automatically
when you "enable" m2 on a project ?
> JUnit runner does not process resource filters before running
> -
>
> Key: MNGECLIPSE-189
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-189
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
>Affects Versions: 0.0.9
> Environment: Eclipse 3.1.2 Linux
>Reporter: Jonathan Share
> Assigned To: Eugene Kuleshov
>Priority: Trivial
> Attachments: filter-test.zip
>
>
> I have a project that uses a resource filter to set the path to some files
> depending on what platform the developer is on. Using maven on the command
> line this is processed correctly and the Unit tests pass. However, I wish to
> use the JUnit runner within eclipse however as my resources do not get
> filtered before the tests try to load them I get exceptions creating URL
> objects with ${news.image.url} in them.
> Desired behaviour
> ===
> This plugin should provide a launcher for the junit runner that first runs
> the process-resources (apologies if this is wrong, writing from memory here)
> target and ensure the classpath is configured correctly so that the non
> processed resources are not available to the JUnit runner before running the
> JUnit tests.
--
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: (MNGECLIPSE-116) Embedder can't find local repository
[ http://jira.codehaus.org/browse/MNGECLIPSE-116?page=comments#action_77054 ] Ricardo Gladwell commented on MNGECLIPSE-116: - Thanks for the feedback Eugene. I'm still not clear if MNGECLIPSE requires M2 installed first which could be a separate issue. > Embedder can't find local repository > > > Key: MNGECLIPSE-116 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-116 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.7 > Environment: WinXP, Eclipse 3.1.2, Maven2.0.4 >Reporter: Cliff Resnick > Attachments: 20060526_MNGECLIPSE-116_trunk.patch, > 20060529_MNGECLIPSE-116_trunk.patch, maven-embedder-2.0.4_fixed-dep.jar > > > I upgraded from 0.0.5 to 0.0.7 and the plugin fails to load. > Below is output from the workspace log file: > java.lang.IllegalArgumentException: When not aligning with a user install you > must specify a local repository location using the > setLocalRepositoryDirectory( File ) method. > at > org.apache.maven.embedder.MavenEmbedder.createMavenSettings(MavenEmbedder.java:699) > at org.apache.maven.embedder.MavenEmbedder.start(MavenEmbedder.java:628) > at > org.maven.ide.eclipse.Maven2Plugin.createEmbedder(Maven2Plugin.java:267) > at > org.maven.ide.eclipse.Maven2Plugin.getMavenEmbedder(Maven2Plugin.java:155) > at > org.maven.ide.eclipse.Maven2Plugin.executeInEmbedder(Maven2Plugin.java:165) > at org.maven.ide.eclipse.Maven2Plugin.start(Maven2Plugin.java:112) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:994) > at java.security.AccessController.doPrivileged(Native Method) > -- 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: (MPIDEA-49) idea:module fails on project:type of ejb
[ http://jira.codehaus.org/browse/MPIDEA-49?page=comments#action_77055 ] Jimmy Wan commented on MPIDEA-49: - The problem appears to be emanating from line 41 in templates/v4/module.jelly: maven.ejb.src is considered an optional property for the EJB plugin. As such, it is likely not present. >From EJB plugin notes: "Root of files to be included within the ejb-jar. The same directory structure will be followed within the assembled jar file. Please note this is not for your java code or class files, these are other resources. Alternatively, you can use the resources element of the project.xml to specify resource across various directories, just as you would for a jar or war project." > idea:module fails on project:type of ejb > > > Key: MPIDEA-49 > URL: http://jira.codehaus.org/browse/MPIDEA-49 > Project: maven-idea-plugin > Issue Type: Bug >Affects Versions: 1.6 > Environment: Maven 1.0.2 > maven-multiproject-plugin-1.5.jar > maven-idea-plugin-1.6.jar >Reporter: Jimmy Wan > > My general project structure is something like this: > Toplevel project with no artifacts. > Tier 2 children of toplevel project are subprojects that inherit from the > toplevel project and are of 2 types (jar or ejb). > Tier 3 children of tier 2 projects are subprojects of tier 2 projects and are > all of type jar. > The idea:multiproject task fails and generates a truncated module file as > seen below. v1.5 of the IDEA plugin does not have this problem, but fails in > other ways that also makes it unsuitable for me. > Output: > [CUT-REMOVED ARTIFACT DOWNLOAD OUTPUT] > [echo] DEPRECATED: the use of dependency-handle is deprecated. Please use > maven:get/set to modify properties of the multiproject plugin > build:start: > idea:init: > war:load: > [echo] DEPRECATED: war:load is deprecated, please use maven:get tags > idea:module: > [echo] Creating > c:\repo\Products\Wolverine\WorkflowServices/WolverineWorkflowServices.iml ... > BUILD FAILED > File.. C:\Documents and > Settings\jwan.21TECHNOLOGIES\.maven\cache\maven-idea-plugin-1.6\plugin.jelly > Element... j:import > Line.. 78 > Column 79 > file:/C:/Documents and > Settings/jwan.21TECHNOLOGIES/.maven/cache/maven-idea-plugin-1.6/plugin-resources/templates/v4/module.jelly:41:106: > You must define an attribute called 'path' for this > tag. > Total time: 3 seconds > Finished at: Fri Oct 06 11:42:00 CDT 2006 > Generated Module file: > > > > > > > > > > > > > -- 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-53) Clover plugin installs clover instrumented source in local repository
[ http://jira.codehaus.org/browse/MCLOVER-53?page=comments#action_77058 ]
Vincent Massol commented on MCLOVER-53:
---
Evan, what version of Maven are you using? (mvn --version)
What version of the install plugin are you using? To know that, just run
{noformat}
C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\usertest>mvn
help:describe -DgroupId=org.apache.maven.plugins
-DartifactId=maven-install-plugin
[INFO] Scanning for projects...
[INFO] Searching repository for plugin with prefix: 'help'.
[INFO]
[INFO] Building Maven Clover Plugin usertest Sample
[INFO]task-segment: [help:describe] (aggregator-style)
[INFO]
[INFO] [help:describe]
[INFO] Plugin: 'org.apache.maven.plugins:maven-install-plugin:2.1'
---
Group Id: org.apache.maven.plugins
Artifact Id: maven-install-plugin
Version: 2.1
Goal Prefix: install
Description:
Maven plugin parent
{noformat}
Thanks
-Vincent
> Clover plugin installs clover instrumented source in local repository
> -
>
> Key: MCLOVER-53
> URL: http://jira.codehaus.org/browse/MCLOVER-53
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.2
> Environment: Windows XP Pro, Maven 2.0.4
>Reporter: Evan Tritsch
> Assigned To: Vincent Massol
>Priority: Minor
> Attachments: usertest.zip
>
>
> When I run "clean verify site" on a project that has the clover plugin
> enabled, the clover-sources jar gets installed to the local repository,
> overwriting the real sources jar. The last line of the log snippet below
> shows the problem.
> [INFO] [install:install]
> [INFO] Installing
> C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover.jar
> to C:\Documents and
> Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-clover.jar
> [INFO] Installing
> C:\Workspaces\Cleanroom\myProject\target\myProject-2.0-SNAPSHOT-sources.jar
> to C:\Documents and
> Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar
> [INFO] Installing
> C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover-sources.jar
> to C:\Documents and
> Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar
> It looks like the clover plugin is just using the wrong destination name for
> the 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] Closed: (CONTINUUM-736) "Edit User" page resets password to the empty password - admin user no longer useable
[ http://jira.codehaus.org/browse/CONTINUUM-736?page=all ] Jesse McConnell closed CONTINUUM-736. - Resolution: Won't Fix the entire web interface and security model are being changed under continuum 1.1 so this issue is not really applicable to the trunk, and the user management pages for these activities are managed by the plexus-security integration sorry about that, going through issues now to update and start preparing for 1.1 release > "Edit User" page resets password to the empty password - admin user no longer > useable > - > > Key: CONTINUUM-736 > URL: http://jira.codehaus.org/browse/CONTINUUM-736 > Project: Continuum > Issue Type: Bug > Components: Web interface >Affects Versions: 1.0.3 >Reporter: Bernhard Wellhöfer >Priority: Blocker > Fix For: 1.1 > > > Hello, > > I changed in the user management section the real name for the continuum > admin user. The form where I added the real name also presented the password > field. Here the password field was empty - nevertheless the admin user had a > password. After entering the new real name for admin and after hitting > "submit" the real named changed - but the password also changed. I did not > enter anything in the password text field ... > It seems that the new password is now blank. This is a serious issue, since > the login page does not allow an empty password. So how do I reset the admin > password to a known value? > Moreover I need a solution how to repair my continuum system. > > Cheers, > > Bernd -- 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-168) make repository variable configurable (M2_REPO)
make repository variable configurable (M2_REPO) --- Key: MECLIPSE-168 URL: http://jira.codehaus.org/browse/MECLIPSE-168 Project: Maven 2.x Eclipse Plugin Issue Type: Improvement Affects Versions: 2.3 Reporter: Dan Allen Priority: Minor It would be nice to allow the name of the M2_REPO variable to be configurable via the plugin configuration. It is possible that a user will have multiple maven repository locations and thus it is necessary to have different eclipse variables that point to them. An example use case would be a developer who maintains a local repository for access to public mirrors for personal development, while at the same time has a local repository for a company's internal mirror for corporate development. i.e. M2_REPO_PERSONAL -- 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-684) Access to Continuum using XML-RPC is not authenticated.
[ http://jira.codehaus.org/browse/CONTINUUM-684?page=comments#action_77068 ] Jesse McConnell commented on CONTINUUM-684: --- rahul, we are going to be merging the plexus-security integration into continuum this week...would you be interested in applying this to the xml-rpc code? you were looking for something to do :P > Access to Continuum using XML-RPC is not authenticated. > --- > > Key: CONTINUUM-684 > URL: http://jira.codehaus.org/browse/CONTINUUM-684 > Project: Continuum > Issue Type: Bug > Components: XMLRPC Interface >Reporter: Rahul Thakur >Priority: Critical > Fix For: 1.1 > > > Noticed that I could connect to a Continuum instance on my local box and > obtain list of project details without being authenticated. > Can this also be considered as a request to implement a "doLogin( )" service > or similar for Continuum - Thanks. -- 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: (SCM-242) NPE on ScmRepositoryException
NPE on ScmRepositoryException - Key: SCM-242 URL: http://jira.codehaus.org/browse/SCM-242 Project: Maven SCM Issue Type: Bug Components: maven-plugin Reporter: Julien HENRY I get a NPE when using Scm plugin with the provider I wrote (Synergy) and the URL is incorrect. I think it's because I use the ScmRepositoryException( String msg ) constructor instead of ScmRepositoryException( String msg, List validationMessages ), and the result is e.getValidationMessages().isEmpty() raise a NPE. Here is stack trace : java.lang.NullPointerException at org.apache.maven.scm.plugin.AbstractScmMojo.getScmRepository(AbstractScmMojo.java:258) at org.apache.maven.scm.plugin.CheckoutMojo.checkout(CheckoutMojo.java:94) at org.apache.maven.scm.plugin.BootstrapMojo.execute(BootstrapMojo.java:58) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) 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.java:306) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:219) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:140) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) ... -- 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-622) Configure default build description
[ http://jira.codehaus.org/browse/CONTINUUM-622?page=all ] Jesse McConnell updated CONTINUUM-622: -- Fix Version/s: (was: 1.1) 1.2 the lion share of the issue is addressed in the bulk project group lvl build definitions, but some configuration for defaults might be good for the profiles that will be a feature in 1.2 > Configure default build description > --- > > Key: CONTINUUM-622 > URL: http://jira.codehaus.org/browse/CONTINUUM-622 > Project: Continuum > Issue Type: Wish > Components: Core system >Affects Versions: 1.0.2 >Reporter: Shinobu Kawai > Fix For: 1.2 > > > It would be great if it was possible to configure the build definition > created when adding a project. > e.g. Currently, the goal for m2 projects are "clean install". If you wanted > to have all your projects do "clean deploy site site:deploy", you need to > edit them one by one. But if you could configure the defaults, you can set > it to the goals you would use most. > I guess this will improve with the upcoming bulk updating feature, but you > still need to edit it. ;) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-44) multiple profiles
[ http://jira.codehaus.org/browse/CONTINUUM-44?page=all ] Jesse McConnell updated CONTINUUM-44: - Fix Version/s: (was: 1.1) 1.2 I think profiles will probably be a key feature for 1.2 > multiple profiles > - > > Key: CONTINUUM-44 > URL: http://jira.codehaus.org/browse/CONTINUUM-44 > Project: Continuum > Issue Type: New Feature >Reporter: Brett Porter > Fix For: 1.2 > > > would like to be able to define a profile (which can include certain > environmental things such as the version of m2 to use, the JDK version, etc). > Profiles should be able to be used globally, per group or per project. In > this way, you could build certain projects under a variety of different JDKs > for example. -- 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-436) prefill the build definition
[ http://jira.codehaus.org/browse/CONTINUUM-436?page=all ] Jesse McConnell updated CONTINUUM-436: -- Component/s: Web interface > prefill the build definition > > > Key: CONTINUUM-436 > URL: http://jira.codehaus.org/browse/CONTINUUM-436 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.0 >Reporter: Wim Deblauwe > Fix For: 1.1 > > > when adding a build definition it would be nice if it is pre-filled with the > values of the previous one. Most of the time the values will probably be the > same (wel at least the location of the pom.xml). It might save some typing > (and the possibility for typo's!). Or you can have a clone button or > something. -- 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-53) Clover plugin installs clover instrumented source in local repository
[ http://jira.codehaus.org/browse/MCLOVER-53?page=comments#action_77077 ] Evan Tritsch commented on MCLOVER-53: - I'm using version 2.0.4 of maven, and version 2.1 of the install plugin. > Clover plugin installs clover instrumented source in local repository > - > > Key: MCLOVER-53 > URL: http://jira.codehaus.org/browse/MCLOVER-53 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP Pro, Maven 2.0.4 >Reporter: Evan Tritsch > Assigned To: Vincent Massol >Priority: Minor > Attachments: usertest.zip > > > When I run "clean verify site" on a project that has the clover plugin > enabled, the clover-sources jar gets installed to the local repository, > overwriting the real sources jar. The last line of the log snippet below > shows the problem. > [INFO] [install:install] > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-clover.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\myProject-2.0-SNAPSHOT-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > It looks like the clover plugin is just using the wrong destination name for > the 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: (MNG-2595) mvn support for GCJ 4.1 and java-1.4 compat
mvn support for GCJ 4.1 and java-1.4 compat --- Key: MNG-2595 URL: http://jira.codehaus.org/browse/MNG-2595 Project: Maven 2 Issue Type: New Feature Components: Bootstrap & Build Affects Versions: 2.0.4 Environment: Fedora Core 5, libgcj 4.1.1, java-1.4.2-gcj-compat Reporter: Ricardo Gladwell Priority: Minor The mvn Unix shell script does not properly detect the location of local JAVA_HOME on the above GCJ system. Error is as follows: $mvn -version Error: JAVA_HOME is not defined correctly. We cannot execute java This can be fixed by manually setting $JAVA_HOME=/usr/lib/jvm/java-1.4.2/ (compat home of gcj) but M2 still refuses to run with the following error: $ mvn -version Sorry, but JDK 1.4 or above is required to execute Maven You appear to be using Java version: 1.4.2 I'm not even sure the mvn can run on GCJ-compat systems yet, but if so it would be nice if the mvn shell script also supported such systems. The above can be worked around by downloading and installing the Linux version of the JAVA 5 SDK. -- 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-53) Clover plugin installs clover instrumented source in local repository
[ http://jira.codehaus.org/browse/MCLOVER-53?page=comments#action_77079 ] Vincent Massol commented on MCLOVER-53: --- hmmm... really strange... we're using the same versions... Could you please attach to this issue the full log of running 'mvn clean verify site -X" (note the -X for debug mode)? I'll try to compare it with my output. I have currently no idea why we're getting different results... Thanks -Vincent > Clover plugin installs clover instrumented source in local repository > - > > Key: MCLOVER-53 > URL: http://jira.codehaus.org/browse/MCLOVER-53 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP Pro, Maven 2.0.4 >Reporter: Evan Tritsch > Assigned To: Vincent Massol >Priority: Minor > Attachments: usertest.zip > > > When I run "clean verify site" on a project that has the clover plugin > enabled, the clover-sources jar gets installed to the local repository, > overwriting the real sources jar. The last line of the log snippet below > shows the problem. > [INFO] [install:install] > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-clover.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\myProject-2.0-SNAPSHOT-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > It looks like the clover plugin is just using the wrong destination name for > the 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] Updated: (MCLOVER-53) Clover plugin installs clover instrumented source in local repository
[ http://jira.codehaus.org/browse/MCLOVER-53?page=all ] Evan Tritsch updated MCLOVER-53: Attachment: output.txt I noticed while looking at the log that install:install gets run twice. The first time it only installs the compiled clover jar and the regular source jar. The second time it installs the compiled clover jar, the regular source jar, and then overwrites it with the clover source jar. > Clover plugin installs clover instrumented source in local repository > - > > Key: MCLOVER-53 > URL: http://jira.codehaus.org/browse/MCLOVER-53 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP Pro, Maven 2.0.4 >Reporter: Evan Tritsch > Assigned To: Vincent Massol >Priority: Minor > Attachments: output.txt, usertest.zip > > > When I run "clean verify site" on a project that has the clover plugin > enabled, the clover-sources jar gets installed to the local repository, > overwriting the real sources jar. The last line of the log snippet below > shows the problem. > [INFO] [install:install] > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-clover.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\myProject-2.0-SNAPSHOT-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > It looks like the clover plugin is just using the wrong destination name for > the 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: (MAVENUPLOAD-1171) hibernate 3.2.0.cr5
hibernate 3.2.0.cr5 --- Key: MAVENUPLOAD-1171 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1171 Project: maven-upload-requests Issue Type: Task Reporter: Mark Hobson hibernate 3.2.0.cr5 -- 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-1172) hibernate-annotations 3.2.0.cr3
hibernate-annotations 3.2.0.cr3 --- Key: MAVENUPLOAD-1172 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1172 Project: maven-upload-requests Issue Type: Task Reporter: Mark Hobson hibernate-annotations 3.2.0.cr3 -- 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: (MNGECLIPSE-116) Embedder can't find local repository
[ http://jira.codehaus.org/browse/MNGECLIPSE-116?page=comments#action_77084 ] Eugene Kuleshov commented on MNGECLIPSE-116: No, there is no need to install Maven. Embedder component used by plugin is basically the same thing as command line Maven is using. > Embedder can't find local repository > > > Key: MNGECLIPSE-116 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-116 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.7 > Environment: WinXP, Eclipse 3.1.2, Maven2.0.4 >Reporter: Cliff Resnick > Attachments: 20060526_MNGECLIPSE-116_trunk.patch, > 20060529_MNGECLIPSE-116_trunk.patch, maven-embedder-2.0.4_fixed-dep.jar > > > I upgraded from 0.0.5 to 0.0.7 and the plugin fails to load. > Below is output from the workspace log file: > java.lang.IllegalArgumentException: When not aligning with a user install you > must specify a local repository location using the > setLocalRepositoryDirectory( File ) method. > at > org.apache.maven.embedder.MavenEmbedder.createMavenSettings(MavenEmbedder.java:699) > at org.apache.maven.embedder.MavenEmbedder.start(MavenEmbedder.java:628) > at > org.maven.ide.eclipse.Maven2Plugin.createEmbedder(Maven2Plugin.java:267) > at > org.maven.ide.eclipse.Maven2Plugin.getMavenEmbedder(Maven2Plugin.java:155) > at > org.maven.ide.eclipse.Maven2Plugin.executeInEmbedder(Maven2Plugin.java:165) > at org.maven.ide.eclipse.Maven2Plugin.start(Maven2Plugin.java:112) > at > org.eclipse.osgi.framework.internal.core.BundleContextImpl$2.run(BundleContextImpl.java:994) > at java.security.AccessController.doPrivileged(Native Method) > -- 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: (MNGECLIPSE-189) JUnit runner does not process resource filters before running
[ http://jira.codehaus.org/browse/MNGECLIPSE-189?page=comments#action_77085
]
Eugene Kuleshov commented on MNGECLIPSE-189:
It this moment I am not convinced that it will be a good idea. This is not
needed for the projects that are not using properties rewrting, but in general
we can't tell that without scanning all the properties (which is sounds like a
hack to me). More over, some other projects may want to tweak such builder and
add some other goals, for example to generate sources.
Also, running maven on the whole source tree on every change of the single
resource seem an overkill, so we would need some additional hooks into Maven to
have better control on what resources it should run. As well as allow to launch
Maven in the same VM as Eclipse...
So, once again, please raise an objective objections against closing this issue
as "worksome".
> JUnit runner does not process resource filters before running
> -
>
> Key: MNGECLIPSE-189
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-189
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
>Affects Versions: 0.0.9
> Environment: Eclipse 3.1.2 Linux
>Reporter: Jonathan Share
> Assigned To: Eugene Kuleshov
>Priority: Trivial
> Attachments: filter-test.zip
>
>
> I have a project that uses a resource filter to set the path to some files
> depending on what platform the developer is on. Using maven on the command
> line this is processed correctly and the Unit tests pass. However, I wish to
> use the JUnit runner within eclipse however as my resources do not get
> filtered before the tests try to load them I get exceptions creating URL
> objects with ${news.image.url} in them.
> Desired behaviour
> ===
> This plugin should provide a launcher for the junit runner that first runs
> the process-resources (apologies if this is wrong, writing from memory here)
> target and ensure the classpath is configured correctly so that the non
> processed resources are not available to the JUnit runner before running the
> JUnit tests.
--
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: (MIDEA-72) -DdownloadSources=true only works if sources do not already exist in local repository
-DdownloadSources=true only works if sources do not already exist in local repository - Key: MIDEA-72 URL: http://jira.codehaus.org/browse/MIDEA-72 Project: Maven 2.x Idea Plugin Issue Type: Bug Environment: Clean install of Maven 2.04. Reporter: Rob Butler Running mvn idea:idea -DdownloadSources=true will add source jars to idea project file if the source jars are downloaded (not in local repository). If the project files are deleted and the command run again the sources will not be added to the project files because they already exist in the local repository and are not downloaded. -- 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-53) Clover plugin installs clover instrumented source in local repository
[ http://jira.codehaus.org/browse/MCLOVER-53?page=comments#action_77088 ] Vincent Massol commented on MCLOVER-53: --- You're right sorry. I missed the second invocation of install:install. I also get the 3 lines. I'll have a look at what is causing it. Thanks. > Clover plugin installs clover instrumented source in local repository > - > > Key: MCLOVER-53 > URL: http://jira.codehaus.org/browse/MCLOVER-53 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP Pro, Maven 2.0.4 >Reporter: Evan Tritsch > Assigned To: Vincent Massol >Priority: Minor > Attachments: output.txt, usertest.zip > > > When I run "clean verify site" on a project that has the clover plugin > enabled, the clover-sources jar gets installed to the local repository, > overwriting the real sources jar. The last line of the log snippet below > shows the problem. > [INFO] [install:install] > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-clover.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\myProject-2.0-SNAPSHOT-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > It looks like the clover plugin is just using the wrong destination name for > the 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: (MSOURCES-10) Attached source artifact should not be added for artifacts with classifier
Attached source artifact should not be added for artifacts with classifier
--
Key: MSOURCES-10
URL: http://jira.codehaus.org/browse/MSOURCES-10
Project: Maven 2.x Sources Plugin
Issue Type: Bug
Affects Versions: 2.0.1
Reporter: Vincent Massol
Assigned To: Vincent Massol
Fix For: 2.0.2
If the main artifact has a classifier then we shouldn't attach a source
artifact to it as Maven2 only allows one classifier. Doing the attachment leads
to errors such as:
{noformat}
[INFO] Installing
C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\usertest\target\clover\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-clover.jar
to C:\Documents and
Settings\vmassol\.m2\repository\org\apache\maven\plugins\maven-clover-plugin-sample-usertest\1.0-SNAPSHOT\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-clover.jar
[INFO] Installing
C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\usertest\target\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-sources.jar
to C:\Documents and
Settings\vmassol\.m2\repository\org\apache\maven\plugins\maven-clover-plugin-sample-usertest\1.0-SNAPSHOT\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-sources.jar
[INFO] Installing
C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\usertest\target\clover\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-clover-sources.jar
to C:\Documents and
Settings\vmassol\.m2\repository\org\apache\maven\plugins\maven-clover-plugin-sample-usertest\1.0-SNAPSHOT\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-sources.jar
{noformat}
In the last line, notice the double classifier "-clover-sources" and the wrong
destination "-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] Updated: (SUREFIRE-31) support junit 4.0
[ http://jira.codehaus.org/browse/SUREFIRE-31?page=all ] Karl M. Davis updated SUREFIRE-31: -- Attachment: SUREFIRE31_karl_surefire_surefire-providers_surefire-junit_2ndMethod.patch This patch is an alternative to the other two I posted. Instead of adding JUnit4 support as a new provider, it patches the existing JUnit3 provider so that it now properly supports the "suite()" method. If you apply this patch and add a "suite()" method to your JUnit4 test classes per http://junit.sourceforge.net/doc/cookbook/cookbook.htm then the JUnit4 tests will be run and reported correctly by Surefire. > support junit 4.0 > - > > Key: SUREFIRE-31 > URL: http://jira.codehaus.org/browse/SUREFIRE-31 > Project: surefire > Issue Type: Improvement > Components: Junit 4.x support >Reporter: John Didion > Fix For: 2.1 > > Attachments: SUREFIRE-31-maven-surefire-plugin.patch, > SUREFIRE-31-surefire-trunk.patch, surefire-junit4.zip, > SUREFIRE31_karl_maven-surefire-plugin.patch, > SUREFIRE31_karl_surefire_surefire-providers_surefire-junit.patch, > SUREFIRE31_karl_surefire_surefire-providers_surefire-junit_2ndMethod.patch > > > I know this is a pretty sizable task. I just wanted to get it in the system > now that 4.0 has officially been released. Hopefully this will generate some > discussion about how 4.0 will be handled - mainly if it will require a > completely seperate implemenation of surefire (keeping the same API so it can > easily be used by the maven plugin), or if use of 4.0 will be made a > configurable option of the current surefire. > Here's some additional features I'd like to see: > 1. Ability to categorize tests. Unfortunately, 4.0 doesn't include an > @Category annotation, or make category a parameter of @Test. However, the > filtering mechanism provided by 4.0 is sufficent to support categories given > the presense of such an annotation. I recommend putting the @Category > annotation in a seperate module (surefire-annotations?) and build support for > it into surefire. Hopefully the junit guys could be convinced to incorporate > it in a later version. > 2. Similarly, support repeated tests via an @Repeated annotation. I'm not > sure how easy this would be to do external to junit. -- 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-53) Clover plugin installs clover instrumented source in local repository
[ http://jira.codehaus.org/browse/MCLOVER-53?page=comments#action_77091 ] Vincent Massol commented on MCLOVER-53: --- The error is that the Source plugin creates an attached source jar even for artifacts with classifier. See MSOURCES-10 > Clover plugin installs clover instrumented source in local repository > - > > Key: MCLOVER-53 > URL: http://jira.codehaus.org/browse/MCLOVER-53 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP Pro, Maven 2.0.4 >Reporter: Evan Tritsch > Assigned To: Vincent Massol >Priority: Minor > Attachments: output.txt, usertest.zip > > > When I run "clean verify site" on a project that has the clover plugin > enabled, the clover-sources jar gets installed to the local repository, > overwriting the real sources jar. The last line of the log snippet below > shows the problem. > [INFO] [install:install] > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-clover.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\myProject-2.0-SNAPSHOT-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > It looks like the clover plugin is just using the wrong destination name for > the 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] Commented: (MSOURCES-10) Attached source artifact should not be added for artifacts with classifier
[ http://jira.codehaus.org/browse/MSOURCES-10?page=comments#action_77092 ]
Vincent Massol commented on MSOURCES-10:
Done. Leaving open for a few days to see if there's any reaction to my patch...
> Attached source artifact should not be added for artifacts with classifier
> --
>
> Key: MSOURCES-10
> URL: http://jira.codehaus.org/browse/MSOURCES-10
> Project: Maven 2.x Sources Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Vincent Massol
> Assigned To: Vincent Massol
> Fix For: 2.0.2
>
>
> If the main artifact has a classifier then we shouldn't attach a source
> artifact to it as Maven2 only allows one classifier. Doing the attachment
> leads to errors such as:
> {noformat}
> [INFO] Installing
> C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\usertest\target\clover\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-clover.jar
> to C:\Documents and
> Settings\vmassol\.m2\repository\org\apache\maven\plugins\maven-clover-plugin-sample-usertest\1.0-SNAPSHOT\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-clover.jar
> [INFO] Installing
> C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\usertest\target\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-sources.jar
> to C:\Documents and
> Settings\vmassol\.m2\repository\org\apache\maven\plugins\maven-clover-plugin-sample-usertest\1.0-SNAPSHOT\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-sources.jar
> [INFO] Installing
> C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\usertest\target\clover\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-clover-sources.jar
> to C:\Documents and
> Settings\vmassol\.m2\repository\org\apache\maven\plugins\maven-clover-plugin-sample-usertest\1.0-SNAPSHOT\maven-clover-plugin-sample-usertest-1.0-SNAPSHOT-sources.jar
> {noformat}
> In the last line, notice the double classifier "-clover-sources" and the
> wrong destination "-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] Commented: (MCLOVER-53) Clover plugin installs clover instrumented source in local repository
[ http://jira.codehaus.org/browse/MCLOVER-53?page=comments#action_77093 ] Vincent Massol commented on MCLOVER-53: --- Fixed in MSOURCES-10. To fix the issue build the source plugin from svn trunk and the problem will go away. Waiting for a few days before closing this issue to see if my patch for MSOURCES-10 is ok with everyone... > Clover plugin installs clover instrumented source in local repository > - > > Key: MCLOVER-53 > URL: http://jira.codehaus.org/browse/MCLOVER-53 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP Pro, Maven 2.0.4 >Reporter: Evan Tritsch > Assigned To: Vincent Massol >Priority: Minor > Attachments: output.txt, usertest.zip > > > When I run "clean verify site" on a project that has the clover plugin > enabled, the clover-sources jar gets installed to the local repository, > overwriting the real sources jar. The last line of the log snippet below > shows the problem. > [INFO] [install:install] > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-clover.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\myProject-2.0-SNAPSHOT-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > It looks like the clover plugin is just using the wrong destination name for > the 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] Commented: (MCLOVER-53) Clover plugin installs clover instrumented source in local repository
[ http://jira.codehaus.org/browse/MCLOVER-53?page=comments#action_77094 ] Evan Tritsch commented on MCLOVER-53: - That fixed it for me. Thanks for taking care of this. > Clover plugin installs clover instrumented source in local repository > - > > Key: MCLOVER-53 > URL: http://jira.codehaus.org/browse/MCLOVER-53 > Project: Maven 2.x Clover Plugin > Issue Type: Bug >Affects Versions: 2.2 > Environment: Windows XP Pro, Maven 2.0.4 >Reporter: Evan Tritsch > Assigned To: Vincent Massol >Priority: Minor > Attachments: output.txt, usertest.zip > > > When I run "clean verify site" on a project that has the clover plugin > enabled, the clover-sources jar gets installed to the local repository, > overwriting the real sources jar. The last line of the log snippet below > shows the problem. > [INFO] [install:install] > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-clover.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\myProject-2.0-SNAPSHOT-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > [INFO] Installing > C:\Workspaces\Cleanroom\myProject\target\clover\myProject-2.0-SNAPSHOT-clover-sources.jar > to C:\Documents and > Settings\user\.m2\repository\system\myProject\2.0-SNAPSHOT\myProject-2.0-SNAPSHOT-sources.jar > It looks like the clover plugin is just using the wrong destination name for > the 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] Closed: (MECLIPSE-140) SNAPSHOT plugin versions are not supported for PDE projects. Error in MANIFEST.MF
[ http://jira.codehaus.org/browse/MECLIPSE-140?page=all ] fabrizio giustina closed MECLIPSE-140. -- Assignee: fabrizio giustina Resolution: Fixed Fix Version/s: 2.3 I agree that if if you're using PDE you have to abide by the OSGI versioning limitations, but since the use of the "-SNAPSHOT" suffix is a maven standard I think that handling it in plugins will make life easier for many maven/eclipse users. Fixed in svn by replacing the "-" with a comma and moving the "SNAPSHOT" version to the 4th tokens in a version string (first 3 tokens must be numeric), > SNAPSHOT plugin versions are not supported for PDE projects. Error in > MANIFEST.MF > - > > Key: MECLIPSE-140 > URL: http://jira.codehaus.org/browse/MECLIPSE-140 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug > Components: PDE support >Affects Versions: 2.3 >Reporter: David Boden > Assigned To: fabrizio giustina >Priority: Critical > Fix For: 2.3 > > Attachments: maven-eclipse-plugin-447076.patch, patch.txt > > > If the version declared in your pom.xml is 2.0.0-SNAPSHOT then the following > is written to MANIFEST.MF: > Bundle-Version: 2.0.0-SNAPSHOT > Eclipse complains: > assertion failed: The service (3rd) component of plug-in version identifier, > "2.0.0-SNAPSHOT", must be numeric. > Is the resolution to strip the "-SNAPSHOT" string off the end of the version? -- 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: (MECLIPSE-155) Stop assuming J2EE 1.3
[ http://jira.codehaus.org/browse/MECLIPSE-155?page=all ] fabrizio giustina closed MECLIPSE-155. -- Assignee: fabrizio giustina Resolution: Fixed fix committed for 2.3, thanks > Stop assuming J2EE 1.3 > -- > > Key: MECLIPSE-155 > URL: http://jira.codehaus.org/browse/MECLIPSE-155 > Project: Maven 2.x Eclipse Plugin > Issue Type: Improvement > Components: WTP support >Affects Versions: 2.2 >Reporter: Matthew Beermann > Assigned To: fabrizio giustina > Fix For: 2.3 > > Attachments: maven-eclipse-plugin.patch > > > Currently, when writing out the WTP facet settings for an EAR, the eclipse > goal is assuming J2EE version 1.3. This is a problem, as certain > functionality could be disabled or broken in the IDE if we're actually > working on a 1.4 project. The source code contains a comment saying as much. > I'm attaching a patch that does the TODO, and lets the goal sense if we're > running on J2EE 1.4. -- 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: (MECLIPSE-134) target/classes not acceptable for eclipse
[ http://jira.codehaus.org/browse/MECLIPSE-134?page=all ] fabrizio giustina closed MECLIPSE-134. -- Assignee: fabrizio giustina Resolution: Won't Fix you can already use the "outputDir" parameter in order to specify a different target dir for classes. We will leave the default as is, when running "mvn clean" you just have to refresh your eclipse project if you want to make eclipse aware of changes. > target/classes not acceptable for eclipse > - > > Key: MECLIPSE-134 > URL: http://jira.codehaus.org/browse/MECLIPSE-134 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.0, 2.1, 2.2 >Reporter: Jörg Hohwiller > Assigned To: fabrizio giustina >Priority: Minor > > "mvn eclipse:eclipse" causes an eclipse configuration where the classfiles > generated by eclipse go to the same directory as the classes generated by > maven. This is extremly evil! Eclipse and maven are independent tools and > should therefore not compile to the same target folder causing side effects. > Especially when "mvn clean" is called and you re-run an existing application > inside eclipse, and get a NoClassDefFoundError you can get slightly confused. > Please use anything else than "target/...". My suggestion would be > ".eclipse-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: (MIDEA-73) Plugin configuration not being picked up from parent pom.xml
Plugin configuration not being picked up from parent pom.xml Key: MIDEA-73 URL: http://jira.codehaus.org/browse/MIDEA-73 Project: Maven 2.x Idea Plugin Issue Type: Bug Affects Versions: 2.0 Reporter: Charles Crouch If I include the following snippet in my regular pom.xml, mvn idea:idea works as expected. org.apache.maven.plugins maven-idea-plugin 1.5.0_07 However if I include it in a parent/grandparent pom, the configuration property is not picked up and I get the "[INFO] jdkName is not set" message when running mvn idea:idea. Several other plugins have their configuration properties set from a parent pom, so I don't think this is a general mvn issue. -- 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-1577) dependencyManagement does not work for transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1577?page=comments#action_77104 ] Mike Perham commented on MNG-1577: -- Anyone tried the patch yet? I'm considering upgrading us to use a patched binary to get this fix. > dependencyManagement does not work for transitive dependencies > -- > > Key: MNG-1577 > URL: http://jira.codehaus.org/browse/MNG-1577 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0 >Reporter: Joerg Schaible > Fix For: 2.1 > > Attachments: mng1577.patch, mng1577a.patch > > > The dependencyManagement does not work for transient dependencies. The > specified version is ignored. > Use case: > Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT > and B-SNAPSHOT > Project A is child of Main and depends directly on commons-beanutils (version > inherited from Main) > Project B is child of Main and depends directly on commons-digester (version > inherited from Main) > Project C is child of Main and depends directly on A & B (versions inherited > from Main) > A is compiled and tests are run using commons-beanutils-1.7.0 > B is compiled and tests are run using commons-digester-1.6 and > commons-beanutils-1.6, since digester is dependend on this > C is compiled and tests are run using commons-beanutils-1.7.0 > Integration tests of B did not verify, that B is behaving as expected in this > scenario. B might fail with 1.7.0 and it is not even recognized. > If I add beanutils also as direct dependency to B, it works fine, but then > are transitive dependency useless. It should be possible to define at least > in the dependencyManagement, that the versions of transient dependencies also > defined in the dependencyManagement have priority. > - Jörg -- 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-1577) dependencyManagement does not work for transitive dependencies
[ http://jira.codehaus.org/browse/MNG-1577?page=comments#action_77108 ] Ralph Goers commented on MNG-1577: -- Pleaes wait until the end of the week. It was requested that I provide unit tests along with the patch. I've had a little trouble with that as Maven without the patches doesn't seem to handle DependencyManagement as documented. I'm going to try to talk to some of the Maven committers at ApacheCon this week to see if I can't get this put to bed. > dependencyManagement does not work for transitive dependencies > -- > > Key: MNG-1577 > URL: http://jira.codehaus.org/browse/MNG-1577 > Project: Maven 2 > Issue Type: Bug > Components: Artifacts and Repositories >Affects Versions: 2.0 >Reporter: Joerg Schaible > Fix For: 2.1 > > Attachments: mng1577.patch, mng1577a.patch > > > The dependencyManagement does not work for transient dependencies. The > specified version is ignored. > Use case: > Main POM defines commons-digester-1.6 and commons-beanutils-1.7.0, A-SNAPSHOT > and B-SNAPSHOT > Project A is child of Main and depends directly on commons-beanutils (version > inherited from Main) > Project B is child of Main and depends directly on commons-digester (version > inherited from Main) > Project C is child of Main and depends directly on A & B (versions inherited > from Main) > A is compiled and tests are run using commons-beanutils-1.7.0 > B is compiled and tests are run using commons-digester-1.6 and > commons-beanutils-1.6, since digester is dependend on this > C is compiled and tests are run using commons-beanutils-1.7.0 > Integration tests of B did not verify, that B is behaving as expected in this > scenario. B might fail with 1.7.0 and it is not even recognized. > If I add beanutils also as direct dependency to B, it works fine, but then > are transitive dependency useless. It should be possible to define at least > in the dependencyManagement, that the versions of transient dependencies also > defined in the dependencyManagement have priority. > - Jörg -- 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
