[jira] Updated: (MRM-157) add a report on artifacts that have external repositories/plugin repositories in them
[ http://jira.codehaus.org/browse/MRM-157?page=all ] Brett Porter updated MRM-157: - Fix Version/s: 1.0-beta-1 > add a report on artifacts that have external repositories/plugin repositories > in them > - > > Key: MRM-157 > URL: http://jira.codehaus.org/browse/MRM-157 > Project: Archiva > Issue Type: New Feature > Components: reporting >Reporter: Brett Porter > Fix For: 1.0-beta-1 > > > this may have certain constraints - eg, we report on release repo if it has > any snapshot repos, etc. -- 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-153) when used as a maven1 proxy, Archiva should handle relocation from maven2 poms
[ http://jira.codehaus.org/browse/MRM-153?page=comments#action_73629 ] Brett Porter commented on MRM-153: -- Hi Nicolas. The test looks pretty, good, but some comments: - this will require downloading from ibiblio, which is not very good. I think it would be better to have the 'managed' repository created in, say, target/test/managed-repository instead of src/test/maven-2.x-repository, and use maven-2.x repository as the proxy repo (using file:// ... as the URL) - in the patch, you should omit binary files. Besides, its not necessary to have a full size servlet jar for this test - the code and test should be in the proxy module instead of core. The code should be part of the proxy request handler instead of being done in the proxy manager. This can guarantee it gets done after the POM is downloaded, whereas this technique I think will fail if the POM was not already present. Can you review the patch? Thanks! If you could submit a single diff file for the proxy module that would be most helpful. > when used as a maven1 proxy, Archiva should handle relocation from maven2 poms > -- > > Key: MRM-153 > URL: http://jira.codehaus.org/browse/MRM-153 > Project: Archiva > Issue Type: Improvement > Environment: Archiva as a repository proxy for maven1 >Reporter: nicolas de loof >Priority: Minor > Attachments: DefaultProxyManager.java.patch, > DefaultProxyManager.java.patch, MRM-153-test.patch, patch.patch > > > When a maven1 client asks for /servletapi/jars/servletapi-2.4.jar, Archiva > converts path to the maven2 location of this artifact. As maven1 has no > relocation support, the jar is required in the repo. > Archiva can be more that a proxy : download the artifact POM, read relocation > infos, and return the relocated jar. > attached Patch add a new "applyRelocation" to DefaultProxyManager. > I've tried this code with the servletapi example, but it may be bad designed > as I just discovered maven / archiva APIs. -- 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-159) should not respond with a 404 if proxying a file results in a remote error
[ http://jira.codehaus.org/browse/MRM-159?page=all ] Brett Porter updated MRM-159: - Fix Version/s: 1.0-beta-1 > should not respond with a 404 if proxying a file results in a remote error > -- > > Key: MRM-159 > URL: http://jira.codehaus.org/browse/MRM-159 > Project: Archiva > Issue Type: Bug > Components: remote proxy >Reporter: Brett Porter > Fix For: 1.0-beta-1 > > > if any repository returns success, return success > otherwise, if any repository returns in error, return a generic error (500), > saying to check the logs. -- 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: (MNGECLIPSE-122) wrong download url for javadoc ?
[ http://jira.codehaus.org/browse/MNGECLIPSE-122?page=all ] Eugene Kuleshov closed MNGECLIPSE-122. -- Resolution: Fixed Fix Version/s: 0.0.10 This huld be fixed in trunk. Please retest when 0.0.10 is released and reopef needed. > wrong download url for javadoc ? > > > Key: MNGECLIPSE-122 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-122 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Dependency Resolver >Affects Versions: 0.0.7 > Environment: Eclipse 3.1.2 / Windows 2003 / Java 1.4.2 >Reporter: Dirk Datzert >Priority: Minor > Fix For: 0.0.10 > > Attachments: pom.xml > > > after upgrading to latested release 0.0.7 I tried the download if javadoc > artefacts. I saw in the log of the maven-proxy that m2 tried to download > javadoc named name-version-java-doc.javadoc instead of > name-version-javadoc.jar > As I looked into Maven2Plugin.java I would expect the downloads of java-doc > to be named name-version-javadoc.jar. > Some examples of the maven-proxy.log: > 2006-05-05 21:46:44,308 [INFO ] proxy.config.HttpRepoConfiguration - > Repo[www-ibiblio-org]: Checking last modified time for > http://www.ibiblio.org/maven2/com/sap/ip/bi/sdk/aii_proxy_rt/3.50.16.0/aii_proxy_rt-3.50.16.0-javadoc.java-doc > 2006-05-05 21:46:45,228 [INFO ] components.impl.DefaultSnapshotCache - > Adding > /com/sap/ip/bi/sdk/aii_proxy_rt/3.50.16.0/aii_proxy_rt-3.50.16.0-javadoc.java-doc > to snapshot cache > 2006-05-05 21:46:45,228 [DEBUG] components.impl.DefaultSnapshotCache - > Unable to find > /com/sap/ip/bi/sdk/aii_proxy_rt/3.50.16.0/aii_proxy_rt-3.50.16.0-javadoc.java-doc > in snapshot cache > 2006-05-05 21:46:45,228 [INFO ] proxy.config.HttpRepoConfiguration - > Repo[cargo-codehaus-org]: Checking last modified time for > http://cargo.codehaus.org/dist2/com/sap/ip/bi/sdk/aii_proxy_rt/3.50.16.0/aii_proxy_rt-3.50.16.0-javadoc.java-doc > 2006-05-05 21:46:45,495 [INFO ] components.impl.DefaultSnapshotCache - > Adding > /com/sap/ip/bi/sdk/aii_proxy_rt/3.50.16.0/aii_proxy_rt-3.50.16.0-javadoc.java-doc > to snapshot cache -- 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: (MNGECLIPSE-173) doesn't execute the right profile
[ http://jira.codehaus.org/browse/MNGECLIPSE-173?page=all ] Eugene Kuleshov closed MNGECLIPSE-173. -- Resolution: Fixed Fix Version/s: 0.0.10 Launch configuration dialog now allows to specify proviles. Still have to get embedder to use settings.xml as per MNGECLIPSE-29 > doesn't execute the right profile > - > > Key: MNGECLIPSE-173 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-173 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Maven Launcher >Affects Versions: 0.0.9 > Environment: Windows Xp, Eclipse 3.2 >Reporter: femke ongenae >Priority: Blocker > Fix For: 0.0.10 > > Attachments: pom.xml > > > When i do run -> maven2 build... > i get a screen. > In my pom i have to profiles : 1) a dev profile, that is active by default > 2) a test profile (in > command promt activated by -Ptest) > but i can't get this maven integration for eclipse to run the test profile > i have tried to fill in anything at the parameters > name value > P test > -P test > ptest > -p test > active-profiles test > if you could resolve this i would be very happy, cause it's very annoying > that i can > only execute the default profile from eclipse. > i have included the pom.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-130) Create a model for a release
[ http://jira.codehaus.org/browse/MRELEASE-130?page=comments#action_73620 ] Brett Porter commented on MRELEASE-130: --- I applied this and tried it on it2002 and noticed a couple of issues: - non-interactive mode doesn't seem to be honoured (probably a result of settings changes) - something goes wrong at the svn commit point. I'll see if I can find some time to take a closer look. > Create a model for a release > > > Key: MRELEASE-130 > URL: http://jira.codehaus.org/browse/MRELEASE-130 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Reporter: Jason van Zyl > Assigned To: Jeremy Whitlock > Attachments: MRELEASE-130.refactor.patch > > > Use modello to create a model for a release. Something that could be sent to > a release mechanism for an official release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MRELEASE-130) Create a model for a release
[ http://jira.codehaus.org/browse/MRELEASE-130?page=comments#action_73619 ] Brett Porter commented on MRELEASE-130: --- the ReleaseConfiguration files got moved so the patch didn't apply. Did this first: grep 'Index.*ReleaseDescriptor' ~/Desktop/MRELEASE-130.refactor.patch | sed 's/Index: //' | while read t1; do svn mv `echo $t1 | sed 's/ReleaseDescriptor/ReleaseConfiguration/g'` $t1; done Now trying the patch... > Create a model for a release > > > Key: MRELEASE-130 > URL: http://jira.codehaus.org/browse/MRELEASE-130 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Reporter: Jason van Zyl > Assigned To: Jeremy Whitlock > Attachments: MRELEASE-130.refactor.patch > > > Use modello to create a model for a release. Something that could be sent to > a release mechanism for an official release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGECLIPSE-185) bug with dependencyManagement section in a parent pom
[ http://jira.codehaus.org/browse/MNGECLIPSE-185?page=all ] Eugene Kuleshov closed MNGECLIPSE-185. -- Resolution: Incomplete Please feel free to reopen and provide requested info. Thanks. > bug with dependencyManagement section in a parent pom > - > > Key: MNGECLIPSE-185 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-185 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug >Affects Versions: 0.0.9 > Environment: maven 2.0.4 on Windows with eclipse 3.1 >Reporter: Nicolas Cazottes > Assigned To: Eugene Kuleshov > Attachments: projects.zip > > > I have also an issue related to dependencyManagement section in parent pom > with m2eclipse plugin on windows. > I have attached the projects that show the problem : when a project (projectD > in my example) is defined with a dependencyManagement section in the parent > pom in order to allow other projects to define its version (projectC in my > example), the build in eclipse with a clean on the project (calling the > install goal) fails when creating the jar. > The trace is the following : > org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling JAR > ... > ... 8 more > Caused by: java.lang.NullPointerException > at > org.apache.maven.artifact.ArtifactUtils.copyArtifact(ArtifactUtils.java:109) > ... -- 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: (MNGECLIPSE-186) repositories section in settings.xml ignored (trunk - 0.0.10 candidate)
[ http://jira.codehaus.org/browse/MNGECLIPSE-186?page=all ] Eugene Kuleshov closed MNGECLIPSE-186. -- Resolution: Duplicate Closing as duplicate of MNGECLIPSE-29. Please open separate issue when MNGECLIPSE-29 is resolved and attach required project and configuration files along with exact instructions how to reproduce issue. Thanks. > repositories section in settings.xml ignored (trunk - 0.0.10 candidate) > --- > > Key: MNGECLIPSE-186 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-186 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Repository Management > Environment: Eclipse 3.1/3.2 for Windows >Reporter: Marek Bieganski > Assigned To: Eugene Kuleshov > > Repositories section in settings.xml ignored. It worked ok in 0.0.9 > When I switched to unreleased version from trunk, i had to configure remote > repositories in every pom. -- 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: (MNGECLIPSE-186) repositories section in settings.xml ignored (trunk - 0.0.10 candidate)
[ http://jira.codehaus.org/browse/MNGECLIPSE-186?page=all ] Eugene Kuleshov updated MNGECLIPSE-186: --- Comment: was deleted > repositories section in settings.xml ignored (trunk - 0.0.10 candidate) > --- > > Key: MNGECLIPSE-186 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-186 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Repository Management > Environment: Eclipse 3.1/3.2 for Windows >Reporter: Marek Bieganski > Assigned To: Eugene Kuleshov > > Repositories section in settings.xml ignored. It worked ok in 0.0.9 > When I switched to unreleased version from trunk, i had to configure remote > repositories in every pom. -- 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: (MNGECLIPSE-168) User settings.xml are ignored
[ http://jira.codehaus.org/browse/MNGECLIPSE-168?page=all ] Eugene Kuleshov closed MNGECLIPSE-168. -- Resolution: Duplicate Duplicate of MNGECLIPSE-29 > User settings.xml are ignored > - > > Key: MNGECLIPSE-168 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-168 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Environment: there is a settings.xml in the %userprofile%/.m2 with > mirrors defined >Reporter: Robert Herschke >Priority: Blocker > > The user settings of maven (in settings.xml) are completely ignored. So I > cannot set any proxies or mirrors. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGECLIPSE-189) JUnit runner does not process resource filters before running
[ http://jira.codehaus.org/browse/MNGECLIPSE-189?page=all ]
Eugene Kuleshov closed MNGECLIPSE-189.
--
Resolution: Incomplete
Closing since additional requiested information is not provided. Feel free to
reopen and provide requested info. Thanks.
> JUnit runner does not process resource filters before running
> -
>
> Key: MNGECLIPSE-189
> URL: http://jira.codehaus.org/browse/MNGECLIPSE-189
> Project: Maven 2.x Extension for Eclipse
> Issue Type: Bug
>Affects Versions: 0.0.9
> Environment: Eclipse 3.1.2 Linux
>Reporter: Jonathan Share
> Assigned To: Eugene Kuleshov
>Priority: Trivial
>
> I have a project that uses a resource filter to set the path to some files
> depending on what platform the developer is on. Using maven on the command
> line this is processed correctly and the Unit tests pass. However, I wish to
> use the JUnit runner within eclipse however as my resources do not get
> filtered before the tests try to load them I get exceptions creating URL
> objects with ${news.image.url} in them.
> Desired behaviour
> ===
> This plugin should provide a launcher for the junit runner that first runs
> the process-resources (apologies if this is wrong, writing from memory here)
> target and ensure the classpath is configured correctly so that the non
> processed resources are not available to the JUnit runner before running the
> JUnit tests.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNGECLIPSE-188) [ERROR] mojo-execute : compiler:compile
[ http://jira.codehaus.org/browse/MNGECLIPSE-188?page=all ] Eugene Kuleshov closed MNGECLIPSE-188. -- Resolution: Incomplete Attached project has incomplete pom (webapp module referenced from root pom.xml does not exist). Please make sure this works from the command line and feel free to reopen this issue explaining exact steps how to reproduce it. > [ERROR] mojo-execute : compiler:compile > > > Key: MNGECLIPSE-188 > URL: http://jira.codehaus.org/browse/MNGECLIPSE-188 > Project: Maven 2.x Extension for Eclipse > Issue Type: Bug > Components: Maven Launcher, POM Editor >Affects Versions: 0.0.5 > Environment: windows xp, eclipse 3.2, jdk 1.5_05 >Reporter: Stefaan Delanghe > Assigned To: Eugene Kuleshov >Priority: Blocker > Attachments: startup.zip > > > After launching mvn clean install on this pom file i get this error message. > I looked at the forums before posting this issue, but it seems the problem is > not > related to that. I could launched another pom file which only varies in > depencies and project defintion and that works just fine. > Could the problem be in my pom file definition or am i missing something > else? > WARN] Unable to get resource from repository central > (http://repo1.maven.org/maven2) > [INFO] > > [INFO] Building backend > [INFO]task-segment: [clean, install] > [INFO] > > [INFO] clean:clean > [INFO] Deleting directory > D:\Development\workspace\Start\startup\backend\target > [INFO] Deleting directory > D:\Development\workspace\Start\startup\backend\target\classes > [INFO] Deleting directory > D:\Development\workspace\Start\startup\backend\target\test-classes > [INFO] resources:resources > [INFO] Using default encoding to copy filtered resources. > [INFO] compiler:compile > Compiling 10 source files to > D:\Development\workspace\Start\startup\backend\target\classes > [ERROR] mojo-execute : compiler:compile > Diagnosis: Compilation failure > FATAL ERROR: Error executing Maven for a project > [ERROR] project-execute : visionit:backend:jar:0.1 ( task-segment: [clean, > install] ) > Diagnosis: Compilation failure > FATAL ERROR: Error executing Maven for a project > org.apache.maven.BuildFailureException: Compilation failure > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:552) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:472) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:451) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:303) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:270) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:139) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:472) > at > org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:413) > at org.maven.ide.eclipse.Maven2Executor.main(Maven2Executor.java:68) > Caused by: org.apache.maven.plugin.CompilationFailureException: Compilation > failure > at > org.apache.maven.plugin.AbstractCompilerMojo.execute(AbstractCompilerMojo.java:505) > at org.apache.maven.plugin.CompilerMojo.execute(CompilerMojo.java:111) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:415) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:531) > ... 8 more > Here is my pom file that gives this error on execution of mvn clean install: > http://maven.apache.org/POM/4.0.0"; > xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"; > xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 > http://maven.apache.org/maven-v4_0_0.xsd";> > 4.0.0 > visionit > backend > jar > 0.1 > backend > > the backend development of the application > > > > org.springframework > spring > 1.2.8 > test > > > org.hibernate > hibernate > 3.1.3 > test > > > > src/main/java > src/main/scripts > src/test/java > target > target/classes >
[jira] Closed: (MNG-2534) When building a multiproject build, maven2 may incorrectly store output files in the repository with a wrong extension. It does not do this if the project is built on its own
[ http://jira.codehaus.org/browse/MNG-2534?page=all ] Brett Porter closed MNG-2534. - Assignee: Brett Porter Resolution: Duplicate > When building a multiproject build, maven2 may incorrectly store output files > in the repository with a wrong extension. It does not do this if the project > is built on its own. > > > Key: MNG-2534 > URL: http://jira.codehaus.org/browse/MNG-2534 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: Windows XP SP2 >Reporter: Olivier Jauze > Assigned To: Brett Porter >Priority: Blocker > Attachments: log.txt, plugins.zip > > > I have created two new maven plugins to customize the way war et ejb projects > are built (i.e. maven 2 default plugins are not compliant with my > requirements). In order to use these custom plugins, I have also creating two > new packaging (named xnet-ejb and xnet-war) but output files I want to store > in the maven repository must have .war and .jar extensions. So I have added > plexus components descriptor in order to change the extension (by default, > the role-hint will be the extension of the file). > In a multiproject build, if I use only one of my plugin, it works well; the > file install in the repository has the correct extension. But if I use both > plugin, only one works and for project manage by the other one plugin, the > file install in the repository will have a wrong extension (i.e. the > role-hint). > This problem seems to be known (see > http://cargo.codehaus.org/Merging+WAR+files) but I haven't found any fix. > Thanks for your help > Attached are my both plugin jar files. -- 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-840) jdbc2_0-stdext.jar download instructions not in README.txt
jdbc2_0-stdext.jar download instructions not in README.txt --- Key: CONTINUUM-840 URL: http://jira.codehaus.org/browse/CONTINUUM-840 Project: Continuum Issue Type: Bug Affects Versions: 1.0.3 Reporter: Baerrach bonDierne Priority: Minor Attachments: patch.txt The README file does not include jdbc2_0-stdext.jar instructions. It is fairly easy to read the pom from ibiblio and work it out. (patch attached) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-795) Prevent password reuse
[ http://jira.codehaus.org/browse/CONTINUUM-795?page=all ] Carlos Sanchez closed CONTINUUM-795. Assignee: Carlos Sanchez (was: Lester Ecarma) Resolution: Fixed Fix Version/s: 1.1 Applied patch from Joakim > Prevent password reuse > -- > > Key: CONTINUUM-795 > URL: http://jira.codehaus.org/browse/CONTINUUM-795 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez > Fix For: 1.1 > > > For instance, password history prevents reuse for 3 password change cycles > this requires a small change of design to store the password history and > check against the history every time there's a change of password -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-793) Password validation
[ http://jira.codehaus.org/browse/CONTINUUM-793?page=all ] Carlos Sanchez closed CONTINUUM-793. Assignee: Carlos Sanchez Resolution: Fixed Fix Version/s: 1.1 Applied patch from Joakim > Password validation > --- > > Key: CONTINUUM-793 > URL: http://jira.codehaus.org/browse/CONTINUUM-793 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez > Fix For: 1.1 > > > Implement a validation process to the creation of passwords, probably a > bridge to commons-validation. > Note that it may not be enough to validate at the view layer as the model can > be called through xmlrpc. It needs to be done at the model layer. > For instance: > Minimum 7 character password length > Password must contain at least 1 alpha and 1 numeric character -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (CONTINUUM-796) Disable account on login failures
[ http://jira.codehaus.org/browse/CONTINUUM-796?page=all ] Carlos Sanchez closed CONTINUUM-796. Assignee: Carlos Sanchez Resolution: Fixed Fix Version/s: 1.1 Applied patch from Joakim > Disable account on login failures > - > > Key: CONTINUUM-796 > URL: http://jira.codehaus.org/browse/CONTINUUM-796 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Assigned To: Carlos Sanchez > Fix For: 1.1 > > > We can hook into acegi authz event system to get unsuccessful logins and add > the counter. > After a definer number (eg. 3) of unsucessful consecutive logins the account > must be 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] Closed: (MPMD-34) Review plugin documentation
[ http://jira.codehaus.org/browse/MPMD-34?page=all ] Dennis Lundberg closed MPMD-34. --- Resolution: Fixed I've read through the docs and it looks good. I just fixed a couple of typos and added formating and license where it was needed. Also fixed the last remaining docck error. > Review plugin documentation > --- > > Key: MPMD-34 > URL: http://jira.codehaus.org/browse/MPMD-34 > Project: Maven 2.x Pmd Plugin > Issue Type: Task >Reporter: Maria Odea Ching > Assigned To: Mike Perham > Original Estimate: 12 hours > Time Spent: 15 hours > Remaining Estimate: 0 minutes > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2536) Resources are merged into derived POMs
Resources are merged into derived POMs -- Key: MNG-2536 URL: http://jira.codehaus.org/browse/MNG-2536 Project: Maven 2 Issue Type: Improvement Components: Documentation: Introductions Reporter: Phil Steitz Attachments: resources_are_merged.patch I have found that build resources get merged into derived POMs. The attached patch adds resources to the list of POM elements that are merged. -- 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: (MONE-4) Review Plugin Documentation
[ http://jira.codehaus.org/browse/MONE-4?page=all ] Dennis Lundberg closed MONE-4. -- Resolution: Fixed > Review Plugin Documentation > --- > > Key: MONE-4 > URL: http://jira.codehaus.org/browse/MONE-4 > Project: Maven 2.x M1 Plugin > Issue Type: Task >Reporter: Dennis Lundberg > Assigned To: Dennis Lundberg > -- 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-796) Disable account on login failures
[ http://jira.codehaus.org/browse/CONTINUUM-796?page=comments#action_73602 ] Joakim Erdfelt commented on CONTINUUM-796: -- Work has been completed on this. Uber-patch has been submitted to Carlos Sanchez. > Disable account on login failures > - > > Key: CONTINUUM-796 > URL: http://jira.codehaus.org/browse/CONTINUUM-796 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > > We can hook into acegi authz event system to get unsuccessful logins and add > the counter. > After a definer number (eg. 3) of unsucessful consecutive logins the account > must be 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: (CONTINUUM-795) Prevent password reuse
[ http://jira.codehaus.org/browse/CONTINUUM-795?page=comments#action_73601 ] Joakim Erdfelt commented on CONTINUUM-795: -- Work has been completed on this. Uber-patch has been submitted to Carlos Sanchez. > Prevent password reuse > -- > > Key: CONTINUUM-795 > URL: http://jira.codehaus.org/browse/CONTINUUM-795 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > Assigned To: Lester Ecarma > > For instance, password history prevents reuse for 3 password change cycles > this requires a small change of design to store the password history and > check against the history every time there's a change of password -- 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-793) Password validation
[ http://jira.codehaus.org/browse/CONTINUUM-793?page=comments#action_73600 ] Joakim Erdfelt commented on CONTINUUM-793: -- Work has been completed on this. Uber-patch has been submitted to Carlos Sanchez. > Password validation > --- > > Key: CONTINUUM-793 > URL: http://jira.codehaus.org/browse/CONTINUUM-793 > Project: Continuum > Issue Type: Sub-task >Reporter: Carlos Sanchez > > Implement a validation process to the creation of passwords, probably a > bridge to commons-validation. > Note that it may not be enough to validate at the view layer as the model can > be called through xmlrpc. It needs to be done at the model layer. > For instance: > Minimum 7 character password length > Password must contain at least 1 alpha and 1 numeric character -- 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-839) Editing a user changes the password to what's submitted, which by default is "" (empty string).
Editing a user changes the password to what's submitted, which by default is "" (empty string). --- Key: CONTINUUM-839 URL: http://jira.codehaus.org/browse/CONTINUUM-839 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.1 Reporter: Christian Gruber On the edit user screen, if you don't elect to change the password, you will implicitly change it to what's in the password field by default. The current default state of the page is for the password fields to be empty. solutions: 1. Empty passwords should be ignored, (if we assume people MUST have passwords) and assumed to mean "no change" 2. The current password needs to be pushed out (not very secure) in the form 3. The form needs to be split on the page into two seperate forms for general info editing and for password changes. This will then not submit the password fields when you're, say, just changing the username or e-mail address. -- 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-838) Cross Site Request Forgery protection
Cross Site Request Forgery protection - Key: CONTINUUM-838 URL: http://jira.codehaus.org/browse/CONTINUUM-838 Project: Continuum Issue Type: Improvement Components: Web interface Affects Versions: 1.0.3, 1.0.2, 1.0.1, 1.0, 1.1 Reporter: Christian Gruber Priority: Critical XSRF vulnerabilities are very hard to fix. More details on them at http://en.wikipedia.org/wiki/Cross-site_request_forgery with a key document found at http://isecpartners.com/documents/XSRF_Paper.pdf which outlines a solution. In short, an XSRFProtectionToken is passed in each form in a hidden variable, with the XSRFProtectionToken consisting of (pseudocode): hash(sessionid + actionName + sitewide_secret); The hash can be MD5 or SHA-1 or whatever. The important thing is that even if a user is logged on with a valid sessionId, the attacker cannot know in advance what the token will be without getting it out of an insecure browser (in which case, you have other problems). Even if the attacker gets access to a token for one action that's less security-risky (like invoking a build), they cannot then replay that token against something more risky (such as creating a new admin user). -- 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-830) Use redirect after post instead of forward when page refresh is common but could cause re-triggering
[ http://jira.codehaus.org/browse/CONTINUUM-830?page=comments#action_73599 ] Jesse McConnell commented on CONTINUUM-830: --- I am not sure how this would be done in webwork in some cases. these kinda things are configured in the xwork.xml file with foo you use the chain so that the form variables are populated into the targeted actionso you can't redirect to a particular project's summary page for example where you need projectGroupId populated. gotta be some way to do it, I just can't think of it off the top of my head > Use redirect after post instead of forward when page refresh is common but > could cause re-triggering > > > Key: CONTINUUM-830 > URL: http://jira.codehaus.org/browse/CONTINUUM-830 > Project: Continuum > Issue Type: Improvement > Components: Web interface >Affects Versions: 1.0.3 >Reporter: John Casey > Fix For: 1.1 > > > When I force a build, Continuum simply forwards me to the summary page, > instead of redirecting. This means that if I use the browser's refresh > function, I'll force another build, since the URL is the one used to trigger > the build. If you're doing many things at once, it means you have to look at > the URL before you punch reload, or you may wind up rebuilding again. > It'd be nice to simply redirect the user to the summary page, so reloads of > the page wouldn't trigger fresh builds. -- 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: (MCHANGELOG-47) Cannot find .cvspass file. Documentation not up-to-date.
[ http://jira.codehaus.org/browse/MCHANGELOG-47?page=comments#action_73598 ] Dennis Lundberg commented on MCHANGELOG-47: --- This plugin has not yet been released. That's why it is not available from ibiblio. If you want to try it out please read this document: http://maven.apache.org/guides/development/guide-testing-development-plugins.html "The plugin 'org.apache.maven.plugins:maven-changelog-plugin' does not exist or no valid version could be found" This simply means that the plugin is not installed on you machine and is not available from the repos that you have defined. This is explained in the document mentioned above. The plugin uses maven-scm to handle the communication with your SCM. IIRC it doesn't support passing the password as a parameter. > Cannot find .cvspass file. Documentation not up-to-date. > - > > Key: MCHANGELOG-47 > URL: http://jira.codehaus.org/browse/MCHANGELOG-47 > Project: Maven 2.x Changelog Plugin > Issue Type: Bug >Affects Versions: 2.0-beta-1 > Environment: Maven2 on Windows in Eclipse with CVS (anonymous pserver) > Maven2 on GenToo in CruiseControl with CVS (anonymous pserver) >Reporter: Paul R. Saxman > > I've run into a few issues while using this plugin, which are as follows: > - When I try to run the Maven 2 changelog plugin in Eclipse or using > CruiseControl, I get an error that the file .cvspass cannot be found. > - I've found a reference to the .cvspass file on the Maven 1 plugin > documentation, but not in the Maven 2 documentation. > - The Maven 2 documentation specifies to use the groupId > org.apache.maven.plugins for the plugin, which doesn't exist on ibiblio. The > plugin actually exists at org.codehaus.mojo; HOWEVER, it is not documented as > being part of Mojo at http://mojo.codehaus.org. > - When I follow the Maven 1 instructions to generate the .cvspass file, I get > the error "The plugin 'org.apache.maven.plugins:maven-changelog-plugin' does > not exist or no valid version could be found". > - Passing in a password (which doesn't really exist since I'm using an > anonymous pserver) using the Maven 2 plugin "password" parameter has no > effect, which is consistent with the documentation. Is there any way to not > bother with a password or to specify an empty password? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-33) jars with differents versions can be in WEB-INF/lib with war as dependencies
[ http://jira.codehaus.org/browse/MWAR-33?page=comments#action_73595 ] Carlos Sanchez commented on MWAR-33: Workaround: Using latest version in svn you can do WEB-INF/lib/** to avoid the jars from the war > jars with differents versions can be in WEB-INF/lib with war as dependencies > > > Key: MWAR-33 > URL: http://jira.codehaus.org/browse/MWAR-33 > Project: Maven 2.x War Plugin > Issue Type: Bug > Environment: all >Reporter: Olivier Lamy > Fix For: 2.1 > > Original Estimate: 15 minutes > Time Spent: 30 minutes > Remaining Estimate: 0 minutes > > My pom has the following dependencies : > - log4j:log4j:1.2.13 > - a war with log4j:log4j:1.2.11 included > Result the two jars are in WEB-INF/lib. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-72) Need ability to protect (or exclude) resource from being destroyed during war overlay.
[ http://jira.codehaus.org/browse/MWAR-72?page=comments#action_73596 ]
Carlos Sanchez commented on MWAR-72:
Seems that for now we can use dependentWarExcludes
> Need ability to protect (or exclude) resource from being destroyed during war
> overlay.
> --
>
> Key: MWAR-72
> URL: http://jira.codehaus.org/browse/MWAR-72
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Joakim Erdfelt
>
> If you have a template war TEMPLATE.war that is used to overlay the current
> project war CURRENT.war, and there are values in the CURRENT.war that should
> never be overlaid, a mechanism needs to exist to protect those resources.
> Example:
> template.war uses xwork - /WEB-INF/classes/xwork.xml
> current.war also uses xwork.
> when you overlay template.war onto current.war you want to prevent
> /WEB-INF/classes/xwork.xml from being overwritten.
> desired.
> {noformat}
>
> org.apache.maven.plugin
> maven-war-plugin
>
>
>
> /WEB-INF
>
> classes/xwork.xml
>
>
>
>
>
> {noformat}
> You can use the maven-shared/file-management FileSet implementation to
> perform this (see maven-clean-plugin) for example usage.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-73) war overlay mechanism does not work for classes
[ http://jira.codehaus.org/browse/MWAR-73?page=comments#action_73592 ] Carlos Sanchez commented on MWAR-73: You can try archiveClasses option, that may help > war overlay mechanism does not work for classes > --- > > Key: MWAR-73 > URL: http://jira.codehaus.org/browse/MWAR-73 > Project: Maven 2.x War Plugin > Issue Type: Improvement >Affects Versions: 2.0, 2.1, 2.0.1, 2.0.2 > Environment: all OS, all JDK, currently using jdk1.4.2_10 and > jdk1.5.0_06 under linux fedora core 5/x86_64 and sunOS5.10/Sparc64 >Reporter: mark struberg > Attachments: maven-war-plugin-patch.tar.gz > > > PROBLEM DESCRIPTION: > When building a WAR (e.g. war2.war) which depends on another WAR (e.g. > war1.war), the web-resources from the dependant war are beeing used as base > for overlaying. > This mechanism doesn't currently work for the classes within the dependant > war, altough it is specified by the plugin documentation > See the SampleActionDependency.class in > http://maven.apache.org/plugins/maven-war-plugin/examples/war-overlay.html > APPLIED PATCH: > I have written two simple war examples war1 and war2 and extended the > maven-war-plugin by an own WarClasspathMojo which is bound to the phase > generate-resources to fix this issue. > Since i found no way to add non-artifact parts to the classpath, i simply > unpack all dependant war files (reusing the functions already there in > AbstractWarMojo) and add a resource-path to the > $explodedWarDir/WEB-INF/classes for each of them. The > The implementation fits all my needs, but if you provide me with a hint how > it may be improved, then let me know. > KNOWN ISSUES: > This mechanism currently doesn't work if you have specified to generate an > archive for the dependant war's classes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-72) Need ability to protect (or exclude) resource from being destroyed during war overlay.
[ http://jira.codehaus.org/browse/MWAR-72?page=comments#action_73591 ]
Carlos Sanchez commented on MWAR-72:
i think current war must always win, that's the easy solution and how
classpaths also work. The problem is when you overlay more than one war.
> Need ability to protect (or exclude) resource from being destroyed during war
> overlay.
> --
>
> Key: MWAR-72
> URL: http://jira.codehaus.org/browse/MWAR-72
> Project: Maven 2.x War Plugin
> Issue Type: Bug
>Affects Versions: 2.0.1
>Reporter: Joakim Erdfelt
>
> If you have a template war TEMPLATE.war that is used to overlay the current
> project war CURRENT.war, and there are values in the CURRENT.war that should
> never be overlaid, a mechanism needs to exist to protect those resources.
> Example:
> template.war uses xwork - /WEB-INF/classes/xwork.xml
> current.war also uses xwork.
> when you overlay template.war onto current.war you want to prevent
> /WEB-INF/classes/xwork.xml from being overwritten.
> desired.
> {noformat}
>
> org.apache.maven.plugin
> maven-war-plugin
>
>
>
> /WEB-INF
>
> classes/xwork.xml
>
>
>
>
>
> {noformat}
> You can use the maven-shared/file-management FileSet implementation to
> perform this (see maven-clean-plugin) for example usage.
--
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-2535) Maven and Continuum sites both list the wrong Continuous Integration server URL
Maven and Continuum sites both list the wrong Continuous Integration server URL --- Key: MNG-2535 URL: http://jira.codehaus.org/browse/MNG-2535 Project: Maven 2 Issue Type: Bug Components: Sites & Reporting Affects Versions: 2.0.4 Reporter: Binyan The url for the continuous integration server for Maven and Continuum is dead. The presented url is http://maven.zones.apache.org:8080/continuum. -- 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-1103) Please upload json-lib-0.8
Please upload json-lib-0.8 -- Key: MAVENUPLOAD-1103 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1103 Project: maven-upload-requests Issue Type: Task Reporter: Andres Almiray Please upload version 0.8 This release contains major bugfixes. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MWAR-63) Online available docu (corresponds to 2.0.2) is not in sync with released version 2.0.1 on ibiblio
[ http://jira.codehaus.org/browse/MWAR-63?page=comments#action_73590 ] Elliot Metsger commented on MWAR-63: this issue caught me too! The documentation is great - it was exactly what I needed, but after putting into pom.xml it didn't work, so I came here :) > Online available docu (corresponds to 2.0.2) is not in sync with released > version 2.0.1 on ibiblio > -- > > Key: MWAR-63 > URL: http://jira.codehaus.org/browse/MWAR-63 > Project: Maven 2.x War Plugin > Issue Type: Task >Reporter: Chris Wewerka >Priority: Critical > Fix For: 2.0.2 > > > The documentation of the plugin (especially > http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-webresources.html) > refers to features only available in versions of the plugin which are not > yet deployed (2.0.2 and later) on ibiblio. This is very misleading. Example: > the property 'targetPath' > If you try to access the source code and build the plugin by yourself, you'll > notice that the version was already raised to 2.1-SNAPSHOT. > Will the 2.0.2 never be released? -- 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-837) POM upload screen says file:// URLs are supported but fails if you try one
POM upload screen says file:// URLs are supported but fails if you try one -- Key: CONTINUUM-837 URL: http://jira.codehaus.org/browse/CONTINUUM-837 Project: Continuum Issue Type: Bug Components: Web interface Affects Versions: 1.0.3 Reporter: Aaron Mulder The POM upload screen lists file:// among the supported URL types. However, any file:// URL that you try results in a misleading error message. In fact, the "file" protocol is disabled by default. This screen should explain that "file" must be manually enabled, and the resulting error message should say that the "file" protocol is disabled. Ideally it would point you to the correct place to enable it, and mention that until you've started continuum for the first time, the config file you need to edit won't be there (the JAR has to be unpacked first). -- 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-836) Improve HTTP access to POMs for adding a multi-module project
Improve HTTP access to POMs for adding a multi-module project - Key: CONTINUUM-836 URL: http://jira.codehaus.org/browse/CONTINUUM-836 Project: Continuum Issue Type: New Feature Components: Core system Affects Versions: 1.0.3 Reporter: Aaron Mulder If you're not using SVN, there's no obvious way to load a multi-module POM into continuum. If you point it to a M2 repo, then the child module paths are all resolved relative to the parent's group/artifact/version/ directory, which doesn't work (parent-group/parent-artifact/parent-version/child-module-name/...) If you point it to a file:// URL it doesn't work because that's disabled by default. If you're using CVS, there is no clear way to get the POMs into the web -- perhaps exporting the whole source tree onto an HTTP server, but that's going to be manual. Ideally, you could point Continuum to the parent POM in the M2 repository and it would check out the tree to access the child POMs, which would avoid this whole issue. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1412) dependency sorting in classpath
[ http://jira.codehaus.org/browse/MNG-1412?page=comments#action_73585 ] Pablo Gutierrez commented on MNG-1412: -- Sometimes there is a need to specify the order of the dependencies. Rigth now I'm in a situation where one jar overwrites some classes (not all) of some purchased library as didn't perform what we wanted. So in our jnlp's and scripts for launching our applications we have to specify one strict classpath order on jars. We are moving to Maven 2 but ran into this problem. Where can I download this fix? I need to use svn and build maven? Thanks > dependency sorting in classpath > --- > > Key: MNG-1412 > URL: http://jira.codehaus.org/browse/MNG-1412 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0 >Reporter: Mark Hobson > Assigned To: fabrizio giustina > Fix For: 2.1 > > Attachments: artifact-order_maven-artifact-manager.txt, > artifact-order_maven-artifact.txt, artifact-order_maven-project.txt > > > The .classpath file entries should be ordered by nearest transitiveness (if > that's a word). > For example, I have project A that depends on B that depends on C. The > classpath for A is generated in the order C, B. Ideally the classpath should > be in order of how near they are to the project, i.e. B, C. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MCLOVER-51) Clover plugin should use the original dependency if it's newer than the clovered one
[ http://jira.codehaus.org/browse/MCLOVER-51?page=all ]
Vincent Massol closed MCLOVER-51.
-
Resolution: Fixed
Should work now. I have written some unit tests for it but no functional tests
(not easy to do). Mike, do you think you could try it and tell me if it works
on your project? Thanks
> Clover plugin should use the original dependency if it's newer than the
> clovered one
>
>
> Key: MCLOVER-51
> URL: http://jira.codehaus.org/browse/MCLOVER-51
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Mike Perham
> Assigned To: Vincent Massol
>Priority: Critical
> Fix For: 2.3
>
>
> This is an interesting one. Take module A and B where B depends on A.
> I run clover to get the coverage numbers for A. This installs A-clover.jar
> in the repo.
> I modify some interfaces in A and install A.jar. The tests pass.
> I modify B to work with the new A interfaces and install B. The compile and
> tests pass.
> I run clover to get coverage numbers for B.
> B fails to build because it says the code is not using A's old interfaces.
> This is because Clover tries to use A-clover.jar instead of A.jar in the
> classpath and the A-clover.jar was built before the code in A was refactored.
> I would suggest that you prefer the newer of { a.jar, a-clover.jar} in order
> to guarantee that these types of build failures will not occur. Marked as
> Critical because the plugin is erroneously failing the build.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MCLOVER-51) Clover plugin should use the original dependency if it's newer than the clovered one
[ http://jira.codehaus.org/browse/MCLOVER-51?page=all ]
Vincent Massol updated MCLOVER-51:
--
Summary: Clover plugin should use the original dependency if it's newer
than the clovered one (was: Clover causes build failure)
> Clover plugin should use the original dependency if it's newer than the
> clovered one
>
>
> Key: MCLOVER-51
> URL: http://jira.codehaus.org/browse/MCLOVER-51
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Mike Perham
> Assigned To: Vincent Massol
>Priority: Critical
> Fix For: 2.3
>
>
> This is an interesting one. Take module A and B where B depends on A.
> I run clover to get the coverage numbers for A. This installs A-clover.jar
> in the repo.
> I modify some interfaces in A and install A.jar. The tests pass.
> I modify B to work with the new A interfaces and install B. The compile and
> tests pass.
> I run clover to get coverage numbers for B.
> B fails to build because it says the code is not using A's old interfaces.
> This is because Clover tries to use A-clover.jar instead of A.jar in the
> classpath and the A-clover.jar was built before the code in A was refactored.
> I would suggest that you prefer the newer of { a.jar, a-clover.jar} in order
> to guarantee that these types of build failures will not occur. Marked as
> Critical because the plugin is erroneously failing the build.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2534) When building a multiproject build, maven2 may incorrectly store output files in the repository with a wrong extension. It does not do this if the project is built on its ow
[ http://jira.codehaus.org/browse/MNG-2534?page=all ] Olivier Jauze updated MNG-2534: --- Attachment: plugins.zip Custom maven plugins jars > When building a multiproject build, maven2 may incorrectly store output files > in the repository with a wrong extension. It does not do this if the project > is built on its own. > > > Key: MNG-2534 > URL: http://jira.codehaus.org/browse/MNG-2534 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: Windows XP SP2 >Reporter: Olivier Jauze >Priority: Blocker > Attachments: log.txt, plugins.zip > > > I have created two new maven plugins to customize the way war et ejb projects > are built (i.e. maven 2 default plugins are not compliant with my > requirements). In order to use these custom plugins, I have also creating two > new packaging (named xnet-ejb and xnet-war) but output files I want to store > in the maven repository must have .war and .jar extensions. So I have added > plexus components descriptor in order to change the extension (by default, > the role-hint will be the extension of the file). > In a multiproject build, if I use only one of my plugin, it works well; the > file install in the repository has the correct extension. But if I use both > plugin, only one works and for project manage by the other one plugin, the > file install in the repository will have a wrong extension (i.e. the > role-hint). > This problem seems to be known (see > http://cargo.codehaus.org/Merging+WAR+files) but I haven't found any fix. > Thanks for your help > Attached are my both plugin jar files. -- 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-2534) When building a multiproject build, maven2 may incorrectly store output files in the repository with a wrong extension. It does not do this if the project is built on its ow
[ http://jira.codehaus.org/browse/MNG-2534?page=all ] Olivier Jauze updated MNG-2534: --- Attachment: log.txt Log when I get the error > When building a multiproject build, maven2 may incorrectly store output files > in the repository with a wrong extension. It does not do this if the project > is built on its own. > > > Key: MNG-2534 > URL: http://jira.codehaus.org/browse/MNG-2534 > Project: Maven 2 > Issue Type: Bug >Affects Versions: 2.0.4 > Environment: Windows XP SP2 >Reporter: Olivier Jauze >Priority: Blocker > Attachments: log.txt, plugins.zip > > > I have created two new maven plugins to customize the way war et ejb projects > are built (i.e. maven 2 default plugins are not compliant with my > requirements). In order to use these custom plugins, I have also creating two > new packaging (named xnet-ejb and xnet-war) but output files I want to store > in the maven repository must have .war and .jar extensions. So I have added > plexus components descriptor in order to change the extension (by default, > the role-hint will be the extension of the file). > In a multiproject build, if I use only one of my plugin, it works well; the > file install in the repository has the correct extension. But if I use both > plugin, only one works and for project manage by the other one plugin, the > file install in the repository will have a wrong extension (i.e. the > role-hint). > This problem seems to be known (see > http://cargo.codehaus.org/Merging+WAR+files) but I haven't found any fix. > Thanks for your help > Attached are my both plugin jar files. -- 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-2534) When building a multiproject build, maven2 may incorrectly store output files in the repository with a wrong extension. It does not do this if the project is built on its ow
When building a multiproject build, maven2 may incorrectly store output files in the repository with a wrong extension. It does not do this if the project is built on its own. Key: MNG-2534 URL: http://jira.codehaus.org/browse/MNG-2534 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.4 Environment: Windows XP SP2 Reporter: Olivier Jauze Priority: Blocker I have created two new maven plugins to customize the way war et ejb projects are built (i.e. maven 2 default plugins are not compliant with my requirements). In order to use these custom plugins, I have also creating two new packaging (named xnet-ejb and xnet-war) but output files I want to store in the maven repository must have .war and .jar extensions. So I have added plexus components descriptor in order to change the extension (by default, the role-hint will be the extension of the file). In a multiproject build, if I use only one of my plugin, it works well; the file install in the repository has the correct extension. But if I use both plugin, only one works and for project manage by the other one plugin, the file install in the repository will have a wrong extension (i.e. the role-hint). This problem seems to be known (see http://cargo.codehaus.org/Merging+WAR+files) but I haven't found any fix. Thanks for your help Attached are my both plugin jar files. -- 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: (MJAR-56) maven-jar-plugin: Update site documentation from sources
[ http://jira.codehaus.org/browse/MJAR-56?page=comments#action_73575 ] Dennis Lundberg commented on MJAR-56: - The site will be published when version 2.1 of this plugin is released. This will probably happen within the next few days. > maven-jar-plugin: Update site documentation from sources > > > Key: MJAR-56 > URL: http://jira.codehaus.org/browse/MJAR-56 > Project: Maven 2.x Jar Plugin > Issue Type: Task >Reporter: Marcel May >Priority: Minor > > Please update the maven plugin documentation at > http://maven.apache.org/plugins/maven-jar-plugin/ for the maven jar plugin, > it's quire out of date (Last Published: Sun Oct 16 04:42:06 EST 2005). > Currently contains dead links, too (eg Project Info/Source Repository/Web > Access). > Possibly applies to many other plugins, too. > Sorry if this is not the correct way to trigger a plugin site update ... ? > Thx alot! -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MJAR-56) maven-jar-plugin: Update site documentation from sources
[ http://jira.codehaus.org/browse/MJAR-56?page=all ] Dennis Lundberg moved MNG-2533 to MJAR-56: -- Component/s: (was: Documentation: General) Complexity: (was: Intermediate) Issue Type: Task (was: Wish) Key: MJAR-56 (was: MNG-2533) Project: Maven 2.x Jar Plugin (was: Maven 2) > maven-jar-plugin: Update site documentation from sources > > > Key: MJAR-56 > URL: http://jira.codehaus.org/browse/MJAR-56 > Project: Maven 2.x Jar Plugin > Issue Type: Task >Reporter: Marcel May >Priority: Minor > > Please update the maven plugin documentation at > http://maven.apache.org/plugins/maven-jar-plugin/ for the maven jar plugin, > it's quire out of date (Last Published: Sun Oct 16 04:42:06 EST 2005). > Currently contains dead links, too (eg Project Info/Source Repository/Web > Access). > Possibly applies to many other plugins, too. > Sorry if this is not the correct way to trigger a plugin site update ... ? > Thx alot! -- 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-2533) maven-jar-plugin: Update site documentation from sources
maven-jar-plugin: Update site documentation from sources Key: MNG-2533 URL: http://jira.codehaus.org/browse/MNG-2533 Project: Maven 2 Issue Type: Wish Components: Documentation: General Reporter: Marcel May Priority: Minor Please update the maven plugin documentation at http://maven.apache.org/plugins/maven-jar-plugin/ for the maven jar plugin, it's quire out of date (Last Published: Sun Oct 16 04:42:06 EST 2005). Currently contains dead links, too (eg Project Info/Source Repository/Web Access). Possibly applies to many other plugins, too. Sorry if this is not the correct way to trigger a plugin site update ... ? Thx alot! -- 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-153) when used as a maven1 proxy, Archiva should handle relocation from maven2 poms
[ http://jira.codehaus.org/browse/MRM-153?page=all ] nicolas de loof updated MRM-153: Attachment: MRM-153-test.patch Testcase that uses servletapi POM to relocate a maven1 request. > when used as a maven1 proxy, Archiva should handle relocation from maven2 poms > -- > > Key: MRM-153 > URL: http://jira.codehaus.org/browse/MRM-153 > Project: Archiva > Issue Type: Improvement > Environment: Archiva as a repository proxy for maven1 >Reporter: nicolas de loof >Priority: Minor > Attachments: DefaultProxyManager.java.patch, > DefaultProxyManager.java.patch, MRM-153-test.patch, patch.patch > > > When a maven1 client asks for /servletapi/jars/servletapi-2.4.jar, Archiva > converts path to the maven2 location of this artifact. As maven1 has no > relocation support, the jar is required in the repo. > Archiva can be more that a proxy : download the artifact POM, read relocation > infos, and return the relocated jar. > attached Patch add a new "applyRelocation" to DefaultProxyManager. > I've tried this code with the servletapi example, but it may be bad designed > as I just discovered maven / archiva APIs. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MCLOVER-51) Clover causes build failure
[ http://jira.codehaus.org/browse/MCLOVER-51?page=comments#action_73558 ]
Vincent Massol commented on MCLOVER-51:
---
Hi Mike,
Yes, an interesting use case... I agree that taking the newer of {a.jar,
a-clover.jar} is probably the best way around this.
Thanks
> Clover causes build failure
> ---
>
> Key: MCLOVER-51
> URL: http://jira.codehaus.org/browse/MCLOVER-51
> Project: Maven 2.x Clover Plugin
> Issue Type: Bug
>Affects Versions: 2.1
>Reporter: Mike Perham
>Priority: Critical
> Fix For: 2.3
>
>
> This is an interesting one. Take module A and B where B depends on A.
> I run clover to get the coverage numbers for A. This installs A-clover.jar
> in the repo.
> I modify some interfaces in A and install A.jar. The tests pass.
> I modify B to work with the new A interfaces and install B. The compile and
> tests pass.
> I run clover to get coverage numbers for B.
> B fails to build because it says the code is not using A's old interfaces.
> This is because Clover tries to use A-clover.jar instead of A.jar in the
> classpath and the A-clover.jar was built before the code in A was refactored.
> I would suggest that you prefer the newer of { a.jar, a-clover.jar} in order
> to guarantee that these types of build failures will not occur. Marked as
> Critical because the plugin is erroneously failing the build.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-2532) System properties cannot be set from Profiles or Settings.xml
System properties cannot be set from Profiles or Settings.xml - Key: MNG-2532 URL: http://jira.codehaus.org/browse/MNG-2532 Project: Maven 2 Issue Type: Bug Affects Versions: 2.0.4 Environment: Windows XP Reporter: Peter Pilgrim Hi All With the maven-antrun-plugin in Maven 2.0.4 is it possibly to define a system property. Instead of me doing this all the time. mvn install -Duser.install.root="C:\Program Files\IBM\WebSphere\AppServer" For more info on the context see my blog http://www.jroller.com/page/peter_pilgrim?entry=how_to_configure_xemacs_http Specifically the system properties is not set up following to either a profiles.xml or settings.xml file by Maven 2 Possibly the system property I need is not also transfered to the Ant task using the maven-antrun-plugin. /* profiles.xml */ user-install-root !user.install.root C:\\Program Files\\IBM\\WebSphere\\AppServer Running mvn help:active-profiles, however, does show that the profile has been read. C:\WORKSP~2\M2SPRI~1\ejb>mvn help:active-profiles [INFO] Scanning for projects... [INFO] Searching repository for plugin with prefix: 'help'. [INFO] - --- [INFO] Building Maven 2.0 Spring EJB Research Project (EJB Module) [INFO]task-segment: [help:active-profiles] (aggregator-style) [INFO] - --- [INFO] [help:active-profiles] [INFO] Active Profiles for Project 'com.ubs.firc.ptsp.research.ejb:M2SpringEJBExample-e jb:ejb:1.0-SNAPSHOT': The following profiles are active: - user-install-root (source: profiles.xml) [INFO] [INFO] BUILD SUCCESSFUL [INFO] [INFO] Total time: 1 second [INFO] Finished at: Tue Aug 29 10:46:31 BST 2006 [INFO] Final Memory: 2M/5M [INFO] C:\WORKSP~2\M2SPRI~1\ejb> Thanks Peter Pilgrim -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MCHANGELOG-48) The link generated in the report contain only one occurrence if a duplicated word is used in the scm repository url.
The link generated in the report contain only one occurrence if a duplicated word is used in the scm repository url. Key: MCHANGELOG-48 URL: http://jira.codehaus.org/browse/MCHANGELOG-48 Project: Maven 2.x Changelog Plugin Issue Type: Bug Affects Versions: 2.0-beta-1 Reporter: Giorgio Urto Priority: Minor We have chose this svn repository layout . where is a svn repository, and are directory having each one it's trunk, tags and branch. If the product have only one component, we have product and component with equals names. es: http://mysubversion/workarea/lgrefapp/lgrefapp/trunk where: - workarea is the root directory of all the products - the first occurrence of lgrefapp is the product - the second occurrence of lgrefapp is the component The link generated by changelog report contains only one occurrence of lgrefapp es: http://mysubversion/workarea/lgrefapp/trunk/. So the links are broken. Thank you Giorgio Here are my configurations: http://mysubversion/viewvc/lgrefapp/lgrefapp/trunk scm:svn:http://mysubversion/workarea/lgrefapp/lgrefapp/trunk scm:svn:http://[EMAIL PROTECTED]/workarea/lgrefapp/lgrefapp/trunk org.apache.maven.plugins maven-changelog-plugin 2.0-SNAPSHOT dual-report range 365 changelog file-activity dev-activity -- 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-1545) some execution output not routed through default routes.
[ http://jira.codehaus.org/browse/MNG-1545?page=comments#action_73549 ] Milos Kleint commented on MNG-1545: --- brett: I've done some additional debugging of the surefire plugin problem and I tracked it down the StreamPumper classes that print messages from the forked process to the System.out of the IDE's process. However the delegating System.out impl in the IDE doesn't recognize these threads (StreamPumper is a running thread) as belonging to build being executed and prints them to console. I believe it's because the threads don't belong to the same ThreadGroup. I tried to confirm the theory but surefire cannot be used with the trunk version of plexus-utils. please note that even when this is fixed, it still doens't fully satisfy the issues mentioned in this report. In the ideal case one should get the output in the logger/llisteners, which is not the case now and it will only be cought by the IDE's safety net. But it cannot be filtered out, have actions attached to it etc.. > some execution output not routed through default routes. > > > Key: MNG-1545 > URL: http://jira.codehaus.org/browse/MNG-1545 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Reporter: Milos Kleint >Priority: Critical > Fix For: 2.0.5 > > > when running embedded maven I create an instance of EventMonitor, > TransferListener and MavenEmbedderLogger. > however there's still some output that is not received through these means, > but rather printoed to standard output (I suppose) > that's wrong because it prohibits custom handling of output. > one example that I found is the surefire plugin's output.. everything > prepended with [surefire] is printed out wrongly.. -- 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-1102) Sync with wicket repository
Sync with wicket repository --- Key: MAVENUPLOAD-1102 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1102 Project: maven-upload-requests Issue Type: Task Reporter: Martijn Dashorst http://wicketframework.org/maven2/ http://wicketframework.org/ http://wicketframework.org/team-list.html Please sync the wicket repository with ibiblio (the script is already in place, just needs running) -- 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-130) Create a model for a release
[ http://jira.codehaus.org/browse/MRELEASE-130?page=all ] Jeremy Whitlock updated MRELEASE-130: - Attachment: MRELEASE-130.refactor.patch Hi All, I have attached MRELEASE-130.refactor.patch. This patch contains the following: Refactoring of ReleaseConfiguration to ReleaseDescriptor Modello to create ReleaseDescriptor Removal of Settings and reactorProjects from ReleaseDescriptor Refactoring for all necessary API changes to reflect the above Refactoring for all tests to pass/fail as before these refactorings were done Please let me know if there is more I can do in regard to this patch. Take care, Jeremy > Create a model for a release > > > Key: MRELEASE-130 > URL: http://jira.codehaus.org/browse/MRELEASE-130 > Project: Maven 2.x Release Plugin > Issue Type: New Feature >Reporter: Jason van Zyl > Assigned To: Jeremy Whitlock > Attachments: MRELEASE-130.refactor.patch > > > Use modello to create a model for a release. Something that could be sent to > a release mechanism for an official release. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
