[jira] Commented: (MAVENUPLOAD-1603) Upload JIDE Common Layer to maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99747 ] Wim Deblauwe commented on MAVENUPLOAD-1603: --- No it does not. I opened the bundle jar with winzip and I see the following files: jide-oss-2.0.4.jar license.txt pom.xml Manifest.mf No source jar seems to be in there... > Upload JIDE Common Layer to maven repository > > > Key: MAVENUPLOAD-1603 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1603 > Project: maven-upload-requests > Issue Type: Task >Reporter: David Qiao > > JIDE Common Layer is Swing component library built on top of Java/Swing. It > is also the foundation of other component products from JIDE. This project > has over 30 Swing components and over 100k lines of code. It greatly enhanced > the default component set provided by Swing and allow developers to focus on > business logic layer instead of making components. > JIDE Common Layer was originally developed by JIDE Software developers as a > foundation in order to build other more advanced components. In April of > 2007, JIDE Software decided to open source this common layer so that more and > more developers can leverage them instead of wasting time building them > again. > For more information, please visit project home page on JIDE Software website > at http://www.jidesoft.com/products/oss.htm or on java.net at > https://jide-oss.dev.java.net. -- 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: (MNG-2886) Dynamically includes dependencies if subfolder is available
[
http://jira.codehaus.org/browse/MNG-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dominick More reopened MNG-2886:
This case is not fixed it is rejected. Since neither ANT (no ANT doesn't
dynamically include projects either I had to write custom beanshell scripts)
nor Maven can provide a system that I can use, I will have to write my own
build system. So much for open source...
> Dynamically includes dependencies if subfolder is available
> -
>
> Key: MNG-2886
> URL: http://jira.codehaus.org/browse/MNG-2886
> Project: Maven 2
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 2.0.5
>Reporter: Dominick More
> Fix For: Reviewed Pending Version Assignment
>
>
> We would like to use Maven to build our multi-project using the
> construct in a top level pom file. The project contains common libraries and
> war files. Since the war files are not dependent on each other, developers
> are used to exclude all other war project directories out of their SCM load
> configurations to reduce update time. Currently we have implemented ANT in
> such a way that if a project directory is not available at build time it will
> excluded from the build configuration. Since the sub-module pom contains the
> reference to a sibling build configuration anyway the build
> will fail if the dependency cannot be found.
> Currently if a module is defined for which no project exists you get the
> following error:
> E:\Temp\Maven\AXN>mvn install
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] Error building POM (may not be this project's POM).
> Project ID: unknown
> Reason: Could not find the model file 'E:\Temp\Maven\AXN\xyz\pom.xml'.
> ...
> On further investigation I located the source of the exception is being
> thrown in the method org.apache.maven.DefaultMaven::collectProjects where the
> modules list added at line 496:
> modulesFiles.add( moduleFile );
> The following change would do the trick...
> if( moduleFile.isFile()) {
> modulesFiles.add( moduleFile );
> }
--
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-1603) Upload JIDE Common Layer to maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99757 ] Arik Kfir commented on MAVENUPLOAD-1603: I don't see it either. > Upload JIDE Common Layer to maven repository > > > Key: MAVENUPLOAD-1603 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1603 > Project: maven-upload-requests > Issue Type: Task >Reporter: David Qiao > > JIDE Common Layer is Swing component library built on top of Java/Swing. It > is also the foundation of other component products from JIDE. This project > has over 30 Swing components and over 100k lines of code. It greatly enhanced > the default component set provided by Swing and allow developers to focus on > business logic layer instead of making components. > JIDE Common Layer was originally developed by JIDE Software developers as a > foundation in order to build other more advanced components. In April of > 2007, JIDE Software decided to open source this common layer so that more and > more developers can leverage them instead of wasting time building them > again. > For more information, please visit project home page on JIDE Software website > at http://www.jidesoft.com/products/oss.htm or on java.net at > https://jide-oss.dev.java.net. -- 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-410) Dependency Tree is not shown in artifact details screen.
[ http://jira.codehaus.org/browse/MRM-410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-410. -- Resolution: Fixed Work completed in trunk. > Dependency Tree is not shown in artifact details screen. > > > Key: MRM-410 > URL: http://jira.codehaus.org/browse/MRM-410 > Project: Archiva > Issue Type: Bug > Components: browser >Affects Versions: 1.0-alpha-1 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-2 > > > When browsing to an artifact, the artifact details screen is shown ok. > But when using the Dependency Tree tab, the information is always blank. -- 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: (MINVOKER-4) Use order of invocations as specified in pomIncludes
[ http://jira.codehaus.org/browse/MINVOKER-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MINVOKER-4: -- Description: I use the invoker plugin to create a multi-multiproject build. In fact, this is like using maven as a build server. It would be nice if the invoker plugins does its invocations in the order as specied in pomIncludes, just like maven does on modules in pom projects. Now, it seems to use some kind of alphabetical order. was: I use the invoker plugin to create a multi-multiproject build. In fact, this is like using maven as a build server. It would be nice if the invoker plugins does its invocations in the order as specied in pomIncludes, just like maven does on modules in pom projects. Now, it seems to use some kind of alphabetical order. > Use order of invocations as specified in pomIncludes > > > Key: MINVOKER-4 > URL: http://jira.codehaus.org/browse/MINVOKER-4 > Project: Maven 2.x Invoker Plugin > Issue Type: Improvement >Affects Versions: 1.0 >Reporter: Wouter Hermeling >Assignee: John Casey > > I use the invoker plugin to create a multi-multiproject build. In fact, this > is like using maven as a build server. > It would be nice if the invoker plugins does its invocations in the order as > specied in pomIncludes, just like maven does on modules in pom projects. Now, > it seems to use some kind of alphabetical order. -- 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-1603) Upload JIDE Common Layer to maven repository
[ http://jira.codehaus.org/browse/MAVENUPLOAD-1603?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99761 ] David Qiao commented on MAVENUPLOAD-1603: - Sorry about that. It should have the source jar now. I uploaded the wrong jar last time. > Upload JIDE Common Layer to maven repository > > > Key: MAVENUPLOAD-1603 > URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1603 > Project: maven-upload-requests > Issue Type: Task >Reporter: David Qiao > > JIDE Common Layer is Swing component library built on top of Java/Swing. It > is also the foundation of other component products from JIDE. This project > has over 30 Swing components and over 100k lines of code. It greatly enhanced > the default component set provided by Swing and allow developers to focus on > business logic layer instead of making components. > JIDE Common Layer was originally developed by JIDE Software developers as a > foundation in order to build other more advanced components. In April of > 2007, JIDE Software decided to open source this common layer so that more and > more developers can leverage them instead of wasting time building them > again. > For more information, please visit project home page on JIDE Software website > at http://www.jidesoft.com/products/oss.htm or on java.net at > https://jide-oss.dev.java.net. -- 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-74) project doesn't get well packaged on MacOSX: missing entries in plexus components.xml
project doesn't get well packaged on MacOSX: missing entries in plexus
components.xml
-
Key: MANTTASKS-74
URL: http://jira.codehaus.org/browse/MANTTASKS-74
Project: Maven 2.x Ant Tasks
Issue Type: Bug
Affects Versions: 2.1-alpha-1
Environment: MacOS 10.4, java version "1.5.0_07", ant-tasks/trunk
revision 548061
Reporter: Herve Boutemy
running "{{mvn package && ant -f sample.build.xml}}", I get
{{/Users/herve/Documents/maven/ant-tasks/trunk/sample.build.xml:34: Unable to
find component:
org.apache.maven.artifact.repository.layout.ArtifactRepositoryLayout[default]}}
Works well:
- on the same Mac machine, for {{ant-tasks/branches/maven-ant-tasks-2.0.x}}
revision 548060
- on a Linux box for ant-tasks/trunk
I found that there are a lot of entries missing in
{{META-INF/plexus/components.xml}}:
- 6846 bytes on the Mac
- 19682 bytes on 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] Closed: (MANTTASKS-11) antlib + http based repository + version range errors badly
[
http://jira.codehaus.org/browse/MANTTASKS-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Herve Boutemy closed MANTTASKS-11.
--
Resolution: Cannot Reproduce
Fix Version/s: 2.0.7
I just tried to add {{}} to test-deps target in
sample.build.xml, and found everything ok (Maven Ant Tasks version is
2.0.7-SNAPSHOT)
Please reopen the issue if you still have a problem: we'll work together to
reproduce it.
> antlib + http based repository + version range errors badly
> ---
>
> Key: MANTTASKS-11
> URL: http://jira.codehaus.org/browse/MANTTASKS-11
> Project: Maven 2.x Ant Tasks
> Issue Type: Bug
> Environment: maven 2.0 (release), antlib, ant, apache 2 webserver on
> windows
>Reporter: spencer portee
>Priority: Critical
> Fix For: 2.0.7
>
>
> In my pom file, I have a dependency, it has no child dependencies beyond that
> looks like this:
>
>org.sporty
>xwork
>[1.0.5,1.1)
>runtime
>
> and use the following in my build script:
> pathId="project.classpath.runtime">
>
> layout="default" />
>
> The variable I have above is being set right per tests 1-3. The last test..
> it gets strange.
> I deployed xwork, as an empty jar by accident, so don't be surprised there's
> nothing in the jar. But the dependency downloading from the webserver breaks
> horribly. I tested 4 scenarios:
> 1. If I put in my pom as my remote repository as file://c:/temp/repository
> and deploy to there, the above pom works flawlessly.
> 2 & 3. If I replace the range w/ a simple: 1.0.5 and set
> my repository to http://sporty.org/java/repository, it downloads fine as
> well. It works with the filesystem remote repository of my c:/temp...
> directory.
> 4. If I use the http repository AND use a range version as I originally
> wanted, I get an ugly error:
> C:\development\eclipse 3.0\workspace\hibernate-3\common.xml:4: Unable to
> resolve
> artifact: Unable to get dependency information: Unable to read local copy of
> me
> tadata: Cannot read metadata from 'C:\Documents and
> Settings\sportee\.m2\reposit
> ory\org\sporty\xwork\maven-metadata-remote.xml': end tag name must
> match
> start tag name from line 11 (position: START_TAG seen ...
> 11-Oct-2005 17:52- \n... @11:11)
> org.sporty:xwork:null:jar
> from the specified remote repositories:
> remote (http://sporty.org/java/repository )
> Path to dependency:
> 1) org.sporty:xdoclet-xwork:jar:1.0-SNAPSHOT
> --
> The contents of the ...-remote.xml file, I see a directory listing, and not
> the contents of the repository file on the server. My naive guess is the
> repository file to look for is getting lost, or not passed, if it's in a
> hashmap, not being referenced properly...
> Thanks,
> -s
--
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: (MANTTASKS-16) Antlib attempts to download version.txt files from legacy repository.
[ http://jira.codehaus.org/browse/MANTTASKS-16?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99767 ] Herve Boutemy commented on MANTTASKS-16: can you check this issue with Maven Ant Tasks 2.0.6 or 2.0.7? If the problem persist, please provide a sample build.xml for me to reproduce it > Antlib attempts to download version.txt files from legacy repository. > - > > Key: MANTTASKS-16 > URL: http://jira.codehaus.org/browse/MANTTASKS-16 > Project: Maven 2.x Ant Tasks > Issue Type: Bug > Environment: Reproduced on Solaris, Linux, and Win32. >Reporter: Tim Clemons > > When attempting to download artifacts from a legacy repository, the build > sometimes fails with the following error: > Caused by: org.apache.maven.artifact.resolver.ArtifactResolutionException: > Unable to retrieve metadata > On checking the maven-proxy's log, it appears that files of the format > --SNAPSHOT-version.txt are getting queried. These don't > appear to be a part of Maven 1.x builds and so shouldn't trigger a failure > condition if they can't be found. -- 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-369) [Repository Scanning] Exception on update to pre-existing artifact.
[
http://jira.codehaus.org/browse/MRM-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MRM-369 started by Joakim Erdfelt.
> [Repository Scanning] Exception on update to pre-existing artifact.
> ---
>
> Key: MRM-369
> URL: http://jira.codehaus.org/browse/MRM-369
> Project: Archiva
> Issue Type: Bug
> Components: repository scanning
>Affects Versions: 1.0-alpha-1
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-alpha-2
>
>
> When scanning a repository that has an artifact that has been updated on
> disk, and exists in the database already, the following exception occurs.
> {code}
> com.mysql.jdbc.exceptions.MySQLIntegrityConstraintViolationException:
> Duplicate entry 'commons-httpclient--commons-httpclient-jar-2.0.2' for key 1
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:931)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1573)
> at
> com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1169)
> at
> com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:693)
> at
> com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1404)
> at
> com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1318)
> at
> com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1303)
> at
> org.jpox.store.rdbms.RDBMSManager.executeStatementUpdate(RDBMSManager.java:572)
> at
> org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:328)
> 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.makePersistent(AbstractPersistenceManager.java:1261)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.saveObject(JdoAccess.java:196)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.saveObject(JdoAccess.java:169)
> at
> org.apache.maven.archiva.database.jdo.JdoArtifactDAO.saveArtifact(JdoArtifactDAO.java:110)
> at
> org.apache.maven.archiva.consumers.database.ArtifactUpdateDatabaseConsumer.processFile(ArtifactUpdateDatabaseConsumer.java:195)
> at
> org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessFileClosure.execute(ConsumerProcessFileClosure.java:57)
> at
> org.apache.commons.collections.functors.IfClosure.execute(IfClosure.java:117)
> at
> org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388)
> at
> org.apache.maven.archiva.repository.scanner.RepositoryScannerInstance.directoryWalkStep(RepositoryScannerInstance.java:127)
> at
> org.codehaus.plexus.util.DirectoryWalker.fireStep(DirectoryWalker.java:173)
> at
> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:391)
> at
> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
> at
> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
> at
> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
> at
> org.codehaus.plexus.util.DirectoryWalker.scan(DirectoryWalker.java:344)
> at
> org.apache.maven.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultRepositoryScanner.java:126)
> at
> org.apache.maven.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultRepositoryScanner.java:65)
> at
> org.apache.maven.archiva.scheduled.executors.ArchivaRepositoryScanningTaskExecutor.executeTask(ArchivaRepositoryScanningTaskExecutor.java:105)
> at
> org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
> at
> edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
> at
> edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
> at java.lang.Thread.run(Thread.java:595)
> {code}
> Need logic to prevent the Table cons
[jira] Commented: (CONTINUUM-1184) using plexus-contextualizer to setup port in jetty
[
http://jira.codehaus.org/browse/CONTINUUM-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99781
]
Wendy Smoak commented on CONTINUUM-1184:
This works, with the exception of the pom.xml piece of the patch getting
rejected because we're on a later plexus version now.
With the patch applied, I'm able to pre-configure the port number. However, I
get an apps/continuum/conf/application.xml.rej file created with the following
contents:
{noformat}
***
*** 31,37
true
- 8080
> Key: CONTINUUM-1184
> URL: http://jira.codehaus.org/browse/CONTINUUM-1184
> Project: Continuum
> Issue Type: Improvement
> Environment: all
>Reporter: Olivier Lamy
> Fix For: 1.1-alpha-3
>
> Attachments: CONTINUUM-1184
>
>
> Actually when using continuum-plexus-runtime, in order to change the http
> port : the application must be started (in order to be extracted), stopped.
> Then configuration file can be changed.
> With this patch the jetty port can be set before the first start.
> I have deployed all needed artifacts in codehaus snapshot repo.
> --
> Olivier
--
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-369) [Repository Scanning] Exception on update to pre-existing artifact.
[
http://jira.codehaus.org/browse/MRM-369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt closed MRM-369.
--
Resolution: Fixed
Fixed in trunk
> [Repository Scanning] Exception on update to pre-existing artifact.
> ---
>
> Key: MRM-369
> URL: http://jira.codehaus.org/browse/MRM-369
> Project: Archiva
> Issue Type: Bug
> Components: repository scanning
>Affects Versions: 1.0-alpha-1
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>Priority: Blocker
> Fix For: 1.0-alpha-2
>
>
> When scanning a repository that has an artifact that has been updated on
> disk, and exists in the database already, the following exception occurs.
> {code}
> com.mysql.jdbc.exceptions.MySQLIntegrityConstraintViolationException:
> Duplicate entry 'commons-httpclient--commons-httpclient-jar-2.0.2' for key 1
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:931)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1573)
> at
> com.mysql.jdbc.ServerPreparedStatement.serverExecute(ServerPreparedStatement.java:1169)
> at
> com.mysql.jdbc.ServerPreparedStatement.executeInternal(ServerPreparedStatement.java:693)
> at
> com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1404)
> at
> com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1318)
> at
> com.mysql.jdbc.PreparedStatement.executeUpdate(PreparedStatement.java:1303)
> at
> org.jpox.store.rdbms.RDBMSManager.executeStatementUpdate(RDBMSManager.java:572)
> at
> org.jpox.store.rdbms.request.InsertRequest.execute(InsertRequest.java:328)
> 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.makePersistent(AbstractPersistenceManager.java:1261)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.saveObject(JdoAccess.java:196)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.saveObject(JdoAccess.java:169)
> at
> org.apache.maven.archiva.database.jdo.JdoArtifactDAO.saveArtifact(JdoArtifactDAO.java:110)
> at
> org.apache.maven.archiva.consumers.database.ArtifactUpdateDatabaseConsumer.processFile(ArtifactUpdateDatabaseConsumer.java:195)
> at
> org.apache.maven.archiva.repository.scanner.functors.ConsumerProcessFileClosure.execute(ConsumerProcessFileClosure.java:57)
> at
> org.apache.commons.collections.functors.IfClosure.execute(IfClosure.java:117)
> at
> org.apache.commons.collections.CollectionUtils.forAllDo(CollectionUtils.java:388)
> at
> org.apache.maven.archiva.repository.scanner.RepositoryScannerInstance.directoryWalkStep(RepositoryScannerInstance.java:127)
> at
> org.codehaus.plexus.util.DirectoryWalker.fireStep(DirectoryWalker.java:173)
> at
> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:391)
> at
> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
> at
> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
> at
> org.codehaus.plexus.util.DirectoryWalker.scanDir(DirectoryWalker.java:385)
> at
> org.codehaus.plexus.util.DirectoryWalker.scan(DirectoryWalker.java:344)
> at
> org.apache.maven.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultRepositoryScanner.java:126)
> at
> org.apache.maven.archiva.repository.scanner.DefaultRepositoryScanner.scan(DefaultRepositoryScanner.java:65)
> at
> org.apache.maven.archiva.scheduled.executors.ArchivaRepositoryScanningTaskExecutor.executeTask(ArchivaRepositoryScanningTaskExecutor.java:105)
> at
> org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
> at
> edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
> at
> edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:987)
> at
> edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:528)
> at java.lang.Thread.run(Thread
[jira] Created: (MRM-415) [MySQL] Specified key was too long; max key length is 765 bytes
[MySQL] Specified key was too long; max key length is 765 bytes
---
Key: MRM-415
URL: http://jira.codehaus.org/browse/MRM-415
Project: Archiva
Issue Type: Bug
Reporter: Joakim Erdfelt
When starting up archiva on a MySQL Database. the following error is seen.
{code}
Caused by: javax.jdo.JDODataStoreException: An exception was thrown while
adding/validating class(es) : Specified key was too long; max key length is 765
bytes
com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Specified key was too
long; max key length is 765 bytes
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1573)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1665)
at com.mysql.jdbc.Connection.execSQL(Connection.java:3170)
at com.mysql.jdbc.Connection.execSQL(Connection.java:3099)
at com.mysql.jdbc.Statement.execute(Statement.java:695)
at
org.jpox.store.rdbms.table.AbstractTable.executeDdlStatement(AbstractTable.java:614)
at
org.jpox.store.rdbms.table.AbstractTable.executeDdlStatementList(AbstractTable.java:570)
at
org.jpox.store.rdbms.table.AbstractTable.create(AbstractTable.java:297)
at
org.jpox.store.rdbms.table.AbstractTable.exists(AbstractTable.java:341)
at
org.jpox.store.rdbms.RDBMSManager$ClassAdder.performTablesValidation(RDBMSManager.java:3052)
at
org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:3313)
at
org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2554)
at
org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2406)
at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:821)
at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:835)
at
org.jpox.AbstractPersistenceManager.newObjectIdInstance(AbstractPersistenceManager.java:2377)
at
org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:428)
at
org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:466)
at
org.apache.maven.archiva.database.jdo.JdoRepositoryDAO.getRepository(JdoRepositoryDAO.java:76)
at
org.apache.maven.archiva.web.startup.ConfigurationSynchronization.synchConfiguration(ConfigurationSynchronization.java:94)
at
org.apache.maven.archiva.web.startup.ConfigurationSynchronization.initialize(ConfigurationSynchronization.java:147)
at
org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
{code}
--
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-415) [MySQL] Specified key was too long; max key length is 765 bytes
[
http://jira.codehaus.org/browse/MRM-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt updated MRM-415:
---
Assignee: Joakim Erdfelt
Affects Version/s: 1.0-alpha-2
> [MySQL] Specified key was too long; max key length is 765 bytes
> ---
>
> Key: MRM-415
> URL: http://jira.codehaus.org/browse/MRM-415
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-alpha-2
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>
> When starting up archiva on a MySQL Database. the following error is seen.
> {code}
> Caused by: javax.jdo.JDODataStoreException: An exception was thrown while
> adding/validating class(es) : Specified key was too long; max key length is
> 765 bytes
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Specified key was too
> long; max key length is 765 bytes
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1573)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1665)
> at com.mysql.jdbc.Connection.execSQL(Connection.java:3170)
> at com.mysql.jdbc.Connection.execSQL(Connection.java:3099)
> at com.mysql.jdbc.Statement.execute(Statement.java:695)
> at
> org.jpox.store.rdbms.table.AbstractTable.executeDdlStatement(AbstractTable.java:614)
> at
> org.jpox.store.rdbms.table.AbstractTable.executeDdlStatementList(AbstractTable.java:570)
> at
> org.jpox.store.rdbms.table.AbstractTable.create(AbstractTable.java:297)
> at
> org.jpox.store.rdbms.table.AbstractTable.exists(AbstractTable.java:341)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.performTablesValidation(RDBMSManager.java:3052)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:3313)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2554)
> at
> org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2406)
> at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:821)
> at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:835)
> at
> org.jpox.AbstractPersistenceManager.newObjectIdInstance(AbstractPersistenceManager.java:2377)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:428)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:466)
> at
> org.apache.maven.archiva.database.jdo.JdoRepositoryDAO.getRepository(JdoRepositoryDAO.java:76)
> at
> org.apache.maven.archiva.web.startup.ConfigurationSynchronization.synchConfiguration(ConfigurationSynchronization.java:94)
> at
> org.apache.maven.archiva.web.startup.ConfigurationSynchronization.initialize(ConfigurationSynchronization.java:147)
> at
> org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
> {code}
--
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-415) [MySQL] Specified key was too long; max key length is 765 bytes
[
http://jira.codehaus.org/browse/MRM-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on MRM-415 started by Joakim Erdfelt.
> [MySQL] Specified key was too long; max key length is 765 bytes
> ---
>
> Key: MRM-415
> URL: http://jira.codehaus.org/browse/MRM-415
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-alpha-2
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>
> When starting up archiva on a MySQL Database. the following error is seen.
> {code}
> Caused by: javax.jdo.JDODataStoreException: An exception was thrown while
> adding/validating class(es) : Specified key was too long; max key length is
> 765 bytes
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Specified key was too
> long; max key length is 765 bytes
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1573)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1665)
> at com.mysql.jdbc.Connection.execSQL(Connection.java:3170)
> at com.mysql.jdbc.Connection.execSQL(Connection.java:3099)
> at com.mysql.jdbc.Statement.execute(Statement.java:695)
> at
> org.jpox.store.rdbms.table.AbstractTable.executeDdlStatement(AbstractTable.java:614)
> at
> org.jpox.store.rdbms.table.AbstractTable.executeDdlStatementList(AbstractTable.java:570)
> at
> org.jpox.store.rdbms.table.AbstractTable.create(AbstractTable.java:297)
> at
> org.jpox.store.rdbms.table.AbstractTable.exists(AbstractTable.java:341)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.performTablesValidation(RDBMSManager.java:3052)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:3313)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2554)
> at
> org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2406)
> at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:821)
> at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:835)
> at
> org.jpox.AbstractPersistenceManager.newObjectIdInstance(AbstractPersistenceManager.java:2377)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:428)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:466)
> at
> org.apache.maven.archiva.database.jdo.JdoRepositoryDAO.getRepository(JdoRepositoryDAO.java:76)
> at
> org.apache.maven.archiva.web.startup.ConfigurationSynchronization.synchConfiguration(ConfigurationSynchronization.java:94)
> at
> org.apache.maven.archiva.web.startup.ConfigurationSynchronization.initialize(ConfigurationSynchronization.java:147)
> at
> org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
> {code}
--
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-415) [MySQL] Specified key was too long; max key length is 765 bytes
[
http://jira.codehaus.org/browse/MRM-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99783
]
Joakim Erdfelt commented on MRM-415:
Some more details...
{code}
NestedThrowables:
com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Specified key was too
long; max key length is 765 bytes
at
org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:3330)
at
org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2554)
at
org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2406)
at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:821)
at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:835)
at
org.jpox.AbstractPersistenceManager.newObjectIdInstance(AbstractPersistenceManager.java:2377)
at
org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:428)
... 55 more
Caused by: com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Specified key
was too long; max key length is 765 bytes
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1573)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1665)
at com.mysql.jdbc.Connection.execSQL(Connection.java:3170)
at com.mysql.jdbc.Connection.execSQL(Connection.java:3099)
at com.mysql.jdbc.Statement.execute(Statement.java:695)
at
org.jpox.store.rdbms.table.AbstractTable.executeDdlStatement(AbstractTable.java:614)
at
org.jpox.store.rdbms.table.AbstractTable.executeDdlStatementList(AbstractTable.java:570)
at
org.jpox.store.rdbms.table.AbstractTable.create(AbstractTable.java:297)
at
org.jpox.store.rdbms.table.AbstractTable.exists(AbstractTable.java:341)
at
org.jpox.store.rdbms.RDBMSManager$ClassAdder.performTablesValidation(RDBMSManager.java:3052)
at
org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:3313)
... 61 more
{code}
> [MySQL] Specified key was too long; max key length is 765 bytes
> ---
>
> Key: MRM-415
> URL: http://jira.codehaus.org/browse/MRM-415
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-alpha-2
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>
> When starting up archiva on a MySQL Database. the following error is seen.
> {code}
> Caused by: javax.jdo.JDODataStoreException: An exception was thrown while
> adding/validating class(es) : Specified key was too long; max key length is
> 765 bytes
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Specified key was too
> long; max key length is 765 bytes
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1573)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1665)
> at com.mysql.jdbc.Connection.execSQL(Connection.java:3170)
> at com.mysql.jdbc.Connection.execSQL(Connection.java:3099)
> at com.mysql.jdbc.Statement.execute(Statement.java:695)
> at
> org.jpox.store.rdbms.table.AbstractTable.executeDdlStatement(AbstractTable.java:614)
> at
> org.jpox.store.rdbms.table.AbstractTable.executeDdlStatementList(AbstractTable.java:570)
> at
> org.jpox.store.rdbms.table.AbstractTable.create(AbstractTable.java:297)
> at
> org.jpox.store.rdbms.table.AbstractTable.exists(AbstractTable.java:341)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.performTablesValidation(RDBMSManager.java:3052)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:3313)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2554)
> at
> org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2406)
> at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:821)
> at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:835)
> at
> org.jpox.AbstractPersistenceManager.newObjectIdInstance(AbstractPersistenceManager.java:2377)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:428)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:466)
> at
> org.apache.maven.archiva.database.jdo.JdoRepositoryDAO.getRepository(JdoRepositoryDAO.java:76)
> at
> org.apache.maven.archiva.web.startup.ConfigurationSynchronization.synchConfiguration(ConfigurationSynchronization.java:94)
>
[jira] Commented: (MRM-415) [MySQL] Specified key was too long; max key length is 765 bytes
[
http://jira.codehaus.org/browse/MRM-415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99784
]
Joakim Erdfelt commented on MRM-415:
Going through and setting the stash.maxsize on all of the keys in the database
> [MySQL] Specified key was too long; max key length is 765 bytes
> ---
>
> Key: MRM-415
> URL: http://jira.codehaus.org/browse/MRM-415
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-alpha-2
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
>
> When starting up archiva on a MySQL Database. the following error is seen.
> {code}
> Caused by: javax.jdo.JDODataStoreException: An exception was thrown while
> adding/validating class(es) : Specified key was too long; max key length is
> 765 bytes
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Specified key was too
> long; max key length is 765 bytes
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1573)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1665)
> at com.mysql.jdbc.Connection.execSQL(Connection.java:3170)
> at com.mysql.jdbc.Connection.execSQL(Connection.java:3099)
> at com.mysql.jdbc.Statement.execute(Statement.java:695)
> at
> org.jpox.store.rdbms.table.AbstractTable.executeDdlStatement(AbstractTable.java:614)
> at
> org.jpox.store.rdbms.table.AbstractTable.executeDdlStatementList(AbstractTable.java:570)
> at
> org.jpox.store.rdbms.table.AbstractTable.create(AbstractTable.java:297)
> at
> org.jpox.store.rdbms.table.AbstractTable.exists(AbstractTable.java:341)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.performTablesValidation(RDBMSManager.java:3052)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:3313)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2554)
> at
> org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2406)
> at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:821)
> at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:835)
> at
> org.jpox.AbstractPersistenceManager.newObjectIdInstance(AbstractPersistenceManager.java:2377)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:428)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:466)
> at
> org.apache.maven.archiva.database.jdo.JdoRepositoryDAO.getRepository(JdoRepositoryDAO.java:76)
> at
> org.apache.maven.archiva.web.startup.ConfigurationSynchronization.synchConfiguration(ConfigurationSynchronization.java:94)
> at
> org.apache.maven.archiva.web.startup.ConfigurationSynchronization.initialize(ConfigurationSynchronization.java:147)
> at
> org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
> {code}
--
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-1184) Ability to pre-configure the Jetty port in conf/plexus.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated CONTINUUM-1184: --- Summary: Ability to pre-configure the Jetty port in conf/plexus.xml (was: using plexus-contextualizer to setup port in jetty) original summary: using plexus-contextualizer to setup port in jetty > Ability to pre-configure the Jetty port in conf/plexus.xml > -- > > Key: CONTINUUM-1184 > URL: http://jira.codehaus.org/browse/CONTINUUM-1184 > Project: Continuum > Issue Type: Improvement > Environment: all >Reporter: Olivier Lamy > Fix For: 1.1-alpha-3 > > Attachments: CONTINUUM-1184 > > > Actually when using continuum-plexus-runtime, in order to change the http > port : the application must be started (in order to be extracted), stopped. > Then configuration file can be changed. > With this patch the jetty port can be set before the first start. > I have deployed all needed artifacts in codehaus snapshot repo. > -- > Olivier -- 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-1184) Ability to pre-configure the Jetty port in conf/plexus.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated CONTINUUM-1184: --- Assignee: Wendy Smoak Affects Version/s: 1.1-alpha-2 Applied the patch (with a bit of cleanup) in r548122 and updated the configuration guide in r548124. Leaving this open to deal with the .rej file mentioned in the previous comment. Brett? Emmanuel? > Ability to pre-configure the Jetty port in conf/plexus.xml > -- > > Key: CONTINUUM-1184 > URL: http://jira.codehaus.org/browse/CONTINUUM-1184 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-alpha-2 > Environment: all >Reporter: Olivier Lamy >Assignee: Wendy Smoak > Fix For: 1.1-alpha-3 > > Attachments: CONTINUUM-1184 > > > Actually when using continuum-plexus-runtime, in order to change the http > port : the application must be started (in order to be extracted), stopped. > Then configuration file can be changed. > With this patch the jetty port can be set before the first start. > I have deployed all needed artifacts in codehaus snapshot repo. > -- > Olivier -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (CONTINUUM-1184) Ability to pre-configure the Jetty port in conf/plexus.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99787 ] Wendy Smoak edited comment on CONTINUUM-1184 at 6/17/07 5:24 PM: - Applied the patch (with a bit of cleanup) in r548122 and updated the configuration guide in r548124. was: Applied the patch (with a bit of cleanup) in r548122 and updated the configuration guide in r548124. Leaving this open to deal with the .rej file mentioned in the previous comment. Brett? Emmanuel? > Ability to pre-configure the Jetty port in conf/plexus.xml > -- > > Key: CONTINUUM-1184 > URL: http://jira.codehaus.org/browse/CONTINUUM-1184 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-alpha-2 > Environment: all >Reporter: Olivier Lamy >Assignee: Wendy Smoak > Fix For: 1.1-alpha-3 > > Attachments: CONTINUUM-1184 > > > Actually when using continuum-plexus-runtime, in order to change the http > port : the application must be started (in order to be extracted), stopped. > Then configuration file can be changed. > With this patch the jetty port can be set before the first start. > I have deployed all needed artifacts in codehaus snapshot repo. > -- > Olivier -- 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-1184) Ability to pre-configure the Jetty port in conf/plexus.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated CONTINUUM-1184: --- Comment: was deleted > Ability to pre-configure the Jetty port in conf/plexus.xml > -- > > Key: CONTINUUM-1184 > URL: http://jira.codehaus.org/browse/CONTINUUM-1184 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-alpha-2 > Environment: all >Reporter: Olivier Lamy >Assignee: Wendy Smoak > Fix For: 1.1-alpha-3 > > Attachments: CONTINUUM-1184 > > > Actually when using continuum-plexus-runtime, in order to change the http > port : the application must be started (in order to be extracted), stopped. > Then configuration file can be changed. > With this patch the jetty port can be set before the first start. > I have deployed all needed artifacts in codehaus snapshot repo. > -- > Olivier -- 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-1184) Ability to pre-configure the Jetty port in conf/plexus.xml
[ http://jira.codehaus.org/browse/CONTINUUM-1184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak closed CONTINUUM-1184. -- Resolution: Fixed > Ability to pre-configure the Jetty port in conf/plexus.xml > -- > > Key: CONTINUUM-1184 > URL: http://jira.codehaus.org/browse/CONTINUUM-1184 > Project: Continuum > Issue Type: Improvement >Affects Versions: 1.1-alpha-2 > Environment: all >Reporter: Olivier Lamy >Assignee: Wendy Smoak > Fix For: 1.1-alpha-3 > > Attachments: CONTINUUM-1184 > > > Actually when using continuum-plexus-runtime, in order to change the http > port : the application must be started (in order to be extracted), stopped. > Then configuration file can be changed. > With this patch the jetty port can be set before the first start. > I have deployed all needed artifacts in codehaus snapshot repo. > -- > Olivier -- 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-2602) maven-csharp-source-plugin:process-classes messes up outputDirectory and thereby indirectly messes up release plugin
[ http://jira.codehaus.org/browse/MNG-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99791 ] James Carpenter commented on MNG-2602: -- The old C# plugins in this bug refers to are pre-NMaven. At this point NMaven has far exceeded what was available so these old plugins are really just cruft. I recommend removing them from the trunk. > maven-csharp-source-plugin:process-classes messes up outputDirectory and > thereby indirectly messes up release plugin > > > Key: MNG-2602 > URL: http://jira.codehaus.org/browse/MNG-2602 > Project: Maven 2 > Issue Type: Bug > Components: Sandbox > Environment: Windows XP >Reporter: James Carpenter >Priority: Critical > Fix For: Reviewed Pending Version Assignment > > > Within the csharp plugins > org.apache.maven.plugins:maven-csharp-source-plugin:process-classes is > registered at the process-classes phase. Within this plugin the execute > method resets the output directory to be that of the actual artifact > (target/dotnet-assembly/somelib.dll) rather than the directory which it was > set to (target/dotnet-assembly). > The short javadoc within > org.apache.maven.plugin.csharp.source.ProcessClassesMojo says: > --- > This Mojo adds the result of the compile to the classpath elements > This is required by the NUnitMojo. > > As it turns out this has very negative side affects. If one tries to run > multiple goals at once (mvn deploy site-deploy), the first goal is very > likely to mess up the effective pom for the following goal. This is what > happens to the release plugin. During release:perform the release plugin > uses the plexus command line tools to run "mvn --no-plugin-updates > --variousOtherFlags deploy site-deploy" within target/checkout. As you might > imagine this really messes things up, such that the site-deploy fails as it > tries to find target/checkout/target/dotnet-assembly/somelib.dll/somelib.dll. > In summary a better way to keep the NUnit plugin happy must be found, as the > current solution is very problematic. -- 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-415) [MySQL] Specified key was too long; max key length is 765 bytes
[
http://jira.codehaus.org/browse/MRM-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt closed MRM-415.
--
Resolution: Fixed
Fix Version/s: 1.0-alpha-2
Fixed in trunk.
> [MySQL] Specified key was too long; max key length is 765 bytes
> ---
>
> Key: MRM-415
> URL: http://jira.codehaus.org/browse/MRM-415
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0-alpha-2
>Reporter: Joakim Erdfelt
>Assignee: Joakim Erdfelt
> Fix For: 1.0-alpha-2
>
>
> When starting up archiva on a MySQL Database. the following error is seen.
> {code}
> Caused by: javax.jdo.JDODataStoreException: An exception was thrown while
> adding/validating class(es) : Specified key was too long; max key length is
> 765 bytes
> com.mysql.jdbc.exceptions.MySQLSyntaxErrorException: Specified key was too
> long; max key length is 765 bytes
> at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:936)
> at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:2870)
> at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:1573)
> at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:1665)
> at com.mysql.jdbc.Connection.execSQL(Connection.java:3170)
> at com.mysql.jdbc.Connection.execSQL(Connection.java:3099)
> at com.mysql.jdbc.Statement.execute(Statement.java:695)
> at
> org.jpox.store.rdbms.table.AbstractTable.executeDdlStatement(AbstractTable.java:614)
> at
> org.jpox.store.rdbms.table.AbstractTable.executeDdlStatementList(AbstractTable.java:570)
> at
> org.jpox.store.rdbms.table.AbstractTable.create(AbstractTable.java:297)
> at
> org.jpox.store.rdbms.table.AbstractTable.exists(AbstractTable.java:341)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.performTablesValidation(RDBMSManager.java:3052)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.addClassTablesAndValidate(RDBMSManager.java:3313)
> at
> org.jpox.store.rdbms.RDBMSManager$ClassAdder.run(RDBMSManager.java:2554)
> at
> org.jpox.store.rdbms.RDBMSManager$MgmtTransaction.execute(RDBMSManager.java:2406)
> at org.jpox.store.rdbms.RDBMSManager.addClasses(RDBMSManager.java:821)
> at org.jpox.store.rdbms.RDBMSManager.addClass(RDBMSManager.java:835)
> at
> org.jpox.AbstractPersistenceManager.newObjectIdInstance(AbstractPersistenceManager.java:2377)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:428)
> at
> org.apache.maven.archiva.database.jdo.JdoAccess.getObjectById(JdoAccess.java:466)
> at
> org.apache.maven.archiva.database.jdo.JdoRepositoryDAO.getRepository(JdoRepositoryDAO.java:76)
> at
> org.apache.maven.archiva.web.startup.ConfigurationSynchronization.synchConfiguration(ConfigurationSynchronization.java:94)
> at
> org.apache.maven.archiva.web.startup.ConfigurationSynchronization.initialize(ConfigurationSynchronization.java:147)
> at
> org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33)
> {code}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-2466) resursive build - modules using always using pom.xml
[ http://jira.codehaus.org/browse/MNG-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2466. - Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) > resursive build - modules using always using pom.xml > > > Key: MNG-2466 > URL: http://jira.codehaus.org/browse/MNG-2466 > Project: Maven 2 > Issue Type: Bug > Components: POM > Environment: software >Reporter: Jagan >Priority: Blocker > > When we run a multi project build with an alternative pom file, the modules > its still using pom.xml. > Shouldn't the modules use the same alternative pom file which we passed. > Could someone fix at the earliest as its a showstopper for our development. > 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] Reopened: (MNG-2466) resursive build - modules using always using pom.xml
[ http://jira.codehaus.org/browse/MNG-2466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-2466: --- > resursive build - modules using always using pom.xml > > > Key: MNG-2466 > URL: http://jira.codehaus.org/browse/MNG-2466 > Project: Maven 2 > Issue Type: Bug > Components: POM > Environment: software >Reporter: Jagan >Priority: Blocker > > When we run a multi project build with an alternative pom file, the modules > its still using pom.xml. > Shouldn't the modules use the same alternative pom file which we passed. > Could someone fix at the earliest as its a showstopper for our development. > 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: (MNG-1436) Unable to load maven-model-2.0-all from a plugin
[ http://jira.codehaus.org/browse/MNG-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-1436. - Resolution: Won't Fix Fix Version/s: (was: Reviewed Pending Version Assignment) using a different artifact ID in the maven-one-plugin now. Though it may be possible to use the classifier version in Maven 2.0.6 due to the different exclusino rule s not sure. > Unable to load maven-model-2.0-all from a plugin > > > Key: MNG-1436 > URL: http://jira.codehaus.org/browse/MNG-1436 > Project: Maven 2 > Issue Type: Bug > Components: Plugins and Lifecycle >Reporter: fabrizio giustina >Priority: Critical > > The org.apache.maven:maven-model artifact is available with the "all" > classifier in the maven repo. The "all" version also contains project v3 > classes and reader/writer. > Adding a dependency with: > > org.apache.maven > maven-model > 2.0 > jar > all > > let you use project 3 classes in a plugin and install successfully. > However, when running the plugin, the maven-model-2.0-all artifact seems to > be ignored and replaced by the version in m2/lib _also if the classifier is > different_. > This is the debug log from an execution of a plugin that uses this dependency: > [INFO] Searching repository for plugin with prefix: 'maven1'. > [DEBUG] maven-maven1-plugin: using locally installed snapshot > [DEBUG] maven-maven1-plugin: using locally installed snapshot > [DEBUG] > org.apache.maven.plugins:maven-maven1-plugin:maven-plugin:2.0-SNAPSHOT > (selected for runtime) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) > [DEBUG] Retrieving parent-POM from the repository for project: > org.apache.maven:maven-model:jar:2.0 > [DEBUG] org.apache.maven:maven-model:jar:all:2.0 (selected for runtime) > [DEBUG] org.codehaus.plexus:plexus-utils:jar:1.0.4 (selected for runtime) > [DEBUG] dom4j:dom4j:jar:1.4 (selected for runtime) > [DEBUG] Configuring mojo > 'org.apache.maven.plugins:maven-maven1-plugin:2.0-SNAPSHOT:convert' --> > [DEBUG] (f) basedir = \testconvert > [DEBUG] -- end configuration -- > [INFO] [1:convert] > [WARNING] pom.xml in \testconvert already exists, overwriting > [INFO] > > [ERROR] FATAL ERROR > [INFO] > > [INFO] org/apache/maven/model/v3_0_0/io/xpp3/MavenXpp3Reader > [INFO] > > [DEBUG] Trace > java.lang.NoClassDefFoundError: > org/apache/maven/model/v3_0_0/io/xpp3/MavenXpp3Reader > At the moment this makes impossible to use pom v.3 in mvn. > Apart from the classifier issue that could be solved in a future m2 release, > I would like to find out a workaroud in order to use v3 poms for a mvn plugin > that could automatically convert maven 1 project.xml to mvn pom.xml for > making migration from maven 1 easier. > The current options I can think at are: > - embedding the org.apache.maven.model.v3_0_0.* classes in the plugin > - releasing maven-model-2.0-all with a different artifactId > (maven-model-all-2.0 or maven-model-v3-2.0) > thoughts? -- 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-2559) Module Selection From Command Line Argument Broken
[ http://jira.codehaus.org/browse/MNG-2559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99795 ] Brett Porter commented on MNG-2559: --- you can also use -r > Module Selection From Command Line Argument Broken > -- > > Key: MNG-2559 > URL: http://jira.codehaus.org/browse/MNG-2559 > Project: Maven 2 > Issue Type: Bug > Components: Command Line >Affects Versions: 2.0.4 > Environment: Linux 2.6.16-gentoo-r7 #3 SMP PREEMPT i686 Intel(R) > Xeon(TM) CPU 3.40GHz GNU/Linux > Java HotSpot(TM) Server VM (build 1.5.0_07-b03, mixed mode) > Maven 2.0.4 >Reporter: Gus Power > Fix For: Reviewed Pending Version Assignment > > > Hi, > I am unable to specify which modules to include in the reactor build from the > command line when invoking maven on the parent POM. Having searched around on > Google I have seen references to invoking maven using the following syntax: > 'mvn -Dmodule=moduleName goal' but it does not appear to have any effect. My > solution is to define different module combinations in different parent POM > profiles but this is clunky and inflexible. This has been a key annoyance in > setting up different cruisecontrol configurations for our continuous build. > Regards, > Gus. -- 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-388) Unable to configure archiva if configuration file did not already exist
[ http://jira.codehaus.org/browse/MRM-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-388 started by Joakim Erdfelt. > Unable to configure archiva if configuration file did not already exist > --- > > Key: MRM-388 > URL: http://jira.codehaus.org/browse/MRM-388 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-1 >Reporter: Brett Porter >Assignee: Joakim Erdfelt >Priority: Blocker > Fix For: 1.0-alpha-2 > > > - remove archiva configuration and database (first install scenario) > - fill in admin details on startup > - log in > EXPECTED: go to configuration page for repositories > ACTUAL: Archiva goes into an infinite redirect loop trying to access > addRepository!input.action -- 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: (MSANDBOX-3) Rewrite of the maven-jdeveloper-plugin to use classes for IDE like in the Eclipse plugins
[ http://jira.codehaus.org/browse/MSANDBOX-3?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2588 to MSANDBOX-3: -- Fix Version/s: (was: Reviewed Pending Version Assignment) Component/s: (was: IDEs) Complexity: (was: Intermediate) Key: MSANDBOX-3 (was: MNG-2588) Project: Maven 2.x Sandbox (was: Maven 2) > Rewrite of the maven-jdeveloper-plugin to use classes for IDE like in the > Eclipse plugins > - > > Key: MSANDBOX-3 > URL: http://jira.codehaus.org/browse/MSANDBOX-3 > Project: Maven 2.x Sandbox > Issue Type: Improvement >Reporter: Sylvain Deschênes > Attachments: patch.txt > > > Following a discussion on the Maven developer List started by Brett Porter, I > have rewrited the JDeveloper plugin in order to make it use the utility > classes wich are found in the maven eclipse plugin. > I have kept the same idea wich was used by John Fallows. The plugin updates a > blank jdeveloper project with informations coming from the pom and some > additional configuration options. > It still needs some work - some of the original features are still not > implemented. For instance, it doesn't generate a test project, and it only > work with version 10.1.3. > I am planning to continue workint on it but I would like the original > author's feedback 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] Commented: (MSANDBOX-3) Rewrite of the maven-jdeveloper-plugin to use classes for IDE like in the Eclipse plugins
[ http://jira.codehaus.org/browse/MSANDBOX-3?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99796 ] Brett Porter commented on MSANDBOX-3: - suggesting we use the sandbox jira for proposals and sandbox stuff > Rewrite of the maven-jdeveloper-plugin to use classes for IDE like in the > Eclipse plugins > - > > Key: MSANDBOX-3 > URL: http://jira.codehaus.org/browse/MSANDBOX-3 > Project: Maven 2.x Sandbox > Issue Type: Improvement >Reporter: Sylvain Deschênes > Attachments: patch.txt > > > Following a discussion on the Maven developer List started by Brett Porter, I > have rewrited the JDeveloper plugin in order to make it use the utility > classes wich are found in the maven eclipse plugin. > I have kept the same idea wich was used by John Fallows. The plugin updates a > blank jdeveloper project with informations coming from the pom and some > additional configuration options. > It still needs some work - some of the original features are still not > implemented. For instance, it doesn't generate a test project, and it only > work with version 10.1.3. > I am planning to continue workint on it but I would like the original > author's feedback 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] Closed: (MNG-2886) Dynamically includes dependencies if subfolder is available
[
http://jira.codehaus.org/browse/MNG-2886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter closed MNG-2886.
-
Resolution: Won't Fix
Fix Version/s: (was: Reviewed Pending Version Assignment)
setting correct resolution.
Dominick - you can use to exclude sets of modules (you can even do
this based on the existence of a file).
> Dynamically includes dependencies if subfolder is available
> -
>
> Key: MNG-2886
> URL: http://jira.codehaus.org/browse/MNG-2886
> Project: Maven 2
> Issue Type: Improvement
> Components: Reactor and workspace
>Affects Versions: 2.0.5
>Reporter: Dominick More
>
> We would like to use Maven to build our multi-project using the
> construct in a top level pom file. The project contains common libraries and
> war files. Since the war files are not dependent on each other, developers
> are used to exclude all other war project directories out of their SCM load
> configurations to reduce update time. Currently we have implemented ANT in
> such a way that if a project directory is not available at build time it will
> excluded from the build configuration. Since the sub-module pom contains the
> reference to a sibling build configuration anyway the build
> will fail if the dependency cannot be found.
> Currently if a module is defined for which no project exists you get the
> following error:
> E:\Temp\Maven\AXN>mvn install
> [INFO] Scanning for projects...
> [INFO]
>
> [ERROR] FATAL ERROR
> [INFO]
>
> [INFO] Error building POM (may not be this project's POM).
> Project ID: unknown
> Reason: Could not find the model file 'E:\Temp\Maven\AXN\xyz\pom.xml'.
> ...
> On further investigation I located the source of the exception is being
> thrown in the method org.apache.maven.DefaultMaven::collectProjects where the
> modules list added at line 496:
> modulesFiles.add( moduleFile );
> The following change would do the trick...
> if( moduleFile.isFile()) {
> modulesFiles.add( moduleFile );
> }
--
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: (MNG-2791) Error parsing Maven 1 POM file with an extend tag
[ http://jira.codehaus.org/browse/MNG-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter reopened MNG-2791: --- > Error parsing Maven 1 POM file with an extend tag > - > > Key: MNG-2791 > URL: http://jira.codehaus.org/browse/MNG-2791 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 2.1.x > Environment: Maven 2 Eclipse plugin 0.0.10 (latest from SVN) using > the following jars: > lucene-core-2.0.0.jar > maven-embedder-2.1.0.v20070110-2115-dep.jar > Eclipse 3.2 Session Data: > eclipse.buildId=M20060921-0945 > java.version=1.6.0 > java.vendor=Sun Microsystems Inc. > BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=es_ES > Command-line arguments: -os win32 -ws win32 -arch x86 -data c:\workspace > -clean >Reporter: Rodrigo Ruiz > Fix For: Reviewed Pending Version Assignment > > > Trying to rebuild a project that depends on an artifact obtained from a > Maven1 repository, I get the following stacktrace: > org.eclipse.core.runtime.CoreException: Parsing error [whatever].pom; > org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: > 'extend' (position: START_TAG seen ...\n ... @4:11) > at > org.maven.ide.eclipse.embedder.MavenModelManager.readMavenModel(MavenModelManager.java:137) > at > org.maven.ide.eclipse.embedder.ClassPathResolver.getJavaDocUrl(ClassPathResolver.java:241) > at > org.maven.ide.eclipse.embedder.ClassPathResolver.resolveClasspathEntries(ClassPathResolver.java:154) > at > org.maven.ide.eclipse.builder.Maven2Builder.updateClasspath(Maven2Builder.java:95) > at > org.maven.ide.eclipse.builder.Maven2Builder.build(Maven2Builder.java:86) > at > org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:603) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:167) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) > at > org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:230) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:233) > at > org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:252) > at > org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:285) > at > org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:145) > at > org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:208) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) > org.eclipse.core.runtime.CoreException[4]: > org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: > 'extend' (position: START_TAG seen ...\n ... @4:11) > at > org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2405) > at > org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4438) > at > org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4449) > at > org.apache.maven.embedder.MavenEmbedder.readModel(MavenEmbedder.java:208) > at > org.maven.ide.eclipse.embedder.MavenModelManager.readMavenModel(MavenModelManager.java:133) > at > org.maven.ide.eclipse.embedder.ClassPathResolver.getJavaDocUrl(ClassPathResolver.java:241) > at > org.maven.ide.eclipse.embedder.ClassPathResolver.resolveClasspathEntries(ClassPathResolver.java:154) > at > org.maven.ide.eclipse.builder.Maven2Builder.updateClasspath(Maven2Builder.java:95) > at > org.maven.ide.eclipse.builder.Maven2Builder.build(Maven2Builder.java:86) > at > org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:603) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:167) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) > at > org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:230) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:233) > at > org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:252) > at > org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:285) > at > org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:145) > at > org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:208) > at org.eclipse.core.
[jira] Commented: (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:comment-tabpanel#action_99798
]
Joakim Erdfelt commented on MRM-352:
The message for 'externalResult' is expected when redirecting from login to
desired page.
This parameter/property should be filtered out in the Interceptor chain, but
alas, it is not.
It causes no harm, other than filling up the logs quicker.
> 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(CoyoteAda
[jira] Closed: (MNG-2791) Error parsing Maven 1 POM file with an extend tag
[ http://jira.codehaus.org/browse/MNG-2791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter closed MNG-2791. - Resolution: Cannot Reproduce > Error parsing Maven 1 POM file with an extend tag > - > > Key: MNG-2791 > URL: http://jira.codehaus.org/browse/MNG-2791 > Project: Maven 2 > Issue Type: Bug > Components: Embedding >Affects Versions: 2.1.x > Environment: Maven 2 Eclipse plugin 0.0.10 (latest from SVN) using > the following jars: > lucene-core-2.0.0.jar > maven-embedder-2.1.0.v20070110-2115-dep.jar > Eclipse 3.2 Session Data: > eclipse.buildId=M20060921-0945 > java.version=1.6.0 > java.vendor=Sun Microsystems Inc. > BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=es_ES > Command-line arguments: -os win32 -ws win32 -arch x86 -data c:\workspace > -clean >Reporter: Rodrigo Ruiz > Fix For: Reviewed Pending Version Assignment > > > Trying to rebuild a project that depends on an artifact obtained from a > Maven1 repository, I get the following stacktrace: > org.eclipse.core.runtime.CoreException: Parsing error [whatever].pom; > org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: > 'extend' (position: START_TAG seen ...\n ... @4:11) > at > org.maven.ide.eclipse.embedder.MavenModelManager.readMavenModel(MavenModelManager.java:137) > at > org.maven.ide.eclipse.embedder.ClassPathResolver.getJavaDocUrl(ClassPathResolver.java:241) > at > org.maven.ide.eclipse.embedder.ClassPathResolver.resolveClasspathEntries(ClassPathResolver.java:154) > at > org.maven.ide.eclipse.builder.Maven2Builder.updateClasspath(Maven2Builder.java:95) > at > org.maven.ide.eclipse.builder.Maven2Builder.build(Maven2Builder.java:86) > at > org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:603) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:167) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) > at > org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:230) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:233) > at > org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:252) > at > org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:285) > at > org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:145) > at > org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:208) > at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) > org.eclipse.core.runtime.CoreException[4]: > org.codehaus.plexus.util.xml.pull.XmlPullParserException: Unrecognised tag: > 'extend' (position: START_TAG seen ...\n ... @4:11) > at > org.apache.maven.model.io.xpp3.MavenXpp3Reader.parseModel(MavenXpp3Reader.java:2405) > at > org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4438) > at > org.apache.maven.model.io.xpp3.MavenXpp3Reader.read(MavenXpp3Reader.java:4449) > at > org.apache.maven.embedder.MavenEmbedder.readModel(MavenEmbedder.java:208) > at > org.maven.ide.eclipse.embedder.MavenModelManager.readMavenModel(MavenModelManager.java:133) > at > org.maven.ide.eclipse.embedder.ClassPathResolver.getJavaDocUrl(ClassPathResolver.java:241) > at > org.maven.ide.eclipse.embedder.ClassPathResolver.resolveClasspathEntries(ClassPathResolver.java:154) > at > org.maven.ide.eclipse.builder.Maven2Builder.updateClasspath(Maven2Builder.java:95) > at > org.maven.ide.eclipse.builder.Maven2Builder.build(Maven2Builder.java:86) > at > org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:603) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:167) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201) > at > org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:230) > at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) > at > org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:233) > at > org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:252) > at > org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:285) > at > org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:145) > at > org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:208)
[jira] Commented: (MNG-763) consider include source root
[ http://jira.codehaus.org/browse/MNG-763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99799 ] Brett Porter commented on MNG-763: -- we have compile source root, tests source root - we should consider an 'includes' source root. without the quotes I see it's harder to read :) I'm not so sure it's necessary since the native stuff has gotten by without it for some time. > consider include source root > > > Key: MNG-763 > URL: http://jira.codehaus.org/browse/MNG-763 > Project: Maven 2 > Issue Type: New Feature > Components: POM >Reporter: Brett Porter >Priority: Minor > Fix For: 2.1.x > > > this is something used by the native plugin but could be used by several > plugins that deal with C/C++ and maybe other languages. We should consider > adding it to the build section and the MavenProject object. -- 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: (MSANDBOX-4) [maven-maven1-plugin] Tweak the configuration xml syntax
[ http://jira.codehaus.org/browse/MSANDBOX-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2336 to MSANDBOX-4: -- Component/s: (was: Sandbox) Key: MSANDBOX-4 (was: MNG-2336) Project: Maven 2.x Sandbox (was: Maven 2) > [maven-maven1-plugin] Tweak the configuration xml syntax > > > Key: MSANDBOX-4 > URL: http://jira.codehaus.org/browse/MSANDBOX-4 > Project: Maven 2.x Sandbox > Issue Type: Bug >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg >Priority: Minor > Attachments: tweakConfigurationXmlSyntax.patch, > tweakConfigurationXmlSyntax2.patch > > > Changelog: > - The following changes makes the configuration xml elements pretty print > correctly > - Remove AbstractPluginConfigurationConverter.newXpp3Dom() > - Replace all usages of it with plain Xpp3Dom objects instead of using > Xpp3DomBuilder.build(Reader) -- 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: (MSANDBOX-8) [maven-maven1-plugin] Use maven-model-converter instead of bundled class
[ http://jira.codehaus.org/browse/MSANDBOX-8?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2335 to MSANDBOX-8: -- Component/s: (was: Sandbox) Key: MSANDBOX-8 (was: MNG-2335) Project: Maven 2.x Sandbox (was: Maven 2) > [maven-maven1-plugin] Use maven-model-converter instead of bundled class > > > Key: MSANDBOX-8 > URL: http://jira.codehaus.org/browse/MSANDBOX-8 > Project: Maven 2.x Sandbox > Issue Type: Improvement >Reporter: Dennis Lundberg >Assignee: Carlos Sanchez > Attachments: useMavenModelConverter.patch > > > Changelog: > - Move loadV3Pom() and a helper method from PomV3ToV4Converter to the mojo > - Switch from using PomV3ToV4Converter class to using PomV3ToV4Translator > class from maven-model-converter > - Add method to remove DistributionManagement/Status=converted since this pom > is not in the repo > - Remove PomV3ToV4Converter class -- 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: (MSANDBOX-5) [maven-maven1-plugin] Don't add plugins twice
[ http://jira.codehaus.org/browse/MSANDBOX-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2327 to MSANDBOX-5: -- Component/s: (was: Sandbox) Key: MSANDBOX-5 (was: MNG-2327) Project: Maven 2.x Sandbox (was: Maven 2) > [maven-maven1-plugin] Don't add plugins twice > - > > Key: MSANDBOX-5 > URL: http://jira.codehaus.org/browse/MSANDBOX-5 > Project: Maven 2.x Sandbox > Issue Type: Bug >Reporter: Dennis Lundberg >Assignee: Carlos Sanchez > Attachments: dontAddPluginsTwice.patch > > > When using a PluginConfigurationConverter it can sometimes add a plugin that > already exists in the v4 pom. The attached patch makes sure that the pom is > searched for the plugin first, and adds a new one only if the plugin doesn't > already exist. If the plugin already exist, the configuration is added to the > existing plugin. -- 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: (MSANDBOX-7) [maven-maven1-plugin] Expand Compiler and Surefire Converters
[ http://jira.codehaus.org/browse/MSANDBOX-7?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2332 to MSANDBOX-7: -- Component/s: (was: Sandbox) Key: MSANDBOX-7 (was: MNG-2332) Project: Maven 2.x Sandbox (was: Maven 2) > [maven-maven1-plugin] Expand Compiler and Surefire Converters > - > > Key: MSANDBOX-7 > URL: http://jira.codehaus.org/browse/MSANDBOX-7 > Project: Maven 2.x Sandbox > Issue Type: Improvement >Reporter: Dennis Lundberg >Assignee: Carlos Sanchez > Attachments: expandCompilerAndSurefireConverters.patch > > > - Add lots of configuration property conversions to the Compiler and Surefire > PluginConfigurationConverters > - Add a couple of helper methods and a utility class to help with converting > configuration properties > - Add tests for Compiler and Surefire PluginConfigurationConverters > - Add Cobertura report, to monitor test coverage -- 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: (MSANDBOX-6) [maven-maven1-plugin] Allow configuration conversion for reporting plugins
[ http://jira.codehaus.org/browse/MSANDBOX-6?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2338 to MSANDBOX-6: -- Description: (was: Changelog: - Allow the PluginConfigurationConverters to work with report plugins as well as build plugins - Fix two NPEs which occured if the v4 pom didn't include a build section) Component/s: (was: Sandbox) Key: MSANDBOX-6 (was: MNG-2338) Project: Maven 2.x Sandbox (was: Maven 2) > [maven-maven1-plugin] Allow configuration conversion for reporting plugins > -- > > Key: MSANDBOX-6 > URL: http://jira.codehaus.org/browse/MSANDBOX-6 > Project: Maven 2.x Sandbox > Issue Type: New Feature >Reporter: Dennis Lundberg >Assignee: Carlos Sanchez > Attachments: allowReportPlugins.patch > > -- 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: (MSANDBOX-9) [maven-maven1-plugin] Replace bundled v3 model-classes with a dependency on maven-model-v3
[ http://jira.codehaus.org/browse/MSANDBOX-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2320 to MSANDBOX-9: -- Component/s: (was: Sandbox) Key: MSANDBOX-9 (was: MNG-2320) Project: Maven 2.x Sandbox (was: Maven 2) > [maven-maven1-plugin] Replace bundled v3 model-classes with a dependency on > maven-model-v3 > -- > > Key: MSANDBOX-9 > URL: http://jira.codehaus.org/browse/MSANDBOX-9 > Project: Maven 2.x Sandbox > Issue Type: Improvement >Reporter: Dennis Lundberg >Assignee: Carlos Sanchez > Attachments: remove-model-classes.patch > > > This was mentioned by Fabrizio in MNG-1530. He was unable to do it at the > time because of MNG-1436, but this has later been made possible by > MAVENUPLOAD-583. > The attached patch does this: > - adds a dependency on maven-model-v3 > - removes the package "org.apache.maven.model" and everything under it from > this plugin > - adds some ignore props on the root directory -- 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: (MSANDBOX-12) [maven-ejb3-plugin] NPE in EJB3Mojo.java
[ http://jira.codehaus.org/browse/MSANDBOX-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-1690 to MSANDBOX-12: --- Component/s: (was: Sandbox) Key: MSANDBOX-12 (was: MNG-1690) Project: Maven 2.x Sandbox (was: Maven 2) > [maven-ejb3-plugin] NPE in EJB3Mojo.java > > > Key: MSANDBOX-12 > URL: http://jira.codehaus.org/browse/MSANDBOX-12 > Project: Maven 2.x Sandbox > Issue Type: Bug >Reporter: Tim Kettler >Assignee: Stephane Nicoll > Attachments: maven-ejb3-plugin.patch > > > running mvn package fails with: > [INFO] > > [ERROR] BUILD ERROR > [INFO] > > [INFO] Error assembling EJB3 > [INFO] > > [INFO] Trace > org.apache.maven.lifecycle.LifecycleExecutionException: Error assembling EJB3 > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:544) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:469) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:448) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:301) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:137) > at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:322) > at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) > at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at java.lang.reflect.Method.invoke(Method.java:585) > at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) > at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) > at > org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) > at org.codehaus.classworlds.Launcher.main(Launcher.java:375) > Caused by: org.apache.maven.plugin.MojoExecutionException: Error assembling > EJB3 > at org.apache.maven.plugin.ejb3.Ejb3Mojo.execute(Ejb3Mojo.java:146) > at > org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:412) > at > org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:519) > ... 16 more > Caused by: java.lang.NullPointerException > at org.apache.maven.plugin.ejb3.Ejb3Mojo.execute(Ejb3Mojo.java:136) > ... 18 more > A look at the source shows that the archiver is never initialized. The > attached patch initializes the archiver with a JarArchiver. -- 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: (MSANDBOX-10) Csharp dependencies are not inherited from dependencyManagement
[ http://jira.codehaus.org/browse/MSANDBOX-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2367 to MSANDBOX-10: --- Fix Version/s: (was: Reviewed Pending Version Assignment) Component/s: (was: Sandbox) Key: MSANDBOX-10 (was: MNG-2367) Project: Maven 2.x Sandbox (was: Maven 2) > Csharp dependencies are not inherited from dependencyManagement > --- > > Key: MSANDBOX-10 > URL: http://jira.codehaus.org/browse/MSANDBOX-10 > Project: Maven 2.x Sandbox > Issue Type: Bug > Environment: WIndows XP >Reporter: James Carpenter >Priority: Minor > > Csharp dependencies are not inherited from dependencyManagement. > As I am short on time, I havn't taken the time to figure out the bug. -- 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: (MSANDBOX-11) maven-csharp-source-plugin:process-classes messes up outputDirectory and thereby indirectly messes up release plugin
[ http://jira.codehaus.org/browse/MSANDBOX-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2602 to MSANDBOX-11: --- Fix Version/s: (was: Reviewed Pending Version Assignment) Component/s: (was: Sandbox) Key: MSANDBOX-11 (was: MNG-2602) Project: Maven 2.x Sandbox (was: Maven 2) > maven-csharp-source-plugin:process-classes messes up outputDirectory and > thereby indirectly messes up release plugin > > > Key: MSANDBOX-11 > URL: http://jira.codehaus.org/browse/MSANDBOX-11 > Project: Maven 2.x Sandbox > Issue Type: Bug > Environment: Windows XP >Reporter: James Carpenter >Priority: Critical > > Within the csharp plugins > org.apache.maven.plugins:maven-csharp-source-plugin:process-classes is > registered at the process-classes phase. Within this plugin the execute > method resets the output directory to be that of the actual artifact > (target/dotnet-assembly/somelib.dll) rather than the directory which it was > set to (target/dotnet-assembly). > The short javadoc within > org.apache.maven.plugin.csharp.source.ProcessClassesMojo says: > --- > This Mojo adds the result of the compile to the classpath elements > This is required by the NUnitMojo. > > As it turns out this has very negative side affects. If one tries to run > multiple goals at once (mvn deploy site-deploy), the first goal is very > likely to mess up the effective pom for the following goal. This is what > happens to the release plugin. During release:perform the release plugin > uses the plexus command line tools to run "mvn --no-plugin-updates > --variousOtherFlags deploy site-deploy" within target/checkout. As you might > imagine this really messes things up, such that the site-deploy fails as it > tries to find target/checkout/target/dotnet-assembly/somelib.dll/somelib.dll. > In summary a better way to keep the NUnit plugin happy must be found, as the > current solution is very problematic. -- 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: (MSANDBOX-13) CSharp Plugins-Version overriding and transitive dependencies
[ http://jira.codehaus.org/browse/MSANDBOX-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2527 to MSANDBOX-13: --- Fix Version/s: (was: Reviewed Pending Version Assignment) Component/s: (was: Multiple Language Support) (was: Sandbox) Key: MSANDBOX-13 (was: MNG-2527) Project: Maven 2.x Sandbox (was: Maven 2) > CSharp Plugins-Version overriding and transitive dependencies > - > > Key: MSANDBOX-13 > URL: http://jira.codehaus.org/browse/MSANDBOX-13 > Project: Maven 2.x Sandbox > Issue Type: Bug > Environment: Windows XP >Reporter: James Carpenter > > Further experience with the maven csharp plugins has revealed an interesting > side affect of the current way in which maven built csharp libraries are > used. As mentioned in MNG-2369, the csharp libraries built by maven have the > version number in their name. > Assume the following library heiarchy: A depends upon B which depends upon C > (A->B->C). > Lets assume the initial versioned dependencies are as follows: > A_1.0 (explict dependency upon B_1.0) > B_1.0 (explict dependency upon C_1.0) > C_1.0 > Now lets assume C has changed to add some new feature needed by a new version > of A. Lets assume that although A needs the new feature of C, the interfaces > from C used B have not changed and hence no code changes are necessary to B. > So we now try (Will not work with CSharp even though Java code would be fine): > A_2.0 (explict dependency upon B_1.0, and C_2.0) Note: 2.0 version of C > superceeds 1.0 in typical mvn fashion > B_1.0 (explict dependency upon C_1.0) > C_2.0 > This new configuration fails when the unit tests for A_2.0 are run. When the > unit tests in A_2.0 are run we see that B_1.0 is looking for C_1.0 which > doesn't exist as C_2.0 has taken its place in the dependency list. Remember > that B_1.0 is looking for C_1.0 because the assembly meta-data in B_1.0 says > it needs an assembly named C_1.0.dll. > If none of the assemblies are strongly-named (assembly meta-data contains > digital signatures for each dependency) it would be sufficient if the > dependencies within the assembly meta-data didn't contain the version > numbers. (Such a change would have synergies with whatever was done for 3rd > party libraries.) > Alternatively, I think one can probably include all versions mentioned by any > of the dependencies. In this case it is important to maintain version > numbers as part of the dependency names as doing so allows them to co-exist > in the same directory. (Could be problematic for 3rd party dlls without > version numbers in their name.) > All of the above solutions require a change to the csharp maven support in > some fashion. The only solution available today is to create a new release > of B which uses the newer version of C. > A_2.0 (explict dependency upon B_2.0) > B_2.0 (explict dependency upon C_2.0) > C_2.0 > The inability to override versions is both an advantage and disadvantage. As > you can see there the advantage to the current solution is that B is now > known to work with C_2.0. The disadvantage is one must re-release B just to > get the updated C version. > Summary: Version overriding with CSharp dependencies doesn't work out. A > general solution to the problem is either impossible or at least awkward. > The issue stems from the decision by MS to support digitally signed > libraries, and the particulars of the current mvn csharp plugin behavior. -- 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: (MINVOKER-5) [maven-invoker-plugin] build.log file should not be placed inside the target/ directory
[
http://jira.codehaus.org/browse/MINVOKER-5?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter moved MNG-2587 to MINVOKER-5:
--
Component/s: (was: Sandbox)
Complexity: (was: Intermediate)
Key: MINVOKER-5 (was: MNG-2587)
Project: Maven 2.x Invoker Plugin (was: Maven 2)
> [maven-invoker-plugin] build.log file should not be placed inside the target/
> directory
> ---
>
> Key: MINVOKER-5
> URL: http://jira.codehaus.org/browse/MINVOKER-5
> Project: Maven 2.x Invoker Plugin
> Issue Type: Bug
>Reporter: Vincent Massol
>Assignee: Vincent Massol
>
> The invoker plugin creates the build.log file in target/. However if you have
> the "clean" goal inside the goals.txt file and you're running on windows,
> it'll fail with:
> {noformat}
> [INFO] [INFO]
>
> [INFO] [INFO] Building Maven Clover Plugin Contexts Sample
> [INFO] [INFO]task-segment: [clean, install]
> [INFO] [INFO]
>
> [INFO] [INFO] [clean:clean]
> [INFO] [INFO] Deleting directory
> C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\contexts\target
> [INFO] [INFO]
>
> [INFO] [ERROR] BUILD ERROR
> [INFO] [INFO]
>
> [INFO] [INFO] Failed to delete directory:
> C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\contexts\target.
> Reason: Failed to delete file:
> C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\contexts\target\build.log.
> Reason is unknown.
> [INFO]
> [INFO] [INFO]
>
> [INFO] [DEBUG] Trace
> [INFO] org.apache.maven.lifecycle.LifecycleExecutionException: Failed to
> delete directory:
> C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\contexts\target.
> Reason: Failed to delete file:
> C:\dev\maven\trunks\plugins\maven-clover-plugin\src\it\contexts\target\build.log.
> Reason is unknown.
> {noformat}
> I propose to locate the build.log file in the main directory of the project
> being built.
--
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: (MSANDBOX-14) CSharp plugins don't handle empty sources
[ http://jira.codehaus.org/browse/MSANDBOX-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2371 to MSANDBOX-14: --- Fix Version/s: (was: Reviewed Pending Version Assignment) Component/s: (was: Sandbox) Key: MSANDBOX-14 (was: MNG-2371) Project: Maven 2.x Sandbox (was: Maven 2) > CSharp plugins don't handle empty sources > - > > Key: MSANDBOX-14 > URL: http://jira.codehaus.org/browse/MSANDBOX-14 > Project: Maven 2.x Sandbox > Issue Type: Bug > Environment: Windows XP >Reporter: James Carpenter >Priority: Minor > > The CSharp plugins don't properly handle empty source or test source > directories. One is currently forced to have at least a dummy class and a > dummy test hanging around. (Alternatively, I think you can override the > executions section of the maven-compiler-plugin configuration to only list > directories known to contain at least one class, but this isn't good either.) > I imagine this is a simple bug, but I havn't had time to track it down. -- 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: (MSANDBOX-19) Problem with configuration attribute parameter injection
[ http://jira.codehaus.org/browse/MSANDBOX-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2798 to MSANDBOX-19: --- Fix Version/s: (was: Reviewed Pending Version Assignment) Component/s: (was: Sandbox) Key: MSANDBOX-19 (was: MNG-2798) Project: Maven 2.x Sandbox (was: Maven 2) > Problem with configuration attribute parameter injection > > > Key: MSANDBOX-19 > URL: http://jira.codehaus.org/browse/MSANDBOX-19 > Project: Maven 2.x Sandbox > Issue Type: Bug > Environment: Maven 2.0.4, JDK 1.5 >Reporter: cfoubert > Attachments: Native2AsciiMojo.java > > > The native2ascii MOJO does'nt care about the src configuration attribute > parameter injection, it takes the default value each time... > The injection seems not yet work or still in developpement? -- 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: (MSANDBOX-17) [maven-par-plugin] NPE in ParMojo.java
[ http://jira.codehaus.org/browse/MSANDBOX-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-1691 to MSANDBOX-17: --- Component/s: (was: Sandbox) Key: MSANDBOX-17 (was: MNG-1691) Project: Maven 2.x Sandbox (was: Maven 2) > [maven-par-plugin] NPE in ParMojo.java > -- > > Key: MSANDBOX-17 > URL: http://jira.codehaus.org/browse/MSANDBOX-17 > Project: Maven 2.x Sandbox > Issue Type: Bug >Reporter: Tim Kettler >Assignee: Stephane Nicoll > Attachments: maven-par-plugin.patch > > > Same problem as described in MNG-1690. -- 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: (MSANDBOX-21) New NDoc Plugin for CSharp Code
[ http://jira.codehaus.org/browse/MSANDBOX-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2552 to MSANDBOX-21: --- Description: (was: I have created an ndoc plugin for use with Chris Stevenson's csharp plugins. The new maven-ndoc-plugin can be found in the attached zip file.) Component/s: (was: Sandbox) Key: MSANDBOX-21 (was: MNG-2552) Project: Maven 2.x Sandbox (was: Maven 2) > New NDoc Plugin for CSharp Code > --- > > Key: MSANDBOX-21 > URL: http://jira.codehaus.org/browse/MSANDBOX-21 > Project: Maven 2.x Sandbox > Issue Type: New Feature > Environment: Windows >Reporter: James Carpenter >Assignee: Brett Porter > Attachments: maven-ndoc-plugin-1.0.0-SNAPSHOT.zip, > maven-ndoc-plugin-1.0.3.zip > > -- 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: (MSANDBOX-15) maven-grafo-plugin generates only create 1 node for each artifact eventhough multiple versions exist in edges
[ http://jira.codehaus.org/browse/MSANDBOX-15?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2547 to MSANDBOX-15: --- Affects Version/s: (was: 2.0.4) Fix Version/s: (was: Reviewed Pending Version Assignment) Component/s: (was: Sandbox) Key: MSANDBOX-15 (was: MNG-2547) Project: Maven 2.x Sandbox (was: Maven 2) > maven-grafo-plugin generates only create 1 node for each artifact eventhough > multiple versions exist in edges > - > > Key: MSANDBOX-15 > URL: http://jira.codehaus.org/browse/MSANDBOX-15 > Project: Maven 2.x Sandbox > Issue Type: Bug > Environment: J2SE 1.5 >Reporter: Pin Ngee Koh > Attachments: Grafo.java > > > If the following compile dependencies exist > A-1.0.jar --> B-2.0.jar --> C-3.0.jar --> D-4.0.jar > B-2.0.jar --> D-5.0.jar > Node generated for artifact D is for version 5.0, > while the edges reflects both version - 4.0 and 5.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MSANDBOX-22) DependencyVisitor bug fix & more tests
[ http://jira.codehaus.org/browse/MSANDBOX-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2850 to MSANDBOX-22: --- Component/s: (was: Sandbox) Key: MSANDBOX-22 (was: MNG-2850) Project: Maven 2.x Sandbox (was: Maven 2) > DependencyVisitor bug fix & more tests > -- > > Key: MSANDBOX-22 > URL: http://jira.codehaus.org/browse/MSANDBOX-22 > Project: Maven 2.x Sandbox > Issue Type: Improvement >Reporter: Mark Hobson >Assignee: Joakim Erdfelt >Priority: Minor > Attachments: maven-dependency-analyzer.patch > > > o Fixed bug in DependencyVisitor > o Improved test coverage -- 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: (MSANDBOX-16) VStudio Project generated by CSharp VStudio Plugin doesn't support NUnit appropriately
[ http://jira.codehaus.org/browse/MSANDBOX-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2372 to MSANDBOX-16: --- Component/s: (was: Sandbox) Key: MSANDBOX-16 (was: MNG-2372) Project: Maven 2.x Sandbox (was: Maven 2) > VStudio Project generated by CSharp VStudio Plugin doesn't support NUnit > appropriately > -- > > Key: MSANDBOX-16 > URL: http://jira.codehaus.org/browse/MSANDBOX-16 > Project: Maven 2.x Sandbox > Issue Type: Bug > Environment: Windows XP >Reporter: James Carpenter >Assignee: Brett Porter > Attachments: maven-vstudio-plugin.zip > > > The csharp vstudio plugin spins up a csproj file for an individual csharp > maven module. (No multi-module support currently exists.) For some strange > reason the nunit dependencies provided as resources to the VS project, don't > work correctly with the TestDriven VS plugin. > To work around this issue, I extended the vstudio plugin to support the > inclusion of resources specified with an absolute path as well as the ability > to exclude dependencies from the resources included in the generated csproj > file. > The excludedDependencies functionality is more or less what it should be, but > the references tweak is a bit hackish. The reference support should actually > be changed to support subsections for each directory references are coming > from. > == > Example References Suggestion > - > I now have: > > > System.dll > true > > > C:/Program Files/NUnit > 2.2/bin/nunit.core.dll > false > true > > > A better solution would be something like the following: > > > System.dll > true > > > > C:/Program Files/NUnit > 2.2/bin/nunit.core.dll > false > > > > This may not be quite right, but I suspect you get the idea. > === > Background on the Importance of the TestDriven Plugin > > Being the [EMAIL PROTECTED] IDE that it is, MS Visual Studio .NET 2003 > doesn't have built in support for NUnit (in the xUnit family). The > TestDriven VS plugin (http://www.testdriven.net) provides the ability to > right click on an nunit test and run it. One can thereby obtain > functionality similar to the junit support built into IDEA, Eclipse, etc. > = > Differences between my Plugin's POM and the one in the Maven Sandbox > > The attachment below contains my changes. As there is no release version > for the csharp plugins, I have created my own in-house versions simply to > keep them from unknowingly moving under my feet. I strongly suspect the > in-house csharp plugin versions are still identical to that in the maven > plugin sandbox, but I havn't actually checked. My in-house copies were built > from maven SVN copies only a few weeks ago. You will need to change the > version numbers of the plugins in the attached example project. -- 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: (MSANDBOX-23) Dotnet Resources Support (code fix included)
[
http://jira.codehaus.org/browse/MSANDBOX-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter moved MNG-2487 to MSANDBOX-23:
---
Component/s: (was: Sandbox)
Key: MSANDBOX-23 (was: MNG-2487)
Project: Maven 2.x Sandbox (was: Maven 2)
> Dotnet Resources Support (code fix included)
>
>
> Key: MSANDBOX-23
> URL: http://jira.codehaus.org/browse/MSANDBOX-23
> Project: Maven 2.x Sandbox
> Issue Type: Improvement
> Environment: Windows XP
>Reporter: James Carpenter
>Assignee: Brett Porter
> Attachments: masterzip.zip
>
>
> The csharp plugins (currently in the sandbox) do not properly support csharp
> resources. It turns out that solving the problem requires changing several
> of the standard plugins. To resolve the problem I have made a few small
> changes to the following code:
> 1) Created the maven-dotnet-resources-plugin.
> >This plugin is a clone of the standard resources plugin. The only real
> change is to change the expression used in computing the output directory
> >within the @parameter tag of the Mojos. The output directory of the
> maven-dotnet-resources-plugin points at a temporary directory down in
> >the target.
> >@parameter
> expression="${project.build.directory}/csharp-workarea/dotnet-resources-plugin/resources"
>
> >for the DotNetResourcesMojo, similar for the DotNetTestResourcesMojo
> >This is the same expression used for the filteredResourcesDirectory
> instance variable in the modified maven-compiler-plugin.
> >Upon inspection the reader will soon realize the standard and dotnet
> resources plugins should be somehow refactored so as to avoid
> >the gross copy/paste reuse.
> 2) maven-compiler-plugin
> >Added filteredResourcesDirectory and TestResourcesDirectory to the
> CompilerMojo and TestCompilerMojo respectively. This is used to add a
> resourceDir custom compiler configuration whenver the attributes point to
> actual directories.
> 3) plexus-compiler-csharp
> >Added code to leverage the resourceDir compiler argument now being
> passed down by the maven-compiler-plugin.
> 4) Modified the maven-csharp-lifecycle plugin
> >Changed META-INF/plexus/components.xml so as to replace
> maven-resources-plugin with maven-dotnet-resources-plugin
>
>
> Description from new maven-dotnet-resources-plugin (explains the overall
> motivation):
> The maven dotnet resources plugin is almost identical to the standard
> resources plugin. The only difference is the result of
> the resources and testResources goals are copied into special workarea
> directories under target. Unlike javac which produces
> a directory of class files which are typically archived in jar format by the
> jar tool after javac has run, the csc (C# compiler) directly
> produces an archive (a dll containing the dotnet assembly). Consequently,
> csc must be passed each resource using the resource option. The
> csharp compiler plugin and this plugin therefore collaborate. This dotnet
> resources plugin places the resources in a temporary workarea under target
> and the csharp compiler plugin produces resource option arguments to csc for
> every file found there. You will notice all the filter support available in
> the standard resources plugin is also available in the dotnet resources
> plugin.
> =
> The attached maven-csharp plugins are currently set to SNAPSHOT as I havn't
> yet created a new inhouse release for them. I'll probably do this as soon as
> I finish this jira issue.
> =
> The attached zip file contains relevant patch files along with complete zips
> of the code. You will notice the csharp plugins are slightly improved from
> what is currently in the sandbox. To my knowledge the development of the
> sandboxed csharp plugins is rather stagnated. There is probably enough code
> here to bring the csharp plugins to an alpha release. I would much prefer to
> be using officially released versions rather than having to maintain my own.
> I am happy to have a half hour phone conversation with maven developer with
> commit priviledges who can make this happen.
--
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: (MSANDBOX-18) maven-plugin-testing-tools: ProjectToolTest.testPackageProjectArtifact_ShouldPopulateArtifactFileWithJarLocation fails on Windows
[ http://jira.codehaus.org/browse/MSANDBOX-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2697 to MSANDBOX-18: --- Component/s: (was: Sandbox) Key: MSANDBOX-18 (was: MNG-2697) Project: Maven 2.x Sandbox (was: Maven 2) > maven-plugin-testing-tools: > ProjectToolTest.testPackageProjectArtifact_ShouldPopulateArtifactFileWithJarLocation > fails on Windows > - > > Key: MSANDBOX-18 > URL: http://jira.codehaus.org/browse/MSANDBOX-18 > Project: Maven 2.x Sandbox > Issue Type: Bug > Environment: Windows XP >Reporter: Barrie Treloar >Assignee: John Casey >Priority: Critical > Attachments: MNG-2697-patch.txt > > > File.getPath() can not be used as a comparison with a string because of the / > vs \ problem. > Attached patch, replaces this check with one against 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] Moved: (MSANDBOX-20) maven-it-plugin doesn't work with plugins leveraging CSharp dependencies
[ http://jira.codehaus.org/browse/MSANDBOX-20?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2370 to MSANDBOX-20: --- Fix Version/s: (was: Reviewed Pending Version Assignment) Component/s: (was: Sandbox) Key: MSANDBOX-20 (was: MNG-2370) Project: Maven 2.x Sandbox (was: Maven 2) > maven-it-plugin doesn't work with plugins leveraging CSharp dependencies > > > Key: MSANDBOX-20 > URL: http://jira.codehaus.org/browse/MSANDBOX-20 > Project: Maven 2.x Sandbox > Issue Type: Bug > Environment: Windows XP >Reporter: James Carpenter >Priority: Minor > Attachments: dotnet-dummy-plugin.zip > > > The maven-it-plugin doesn't work correctly when the integration test project > is a csharp build. I'm not sure why this is the case. > The attachment below demonstrates the problematic behavior. As there is no > release version for the csharp plugins, I have created my own in-house > versions simply to keep them from unknowingly moving under my feet. I'm > strongly suspect the in-house csharp plugin versions are still identical to > that in the maven plugin sandbox, but I havn't actually checked. My in-house > copies were built from maven SVN copies only a few weeks ago. You will need > to change the version numbers of the plugins in the attached example project. -- 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: (MSANDBOX-26) Generic 3rd Party DotNet Libraries not appropriately handled
[ http://jira.codehaus.org/browse/MSANDBOX-26?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2369 to MSANDBOX-26: --- Fix Version/s: (was: 2.2.x) Component/s: (was: Multiple Language Support) (was: Sandbox) Key: MSANDBOX-26 (was: MNG-2369) Project: Maven 2.x Sandbox (was: Maven 2) > Generic 3rd Party DotNet Libraries not appropriately handled > > > Key: MSANDBOX-26 > URL: http://jira.codehaus.org/browse/MSANDBOX-26 > Project: Maven 2.x Sandbox > Issue Type: Improvement > Environment: Windows XP >Reporter: James Carpenter > > The csharp plugins work great when using .Net dependencies built with the > csharp plugins, but don't work in the general case. > Problem Statement: > (Note: As a Java developer, I might mess this up a bit.) > A .NET assembly contains a manifest which lists the assemblies it depends > upon. In addition to checking digital signatures for public assemblies, the > classloader (whatever MS calls it) expects the filenames of the dependencies > to match that described in the manifest. The problem is the maven repository > structure imposes a particular naming convention upon the artifacts placed > within it. So you can't just take a third party dll change its name to fit > into the maven repo artifact naming convention and create an associated POM. > Artifacts built by maven using the csharp plugins match the maven repo > artifact naming conventions and the assembly manifests contain dependencies > whose names are consistent with the maven repo artifact naming conventions. > Tatical Solution: > The nasty tatical solution I am currently using, is to simple refer to any > 3rd party dlls as system dependencies. (system) > Potential Strategic Solution: > I believe the solution is to create another maven artifact type to support > 3rd party dlls. The artifact actually stored in the maven repo should be an > archieve of some sort (jar, zip, etc.). During the process-resources (some > phase prior to compilation, might need custom lifecycle) phase these 3rd > party dependencies would be downloaded by the ArtifactResolver and > unarchieved in some directory structure which maintains the versioning > through directory naming, but not by file name. The dll filename would be > the same as the original name of the 3rd party dll (most likely > implementation choice is simply to let the archieve maintain the original > name). > When maven builds the classpath, any artifact of this new type would be > represented in the classpath as the path to the unarchieved dll. (The > current csharp compiler plugin sees these as the path to the local repo.) > I believe, it will actually be necessary to produce two new artifact types. > One will be used for "managed" dependencies and another for native > "unmanaged" dependencies. This distinction is important because the csc (C# > compiler) only wants to know about "managed" dependencies. (See as /resource > arguments to csc compiler. Refer to plexus csharp compiler code for details.) > I'm not sure my proposed solution is 100% accurate, as I still don't know the > maven internals that well, but I think its close. -- 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: (MSANDBOX-27) APT & AspectJ plugins
[ http://jira.codehaus.org/browse/MSANDBOX-27?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MNG-2089 to MSANDBOX-27: --- Description: (was: We have prototypes of AspectJ & APT plugins ready. Can you put it into the Sanbox? Thanx. best regards J.Burian) Affects Version/s: (was: 2.0.3) Component/s: (was: Sandbox) Key: MSANDBOX-27 (was: MNG-2089) Project: Maven 2.x Sandbox (was: Maven 2) > APT & AspectJ plugins > - > > Key: MSANDBOX-27 > URL: http://jira.codehaus.org/browse/MSANDBOX-27 > Project: Maven 2.x Sandbox > Issue Type: Wish >Reporter: Juraj Burian >Priority: Minor > Attachments: APTexamplePrj.zip, plugins.zip > > -- 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: (MSANDBOX-25) CSharp plugins don't support test-jar equivalent
[
http://jira.codehaus.org/browse/MSANDBOX-25?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter moved MNG-2505 to MSANDBOX-25:
---
Fix Version/s: (was: Reviewed Pending Version Assignment)
Component/s: (was: Sandbox)
Key: MSANDBOX-25 (was: MNG-2505)
Project: Maven 2.x Sandbox (was: Maven 2)
> CSharp plugins don't support test-jar equivalent
>
>
> Key: MSANDBOX-25
> URL: http://jira.codehaus.org/browse/MSANDBOX-25
> Project: Maven 2.x Sandbox
> Issue Type: Improvement
> Environment: Windows XP
>Reporter: James Carpenter
>Priority: Minor
>
> Although the csharp plugins support nunit tests, they don't provide a
> mechanism to include these as attached artifacts. This is of course
> inconvenient when one wants to share some shared test utilities, etc.
> I tried to quickly hack around the situation with the following in my pom:
>
>
>
> org.codehaus.mojo
> build-helper-maven-plugin
>
>
> attach-artifacts
> package
>
> attach-artifact
>
>
>
>
>
> ${project.build.directory}/test-dotnet-assembly/unit-tests.dll
> dotnet-library
> unit-tests
>
>
>
>
>
>
>
>
> Unfortunately, this doesn't work out. I haven't spent any more time looking
> at the issue. This is a fairly low priority issue, I post it just to be able
> to keep track.
--
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: (MSANDBOX-24) Extended maven-nunit-plugin to support systemProperties configuration
[
http://jira.codehaus.org/browse/MSANDBOX-24?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter moved MNG-2403 to MSANDBOX-24:
---
Component/s: (was: Sandbox)
Key: MSANDBOX-24 (was: MNG-2403)
Project: Maven 2.x Sandbox (was: Maven 2)
> Extended maven-nunit-plugin to support systemProperties configuration
> -
>
> Key: MSANDBOX-24
> URL: http://jira.codehaus.org/browse/MSANDBOX-24
> Project: Maven 2.x Sandbox
> Issue Type: Improvement
> Environment: Windows XP
>Reporter: James Carpenter
>Assignee: Brett Porter
> Attachments: maven-nunit-plugin-1.3.1.jpm-sources.jar
>
>
> h3. Summary
> I have extended the maven-nunit-plugin to support the use of
> systemProperties. Unfortunately, as I am working from an in-house copy I
> can't easily make a patch file for you.
> h3. Significant Changes
> 1) Addition of new Properties class.
> 2) Several small changes within the NUnitEnvironment and NUnitMojo classes.
> 3) Upgrading org.codehaus.plexus:plexus-utils from version 1.0.4 to version
> 1.1 (necessary to gain some enhancements to the plexus Commandline class)
> h3. Unrelated Changes
> 1) Somewhat different POM inheritance since I'm using an in-house version.
> If you take the changes above, everything should work out.
> h3. Motivation
> By combining this change to the maven-nunit-plugin with my change to the
> maven-exec-plugin (See [MEXEC-4|http://jira.codehaus.org/browse/MEXEC-4]) its
> possible to create a cross-language integration test.
> My C# based NUnit test can use the .NET Process class to execute "mvn
> exec:java" as part of a \[TestFrameworkSetUp\] annotated method in an nunit
> test. The exec:java goal within the C# code's POM just so happens to start
> up a java based server. (I actually have a little C# utility class to make
> this easy.) The nunit test methods can then perform integration tests
> requiring communication with the java server process. Upon completion of the
> tests a \[TestFrameworkTearDown\] annotated method in the nunit test can shut
> down the server process.
> h3. Example POM Snipt
> {noformat}
>
> org.apache.maven.plugins
> maven-nunit-plugin
> 1.3.1.jpm
>
>
>
>
>
> basedir
> ${basedir}
>
>
>
>
>
> {noformat}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Moved: (MONE-9) [maven-maven1-plugin] Don't add plugins twice
[ http://jira.codehaus.org/browse/MONE-9?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MSANDBOX-5 to MONE-9: Key: MONE-9 (was: MSANDBOX-5) Project: Maven 2.x One Plugin (was: Maven 2.x Sandbox) > [maven-maven1-plugin] Don't add plugins twice > - > > Key: MONE-9 > URL: http://jira.codehaus.org/browse/MONE-9 > Project: Maven 2.x One Plugin > Issue Type: Bug >Reporter: Dennis Lundberg >Assignee: Carlos Sanchez > Attachments: dontAddPluginsTwice.patch > > > When using a PluginConfigurationConverter it can sometimes add a plugin that > already exists in the v4 pom. The attached patch makes sure that the pom is > searched for the plugin first, and adds a new one only if the plugin doesn't > already exist. If the plugin already exist, the configuration is added to the > existing plugin. -- 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: (MONE-10) [maven-maven1-plugin] Tweak the configuration xml syntax
[ http://jira.codehaus.org/browse/MONE-10?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MSANDBOX-4 to MONE-10: - Key: MONE-10 (was: MSANDBOX-4) Project: Maven 2.x One Plugin (was: Maven 2.x Sandbox) > [maven-maven1-plugin] Tweak the configuration xml syntax > > > Key: MONE-10 > URL: http://jira.codehaus.org/browse/MONE-10 > Project: Maven 2.x One Plugin > Issue Type: Bug >Reporter: Dennis Lundberg >Assignee: Dennis Lundberg >Priority: Minor > Attachments: tweakConfigurationXmlSyntax.patch, > tweakConfigurationXmlSyntax2.patch > > > Changelog: > - The following changes makes the configuration xml elements pretty print > correctly > - Remove AbstractPluginConfigurationConverter.newXpp3Dom() > - Replace all usages of it with plain Xpp3Dom objects instead of using > Xpp3DomBuilder.build(Reader) -- 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: (MONE-11) [maven-maven1-plugin] Allow configuration conversion for reporting plugins
[ http://jira.codehaus.org/browse/MONE-11?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MSANDBOX-6 to MONE-11: - Key: MONE-11 (was: MSANDBOX-6) Project: Maven 2.x One Plugin (was: Maven 2.x Sandbox) > [maven-maven1-plugin] Allow configuration conversion for reporting plugins > -- > > Key: MONE-11 > URL: http://jira.codehaus.org/browse/MONE-11 > Project: Maven 2.x One Plugin > Issue Type: New Feature >Reporter: Dennis Lundberg >Assignee: Carlos Sanchez > Attachments: allowReportPlugins.patch > > -- 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: (MONE-12) [maven-maven1-plugin] Expand Compiler and Surefire Converters
[ http://jira.codehaus.org/browse/MONE-12?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MSANDBOX-7 to MONE-12: - Key: MONE-12 (was: MSANDBOX-7) Project: Maven 2.x One Plugin (was: Maven 2.x Sandbox) > [maven-maven1-plugin] Expand Compiler and Surefire Converters > - > > Key: MONE-12 > URL: http://jira.codehaus.org/browse/MONE-12 > Project: Maven 2.x One Plugin > Issue Type: Improvement >Reporter: Dennis Lundberg >Assignee: Carlos Sanchez > Attachments: expandCompilerAndSurefireConverters.patch > > > - Add lots of configuration property conversions to the Compiler and Surefire > PluginConfigurationConverters > - Add a couple of helper methods and a utility class to help with converting > configuration properties > - Add tests for Compiler and Surefire PluginConfigurationConverters > - Add Cobertura report, to monitor test coverage -- 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: (MONE-13) [maven-maven1-plugin] Use maven-model-converter instead of bundled class
[ http://jira.codehaus.org/browse/MONE-13?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MSANDBOX-8 to MONE-13: - Key: MONE-13 (was: MSANDBOX-8) Project: Maven 2.x One Plugin (was: Maven 2.x Sandbox) > [maven-maven1-plugin] Use maven-model-converter instead of bundled class > > > Key: MONE-13 > URL: http://jira.codehaus.org/browse/MONE-13 > Project: Maven 2.x One Plugin > Issue Type: Improvement >Reporter: Dennis Lundberg >Assignee: Carlos Sanchez > Attachments: useMavenModelConverter.patch > > > Changelog: > - Move loadV3Pom() and a helper method from PomV3ToV4Converter to the mojo > - Switch from using PomV3ToV4Converter class to using PomV3ToV4Translator > class from maven-model-converter > - Add method to remove DistributionManagement/Status=converted since this pom > is not in the repo > - Remove PomV3ToV4Converter class -- 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: (MONE-14) [maven-maven1-plugin] Replace bundled v3 model-classes with a dependency on maven-model-v3
[ http://jira.codehaus.org/browse/MONE-14?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter moved MSANDBOX-9 to MONE-14: - Key: MONE-14 (was: MSANDBOX-9) Project: Maven 2.x One Plugin (was: Maven 2.x Sandbox) > [maven-maven1-plugin] Replace bundled v3 model-classes with a dependency on > maven-model-v3 > -- > > Key: MONE-14 > URL: http://jira.codehaus.org/browse/MONE-14 > Project: Maven 2.x One Plugin > Issue Type: Improvement >Reporter: Dennis Lundberg >Assignee: Carlos Sanchez > Attachments: remove-model-classes.patch > > > This was mentioned by Fabrizio in MNG-1530. He was unable to do it at the > time because of MNG-1436, but this has later been made possible by > MAVENUPLOAD-583. > The attached patch does this: > - adds a dependency on maven-model-v3 > - removes the package "org.apache.maven.model" and everything under it from > this plugin > - adds some ignore props on the root directory -- 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-311) incorrectly displayed groupId for dependencies
[
http://jira.codehaus.org/browse/MRM-311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Joakim Erdfelt closed MRM-311.
--
Assignee: Joakim Erdfelt
Resolution: Fixed
Fixed in trunk
> incorrectly displayed groupId for dependencies
> --
>
> Key: MRM-311
> URL: http://jira.codehaus.org/browse/MRM-311
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0-alpha-1
>Reporter: Petr Kozelka
>Assignee: Joakim Erdfelt
> Fix For: 1.0-alpha-2
>
>
> the list in the "Dependencies" tab contains correct artifacts, but with
> groupId taken from the library being explored, not from the dependency itself.
> Example:
> library {{org.hibernate:hibernate:3.2.1.ga}} depends on
> - {{*net.sf.ehcache*:ehcache:1.2.3}}
> - {{*javax.transaction*:jta:1.0.1B}}
> - etc
> but the page displays this information:
> - {{{color:red}org.hibernate{color}:ehcache:1.2.3}}
> - {{{color:red}org.hibernate{color}:jta:1.0.1B}}
> - etc
> The same bug appears on tabs "*Dependency tree*" and "*Used by*".
--
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-388) Unable to configure archiva if configuration file did not already exist
[ http://jira.codehaus.org/browse/MRM-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-388. -- Resolution: Fixed Fixed in trunk > Unable to configure archiva if configuration file did not already exist > --- > > Key: MRM-388 > URL: http://jira.codehaus.org/browse/MRM-388 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0-alpha-1 >Reporter: Brett Porter >Assignee: Joakim Erdfelt >Priority: Blocker > Fix For: 1.0-alpha-2 > > > - remove archiva configuration and database (first install scenario) > - fill in admin details on startup > - log in > EXPECTED: go to configuration page for repositories > ACTUAL: Archiva goes into an infinite redirect loop trying to access > addRepository!input.action -- 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-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:comment-tabpanel#action_99802
]
Joakim Erdfelt commented on MRM-352:
The admin add repository page does not show up anymore, as the repositories are
defaulted now.
Something here will have to change.
Some ideas.
# The list of default repositories should not be created
# A default repository is bundled with archiva standalone.
#* maybe with just wagon-webdav (+ deps) in it.
What do you think? (I like option #2)
> 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
[jira] Commented: (MRM-234) Moving files between repos through webdav doesn't work
[ http://jira.codehaus.org/browse/MRM-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99803 ] Joakim Erdfelt commented on MRM-234: The biggest concern in implementing solution #2 is the security aspect. This would mean the webdav impl is now aware of redback and archiva itself. (unless we do some smoke and mirrors on the incoming HttpServletRequest before the webdav impl gets it) Supporting the WebDav MOVE operation is going to be tricky. > Moving files between repos through webdav doesn't work > -- > > Key: MRM-234 > URL: http://jira.codehaus.org/browse/MRM-234 > Project: Archiva > Issue Type: Bug > Components: repository interface >Affects Versions: 1.0 >Reporter: Carlos Sanchez > Fix For: 1.0-alpha-2 > > Attachments: client.log, server.log, webdav-0.5-dev.jar > > > The goal is to move files from one repo to another through the webdav > interface, using a webdav client, like Windows My Network Places or BitKinex > Two repos where created and accessed with username/password > http://localhost:8092/repository/repo1 > http://localhost:8092/repository/repo2 > Copying from one to another fails. > Copying from any other webdav server to them works > Copying from them to any other webdav server works > Copying from local to them and from them to local of course works > I tried with latest svn code from could.it which includes this MOVE > improvement http://issues.apache.org/jira/browse/HADOOP-505 that makes a real > move and not a copy+delete -- 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-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:comment-tabpanel#action_99805
]
Joakim Erdfelt commented on MRM-352:
The errors and whatnot have been fixed on trunk.
We should create a new jira about the 'add repository' process in light of the
configuration upgrade phase.
> 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(Http11Proc
[jira] Commented: (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:comment-tabpanel#action_99804
]
Brett Porter commented on MRM-352:
--
I like what we have now, where the default repository is created from scratch,
automatically, outside the installation. So I'd say just remove the bit that
fires up that page on startup.
> 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.Http11P
[jira] Closed: (MRM-362) [Admin / Repositories] Fix "Index Repository" link.
[ http://jira.codehaus.org/browse/MRM-362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-362. -- Assignee: Joakim Erdfelt Resolution: Fixed Fixed in trunk > [Admin / Repositories] Fix "Index Repository" link. > --- > > Key: MRM-362 > URL: http://jira.codehaus.org/browse/MRM-362 > Project: Archiva > Issue Type: Bug > Components: design >Affects Versions: 1.0-alpha-1 >Reporter: Joakim Erdfelt >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-2 > > > Tasks to do about "Index Repository" link on repositories page. > * Move Link to left hand side. - done > * Make into button. - done > * Rename to "Scan Repository Now" - done > Remaining is new functionality, perhaps add status field to repositories to > allow different actions to set statuses on a particular repository for > conditionally wrapping the Scan Repository Now button. > * Add verbiage to repository screen to show if a scan is in progress. -- 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-340) release:prepare fails due to missing archiva-applet
[ http://jira.codehaus.org/browse/MRM-340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-340. -- Assignee: Joakim Erdfelt Resolution: Fixed Fixed in trunk. > release:prepare fails due to missing archiva-applet > --- > > Key: MRM-340 > URL: http://jira.codehaus.org/browse/MRM-340 > Project: Archiva > Issue Type: Bug > Components: build >Affects Versions: 1.0-alpha-1 >Reporter: Wendy Smoak >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-2 > > > During release:prepare, the build fails with: > [INFO] Building Archiva Web Application > [INFO]task-segment: [clean, integration-test] > ... > [ERROR] BUILD ERROR > [INFO] > > [INFO] Failed to resolve artifact. > GroupId: org.apache.maven.archiva > ArtifactId: archiva-applet > Version: 0.9-alpha-2 > Reason: Unable to download the artifact from any repository > Try downloading the file manually from the project website. > Then, install it using the command: > mvn install:install-file -DgroupId=org.apache.maven.archiva > -DartifactId=archiva-applet > -Dversion=0.9-alpha-2 -Dpackaging=jar -Dfile=/path/to/file > org.apache.maven.archiva:archiva-applet:jar:0.9-alpha-2 -- 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-225) Forced password complexity
[ http://jira.codehaus.org/browse/MRM-225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-225. -- Resolution: Won't Fix Closing as "Wont Fix" Agreement on "default values" cannot be met. (Everyone has a different view on what is considered default. Having the restrictions in place lets people know that are restrictions.) Documentation on how to change the defaults exist at http://maven.apache.org/archiva/guides/security-configuration.html > Forced password complexity > -- > > Key: MRM-225 > URL: http://jira.codehaus.org/browse/MRM-225 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.0 > Environment: tomcat 5.5.x, jdk 5, suse >Reporter: Brill Pappin > Fix For: 1.0-alpha-2 > > > Archiva should not enforce complexity when setting passwords. > If the feature is kept it should be an option turned off be default. > The problem is that it conflicts with other complexity policies external to > Archiva. -- 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-229) Do not limit administrator password length
[ http://jira.codehaus.org/browse/MRM-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-229. -- Assignee: Joakim Erdfelt Resolution: Won't Fix Closing as "Wont Fix" Agreement on "default values" cannot be met. (Everyone has a different view on what is considered default. Having the restrictions in place lets people know that are restrictions.) Documentation on how to change the defaults exist at http://maven.apache.org/archiva/guides/security-configuration.html > Do not limit administrator password length > -- > > Key: MRM-229 > URL: http://jira.codehaus.org/browse/MRM-229 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.0 >Reporter: Brill Pappin >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-2 > > > Getting a message "You must provide a password between 1 and 8 characters in > length" with a password that looks like "aa###" (where "a" is a letter > and "#" is a number).. > The passwords should not be limited in length. -- 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-290) Ability to pre-configure the Jetty port in conf/plexus.xml
[ http://jira.codehaus.org/browse/MRM-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak updated MRM-290: Description: When using the plexus runtime, in order to change the http port : the application must be started (in order to be extracted), stopped. Then configuration file can be changed. With this patch the jetty port can be set before the first start. Same as CONTINUUM-1184. was:same description as CONTINUUM-1184. Summary: Ability to pre-configure the Jetty port in conf/plexus.xml (was: using plexus-contextualizer to setup port in jetty) original summary: using plexus-contextualizer to setup port in jetty > Ability to pre-configure the Jetty port in conf/plexus.xml > -- > > Key: MRM-290 > URL: http://jira.codehaus.org/browse/MRM-290 > Project: Archiva > Issue Type: Improvement >Affects Versions: 1.0-alpha-1 >Reporter: Olivier Lamy > Fix For: Future > > Attachments: MRM-290 > > > When using the plexus runtime, in order to change the http port : the > application must be started (in order to be extracted), stopped. > Then configuration file can be changed. With this patch the jetty port can > be set before the first start. > Same as CONTINUUM-1184. -- 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-1315) changefile name should not be limited to 256 characters
changefile name should not be limited to 256 characters --- Key: CONTINUUM-1315 URL: http://jira.codehaus.org/browse/CONTINUUM-1315 Project: Continuum Issue Type: Bug Components: Database Affects Versions: 1.1-alpha-2 Reporter: Brett Porter results in this type of exception: javax.jdo.JDOFatalUserException: Attempt to store value "/maven/archiva/trunk/archiva-database/src/main/java/org/apache/maven/archiva/database/project/DatabaseProjectModelResolver.java (from /maven/archiva/trunk/archiva-base/archiva-consumers/archiva-database-consumers/src/main/java/org/apache/maven/archiva/consumers/database/project/DatabaseProjectModelResolver.java:547276)" in column ""NAME"" that has maximum length of 256. Please correct your data! -- 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-1293) Hitting 'Add' button repetitively in adding an Ant, Shell and Schedule using empty string only accumulates validation prompts
[ http://jira.codehaus.org/browse/CONTINUUM-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99811 ] Brett Porter commented on CONTINUUM-1293: - this should be opened as a new issue if it was fixed in alpha-2, but there is an additional fix to be made. You shouldn't reopen things in an old version. > Hitting 'Add' button repetitively in adding an Ant, Shell and Schedule using > empty string only accumulates validation prompts > -- > > Key: CONTINUUM-1293 > URL: http://jira.codehaus.org/browse/CONTINUUM-1293 > Project: Continuum > Issue Type: Bug > Components: Web - UI > Environment: firefox 2 >Reporter: jan ancajas >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1-alpha-2 > > Attachments: CONTINUUM-1293-continuum-webapp (part 2).patch, > CONTINUUM-1293-continuum-webapp.patch > > -- 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-1316) Hitting 'Add' button repetitively in adding an Ant, Shell and Schedule using empty string only accumulates validation prompts in IE browser
Hitting 'Add' button repetitively in adding an Ant, Shell and Schedule using empty string only accumulates validation prompts in IE browser --- Key: CONTINUUM-1316 URL: http://jira.codehaus.org/browse/CONTINUUM-1316 Project: Continuum Issue Type: Bug Components: Web - UI Affects Versions: 1.1-alpha-3 Environment: windows XP, IE Reporter: jan ancajas Priority: Minor -- 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-1293) Hitting 'Add' button repetitively in adding an Ant, Shell and Schedule using empty string only accumulates validation prompts
[ http://jira.codehaus.org/browse/CONTINUUM-1293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jan ancajas closed CONTINUUM-1293. -- Resolution: Fixed sorry about that. ^_^ created new issue: CONTINUUM-1316 > Hitting 'Add' button repetitively in adding an Ant, Shell and Schedule using > empty string only accumulates validation prompts > -- > > Key: CONTINUUM-1293 > URL: http://jira.codehaus.org/browse/CONTINUUM-1293 > Project: Continuum > Issue Type: Bug > Components: Web - UI > Environment: firefox 2 >Reporter: jan ancajas >Assignee: Emmanuel Venisse >Priority: Minor > Fix For: 1.1-alpha-2 > > Attachments: CONTINUUM-1293-continuum-webapp (part 2).patch, > CONTINUUM-1293-continuum-webapp.patch > > -- 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-1316) Hitting 'Add' button repetitively in adding an Ant, Shell and Schedule using empty string only accumulates validation prompts in IE browser
[ http://jira.codehaus.org/browse/CONTINUUM-1316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] jan ancajas updated CONTINUUM-1316: --- Attachment: CONTINUUM-1316-continuum-webapp.patch attached patch. :) > Hitting 'Add' button repetitively in adding an Ant, Shell and Schedule using > empty string only accumulates validation prompts in IE browser > --- > > Key: CONTINUUM-1316 > URL: http://jira.codehaus.org/browse/CONTINUUM-1316 > Project: Continuum > Issue Type: Bug > Components: Web - UI >Affects Versions: 1.1-alpha-3 > Environment: windows XP, IE >Reporter: jan ancajas >Priority: Minor > Attachments: CONTINUUM-1316-continuum-webapp.patch > > -- 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: (MRM-229) Do not limit administrator password length
[ http://jira.codehaus.org/browse/MRM-229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brill Pappin reopened MRM-229: -- Setting the issue as "Won't Fix" based on the statement that people can't agree on what minimum values are is completely bogus. 1) This is a team of experienced developers and *sombody* does have the final say to get people in line when no agreement can be reached. 2) When in doubt, err on the side of the user experience; which means you don't limit the values. Most people using it *will not care* and those minority that do can be the ones to go looking though the documentation to find out how to limit it. > Do not limit administrator password length > -- > > Key: MRM-229 > URL: http://jira.codehaus.org/browse/MRM-229 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.0 >Reporter: Brill Pappin >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-2 > > > Getting a message "You must provide a password between 1 and 8 characters in > length" with a password that looks like "aa###" (where "a" is a letter > and "#" is a number).. > The passwords should not be limited in length. -- 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-229) Do not limit administrator password length
[ http://jira.codehaus.org/browse/MRM-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99817 ] Brett Porter commented on MRM-229: -- I suggest someone starts a thread on the dev list about this > Do not limit administrator password length > -- > > Key: MRM-229 > URL: http://jira.codehaus.org/browse/MRM-229 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.0 >Reporter: Brill Pappin >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-2 > > > Getting a message "You must provide a password between 1 and 8 characters in > length" with a password that looks like "aa###" (where "a" is a letter > and "#" is a number).. > The passwords should not be limited in length. -- 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-229) Do not limit administrator password length
[ http://jira.codehaus.org/browse/MRM-229?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99818 ] Wendy Smoak commented on MRM-229: - I agree that an 8 character maximum is too short for the default, but this needs to be changed in Plexus Redback, not in Archiva. > Do not limit administrator password length > -- > > Key: MRM-229 > URL: http://jira.codehaus.org/browse/MRM-229 > Project: Archiva > Issue Type: Improvement > Components: web application >Affects Versions: 1.0 >Reporter: Brill Pappin >Assignee: Joakim Erdfelt > Fix For: 1.0-alpha-2 > > > Getting a message "You must provide a password between 1 and 8 characters in > length" with a password that looks like "aa###" (where "a" is a letter > and "#" is a number).. > The passwords should not be limited in length. -- 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: (MPPMD-19) Java language level not settable through plugin
[
http://jira.codehaus.org/browse/MPPMD-19?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99821
]
dion gillard commented on MPPMD-19:
---
This fix causes the PMD report to fail if maven.compile.source is set to '1.2'
with the following message:
Caused by: The targetjdk attribute, if used, must be set to either '1.3',
'1.4', '1.5', '1.6' or 'jsp'
at net.sourceforge.pmd.ant.PMDTask.validate(PMDTask.java:250)
at net.sourceforge.pmd.ant.PMDTask.execute(PMDTask.java:117)
at org.apache.tools.ant.Task.perform(Task.java:364)
at org.apache.commons.jelly.tags.ant.AntTag.doTag(AntTag.java:195)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:250)
The workaround is to either use the previous version of the plugin or to set
maven.pmd.targetjdk=1.3
> Java language level not settable through plugin
> ---
>
> Key: MPPMD-19
> URL: http://jira.codehaus.org/browse/MPPMD-19
> Project: Maven 1.x PMD Plugin
> Issue Type: New Feature
>Affects Versions: 1.7
> Environment: Windows XP
>Reporter: Wim Deblauwe
>Assignee: Arnaud Heritier
> Fix For: 1.8
>
>
> The maven plugin does not allow setting the language level (1.3, 1.4 or 1.5)
> for PMD. This can be easily fixed by using 'targetjdk' property in the plugin
> script:
> Original plugin.jelly (version 1.7):
>
>
>
>toFile="${maven.build.dir}/pmd-raw-report.xml"/>
>Change:
>
>
> targetjdk="${maven.pmd.targetjdk}>
>toFile="${maven.build.dir}/pmd-raw-report.xml"/>
>By default 'maven.pmd.targetjdk' can be equal to 'maven.compile.source'
> regards,
> Wim
--
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-3059) Allow pom to override plugin dependencies
Allow pom to override plugin dependencies - Key: MNG-3059 URL: http://jira.codehaus.org/browse/MNG-3059 Project: Maven 2 Issue Type: Wish Affects Versions: 2.1 Reporter: Eric Redmond Attachments: maven-core.diff Let win out over a plugin's own dependencies. -- 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: (MPANNOUNCEMENT-21) Plugin causes site to fail during processing of xdoc plugin's downloads.jelly
Plugin causes site to fail during processing of xdoc plugin's downloads.jelly - Key: MPANNOUNCEMENT-21 URL: http://jira.codehaus.org/browse/MPANNOUNCEMENT-21 Project: Maven 1.x Announcement Plugin Issue Type: Bug Affects Versions: 1.4.1 Environment: Windows XP, Maven 1.1-RC1, Plugin version 1.4.2 Reporter: dion gillard Priority: Critical The xdoc plugin calls during it's generation of reports from the POM. This causes announcement:check-version to run and fail, if a project has a currentVersion not listed in the versions stanza. This is very common, especially with x.y-SNAPSHOT as the currentVersion. -- 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: (MPANNOUNCEMENT-21) Plugin causes site to fail during processing of xdoc plugin's downloads.jelly
[ http://jira.codehaus.org/browse/MPANNOUNCEMENT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl closed MPANNOUNCEMENT-21. --- Assignee: Lukas Theussl Resolution: Won't Fix Use maven.announcement.lenient=true, see MPANNOUNCEMENT-19. > Plugin causes site to fail during processing of xdoc plugin's downloads.jelly > - > > Key: MPANNOUNCEMENT-21 > URL: http://jira.codehaus.org/browse/MPANNOUNCEMENT-21 > Project: Maven 1.x Announcement Plugin > Issue Type: Bug >Affects Versions: 1.4.1 > Environment: Windows XP, Maven 1.1-RC1, Plugin version 1.4.2 >Reporter: dion gillard >Assignee: Lukas Theussl >Priority: Critical > > The xdoc plugin calls during > it's generation of reports from the POM. > This causes announcement:check-version to run and fail, if a project has a > currentVersion not listed in the versions stanza. > This is very common, especially with x.y-SNAPSHOT as the currentVersion. -- 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: (MPANNOUNCEMENT-21) Plugin causes site to fail during processing of xdoc plugin's downloads.jelly
[ http://jira.codehaus.org/browse/MPANNOUNCEMENT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99823 ] dion gillard commented on MPANNOUNCEMENT-21: This can be fixed by providing maven.announcement.lenient=true But, still, MPANNOUNCEMENT-19 is a compatibility-breaking change. > Plugin causes site to fail during processing of xdoc plugin's downloads.jelly > - > > Key: MPANNOUNCEMENT-21 > URL: http://jira.codehaus.org/browse/MPANNOUNCEMENT-21 > Project: Maven 1.x Announcement Plugin > Issue Type: Bug >Affects Versions: 1.4.1 > Environment: Windows XP, Maven 1.1-RC1, Plugin version 1.4.2 >Reporter: dion gillard >Assignee: Lukas Theussl >Priority: Critical > > The xdoc plugin calls during > it's generation of reports from the POM. > This causes announcement:check-version to run and fail, if a project has a > currentVersion not listed in the versions stanza. > This is very common, especially with x.y-SNAPSHOT as the currentVersion. -- 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: (MPANNOUNCEMENT-21) Plugin causes site to fail during processing of xdoc plugin's downloads.jelly
[ http://jira.codehaus.org/browse/MPANNOUNCEMENT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99826 ] dion gillard commented on MPANNOUNCEMENT-21: Why is breaking compatibility acceptable? Why not default it to true and allow those that want the feature to set it to false? I personally don't see the reasoning. Got an email discussion thread for me to read up on the history? > Plugin causes site to fail during processing of xdoc plugin's downloads.jelly > - > > Key: MPANNOUNCEMENT-21 > URL: http://jira.codehaus.org/browse/MPANNOUNCEMENT-21 > Project: Maven 1.x Announcement Plugin > Issue Type: Bug >Affects Versions: 1.4.1 > Environment: Windows XP, Maven 1.1-RC1, Plugin version 1.4.2 >Reporter: dion gillard >Assignee: Lukas Theussl >Priority: Critical > > The xdoc plugin calls during > it's generation of reports from the POM. > This causes announcement:check-version to run and fail, if a project has a > currentVersion not listed in the versions stanza. > This is very common, especially with x.y-SNAPSHOT as the currentVersion. -- 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: (MPANNOUNCEMENT-21) Plugin causes site to fail during processing of xdoc plugin's downloads.jelly
[ http://jira.codehaus.org/browse/MPANNOUNCEMENT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_99827 ] Lukas Theussl commented on MPANNOUNCEMENT-21: - This was done before I joined the Maven team, I don't know the history. I was not aware of a compatibility problem though, Felipe's comments at MPANNOUNCEMENT-19 seem to indicate that he took care of that. I'll check. > Plugin causes site to fail during processing of xdoc plugin's downloads.jelly > - > > Key: MPANNOUNCEMENT-21 > URL: http://jira.codehaus.org/browse/MPANNOUNCEMENT-21 > Project: Maven 1.x Announcement Plugin > Issue Type: Bug >Affects Versions: 1.4.1 > Environment: Windows XP, Maven 1.1-RC1, Plugin version 1.4.2 >Reporter: dion gillard >Assignee: Lukas Theussl >Priority: Critical > > The xdoc plugin calls during > it's generation of reports from the POM. > This causes announcement:check-version to run and fail, if a project has a > currentVersion not listed in the versions stanza. > This is very common, especially with x.y-SNAPSHOT as the currentVersion. -- 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: (MPANNOUNCEMENT-21) Plugin causes site to fail during processing of xdoc plugin's downloads.jelly
[ http://jira.codehaus.org/browse/MPANNOUNCEMENT-21?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl reopened MPANNOUNCEMENT-21: - Assignee: (was: Lukas Theussl) Confirming that a build succeeds with m1.0.2 (announcement-plugin-1.3), but fails with 11rc1 if lenient is not set. I don't feel like fixing this for m11-final though, I'd just document it as a compat problem... > Plugin causes site to fail during processing of xdoc plugin's downloads.jelly > - > > Key: MPANNOUNCEMENT-21 > URL: http://jira.codehaus.org/browse/MPANNOUNCEMENT-21 > Project: Maven 1.x Announcement Plugin > Issue Type: Bug >Affects Versions: 1.4.1 > Environment: Windows XP, Maven 1.1-RC1, Plugin version 1.4.2 >Reporter: dion gillard >Priority: Critical > > The xdoc plugin calls during > it's generation of reports from the POM. > This causes announcement:check-version to run and fail, if a project has a > currentVersion not listed in the versions stanza. > This is very common, especially with x.y-SNAPSHOT as the currentVersion. -- 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
