[jira] Work started: (MRM-416) Find artifact does not work.
[ http://jira.codehaus.org/browse/MRM-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-416 started by Maria Odea Ching. > Find artifact does not work. > > > Key: MRM-416 > URL: http://jira.codehaus.org/browse/MRM-416 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Henry S. Isidro >Assignee: Maria Odea Ching > Fix For: 1.0-alpha-2 > > > Finding an artifact always shows the 'No results found' message even though > the artifact that is being looked for is in the repository. -- 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-1832) built-in property containing current timestamp
[ http://jira.codehaus.org/browse/MNG-1832?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100300 ] Paul Sundling commented on MNG-1832: What happened to the buildinfo plugin? It was in the sandbox and now it disappeared. Look at the hoops someone else went through: http://www.gadberry.com/aaron/2007/05/28/inject-build-time-timestamp-property-using-maven/ I notice his caveat that you have to build twice, all for a timestamp. It's a shame the fix won't be included until 2.1. I downloaded head of 2.1 and used mvn.timestamp and didn't seem to filter properly still. > built-in property containing current timestamp > -- > > Key: MNG-1832 > URL: http://jira.codehaus.org/browse/MNG-1832 > Project: Maven 2 > Issue Type: New Feature >Affects Versions: 2.0.1 >Reporter: Michal Stochmialek > Fix For: 2.1.x > > Attachments: maven-archiver_pomDelete.patch, > maven-core_defaultExpressions.patch > > > Current timestamp (time or date) is often used while filtering resources or > creating manifest in ant builds. There is no equivalent in maven. -- 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-271) Ability to skip
[ http://jira.codehaus.org/browse/MECLIPSE-271?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MECLIPSE-271. --- Assignee: Carlos Sanchez Resolution: Fixed > Ability to skip > --- > > Key: MECLIPSE-271 > URL: http://jira.codehaus.org/browse/MECLIPSE-271 > Project: Maven 2.x Eclipse Plugin > Issue Type: New Feature > Components: multiproject >Affects Versions: 2.3 > Environment: xp, linux >Reporter: Dan Tran >Assignee: Carlos Sanchez > Fix For: 2.4 > > Attachments: MECLIPSE-271.diff > > > I would like mvn eclipse:eclipse to skip its execution > use case: currently eclipse:eclipse goal can not generate my webapp project > file correctly using WTP 2.0 so I ended up to handcraft eclipse project and > setting files and check them into SCM. By supporting 'skip' configuration, I > can have eclipse to generate other project file and skip my web app ( until > WTP 2.0 feature is added in the example) > comments? -- 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-251) Allows prefixing of eclipse project name
[
http://jira.codehaus.org/browse/MECLIPSE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sanchez closed MECLIPSE-251.
---
Resolution: Fixed
Fixed using [] for the variables
> Allows prefixing of eclipse project name
>
>
> Key: MECLIPSE-251
> URL: http://jira.codehaus.org/browse/MECLIPSE-251
> Project: Maven 2.x Eclipse Plugin
> Issue Type: New Feature
> Components: multiproject
>Affects Versions: 2.4
>Reporter: Martin Desruisseaux
>Assignee: Carlos Sanchez
> Fix For: 2.4
>
> Attachments: 20070509-maven-eclipse-plugin.patch
>
>
> This issue is related to MECLIPSE-44, MECLIPSE-119 and MECLIPSE-161. They
> were closed as fixed by MECLIPSE-189, but the later doesn't adress fully our
> issue (or works only if we are lucky).
> We have two Maven projects (namely _Geotools_ and _Geoserver_) made of many
> modules. Some Geoserver modules may (by accident) have the same name than
> Geotools modules. For example both Geotools and Geoserver have a module named
> "_main_". We need to import those two projects in Eclipse, because they are
> closely related and share the same pool of developpers. Before MECLIPSE-189,
> it was not possible with those names, because of module name clash like
> "_main_". Since MECLIPSE-189, it is possible if we are lucky enough to have
> different Geotools and Geoserver version numbers.
> We would like a way to prefix every Eclipse module names. For example we
> would like a way to add {{"gt-"}} in front of every Geotools modules imported
> in Eclipse. I realize that the common practice in Maven projects seems to be
> long module names (for example "{{maven-eclipse-plugin}}"), but such practice
> seems quite redundant with group name. We would like to keep module names
> that match SVN directory names or Maven report directory names (otherwise we
> often get broken links in generated HTML pages), and we would like to keep
> the path names simple and intelligible (long module names don't bring much
> compared to full path names, which should already be unique).
> The ability to add some prefix before Eclipse project names would help. If
> this is not possible, something like {{addGroupNameToProjectName}} property
> (similar to {{addVersionToProjectName}} defined in MECLIPSE-189) could be a
> fallback.
--
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-251) Allows prefixing of eclipse project name
[
http://jira.codehaus.org/browse/MECLIPSE-251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Carlos Sanchez reopened MECLIPSE-251:
-
There are problem with the syntax used, it doesn't work in the reactor as the
variables (${groupId}, ${artifactId}) are injected by maven
> Allows prefixing of eclipse project name
>
>
> Key: MECLIPSE-251
> URL: http://jira.codehaus.org/browse/MECLIPSE-251
> Project: Maven 2.x Eclipse Plugin
> Issue Type: New Feature
> Components: multiproject
>Affects Versions: 2.4
>Reporter: Martin Desruisseaux
>Assignee: Carlos Sanchez
> Fix For: 2.4
>
> Attachments: 20070509-maven-eclipse-plugin.patch
>
>
> This issue is related to MECLIPSE-44, MECLIPSE-119 and MECLIPSE-161. They
> were closed as fixed by MECLIPSE-189, but the later doesn't adress fully our
> issue (or works only if we are lucky).
> We have two Maven projects (namely _Geotools_ and _Geoserver_) made of many
> modules. Some Geoserver modules may (by accident) have the same name than
> Geotools modules. For example both Geotools and Geoserver have a module named
> "_main_". We need to import those two projects in Eclipse, because they are
> closely related and share the same pool of developpers. Before MECLIPSE-189,
> it was not possible with those names, because of module name clash like
> "_main_". Since MECLIPSE-189, it is possible if we are lucky enough to have
> different Geotools and Geoserver version numbers.
> We would like a way to prefix every Eclipse module names. For example we
> would like a way to add {{"gt-"}} in front of every Geotools modules imported
> in Eclipse. I realize that the common practice in Maven projects seems to be
> long module names (for example "{{maven-eclipse-plugin}}"), but such practice
> seems quite redundant with group name. We would like to keep module names
> that match SVN directory names or Maven report directory names (otherwise we
> often get broken links in generated HTML pages), and we would like to keep
> the path names simple and intelligible (long module names don't bring much
> compared to full path names, which should already be unique).
> The ability to add some prefix before Eclipse project names would help. If
> this is not possible, something like {{addGroupNameToProjectName}} property
> (similar to {{addVersionToProjectName}} defined in MECLIPSE-189) could be a
> fallback.
--
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: (MPA-89) Apply remaining patches in MNG JIRA
[ http://jira.codehaus.org/browse/MPA-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MPA-89: - > Apply remaining patches in MNG JIRA > --- > > Key: MPA-89 > URL: http://jira.codehaus.org/browse/MPA-89 > Project: Maven Project Administration > Issue Type: Task > Components: Issue Management >Reporter: Brett Porter >Assignee: Jason van Zyl > Fix For: Maven 2.1 Prep > > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&customfield_10170=Yes&pid=10500&assigneeSelect=unassigned&status=1&sorter/field=priority&sorter/order=DESC -- 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: (MPA-89) Apply remaining patches in MNG JIRA
[ http://jira.codehaus.org/browse/MPA-89?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-89. --- Resolution: Fixed > Apply remaining patches in MNG JIRA > --- > > Key: MPA-89 > URL: http://jira.codehaus.org/browse/MPA-89 > Project: Maven Project Administration > Issue Type: Task > Components: Issue Management >Reporter: Brett Porter >Assignee: Jason van Zyl > Fix For: Maven 2.1 Prep > > > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&&customfield_10170=Yes&pid=10500&assigneeSelect=unassigned&status=1&sorter/field=priority&sorter/order=DESC -- 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: (MPA-93) release Maven 2.0.7
[ http://jira.codehaus.org/browse/MPA-93?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MPA-93. --- Resolution: Fixed Fix Version/s: (was: Maven 2.1 Prep) 2007-q2 > release Maven 2.0.7 > --- > > Key: MPA-93 > URL: http://jira.codehaus.org/browse/MPA-93 > Project: Maven Project Administration > Issue Type: Task > Components: Releases >Reporter: Brett Porter >Assignee: Jason van Zyl > Fix For: 2007-q2 > > -- 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: (MECLIPSE-248) Eclipse plugin looks for pom version "test"
[ http://jira.codehaus.org/browse/MECLIPSE-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MECLIPSE-248: Priority: Blocker (was: Major) Affects Version/s: 2.4 Fix Version/s: 2.4 Summary: Eclipse plugin looks for pom version "test" (was: Clean build of maven-eclipse-plugin-2.3 tag fails) > Eclipse plugin looks for pom version "test" > --- > > Key: MECLIPSE-248 > URL: http://jira.codehaus.org/browse/MECLIPSE-248 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.3, 2.4 > Environment: Linux (Ubuntu Edgy), Maven 2.0.5, JDK5update11, totally > empty local repository, no remote repositories other than central >Reporter: Max Bowsher >Priority: Blocker > Fix For: 2.4 > > Attachments: log.txt, > org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest_testModule1Project.build.log > > > A clean build of the maven-eclipse-plugin-2.3 tag fails, because of a test > failure: > Tests in error: > > testModule1Project(org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest) > (build log for this test is attached) > Presumably this is not the fault of the eclipse plugin code, since it must > have built at one time in order to be released, but I'm not sure where else > to report it. > The test failure poses a problem for people trying to make modified versions > of the plugin based on the last released 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] Commented: (MECLIPSE-248) Eclipse plugin looks for pom version "test"
[ http://jira.codehaus.org/browse/MECLIPSE-248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100294 ] Carlos Sanchez commented on MECLIPSE-248: - If the pligin 2.4-SNAPSHOT is installed then the embedder test org.apache.maven.embedder.EmbedderUsingEclipsePluginTest also fails > Eclipse plugin looks for pom version "test" > --- > > Key: MECLIPSE-248 > URL: http://jira.codehaus.org/browse/MECLIPSE-248 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.3, 2.4 > Environment: Linux (Ubuntu Edgy), Maven 2.0.5, JDK5update11, totally > empty local repository, no remote repositories other than central >Reporter: Max Bowsher >Priority: Blocker > Fix For: 2.4 > > Attachments: log.txt, > org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest_testModule1Project.build.log > > > A clean build of the maven-eclipse-plugin-2.3 tag fails, because of a test > failure: > Tests in error: > > testModule1Project(org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest) > (build log for this test is attached) > Presumably this is not the fault of the eclipse plugin code, since it must > have built at one time in order to be released, but I'm not sure where else > to report it. > The test failure poses a problem for people trying to make modified versions > of the plugin based on the last released 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] Updated: (MECLIPSE-248) Clean build of maven-eclipse-plugin-2.3 tag fails
[ http://jira.codehaus.org/browse/MECLIPSE-248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez updated MECLIPSE-248: Attachment: log.txt If the latest eclipse 2.4-SNAPSHOT is installed locally then it causes this problem, missing org.apache.maven.plugins:maven-eclipse-plugin:pom:test For some reason that I haven't found yet it's looking for the version "test" of the plugin > Clean build of maven-eclipse-plugin-2.3 tag fails > - > > Key: MECLIPSE-248 > URL: http://jira.codehaus.org/browse/MECLIPSE-248 > Project: Maven 2.x Eclipse Plugin > Issue Type: Bug >Affects Versions: 2.3 > Environment: Linux (Ubuntu Edgy), Maven 2.0.5, JDK5update11, totally > empty local repository, no remote repositories other than central >Reporter: Max Bowsher > Attachments: log.txt, > org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest_testModule1Project.build.log > > > A clean build of the maven-eclipse-plugin-2.3 tag fails, because of a test > failure: > Tests in error: > > testModule1Project(org.apache.maven.plugin.eclipse.EclipsePluginMasterProjectTest) > (build log for this test is attached) > Presumably this is not the fault of the eclipse plugin code, since it must > have built at one time in order to be released, but I'm not sure where else > to report it. > The test failure poses a problem for people trying to make modified versions > of the plugin based on the last released 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] Commented: (MRELEASE-254) tests failed on windows
[ http://jira.codehaus.org/browse/MRELEASE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100291 ] Mark Hobson commented on MRELEASE-254: -- I'm using cygwin too. Are the errors line-ending problems? They should be set correctly by svn:eol-style. > tests failed on windows > --- > > Key: MRELEASE-254 > URL: http://jira.codehaus.org/browse/MRELEASE-254 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: windows + cygwin >Reporter: Olivier Lamy > Attachments: MRELEASE-254 > > > Tests failed on windows due to Comparing files with String equals method. > This patch compares xml content with using xmlunit. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-254) tests failed on windows
[ http://jira.codehaus.org/browse/MRELEASE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100284 ] Olivier Lamy commented on MRELEASE-254: --- Content not same with assertEquals(expected, actual). xml content expected and actual. Note : - using cygwin - MAVEN_OPTS=-Dfile.encoding=ISO-8859-1 > tests failed on windows > --- > > Key: MRELEASE-254 > URL: http://jira.codehaus.org/browse/MRELEASE-254 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: windows + cygwin >Reporter: Olivier Lamy > Attachments: MRELEASE-254 > > > Tests failed on windows due to Comparing files with String equals method. > This patch compares xml content with using xmlunit. -- 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: (MJAVADOC-129) javadocDirectory config parameter is ignored and default doesn't work either.
javadocDirectory config parameter is ignored and default doesn't work either. -- Key: MJAVADOC-129 URL: http://jira.codehaus.org/browse/MJAVADOC-129 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.3 Environment: linux 2.6, mvn 2.0.6 Reporter: Adam Hardy Attachments: javadocBug.zip javadoc should pick up the javadoc package.html and overview.html and image files from src/main/javadoc by default. It will only pick up the src/main/javadoc directory if it is entered in the sourcepath config param. -- 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: (MJAVADOC-106) Dependencies with scope "runtime" or "provided" are not used in the javadoc classpath
[ http://jira.codehaus.org/browse/MJAVADOC-106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adam Hardy updated MJAVADOC-106: Attachment: javadocBug.zip This zip contains a maven project with the bare necessities to run javadoc. I have added the test directory to the sourcepath so that its test files are included. The work-around is to set the dependency scope to 'provided' which then means that mvn puts it in the classpath for javadoc. > Dependencies with scope "runtime" or "provided" are not used in the javadoc > classpath > - > > Key: MJAVADOC-106 > URL: http://jira.codehaus.org/browse/MJAVADOC-106 > Project: Maven 2.x Javadoc Plugin > Issue Type: Bug >Affects Versions: 2.1 >Reporter: Christophe DENEUX > Attachments: javadocBug.zip > > > Hi, > I have a class inherited from an hibernate class. So my project contains a > dependency onto Hibernate with the default scope, and an other dependencies > needed by Hibernate with scope=runtime and/or provided. > My javadoc plugin is configured to use the doclet Umlgraph. > At the report generation I have an error telling that classes are not found. > These classes are contained in dependencies with scope=runtime/provided. If I > change the scope to compile, that works fine. > After investigation in the source code, it seems to me that only dependencies > with scope=compile are used. > Can you take into account dependencies with scope=runtime/provided, or > propose configuration parameters to set these artifacts. > Christophe DENEUX > Capgemini Sud - France - Nice -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-254) tests failed on windows
[ http://jira.codehaus.org/browse/MRELEASE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100281 ] Mark Hobson commented on MRELEASE-254: -- I don't actually have a problem running the tests on Windows. What errors do you get? > tests failed on windows > --- > > Key: MRELEASE-254 > URL: http://jira.codehaus.org/browse/MRELEASE-254 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: windows + cygwin >Reporter: Olivier Lamy > Attachments: MRELEASE-254 > > > Tests failed on windows due to Comparing files with String equals method. > This patch compares xml content with using xmlunit. -- 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: (MASSEMBLY-175) MANIFEST entries are not preserved during assemby
[ http://jira.codehaus.org/browse/MASSEMBLY-175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100277 ] Paul Gier commented on MASSEMBLY-175: - I don't think this is the correct behaviour. There may be situations where you want to create a jar with deps, but do not want the same manifest configuration. It seems like it's better/simpler to just add the desired manifest configuration to to the assembly plugin config. You have some duplication of config, but it is more clear what is happening. > MANIFEST entries are not preserved during assemby > - > > Key: MASSEMBLY-175 > URL: http://jira.codehaus.org/browse/MASSEMBLY-175 > Project: Maven 2.x Assembly Plugin > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Tomasz Pik > Fix For: 2.2-beta-2 > > > "jar-with-dependencies" assembly should preserve MANIFEST entries from > project main result (so configuration for this will be inherited from > maven-jar-plugin). > This is especially important in case for parameter. -- 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: (MASSEMBLY-121) Custom manifest attributres are ignored.
[
http://jira.codehaus.org/browse/MASSEMBLY-121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul Gier updated MASSEMBLY-121:
Attachment: assembly-plugin.patch
Attaching a small change that seems to fix the issue without breaking any of
the other tests.
> Custom manifest attributres are ignored.
>
>
> Key: MASSEMBLY-121
> URL: http://jira.codehaus.org/browse/MASSEMBLY-121
> Project: Maven 2.x Assembly Plugin
> Issue Type: Bug
>Affects Versions: 2.1
> Environment: Windows XP SP2
> Java JDK 1.5.0_07
> Maven 2.0.4
>Reporter: Mark Reynolds
>Assignee: John Casey
> Fix For: 2.2-beta-2
>
> Attachments: assembly-plugin.patch, massembly121.zip
>
>
> Configure custom manifest entry in pom.xml
>
> maven-assembly-plugin
> 2.1
> false
>
>
> package
>
> attached
>
>
>
>
> ${basedir}/src/main/assembly/install.xml
>
>
> ${project.build.directory}
>
> ${project.build.directory}/assembly/work
>
>
> com.company.Install
>
>
> development
>
>
>
>
>
>
> Custom manifest entry "mode" does not appear in jar manifest (although main
> class entry does).
--
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: (MRELEASE-254) tests failed on windows
[ http://jira.codehaus.org/browse/MRELEASE-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated MRELEASE-254: -- Attachment: MRELEASE-254 patch attached. > tests failed on windows > --- > > Key: MRELEASE-254 > URL: http://jira.codehaus.org/browse/MRELEASE-254 > Project: Maven 2.x Release Plugin > Issue Type: Bug > Environment: windows + cygwin >Reporter: Olivier Lamy > Attachments: MRELEASE-254 > > > Tests failed on windows due to Comparing files with String equals method. > This patch compares xml content with using xmlunit. -- 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-2932) Encoding chaos
[ http://jira.codehaus.org/browse/MNG-2932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2932: --- Fix Version/s: (was: Reviewed Pending Version Assignment) 2.0.8 > Encoding chaos > -- > > Key: MNG-2932 > URL: http://jira.codehaus.org/browse/MNG-2932 > Project: Maven 2 > Issue Type: Bug > Components: POM::Encoding >Affects Versions: 2.0.4, 2.0.5, 2.0.6 > Environment: windows, linux >Reporter: Jörg Hohwiller > Fix For: 2.0.8 > > > I have tried maven on a project where javadocs, xdocs, pom-comments are in a > native language with many NON-ASCII characters. > This seems to reveal that maven is not acting clean with different encodings. > For instance the xdocs are XML. And XML allows me to use different encodings > if properly declared in the xml header. However it only works if I encode the > XML as UTF-8. If I use ISO-8859-1 then the produced HTML contains UTF-8 > characters from the nationalized site messages (resource bundles of maven > plugins) and maven dumps the ISO-8859-1 encoded characters into that and ends > up with mixed encodings in one HTML page. > Additionally the JAVA files also cause trouble when I use a different > encoding than UTF-8. I configured the "encoding" for javadoc plugin to > ISO-8859-1 and used Java files in that encoding. The resulting javadoc HTML > was written in ISO-8859-1 but the browser displayed it as UTF-8 and I had to > switch explicitly to ISO-8859-1 in firefox in order to have the special > characters displayed properly. > Further I encounter trouble when I use special characters in pom.xml files > that go onto the generated web-site. In the end I could NOT find a way to > have a site without problems - even when I encode everything as UTF-8. > Maybe there are too few developers involved from non english-speaking > countries that are used to think beyond US-ASCII ;) > Unfortunatly I can not tell where the problems come from - it may be XPP, > doxia, site-plugin or individual reports or all together. > You need to properly distinguish between input and output encoding and have > to be extremly careful with Stuff like byte[] > and never parse XML from strings. > Can you reproduce the problem or do you need dummy projects as test-cases? -- 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: (MRELEASE-254) tests failed on windows
tests failed on windows --- Key: MRELEASE-254 URL: http://jira.codehaus.org/browse/MRELEASE-254 Project: Maven 2.x Release Plugin Issue Type: Bug Environment: windows + cygwin Reporter: Olivier Lamy Attachments: MRELEASE-254 Tests failed on windows due to Comparing files with String equals method. This patch compares xml content with using xmlunit. -- 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-2254) the encoding parameter in xml declaration of POM is ignored
[ http://jira.codehaus.org/browse/MNG-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2254: --- Fix Version/s: (was: 2.1.x) 2.0.8 > the encoding parameter in xml declaration of POM is ignored > > > Key: MNG-2254 > URL: http://jira.codehaus.org/browse/MNG-2254 > Project: Maven 2 > Issue Type: Bug > Components: POM::Encoding >Reporter: Naoki Nose >Assignee: Jason van Zyl > Fix For: 2.0.8 > > Attachments: DefaultMavenProjectBuilder.diff, modello-plugin-xpp3.diff > > > DefaultMavenProjectBuilder reads POM in system default character encoding, > and the encoding parameter in xml declartion is ignored. > to fix this problem, We should > - fix modello-plugin-xpp3 to use the xml parser which is able to handle the > encoding parameter properly > - regenerate maven-model using fixed modello-plugin-xpp3 > - fix DefaultMavenProjectBuilder to use regenerated maven-model properly. -- 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-2025) POM is still not read using the right encoding
[ http://jira.codehaus.org/browse/MNG-2025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jason van Zyl updated MNG-2025: --- Fix Version/s: (was: 2.1.x) 2.0.8 > POM is still not read using the right encoding > -- > > Key: MNG-2025 > URL: http://jira.codehaus.org/browse/MNG-2025 > Project: Maven 2 > Issue Type: Bug > Components: POM::Encoding >Affects Versions: 2.0 >Reporter: Stefan Hübner >Assignee: Jason van Zyl >Priority: Critical > Fix For: 2.0.8 > > Attachments: MNG-2025-maven-model-testcases.patch, > MNG-2025-maven-project-testcases.patch > > > IIRC XML standard says that default encoding is UTF-8 for xml files > That can be overriden with > > But files without header saved as UTF8 are not parsed in some systems (eg > windows, solaris), while files saved as other encoding (I believe it was > ansi) break under a Mac mini with yellowdog linux -- 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-2216) Add default encodings section to POM
[
http://jira.codehaus.org/browse/MNG-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jason van Zyl updated MNG-2216:
---
Fix Version/s: (was: 2.1.x)
2.0.8
> Add default encodings section to POM
>
>
> Key: MNG-2216
> URL: http://jira.codehaus.org/browse/MNG-2216
> Project: Maven 2
> Issue Type: Improvement
> Components: POM::Encoding
>Affects Versions: 2.0, 2.0.1, 2.0.2, 2.0.3
>Reporter: Trustin Lee
> Fix For: 2.0.8
>
> Attachments: example-pom.xml
>
>
> Look at the attached example POM.
> Do you see many duplicate configuration properties ('UTF-8') in it? and the
> names of properties are very inconsistent.
> It would be great if:
> 1) Add a global section which specifies default encodings:
>
>
> UTF-8
>
> UTF-8
>
> 2) Make encoding properties in all plugins to be consistent and deprecate old
> properties. The default values could be:
> inputEncoding = ${pom.encoding.input}
> outputEncoding = ${pom.encoding.output}
> so users can override the default settings easily.
--
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=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Lamy updated CONTINUUM-44: -- Attachment: CONTINUUM-44-GOODIES Sorry just detected a small issue on the previous patch Information on the builder in the mail was not correct. > multiple profiles > - > > Key: CONTINUUM-44 > URL: http://jira.codehaus.org/browse/CONTINUUM-44 > Project: Continuum > Issue Type: New Feature > Components: Core - Profiles >Reporter: Brett Porter >Assignee: Emmanuel Venisse > Fix For: 1.1-alpha-3 > > Attachments: CONTINUUM-44, CONTINUUM-44, > CONTINUUM-44-continuum-data-management, > CONTINUUM-44-continuum-data-management, CONTINUUM-44-GOODIES, > CONTINUUM-44-GOODIES, CONTINUUM-44-LICENSE-REFORMATED > > > 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] Commented: (CONTINUUM-1094) Continuum does not build with Sun JDK 6
[
http://jira.codehaus.org/browse/CONTINUUM-1094?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100270
]
Olivier Lamy commented on CONTINUUM-1094:
-
As I see in your logs it doesn't look to be a java6 trouble but a xml
comparaison with a String equals.
Now in the trunk it's made with xmlunit.
Can you check again with trunk ?
Thanks.
> Continuum does not build with Sun JDK 6
> ---
>
> Key: CONTINUUM-1094
> URL: http://jira.codehaus.org/browse/CONTINUUM-1094
> Project: Continuum
> Issue Type: Bug
> Components: Environmental
>Affects Versions: 1.1-alpha-1
> Environment: continuum trunk r490449
> linux 2.6.12
> Sun JDK 6 (build 1.6.0-b105)
>Reporter: Minto van der Sluis
> Fix For: 1.1-alpha-3
>
> Attachments:
> org.apache.maven.continuum.management.DataManagementToolTest.txt
>
>
> snippet of the build output (mvn clean install).
> ...
> [INFO]
>
> [INFO] Building Continuum Data Management API
> [INFO]task-segment: [clean, install]
> [INFO]
>
> [INFO] [clean:clean]
> [INFO] Deleting directory
> /home/minto/rommel/svn-src/continuum/continuum-data-management/target
> [INFO] Deleting directory
> /home/minto/rommel/svn-src/continuum/continuum-data-management/target/classes
> [INFO] Deleting directory
> /home/minto/rommel/svn-src/continuum/continuum-data-management/target/test-classes
> [INFO] [plexus:descriptor {execution: generate}]
> [INFO] [resources:resources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:compile]
> Compiling 2 source files to
> /home/minto/rommel/svn-src/continuum/continuum-data-management/target/classes
> [INFO] [resources:testResources]
> [INFO] Using default encoding to copy filtered resources.
> [INFO] [compiler:testCompile]
> Compiling 1 source file to
> /home/minto/rommel/svn-src/continuum/continuum-data-management/target/test-classes
> [INFO] [surefire:test]
> [INFO] Surefire report directory:
> /home/minto/rommel/svn-src/continuum/continuum-data-management/target/surefire-reports
> ---
> T E S T S
> ---
> Running org.apache.maven.continuum.management.DataManagementToolTest
> Tests run: 3, Failures: 0, Errors: 2, Skipped: 0, Time elapsed: 8.348 sec <<<
> FAILURE!
> Results :
> Tests run: 3, Failures: 0, Errors: 2, Skipped: 0
> [INFO]
>
> [ERROR] BUILD FAILURE
> [INFO]
>
> Builds with JDK 5 runs just fine.
--
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-2254) the encoding parameter in xml declaration of POM is ignored
[ http://jira.codehaus.org/browse/MNG-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100268 ] Jason van Zyl commented on MNG-2254: Herve, if you want take a crack at this I would certainly incorporate this into Modello. > the encoding parameter in xml declaration of POM is ignored > > > Key: MNG-2254 > URL: http://jira.codehaus.org/browse/MNG-2254 > Project: Maven 2 > Issue Type: Bug > Components: POM::Encoding >Reporter: Naoki Nose >Assignee: Jason van Zyl > Fix For: 2.1.x > > Attachments: DefaultMavenProjectBuilder.diff, modello-plugin-xpp3.diff > > > DefaultMavenProjectBuilder reads POM in system default character encoding, > and the encoding parameter in xml declartion is ignored. > to fix this problem, We should > - fix modello-plugin-xpp3 to use the xml parser which is able to handle the > encoding parameter properly > - regenerate maven-model using fixed modello-plugin-xpp3 > - fix DefaultMavenProjectBuilder to use regenerated maven-model properly. -- 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-2254) the encoding parameter in xml declaration of POM is ignored
[ http://jira.codehaus.org/browse/MNG-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100267 ] Herve Boutemy commented on MNG-2254: for problems about encodings, there are ways to write a Reader that automagically detects the encoding of a XML stream: see https://rome.dev.java.net/apidocs/0_5/com/sun/syndication/io/XmlReader.html this permits to use a reader as a source for an XML parser without loosing any information: the magic is done by the reader, not by the parser. Such a solution would be an easy fix: the actual MavenXpp3Reader signature could be sufficient (even if using an InputStream would be more classical) > the encoding parameter in xml declaration of POM is ignored > > > Key: MNG-2254 > URL: http://jira.codehaus.org/browse/MNG-2254 > Project: Maven 2 > Issue Type: Bug > Components: POM::Encoding >Reporter: Naoki Nose >Assignee: Jason van Zyl > Fix For: 2.1.x > > Attachments: DefaultMavenProjectBuilder.diff, modello-plugin-xpp3.diff > > > DefaultMavenProjectBuilder reads POM in system default character encoding, > and the encoding parameter in xml declartion is ignored. > to fix this problem, We should > - fix modello-plugin-xpp3 to use the xml parser which is able to handle the > encoding parameter properly > - regenerate maven-model using fixed modello-plugin-xpp3 > - fix DefaultMavenProjectBuilder to use regenerated maven-model properly. -- 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: (MANTTASKS-75) [PATCH] NPE if loaded settings.xml does not contain
[PATCH] NPE if loaded settings.xml does not contain - Key: MANTTASKS-75 URL: http://jira.codehaus.org/browse/MANTTASKS-75 Project: Maven 2.x Ant Tasks Issue Type: Bug Affects Versions: 2.0.6 Environment: Ant 1.6.5 Reporter: Herve Boutemy see http://www.nabble.com/Re%3A-NullPointer-with-maven-ant-tasks-2.0.6-%28linux%29-p11220688s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MANTTASKS-75) [PATCH] NPE if loaded settings.xml does not contain
[ http://jira.codehaus.org/browse/MANTTASKS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-75: --- Attachment: MANTTASKS-75.diff > [PATCH] NPE if loaded settings.xml does not contain > - > > Key: MANTTASKS-75 > URL: http://jira.codehaus.org/browse/MANTTASKS-75 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 > Environment: Ant 1.6.5 >Reporter: Herve Boutemy > Fix For: 2.0.7 > > Attachments: MANTTASKS-75.diff > > > see > http://www.nabble.com/Re%3A-NullPointer-with-maven-ant-tasks-2.0.6-%28linux%29-p11220688s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MANTTASKS-75) [PATCH] NPE if loaded settings.xml does not contain
[ http://jira.codehaus.org/browse/MANTTASKS-75?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MANTTASKS-75: --- Priority: Trivial (was: Major) Fix Version/s: 2.0.7 > [PATCH] NPE if loaded settings.xml does not contain > - > > Key: MANTTASKS-75 > URL: http://jira.codehaus.org/browse/MANTTASKS-75 > Project: Maven 2.x Ant Tasks > Issue Type: Bug >Affects Versions: 2.0.6 > Environment: Ant 1.6.5 >Reporter: Herve Boutemy >Priority: Trivial > Fix For: 2.0.7 > > Attachments: MANTTASKS-75.diff > > > see > http://www.nabble.com/Re%3A-NullPointer-with-maven-ant-tasks-2.0.6-%28linux%29-p11220688s177.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MAVENUPLOAD-1609) Synchronize opensymphony:xwork:jar:2.0.3 to central repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100266 ] Olivier Lamy commented on MAVENUPLOAD-1609: --- Ok, I see. I need to ask struts project to change the dependency in http://repo1.maven.org/maven2/org/apache/struts/struts2-core/2.0.8/struts2-core-2.0.8.pom. Is there any possible workaround with relocation ? Thanks. > Synchronize opensymphony:xwork:jar:2.0.3 to central repo > > > Key: MAVENUPLOAD-1609 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1609 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Olivier Lamy > > Hi, > The artifact opensymphony:xwork:jar:2.0.3 is in the opensymphony repository > http://maven2.opensymphony.com/opensymphony/xwork/2.0.3/ . > Is it possible to have in http://repo1.maven.org/maven2/opensymphony/xwork/ ? > 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: (MAVENUPLOAD-1608) FontBox/JempBox/PDFBox updates
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100265 ] Ben Litchfield commented on MAVENUPLOAD-1608: - hmm, the existing pdfbox uses a groupid of "pdfbox" why would the groupid of fontbox be "org.fontbox"? Can you please point me to documentation that states the format of the groupid. Looking through the repository for example groupids, I don't see any that start with "org." Ben > FontBox/JempBox/PDFBox updates > -- > > Key: MAVENUPLOAD-1608 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1608 > Project: maven-upload-requests > Issue Type: Task >Reporter: Ben Litchfield > > Please let me know if this is right, this is the first time I have submitted > a request for a maven bundle. > Additional bundles > http://www.pdfbox.org/dist/FontBox-0.1.0-maven.jar > http://www.pdfbox.org/dist/JempBox-0.2.0-maven.jar > Other Project URLs > http://www.jempbox.org/ > http://www.fontbox.org/ > PDFBox SF Project site http://sourceforge.net/projects/pdfbox shows > benlitchfield as project admin > Thanks, > Ben -- 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: (MAVENUPLOAD-1609) Synchronize opensymphony:xwork:jar:2.0.3 to central repo
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100263 ] Carlos Sanchez commented on MAVENUPLOAD-1609: - right now we are only syncing com.opensymphony from there as you can see from the script https://svn.apache.org/repos/asf/maven/archiva/trunk/maven-meeper/src/bin/synchronize/m2-sync/conf/com.opensymphony.sh if you want to keep the old groupId for historical reasons we can do it, but you must remove all the snapshots that are in that repo > Synchronize opensymphony:xwork:jar:2.0.3 to central repo > > > Key: MAVENUPLOAD-1609 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1609 > Project: maven-upload-requests > Issue Type: Bug >Reporter: Olivier Lamy > > Hi, > The artifact opensymphony:xwork:jar:2.0.3 is in the opensymphony repository > http://maven2.opensymphony.com/opensymphony/xwork/2.0.3/ . > Is it possible to have in http://repo1.maven.org/maven2/opensymphony/xwork/ ? > 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] Closed: (MAVENUPLOAD-1604) release ognl 2.7
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1604. --- Assignee: Carlos Sanchez Resolution: Fixed until we have a better solution we need another script, that I already added https://svn.apache.org/repos/asf/maven/archiva/trunk/maven-meeper/src/bin/synchronize/m2-sync/conf/ognl.sh > release ognl 2.7 > > > Key: MAVENUPLOAD-1604 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1604 > Project: maven-upload-requests > Issue Type: Task >Reporter: Jesse Kuhnert >Assignee: Carlos Sanchez > > The 2.7 release has been made to a remote repository which can be found here: > http://opencomponentry.com/repository/m2-ibiblio-sync-repo/ognl/ognl/2.7/ . > The main project web site is http://www.ognl.org, but also > http://opensymphony.com/ognl/ since the project was taken over by > opensymphony. > I haven't yet made any new changes to the actual web site (still syncing with > Patrick) so I'm not listed officially on a team list but am visible as the > project lead here: http://jira.opensymphony.com/browse/OGNL. -- 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: (MRM-414) Don't queue a request to scan a repository that is currently being scanned
[ http://jira.codehaus.org/browse/MRM-414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-414: --- Fix Version/s: 1.0-alpha-2 > Don't queue a request to scan a repository that is currently being scanned > -- > > Key: MRM-414 > URL: http://jira.codehaus.org/browse/MRM-414 > Project: Archiva > Issue Type: Improvement > Components: indexing >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak >Priority: Minor > Fix For: 1.0-alpha-2 > > > If a repository is currently being scanned when the 'Scan Repository Now' > button is clicked, don't queue another request to scan it. > Example: > INFO | jvm 1| 2007/06/10 21:00:09 | 728900 [SocketListener0-1] INFO > com.opensymphony.xwork.Action:schedulerAction - [ActionMessage] Your request > to have repository [central] be indexed has been queued. > INFO | jvm 1| 2007/06/10 21:00:09 | 728902 [pool-2-thread-1] INFO > org.codehaus.plexus.taskqueue.execution.TaskExecutor:repository-scanning - > Executing task from queue with job name: repository-job:central > INFO | jvm 1| 2007/06/10 21:00:09 | 728928 [pool-2-thread-1] INFO > org.apache.maven.archiva.repository.scanner.RepositoryScanner:default - Walk > Started: [central] file:/opt/central-repository/ > INFO | jvm 1| 2007/06/10 21:01:08 | 788035 [SocketListener0-1] INFO > com.opensymphony.xwork.Action:schedulerAction - [ActionMessage] Your request > to have repository [central] be indexed has been queued. -- 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: (MAVENUPLOAD-1608) FontBox/JempBox/PDFBox updates
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100260 ] Carlos Sanchez commented on MAVENUPLOAD-1608: - I missed the other bundles, but you are using wrong groupIds they must be org.fontbox and org.jempbox or something like that > FontBox/JempBox/PDFBox updates > -- > > Key: MAVENUPLOAD-1608 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1608 > Project: maven-upload-requests > Issue Type: Task >Reporter: Ben Litchfield > > Please let me know if this is right, this is the first time I have submitted > a request for a maven bundle. > Additional bundles > http://www.pdfbox.org/dist/FontBox-0.1.0-maven.jar > http://www.pdfbox.org/dist/JempBox-0.2.0-maven.jar > Other Project URLs > http://www.jempbox.org/ > http://www.fontbox.org/ > PDFBox SF Project site http://sourceforge.net/projects/pdfbox shows > benlitchfield as project admin > Thanks, > Ben -- 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: (MRM-416) Find artifact does not work.
[ http://jira.codehaus.org/browse/MRM-416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-416: --- Fix Version/s: 1.0-alpha-2 > Find artifact does not work. > > > Key: MRM-416 > URL: http://jira.codehaus.org/browse/MRM-416 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Henry S. Isidro > Fix For: 1.0-alpha-2 > > > Finding an artifact always shows the 'No results found' message even though > the artifact that is being looked for is in the repository. -- 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: (MRM-419) WebDAV functionality not working for Internet Explorer / Windows Network Places
[ http://jira.codehaus.org/browse/MRM-419?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-419. -- Assignee: Joakim Erdfelt Resolution: Duplicate Fix Version/s: 1.0-alpha-2 This is a duplicate of MRM-417 (which was recently fixed on trunk) > WebDAV functionality not working for Internet Explorer / Windows Network > Places > --- > > Key: MRM-419 > URL: http://jira.codehaus.org/browse/MRM-419 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-alpha-2 >Reporter: John Didion >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-2 > > > I am using archiva built from source (r548493). I set up a managed repository > and several proxied repositories. > Browsing the WebDAV url from Firefox works just fine, but it appears the IE > doesn't recognize the url - it asks me if I want to "save this file", and its > type is unknown. > When I try to set up a Network Place using the url, it shows me the top level > of the repository, but if I try to browse to any folder, I get the error: > "Documents in this folder are not available. The folder may have been moved > or deleted, or network problems may be preventing a connection to the server. > There is a problem with the web server. Please try again later or contact the > server administrator." > I notice that the url it's trying to browse to is incorrect. The root URL of > the repository is: > http://[host]/archiva/repository/internal/ > but when I double-click on, say, commons-collections, it tries to browse to: > http://repository.muze.com/archiva/repository/commons-collections -- 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: (MRM-412) Add support for maven1 (legacy) request to access a maven2 (default layout) repo
[ http://jira.codehaus.org/browse/MRM-412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-412: --- Fix Version/s: 1.0.x > Add support for maven1 (legacy) request to access a maven2 (default layout) > repo > > > Key: MRM-412 > URL: http://jira.codehaus.org/browse/MRM-412 > Project: Archiva > Issue Type: Improvement > Components: WebDAV interface >Affects Versions: 1.0-alpha-2 >Reporter: nicolas de loof >Priority: Minor > Fix For: 1.0.x > > Attachments: archiva-1.0-alpha-2.patch > > > archiva 1.0-alpha-1 doesn't support converting legacy-layout request to > default layout. This behaviour is usefull to allow maven1 to access a maven2 > repository, and avoid having multiple managed repo as proxies to central. > The attached patch add this support : > - it adds to BidirectionalRepositoryLayout the new method boolean > isValidPath( String path ) > - it adds to BidirectionalRepositoryLayoutFactory the new method > BidirectionalRepositoryLayout getLayoutForPath( String path ) > - it use them to detect the layout used by incoming request and build the > ArchivaArtifact object used to proxy the request. It aslo overrides the > pathInfo to make the request point to the real-file path in the managed > repository > BidirectionalRepositoryLayoutFactoryTest also updated -- 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: (MRM-221) Webdav upload is not working
[ http://jira.codehaus.org/browse/MRM-221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-221: --- Assignee: Wendy Smoak Affects Version/s: (was: 1.0) 1.0-alpha-1 Fix Version/s: 1.0-alpha-2 > Webdav upload is not working > > > Key: MRM-221 > URL: http://jira.codehaus.org/browse/MRM-221 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-alpha-1 > Environment: Mac OS X using the default jetty container. Jetty > started with mvn jetty:run >Reporter: Greg Luck >Assignee: Wendy Smoak > Fix For: 1.0-alpha-2 > > > MRM-172 added webdav support. This is not working. > I have everything working scping to the repository. webdav via Archiva does > not work. > When I use > > > > > > url="dav://localhost:9091/repository/maven_repository"> > password="###"/> > > > > I get > upload-to-repository: > [artifact:install-provider] Installing provider: > org.apache.maven.wagon:wagon-webdav:jar:1.0-beta-1 > [artifact:install-provider] Installing provider: > org.apache.maven.wagon:wagon-ssh:jar:1.0-beta-1 > [artifact:install] [INFO] Installing > /Users/gluck/work/ehcache/trunk/target/dist/ehcache-1.2.4.jar to > /m2repository/net/sf/ehcache/ehcache/1.2.4/ehcache-1.2.4.jar > [artifact:deploy] Deploying to > dav://localhost:9091/repository/maven_repository > [artifact:deploy] WAGON_VERSION: 1.0-beta-1 > BUILD FAILED > /Users/gluck/work/ehcache/trunk/build.xml:364: > java.lang.IllegalArgumentException: id is null > If I click on the webdav link from archiva I get: > Error 404 Not Found > Resource in error: http://localhost:9091/repository/LOCAL/maven_repository > Exception details: > it.could.webdav.DAVException: Not found > at it.could.webdav.methods.HEAD.process(HEAD.java:52) > at it.could.webdav.methods.GET.process(GET.java:58) > at it.could.webdav.DAVProcessor.process(DAVProcessor.java:79) > at > org.apache.maven.archiva.web.servlet.repository.RepositoryAccess.servletRequest(RepositoryAccess.java:223) > at > org.apache.maven.archiva.web.servlet.PlexusComponentServlet.service(PlexusComponentServlet.java:126) > at > org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:445) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1049) > at > com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:189) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1040) > at > com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118) > at > com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1040) > at > com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88) > at > org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1040) > at > org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:352) > at > org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:230) > at > org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:627) > at > org.mortbay.jetty.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:149) > at > org.mortbay.jetty.handler.HandlerCollection.handle(HandlerCollection.java:123) > at > org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:141) > at org.mortbay.jetty.Server.handle(Server.java:286) > at > org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:444) > at > org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:701) > at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:500) > at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:203) > at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:340) > at > org.mortbay.jetty.nio.HttpChannelEndPoint.run(HttpChannelEndPoint.java:270) > at > org.mortbay.thread.BoundedThreadPool$PoolThread.run(BoundedThreadPool.java:475) -- 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-1606) Upload OpenOffice.org Java/Uno 2.2.1
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1606. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload OpenOffice.org Java/Uno 2.2.1 > > > Key: MAVENUPLOAD-1606 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1606 > Project: maven-upload-requests > Issue Type: Task >Reporter: Mirko Nasato >Assignee: Carlos Sanchez > > OpenOffice.org includes some JARs that can be used in a standalone Java app > to connect to a running OpenOffice.org instance. > Please find the bundles here: > http://www.artofsolving.com/files/m2/juh-2.2.1-bundle.jar > http://www.artofsolving.com/files/m2/jurt-2.2.1-bundle.jar > http://www.artofsolving.com/files/m2/ridl-2.2.1-bundle.jar > http://www.artofsolving.com/files/m2/unoil-2.2.1-bundle.jar -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MAVENUPLOAD-1607) Upload Unitils 1.0 rc 3
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Carlos Sanchez closed MAVENUPLOAD-1607. --- Assignee: Carlos Sanchez Resolution: Fixed > Upload Unitils 1.0 rc 3 > --- > > Key: MAVENUPLOAD-1607 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1607 > Project: maven-upload-requests > Issue Type: Task >Reporter: Tim Ducheyne >Assignee: Carlos Sanchez > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-419) WebDAV functionality not working for Internet Explorer / Windows Network Places
WebDAV functionality not working for Internet Explorer / Windows Network Places --- Key: MRM-419 URL: http://jira.codehaus.org/browse/MRM-419 Project: Archiva Issue Type: Bug Components: WebDAV interface Affects Versions: 1.0-alpha-2 Reporter: John Didion I am using archiva built from source (r548493). I set up a managed repository and several proxied repositories. Browsing the WebDAV url from Firefox works just fine, but it appears the IE doesn't recognize the url - it asks me if I want to "save this file", and its type is unknown. When I try to set up a Network Place using the url, it shows me the top level of the repository, but if I try to browse to any folder, I get the error: "Documents in this folder are not available. The folder may have been moved or deleted, or network problems may be preventing a connection to the server. There is a problem with the web server. Please try again later or contact the server administrator." I notice that the url it's trying to browse to is incorrect. The root URL of the repository is: http://[host]/archiva/repository/internal/ but when I double-click on, say, commons-collections, it tries to browse to: http://repository.muze.com/archiva/repository/commons-collections -- 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: (MRM-403) when browsing, groups list incorrect sub-groups
[ http://jira.codehaus.org/browse/MRM-403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-403. -- Resolution: Fixed Fixed in trunk. > when browsing, groups list incorrect sub-groups > --- > > Key: MRM-403 > URL: http://jira.codehaus.org/browse/MRM-403 > Project: Archiva > Issue Type: Bug > Components: WebDAV interface >Affects Versions: 1.0-alpha-1 >Reporter: Brett Porter >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-2 > > > eg. go to group ant, and see more groups are listed at the top (eg, ant > again, but also ant-contrib, etc), even though you are inside a group that > does not have sub groups. -- 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: (MAVENUPLOAD-1608) FontBox/JempBox/PDFBox updates
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100257 ] Carlos Sanchez commented on MAVENUPLOAD-1608: - you have to request the upload of all the dependencies first if they are not in the repo missing tag > FontBox/JempBox/PDFBox updates > -- > > Key: MAVENUPLOAD-1608 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1608 > Project: maven-upload-requests > Issue Type: Task >Reporter: Ben Litchfield > > Please let me know if this is right, this is the first time I have submitted > a request for a maven bundle. > Additional bundles > http://www.pdfbox.org/dist/FontBox-0.1.0-maven.jar > http://www.pdfbox.org/dist/JempBox-0.2.0-maven.jar > Other Project URLs > http://www.jempbox.org/ > http://www.fontbox.org/ > PDFBox SF Project site http://sourceforge.net/projects/pdfbox shows > benlitchfield as project admin > Thanks, > Ben -- 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: (MRM-357) Update Consumers button in Repository Scanning doesn't work
[ http://jira.codehaus.org/browse/MRM-357?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-357. -- Resolution: Fixed Patch applied in trunk. Thanks! > Update Consumers button in Repository Scanning doesn't work > --- > > Key: MRM-357 > URL: http://jira.codehaus.org/browse/MRM-357 > Project: Archiva > Issue Type: Bug > Components: repository scanning >Affects Versions: 1.0-alpha-1 >Reporter: Dawn Angelito >Assignee: Joakim Erdfelt >Priority: Critical > Fix For: 1.0-alpha-2 > > Attachments: MRM-357-archiva-webapp.patch > > > 1) Log in as admin. > 2) Click the Repository Scanning button in the left menu under Administration. > 3) In Repository Scanning - Consumers of Known Content, check > "validate-checksums" to enable it. > 4) Click the Update Consumers button. > Once the page is refreshed, notice that "validate-checksums" is still > disabled. -- 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: (MRM-402) javadoc jar is listed as just jar in the download box
[ http://jira.codehaus.org/browse/MRM-402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100249 ] Joakim Erdfelt commented on MRM-402: Attached image of what happens. The list of links in this example link to the following artifacts ... * daytrader-ejb-2.0-SNAPSHOT.jar * daytrader-ejb-2.0-SNAPSHOT.pom * daytrader-ejb-2.0-SNAPSHOT-client.jar * daytrader-ejb-2.0-SNAPSHOT-javadoc.jar * daytrader-ejb-2.0-SNAPSHOT-sources.jar I think it should show the following instead. | *Jar* | | _(size-kb)_ | | *Pom* | | _(size-kb)_ | | *Jar* | Client | _(size-kb)_ | | *Jar* | Javadoc | _(size-kb)_ | | *Jar* | Source | _(size-kb)_ | What do you think? > javadoc jar is listed as just jar in the download box > - > > Key: MRM-402 > URL: http://jira.codehaus.org/browse/MRM-402 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-1 >Reporter: Brett Porter >Priority: Minor > Fix For: 1.0.x > > Attachments: archiva-bad-downloads-box.jpg > > > go to an artifact that has an attached javadoc jar - you will notice that it > is described as "Jar", not "Javadoc" -- 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: (MRM-402) javadoc jar is listed as just jar in the download box
[ http://jira.codehaus.org/browse/MRM-402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt updated MRM-402: --- Attachment: archiva-bad-downloads-box.jpg > javadoc jar is listed as just jar in the download box > - > > Key: MRM-402 > URL: http://jira.codehaus.org/browse/MRM-402 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-1 >Reporter: Brett Porter >Priority: Minor > Fix For: 1.0.x > > Attachments: archiva-bad-downloads-box.jpg > > > go to an artifact that has an attached javadoc jar - you will notice that it > is described as "Jar", not "Javadoc" -- 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: (MRM-416) Find artifact does not work.
[ http://jira.codehaus.org/browse/MRM-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100248 ] Joakim Erdfelt commented on MRM-416: Actually ... We can use the database contents in ArchivaArtifact to search for the checksums for MD5 and SHA1. That data is up to date. We should change this search from the old way of using Lucene to just using the database (as it's intended). > Find artifact does not work. > > > Key: MRM-416 > URL: http://jira.codehaus.org/browse/MRM-416 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Henry S. Isidro > > Finding an artifact always shows the 'No results found' message even though > the artifact that is being looked for is in the repository. -- 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: (MRM-417) Unable to view repository contents with IE6
[ http://jira.codehaus.org/browse/MRM-417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-417. -- Assignee: Joakim Erdfelt Resolution: Fixed Fix Version/s: 1.0-alpha-2 Fixed at plexus-webdav. Archiva trunk now using newly released plexus-webdav (1.0-alpha-3) with this fix. > Unable to view repository contents with IE6 > --- > > Key: MRM-417 > URL: http://jira.codehaus.org/browse/MRM-417 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-2 > > Attachments: screenshot-ie7-on-xp-sp2.jpg > > > Attempting to visit a url such as > http://repo.example.com/archiva/repository/releases/org/apache/struts results > in a dialog box: > File Download - Security Warning > Do you want to save this file? > Name: examples > Type: Unknown File Type > From: repo.mycompany.com > The 'file' in question is a directory. you can't see the repo contents. -- 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-1609) Synchronize opensymphony:xwork:jar:2.0.3 to central repo
Synchronize opensymphony:xwork:jar:2.0.3 to central repo Key: MAVENUPLOAD-1609 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1609 Project: maven-upload-requests Issue Type: Bug Reporter: Olivier Lamy Hi, The artifact opensymphony:xwork:jar:2.0.3 is in the opensymphony repository http://maven2.opensymphony.com/opensymphony/xwork/2.0.3/ . Is it possible to have in http://repo1.maven.org/maven2/opensymphony/xwork/ ? 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: (MNG-3062) Allow access to mojoExecution from within plugin.
[ http://jira.codehaus.org/browse/MNG-3062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100241 ] Paul Gier commented on MNG-3062: My use case is basically what I said in the description. I would like to be able to call only certain executions of the surefire plugin. I'm currently accomplishing something similar using profiles, but it seemed like there should be an easier way to just call an execution. I was thinking that if the plugin had access to the execution id you could do something like: mvn test -Dmaven.test.execution1 Then the plugin could check the property to see if it should run or not. Not sure if this is the best way to do it, but it is one idea. Another idea would be to just add the execution ID to the plugin API, and set it when the plugin is initialized, maybe in the same place the log is initialized. But I thought there might be other useful information in the mojoExecution object. > Allow access to mojoExecution from within plugin. > - > > Key: MNG-3062 > URL: http://jira.codehaus.org/browse/MNG-3062 > Project: Maven 2 > Issue Type: Improvement >Affects Versions: 2.0.6 >Reporter: Paul Gier > Fix For: 2.0.x > > Attachments: PluginParameterExpressionEvaluator.patch > > > I would like to be able to access the execution ID from within a plugin. > This could be useful for example to run only certain executions. This could > be done with a small change to the plugin expression evaluator. > I created a patch that would give the plugin access to the current > MojoExecution. -- 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: (MRM-254) connecting proxied repositories without http-proxy fails
[ http://jira.codehaus.org/browse/MRM-254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrice BELLINGARD closed MRM-254. -- Resolution: Cannot Reproduce > connecting proxied repositories without http-proxy fails > > > Key: MRM-254 > URL: http://jira.codehaus.org/browse/MRM-254 > Project: Archiva > Issue Type: Improvement > Components: remote proxy > Environment: archiva-trunk on SuSE-Linux in intranet-environment > behind a firewall and with http-proxy >Reporter: Stefan Hübner >Assignee: Fabrice BELLINGARD >Priority: Critical > Fix For: 1.0-alpha-2 > > > If one configures Archiva to proxy another inhouse repository, Archiva > struggles to connect to the proxied repository. The log file contains 503 > HTTP Error Codes for any attempt to connect to the second repo. This is > because Archiva tries to connect to the second server via > http-proxy-connection (even though the proxied repository is configured not > to connect through http-proxy). > First thing, the "Use HTTP Proxy" option doesn't work properly since Archiva > *does* open proxy-connections even with that option inactive. > Second: I figured out, that there's a hidden option for HTTP-Proxy, only > configurable in Archiva's archiva.xml file. If the proxy-element contains a > "nonProxyHosts"-element (same as in maven settings.xml) and that element > lists the second server, all 503 return codes vanish. > Conclusion: either the "Use HTTP proxy"-option is screwed or serves a > different purpose. If first, please fix that issue. If second, please make > "nonProxyHosts" configurable via UI. > Cheers, > Stefan -- 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: (MRM-418) Remove the network proxy example from default archiva.xml
[ http://jira.codehaus.org/browse/MRM-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrice BELLINGARD closed MRM-418. -- Resolution: Fixed Fixed on trunk. > Remove the network proxy example from default archiva.xml > - > > Key: MRM-418 > URL: http://jira.codehaus.org/browse/MRM-418 > Project: Archiva > Issue Type: Task >Affects Versions: 1.0-alpha-1 >Reporter: Fabrice BELLINGARD >Assignee: Fabrice BELLINGARD >Priority: Minor > Fix For: 1.0-alpha-2 > > > See discussion on issue MRM-373. -- 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: (MRM-418) Remove the network proxy example from default archiva.xml
[ http://jira.codehaus.org/browse/MRM-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrice BELLINGARD updated MRM-418: --- Affects Version/s: (was: 1.0-alpha-2) 1.0-alpha-1 Fix Version/s: 1.0-alpha-2 > Remove the network proxy example from default archiva.xml > - > > Key: MRM-418 > URL: http://jira.codehaus.org/browse/MRM-418 > Project: Archiva > Issue Type: Task >Affects Versions: 1.0-alpha-1 >Reporter: Fabrice BELLINGARD >Assignee: Fabrice BELLINGARD >Priority: Minor > Fix For: 1.0-alpha-2 > > > See discussion on issue MRM-373. -- 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: (MRM-373) Unable to delete the pre-configured example network proxy
[ http://jira.codehaus.org/browse/MRM-373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100235 ] Fabrice BELLINGARD commented on MRM-373: I created MRM-418 to get a trace, in the changelog, of the removal of the default network proxy. As for this issue, unless you tell me that you can reproduce the bug, I'll close it for alpha-2. > Unable to delete the pre-configured example network proxy > - > > Key: MRM-373 > URL: http://jira.codehaus.org/browse/MRM-373 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak >Assignee: Fabrice BELLINGARD >Priority: Critical > Fix For: 1.0-alpha-2 > > > Archiva comes pre-configured with a network proxy. > When I delete it in the web UI, it comes back the next time I start Archiva. > It does not get removed from ~/.m2/archiva.xml. > Workaround: stop Archiva and edit ~/.m2/archiva.xml, then restart -- 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: (MRM-254) connecting proxied repositories without http-proxy fails
[ http://jira.codehaus.org/browse/MRM-254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100238 ] Fabrice BELLINGARD commented on MRM-254: Stefan, we're about to release 1.0-alpha-2, and I can't reproduce this bug. So I'll close this issue as "Cannot reproduce", and if there's a problem when you get the chance to test it, then feel free to open it again. > connecting proxied repositories without http-proxy fails > > > Key: MRM-254 > URL: http://jira.codehaus.org/browse/MRM-254 > Project: Archiva > Issue Type: Improvement > Components: remote proxy > Environment: archiva-trunk on SuSE-Linux in intranet-environment > behind a firewall and with http-proxy >Reporter: Stefan Hübner >Priority: Critical > Fix For: 1.0-alpha-2 > > > If one configures Archiva to proxy another inhouse repository, Archiva > struggles to connect to the proxied repository. The log file contains 503 > HTTP Error Codes for any attempt to connect to the second repo. This is > because Archiva tries to connect to the second server via > http-proxy-connection (even though the proxied repository is configured not > to connect through http-proxy). > First thing, the "Use HTTP Proxy" option doesn't work properly since Archiva > *does* open proxy-connections even with that option inactive. > Second: I figured out, that there's a hidden option for HTTP-Proxy, only > configurable in Archiva's archiva.xml file. If the proxy-element contains a > "nonProxyHosts"-element (same as in maven settings.xml) and that element > lists the second server, all 503 return codes vanish. > Conclusion: either the "Use HTTP proxy"-option is screwed or serves a > different purpose. If first, please fix that issue. If second, please make > "nonProxyHosts" configurable via UI. > Cheers, > Stefan -- 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: (MRM-418) Remove the network proxy example from default archiva.xml
[ http://jira.codehaus.org/browse/MRM-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Fabrice BELLINGARD updated MRM-418: --- Summary: Remove the network proxy example from default archiva.xml (was: Remove the network proxy example form default archiva.xml) > Remove the network proxy example from default archiva.xml > - > > Key: MRM-418 > URL: http://jira.codehaus.org/browse/MRM-418 > Project: Archiva > Issue Type: Task >Affects Versions: 1.0-alpha-2 >Reporter: Fabrice BELLINGARD >Assignee: Fabrice BELLINGARD >Priority: Minor > > See discussion on issue MRM-373. -- 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] Work started: (MRM-418) Remove the network proxy example form default archiva.xml
[ http://jira.codehaus.org/browse/MRM-418?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-418 started by Fabrice BELLINGARD. > Remove the network proxy example form default archiva.xml > - > > Key: MRM-418 > URL: http://jira.codehaus.org/browse/MRM-418 > Project: Archiva > Issue Type: Task >Affects Versions: 1.0-alpha-2 >Reporter: Fabrice BELLINGARD >Assignee: Fabrice BELLINGARD >Priority: Minor > > See discussion on issue MRM-373. -- 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: (MRM-418) Remove the network proxy example form default archiva.xml
Remove the network proxy example form default archiva.xml - Key: MRM-418 URL: http://jira.codehaus.org/browse/MRM-418 Project: Archiva Issue Type: Task Affects Versions: 1.0-alpha-2 Reporter: Fabrice BELLINGARD Priority: Minor See discussion on issue MRM-373. -- 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] Work started: (MRM-373) Unable to delete the pre-configured example network proxy
[ http://jira.codehaus.org/browse/MRM-373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-373 started by Fabrice BELLINGARD. > Unable to delete the pre-configured example network proxy > - > > Key: MRM-373 > URL: http://jira.codehaus.org/browse/MRM-373 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak >Assignee: Fabrice BELLINGARD >Priority: Critical > Fix For: 1.0-alpha-2 > > > Archiva comes pre-configured with a network proxy. > When I delete it in the web UI, it comes back the next time I start Archiva. > It does not get removed from ~/.m2/archiva.xml. > Workaround: stop Archiva and edit ~/.m2/archiva.xml, then restart -- 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: (MJAVADOC-128) Plugin does not accept URL to an offlineLink's location
Plugin does not accept URL to an offlineLink's location --- Key: MJAVADOC-128 URL: http://jira.codehaus.org/browse/MJAVADOC-128 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.2 Reporter: Greg Thompson According to http://java.sun.com/j2se/1.4.2/docs/tooldocs/solaris/javadoc.html#linkoffline, the location "is the path or URL to the directory containing the package-list file for the external documentation." The plugin's OfflineLink.java uses a java.io.File for the argument, which munges it if it's a URL. Easiest fix might be to just use String instead of 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] Created: (CONTINUUM-1323) Checked out shell script should be made executable prior to execution
Checked out shell script should be made executable prior to execution - Key: CONTINUUM-1323 URL: http://jira.codehaus.org/browse/CONTINUUM-1323 Project: Continuum Issue Type: Bug Components: Integration - Shell Affects Versions: 1.1-alpha-2 Reporter: Julien S I had the issue with cvs, I do not know if it also happens with other SCM. I created my shell script, chmoded it 755 under Unix, and added it to my cvs repository. When I checkout the script from somewhere else, it has the right mode, however, when continuum checks it out, it is not executable, triggering a build failure. -- 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: (MRM-385) Maven config docs refer to /proxy urls
[ http://jira.codehaus.org/browse/MRM-385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100233 ] Fabrice BELLINGARD commented on MRM-385: http://maven.apache.org/archiva/guides/maven-configuration.html seems OK. For the "Archiva as a Proxy" page on the Wiki, it looks like it was written for Archiva 0.9, right? > Maven config docs refer to /proxy urls > -- > > Key: MRM-385 > URL: http://jira.codehaus.org/browse/MRM-385 > Project: Archiva > Issue Type: Improvement > Components: documentation >Reporter: Wendy Smoak >Priority: Critical > Fix For: 1.0-alpha-2 > > > The Maven Configuration page still refers to urls containing "/proxy". These > no longer exist. > http://maven.apache.org/archiva/guides/maven-configuration.html > Also incorporate info from: > http://docs.codehaus.org/display/MAVENUSER/Archiva+as+a+Proxy -- 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: (MRM-399) NPE trying to access an artifact that should be proxied
[ http://jira.codehaus.org/browse/MRM-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100232 ] Fabrice BELLINGARD commented on MRM-399: Brett, I cannot reproduce the bug. The only difference with what you described is that I have to specify a network proxy to be able to download maven-core from the Web... Which, IMHO, does not make a big difference with your configuration. Actually, I tested proxying an internal corporate Maven 2 repo (i.e. without a network proxy), and it works perfectly. > NPE trying to access an artifact that should be proxied > --- > > Key: MRM-399 > URL: http://jira.codehaus.org/browse/MRM-399 > Project: Archiva > Issue Type: Bug > Components: remote proxy, WebDAV interface >Affects Versions: 1.0-alpha-1 >Reporter: Brett Porter >Priority: Critical > Fix For: 1.0-alpha-2 > > > I have just the default repository configuration, with no existing content. I > have enabled guest access through the global observer role. > RequestURI=/repository/internal/org/apache/maven/maven-core/2.0.6/maven-core-2.0.6.jar > Caused by: > java.lang.NullPointerException > at > org.apache.maven.archiva.proxy.DefaultRepositoryProxyConnectors.fetchFromProxies(DefaultRepositoryProxyConnectors.java:143) > at > org.apache.maven.archiva.web.repository.ProxiedDavServer.fetchContentFromProxies(ProxiedDavServer.java:163) > at > org.apache.maven.archiva.web.repository.ProxiedDavServer.process(ProxiedDavServer.java:134) > at > org.codehaus.plexus.webdav.servlet.multiplexed.MultiplexedWebDavServlet.service(MultiplexedWebDavServlet.java:119) -- 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-3063) Document precedence for filter property locations
Document precedence for filter property locations - Key: MNG-3063 URL: http://jira.codehaus.org/browse/MNG-3063 Project: Maven 2 Issue Type: Improvement Components: Documentation: Guides Affects Versions: Documentation Reporter: Florian Kirchmeir Priority: Trivial According to the "Getting Started Guide", section "How do I filter resource files?", properties may be defined at different locations: [quote] "The property can be one of the values defined in your pom.xml, a value defined in the user's settings.xml, a property defined in an external properties file, or a system property." [/quote] However, the guide doesn't state explicitely the order in which these locations are evaluated. So, if I have different values for the same property specified in my pom.xml and an external properties file, which value will I get in my filtered resource? According to my own findings, the different locations seem to be already listed in order of precedence above (with lowest precedence for the pom.xml and highest for system properties). Would be nice to see that stated explicitely, to avoid trial and error testing! ;-) 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] Closed: (MRM-352) When logging for the very first time as admin, the "add repository" page fails
[
http://jira.codehaus.org/browse/MRM-352?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Fabrice BELLINGARD closed MRM-352.
--
Resolution: Fixed
MRM-388 fixed this issue. I've tested it today, and I don't get the error
anymore.
> When logging for the very first time as admin, the "add repository" page fails
> --
>
> Key: MRM-352
> URL: http://jira.codehaus.org/browse/MRM-352
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-alpha-1
>Reporter: Fabrice BELLINGARD
>Priority: Critical
> Fix For: 1.0-alpha-2
>
>
> _[ To reproduce the bug, clean your file system like it would be the first
> time you run Archiva (basically, delete the database and the archiva files in
> .m2) ]_
> When you start Archiva for the first time, you have to create an admin user
> first, and then you are redirected to the repository configuration page,
> which fails with the following stack trace:
> {code}
> 2007-05-23 11:20:32,137 [http-8080-Processor25] INFO
> com.opensymphony.xwork.interceptor.Interceptor:configurationInterceptor - No
> repositories exist - forwarding to repository configuration page
> 2007-05-23 11:21:22,200 [http-8080-Processor24] ERROR
> com.opensymphony.xwork.util.CompoundRootAccessor - No object in the
> CompoundRoot has a publicly accessible property named 'externalResult' (no
> setter could be found).
> 2007-05-23 11:21:22,263 [http-8080-Processor24] ERROR
> com.opensymphony.xwork.util.OgnlValueStack - Error setting expr
> 'externalResult' with value '[Ljava.lang.String;@160088f'
> No object in the CompoundRoot has a publicly accessible property named
> 'externalResult' (no setter could be found). - [unknown location]
> at
> com.opensymphony.xwork.util.CompoundRootAccessor.setProperty(CompoundRootAccessor.java:69)
> at ognl.OgnlRuntime.setProperty(OgnlRuntime.java:1629)
> at ognl.ASTProperty.setValueBody(ASTProperty.java:105)
> at ognl.SimpleNode.evaluateSetValueBody(SimpleNode.java:177)
> at ognl.SimpleNode.setValue(SimpleNode.java:246)
> at ognl.Ognl.setValue(Ognl.java:476)
> at com.opensymphony.xwork.util.OgnlUtil.setValue(OgnlUtil.java:186)
> at
> com.opensymphony.xwork.util.OgnlValueStack.setValue(OgnlValueStack.java:154)
> at
> com.opensymphony.xwork.util.OgnlValueStack.setValue(OgnlValueStack.java:137)
> at
> com.opensymphony.xwork.interceptor.ParametersInterceptor.setParameters(ParametersInterceptor.java:139)
> at
> com.opensymphony.xwork.interceptor.ParametersInterceptor.before(ParametersInterceptor.java:114)
> at
> com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:30)
> at
> com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:188)
> at
> com.opensymphony.xwork.DefaultActionProxy.execute(DefaultActionProxy.java:113)
> at
> com.opensymphony.webwork.dispatcher.DispatcherUtils.serviceAction(DispatcherUtils.java:225)
> at
> com.opensymphony.webwork.dispatcher.FilterDispatcher.doFilter(FilterDispatcher.java:202)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
> at
> com.opensymphony.module.sitemesh.filter.PageFilter.parsePage(PageFilter.java:118)
> at
> com.opensymphony.module.sitemesh.filter.PageFilter.doFilter(PageFilter.java:52)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
> at
> com.opensymphony.webwork.dispatcher.ActionContextCleanUp.doFilter(ActionContextCleanUp.java:88)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151)
> at
> org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870)
> at
> org.apache.coyote.http11.Http11BaseProtoco
[jira] Closed: (MIDEA-97) -DdownloadSources - sources are not in sync with binaries on SNAPSHOT versions
[ http://jira.codehaus.org/browse/MIDEA-97?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MIDEA-97. Assignee: Stephane Nicoll Resolution: Duplicate > -DdownloadSources - sources are not in sync with binaries on SNAPSHOT versions > -- > > Key: MIDEA-97 > URL: http://jira.codehaus.org/browse/MIDEA-97 > Project: Maven 2.x IDEA Plugin > Issue Type: Bug >Affects Versions: 2.0 > Environment: win2000 client, proximity repo >Reporter: Walter Angerer >Assignee: Stephane Nicoll > > using the "-DdownloadSources" switch doesn't sync correctly the sources with > binaries for SNAPSHOT versions. > for reproducing follow these steps: > - person A deploys an artifact with version for example 1.0-SNAPSHOT > - person B calls "mvn idea:idea -DdownloadSources -U" and the sources and the > binaries of the artifact will be correctly downloaded into the local repo > - person A again deploys the changed artifact with the same version for > example 1.0-SNAPSHOT > - person B again calls "mvn idea:idea -DdownloadSources -U" and the binaries > will be downloaded correctly but the sources got out of sync meaning the > sources from the previous call are not updated -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (CONTINUUM-1322) Attempt to store value with more than 256 chars
Attempt to store value with more than 256 chars --- Key: CONTINUUM-1322 URL: http://jira.codehaus.org/browse/CONTINUUM-1322 Project: Continuum Issue Type: Bug Affects Versions: 1.1-alpha-3 Reporter: Pavel Halas Using latest snapshot (continuum-20070621.01.war) I get this exception causing the project build not processed at all -- red X on the project page, no build statistics to be found. 690292 [Thread-2] ERROR org.codehaus.plexus.taskqueue.execution.TaskQueueExecutor:build-project - Error executing task edu.emory.mathcs.backport.java.util.concurrent.ExecutionException: javax.jdo.JDOFatalUserException: Attempt to store value "/soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/core/bundle/ManagerPartDelegateConfig.java (from /soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/parts/ManagerPartDelegateConfig.java:12912)" in column ""NAME"" that has maximum length of 256. Please correct your data! at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.getResult(FutureTask.java:299) at edu.emory.mathcs.backport.java.util.concurrent.FutureTask.get(FutureTask.java:128) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.waitForTask(ThreadedTaskQueueExecutor.java:165) at org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable.run(ThreadedTaskQueueExecutor.java:127) Caused by: javax.jdo.JDOFatalUserException: Attempt to store value "/soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/core/bundle/ManagerPartDelegateConfig.java (from /soseco/dev/tahoe/applications/rcp/rcpmanager/src/main/java/biz/wss/rcp/rcpmanager/parts/ManagerPartDelegateConfig.java:12912)" in column ""NAME"" that has maximum length of 256. Please correct your data! at org.jpox.store.rdbms.mapping.CharRDBMSMapping.setString(CharRDBMSMapping.java:214) at org.jpox.store.mapping.SingleFieldMapping.setString(SingleFieldMapping.java:203) at org.jpox.store.rdbms.fieldmanager.ParameterSetter.storeStringField(ParameterSetter.java:122) at org.jpox.state.StateManagerImpl.providedStringField(StateManagerImpl.java:2757) at org.apache.maven.continuum.model.scm.ChangeFile.jdoProvideField(ChangeFile.java) at org.apache.maven.continuum.model.scm.ChangeFile.jdoProvideFields(ChangeFile.java) at org.jpox.state.StateManagerImpl.provideFields(StateManagerImpl.java:3115) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:252) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) at org.jpox.store.StoreManager.insert(StoreManager.java:920) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1198) at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1243) at org.jpox.store.rdbms.scostore.FKListStore.validateElementForWriting(FKListStore.java:1231) at org.jpox.store.rdbms.scostore.FKListStore.internalAdd(FKListStore.java:772) at org.jpox.store.rdbms.scostore.AbstractListStore.addAll(AbstractListStore.java:386) at org.jpox.store.mapping.CollectionMapping.postInsert(CollectionMapping.java:209) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:464) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) at org.jpox.store.StoreManager.insert(StoreManager.java:920) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667) at org.jpox.state.StateManagerImpl.makePersistent(StateManagerImpl.java:3646) at org.jpox.AbstractPersistenceManager.internalMakePersistent(AbstractPersistenceManager.java:1198) at org.jpox.AbstractPersistenceManager.makePersistentInternal(AbstractPersistenceManager.java:1243) at org.jpox.store.rdbms.scostore.FKListStore.validateElementForWriting(FKListStore.java:1231) at org.jpox.store.rdbms.scostore.FKListStore.internalAdd(FKListStore.java:772) at org.jpox.store.rdbms.scostore.AbstractListStore.addAll(AbstractListStore.java:386) at org.jpox.store.mapping.CollectionMapping.postInsert(CollectionMapping.java:209) at org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:464) at org.jpox.store.rdbms.table.ClassTable.insert(ClassTable.java:2519) at org.jpox.store.StoreManager.insert(StoreManager.java:920) at org.jpox.state.StateManagerImpl.internalMakePersistent(StateManagerImpl.java:3667
[jira] Updated: (MNG-1323) Plugin extensions (dependencies) not resolved in reactor build
[ http://jira.codehaus.org/browse/MNG-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Piotr Tabor updated MNG-1323: - Attachment: MNG-1323-core-integration-tests.diff Attached integration test to the issue - ready to commit. The test fails if run from parent directory and works if run from children directories. > Plugin extensions (dependencies) not resolved in reactor build > -- > > Key: MNG-1323 > URL: http://jira.codehaus.org/browse/MNG-1323 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Affects Versions: 2.0 >Reporter: Kenney Westerhof > Fix For: 2.0.x > > Attachments: MNG-1323-core-integration-tests.diff > > > I've added a dependency on an Ant Task in > project/build/plugins/plugin[artifactId='maven-antrun-plugin']/dependencies/ > and run that anttask using the antrun plugin. > When run from the project dir itself it runs fine. > When running from the root of the project tree (reactor build, project one > level below root), > antrun bails out because the taskdef can't be found (not on classpath). > It looks like the dependency isn't resolved, or not added to the plugins' > classrealm. -- 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: (MEV-530) Broken checksum for org/apache/maven/maven/2.0.6/maven-2.0.6.pom
Broken checksum for org/apache/maven/maven/2.0.6/maven-2.0.6.pom Key: MEV-530 URL: http://jira.codehaus.org/browse/MEV-530 Project: Maven Evangelism Issue Type: Bug Reporter: Max Bowsher org/apache/maven/maven/2.0.6/maven-2.0.6.pom has bad md5 and sha1 -- 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: (MRM-416) Find artifact does not work.
[ http://jira.codehaus.org/browse/MRM-416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100208 ] Maria Odea Ching commented on MRM-416: -- The database must be updated (to run index-artifact consumer) so that the artifact checksums are added in the index. Currently, there are 2 ways to do this: 1. Manually execute this (Database --> click Update Database Now) 2. Wait for it to be executed through the schedule Is it possible to do this if we hook it up to automatically execute right after a repository scan is performed (even for just those manually triggered repository scans) ? Thoughts anyone? > Find artifact does not work. > > > Key: MRM-416 > URL: http://jira.codehaus.org/browse/MRM-416 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0-alpha-2 >Reporter: Henry S. Isidro > > Finding an artifact always shows the 'No results found' message even though > the artifact that is being looked for is in the repository. -- 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-1258) Add option to redownload poms
[ http://jira.codehaus.org/browse/MNG-1258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_100203 ] Damien Lecan commented on MNG-1258: --- -1 pom, jars should never be redownloaded A released version is build and deployed once and for all > Add option to redownload poms > - > > Key: MNG-1258 > URL: http://jira.codehaus.org/browse/MNG-1258 > Project: Maven 2 > Issue Type: Improvement > Components: Plugins and Lifecycle >Affects Versions: 2.0 (RC) >Reporter: Carlos Sanchez > Fix For: 2.1.x > > > Add an option to the command line to redownload the poms, so it's easy to get > the fixes in the remote repo. Something like -f , --refresh or whatever -- 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
