[jira] Commented: (MRM-730) Index/Search by class, method or package name
[ http://jira.codehaus.org/browse/MRM-730?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126269 ] Maria Odea Ching commented on MRM-730: -- There are already stub consumers for this in archiva-lucene-consumers (IndexArchiveTableOfContentsConsumer and IndexJavaPublicMethodsConsumer). Only the implementation code is needed. > Index/Search by class, method or package name > - > > Key: MRM-730 > URL: http://jira.codehaus.org/browse/MRM-730 > Project: Archiva > Issue Type: New Feature > Components: indexing >Reporter: Maria Odea Ching > -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-730) Index/Search by class, method or package name
Index/Search by class, method or package name - Key: MRM-730 URL: http://jira.codehaus.org/browse/MRM-730 Project: Archiva Issue Type: New Feature Components: indexing Reporter: Maria Odea Ching -- 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-728) After successful admin login archiva reacts as if user is guest
[ http://jira.codehaus.org/browse/MRM-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126265 ] Arun Nachimuthu commented on MRM-728: - I am facing exactly the same issue. Archiva 1.0.1 on Tomcat 6.x RedHat Linux. Once i login, I get only the page with only Search/FindArtifact/Browse functions. This issue is reproducable only if I use IE7 as the browser. When I try to login with FireFox everything is fine. Was not able to reproduce this in windows with exactly the same setup/installation instrucations. Thanks > After successful admin login archiva reacts as if user is guest > --- > > Key: MRM-728 > URL: http://jira.codehaus.org/browse/MRM-728 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0.1 > Environment: linux >Reporter: Robin Roos > Fix For: 1.0.x > > > I ran Archiva on my windows box and, after configuring the admin user, I was > able to login. The header of the web page identified me as Administrator > (admin) and I could see all the expected functions on the left hand frame. > So far so good. > I had Archiva installed on a linux box and started. I surfed to the box from > Windows and configured the admin user. But when I logged in as admin I got a > page with only Search/FindArtifact/Browse functions. The header page reads > "Login - Register". It is as if I am not logged in and am seeing the guest > functions. Note that if I log in with a deliberately incorrect password then > I get an error message as expected. But logging in with the right > credentials appears to fail silently. > As a result I cannot deploy any artifacts into Archiva, I cannot roll out the > maven/subversion/archiva based edition of our in-house project, and I fear my > time is limited! -- 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-677) Upgrade archiva to redback 1.0
[ http://jira.codehaus.org/browse/MRM-677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126234 ] Maria Odea Ching commented on MRM-677: -- Current status of this issue: waiting for the deployed redback-1.1-SNAPSHOT which contains the fixes to be synched to the codehaus snapshots repo > Upgrade archiva to redback 1.0 > -- > > Key: MRM-677 > URL: http://jira.codehaus.org/browse/MRM-677 > Project: Archiva > Issue Type: Task > Components: build >Affects Versions: 1.0, 1.0.1 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > Fix For: 1.0.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] Work stopped: (MRM-677) Upgrade archiva to redback 1.0
[ http://jira.codehaus.org/browse/MRM-677?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-677 stopped by Maria Odea Ching. > Upgrade archiva to redback 1.0 > -- > > Key: MRM-677 > URL: http://jira.codehaus.org/browse/MRM-677 > Project: Archiva > Issue Type: Task > Components: build >Affects Versions: 1.0, 1.0.1 >Reporter: Maria Odea Ching >Assignee: Maria Odea Ching > Fix For: 1.0.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] Commented: (MRM-727) Archiva does not download plugin artifacts
[ http://jira.codehaus.org/browse/MRM-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126215 ] Christian Domsch commented on MRM-727: -- As far as I found out, part of the problem seems to be a classloading issue with geronimo. I found out, that when the DefaultRepositoryProxyConnector finished with downloading the maven-metadata-central.xml, it tries to merge it with a possible existing maven-metadata.xml. In this process, the previously downloaded xml is read with a RepositoryMetadataReader, that uses dom4j internally with xpath expressions. This process throws a NoDefClassFoundError while it tries to load org.dom4j.Element. By googling this issue, I found this link: http://mail-archives.apache.org/mod_mbox/geronimo-user/200705.mbox/[EMAIL PROTECTED] I have no clue, what the real problem is in detail, nor how to solve it. > Archiva does not download plugin artifacts > -- > > Key: MRM-727 > URL: http://jira.codehaus.org/browse/MRM-727 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0.1 > Environment: Ubuntu 7.10 x64, jdk1.6.0_04 x64, geronimo 2.0.2, maven > 2.0.8 on client >Reporter: Christian Domsch >Assignee: Maria Odea Ching > Fix For: 1.0.2 > > Attachments: MRM727.diff, settings-wrong.xml > > > When i have an initially blank local maven repo and for example start maven > with "mvn clean", no artifacts get downloaded. Maven is configured via the > attached settings.xml. When i monitor the tcp traffic, i see that the GET (in > this case for the maven-metadata.xml for maven-clean-plugin) request issued > to archiva is the correct one. Archiva responses with a 404. > When I browse the repository file system on the server where archiva stores > its files, i see that a maven-metadata-central.xml was stored. the contents > of this file are not correct, though. > From trial and error I found out, that any request to a plugin related > maven-metadata.xml file will fail. If I try the same for a "normal" artifact > maven-metadata.xml (like the one for commons-lang) then archiva downloads the > correct 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] Updated: (MRM-724) Unable to restart Archiva after restarting Tomcat : "SQL Exception: Failed to start database"
[ http://jira.codehaus.org/browse/MRM-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-724: - Fix Version/s: 1.0.x > Unable to restart Archiva after restarting Tomcat : "SQL Exception: Failed to > start database" > - > > Key: MRM-724 > URL: http://jira.codehaus.org/browse/MRM-724 > Project: Archiva > Issue Type: Bug > Components: web application >Affects Versions: 1.0.1 > Environment: Linux / Tomcat-5.5.26 >Reporter: TOTTEREAU Benoît >Priority: Blocker > Fix For: 1.0.x > > > After restarting Tomcat, I get the following exception in the log file : > 3282 [Main Thread] ERROR > org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/archiva] - > Exception lors de l'envoi de l'évènement contexte initialisé (context > initialized) à l'instance de classe d'écoute (listener) > org.codehaus.plexus.xwork.PlexusLifecycleListener > javax.jdo.JDODataStoreException: Failed initialising database. Please check > that your database JDBC driver is accessible, and the database URL and > username/password are correct. Exception : Cannot create > PoolableConnectionFactory (Failed to start database > '/exec/products/jonas/integration/archiva/database/users', see the next > exception for details.) > org.apache.tomcat.dbcp.dbcp.SQLNestedException: Cannot create > PoolableConnectionFactory (Failed to start database > '/exec/products/jonas/integration/archiva/database/users', see the next > exception for details.) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.createDataSource(BasicDataSource.java:1225) > at > org.apache.tomcat.dbcp.dbcp.BasicDataSource.getConnection(BasicDataSource.java:880) > at org.jpox.util.FailoverUtils.getConnection(FailoverUtils.java:51) > at org.jpox.store.rdbms.RDBMSManager.(RDBMSManager.java:244) > at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method) > at > sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39) > at > sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27) > at java.lang.reflect.Constructor.newInstance(Constructor.java:494) > at org.jpox.util.ClassUtils.newInstance(ClassUtils.java:73) > at > org.jpox.store.StoreManagerFactory.getStoreManager(StoreManagerFactory.java:73) > at > org.jpox.AbstractPersistenceManager.getStoreManager(AbstractPersistenceManager.java:295) > at > org.jpox.AbstractPersistenceManager.(AbstractPersistenceManager.java:217) > at > org.jpox.PersistenceManagerImpl.(PersistenceManagerImpl.java:42) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:178) > at > org.jpox.PersistenceManagerFactoryImpl.getPersistenceManager(PersistenceManagerFactoryImpl.java:153) > at > org.codehaus.plexus.redback.rbac.jdo.JdoTool.getPersistenceManager(JdoTool.java:114) > at > org.codehaus.plexus.redback.rbac.jdo.JdoTool.getObjectById(JdoTool.java:292) > at > org.codehaus.plexus.redback.rbac.jdo.JdoTool.objectExistsById(JdoTool.java:340) > at > org.codehaus.plexus.redback.rbac.jdo.JdoRbacManager.resourceExists(JdoRbacManager.java:467) > at > org.codehaus.plexus.redback.rbac.cached.CachedRbacManager.resourceExists(CachedRbacManager.java:622) > at > org.codehaus.plexus.redback.role.processor.DefaultRoleModelProcessor.processResources(DefaultRoleModelProcessor.java:77) > at > org.codehaus.plexus.redback.role.processor.DefaultRoleModelProcessor.process(DefaultRoleModelProcessor.java:63) > at > org.codehaus.plexus.redback.role.DefaultRoleManager.loadRoleModel(DefaultRoleManager.java:210) > at > org.codehaus.plexus.redback.role.DefaultRoleManager.loadRoleModel(DefaultRoleManager.java:132) > at > org.codehaus.plexus.redback.role.DefaultRoleManager.initialize(DefaultRoleManager.java:457) > at > org.codehaus.plexus.personality.plexus.lifecycle.phase.InitializePhase.execute(InitializePhase.java:33) > at > org.codehaus.plexus.lifecycle.AbstractLifecycleHandler.start(AbstractLifecycleHandler.java:128) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.startComponentLifecycle(AbstractComponentManager.java:142) > at > org.codehaus.plexus.component.manager.AbstractComponentManager.createComponentInstance(AbstractComponentManager.java:132) > at > org.codehaus.plexus.component.manager.ClassicSingletonComponentManager.getComponent(ClassicSingletonComponentManager.java:90) > at > org.codehaus.plexus.DefaultComponentLookupManager.lookup(DefaultComponentLookupManager.java:147) > at > org.codehaus.plexus.DefaultPlex
[jira] Updated: (MRM-729) [MySQL] Specified key was too long; max key length is 765 bytes - in redback
[
http://jira.codehaus.org/browse/MRM-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MRM-729:
-
Fix Version/s: 1.0.x
> [MySQL] Specified key was too long; max key length is 765 bytes - in redback
>
>
> Key: MRM-729
> URL: http://jira.codehaus.org/browse/MRM-729
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Arnaud Heritier
> Fix For: 1.0.x
>
> Attachments: wrapper.txt
>
>
> 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-725) /archiva/browse URL does not work on WebSphere
[
http://jira.codehaus.org/browse/MRM-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MRM-725:
-
Fix Version/s: 1.0.x
> /archiva/browse URL does not work on WebSphere
> --
>
> Key: MRM-725
> URL: http://jira.codehaus.org/browse/MRM-725
> Project: Archiva
> Issue Type: Bug
> Components: web application
>Affects Versions: 1.0.1
> Environment: WebSphere 6.1
>Reporter: Steffen Grunwald
> Fix For: 1.0.x
>
> Attachments: MRM-725.patch
>
>
> The browse URL is not recognized, since the RepositoryActionMapper uses the
> ServletPath to determine the "browse" prefix in the path.
> The JEE 5 spec specifies [1]:
> "This method will return an empty string ("") if the servlet used to process
> this request was matched using the "/*" pattern."
> If your appserver works as described the "browse" in the URL can only be
> determined by using getPathInfo().
> [1]
> http://java.sun.com/javaee/5/docs/api/javax/servlet/http/HttpServletRequest.html#getServletPath()
--
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-726) snapshot artifacts in maven1 repo with legacy timestamps not being cleaned
[
http://jira.codehaus.org/browse/MRM-726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brett Porter updated MRM-726:
-
Fix Version/s: 1.0.x
> snapshot artifacts in maven1 repo with legacy timestamps not being cleaned
> --
>
> Key: MRM-726
> URL: http://jira.codehaus.org/browse/MRM-726
> Project: Archiva
> Issue Type: Bug
> Components: repository scanning
>Affects Versions: 1.0.1, 1.0.2
>Reporter: james ahlborn
>Priority: Minor
> Fix For: 1.0.x
>
>
> we have artifacts in our maven1 repository which are fairly old (one of the
> reasons we wanted to use archiva, to clean up the crud!). however, it
> appears that some of the snapshots are not being cleaned up. my guess is
> that it is due to an unrecognized timestamp format:
> For an artifact with artifactId "hmsCommon-jwrap", we have snapshots which
> look like:
> hmsCommon-jwrap-20070308.050344.jar
> // unit test
> public void testLegacyVersion() {
> assertTrue(VersionUtil.isSnapshot("20070308.050344"));
> }
--
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-728) After successful admin login archiva reacts as if user is guest
[ http://jira.codehaus.org/browse/MRM-728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brett Porter updated MRM-728: - Fix Version/s: 1.0.x > After successful admin login archiva reacts as if user is guest > --- > > Key: MRM-728 > URL: http://jira.codehaus.org/browse/MRM-728 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0.1 > Environment: linux >Reporter: Robin Roos > Fix For: 1.0.x > > > I ran Archiva on my windows box and, after configuring the admin user, I was > able to login. The header of the web page identified me as Administrator > (admin) and I could see all the expected functions on the left hand frame. > So far so good. > I had Archiva installed on a linux box and started. I surfed to the box from > Windows and configured the admin user. But when I logged in as admin I got a > page with only Search/FindArtifact/Browse functions. The header page reads > "Login - Register". It is as if I am not logged in and am seeing the guest > functions. Note that if I log in with a deliberately incorrect password then > I get an error message as expected. But logging in with the right > credentials appears to fail silently. > As a result I cannot deploy any artifacts into Archiva, I cannot roll out the > maven/subversion/archiva based edition of our in-house project, and I fear my > time is limited! -- 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-728) After successful admin login archiva reacts as if user is guest
[ http://jira.codehaus.org/browse/MRM-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126172 ] Brett Porter commented on MRM-728: -- There are two things to investigate: - was there anything in the logs or anything additional in the URL when the login appeared to work but didn't? - what browser is in use? Could there be a cookie issue here? Thanks! > After successful admin login archiva reacts as if user is guest > --- > > Key: MRM-728 > URL: http://jira.codehaus.org/browse/MRM-728 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0.1 > Environment: linux >Reporter: Robin Roos > > I ran Archiva on my windows box and, after configuring the admin user, I was > able to login. The header of the web page identified me as Administrator > (admin) and I could see all the expected functions on the left hand frame. > So far so good. > I had Archiva installed on a linux box and started. I surfed to the box from > Windows and configured the admin user. But when I logged in as admin I got a > page with only Search/FindArtifact/Browse functions. The header page reads > "Login - Register". It is as if I am not logged in and am seeing the guest > functions. Note that if I log in with a deliberately incorrect password then > I get an error message as expected. But logging in with the right > credentials appears to fail silently. > As a result I cannot deploy any artifacts into Archiva, I cannot roll out the > maven/subversion/archiva based edition of our in-house project, and I fear my > time is limited! -- 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-729) CLONE -[MySQL] Specified key was too long; max key length is 765 bytes
[
http://jira.codehaus.org/browse/MRM-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126148
]
Arnaud Heritier commented on MRM-729:
-
The problem seems to be in rednack and no more in archiva itself. Fixing the
application.xml for redback like in MRM-227 fixes the issue
> CLONE -[MySQL] Specified key was too long; max key length is 765 bytes
> --
>
> Key: MRM-729
> URL: http://jira.codehaus.org/browse/MRM-729
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Arnaud Heritier
> Attachments: wrapper.txt
>
>
> 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-729) [MySQL] Specified key was too long; max key length is 765 bytes - in redback
[
http://jira.codehaus.org/browse/MRM-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MRM-729:
Summary: [MySQL] Specified key was too long; max key length is 765 bytes -
in redback (was: CLONE -[MySQL] Specified key was too long; max key length is
765 bytes)
> [MySQL] Specified key was too long; max key length is 765 bytes - in redback
>
>
> Key: MRM-729
> URL: http://jira.codehaus.org/browse/MRM-729
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Arnaud Heritier
> Attachments: wrapper.txt
>
>
> 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-729) CLONE -[MySQL] Specified key was too long; max key length is 765 bytes
[
http://jira.codehaus.org/browse/MRM-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MRM-729:
Attachment: wrapper.txt
Wrapper logs
> CLONE -[MySQL] Specified key was too long; max key length is 765 bytes
> --
>
> Key: MRM-729
> URL: http://jira.codehaus.org/browse/MRM-729
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Arnaud Heritier
> Attachments: wrapper.txt
>
>
> 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-729) CLONE -[MySQL] Specified key was too long; max key length is 765 bytes
[
http://jira.codehaus.org/browse/MRM-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Arnaud Heritier updated MRM-729:
Assignee: (was: Joakim Erdfelt)
Reporter: Arnaud Heritier (was: Joakim Erdfelt)
Affects Version/s: 1.0.1
I have the same issue with archiva 1.0.1 (standalone) MySql version 5.0.22,
driver jdbc mysql 5.1.5
> CLONE -[MySQL] Specified key was too long; max key length is 765 bytes
> --
>
> Key: MRM-729
> URL: http://jira.codehaus.org/browse/MRM-729
> Project: Archiva
> Issue Type: Bug
>Affects Versions: 1.0.1
>Reporter: Arnaud Heritier
>
> 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] Created: (MRM-729) CLONE -[MySQL] Specified key was too long; max key length is 765 bytes
CLONE -[MySQL] Specified key was too long; max key length is 765 bytes
--
Key: MRM-729
URL: http://jira.codehaus.org/browse/MRM-729
Project: Archiva
Issue Type: Bug
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: (MRM-657) 'ORA-00910: specified length too long for its datatype' Error when clicking on searched artifact.
[ http://jira.codehaus.org/browse/MRM-657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gunther Van den Bosch updated MRM-657: -- Attachment: package-oracle.orm > 'ORA-00910: specified length too long for its datatype' Error when clicking > on searched artifact. > - > > Key: MRM-657 > URL: http://jira.codehaus.org/browse/MRM-657 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0 > Environment: Oracle 10g 10.2.0.3.0 on Sun Solaris Sparc 64 >Reporter: Mick Knutson > Fix For: 1.1 > > Attachments: package-oracle.orm > > > When I do a search for an artifact, then I get the results, I then get this > error: > javax.jdo.JDODataStoreException: An exception was thrown while > adding/validating class(es) : ORA-00910: specified length too long for its > datatype > java.sql.SQLException: ORA-00910: specified length too long for its datatype > at > oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:158) > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:316) > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:282) > at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:639) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:113) > at > oracle.jdbc.driver.T4CStatement.execute_for_rows(T4CStatement.java:703) > at > oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1196) > at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1804) > at > org.apache.tomcat.dbcp.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264) > 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:429) > at > org.apache.maven.archiva.database.jdo.JdoProjectModelDAO.getProjectModel(JdoProjectModelDAO.java:74) > at > org.apache.maven.archiva.database.browsing.DefaultRepositoryBrowsing.getProjectModel(DefaultRepositoryBrowsing.java:281) > at > org.apache.maven.archiva.database.browsing.DefaultRepositoryBrowsing.selectVersion(DefaultRepositoryBrowsing.java:127) > at > org.apache.maven.archiva.web.action.ShowArtifactAction.artifact(ShowArtifactAction.java:105) > Now this does not come up like with continuum (at start up): > http://jira.codehaus.org/browse/CONTINUUM-1622 > So Archiva runs, but not when I try to search. -- 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-657) 'ORA-00910: specified length too long for its datatype' Error when clicking on searched artifact.
[ http://jira.codehaus.org/browse/MRM-657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126122 ] Gunther Van den Bosch commented on MRM-657: --- This could be solved by adapting the JDO mapping for Oracle. Oracle supports only VARCHAR types with a maximum length of 4000. The standard implementation of archiva sometimes uses fields which are longer. I have attached the package-oracle.orm file which should be included in the archiva-model-1.0.1.jar next to the package.jdo Using the Oracle mapping can be activated by setting the mapping property in the application.xml for the Jdofactory component javax.jdo.option.Mapping oracle I hope this helps > 'ORA-00910: specified length too long for its datatype' Error when clicking > on searched artifact. > - > > Key: MRM-657 > URL: http://jira.codehaus.org/browse/MRM-657 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0 > Environment: Oracle 10g 10.2.0.3.0 on Sun Solaris Sparc 64 >Reporter: Mick Knutson > Fix For: 1.1 > > Attachments: package-oracle.orm > > > When I do a search for an artifact, then I get the results, I then get this > error: > javax.jdo.JDODataStoreException: An exception was thrown while > adding/validating class(es) : ORA-00910: specified length too long for its > datatype > java.sql.SQLException: ORA-00910: specified length too long for its datatype > at > oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:158) > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:316) > at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:282) > at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:639) > at oracle.jdbc.driver.T4CStatement.doOall8(T4CStatement.java:113) > at > oracle.jdbc.driver.T4CStatement.execute_for_rows(T4CStatement.java:703) > at > oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1196) > at oracle.jdbc.driver.OracleStatement.execute(OracleStatement.java:1804) > at > org.apache.tomcat.dbcp.dbcp.DelegatingStatement.execute(DelegatingStatement.java:264) > 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:429) > at > org.apache.maven.archiva.database.jdo.JdoProjectModelDAO.getProjectModel(JdoProjectModelDAO.java:74) > at > org.apache.maven.archiva.database.browsing.DefaultRepositoryBrowsing.getProjectModel(DefaultRepositoryBrowsing.java:281) > at > org.apache.maven.archiva.database.browsing.DefaultRepositoryBrowsing.selectVersion(DefaultRepositoryBrowsing.java:127) > at > org.apache.maven.archiva.web.action.ShowArtifactAction.artifact(ShowArtifactAction.java:105) > Now this does not come up like with continuum (at start up): > http://jira.codehaus.org/browse/CONTINUUM-1622 > So Archiva runs, but not when I try to search. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MRM-728) After successful admin login archiva reacts as if user is guest
After successful admin login archiva reacts as if user is guest --- Key: MRM-728 URL: http://jira.codehaus.org/browse/MRM-728 Project: Archiva Issue Type: Bug Affects Versions: 1.0.1 Environment: linux Reporter: Robin Roos I ran Archiva on my windows box and, after configuring the admin user, I was able to login. The header of the web page identified me as Administrator (admin) and I could see all the expected functions on the left hand frame. So far so good. I had Archiva installed on a linux box and started. I surfed to the box from Windows and configured the admin user. But when I logged in as admin I got a page with only Search/FindArtifact/Browse functions. The header page reads "Login - Register". It is as if I am not logged in and am seeing the guest functions. Note that if I log in with a deliberately incorrect password then I get an error message as expected. But logging in with the right credentials appears to fail silently. As a result I cannot deploy any artifacts into Archiva, I cannot roll out the maven/subversion/archiva based edition of our in-house project, and I fear my time is limited! -- 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-727) Archiva does not download plugin artifacts
[ http://jira.codehaus.org/browse/MRM-727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126106 ] Maria Odea Ching commented on MRM-727: -- I tried to replicate this in the standalone archiva using the attached settings.xml, and I couldn't replicate the issue. This is my environment: - maven 2.0.7/maven-2.0.8 - ubuntu 7.04 - jdk 1.5.0_11 I will try deploying Archiva to Geronimo.. > Archiva does not download plugin artifacts > -- > > Key: MRM-727 > URL: http://jira.codehaus.org/browse/MRM-727 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0.1 > Environment: Ubuntu 7.10 x64, jdk1.6.0_04 x64, geronimo 2.0.2, maven > 2.0.8 on client >Reporter: Christian Domsch >Assignee: Maria Odea Ching > Fix For: 1.0.2 > > Attachments: MRM727.diff, settings-wrong.xml > > > When i have an initially blank local maven repo and for example start maven > with "mvn clean", no artifacts get downloaded. Maven is configured via the > attached settings.xml. When i monitor the tcp traffic, i see that the GET (in > this case for the maven-metadata.xml for maven-clean-plugin) request issued > to archiva is the correct one. Archiva responses with a 404. > When I browse the repository file system on the server where archiva stores > its files, i see that a maven-metadata-central.xml was stored. the contents > of this file are not correct, though. > From trial and error I found out, that any request to a plugin related > maven-metadata.xml file will fail. If I try the same for a "normal" artifact > maven-metadata.xml (like the one for commons-lang) then archiva downloads the > correct 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] Work started: (MRM-727) Archiva does not download plugin artifacts
[ http://jira.codehaus.org/browse/MRM-727?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Work on MRM-727 started by Maria Odea Ching. > Archiva does not download plugin artifacts > -- > > Key: MRM-727 > URL: http://jira.codehaus.org/browse/MRM-727 > Project: Archiva > Issue Type: Bug >Affects Versions: 1.0.1 > Environment: Ubuntu 7.10 x64, jdk1.6.0_04 x64, geronimo 2.0.2, maven > 2.0.8 on client >Reporter: Christian Domsch >Assignee: Maria Odea Ching > Fix For: 1.0.2 > > Attachments: MRM727.diff, settings-wrong.xml > > > When i have an initially blank local maven repo and for example start maven > with "mvn clean", no artifacts get downloaded. Maven is configured via the > attached settings.xml. When i monitor the tcp traffic, i see that the GET (in > this case for the maven-metadata.xml for maven-clean-plugin) request issued > to archiva is the correct one. Archiva responses with a 404. > When I browse the repository file system on the server where archiva stores > its files, i see that a maven-metadata-central.xml was stored. the contents > of this file are not correct, though. > From trial and error I found out, that any request to a plugin related > maven-metadata.xml file will fail. If I try the same for a "normal" artifact > maven-metadata.xml (like the one for commons-lang) then archiva downloads the > correct 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
