[jira] Updated: (MWAR-218) Missed XSD Schema for the file webapp-cache.xml
[ http://jira.codehaus.org/browse/MWAR-218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll updated MWAR-218: - Affects Version/s: (was: 2.0) 2.1-beta-1 > Missed XSD Schema for the file webapp-cache.xml > --- > > Key: MWAR-218 > URL: http://jira.codehaus.org/browse/MWAR-218 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement >Affects Versions: 2.1-beta-1 >Reporter: Felipe Gaúcho > > When packaging a web-application, maven-war-plugin generates a cache file, as > described here: > http://maven.apache.org/plugins/maven-war-plugin/exploded-mojo.html#cacheFile > This cache file is an XML file but the generated file doesn't contains an > Schema or DTD declaration on its header. This makes impossible to validate > such file, generating warnings in the most common Java IDEs. Since it is a > mandatory XML file I believe it should has a model specification somewhere (a > XSD Schema I hope), eventually just not released for public usage. > The steps I expect to make Maven 2 WAR plugin better: > - to modify the generator of the webapp-cache.xml file to include the proper > XML header (with namespace and schema location) > - to make the schema of such file publicly available, in order to give the > developers and automatic tools a chance to validate any error in a deployable > artifact. > This will give us a chance to detect potential bugs before to deploy a > web-application. > --- The expected header is something like: > > http://maven.apache.org/plugins/maven-war-plugin"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/plugins/maven-war-plugin > http://maven.apache.org/???/???.xsd";> > ... > -- 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-218) Missed XSD Schema for the file webapp-cache.xml
[ http://jira.codehaus.org/browse/MWAR-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210104#action_210104 ] Stephane Nicoll commented on MWAR-218: -- Not sure I understand what you mean with warnings. This file is purely internal to the plugin and is not packaged in any way in your final artifact. Validation here would be necessary if a 3rd party was creating this file. But this just won't happen the way the plugin is designed today. > Missed XSD Schema for the file webapp-cache.xml > --- > > Key: MWAR-218 > URL: http://jira.codehaus.org/browse/MWAR-218 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement >Affects Versions: 2.1-beta-1 >Reporter: Felipe Gaúcho > > When packaging a web-application, maven-war-plugin generates a cache file, as > described here: > http://maven.apache.org/plugins/maven-war-plugin/exploded-mojo.html#cacheFile > This cache file is an XML file but the generated file doesn't contains an > Schema or DTD declaration on its header. This makes impossible to validate > such file, generating warnings in the most common Java IDEs. Since it is a > mandatory XML file I believe it should has a model specification somewhere (a > XSD Schema I hope), eventually just not released for public usage. > The steps I expect to make Maven 2 WAR plugin better: > - to modify the generator of the webapp-cache.xml file to include the proper > XML header (with namespace and schema location) > - to make the schema of such file publicly available, in order to give the > developers and automatic tools a chance to validate any error in a deployable > artifact. > This will give us a chance to detect potential bugs before to deploy a > web-application. > --- The expected header is something like: > > http://maven.apache.org/plugins/maven-war-plugin"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/plugins/maven-war-plugin > http://maven.apache.org/???/???.xsd";> > ... > -- 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: (MCHECKSTYLE-129) Unable To Load configLocation From URL
[ http://jira.codehaus.org/browse/MCHECKSTYLE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MCHECKSTYLE-129: - Priority: Blocker (was: Critical) > Unable To Load configLocation From URL > -- > > Key: MCHECKSTYLE-129 > URL: http://jira.codehaus.org/browse/MCHECKSTYLE-129 > Project: Maven 2.x Checkstyle Plugin > Issue Type: Bug >Affects Versions: 2.5 > Environment: Windows Vista > Maven 2.2.1 >Reporter: Allan Shoup >Assignee: Olivier Lamy >Priority: Blocker > Fix For: 2.6 > > Attachments: checkstyle-new.zip, checkstyle-old.zip > > > With maven-checkstyle-plugin 2.5, I can no longer specify a URL in the > configLocation. -- 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-218) Missed XSD Schema for the file webapp-cache.xml
[ http://jira.codehaus.org/browse/MWAR-218?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210106#action_210106 ] Felipe Gaúcho commented on MWAR-218: Eclipse and other IDEs will complaint against an XML file without schema declaration. That's the warning I refer in the issue. It is not actually a big deal, but what people are doing out there is to disable the validation of this file in the IDEs, a boring and unnecessary step if the plugin just include the header in the generated file. Other good reason to have the header is because it is an XML file and there is no such thing like XML files without a model. If the plugin uses XML, we expect it to use XML in the proper way. I submitted the issue as "enhancement" because it is actually not a big deal, but I believe it is very important to plugin to be the most correct as possible - and I believe the effort to fix this issue is small enough to make it worthy to be done. > Missed XSD Schema for the file webapp-cache.xml > --- > > Key: MWAR-218 > URL: http://jira.codehaus.org/browse/MWAR-218 > Project: Maven 2.x WAR Plugin > Issue Type: Improvement >Affects Versions: 2.1-beta-1 >Reporter: Felipe Gaúcho > > When packaging a web-application, maven-war-plugin generates a cache file, as > described here: > http://maven.apache.org/plugins/maven-war-plugin/exploded-mojo.html#cacheFile > This cache file is an XML file but the generated file doesn't contains an > Schema or DTD declaration on its header. This makes impossible to validate > such file, generating warnings in the most common Java IDEs. Since it is a > mandatory XML file I believe it should has a model specification somewhere (a > XSD Schema I hope), eventually just not released for public usage. > The steps I expect to make Maven 2 WAR plugin better: > - to modify the generator of the webapp-cache.xml file to include the proper > XML header (with namespace and schema location) > - to make the schema of such file publicly available, in order to give the > developers and automatic tools a chance to validate any error in a deployable > artifact. > This will give us a chance to detect potential bugs before to deploy a > web-application. > --- The expected header is something like: > > http://maven.apache.org/plugins/maven-war-plugin"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/plugins/maven-war-plugin > http://maven.apache.org/???/???.xsd";> > ... > -- 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-2743) Project TheseFoolishThings is failing sync
Project TheseFoolishThings is failing sync -- Key: MAVENUPLOAD-2743 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2743 Project: Maven Upload Requests Issue Type: Bug Reporter: Fabrizio Giudici The project has been successfully synced a few months ago and versions 1.0.1 through 1.0.5 (November) were successfully synced to central. Yesterday I released 1.0.6 but I don't see it yet on Central - and I didn't receive any error notification. Please let me know. -- 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: (MCOMPILER-119) classes from src/main/java are coppied to target/test-classes
[ http://jira.codehaus.org/browse/MCOMPILER-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210115#action_210115 ] Pavel Genevski commented on MCOMPILER-119: -- I think this custom config is something needed for GWT launching. I tried removing it and did a clean rebuild, but I got the same problem. BTW, out of my experience during the last week, there were a couple of builds (on windows) in which the problem did not occur. It happens most of the time though. > classes from src/main/java are coppied to target/test-classes > - > > Key: MCOMPILER-119 > URL: http://jira.codehaus.org/browse/MCOMPILER-119 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: The problem occurs on both Windows and Linux >Reporter: Pavel Genevski > Attachments: effectivePom.xml > > > When I rebuild my project I notice that main classes from src/main/java are > coppied to target/test-classes. The consequence for me is that Eclipse JUnit > runner uses the (possibly stale) versions of the main classes from > target/test-classes. For example, if I modify a class from main JUnit runner > doesn't see the changes until I do a clean rebuild of the project with maven. > I checked the eclipse project export order (Properties/Java Build Path/Order > and Export)and it seems OK (src/main, src/resources, src/test/java). > > This behavior must have been introduced recently because I checked the > target/test-classes folder on a system, on which I havent ran a full rebuild > recently and it only contained the test classes. -- 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: (MCOMPILER-119) classes from src/main/java are coppied to target/test-classes
[ http://jira.codehaus.org/browse/MCOMPILER-119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210120#action_210120 ] Stephane Nicoll commented on MCOMPILER-119: --- well, seems weird. Please run mvn with the -X flag and redirect the output to a file (mvn clean install -X > output.log would do). Attach the log file here so that we can have a look > classes from src/main/java are coppied to target/test-classes > - > > Key: MCOMPILER-119 > URL: http://jira.codehaus.org/browse/MCOMPILER-119 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: The problem occurs on both Windows and Linux >Reporter: Pavel Genevski > Attachments: effectivePom.xml > > > When I rebuild my project I notice that main classes from src/main/java are > coppied to target/test-classes. The consequence for me is that Eclipse JUnit > runner uses the (possibly stale) versions of the main classes from > target/test-classes. For example, if I modify a class from main JUnit runner > doesn't see the changes until I do a clean rebuild of the project with maven. > I checked the eclipse project export order (Properties/Java Build Path/Order > and Export)and it seems OK (src/main, src/resources, src/test/java). > > This behavior must have been introduced recently because I checked the > target/test-classes folder on a system, on which I havent ran a full rebuild > recently and it only contained the test classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MSITE-462) Broken module links
[ http://jira.codehaus.org/browse/MSITE-462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210121#action_210121 ] Dennis Lundberg commented on MSITE-462: --- Frederic, in your test project you have supplied the same URL in both the parent and child POM. I suggest that you remove the elements from both POMs and try again. > Broken module links > --- > > Key: MSITE-462 > URL: http://jira.codehaus.org/browse/MSITE-462 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Frederic Müller > Attachments: project.tar.gz > > > The goal site:stage always leads to the same broken links no matter what I > do. I created the most simple project layout under > "/home/fmu01/Projekte/test-parent" and still it won't work. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-2743) Project TheseFoolishThings is failing sync
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2743?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrizio Giudici closed MAVENUPLOAD-2743. - Resolution: Fixed Now the artifacts have appeared. > Project TheseFoolishThings is failing sync > -- > > Key: MAVENUPLOAD-2743 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2743 > Project: Maven Upload Requests > Issue Type: Bug >Reporter: Fabrizio Giudici > > The project has been successfully synced a few months ago and versions 1.0.1 > through 1.0.5 (November) were successfully synced to central. Yesterday I > released 1.0.6 but I don't see it yet on Central - and I didn't receive any > error notification. > Please let me know. -- 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: (MSITE-462) Broken module links
[ http://jira.codehaus.org/browse/MSITE-462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frederic Müller closed MSITE-462. - Resolution: Not A Bug I see my mistake. Initial project setup set a url for both poms. Removing that url lead to a working staging site. Thanks for the help. > Broken module links > --- > > Key: MSITE-462 > URL: http://jira.codehaus.org/browse/MSITE-462 > Project: Maven 2.x Site Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Frederic Müller > Attachments: project.tar.gz > > > The goal site:stage always leads to the same broken links no matter what I > do. I created the most simple project layout under > "/home/fmu01/Projekte/test-parent" and still it won't work. -- 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
mvn repositories hang when trying to get plexus-archiver
I am trying to use maven 2.2.1 to build tika 0.6, and having problems when downloading plexus-archiver mvn hangs on trying to download http://repo1.maven.org/maven2/org/codehaus/plexus/plexus-archiver/1.0-alpha-7/plexus-archiver-1.0-alpha-7.jar I tried deleting my ~/.m2 directory, and changed the mirror to another server, and still getting the same problem.. All the mirrors seem to hang for me. Any ideas what to do? I even tried downloading the file by hand into the right dir, but then the tika install fails saying: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Internal error in the plugin manager executing goal 'org.apache.felix:maven-bundle-plugin:2.0.0:bundle': Unable to load the mojo 'org.apache.felix:maven-bundle-plugin:2.0.0:bundle' in the plugin 'org.apache.felix:maven-bundle-plugin'. A required class is missing: org/codehaus/plexus/archiver/UnArchiver org.codehaus.plexus.archiver.UnArchiver [INFO] I should not need a proxy as every other jar downloads fine from repo1.maven.org thanks for your help
[jira] Updated: (MCOMPILER-119) classes from src/main/java are coppied to target/test-classes
[ http://jira.codehaus.org/browse/MCOMPILER-119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Genevski updated MCOMPILER-119: - Attachment: mvn_output.log File attached > classes from src/main/java are coppied to target/test-classes > - > > Key: MCOMPILER-119 > URL: http://jira.codehaus.org/browse/MCOMPILER-119 > Project: Maven 2.x Compiler Plugin > Issue Type: Bug >Affects Versions: 2.0.2 > Environment: The problem occurs on both Windows and Linux >Reporter: Pavel Genevski > Attachments: effectivePom.xml, mvn_output.log > > > When I rebuild my project I notice that main classes from src/main/java are > coppied to target/test-classes. The consequence for me is that Eclipse JUnit > runner uses the (possibly stale) versions of the main classes from > target/test-classes. For example, if I modify a class from main JUnit runner > doesn't see the changes until I do a clean rebuild of the project with maven. > I checked the eclipse project export order (Properties/Java Build Path/Order > and Export)and it seems OK (src/main, src/resources, src/test/java). > > This behavior must have been introduced recently because I checked the > target/test-classes folder on a system, on which I havent ran a full rebuild > recently and it only contained the test classes. -- 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-2744) Upload Contract4J5
Upload Contract4J5 -- Key: MAVENUPLOAD-2744 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2744 Project: Maven Upload Requests Issue Type: Wish Reporter: Dean Wampler Please upload the Contract4j5 bundle to the maven repository. You can find it here: http://contract4j.org/contract4j5-0.8.0-bundle.jar I am the owner of the contract4jwebsite: http://contract4j.org through my consultancy, Aspect Research Associates (ARA), http://www.aspectresearchassociates.com/ You can see a link to my name (my personal home page, actually) on the ARA web site as well as on this page on the contract4j.org site: http://contract4j.org/contract4j/c4j5 Thank you. -- 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-4561) [regression] network settings are not applied to repositories from plugin dependencies
[ http://jira.codehaus.org/browse/MNG-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210150#action_210150 ] Benjamin Bentmann commented on MNG-4561: Completed fix in [r909934|http://svn.apache.org/viewvc?view=revision&revision=909934]. The particular project mentioned here, nexus-archetype-plugin, suffered actually from two issues. The first issue was a straight forward bug where the proxy settings were not passed to the wagon. The second issue was that an old version of the HTTP wagon was being used which completey ignored proxy settings (WAGON-236). This old wagon version was pulled in via transitive dependencies of a build extension and basically duplicates MNG-4528. > [regression] network settings are not applied to repositories from plugin > dependencies > -- > > Key: MNG-4561 > URL: http://jira.codehaus.org/browse/MNG-4561 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-alpha-6 > Environment: Apache Maven 3.0-alpha-6 (r896384; 2010-01-06 > 11:00:46+) > Java version: 1.6.0_16 > Java home: C:\Java\jdk1.6.0_16\jre > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: James Nord >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-7 > > > See also MNG-4413, MNG-4489 > For some artifacts Maven ignores the proxy defined in the per user > settings.xml and tries to connect directly which results in a connection > timeout. > I will attempt to create a simplified test case but meanwhile. > 1) install a web proxy > 2) install a nexus repo manager > 3) configure your machine so it can not see the repo manager. > 4) add central and sonatype forge to the repo manager and configre repo > manager and settings.xml for proxy and mirror. > 5) delete local repository > 6) checkout > http://svn.sonatype.org/nexus-plugins/trunk/nexus-archetype-plugin/ > 7) mvn package. > The build will fail. > delete the metadata for the associated failed files in the local repo > run mvn -e package > in another shell run netstat -an > observe that the machine is trying to connect to repository.sonatype.org > (63.246.20.88:80) > observe that the stack traces the socket is a plain socket and it is a plain > connect not a proxy connect. -- 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: (MNG-4561) [regression] network settings are not applied to repositories from plugin dependencies
[ http://jira.codehaus.org/browse/MNG-4561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4561. -- Resolution: Fixed > [regression] network settings are not applied to repositories from plugin > dependencies > -- > > Key: MNG-4561 > URL: http://jira.codehaus.org/browse/MNG-4561 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 3.0-alpha-6 > Environment: Apache Maven 3.0-alpha-6 (r896384; 2010-01-06 > 11:00:46+) > Java version: 1.6.0_16 > Java home: C:\Java\jdk1.6.0_16\jre > Default locale: en_GB, platform encoding: Cp1252 > OS name: "windows xp" version: "5.1" arch: "x86" Family: "windows" >Reporter: James Nord >Assignee: Benjamin Bentmann > Fix For: 3.0-alpha-7 > > > See also MNG-4413, MNG-4489 > For some artifacts Maven ignores the proxy defined in the per user > settings.xml and tries to connect directly which results in a connection > timeout. > I will attempt to create a simplified test case but meanwhile. > 1) install a web proxy > 2) install a nexus repo manager > 3) configure your machine so it can not see the repo manager. > 4) add central and sonatype forge to the repo manager and configre repo > manager and settings.xml for proxy and mirror. > 5) delete local repository > 6) checkout > http://svn.sonatype.org/nexus-plugins/trunk/nexus-archetype-plugin/ > 7) mvn package. > The build will fail. > delete the metadata for the associated failed files in the local repo > run mvn -e package > in another shell run netstat -an > observe that the machine is trying to connect to repository.sonatype.org > (63.246.20.88:80) > observe that the stack traces the socket is a plain socket and it is a plain > connect not a proxy connect. -- 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: (MCHECKSTYLE-129) Unable To Load configLocation From URL
[
http://jira.codehaus.org/browse/MCHECKSTYLE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Olivier Lamy closed MCHECKSTYLE-129.
Resolution: Fixed
the issue is in plexus-resources.
You can add a new version in the plugin dependencies
{code:xml}
org.codehaus.plexus
plexus-resources
1.0-alpha-7-SNAPSHOT
{code}
> Unable To Load configLocation From URL
> --
>
> Key: MCHECKSTYLE-129
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-129
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: Windows Vista
> Maven 2.2.1
>Reporter: Allan Shoup
>Assignee: Olivier Lamy
>Priority: Blocker
> Fix For: 2.6
>
> Attachments: checkstyle-new.zip, checkstyle-old.zip
>
>
> With maven-checkstyle-plugin 2.5, I can no longer specify a URL in the
> configLocation.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MCHECKSTYLE-129) Unable To Load configLocation From URL
[
http://jira.codehaus.org/browse/MCHECKSTYLE-129?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210154#action_210154
]
Olivier Lamy edited comment on MCHECKSTYLE-129 at 2/14/10 6:24 PM:
---
the issue is in plexus-resources.
You can add a new version in the plugin dependencies
{code:xml}
org.codehaus.plexus
plexus-resources
1.0-alpha-7-SNAPSHOT
{code}
was (Author: olamy):
the issue is in plexus-resources.
You can add a new version in the plugin dependencies
{code:xml}
org.codehaus.plexus
plexus-resources
1.0-alpha-7-SNAPSHOT
{code}
> Unable To Load configLocation From URL
> --
>
> Key: MCHECKSTYLE-129
> URL: http://jira.codehaus.org/browse/MCHECKSTYLE-129
> Project: Maven 2.x Checkstyle Plugin
> Issue Type: Bug
>Affects Versions: 2.5
> Environment: Windows Vista
> Maven 2.2.1
>Reporter: Allan Shoup
>Assignee: Olivier Lamy
>Priority: Blocker
> Fix For: 2.6
>
> Attachments: checkstyle-new.zip, checkstyle-old.zip
>
>
> With maven-checkstyle-plugin 2.5, I can no longer specify a URL in the
> configLocation.
--
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: (MNG-4538) dependencyManagament dependencies within profiles are not activated by settings.xml
[ http://jira.codehaus.org/browse/MNG-4538?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-4538. - Resolution: Duplicate Assignee: Brett Porter note that this is likely to be rolled back, so you can expect the behaviour in 2.2.1 and 3.0-SNAPSHOT to be permanent. Applying profiles to POMs built from the repository can lead to inconsistent build behaviour across machines - I think the fact this reproduction example was so confusing to find the cause illustrates that. > dependencyManagament dependencies within profiles are not activated by > settings.xml > > > Key: MNG-4538 > URL: http://jira.codehaus.org/browse/MNG-4538 > Project: Maven 2 & 3 > Issue Type: Bug >Affects Versions: 2.2.1, 3.0-alpha-7 > Environment: Windows XP >Reporter: Christian Moser >Assignee: Brett Porter >Priority: Critical > Attachments: profileBug.zip > > > This issue is *not* reproducable with Maven 2.0.9, 2.0.10 and > 2.2.2-RC1-SNAPSHOT. > I'm referring to the sample projects contained in profileBug.zip: > preparation: > - You need to set in your settings.xml: > > testing > > - Install main-parent > reproducing: > - Install project parent. This will fail because of ChildTwo. > The transivite dependency of junit is not beeing resolved correctly through > project ChildOne even it's not necessary. I guess not finding commons-lang is > just a "sequence error" of the "invalid" pom of ChildOne. > It seems like the profile isn't activated by the settings.xml and so the > dependencies aren't known in context of project ChildTwo transitive > dependencies. > But e.g. childOne or childThree can be installed without any problems so the > profile should be loaded correctly, the only difference to ChildTwo is that > they don't have any transitive dependencies to other projects with the same > parent. > If you cange in project parent the profile "testing" to: > >true > > or change the profile activation by property and install project parent with > -Dtesting, childTwo will be installed correctly. > This issue only occurs with maven 3.0 or 2.2.1. It works fine with maven > 2.0.10 or 2.2.2-RC1-SNAPSHOT > Will this error be fixed in maven 3.0? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4148) Apply profiles from settings.xml to POMs built from the repository
[
http://jira.codehaus.org/browse/MNG-4148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=210161#action_210161
]
Brett Porter commented on MNG-4148:
---
This also needs to go into the compatibility wiki if it is not going to be
allowed going forward.
> Apply profiles from settings.xml to POMs built from the repository
> --
>
> Key: MNG-4148
> URL: http://jira.codehaus.org/browse/MNG-4148
> Project: Maven 2 & 3
> Issue Type: Improvement
> Components: Artifacts and Repositories, POM, Profiles
>Affects Versions: 2.1.0
>Reporter: John Casey
>Assignee: John Casey
> Fix For: 2.2.2
>
> Attachments: test-mng3553.zip
>
>
> When we declare a profile in the settings.xml, it will never be applied to
> POMs loaded from the Maven repository. This means that overriding the central
> repository definition - for instance - cannot be done without using mirror
> definitions, since transitive dependencies (any dependency of a direct
> dependency) will skip the modified definition and use the original from the
> super-POM instead.
> I'm attaching a testing setup that was originally reported for MNG-3553,
> which exhibits this problem when dealing with scope == import. The
> instructions for using it are as follows:
> {noformat}
> I installed locally a nexus server (1.3.3 Open Source) and I'm using maven
> 2.1.0 (I reproduced the issue with 2.0.10).
> In the releases repository of nexus you upload all artifacts given in the
> toUpload directory :
> * parent 1.0.0 pom
> * dependencies 1.0.0 pom
> * module 1.0.0 pom and jar
> You'll find in the root of the archive my settings. It defines to use nexus
> for the central repository.
> You launch a build of the project and you'll have :
> [INFO] Scanning for projects...
> [INFO]
>
> [INFO] Building Unnamed -
> org.apache.maven.it.mng3553:project:jar:1.0.0-SNAPSHOT
> [INFO]task-segment: [install]
> [INFO]
>
> [INFO] [resources:resources]
> [WARNING] Using platform encoding (Cp1252 actually) to copy filtered
> resources, i.e. build is platform dependent!
> [INFO] skip non existing resourceDirectory
> E:\jtb\workspaces\tests\test-mng3553\project\src\main\resources
> Downloading:
> http://localhost:8081/nexus/content/groups/public//org/apache/maven/it/mng3553/module/1.0.0/module-1.0.0.pom
> 867b downloaded (module-1.0.0.pom)
> Downloading:
> http://repo1.maven.org/maven2/org/apache/maven/it/mng3553/dependencies/1.0.0/dependencies-1.0.0.pom
> [WARNING] Unable to get resource
> 'org.apache.maven.it.mng3553:dependencies:pom:1.0.0'
> from repository central (http://repo1.maven.org/maven2): Authorization
> failed: Access denied to:
>
> http://repo1.maven.org/maven2/org/apache/maven/it/mng3553/dependencies/1.0.0/dependencies-1.0.0.pom
> [INFO]
>
> [ERROR] BUILD ERROR
> [INFO]
>
> [INFO] Failed to resolve artifact.
> GroupId: org.apache.maven.it.mng3553
> ArtifactId: dependencies
> Version: 1.0.0
> Reason: Unable to download the artifact from any repository
> org.apache.maven.it.mng3553:dependencies:pom:1.0.0
> from the specified remote repositories:
> central (http://repo1.maven.org/maven2)
> [INFO]
>
> [INFO] For more information, run Maven with the -e switch
> [INFO]
>
> [INFO] Total time: 1 second
> [INFO] Finished at: Thu Apr 30 15:19:47 CEST 2009
> [INFO] Final Memory: 6M/254M
> [INFO]
>
> You can see that the project downloads successfully the module-1.0.0 from
> nexus but
> it fails for depencencies which is an import. It tries to download it from
> the real central repository
> and not from the one I defined in my settings.
> The behavior is inconsistent...
> {noformat}
--
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: (MCHANGES-197) Parameter for output encoding
[
http://jira.codehaus.org/browse/MCHANGES-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Marti updated MCHANGES-197:
-
Attachment: changes_encoding.zip
a little demo project.
Usage:
- mvn clean site
-> changes-report is correct, especially german characters äöü or the
publishing date
- mvn clean changes:changes-report
-> publishing date an special characters aren't rendered
> Parameter for output encoding
> -
>
> Key: MCHANGES-197
> URL: http://jira.codehaus.org/browse/MCHANGES-197
> Project: Maven 2.x Changes Plugin
> Issue Type: New Feature
> Components: changes-report
>Affects Versions: 2.1, 2.3
> Environment: Win XP, JDK 1.6.0_18, Maven 2.2.1
>Reporter: Bruno Marti
> Attachments: changes_encoding.zip
>
>
> Add an additional parameter to define the output encoding like in site-plugin.
> __
> If I generate the changes-report by changes:changes-report, I get this in the
> html output:
> {code:xml}
> http://www.w3.org/1999/xhtml";>
>
>
> ...
> {code}
> If I generate the same changes-report by site:site, I get this:
> {code:xml}
> http://www.w3.org/1999/xhtml";>
>
>
> {code}
> Whereas, here I've defined
> _ISO-8859-1_
> and as default in the parent pom
> _ISO-8859-1_
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-197) Parameter for output encoding
[
http://jira.codehaus.org/browse/MCHANGES-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Marti updated MCHANGES-197:
-
Attachment: screenshot-1.jpg
correct characters
> Parameter for output encoding
> -
>
> Key: MCHANGES-197
> URL: http://jira.codehaus.org/browse/MCHANGES-197
> Project: Maven 2.x Changes Plugin
> Issue Type: New Feature
> Components: changes-report
>Affects Versions: 2.1, 2.3
> Environment: Win XP, JDK 1.6.0_18, Maven 2.2.1
>Reporter: Bruno Marti
> Attachments: changes_encoding.zip, screenshot-1.jpg, screenshot-2.jpg
>
>
> Add an additional parameter to define the output encoding like in site-plugin.
> __
> If I generate the changes-report by changes:changes-report, I get this in the
> html output:
> {code:xml}
> http://www.w3.org/1999/xhtml";>
>
>
> ...
> {code}
> If I generate the same changes-report by site:site, I get this:
> {code:xml}
> http://www.w3.org/1999/xhtml";>
>
>
> {code}
> Whereas, here I've defined
> _ISO-8859-1_
> and as default in the parent pom
> _ISO-8859-1_
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCHANGES-197) Parameter for output encoding
[
http://jira.codehaus.org/browse/MCHANGES-197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bruno Marti updated MCHANGES-197:
-
Attachment: screenshot-2.jpg
incorrect
> Parameter for output encoding
> -
>
> Key: MCHANGES-197
> URL: http://jira.codehaus.org/browse/MCHANGES-197
> Project: Maven 2.x Changes Plugin
> Issue Type: New Feature
> Components: changes-report
>Affects Versions: 2.1, 2.3
> Environment: Win XP, JDK 1.6.0_18, Maven 2.2.1
>Reporter: Bruno Marti
> Attachments: changes_encoding.zip, screenshot-1.jpg, screenshot-2.jpg
>
>
> Add an additional parameter to define the output encoding like in site-plugin.
> __
> If I generate the changes-report by changes:changes-report, I get this in the
> html output:
> {code:xml}
> http://www.w3.org/1999/xhtml";>
>
>
> ...
> {code}
> If I generate the same changes-report by site:site, I get this:
> {code:xml}
> http://www.w3.org/1999/xhtml";>
>
>
> {code}
> Whereas, here I've defined
> _ISO-8859-1_
> and as default in the parent pom
> _ISO-8859-1_
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
