[jira] Commented: (MDEP-115) Dependency sort mojo
[ http://jira.codehaus.org/browse/MDEP-115?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109731 ] Mark Hobson commented on MDEP-115: -- Could be worth proposing on mojo-dev and see what people think before incorporating this into the dependency plugin. Dependency sort mojo Key: MDEP-115 URL: http://jira.codehaus.org/browse/MDEP-115 Project: Maven 2.x Dependency Plugin Issue Type: New Feature Affects Versions: 2.0-alpha-4 Reporter: Paul Gier Assignee: Brian Fox Fix For: 2.0-alpha-5 Attachments: maven-dependency-plugin-r579844.patch, MDEP-115-maven-dependency-plugin-r580489-with-test-and-doc.patch I have a few projects that have a large number of dependencies. I would like to be able to sort them into alphabetical order for easier readability. Also sometimes the same dependency gets copied and pasted and there is a duplicate. I created the sort mojo to sort dependencies in alphabetical order and optionally remove duplicates and group the dependencies by their scope. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1764) Upload tagunit 1.0.1 to the repository
Upload tagunit 1.0.1 to the repository -- Key: MAVENUPLOAD-1764 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1764 Project: maven-upload-requests Issue Type: New Feature Reporter: Ulrik Nilsson Attachments: tagunit.jar In the same way that JUnit allows us to write unit tests for Java classes, TagUnit allows us to unit test JSP custom tags, inside the container. In essence, TagUnit is a tag library for testing custom tags within JSP pages. -- 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: (MJAVADOC-138) javadoc:test-javadoc failed if target/classes not already created
[
http://jira.codehaus.org/browse/MJAVADOC-138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109734
]
Benjamin Bentmann commented on MJAVADOC-138:
Well, why to depend on the compiled classes of the project anyway? Regarding
the currently build project, you have something better than just bytecode, the
sources! Unlike the class files, the sources carry documentation that javadoc
can use to inherit documentation (e.g. for overriden methods). So, instead of
{code}-classpath '[SNIP]/target/classes;[SNIP]/target/tests-classes;...'{code}
I would rather aim at
{code}
-classpath '...'
-sourcepath '[SNIP]/src/main/java;[SNIP]/src/test/java;...'
{code}
However, just including the project main sources on the source path has an
unwanted effect: One will likely get Javadoc for production classes if those
happen to reside in the same package as some test class (a common scenario for
organizing tests). This effect stems from the fact, that the plugin currently
specifies which packages to document and javadoc cannot distinguish from main
and test sources. But that is easily solved: Instead of listing up packages,
the plugin simply needs to scan all test source directories for Java files and
put those in an arg file.
javadoc:test-javadoc failed if target/classes not already created
-
Key: MJAVADOC-138
URL: http://jira.codehaus.org/browse/MJAVADOC-138
Project: Maven 2.x Javadoc Plugin
Issue Type: Bug
Affects Versions: 2.3
Reporter: Vincent Siveton
Using
{noformat}
mvn clean javadoc:test-javadoc
{noformat}
it could produce unsuccessful build or warning (depending the javadoc version
used, i.e 1.4 vs 1.5)
The options file contains:
{noformat}
-classpath '[SNIP]/target/classes;[SNIP]/target/tests-classes;...'
{noformat}
The explanation is that no target\classes was created before executing
test-javadoc
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-1519) Continuum does not respect build order for flat projects
[ http://jira.codehaus.org/browse/CONTINUUM-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109750 ] Siarhei Dudzin commented on CONTINUUM-1519: --- Small correction, the reactor build order is specified as I have given in the example with module/ sections (sorry was a bit misleading in the beginning). Continuum does not respect build order for flat projects Key: CONTINUUM-1519 URL: http://jira.codehaus.org/browse/CONTINUUM-1519 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-3 Environment: Windows XP/2003 Server, Maven 2.0.7 Reporter: Siarhei Dudzin Priority: Blocker When adding maven 2 projects with flat project layout continuum sorts the projects build sequence by alphabet thus braking builds. Previous version did respect reactor build sequence and '--non-recursive' option allowed to build flat projects independently but still in the right order. This is a very blocking issue for us because we are forced atm to use flat project structure. -- 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-1519) Continuum does not respect build order for flat projects
[ http://jira.codehaus.org/browse/CONTINUUM-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109748 ] Siarhei Dudzin commented on CONTINUUM-1519: --- We use default schedule, same happens if I just use build all projects in a group, it just builds from top to bottom (thus list order defines the build order). We have the following dependencies (all flat structure): A (parent), has modules listed in the following order: B, C, D, E B (ear), has dependencies on: C (war), D(ejb) C (war) has dependencies on D (type ejb, scope provided), E (type jar) D (ejb) has dependencies on E (jar) E (jar) has no other dependencies As you can see there are not circular dependencies (otherwise maven would not build I imagine). The parent project has modules listed like this: module../E/module module../D/module module../C/module module../B/module Each sub project has a relative path to the parent pom: relativePath../A/pom.xml/relativePath I have the same project working in beta 2 only because it sorted the modules in the right order (still if I add an extra module to the group it does not reorder them but adds at the end thus forcing me to delete the projects from continuum and re-add them). I have not figured another way to build flat projects in continuum. Continuum does not respect build order for flat projects Key: CONTINUUM-1519 URL: http://jira.codehaus.org/browse/CONTINUUM-1519 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-3 Environment: Windows XP/2003 Server, Maven 2.0.7 Reporter: Siarhei Dudzin Priority: Blocker When adding maven 2 projects with flat project layout continuum sorts the projects build sequence by alphabet thus braking builds. Previous version did respect reactor build sequence and '--non-recursive' option allowed to build flat projects independently but still in the right order. This is a very blocking issue for us because we are forced atm to use flat project structure. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MJAVADOC-155) maxmemory and minmemory support only m unit
maxmemory and minmemory support only m unit --- Key: MJAVADOC-155 URL: http://jira.codehaus.org/browse/MJAVADOC-155 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Vincent Siveton Javadoc JVM heap size should support other units like k, m, g or t -- 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-3237) Maven seems to ignore mirror-settings when searching for Reporting-plugins
Maven seems to ignore mirror-settings when searching for Reporting-plugins -- Key: MNG-3237 URL: http://jira.codehaus.org/browse/MNG-3237 Project: Maven 2 Issue Type: Bug Components: Plugin Requests, Sites Reporting Affects Versions: 2.0.7 Reporter: Helge Stieghahn In our company we have set up an Maven-Proxy that uses our department-repository as source also. We have defined the Proxy aus Mirror for maven-central in settings.xml so we don't have to bother with defining repositories within all projects. that works fine for plugins from our department-repository that are defined within the build-section, but does not for ones that are defined within the reporting section of the pom. The error message states that there is no such plugin or no valid version is found. If we now define a pluginRepository-entry for the department-repository the plugin will be found. It seems that the dependency-resolution for reporting-plugins is ignoring the mirror-definition within the settings.xml. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MJAVADOC-155) maxmemory and minmemory support only m unit
[ http://jira.codehaus.org/browse/MJAVADOC-155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MJAVADOC-155. Assignee: Vincent Siveton Resolution: Fixed Fix Version/s: 2.4 fixed in r584160 maxmemory and minmemory support only m unit --- Key: MJAVADOC-155 URL: http://jira.codehaus.org/browse/MJAVADOC-155 Project: Maven 2.x Javadoc Plugin Issue Type: Bug Affects Versions: 2.3 Reporter: Vincent Siveton Assignee: Vincent Siveton Fix For: 2.4 Javadoc JVM heap size should support other units like k, m, g or t -- 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-533) Checksum files (sha1/md5) are not kept up to date on maven-metadata.xml files.
[ http://jira.codehaus.org/browse/MRM-533?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-533. -- Resolution: Fixed Fixed in archiva/trunk revision 583875. Checksum files (sha1/md5) are not kept up to date on maven-metadata.xml files. -- Key: MRM-533 URL: http://jira.codehaus.org/browse/MRM-533 Project: Archiva Issue Type: Bug Components: repository scanning Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Assignee: Joakim Erdfelt Priority: Critical Fix For: 1.0-beta-3 When the maven-metadata.xml files are updated, the associated sha1 and md5 checksums are not updated with it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1766) Upload Cayenne 1.2.4 bundles
Upload Cayenne 1.2.4 bundles Key: MAVENUPLOAD-1766 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1766 Project: maven-upload-requests Issue Type: Task Reporter: Andrus Adamchik Cayenne is already on ibiblio. Please upload these 4 new bundles of the legacy pre-Apache Cayenne 1.2: http://people.apache.org/~aadamchik/release/1.2.4/cayenne-1.2.4-bundle.jar http://people.apache.org/~aadamchik/release/1.2.4/cayenne-client-nodeps-1.2.4-bundle.jar http://people.apache.org/~aadamchik/release/1.2.4/cayenne-modeler-1.2.4-bundle.jar http://people.apache.org/~aadamchik/release/1.2.4/cayenne-nodeps-1.2.4-bundle.jar Thanks, Andrus -- 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: (MSHADE-4) Extraneous directories and unneeded files included after shading
[ http://jira.codehaus.org/browse/MSHADE-4?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mauro Talevi updated MSHADE-4: -- Summary: Extraneous directories and unneeded files included after shading (was: Extraneous directories and uneeded files included after shading) Extraneous directories and unneeded files included after shading Key: MSHADE-4 URL: http://jira.codehaus.org/browse/MSHADE-4 Project: Maven 2.x Shade Plugin Issue Type: Bug Reporter: Paul Hammant Refer build of https://svn.codehaus.org/picocontainer/java/2.x/trunk/pico/container/pom.xml Makes a jar that containes ... 0 Fri Oct 05 09:32:28 PDT 2007 META-INF/ 123 Fri Oct 05 09:32:28 PDT 2007 META-INF/MANIFEST.MF 0 Fri Oct 05 09:32:28 PDT 2007 org/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/adapters/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/annotations/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/containers/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/injectors/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/lifecycle/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/monitors/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/parameters/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/references/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/security/ 0 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/visitors/ 3766 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/adapters/AbstractAdapter.class 4113 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/adapters/InstanceAdapter.class 391 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/annotations/Cache.class 408 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/annotations/Inject.class 387 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/Behavior.class 689 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/BehaviorFactory.class 4770 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/AbstractBehavior.class 3737 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/AbstractBehaviorFactory.class 5132 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/AdaptiveBehavior.class 745 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Automated.class 1742 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Automatic.class 1024 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Behaviors.class 1037 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Cached.class 2685 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Caching.class 1344 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/HiddenImplementation$1.class 4079 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/HiddenImplementation.class 1862 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/ImplementationHiding.class 457 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Intercepted$Controller.class 1360 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Intercepted$ControllerImpl.class 1933 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Intercepted$ControllerWrapper.class 686 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Intercepted$InterceptorThreadLocal.class 3617 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Intercepted.class 1507 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Interception.class 1143 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Locked.class 1687 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/Locking.class 1797 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/OptInCaching.class 1130 Fri Oct 05 09:32:28 PDT 2007 org/picocontainer/behaviors/PropertyApplicator$1.class 10001 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/PropertyApplicator.class 2436 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/PropertyApplying.class 3011 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Stored.class 562 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Storing$StoreThreadLocal.class 814 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Storing$StoreWrapper.class 4043 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Storing.class 842 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Synchronized.class 1660 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/Synchronizing.class 1013 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/ThreadCached.class 1806 Fri Oct 05 09:32:30 PDT 2007 org/picocontainer/behaviors/ThreadCaching.class 940 Fri Oct 05
[jira] Closed: (MRM-459) prune the distributed dependencies
[ http://jira.codehaus.org/browse/MRM-459?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-459. -- Resolution: Fixed Can't find anything else to prune, seems like the rest is in active use by the runtime. Closing issue. prune the distributed dependencies -- Key: MRM-459 URL: http://jira.codehaus.org/browse/MRM-459 Project: Archiva Issue Type: Improvement Components: web application Affects Versions: 1.0-beta-1 Reporter: Brett Porter Assignee: Joakim Erdfelt Fix For: 1.0-beta-3 a large number of unneeded dependencies are distributed with Archiva (or if they are needed, we might want to review why). For example: ant-optional (probably for jsp compiler), commons-logging impl + slf4j + log4j, xerces, jtidy, jdom, dom4j, commons-jxpath, jaxen, jta (we have geronimo-jat already), classworlds (we have plexus-classworlds already), backport (we require JDK 5, no need for this). I'm also uncertain if all the maven libraries are still needed. -- 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-459) prune the distributed dependencies
[ http://jira.codehaus.org/browse/MRM-459?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109790 ] Joakim Erdfelt commented on MRM-459: Pruning the following ... * ant-optional * jdom * classworlds * jta * xerces Setting to scopeprovided/scope the following ... * servlet-api * jsp-api * jstl-api prune the distributed dependencies -- Key: MRM-459 URL: http://jira.codehaus.org/browse/MRM-459 Project: Archiva Issue Type: Improvement Components: web application Affects Versions: 1.0-beta-1 Reporter: Brett Porter Assignee: Joakim Erdfelt Fix For: 1.0-beta-3 a large number of unneeded dependencies are distributed with Archiva (or if they are needed, we might want to review why). For example: ant-optional (probably for jsp compiler), commons-logging impl + slf4j + log4j, xerces, jtidy, jdom, dom4j, commons-jxpath, jaxen, jta (we have geronimo-jat already), classworlds (we have plexus-classworlds already), backport (we require JDK 5, no need for this). I'm also uncertain if all the maven libraries are still needed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-1412) dependency sorting in classpath
[ http://jira.codehaus.org/browse/MNG-1412?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109773 ] Michael Buckley commented on MNG-1412: -- I vote for a stable order in the .classpath file. We commit these to SVN to simplify eclipse usage, and rebuilding them on different machines generates spurious diffs. If fact, just adding -DdownloadSources=true generates different orders. dependency sorting in classpath --- Key: MNG-1412 URL: http://jira.codehaus.org/browse/MNG-1412 Project: Maven 2 Issue Type: Bug Components: Dependencies Affects Versions: 2.0 Reporter: Mark Hobson Assignee: fabrizio giustina Fix For: 2.1 Attachments: artifact-order_maven-artifact-manager.txt, artifact-order_maven-artifact.txt, artifact-order_maven-project.txt, MNG-1412-maven-2.0.x-r507746.patch The .classpath file entries should be ordered by nearest transitiveness (if that's a word). For example, I have project A that depends on B that depends on C. The classpath for A is generated in the order C, B. Ideally the classpath should be in order of how near they are to the project, i.e. B, C. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (CONTINUUM-358) User Authentication via LDAP
[ http://jira.codehaus.org/browse/CONTINUUM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109761 ] Jesse McConnell commented on CONTINUUM-358: --- there is no facility in place for pulling roles from ldap yet...it should be pretty simple to put into place but its implemented yet..the biggest hangup is that it needs to be writable which wasn't in the scope of this first ldap bit. ideally when that bit gets implemented we'll have a mapping in place that lets you map roles from ldap to roles in the application. this pass with ldap was strictly for user authentication so the role management is handled with the embedded derby database or whatever else you might have the users database pointing at User Authentication via LDAP Key: CONTINUUM-358 URL: http://jira.codehaus.org/browse/CONTINUUM-358 Project: Continuum Issue Type: New Feature Components: Web interface Reporter: Frank Zhao Assignee: Jesse McConnell Fix For: 1.1-beta-3 Please add LDAP support for the user authentication in Continuum user management function. -- 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: (ARCHETYPE-108) Use of wildcards in archetype.xml
Use of wildcards in archetype.xml - Key: ARCHETYPE-108 URL: http://jira.codehaus.org/browse/ARCHETYPE-108 Project: Maven Archetype Issue Type: Improvement Components: Archetypes Environment: All OS Reporter: Felipe Lang I could be great if we could use wildcards to specify the sources, testsources, resources and so on in the archetype.xml file. ie: archetype idmy-archetyp/id sources sourcesrc/main/java/com/company/*.java/source sourcesrc/main/java/com/company/**.*/source /sources resources resourcesrc/main/resources/*.*/resource /resources /archetype -- 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-1519) Continuum does not respect build order for flat projects
Continuum does not respect build order for flat projects Key: CONTINUUM-1519 URL: http://jira.codehaus.org/browse/CONTINUUM-1519 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-3 Environment: Windows XP/2003 Server, Maven 2.0.7 Reporter: Siarhei Dudzin Priority: Blocker When adding maven 2 projects with flat project layout continuum sorts the projects build sequence by alphabet thus braking builds. Previous version did respect reactor build sequence and '--non-recursive' option allowed to build flat projects independently but still in the right order. This is a very blocking issue for us because we are forced atm to use flat project structure. -- 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-3236) [maven-dependency-tree] DefaultDependencyTreeBuilder ignores artifact filter
[maven-dependency-tree] DefaultDependencyTreeBuilder ignores artifact filter Key: MNG-3236 URL: http://jira.codehaus.org/browse/MNG-3236 Project: Maven 2 Issue Type: Bug Components: Shared Affects Versions: Shared Components Reporter: Mark Hobson -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-1765) DITA jost-1.4 for Maven 2 plugin Development
DITA jost-1.4 for Maven 2 plugin Development Key: MAVENUPLOAD-1765 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-1765 Project: maven-upload-requests Issue Type: Task Reporter: Sascha Kohlmann -- 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-1519) Continuum does not respect build order for flat projects
[ http://jira.codehaus.org/browse/CONTINUUM-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109745 ] Emmanuel Venisse commented on CONTINUUM-1519: - When Continuum determine the build order, he don't know if it is a flat project or a standard structure. It look only at dependencies in POMs to determine which projects must be built before an other. If it build projects in alphabet order it isn't because you use a flat structure but something else. what is the cron expression for your schedule? do you have a cycle in your dependencies (check your logs when projects are put in queue)? Continuum does not respect build order for flat projects Key: CONTINUUM-1519 URL: http://jira.codehaus.org/browse/CONTINUUM-1519 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-3 Environment: Windows XP/2003 Server, Maven 2.0.7 Reporter: Siarhei Dudzin Priority: Blocker When adding maven 2 projects with flat project layout continuum sorts the projects build sequence by alphabet thus braking builds. Previous version did respect reactor build sequence and '--non-recursive' option allowed to build flat projects independently but still in the right order. This is a very blocking issue for us because we are forced atm to use flat project structure. -- 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-1519) Continuum does not respect build order for flat projects
[ http://jira.codehaus.org/browse/CONTINUUM-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109752 ] Emmanuel Venisse commented on CONTINUUM-1519: - maven and Continuum don't use the order in the modules list to found the build order, all is based on dependencies analyze. Can you attach a sample project that reproduce your issue? Continuum does not respect build order for flat projects Key: CONTINUUM-1519 URL: http://jira.codehaus.org/browse/CONTINUUM-1519 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-3 Environment: Windows XP/2003 Server, Maven 2.0.7 Reporter: Siarhei Dudzin Priority: Blocker When adding maven 2 projects with flat project layout continuum sorts the projects build sequence by alphabet thus braking builds. Previous version did respect reactor build sequence and '--non-recursive' option allowed to build flat projects independently but still in the right order. This is a very blocking issue for us because we are forced atm to use flat project structure. -- 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: (SUREFIRE-357) Java language constraint is a poor criteria for surefire report generation
Java language constraint is a poor criteria for surefire report generation -- Key: SUREFIRE-357 URL: http://jira.codehaus.org/browse/SUREFIRE-357 Project: Maven Surefire Issue Type: Bug Components: report plugin Affects Versions: 2.3 Reporter: David Cardon With the expansion of maven as a project management tool for other (non-Java) languages, the 'canGenerateReport' function in SurefireReportMojo.java limits the scope of the report plugin to only Java projects. This limitation prevents the use of surefire xml as a standard format for test reports. Perhaps a more relevant approach to the function would be to test for the existence of the 'surefire-reports' folder and relevant files within that folder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-2254) the encoding parameter in xml declaration of POM is ignored
[ http://jira.codehaus.org/browse/MNG-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Herve Boutemy updated MNG-2254: --- Attachment: MNG-2254_components-new.diff ok: here is a new patch the encoding parameter in xml declaration of POM is ignored Key: MNG-2254 URL: http://jira.codehaus.org/browse/MNG-2254 Project: Maven 2 Issue Type: Bug Components: POM::Encoding Reporter: Naoki Nose Assignee: Jason van Zyl Fix For: 2.0.8 Attachments: DefaultMavenProjectBuilder.diff, MNG-2254-2.diff, mng-2254-PomEncoding.tgz, MNG-2254.diff, MNG-2254_artifact.diff, MNG-2254_components-new.diff, MNG-2254_components.diff, modello-plugin-xpp3.diff DefaultMavenProjectBuilder reads POM in system default character encoding, and the encoding parameter in xml declartion is ignored. to fix this problem, We should - fix modello-plugin-xpp3 to use the xml parser which is able to handle the encoding parameter properly - regenerate maven-model using fixed modello-plugin-xpp3 - fix DefaultMavenProjectBuilder to use regenerated maven-model properly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (SUREFIRE-357) Java language constraint is a poor criteria for surefire report generation
[
http://jira.codehaus.org/browse/SUREFIRE-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109802
]
David Cardon edited comment on SUREFIRE-357 at 10/12/07 2:40 PM:
-
Here is a patch I created:
{code}
Index:
src/main/java/org/apache/maven/plugins/surefire/report/SurefireReportMojo.java
===
---
src/main/java/org/apache/maven/plugins/surefire/report/SurefireReportMojo.java
(revision 584226)
+++
src/main/java/org/apache/maven/plugins/surefire/report/SurefireReportMojo.java
(working copy)
@@ -25,11 +25,14 @@
import org.apache.maven.reporting.AbstractMavenReport;
import org.apache.maven.reporting.MavenReportException;
import org.codehaus.doxia.site.renderer.SiteRenderer;
+import org.codehaus.plexus.util.FileUtils;
import org.codehaus.plexus.util.PathTool;
import org.codehaus.plexus.util.StringUtils;
import java.io.File;
+import java.io.IOException;
import java.util.Iterator;
+import java.util.List;
import java.util.Locale;
import java.util.ResourceBundle;
@@ -195,8 +198,19 @@
*/
public boolean canGenerateReport()
{
-// Only execute reports for java projects
-ArtifactHandler artifactHandler =
this.project.getArtifact().getArtifactHandler();
-return java.equals( artifactHandler.getLanguage() );
+ try
+ {
+ if ( reportsDirectory.exists()
reportsDirectory.isDirectory() )
+ {
+ List fileList = FileUtils.getFileNames(
reportsDirectory, **/TEST-*.xml, , true );
+ return !fileList.isEmpty();
+ }
+ }
+ catch ( IOException e )
+ {
+ getLog().error( Error accessing reports directory! );
+ }
+
+ return false;
}
}
{code}
was:
Here is a patch I created:
Index:
src/main/java/org/apache/maven/plugins/surefire/report/SurefireReportMojo.java
===
---
src/main/java/org/apache/maven/plugins/surefire/report/SurefireReportMojo.java
(revision 584226)
+++
src/main/java/org/apache/maven/plugins/surefire/report/SurefireReportMojo.java
(working copy)
@@ -25,11 +25,14 @@
import org.apache.maven.reporting.AbstractMavenReport;
import org.apache.maven.reporting.MavenReportException;
import org.codehaus.doxia.site.renderer.SiteRenderer;
+import org.codehaus.plexus.util.FileUtils;
import org.codehaus.plexus.util.PathTool;
import org.codehaus.plexus.util.StringUtils;
import java.io.File;
+import java.io.IOException;
import java.util.Iterator;
+import java.util.List;
import java.util.Locale;
import java.util.ResourceBundle;
@@ -195,8 +198,19 @@
*/
public boolean canGenerateReport()
{
-// Only execute reports for java projects
-ArtifactHandler artifactHandler =
this.project.getArtifact().getArtifactHandler();
-return java.equals( artifactHandler.getLanguage() );
+ try
+ {
+ if ( reportsDirectory.exists()
reportsDirectory.isDirectory() )
+ {
+ List fileList = FileUtils.getFileNames(
reportsDirectory, **/TEST-*.xml, , true );
+ return !fileList.isEmpty();
+ }
+ }
+ catch ( IOException e )
+ {
+ getLog().error( Error accessing reports directory! );
+ }
+
+ return false;
}
}
Java language constraint is a poor criteria for surefire report generation
--
Key: SUREFIRE-357
URL: http://jira.codehaus.org/browse/SUREFIRE-357
Project: Maven Surefire
Issue Type: Bug
Components: report plugin
Affects Versions: 2.3
Reporter: David Cardon
With the expansion of maven as a project management tool for other (non-Java)
languages, the 'canGenerateReport' function in SurefireReportMojo.java limits
the scope of the report plugin to only Java projects. This limitation
prevents the use of surefire xml as a standard format for test reports.
Perhaps a more relevant approach to the function would be to test for the
existence of the 'surefire-reports' folder and relevant files within that
folder.
--
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: (SUREFIRE-357) Java language constraint is a poor criteria for surefire report generation
[
http://jira.codehaus.org/browse/SUREFIRE-357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109802
]
David Cardon commented on SUREFIRE-357:
---
Here is a patch I created:
Index:
src/main/java/org/apache/maven/plugins/surefire/report/SurefireReportMojo.java
===
---
src/main/java/org/apache/maven/plugins/surefire/report/SurefireReportMojo.java
(revision 584226)
+++
src/main/java/org/apache/maven/plugins/surefire/report/SurefireReportMojo.java
(working copy)
@@ -25,11 +25,14 @@
import org.apache.maven.reporting.AbstractMavenReport;
import org.apache.maven.reporting.MavenReportException;
import org.codehaus.doxia.site.renderer.SiteRenderer;
+import org.codehaus.plexus.util.FileUtils;
import org.codehaus.plexus.util.PathTool;
import org.codehaus.plexus.util.StringUtils;
import java.io.File;
+import java.io.IOException;
import java.util.Iterator;
+import java.util.List;
import java.util.Locale;
import java.util.ResourceBundle;
@@ -195,8 +198,19 @@
*/
public boolean canGenerateReport()
{
-// Only execute reports for java projects
-ArtifactHandler artifactHandler =
this.project.getArtifact().getArtifactHandler();
-return java.equals( artifactHandler.getLanguage() );
+ try
+ {
+ if ( reportsDirectory.exists()
reportsDirectory.isDirectory() )
+ {
+ List fileList = FileUtils.getFileNames(
reportsDirectory, **/TEST-*.xml, , true );
+ return !fileList.isEmpty();
+ }
+ }
+ catch ( IOException e )
+ {
+ getLog().error( Error accessing reports directory! );
+ }
+
+ return false;
}
}
Java language constraint is a poor criteria for surefire report generation
--
Key: SUREFIRE-357
URL: http://jira.codehaus.org/browse/SUREFIRE-357
Project: Maven Surefire
Issue Type: Bug
Components: report plugin
Affects Versions: 2.3
Reporter: David Cardon
With the expansion of maven as a project management tool for other (non-Java)
languages, the 'canGenerateReport' function in SurefireReportMojo.java limits
the scope of the report plugin to only Java projects. This limitation
prevents the use of surefire xml as a standard format for test reports.
Perhaps a more relevant approach to the function would be to test for the
existence of the 'surefire-reports' folder and relevant files within that
folder.
--
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-1520) Scheduler is unstable
Scheduler is unstable - Key: CONTINUUM-1520 URL: http://jira.codehaus.org/browse/CONTINUUM-1520 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1-beta-3 Environment: xp,jse5,maven2.07,shell project Reporter: Dan Tran Hi have 2 project groups,each contains a single build defintion shell project. The first one use default scheduler ( build a site) the second one in the another group uses 10 minute recurrence schedule. What i see is the scheduler only wake up at the hour and then the first 10 min of hour. basicly i dont see 10 minute schedule waking up every 10 minute here is the log jvm 1| 2007-10-12 12:00:00,016 [defaultScheduler_Worker-6] INFO SchedulesActivator:default - Executing build job (DEFAULT_SCHEDULE)... jvm 1| 2007-10-12 12:00:00,016 [defaultScheduler_Worker-6] INFO Continuum:default - Enqueuing 'IPLocks Site' (Build defini tion id=21). jvm 1| 2007-10-12 12:00:00,016 [pool-1-thread-1] INFO BuildController:default- Initializing build jvm 1| 2007-10-12 12:00:00,016 [pool-1-thread-1] INFO BuildController:default- Starting build of IPLocks Site jvm 1| 2007-10-12 12:00:00,047 [pool-1-thread-1] INFO BuildController:default- Updating working dir jvm 1| 2007-10-12 12:00:00,047 [pool-1-thread-1] INFO BuildController:default- Performing action check-working-directory jvm 1| 2007-10-12 12:00:00,047 [pool-1-thread-1] INFO BuildController:default- Performing action update-working-directory-from- scm jvm 1| 2007-10-12 12:00:00,063 [pool-1-thread-1] INFO ContinuumScm:default - Updating project: id: '6', name 'IPLocks Site'. jvm 1| 2007-10-12 12:00:00,125 [pool-1-thread-1] INFO ScmManager:default - Executing: cmd.exe /X /C 'svn --non-interactive update' jvm 1| 2007-10-12 12:00:00,125 [pool-1-thread-1] INFO ScmManager:default - Working directory: C:\dev\continuum\working-dire ctory\1.1\6 jvm 1| 2007-10-12 12:00:01,109 [pool-1-thread-1] INFO BuildController:default- Merging SCM results jvm 1| 2007-10-12 12:00:01,125 [pool-1-thread-1] INFO BuildController:default- The project was not built because no changes wer e detected in sources since the last build. jvm 1| 2007-10-12 12:00:01,125 [pool-1-thread-1] INFO BuildController:default- No changes, not building jvm 1| 2007-10-12 12:10:00,012 [defaultScheduler_Worker-0] INFO SchedulesActivator:default - Executing build job (Run every 10 Minute)... jvm 1| 2007-10-12 12:10:00,012 [defaultScheduler_Worker-0] INFO Continuum:default - Enqueuing 'Sentinel - Continuous Build ' (Build definition id=38). jvm 1| 2007-10-12 12:10:00,012 [pool-1-thread-1] INFO BuildController:default- Initializing build jvm 1| 2007-10-12 12:10:00,027 [pool-1-thread-1] INFO BuildController:default- Starting build of Sentinel - Continuous Build jvm 1| 2007-10-12 12:10:00,043 [pool-1-thread-1] INFO BuildController:default- Updating working dir jvm 1| 2007-10-12 12:10:00,043 [pool-1-thread-1] INFO BuildController:default- Performing action check-working-directory jvm 1| 2007-10-12 12:10:00,043 [pool-1-thread-1] INFO BuildController:default- Performing action update-working-directory-from- scm jvm 1| 2007-10-12 12:10:00,058 [pool-1-thread-1] INFO ContinuumScm:default - Updating project: id: '22', name 'Sentinel - Con tinuous Build'. jvm 1| 2007-10-12 12:10:00,137 [pool-1-thread-1] INFO ScmManager:default - Executing: cmd.exe /X /C 'svn --non-interactive update' jvm 1| 2007-10-12 12:10:00,137 [pool-1-thread-1] INFO ScmManager:default - Working directory: C:\dev\continuum\working-dire ctory\1.1\22 jvm 1| 2007-10-12 12:10:01,105 [pool-1-thread-1] INFO BuildController:default- Merging SCM results jvm 1| 2007-10-12 12:10:01,105 [pool-1-thread-1] INFO BuildController:default- The project was not built because no changes wer e detected in sources since the last build. jvm 1| 2007-10-12 12:10:01,105 [pool-1-thread-1] INFO BuildController:default- No changes, not building jvm 1| 2007-10-12 13:00:00,022 [defaultScheduler_Worker-14] INFO SchedulesActivator:default - Executing build job (DEFAULT_SCHEDULE)... jvm 1| 2007-10-12 13:00:00,022 [defaultScheduler_Worker-14] INFO Continuum:default - Enqueuing 'IPLocks Site' (Build defin ition id=21). jvm 1| 2007-10-12 13:00:00,022 [pool-1-thread-1] INFO BuildController:default- Initializing build jvm 1| 2007-10-12 13:00:00,022 [pool-1-thread-1] INFO BuildController:default- Starting build of IPLocks Site jvm 1| 2007-10-12 13:00:00,038 [pool-1-thread-1] INFO
[jira] Created: (MRM-539) Make security level of repository more obvious on admin/repositories screen.
Make security level of repository more obvious on admin/repositories screen. Key: MRM-539 URL: http://jira.codehaus.org/browse/MRM-539 Project: Archiva Issue Type: Improvement Components: Users/Security Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Priority: Minor Make the repositories screen show the security level of the repository. Make the repository configuration process simplify the role assignments. Pre-configure the default-archiva.xml repositories for public, read-only security level. Technical Details: 1) Add a field ManagedRepositoryConfiguration.security (with possible value: public-read-only, public-read-write, access-controlled) 2) Configure the default-archiva.xml with that field set true. 3) Configure the UI for repositories to show/set/change that value. 4) Integrate the guest user role assignments to that field. -- 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-398) configure guest access by default for pre-configured repositories
[ http://jira.codehaus.org/browse/MRM-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Joakim Erdfelt closed MRM-398. -- Resolution: Fixed Fixed in archiva/trunk revision Newly created repositories are setup to be automatically assigned to the guest user in read-only mode. There are no provisions in redback to assign roles on first startup only. Using redback ALONE to automatically assign the read-only role to the shipped repositories is not possible. Closing issue. We can't hard-code the repository ids either, as corporate installations of archiva will often pre-configure their archiva.xml before starting the first time. Created a new jira MRM-539 for alternative approach that was poo-poo'd in an earlier comment by brett in this jira. configure guest access by default for pre-configured repositories - Key: MRM-398 URL: http://jira.codehaus.org/browse/MRM-398 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0-alpha-1 Reporter: Brett Porter Assignee: Joakim Erdfelt Fix For: 1.0-beta-3 I think it makes sense for repositories to be readable by guests by default for a good OOTB experience. -- 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-535) metadata-updater is changing lastUpdating timestamp when it shouldn't
[ http://jira.codehaus.org/browse/MRM-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109806 ] Joakim Erdfelt commented on MRM-535: It needs to keep up that field to date. But going backwards on the lastUpdated field is just bad. What is being implemented and tested on archiva/trunk right now. (project view is working, version view is not, yet) * Never decrease the value of the lastUpdated field. Technique 1) Read the existing metadata's lastUpdated timestamp (if it exists) 2) Iterate through the artifacts on the managed repository for their timestamps. (filename or file last modified date/time). 3) Iterate through the proxy metadata files for their lastUpdated. 4) Use the highest value found. metadata-updater is changing lastUpdating timestamp when it shouldn't - Key: MRM-535 URL: http://jira.codehaus.org/browse/MRM-535 Project: Archiva Issue Type: Bug Components: repository scanning Environment: JDK 1.5.0_11, Maven 2.0.7 Reporter: ajbanck Assignee: Joakim Erdfelt Priority: Minor Fix For: 1.0-beta-3 This is a bit of a trivial 'bug' and the result is not harmfull, but I think the metadata-updater should not change data that is valid. As far as I could find the lastUpdated field is the timestamp on which the metadata was last updated, so should not be touched in this case. During scanning, some (~200) maven-metadata.xml files are updated in my repository . The metadata being updated is: ?xml version=1.0 encoding=UTF-8?metadata groupIdcom.informatica.profiling.services/groupId artifactIdprofiling-model-persist/artifactId version1.0-SNAPSHOT/version versioning snapshot timestamp20070213.050129/timestamp buildNumber79/buildNumber /snapshot lastUpdated20070213050130/lastUpdated /versioning /metadata After update the lastUpdated field is changed to 20070213050129: lastUpdated20070213050129/lastUpdated As far as I could find the lastUpdated field is the timestamp on which the metadata was last updated, so should not be touched in this case. Scanlog: 2007-10-05 14:38:41,043 [pool-2-thread-1] DEBUG org.apache.maven.archiva.repository.scanner.RepositoryScanner:default - Sending to consumer: metadata-updater 2007-10-05 14:38:41,090 [pool-2-thread-1] INFO org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer:metadata-updater - Updated metadata: com/xxx/profiling/services/profiling-model-persist/1.0-SNAPSHOT/maven-metadata.xml 2007-10-05 14:38:46,356 [pool-2-thread-1] INFO org.apache.maven.archiva.consumers.KnownRepositoryContentConsumer:metadata-updater - Updated metadata: com/xxx/profiling/services/profiling-model-persist/maven-metadata.xml -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (CONTINUUM-1520) Scheduler is unstable
[ http://jira.codehaus.org/browse/CONTINUUM-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran updated CONTINUUM-1520: Fix Version/s: 1.1-beta-4 Scheduler is unstable - Key: CONTINUUM-1520 URL: http://jira.codehaus.org/browse/CONTINUUM-1520 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1-beta-3 Environment: xp,jse5,maven2.07,shell project Reporter: Dan Tran Fix For: 1.1-beta-4 Hi have 2 project groups,each contains a single build defintion shell project. The first one use default scheduler ( build a site) the second one in the another group uses 10 minute recurrence schedule. What i see is the scheduler only wake up at the hour and then the first 10 min of hour. basicly i dont see 10 minute schedule waking up every 10 minute here is the log jvm 1| 2007-10-12 12:00:00,016 [defaultScheduler_Worker-6] INFO SchedulesActivator:default - Executing build job (DEFAULT_SCHEDULE)... jvm 1| 2007-10-12 12:00:00,016 [defaultScheduler_Worker-6] INFO Continuum:default - Enqueuing 'IPLocks Site' (Build defini tion id=21). jvm 1| 2007-10-12 12:00:00,016 [pool-1-thread-1] INFO BuildController:default- Initializing build jvm 1| 2007-10-12 12:00:00,016 [pool-1-thread-1] INFO BuildController:default- Starting build of IPLocks Site jvm 1| 2007-10-12 12:00:00,047 [pool-1-thread-1] INFO BuildController:default- Updating working dir jvm 1| 2007-10-12 12:00:00,047 [pool-1-thread-1] INFO BuildController:default- Performing action check-working-directory jvm 1| 2007-10-12 12:00:00,047 [pool-1-thread-1] INFO BuildController:default- Performing action update-working-directory-from- scm jvm 1| 2007-10-12 12:00:00,063 [pool-1-thread-1] INFO ContinuumScm:default - Updating project: id: '6', name 'IPLocks Site'. jvm 1| 2007-10-12 12:00:00,125 [pool-1-thread-1] INFO ScmManager:default - Executing: cmd.exe /X /C 'svn --non-interactive update' jvm 1| 2007-10-12 12:00:00,125 [pool-1-thread-1] INFO ScmManager:default - Working directory: C:\dev\continuum\working-dire ctory\1.1\6 jvm 1| 2007-10-12 12:00:01,109 [pool-1-thread-1] INFO BuildController:default- Merging SCM results jvm 1| 2007-10-12 12:00:01,125 [pool-1-thread-1] INFO BuildController:default- The project was not built because no changes wer e detected in sources since the last build. jvm 1| 2007-10-12 12:00:01,125 [pool-1-thread-1] INFO BuildController:default- No changes, not building jvm 1| 2007-10-12 12:10:00,012 [defaultScheduler_Worker-0] INFO SchedulesActivator:default - Executing build job (Run every 10 Minute)... jvm 1| 2007-10-12 12:10:00,012 [defaultScheduler_Worker-0] INFO Continuum:default - Enqueuing 'Sentinel - Continuous Build ' (Build definition id=38). jvm 1| 2007-10-12 12:10:00,012 [pool-1-thread-1] INFO BuildController:default- Initializing build jvm 1| 2007-10-12 12:10:00,027 [pool-1-thread-1] INFO BuildController:default- Starting build of Sentinel - Continuous Build jvm 1| 2007-10-12 12:10:00,043 [pool-1-thread-1] INFO BuildController:default- Updating working dir jvm 1| 2007-10-12 12:10:00,043 [pool-1-thread-1] INFO BuildController:default- Performing action check-working-directory jvm 1| 2007-10-12 12:10:00,043 [pool-1-thread-1] INFO BuildController:default- Performing action update-working-directory-from- scm jvm 1| 2007-10-12 12:10:00,058 [pool-1-thread-1] INFO ContinuumScm:default - Updating project: id: '22', name 'Sentinel - Con tinuous Build'. jvm 1| 2007-10-12 12:10:00,137 [pool-1-thread-1] INFO ScmManager:default - Executing: cmd.exe /X /C 'svn --non-interactive update' jvm 1| 2007-10-12 12:10:00,137 [pool-1-thread-1] INFO ScmManager:default - Working directory: C:\dev\continuum\working-dire ctory\1.1\22 jvm 1| 2007-10-12 12:10:01,105 [pool-1-thread-1] INFO BuildController:default- Merging SCM results jvm 1| 2007-10-12 12:10:01,105 [pool-1-thread-1] INFO BuildController:default- The project was not built because no changes wer e detected in sources since the last build. jvm 1| 2007-10-12 12:10:01,105 [pool-1-thread-1] INFO BuildController:default- No changes, not building jvm 1| 2007-10-12 13:00:00,022 [defaultScheduler_Worker-14] INFO SchedulesActivator:default - Executing build job (DEFAULT_SCHEDULE)... jvm 1| 2007-10-12 13:00:00,022 [defaultScheduler_Worker-14] INFO Continuum:default - Enqueuing
[jira] Commented: (CONTINUUM-358) User Authentication via LDAP
[ http://jira.codehaus.org/browse/CONTINUUM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109807 ] Christian Schneider commented on CONTINUUM-358: --- Why do you think the ldap roles have to be writeable? I think it would be completely sufficient to pull roles from ldap and do the changes with the normal ldap administration tools. In most organisations the admins of a system like continuum will not have direct write support to the ldap server anyway. Often changes to roles have to be done with a special web front end. User Authentication via LDAP Key: CONTINUUM-358 URL: http://jira.codehaus.org/browse/CONTINUUM-358 Project: Continuum Issue Type: New Feature Components: Web interface Reporter: Frank Zhao Assignee: Jesse McConnell Fix For: 1.1-beta-3 Please add LDAP support for the user authentication in Continuum user management function. -- 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-539) Make security level of repository more obvious on admin/repositories screen.
[ http://jira.codehaus.org/browse/MRM-539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109809 ] Wendy Smoak commented on MRM-539: - From MRM-398, Brett's comment: I would suggest the best way to do this is to allow assignment of roles as a step in repository creation rather than introducing a new flag that is tied to a role. Make security level of repository more obvious on admin/repositories screen. Key: MRM-539 URL: http://jira.codehaus.org/browse/MRM-539 Project: Archiva Issue Type: Improvement Components: Users/Security Affects Versions: 1.0-beta-2 Reporter: Joakim Erdfelt Priority: Minor Make the repositories screen show the security level of the repository. Make the repository configuration process simplify the role assignments. Pre-configure the default-archiva.xml repositories for public, read-only security level. Technical Details: 1) Add a field ManagedRepositoryConfiguration.security (with possible value: public-read-only, public-read-write, access-controlled) 2) Configure the default-archiva.xml with that field set true. 3) Configure the UI for repositories to show/set/change that value. 4) Integrate the guest user role assignments to that field. -- 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-1520) Scheduler is unstable
[ http://jira.codehaus.org/browse/CONTINUUM-1520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dan Tran closed CONTINUUM-1520. --- Resolution: Cannot Reproduce sorry, my 10 minute schedule is wrong, continuum behaves correctly Scheduler is unstable - Key: CONTINUUM-1520 URL: http://jira.codehaus.org/browse/CONTINUUM-1520 Project: Continuum Issue Type: Bug Components: Core system Affects Versions: 1.1-beta-3 Environment: xp,jse5,maven2.07,shell project Reporter: Dan Tran Fix For: 1.1-beta-4 Hi have 2 project groups,each contains a single build defintion shell project. The first one use default scheduler ( build a site) the second one in the another group uses 10 minute recurrence schedule. What i see is the scheduler only wake up at the hour and then the first 10 min of hour. basicly i dont see 10 minute schedule waking up every 10 minute here is the log jvm 1| 2007-10-12 12:00:00,016 [defaultScheduler_Worker-6] INFO SchedulesActivator:default - Executing build job (DEFAULT_SCHEDULE)... jvm 1| 2007-10-12 12:00:00,016 [defaultScheduler_Worker-6] INFO Continuum:default - Enqueuing 'IPLocks Site' (Build defini tion id=21). jvm 1| 2007-10-12 12:00:00,016 [pool-1-thread-1] INFO BuildController:default- Initializing build jvm 1| 2007-10-12 12:00:00,016 [pool-1-thread-1] INFO BuildController:default- Starting build of IPLocks Site jvm 1| 2007-10-12 12:00:00,047 [pool-1-thread-1] INFO BuildController:default- Updating working dir jvm 1| 2007-10-12 12:00:00,047 [pool-1-thread-1] INFO BuildController:default- Performing action check-working-directory jvm 1| 2007-10-12 12:00:00,047 [pool-1-thread-1] INFO BuildController:default- Performing action update-working-directory-from- scm jvm 1| 2007-10-12 12:00:00,063 [pool-1-thread-1] INFO ContinuumScm:default - Updating project: id: '6', name 'IPLocks Site'. jvm 1| 2007-10-12 12:00:00,125 [pool-1-thread-1] INFO ScmManager:default - Executing: cmd.exe /X /C 'svn --non-interactive update' jvm 1| 2007-10-12 12:00:00,125 [pool-1-thread-1] INFO ScmManager:default - Working directory: C:\dev\continuum\working-dire ctory\1.1\6 jvm 1| 2007-10-12 12:00:01,109 [pool-1-thread-1] INFO BuildController:default- Merging SCM results jvm 1| 2007-10-12 12:00:01,125 [pool-1-thread-1] INFO BuildController:default- The project was not built because no changes wer e detected in sources since the last build. jvm 1| 2007-10-12 12:00:01,125 [pool-1-thread-1] INFO BuildController:default- No changes, not building jvm 1| 2007-10-12 12:10:00,012 [defaultScheduler_Worker-0] INFO SchedulesActivator:default - Executing build job (Run every 10 Minute)... jvm 1| 2007-10-12 12:10:00,012 [defaultScheduler_Worker-0] INFO Continuum:default - Enqueuing 'Sentinel - Continuous Build ' (Build definition id=38). jvm 1| 2007-10-12 12:10:00,012 [pool-1-thread-1] INFO BuildController:default- Initializing build jvm 1| 2007-10-12 12:10:00,027 [pool-1-thread-1] INFO BuildController:default- Starting build of Sentinel - Continuous Build jvm 1| 2007-10-12 12:10:00,043 [pool-1-thread-1] INFO BuildController:default- Updating working dir jvm 1| 2007-10-12 12:10:00,043 [pool-1-thread-1] INFO BuildController:default- Performing action check-working-directory jvm 1| 2007-10-12 12:10:00,043 [pool-1-thread-1] INFO BuildController:default- Performing action update-working-directory-from- scm jvm 1| 2007-10-12 12:10:00,058 [pool-1-thread-1] INFO ContinuumScm:default - Updating project: id: '22', name 'Sentinel - Con tinuous Build'. jvm 1| 2007-10-12 12:10:00,137 [pool-1-thread-1] INFO ScmManager:default - Executing: cmd.exe /X /C 'svn --non-interactive update' jvm 1| 2007-10-12 12:10:00,137 [pool-1-thread-1] INFO ScmManager:default - Working directory: C:\dev\continuum\working-dire ctory\1.1\22 jvm 1| 2007-10-12 12:10:01,105 [pool-1-thread-1] INFO BuildController:default- Merging SCM results jvm 1| 2007-10-12 12:10:01,105 [pool-1-thread-1] INFO BuildController:default- The project was not built because no changes wer e detected in sources since the last build. jvm 1| 2007-10-12 12:10:01,105 [pool-1-thread-1] INFO BuildController:default- No changes, not building jvm 1| 2007-10-12 13:00:00,022 [defaultScheduler_Worker-14] INFO SchedulesActivator:default - Executing build job (DEFAULT_SCHEDULE)... jvm 1| 2007-10-12 13:00:00,022
[jira] Commented: (CONTINUUM-358) User Authentication via LDAP
[ http://jira.codehaus.org/browse/CONTINUUM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109810 ] Jesse McConnell commented on CONTINUUM-358: --- well maybe your right...I was just thinking in terms of retaining that functionality from the edit user page since its more dynamic what with role creations for each new project group, etc... User Authentication via LDAP Key: CONTINUUM-358 URL: http://jira.codehaus.org/browse/CONTINUUM-358 Project: Continuum Issue Type: New Feature Components: Web interface Reporter: Frank Zhao Assignee: Jesse McConnell Fix For: 1.1-beta-3 Please add LDAP support for the user authentication in Continuum user management function. -- 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-398) configure guest access by default for pre-configured repositories
[ http://jira.codehaus.org/browse/MRM-398?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109808 ] Wendy Smoak commented on MRM-398: - The solution as described does not match the summary on this issue, so I don't think it should be closed as fixed. I don't like defaulting newly _created_ repositories to be visible to the guest user. That doesn't happen in Continuum-- newly added groups are not visible unless you grant roles. As I understand the request, it was to be able to pre-configure guest access to some known repositories. Brett? configure guest access by default for pre-configured repositories - Key: MRM-398 URL: http://jira.codehaus.org/browse/MRM-398 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0-alpha-1 Reporter: Brett Porter Assignee: Joakim Erdfelt Fix For: 1.0-beta-3 I think it makes sense for repositories to be readable by guests by default for a good OOTB experience. -- 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: (MSANDBOX-37) [jxr] Renamed packages org.apache.forrest.forrestdoc.* to org.apache.maven.jxr.*
[jxr] Renamed packages org.apache.forrest.forrestdoc.* to org.apache.maven.jxr.* Key: MSANDBOX-37 URL: http://jira.codehaus.org/browse/MSANDBOX-37 Project: Maven 2.x Sandbox Issue Type: Task Components: jxr Reporter: Vincent Siveton Assignee: Vincent Siveton -- 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-33) [jxr] Split forrestdoc source to provide more artifacts
[ http://jira.codehaus.org/browse/MSANDBOX-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109819 ] Vincent Siveton commented on MSANDBOX-33: - first step at least in r584307 [jxr] Split forrestdoc source to provide more artifacts --- Key: MSANDBOX-33 URL: http://jira.codehaus.org/browse/MSANDBOX-33 Project: Maven 2.x Sandbox Issue Type: Task Components: jxr Reporter: Vincent Siveton Not sure about this one in the Forrest way, but it seems to be a good idea to split the forrestdoc source to provide 3 artifacts: * one for javasrc * one for ant * one for js Based on http://issues.apache.org/jira/browse/FOR-1028 -- 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: (MSANDBOX-37) [jxr] Renamed packages org.apache.forrest.forrestdoc.* to org.apache.maven.jxr.*
[ http://jira.codehaus.org/browse/MSANDBOX-37?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vincent Siveton closed MSANDBOX-37. --- Resolution: Fixed Done in r584313 [jxr] Renamed packages org.apache.forrest.forrestdoc.* to org.apache.maven.jxr.* Key: MSANDBOX-37 URL: http://jira.codehaus.org/browse/MSANDBOX-37 Project: Maven 2.x Sandbox Issue Type: Task Components: jxr Reporter: Vincent Siveton Assignee: Vincent Siveton -- 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-398) configure guest access by default for pre-configured repositories
[ http://jira.codehaus.org/browse/MRM-398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Wendy Smoak reopened MRM-398: - Reopening for discussion. configure guest access by default for pre-configured repositories - Key: MRM-398 URL: http://jira.codehaus.org/browse/MRM-398 Project: Archiva Issue Type: Bug Components: Users/Security Affects Versions: 1.0-alpha-1 Reporter: Brett Porter Assignee: Joakim Erdfelt Fix For: 1.0-beta-3 I think it makes sense for repositories to be readable by guests by default for a good OOTB experience. -- 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-1519) Continuum does not respect build order for flat projects
[ http://jira.codehaus.org/browse/CONTINUUM-1519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Siarhei Dudzin updated CONTINUUM-1519: -- Attachment: TEST-CONTINUUM-1519.zip Ok, attaching the example project. As you can see it adds the projects in alphabetic order. Another problem is that relative both paths and scm connection url for sub-projects are also not respected - I have to change scm urls in continuum for each project except project 'a' (the parent project). Project a is also the project I add (as parent ) to continuum. While reactor build order (log from maven): [INFO] Reactor build order: [INFO] a [INFO] e [INFO] d [INFO] c [INFO] b This is the order what I get in continuum: Project Name a b c d e Hope this helps. Continuum does not respect build order for flat projects Key: CONTINUUM-1519 URL: http://jira.codehaus.org/browse/CONTINUUM-1519 Project: Continuum Issue Type: Bug Affects Versions: 1.1-beta-3 Environment: Windows XP/2003 Server, Maven 2.0.7 Reporter: Siarhei Dudzin Priority: Blocker Attachments: TEST-CONTINUUM-1519.zip When adding maven 2 projects with flat project layout continuum sorts the projects build sequence by alphabet thus braking builds. Previous version did respect reactor build sequence and '--non-recursive' option allowed to build flat projects independently but still in the right order. This is a very blocking issue for us because we are forced atm to use flat project structure. -- 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-358) User Authentication via LDAP
[ http://jira.codehaus.org/browse/CONTINUUM-358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109825 ] Christian Schneider commented on CONTINUUM-358: --- I think it is quite useful to distinguish between groups in ldap that represent organizational groups like a team and authorizational groups in continuum that mean the right to do something in the project. A good combination could be to reference organizational groups read only in ldap and use them to populate authorization groups that live in the continuum database. So for example you could have a project crm in contiuum and give the team crm_team from ldap the necessary rights in continuum by populating the authorization group crm_project_admins. This two level aproach to authorization is a very useful thing in big companies. User Authentication via LDAP Key: CONTINUUM-358 URL: http://jira.codehaus.org/browse/CONTINUUM-358 Project: Continuum Issue Type: New Feature Components: Web interface Reporter: Frank Zhao Assignee: Jesse McConnell Fix For: 1.1-beta-3 Please add LDAP support for the user authentication in Continuum user management function. -- 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
