[jira] Commented: (MNG-1957) clause in the activation section has to provide more complex expressions.
[ http://jira.codehaus.org/browse/MNG-1957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163525#action_163525 ] Joerg Schaible commented on MNG-1957: - Guys, please take into account that you probably do not get what you try to reach. Especially Edwin's use case will not work. By declaring different dependencies in profiles that are automatically activated based on the used JDK you all implicitly assume that this is also the target JDK. This assumption is false! Have a look at the error reports in MNG-3957 caused by such profiles in spring-core-ws and XStream. Both POMs declare different deps depending on the JDK. If a client now declares a different target JDK than the one he uses to run Maven, he gets the wrong transitive dependencies. > clause in the activation section has to provide more complex > expressions. > - > > Key: MNG-1957 > URL: http://jira.codehaus.org/browse/MNG-1957 > Project: Maven 2 > Issue Type: Improvement > Components: POM >Affects Versions: 2.0, 2.0.1 >Reporter: Trustin Lee > Fix For: 2.0.11, 2.1.0-M2 > > Attachments: MNG-1957-maven-project.patch > > > For now, provides only one operator '!' which means negation, but > it would be great if i can use '+' and ~ operator: > 1.5+ > 1.1 ~ 1.4 > ~ 1.3 > 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] Commented: (MWAR-33) jars with differents versions can be in WEB-INF/lib with war as dependencies
[ http://jira.codehaus.org/browse/MWAR-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163567#action_163567 ] Alex Rau commented on MWAR-33: -- Huge show stopper for us. We extend a 3rd party product and the current state of the WAR plugin forces us to redeclare > 100 3rd party dependencies which is practically *impossible*. Brett - IMHO you described a proper solution (ignore/empty out WEB-INF/lib, resolve *all* deps only using project descriptors). Is this really that tricky to implement (sounds like loads of efforts) - especially considering that this issue is years old - what about current versions of maven ? Regarding WEB-INF/lib: there's no point in using a tool like Maven for dependency management and then rely on plain old files (like ant) for web applications - this is definitely not following the "declaration" concept of Maven. > jars with differents versions can be in WEB-INF/lib with war as dependencies > > > Key: MWAR-33 > URL: http://jira.codehaus.org/browse/MWAR-33 > Project: Maven 2.x War Plugin > Issue Type: Bug > Environment: all >Reporter: Olivier Lamy >Assignee: Stephane Nicoll > Fix For: 2.1 > > Original Estimate: 15 minutes > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > > My pom has the following dependencies : > - log4j:log4j:1.2.13 > - a war with log4j:log4j:1.2.11 included > Result the two jars are in WEB-INF/lib. -- 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
Beginner with Maven
Please, I am a beginner with the Maven "apache-maven-2.0.9", and I installed it and set the environment variables, then I tried to run just the command "mvn clean" but on plugins jars are downloaded as I read in the tutorials The picture show the error http://www.nabble.com/file/p21793246/untitled.jpeg Please HELP me, Thanks in advance. -- View this message in context: http://www.nabble.com/Beginner-with-Maven-tp21793246p21793246.html Sent from the Maven - Issues mailing list archive at Nabble.com.
[jira] Commented: (MNG-3685) Dependency can't be resolved but has been found in the reactor.
[ http://jira.codehaus.org/browse/MNG-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163598#action_163598 ] Torben S. Giesselmann commented on MNG-3685: Could someone provide a sample project? > Dependency can't be resolved but has been found in the reactor. > --- > > Key: MNG-3685 > URL: http://jira.codehaus.org/browse/MNG-3685 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.9 >Reporter: Jörg Hohwiller > Fix For: 2.0.11 > > > Since I upgraded maven to 2.0.9, I get messages like the following endlessly: > Downloading: > http://m-m-m.sourceforge.net/repository/net/sf/m-m-m/mmm-util-core/1.0.2-SNAPSHOT/mmm-util-core-1.0.2-SNAPSHOT.jar > [WARNING] The dependency: net.sf.m-m-m:mmm-util-core:jar:1.0.2-SNAPSHOT can't > be resolved but has been found in the reactor. > This dependency has been excluded from the plugin execution. You should rerun > this mojo after executing mvn install. > This also happens, if someone checks out the project and does "mvn > eclipse:eclipse". The process still works but takes extraordinary long to > proceed because it scales about n^2 with n beiing the number of modules in > your reactor. > You should also take into account that "mvn install" aborts if some tests > fail. > Sorry to say so, but this behaviour of maven is absolutely inacceptable. I > hope there is a chance to fix this in the next release(s). 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: (MSANDBOX-44) maven-truezip-plugin: after processing with truezip in package phs., out-of-date resource is installed into repo in install phs.
maven-truezip-plugin: after processing with truezip in package phs.,
out-of-date resource is installed into repo in install phs.
Key: MSANDBOX-44
URL: http://jira.codehaus.org/browse/MSANDBOX-44
Project: Maven 2.x Sandbox
Issue Type: Bug
Environment: Windows XP, Maven 2.0.9, maven-truezip 1.0-beta-1-SNAPSHOT
Reporter: Rasto Cesnek
In the section, I use truzip plugin bound to package phase to
manipulate a large archive (a 12M SAR file) to remove unwanted stuff from the
packaging (remove **/META-INF/maven/ directories from dependent JARs, etc.).
When I ran "mvn clean install", the plugin scans the SAR file during the
package phase. Then the install phase follows. When the build finishes, the SAR
file in the /target folder is correct - all META-INF/maven directories removed.
How ever, the file which is installed during the install phase IS NOT CORRECT,
it still contains all the META-INF/maven directories in it. When observing the
behavior closely, it looks like the file manipulated by truezip is NOT YET
UPDATED on the file system, when the install phase runs. It seems, that it gets
updated after the install pahse finishes - shortly before the entire maven
build finishes.
The expected behavior would be, that the file processed by truezip lands in the
repo after install.
Is this connected to OS (Windows XP) and some file cacheing? May it have
something to do with the file size? A threading problem?
org.codehaus.mojo
truezip-maven-plugin
1.0-beta-1-SNAPSHOT
remove maven metas from jars
remove
package
${project.build.directory}/${project.build.finalName}.sar/
**/META-INF/maven/
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: (JXR-65) FileNotFoundException with different drives
[
http://jira.codehaus.org/browse/JXR-65?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163532#action_163532
]
Pieter Degraeuwe commented on JXR-65:
-
I have exactly the same problem. Any solutions/workarounds available yet ?
> FileNotFoundException with different drives
> ---
>
> Key: JXR-65
> URL: http://jira.codehaus.org/browse/JXR-65
> Project: Maven JXR
> Issue Type: Bug
> Environment: Windows
>Reporter: Mickaël MORIER
>
> Suppose:
> 1 - I worked on Windows
> 2 - My project is stored on drive letter C
> 3 - I want to generate site:stage in a directory which is stored on drive
> letter D
> JXR generate a FileNotFoundException because project directory and staging
> directory are on different drives.
> Below this exception:
> {quote}
> [INFO] Generating "Source Xref" report.
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Error during page generation
> Embedded error: Error rendering Maven report: Error while generating the HTML
> source code of the projet.
> D:\Temp\melovie-site\localhost\data\maven\sites\melovie\melovie-common\tedi-client\xref\fr\generali\tedi\adresse\constants\Constants.html
> and C:\dev\projects\melovie\melovie-common\tedi-client\target\
> site\apidocs have no common parent.
> [INFO]
>
> [INFO] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error during page
> generation
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:583)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:291)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> at java.lang.reflect.Method.invoke(Method.java:585)
> at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
> at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
> at
> org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
> at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
> Caused by: org.apache.maven.plugin.MojoExecutionException: Error during page
> generation
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:101)
> at
> org.apache.maven.plugins.site.SiteStageMojo.execute(SiteStageMojo.java:105)
> at
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
> at
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:558)
> ... 16 more
> Caused by: org.apache.maven.doxia.siterenderer.RendererException: Error
> rendering Maven report: Error while generating the HTML source code of the
> projet.
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:149)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.renderModule(DefaultSiteRenderer.java:269)
> at
> org.apache.maven.doxia.siterenderer.DefaultSiteRenderer.render(DefaultSiteRenderer.java:101)
> at
> org.apache.maven.plugins.site.SiteMojo.renderLocale(SiteMojo.java:129)
> at org.apache.maven.plugins.site.SiteMojo.execute(SiteMojo.java:96)
> ... 19 more
> Caused by: org.apache.maven.reporting.MavenReportException: Error while
> generating the HTML source code of the projet.
> at
> org.apache.maven.plugin.jxr.AbstractJxrReport.executeReport(AbstractJxrReport.java:417)
> at
> org.apache.maven.reporting.AbstractMavenReport.generate(AbstractMavenReport.java:101)
> at
> org.apache.maven.plugins.site.ReportDocumentRenderer.renderDocument(ReportDocumentRenderer.java:139)
>
[jira] Commented: (MNG-3989) Simple handling of external jars
[ http://jira.codehaus.org/browse/MNG-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163540#action_163540 ] Anders Kr. Andersen commented on MNG-3989: -- And one more thing... I have problems with developers that sits and uploads files into the repository from here and there, the earth, moon, or from an other planet, without documenting where the things comes from. So on my last project I required from all developers (sub projects) that they decared a directory "repository" with thse 3'rd party libraries. And then we had a shell script that uploaded the stuff to repository. So the point here is to give maven projects a place to document this act. > Simple handling of external jars > > > Key: MNG-3989 > URL: http://jira.codehaus.org/browse/MNG-3989 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.9 >Reporter: Greg Wilkins > > For whatever reason, there will always be jars that don't exist in a maven > repository. > There are numerous techniques for these - installing them in your local repo > (either manually or with > some bootstrap.sh script or special profile activation). Checking in the > jars into a local maven repository that is checked into svn > and then point to it from your settings.xml and/or top level pom (with aid of > an env variable). > But all these methods lack a very important features. You can just do: "svn > co http:/myproj.com/foo; cd foo; mvn" > If the jars change, you can't just do "svn up; mvn", you have to re-run > whatever script/profile installed the repo. > It's all rather a PITA. > What I want, is some way to have a module of a project that contains some > non-maven jars that when I > do a "mvn install" in that project, install those jars in my local repository > for use by my other modules. If the > jars are not updated, then nothing is done. > With something like this, projects that have external dependencies could > describe them to maven and > make them available for use, without manual steps and special scripts. -- 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: (MSANDBOX-44) maven-truezip-plugin: after processing with truezip in package phs., out-of-date resource is installed into repo in install phs.
[
http://jira.codehaus.org/browse/MSANDBOX-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163541#action_163541
]
Rasto Cesnek commented on MSANDBOX-44:
--
Probably, some update() or unmount() on the de.schlichtherle.io.File instances
used at some appropriate points will solve this issue.
Otherwise, it looks like the closing of the file happens at finalization time,
which is indeed to late.
> maven-truezip-plugin: after processing with truezip in package phs.,
> out-of-date resource is installed into repo in install phs.
>
>
> Key: MSANDBOX-44
> URL: http://jira.codehaus.org/browse/MSANDBOX-44
> Project: Maven 2.x Sandbox
> Issue Type: Bug
> Environment: Windows XP, Maven 2.0.9, maven-truezip
> 1.0-beta-1-SNAPSHOT
>Reporter: Rasto Cesnek
>
> In the section, I use truzip plugin bound to package phase to
> manipulate a large archive (a 12M SAR file) to remove unwanted stuff from the
> packaging (remove **/META-INF/maven/ directories from dependent JARs, etc.).
> When I ran "mvn clean install", the plugin scans the SAR file during the
> package phase. Then the install phase follows. When the build finishes, the
> SAR file in the /target folder is correct - all META-INF/maven directories
> removed. How ever, the file which is installed during the install phase IS
> NOT CORRECT, it still contains all the META-INF/maven directories in it. When
> observing the behavior closely, it looks like the file manipulated by truezip
> is NOT YET UPDATED on the file system, when the install phase runs. It seems,
> that it gets updated after the install pahse finishes - shortly before the
> entire maven build finishes.
> The expected behavior would be, that the file processed by truezip lands in
> the repo after install.
> Is this connected to OS (Windows XP) and some file cacheing? May it have
> something to do with the file size? A threading problem?
>
> org.codehaus.mojo
> truezip-maven-plugin
> 1.0-beta-1-SNAPSHOT
>
>
>
> remove maven metas from jars
>
> remove
>
> package
>
>
>
> ${project.build.directory}/${project.build.finalName}.sar/
>
>
> **/META-INF/maven/
>
>
> 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: (MNG-3989) Simple handling of external jars
[ http://jira.codehaus.org/browse/MNG-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163539#action_163539 ] Anders Kr. Andersen commented on MNG-3989: -- Hi Greg It seems like it is up to you to come with a solution :-) I have the same issue with weblogic jar files. What we need is a well defined way to load artifacts as jar,war, zip etc into a repository. mostly local repository Consider we made a plugin that could: a) read from a directory "repository" and load all files it finds there into repository. Where the maven coordinaes will be read from the file structure. (so repository should be structured as a maven 2 repository) b) construct poms as long as they where not there. I think this could be great. The problem I have left is to get mvn clean install executed on this pom, so developers can get started ? > Simple handling of external jars > > > Key: MNG-3989 > URL: http://jira.codehaus.org/browse/MNG-3989 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.9 >Reporter: Greg Wilkins > > For whatever reason, there will always be jars that don't exist in a maven > repository. > There are numerous techniques for these - installing them in your local repo > (either manually or with > some bootstrap.sh script or special profile activation). Checking in the > jars into a local maven repository that is checked into svn > and then point to it from your settings.xml and/or top level pom (with aid of > an env variable). > But all these methods lack a very important features. You can just do: "svn > co http:/myproj.com/foo; cd foo; mvn" > If the jars change, you can't just do "svn up; mvn", you have to re-run > whatever script/profile installed the repo. > It's all rather a PITA. > What I want, is some way to have a module of a project that contains some > non-maven jars that when I > do a "mvn install" in that project, install those jars in my local repository > for use by my other modules. If the > jars are not updated, then nothing is done. > With something like this, projects that have external dependencies could > describe them to maven and > make them available for use, without manual steps and special scripts. -- 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: (MSANDBOX-44) maven-truezip-plugin: after processing with truezip in package phs., out-of-date resource is installed into repo in install phs.
[
http://jira.codehaus.org/browse/MSANDBOX-44?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163557#action_163557
]
Rasto Cesnek commented on MSANDBOX-44:
--
Adding a code snipplet:
try {
File.update();
} catch (ArchiveException e) {
throw new MojoExecutionException( "Update() failed.", e );
}
to the end of the execute() of the copy, move and delete MOJOs solves the
problem. The install phase then works with a correctly upated archive. The only
drawback is that if there are more executions, the update happens after each
execution, i.e. the entire files is flushed after each execution.
Another possiblity I used was to create a simple update MOJO, which does
nothing else in execute but the above code snipplet. I added this execution as
the last one in the list of executions. This also solves the problem, the
drawback is that one has to think about it and remember that he may need to
flush the changes performed by truezip plugin before proceeding with the build.
Is there some clever possiblity in Maven how to implement this clean-up task at
the appropriate moments i.e. so that when the processing of goals for a given
phase finishes, the manipulated archives are updated?
> maven-truezip-plugin: after processing with truezip in package phs.,
> out-of-date resource is installed into repo in install phs.
>
>
> Key: MSANDBOX-44
> URL: http://jira.codehaus.org/browse/MSANDBOX-44
> Project: Maven 2.x Sandbox
> Issue Type: Bug
> Environment: Windows XP, Maven 2.0.9, maven-truezip
> 1.0-beta-1-SNAPSHOT
>Reporter: Rasto Cesnek
>
> In the section, I use truzip plugin bound to package phase to
> manipulate a large archive (a 12M SAR file) to remove unwanted stuff from the
> packaging (remove **/META-INF/maven/ directories from dependent JARs, etc.).
> When I ran "mvn clean install", the plugin scans the SAR file during the
> package phase. Then the install phase follows. When the build finishes, the
> SAR file in the /target folder is correct - all META-INF/maven directories
> removed. How ever, the file which is installed during the install phase IS
> NOT CORRECT, it still contains all the META-INF/maven directories in it. When
> observing the behavior closely, it looks like the file manipulated by truezip
> is NOT YET UPDATED on the file system, when the install phase runs. It seems,
> that it gets updated after the install pahse finishes - shortly before the
> entire maven build finishes.
> The expected behavior would be, that the file processed by truezip lands in
> the repo after install.
> Is this connected to OS (Windows XP) and some file cacheing? May it have
> something to do with the file size? A threading problem?
>
> org.codehaus.mojo
> truezip-maven-plugin
> 1.0-beta-1-SNAPSHOT
>
>
>
> remove maven metas from jars
>
> remove
>
> package
>
>
>
> ${project.build.directory}/${project.build.finalName}.sar/
>
>
> **/META-INF/maven/
>
>
> 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] Updated: (MNG-3989) Simple handling of external jars
[ http://jira.codehaus.org/browse/MNG-3989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MNG-3989: -- Attachment: MNG-3989.zip hey Greg - this structure seems closest to what you are looking for without making modifications. IS it on the right track for what you were looking for? You can do a bit more by using the dependency plugin or install:install-file (eg, generate POMs), but you still tend to end up with a separate module and declarations can be quite lengthy. Beyond that it is getting towards writing a custom plugin to copy files directly into the local repository. In any of these cases, it'll result in a transitive closure that won't be resolvable if the project is deployed into the repository without copying the repository module around (which is probably ok in situations like the weblogic one mentioned). I'd still be reluctant to build this right into Maven given the number of alternatives available, though. > Simple handling of external jars > > > Key: MNG-3989 > URL: http://jira.codehaus.org/browse/MNG-3989 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.9 >Reporter: Greg Wilkins > Attachments: MNG-3989.zip > > > For whatever reason, there will always be jars that don't exist in a maven > repository. > There are numerous techniques for these - installing them in your local repo > (either manually or with > some bootstrap.sh script or special profile activation). Checking in the > jars into a local maven repository that is checked into svn > and then point to it from your settings.xml and/or top level pom (with aid of > an env variable). > But all these methods lack a very important features. You can just do: "svn > co http:/myproj.com/foo; cd foo; mvn" > If the jars change, you can't just do "svn up; mvn", you have to re-run > whatever script/profile installed the repo. > It's all rather a PITA. > What I want, is some way to have a module of a project that contains some > non-maven jars that when I > do a "mvn install" in that project, install those jars in my local repository > for use by my other modules. If the > jars are not updated, then nothing is done. > With something like this, projects that have external dependencies could > describe them to maven and > make them available for use, without manual steps and special scripts. -- 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-3999) validation of Id's too restrictive
[ http://jira.codehaus.org/browse/MNG-3999?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163537#action_163537 ] Anders Kr. Andersen commented on MNG-3999: -- ~ is the symbol for home directory on unix > validation of Id's too restrictive > -- > > Key: MNG-3999 > URL: http://jira.codehaus.org/browse/MNG-3999 > Project: Maven 2 > Issue Type: Improvement > Components: POM > Environment: xp, SAP NetWeaver, maven 2.x >Reporter: Sven Pressler > Attachments: pom.xml > > > I guess the validation of the Id's were introduced after issue MNG-801. > I think the validation is too strong. > The problem is that a lot of valid filenames are not validated as true. > The problem is caused by the DefaultModelValidator: private static final > String ID_REGEX = "[A-Za-z0-9_\\-.]+"; > This regular expression is far too restrictive since something like > "x=+%$§~!#^.jar" would be a valid filename on a windows operating system > I stumbled upon this because I'm developing tools for SAP NetWeaver, > currently we still use maven 1 to build our projects but we're in the process > of upgrading to maven 2. > maven 1 doesn't have this problem, since Id's didn't get validated like that. > Problem is SAP have a lot of libraries that have '~' in their names, like > 'tc~epbc~pcm~adminapi~java-5.x.y.jar'. Doesn't look any good, I don't like > it, I didn't make it like that but I have to work with it. > Maybe someone can explain why it's a good idea to be that restrictive about > the Ids, but as far as I see it, it's more like: before MNG-801 there was no > validation, and after MNG-801 there was some validation, and until now, there > was not too much complaining about it. > Attached is a pom which produces the following when trying to run mvn install: > Project ID: group:com~company~my~project > Validation Messages: > [0] 'artifactId' with value 'com~company~my~project' does not match a > valid id pattern. > Reason: Failed to validate POM for project group:com~company~my~project at > C:\test\validate\pom.xml > [INFO] > > [INFO] Trace > org.apache.maven.reactor.MavenExecutionException: Failed to validate POM for > project group:com~company~my~project at C:\test\validate\pom.xml > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:378) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:292) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:287) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.project.InvalidProjectModelException: Failed to > validate POM for project group:com~company~my~project at > C:\test\validate\pom.xml > at > org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:1108) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildInternal(DefaultMavenProjectBuilder.java:878) > at > org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFileInternal(DefaultMavenProjectBuilder.java:506) > at > org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:198) > at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:583) > at > org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:461) > at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:365) > ... 11 more -- 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-4018) Maven doesn't resolve correct the dependency with classifier in the multi-part project.
Maven doesn't resolve correct the dependency with classifier in the multi-part project. Key: MNG-4018 URL: http://jira.codehaus.org/browse/MNG-4018 Project: Maven 2 Issue Type: Bug Environment: *) Fedora release 8 (Werewolf) *) java version "1.6.0_06" Java(TM) SE Runtime Environment (build 1.6.0_06-b02) *) Maven version: 2.0.9 Reporter: Veniamin Avakov Attachments: creation_log.txt, creation_log_alone.txt, workspace_project_mistake.tar.gz Dear Maven-Community, Last Thursday I have got a mistake in the build of my project. At first I was trying to check all pom-files in my project, but I couldn't find the cause or what I did wrong. Therefore I created a small project which a small copy of my project is. It seems to me, that this mistake, which I have got, is the the bug of maven. So, I have a multi-module project (5 parts): 1) The "project_maven_base" - this project contains the parent pom of all my projects. 2) The "project" - this project contains the general or abstract classes: for example 'EasyDate' 3) The "project_test" - this project contains the classes which use classes from the project "project". Furthermore this project contains the test-classes which are used in other projects, for example 'DateWrapperTest'. 4) The "project_web" - this project is a normal web-project. But it contains the test-classes which base upon the test-classes from project "project-test". These test-classes from the project "project-test" are included with the scope "test". project project_test 0.0.1-SNAPSHOT tests test 5) The "project_test_web" - this project is a normal web-project too. But this project contains the test business logic which uses the test-classes from the project "project-test" with the scope compile, for example class 'TestClient' uses the class 'DateWrapperTest'. The dependency is: project project_test 0.0.1-SNAPSHOT tests compile If the build is executed from parent project, all modules could be created except for "project_test_web", see the 'creation_log.txt' - File. The dependencies couldn't be resolved for this project. The library 'project_test-0.0.1-SNAPSHOT-tests.jar' couldn't be found. But if I try to create the project "project_test_web" as stand-alone project, then the project build is successful, see the 'creation_log_alone' - File. It seems to me, that if the dependency with classifier is used in the previous project, than this dependency can be used in the next project only with the same scope. Thanks a lot Best regards Veniamin -- 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-524) Cannot use "Run As Java Application/JUnit Test" (classpath problem) with ejb-client dependecy and "Resolve dependencies from Workspace projects"
Cannot use "Run As Java Application/JUnit Test" (classpath problem) with ejb-client dependecy and "Resolve dependencies from Workspace projects" Key: MECLIPSE-524 URL: http://jira.codehaus.org/browse/MECLIPSE-524 Project: Maven 2.x Eclipse Plugin Issue Type: Bug Components: WTP support Environment: M2Eclipse with WTP Support 0.9.7.200811301806 Reporter: David Causse Attachments: m2bug.tgz With 2 module mod1 mod2 and mod2 refering mod1 ejb-client, classpath is wrong when running unit test or Java Application : ClassNotFoundException for mod1 classes. This does not happen with ejb dependecy and does not happen with no workspace project dependencies. Test case attached. Import attached "m2bug" and try to run unit test in module2/src/test/java/m2bug/M1Test You'll get ClassNotFoundException if "Resolve dependencies from Workspace projects" is checked on module2. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-379) The SCP commands in site use a proxy if an HTTP proxy is defined, but doesn't abide to the nonProxyHosts.
[ http://jira.codehaus.org/browse/MSITE-379?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Jackson updated MSITE-379: Attachment: pom copy.xml Attached is our organization's super POM, with just some internal server names changed. I double and tripled check that I had all the appropriate versions that included MSITE-211 before I submitted this bug, including maven-site-plugin:2.0-beta-7 and wagon-ssh:1.0-beta-3. > The SCP commands in site use a proxy if an HTTP proxy is defined, but doesn't > abide to the nonProxyHosts. > - > > Key: MSITE-379 > URL: http://jira.codehaus.org/browse/MSITE-379 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: site:deploy >Affects Versions: 2.0-beta-7 > Environment: Mac OS X 10.5, Maven 2.0.8 >Reporter: Brian Jackson > Attachments: pom copy.xml > > > I setup an HTTP proxy in my settings.xml and it breaks the site:deploy plugin > which is set to SCP to an internal server. This is due to the wagon-ssh > using the HTTP proxy settings but not abiding to the nonProxyHosts. If I add > the following to my settings.xml, my build works again: > > > espn.proxy > http > examplehttpproxy.espn3.com > 8080 > *.espn3.com > > > > espn.proxy.scp > scp > dummy > 1234 > *.espn3.com > > -- 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-4019) Unrecognised association "exclude" in pom parsing in 2.0.10-RC10
Unrecognised association "exclude" in pom parsing in 2.0.10-RC10 Key: MNG-4019 URL: http://jira.codehaus.org/browse/MNG-4019 Project: Maven 2 Issue Type: Bug Components: POM Affects Versions: 2.0.10 Environment: XP SP3, Java 1.5.0_12-b04, Maven 2.0.10-RC10 2/1/09. Reporter: Bob Fields Priority: Critical Attachments: 209Debug.log, 210Debug.log, pom.xml Fails in Maven 2.0.10-RC10, works in 2.0.8 and 2.0.9. pom.xml containing the following: src/java **/*.java Fails with: org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. Reason: Unrecognised association: 'excludes' (position: START_TAG seen ...\ ... @138:31) for project unknown:andromda-metafacades-uml at C:\workspaces\A34\andromda34\metafacades\uml\pom.xml Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error reading POM. Reason: Unrecognised association: 'excludes' (position: START_TAG seen ...\r\n... @138:31) for project unknown:andromda-metafacades-uml at C:\workspaces\A34\andromda34\metafacades\uml\pom.xml at org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1591) Not sure if this is related to http://jira.codehaus.org/browse/MNG-3680 pom.xml and mvn -X output from 2.0.9 and 2.0.10 attached. Pom file is from AndroMDA: http://team.andromda.org/docs/source-repository.html under directory metafacades\uml. -- 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-4019) Unrecognised association "exclude" in pom parsing in 2.0.10-RC10
[ http://jira.codehaus.org/browse/MNG-4019?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163619#action_163619 ] Bob Fields commented on MNG-4019: - Oops, I meant to say 2.0.10-RC8, built on 2/1/09, downloaded from http://people.apache.org/~brianf/staging-repository2/org/apache/maven/apache-maven/2.0.10-RC8. > Unrecognised association "exclude" in pom parsing > in 2.0.10-RC10 > > > Key: MNG-4019 > URL: http://jira.codehaus.org/browse/MNG-4019 > Project: Maven 2 > Issue Type: Bug > Components: POM >Affects Versions: 2.0.10 > Environment: XP SP3, Java 1.5.0_12-b04, Maven 2.0.10-RC10 2/1/09. >Reporter: Bob Fields >Priority: Critical > Attachments: 209Debug.log, 210Debug.log, pom.xml > > > Fails in Maven 2.0.10-RC10, works in 2.0.8 and 2.0.9. pom.xml containing the > following: > > > src/java > > **/*.java > > > Fails with: > org.apache.maven.reactor.MavenExecutionException: Parse error reading POM. > Reason: Unrecognised association: 'excludes' (position: START_TAG seen > ...\ > ... @138:31) for project > unknown:andromda-metafacades-uml at > C:\workspaces\A34\andromda34\metafacades\uml\pom.xml > Caused by: org.apache.maven.project.InvalidProjectModelException: Parse error > reading POM. Reason: Unrecognised association: 'excludes' (position: > START_TAG seen ...\r\n... @138:31) > for project unknown:andromda-metafacades-uml at > C:\workspaces\A34\andromda34\metafacades\uml\pom.xml > at > org.apache.maven.project.DefaultMavenProjectBuilder.readModel(DefaultMavenProjectBuilder.java:1591) > Not sure if this is related to http://jira.codehaus.org/browse/MNG-3680 > pom.xml and mvn -X output from 2.0.9 and 2.0.10 attached. Pom file is from > AndroMDA: http://team.andromda.org/docs/source-repository.html under > directory metafacades\uml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (SUREFIRE-377) When JUnit and TestNG tests are in same project, only one set gets run
[ http://jira.codehaus.org/browse/SUREFIRE-377?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163624#action_163624 ] James Kato commented on SUREFIRE-377: - Hi, I am trying to run both JUnit 4.4 and TestNG 5.8 tests in the same suite. I seem to have come accross this problem in surefire 2.4.3 where as soon as I add testNG as a dependency, the TestNG runner is used. The problem is that this runner cannot handle JUnit 4.4 tests: I get: Running TestSuite org.testng.TestNGException: Failure in JUnit mode for class com.sampleTest: could not create/run JUnit test suite: cannot retrieve JUnit method Which is resolved if I extend TestCase in com.sampleTest as in JUnit 3.x A sample of the pom.xml I use is: org.testng testng 5.8 test jdk15 junit junit 4.4 test org.apache.maven.plugins maven-surefire-plugin 2.4.3 junit true Note, at present I would be happy to run all JUnit 4.4 tests in one execution and then use a profile to run all TestNG tests. Please can you tell me whether you know of a work around for this? Cheers, James > When JUnit and TestNG tests are in same project, only one set gets run > -- > > Key: SUREFIRE-377 > URL: http://jira.codehaus.org/browse/SUREFIRE-377 > Project: Maven Surefire > Issue Type: Bug > Components: TestNG support >Affects Versions: 2.4 >Reporter: Dan Fabulich > Fix For: 2.4 > > Attachments: surefire377.patch, testng-junit-together.zip > > > The attached Maven project has two tests: one JUnit test and one TestNG test. > According to the documentation, in this case TestNG should run both tests. > Run "mvn test". Only the TestNG test will run. If you modify the pom to set > the property "junit=true", only the JUnit test will run. > > org.apache.maven.plugins > maven-surefire-plugin > 2.4-SNAPSHOT > > > > junit > 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: (MERCURY-82) replace Nexus with jetty based RW server
[ http://jira.codehaus.org/browse/MERCURY-82?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=163633#action_163633 ] Oleg Gusakov commented on MERCURY-82: - replaced with plexus-webdav servlet > replace Nexus with jetty based RW server > > > Key: MERCURY-82 > URL: http://jira.codehaus.org/browse/MERCURY-82 > Project: Mercury > Issue Type: Sub-task > Components: Repository >Affects Versions: 1.0.0-alpha-4 >Reporter: Oleg Gusakov >Assignee: Oleg Gusakov > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MERCURY-82) replace Nexus with jetty based RW server
replace Nexus with jetty based RW server Key: MERCURY-82 URL: http://jira.codehaus.org/browse/MERCURY-82 Project: Mercury Issue Type: Sub-task Components: Repository Affects Versions: 1.0.0-alpha-4 Reporter: Oleg Gusakov Assignee: Oleg Gusakov -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
