[jira] Created: (CONTINUUM-513) Implement 'remember me' in the web interface
Implement 'remember me' in the web interface Key: CONTINUUM-513 URL: http://jira.codehaus.org/browse/CONTINUUM-513 Project: Continuum Type: New Feature Reporter: Trygve Laugstol -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[continuum build - FAILED - update] Wed Dec 14 16:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051214.163000.txt
[jira] Created: (CONTINUUM-514) Consistency in layout of Continuum download page to the Maven 2.0 download page
Consistency in layout of Continuum download page to the Maven 2.0 download page --- Key: CONTINUUM-514 URL: http://jira.codehaus.org/browse/CONTINUUM-514 Project: Continuum Type: Task Components: Documentation Versions: 1.0.2 Reporter: Natalie Burdick Fix For: 1.0.2 Please update the http://maven.apache.org/continuum/download.html page to match the http://maven.apache.org/download.html? page -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[continuum build - FAILED - update] Wed Dec 14 17:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051214.17.txt
Re: [Proposal] Continuum refactoring
+1 I'm all for splitting up into action components, but retaining a Continuum interface as a single entry point to those - Brett John Casey wrote: I think we have to be careful when splitting up a public api like this. It's possible Continuum may need to be embedded someday, and if so, it would be much better to have a single interface for controlling it...even if it means that interface delegates most of its work. While I think you can probably factor out a lot of the actual logic, we need to preserve that coherent, single-interface accessibility IMO. Besides, we do still have to maintain public API compatibility, since it's only a x.y release... My 2 cents. -john Emmanuel Venisse wrote: Hi, I'd like to know your opinions about the continuum refactoring for 1.1 What we'll do? Replace plexus-summit/velocity by JSP/WebWork/SiteMesh What i'd like to do? Actually, DefaultContinuum class is our centralized code class. With a framework like webwork, i think we can improve the architecture by splitting it with this : - all data manipulations (CRUD) will be in several DAO classes - all utility methods (is*InQueue, checkoutProject, buildProject* will be in several utility classes (or action classes in webwork terms) - in DefaultContinuum, we'll keep only initialization methods With this refactoring, i think it will be more easy to migrate to webwork, and maintenance will be more easy. WDYT? Emmanuel
[continuum build - FAILED - update] Wed Dec 14 18:00:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051214.180001.txt
Re: [Proposal] Continuum refactoring
ok, so we'll have some data object store access (ProjectStore, BuildStore...) and DefaultContinuum will use them. Webwork actions will use them too or they'll use Continuum interface? Emmanuel Brett Porter a écrit : +1 I'm all for splitting up into action components, but retaining a Continuum interface as a single entry point to those - Brett John Casey wrote: I think we have to be careful when splitting up a public api like this. It's possible Continuum may need to be embedded someday, and if so, it would be much better to have a single interface for controlling it...even if it means that interface delegates most of its work. While I think you can probably factor out a lot of the actual logic, we need to preserve that coherent, single-interface accessibility IMO. Besides, we do still have to maintain public API compatibility, since it's only a x.y release... My 2 cents. -john Emmanuel Venisse wrote: Hi, I'd like to know your opinions about the continuum refactoring for 1.1 What we'll do? Replace plexus-summit/velocity by JSP/WebWork/SiteMesh What i'd like to do? Actually, DefaultContinuum class is our centralized code class. With a framework like webwork, i think we can improve the architecture by splitting it with this : - all data manipulations (CRUD) will be in several DAO classes - all utility methods (is*InQueue, checkoutProject, buildProject* will be in several utility classes (or action classes in webwork terms) - in DefaultContinuum, we'll keep only initialization methods With this refactoring, i think it will be more easy to migrate to webwork, and maintenance will be more easy. WDYT? Emmanuel
[jira] Updated: (CONTINUUM-514) Consistency in layout of Continuum download page to the Maven 2.0 download page
[ http://jira.codehaus.org/browse/CONTINUUM-514?page=all ] Brett Porter updated CONTINUUM-514: --- Fix Version: (was: 1.0.2) 1.1 Consistency in layout of Continuum download page to the Maven 2.0 download page --- Key: CONTINUUM-514 URL: http://jira.codehaus.org/browse/CONTINUUM-514 Project: Continuum Type: Task Components: Documentation Versions: 1.0.2 Reporter: Natalie Burdick Fix For: 1.1 Please update the http://maven.apache.org/continuum/download.html page to match the http://maven.apache.org/download.html? page -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[continuum build - FAILED - update] Wed Dec 14 18:30:02 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051214.183002.txt
[jira] Commented: (SCM-114) Clientspec naming
[ http://jira.codehaus.org/browse/SCM-114?page=comments#action_53418 ]
Neil Padgen commented on SCM-114:
-
We wouldn't be able to use the last directory in the SCM URL, as we use that
last directory for branches; e.g. //depot/project1/MAIN and
//depot/project1/RELEASE. The RELEASE branch is derived from the MAIN branch,
so each contains its own project.xml. Using the last directory, we'd need lots
of clients called MAIN-${hostname}-mavenscm - obviously that wouldn't work for
us.
If you can identify that the scm plugin is being called from Continuum, you
could maybe adopt Wim's suggestion and call it something like
continuum-${basename_of_working_directory}-${hostname}-${user}-${project}
which would produce something like continuum-16-buildhost-user-foobar for
Mike's example, or continuum-16-buildhost-user-MAIN for us - which would be
fine, as the number 16 would be unique per project within Continuum.
Clientspec naming
-
Key: SCM-114
URL: http://jira.codehaus.org/browse/SCM-114
Project: Maven SCM
Type: Improvement
Components: maven-scm-provider-perforce
Versions: 1.0-beta-3
Reporter: mike perham
Fix For: 1.0-beta-3
Several people have expressed more than a passing interest in how the
Perforce clientspec is named by Maven SCM. The name needs to be
autogenerated and unique for each Continuum project build. Currently I am
thinking something like:
${project}-${user}-${hostname}-mavenscm
Emmannuel, does the SCM subsystem have access to the name of the project
being built? If not, I can just use the name of the last directory in the
SCM URL for the name of the project: //depot/projects/foobar would mean that
${project} = foobar.
And just head off the inevitable question: you cannot set P4CLIENT for this
because Continuum may build several different projects and they each need a
unique clientspec.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SCM-113) Support persistent and transient clientspecs
[ http://jira.codehaus.org/browse/SCM-113?page=comments#action_53419 ] mike perham commented on SCM-113: - Good idea on the Description. Note that Maven SCM does not know anything about the context in which it is running. It does not know that it is running for Continuum, release or any other client. It just knows that someone asked it to perform a checkout operation so I would not be able to add the for part of your example description. Basically the only context I have is the base directory, the SCM tag and the SCM URL. Support persistent and transient clientspecs Key: SCM-113 URL: http://jira.codehaus.org/browse/SCM-113 Project: Maven SCM Type: New Feature Components: maven-scm-provider-perforce Versions: 1.0-beta-3 Reporter: mike perham Fix For: 1.0-beta-3 Continuum needs a persistent clientspec because it needs to update a project's source code and build it once an hour. On larger projects a complete resync might take 10-20 minutes so it is necessary to keep a clientspec around for that Continuum project build so syncs only take a few seconds. However, the Maven Release plugin may need to be used by tens or even hundreds of developers to release any number of small modules. Currently this would mean lots of clientspecs being created for the release checkout which are reused very infrequently. Here I would prefer to create the clientspec, do the checkout, build and then delete the clientspec. This is what I term a transient clientspec. The Perforce plugin would need to default to one mode and support some sort of hint which tells it which mode to operate in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (SCM-114) Clientspec naming
[ http://jira.codehaus.org/browse/SCM-114?page=comments#action_53464 ]
Zabli commented on SCM-114:
---
The perforce plugin ignores the environment variables P4CLIENT, P4PASSWD.
The plugin should check these variable and then use them if they are present.
Clientspec naming
-
Key: SCM-114
URL: http://jira.codehaus.org/browse/SCM-114
Project: Maven SCM
Type: Improvement
Components: maven-scm-provider-perforce
Versions: 1.0-beta-3
Reporter: mike perham
Fix For: 1.0-beta-3
Several people have expressed more than a passing interest in how the
Perforce clientspec is named by Maven SCM. The name needs to be
autogenerated and unique for each Continuum project build. Currently I am
thinking something like:
${project}-${user}-${hostname}-mavenscm
Emmannuel, does the SCM subsystem have access to the name of the project
being built? If not, I can just use the name of the last directory in the
SCM URL for the name of the project: //depot/projects/foobar would mean that
${project} = foobar.
And just head off the inevitable question: you cannot set P4CLIENT for this
because Continuum may build several different projects and they each need a
unique clientspec.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Ruby Mojo Support
Some of you expressed an interest. Please note that it is close, but not quite, ready to be tested on a wider scale (such as the users list). I'm still stummped at how to inject certain values into the Ruby object. But the projects and sourcecode can be downloaded from here: http://www.propellors.net/rubymojo/ Its still very much alpha, email me if you have problems. Thanks! Eric Oh right, I almost forgot. I have been unsuccessful at adding dependencies to the maven-plugin-plugin project via my plugin's POM. For the time being I just build my own maven-plugin-plugin with maven-script-ruby added to its POM. If anyone can get this working without modifying maven-plugin-plugin (by either maven-script-ruby or ruby-scripted plugins that use it) I would be forever grateful! Also: You must have Ruby 1.8 or greater installed and in your path.
[jira] Created: (MNG-1832) built-in property containing current timestamp
built-in property containing current timestamp -- Key: MNG-1832 URL: http://jira.codehaus.org/browse/MNG-1832 Project: Maven 2 Type: New Feature Versions: 2.0.1 Reporter: Michal Stochmialek Current timestamp (time or date) is often used while filtering resources or creating manifest in ant builds. There is no equivalent in maven. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MRM-53) repoort on invalid POMs
[ http://jira.codehaus.org/browse/MRM-53?page=all ] Edwin Punzalan closed MRM-53: - Resolution: Fixed Patch applied, thanks! repoort on invalid POMs --- Key: MRM-53 URL: http://jira.codehaus.org/browse/MRM-53 Project: Maven Repository Manager Type: Task Components: reporting, discovery Reporter: Brett Porter Assignee: Maria Odea Ching Fix For: 1.0-alpha-1 Attachments: MRM-53-repository-manager-reports-standard.patch Time Spent: 10 hours, 30 minutes Remaining: 0 minutes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1833) war:clean goal
[ http://jira.codehaus.org/browse/MNG-1833?page=comments#action_53398 ] Olivier Lamy commented on MNG-1833: --- Look at MNG-1655. war:clean goal -- Key: MNG-1833 URL: http://jira.codehaus.org/browse/MNG-1833 Project: Maven 2 Type: New Feature Components: maven-war-plugin Reporter: Jochen Wiedmann The war:explode goal deploys an application to a webapp directory. However, it only overrides existing files and doesn't remove files. I suggest to add a new goal mvn:clean, which cleans the webapp directory. Things to discuss: - Should the webapp directory be removed or only the webapp directories contents. IMO the former. Is a configurable option required? - Is it possible to bind this to the maven clean plugin somehow? For example, if the maven clean plugin had a new goal clean:appclean, or something like that, then one might make sure, that clean:appclean invokes war:clean. How could that be done? I am ready to provide a patch, if someone signals, that the patch might be accepted and signals the way in which the above questions should be resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1833) war:clean goal
[ http://jira.codehaus.org/browse/MNG-1833?page=all ] Jochen Wiedmann closed MNG-1833: Resolution: Duplicate Sorry, I missed MNG-1655. Clearly, this is a duplicate. However, given the fact that closing MNG-1655 in favour of MNG-1669 (with a more complex patch) and closing the latter in favour of MNG-1683 (with an even more complicated patch), I wonder whether we should better reopen MNG-1655 with a simple patch. To me, the simple part has far better chances to enter the trunk. war:clean goal -- Key: MNG-1833 URL: http://jira.codehaus.org/browse/MNG-1833 Project: Maven 2 Type: New Feature Components: maven-war-plugin Reporter: Jochen Wiedmann The war:explode goal deploys an application to a webapp directory. However, it only overrides existing files and doesn't remove files. I suggest to add a new goal mvn:clean, which cleans the webapp directory. Things to discuss: - Should the webapp directory be removed or only the webapp directories contents. IMO the former. Is a configurable option required? - Is it possible to bind this to the maven clean plugin somehow? For example, if the maven clean plugin had a new goal clean:appclean, or something like that, then one might make sure, that clean:appclean invokes war:clean. How could that be done? I am ready to provide a patch, if someone signals, that the patch might be accepted and signals the way in which the above questions should be resolved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1509) Profile activation by os doesn't work
[ http://jira.codehaus.org/browse/MNG-1509?page=comments#action_53401 ]
David Boden commented on MNG-1509:
--
Morning. This is marked as fixed in 2.0.1 (which is now available on the
ibiblio repository).
I'm using the following:
activation
os
familywindows/family
/os
/activation
This doesn't cause a profile to be activated when building on my Windows XP
machine. If I set activeByDefault/ then my build works and includes the
profile as expected.
Help appreciated.
Moreover, I've looked through the commons-lang API documentation and source
code. I can't find reference to anything resembling the concept of an operating
system family identifier (e.g. windows or unix).
import org.apache.commons.lang.SystemUtils;
public class CommonsLang {
public static void main(String[] args) {
System.out.println(IsOSWindows: + SystemUtils.IS_OS_WINDOWS);
System.out.println(OSName: + SystemUtils.OS_NAME);
System.out.println(OSArch: + SystemUtils.OS_ARCH);
System.out.println(OSVersion: + SystemUtils.OS_VERSION);
}
}
--- Output ---
IsOSWindows: true
OSName: Windows XP
OSArch: x86
OSVersion: 5.1
--- End Output ---
Setting osnameWindows XP/name/os doesn't do the trick either.
Profile activation by os doesn't work
-
Key: MNG-1509
URL: http://jira.codehaus.org/browse/MNG-1509
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0
Environment: Ubuntu 5.10 maven 2.0
Reporter: Bernd Bohmann
Assignee: John Casey
Fix For: 2.0.1
Attachments: DefaultProfileManagerTest.java.patch,
OperatingSystemProfileActivator.java.patch,
OperatingSystemProfileActivator.java.patch, components.xml.patch
Profile activation by os doesn't work.
OperatingSystemProfileActivator is missing in components.xml.
Implementation of OperatingSystemProfileActivator.isActive is wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1834) maven-reporting-impl version 2.0.1 missing component org.codehaus.doxia.site.renderer.SiteRenderer
maven-reporting-impl version 2.0.1 missing component
org.codehaus.doxia.site.renderer.SiteRenderer
--
Key: MNG-1834
URL: http://jira.codehaus.org/browse/MNG-1834
Project: Maven 2
Type: Bug
Versions: 2.0.1
Environment: all
Reporter: Olivier Lamy
Priority: Blocker
With using maven-reporting-impl version 2.0.1. (updating my pom to all maven*
2.0.1)
I have the following stack trace :
ComponentRequirement{role='org.codehaus.doxia.site.renderer.SiteRenderer',
roleHint='null', fieldName='siteRenderer'} was missing.
The component org.codehaus.doxia.site.renderer.SiteRenderer is missing.
The workaroung is using maven-reporting-impl version 2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1835) Ability to specify more than 1 check configuration file and file sets for each of these configurations
Ability to specify more than 1 check configuration file and file sets for each of these configurations -- Key: MNG-1835 URL: http://jira.codehaus.org/browse/MNG-1835 Project: Maven 2 Type: Improvement Components: maven-checkstyle-plugin Reporter: Fabrice BELLINGARD I'm using Eclipse Checkstyle Plug-in, and there's a functionnality I enjoy a lot: the ability to specify as many check configuration files as I want for a projet, and to tell which file sets those configurations should be run on. And as I use this functionnality extensively, I'd love to have it also in the Maven Checkstyle Plug-in :o) To get a look at what the Eclipse plugin does: http://eclipse-cs.sourceforge.net/advanced_file_sets.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1836) inherited plugin dependencies
inherited plugin dependencies
-
Key: MNG-1836
URL: http://jira.codehaus.org/browse/MNG-1836
Project: Maven 2
Type: Bug
Versions: 2.0
Reporter: Gilles Scokart
I have project composed of a reactor/parent pom.xml and a few module.
In the parent pom.xml, I have somthing like this :
plugins
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
!-- The assembly plugin is not flexible
enought for what we have to do --
phasepackage/phase
configuration
tasks
property name=version.number
value=${project.version}/
ant
antfile=src/build/build.xml inheritRefs=true/
/tasks
/configuration
goalsgoalrun/goal/goals
/execution
/executions
inheritedfalse/inherited
/plugin
...
/plugins
In one of the module, I have
plugins
...
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phasegenerate-test-sources/phase
configuration
tasks
ant
antfile=src/test/ant/build.xml inheritRefs=true/
/tasks
testSourceRoottarget/generated-sources/nextmock/testSourceRoot
/configuration
goals
goalrun/goal
/goals
/execution
/executions
dependencies
dependency
!-- Required to use javac --
groupIdsun.jdk/groupId
artifactIdtools/artifactId
version1.5/version
scopesystem/scope
systemPath${java.home}/../lib/tools.jar/systemPath
/dependency
/dependencies
/plugin
...
/plugins
It seems that the dependencies is in the sub-module is not loaded, probably
because the plugin is loaded in the parent pom (or in the reactor pom which is
the same in many cases) and not updated afterward.
The simple work around is to place the dependencies into the reactor plugin
declaration. (A strange thing is that the dependecy doesn't need to be present
in the module declaration anymore in that case)
I tried also to place it only int the pluginManagment section but it doesn't
work. The dependency is not loaded.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Plugin development questions
Hi all, I'm working on a maven 2 plugin to compile IDL files. Alan Cabrera created an initial plugin, and I am adding some additional features. I have a couple of questions I'd like to have some help with. I need to be specify various parameters to pass to the compiler backend. For each idl file to compile, the following needs to be specified: - Whether the compiler should emit stubs, skeletons or both - A list of package prefixes - A list of symbol definitions for preprocessing of the IDL files Obviously, these configurations would be the same for many .idl files, so the .idl files should be grouped together. I suppose an XML configuration of the plugin could look something like this: configuration compilerjacorb/compiler sources source emitall/emit includes include**/*.idl/include /includes excludes exclude**/CORBA_TypeCode.idl/exclude /excludes packagePrefixes packagePrefix typeIIOP/type prefixorg.omg/prefix /packagePrefix /packagePrefixes defines define symbol_PRE_3_0_COMPILER_/symobl value1/value /define /defines /source test-source . . . /test-source /sources /configuration I think it would provide the neccessary flexibility. Does this configuration layout look OK to you guys? I understand that the right way to scan for files to include for compilation is to use a org.codehaus.plexus.compiler.util.scan.StaleSourceScanner. This class uses a SourceMapping to specify which sources to include. There does not seem to be a mapping that can filter sources based some include and exclude patterns, however. Is anyone working on such a SourceMapping, or should I make up my own? Best regards, Anders - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1837) deploy-file succeeds even when local file not found
[ http://jira.codehaus.org/browse/MNG-1837?page=all ] Dan Tran updated MNG-1837: -- Attachment: MVN-1837.patch deploy-file succeeds even when local file not found --- Key: MNG-1837 URL: http://jira.codehaus.org/browse/MNG-1837 Project: Maven 2 Type: Bug Versions: 2.0 Environment: xp Reporter: Dan Tran Fix For: 2.0.2 Attachments: MVN-1837.patch Attached is a patch which will throw exception when local file is not found. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1838) jar plugin recreates jar files all the time
jar plugin recreates jar files all the time --- Key: MNG-1838 URL: http://jira.codehaus.org/browse/MNG-1838 Project: Maven 2 Type: Bug Components: maven-jar-plugin Versions: 2.0.1 Reporter: Jochen Wiedmann The jar plugin doesn't seem to check, whether rebuilding a jar file is actually required. For daily work, it would be faster to do what Ant's jar task does: Compare the timestamps of the input files with the timestamp of the target file. While this approach has the obvious advantage of being safe (and thus possibly well choosen as a default), it is not appropriate for large projects, where a single build requires a real lot of jar files being rebuilt, even if only a single source file has been changed. This applies, in particular, because comparable plugins like the war, ear, and assembly plugin are forced to behave in the same manner. Suggestion: - Introduce a new property, for example maven.build.force. The main idea of the property would be, that other plugins (install, war, assembly, ...) would listen to the same property. While they would possible ignore it initially, one could add support later on. - The default property value would be true. - If the property value is set to false, then the jar plugin compares the timestamps of the input files with the timestamp of the output file. If the latter is newer than the input timestamps, then the jar file isn't being rebuilt. I am ready to provide a patch, if my suggestion should find interest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1839) System Scope dependencies don't work
System Scope dependencies don't work Key: MNG-1839 URL: http://jira.codehaus.org/browse/MNG-1839 Project: Maven 2 Type: Bug Components: maven-compiler-plugin Versions: 2.0.1 Reporter: David Boden I've added the following as a dependency: dependency groupIdcom.tibco/groupId artifactIdtibjms/artifactId version4.1.0/version scopesystem/scope systemPathc:/tibjms.jar/systemPath /dependency The compilation process simply does not pick up this jar and put it on the compilation classpath. The compile fails. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-625) jfreechart-1.0.0
[ http://jira.codehaus.org/browse/MAVENUPLOAD-625?page=comments#action_53412 ] Takayuki Kaneko commented on MAVENUPLOAD-625: - Sorry, I found it in jfreechart groupId. It is both in jfreechart and jfree groupId. I searched it in jfree. :-) jfreechart-1.0.0 Key: MAVENUPLOAD-625 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-625 Project: maven-upload-requests Type: Task Reporter: Brian Fox Assignee: Carlos Sanchez Final 1.0 version of jfreechart. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (SCM-113) Support persistent and transient clientspecs
Support persistent and transient clientspecs Key: SCM-113 URL: http://jira.codehaus.org/browse/SCM-113 Project: Maven SCM Type: New Feature Components: maven-scm-provider-perforce Versions: 1.0-beta-3 Reporter: mike perham Fix For: 1.0-beta-3 Continuum needs a persistent clientspec because it needs to update a project's source code and build it once an hour. On larger projects a complete resync might take 10-20 minutes so it is necessary to keep a clientspec around for that Continuum project build so syncs only take a few seconds. However, the Maven Release plugin may need to be used by tens or even hundreds of developers to release any number of small modules. Currently this would mean lots of clientspecs being created for the release checkout which are reused very infrequently. Here I would prefer to create the clientspec, do the checkout, build and then delete the clientspec. This is what I term a transient clientspec. The Perforce plugin would need to default to one mode and support some sort of hint which tells it which mode to operate in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (SCM-114) Clientspec naming
Clientspec naming
-
Key: SCM-114
URL: http://jira.codehaus.org/browse/SCM-114
Project: Maven SCM
Type: Improvement
Components: maven-scm-provider-perforce
Versions: 1.0-beta-3
Reporter: mike perham
Fix For: 1.0-beta-3
Several people have expressed more than a passing interest in how the Perforce
clientspec is named by Maven SCM. The name needs to be autogenerated and
unique for each Continuum project build. Currently I am thinking something
like:
${project}-${user}-${hostname}-mavenscm
Emmannuel, does the SCM subsystem have access to the name of the project being
built? If not, I can just use the name of the last directory in the SCM URL
for the name of the project: //depot/projects/foobar would mean that ${project}
= foobar.
And just head off the inevitable question: you cannot set P4CLIENT for this
because Continuum may build several different projects and they each need a
unique clientspec.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SCM-114) Clientspec naming
[ http://jira.codehaus.org/browse/SCM-114?page=comments#action_53413 ]
mike perham commented on SCM-114:
-
That should be - ${user} -. Cursed wiki formatting!
Clientspec naming
-
Key: SCM-114
URL: http://jira.codehaus.org/browse/SCM-114
Project: Maven SCM
Type: Improvement
Components: maven-scm-provider-perforce
Versions: 1.0-beta-3
Reporter: mike perham
Fix For: 1.0-beta-3
Several people have expressed more than a passing interest in how the
Perforce clientspec is named by Maven SCM. The name needs to be
autogenerated and unique for each Continuum project build. Currently I am
thinking something like:
${project}-${user}-${hostname}-mavenscm
Emmannuel, does the SCM subsystem have access to the name of the project
being built? If not, I can just use the name of the last directory in the
SCM URL for the name of the project: //depot/projects/foobar would mean that
${project} = foobar.
And just head off the inevitable question: you cannot set P4CLIENT for this
because Continuum may build several different projects and they each need a
unique clientspec.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SCM-114) Clientspec naming
[ http://jira.codehaus.org/browse/SCM-114?page=comments#action_53414 ]
Wim Deblauwe commented on SCM-114:
--
I can answer for Emmanuel, because I have asked the same question for
ClearCase. It does not :(.
For ClearCase, I implemented it with using the last directory name of the
working directory ( an unique number generate by Continuum ), because the
project name is not in the SCM url.
Clientspec naming
-
Key: SCM-114
URL: http://jira.codehaus.org/browse/SCM-114
Project: Maven SCM
Type: Improvement
Components: maven-scm-provider-perforce
Versions: 1.0-beta-3
Reporter: mike perham
Fix For: 1.0-beta-3
Several people have expressed more than a passing interest in how the
Perforce clientspec is named by Maven SCM. The name needs to be
autogenerated and unique for each Continuum project build. Currently I am
thinking something like:
${project}-${user}-${hostname}-mavenscm
Emmannuel, does the SCM subsystem have access to the name of the project
being built? If not, I can just use the name of the last directory in the
SCM URL for the name of the project: //depot/projects/foobar would mean that
${project} = foobar.
And just head off the inevitable question: you cannot set P4CLIENT for this
because Continuum may build several different projects and they each need a
unique clientspec.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact 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: (SCM-113) Support persistent and transient clientspecs
[ http://jira.codehaus.org/browse/SCM-113?page=comments#action_53415 ] Wim Deblauwe commented on SCM-113: -- For ClearCase, we only support what you call a persistent clientspec. The scm url points to the location of the spec on some server. The release:perform part of the release plugin is currently not supported for clearcase. We would need something like the transient spec you talk about. Support persistent and transient clientspecs Key: SCM-113 URL: http://jira.codehaus.org/browse/SCM-113 Project: Maven SCM Type: New Feature Components: maven-scm-provider-perforce Versions: 1.0-beta-3 Reporter: mike perham Fix For: 1.0-beta-3 Continuum needs a persistent clientspec because it needs to update a project's source code and build it once an hour. On larger projects a complete resync might take 10-20 minutes so it is necessary to keep a clientspec around for that Continuum project build so syncs only take a few seconds. However, the Maven Release plugin may need to be used by tens or even hundreds of developers to release any number of small modules. Currently this would mean lots of clientspecs being created for the release checkout which are reused very infrequently. Here I would prefer to create the clientspec, do the checkout, build and then delete the clientspec. This is what I term a transient clientspec. The Perforce plugin would need to default to one mode and support some sort of hint which tells it which mode to operate in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1838) jar plugin recreates jar files all the time
[ http://jira.codehaus.org/browse/MNG-1838?page=comments#action_53416 ] Eric Andresen commented on MNG-1838: I am most definitely interested in this suggestion; we have a 20-module project, which has at least 5 major projects (with wars and a jar apiece), and a lot of time is spent rebuilding these wars and jars, even if nothing has changed in them. jar plugin recreates jar files all the time --- Key: MNG-1838 URL: http://jira.codehaus.org/browse/MNG-1838 Project: Maven 2 Type: Bug Components: maven-jar-plugin Versions: 2.0.1 Reporter: Jochen Wiedmann The jar plugin doesn't seem to check, whether rebuilding a jar file is actually required. For daily work, it would be faster to do what Ant's jar task does: Compare the timestamps of the input files with the timestamp of the target file. While this approach has the obvious advantage of being safe (and thus possibly well choosen as a default), it is not appropriate for large projects, where a single build requires a real lot of jar files being rebuilt, even if only a single source file has been changed. This applies, in particular, because comparable plugins like the war, ear, and assembly plugin are forced to behave in the same manner. Suggestion: - Introduce a new property, for example maven.build.force. The main idea of the property would be, that other plugins (install, war, assembly, ...) would listen to the same property. While they would possible ignore it initially, one could add support later on. - The default property value would be true. - If the property value is set to false, then the jar plugin compares the timestamps of the input files with the timestamp of the output file. If the latter is newer than the input timestamps, then the jar file isn't being rebuilt. I am ready to provide a patch, if my suggestion should find interest. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ruby Mojo Support
Comments inline. Eric Redmond wrote: Some of you expressed an interest. Please note that it is close, but not quite, ready to be tested on a wider scale (such as the users list). I'm still stummped at how to inject certain values into the Ruby object. But the projects and sourcecode can be downloaded from here: http://www.propellors.net/rubymojo/ Its still very much alpha, email me if you have problems. This sounds very cool. I'm only just getting started in Ruby, but it sounds pretty interesting. Thanks! Eric Oh right, I almost forgot. I have been unsuccessful at adding dependencies to the maven-plugin-plugin project via my plugin's POM. For the time being I just build my own maven-plugin-plugin with maven-script-ruby added to its POM. If anyone can get this working without modifying maven-plugin-plugin (by either maven-script-ruby or ruby-scripted plugins that use it) I would be forever grateful! You might want to look at the test projects in https://svn.apache.org/repos/asf/maven/components/trunk/maven-plugin-tools/maven-plugin-tools-ant/integration-tests I'm using plugin-dependencies in those projects to add Ant plugin processing to the plugin-plugin. HTH, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (SCM-110) Perforce should force sync
[ http://jira.codehaus.org/browse/SCM-110?page=all ] mike perham updated SCM-110: Attachment: (was: force.txt) Perforce should force sync -- Key: SCM-110 URL: http://jira.codehaus.org/browse/SCM-110 Project: Maven SCM Type: Bug Components: maven-scm-provider-perforce Reporter: mike perham Attachments: force2.txt It's not pretty but it's the only way to get sync to work when files could be deleted from the filesystem (e.g. mvn clean). -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [Proposal] Continuum refactoring
I think we have to be careful when splitting up a public api like this. It's possible Continuum may need to be embedded someday, and if so, it would be much better to have a single interface for controlling it...even if it means that interface delegates most of its work. While I think you can probably factor out a lot of the actual logic, we need to preserve that coherent, single-interface accessibility IMO. Besides, we do still have to maintain public API compatibility, since it's only a x.y release... My 2 cents. -john Emmanuel Venisse wrote: Hi, I'd like to know your opinions about the continuum refactoring for 1.1 What we'll do? Replace plexus-summit/velocity by JSP/WebWork/SiteMesh What i'd like to do? Actually, DefaultContinuum class is our centralized code class. With a framework like webwork, i think we can improve the architecture by splitting it with this : - all data manipulations (CRUD) will be in several DAO classes - all utility methods (is*InQueue, checkoutProject, buildProject* will be in several utility classes (or action classes in webwork terms) - in DefaultContinuum, we'll keep only initialization methods With this refactoring, i think it will be more easy to migrate to webwork, and maintenance will be more easy. WDYT? Emmanuel
[jira] Created: (CONTINUUM-512) Preview generated site
Preview generated site -- Key: CONTINUUM-512 URL: http://jira.codehaus.org/browse/CONTINUUM-512 Project: Continuum Type: Wish Components: Web interface Reporter: Aviran Mordo Priority: Minor It will be nice to have a way to make continuum link and serve the project's site? If I go to the working folder and click on target-site-index.html, continuum show me the html source in a text box, and I want to actually view the generated site. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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: (SCM-113) Support persistent and transient clientspecs
[ http://jira.codehaus.org/browse/SCM-113?page=comments#action_53417 ] Neil Padgen commented on SCM-113: - I can see the advantages of both persistent and transient clientspecs. I would expect the persistent clientspec to be used more often than the transient clientspec - Continuum will be building things every hour, while modules will be released probably not much more than once a day. You should almost definitely use the Description field of a clientspec to describe the purpose of the client. Name: client Root: /path/to/root Description: nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;Created by maven-scm-provider-perforce for maven-release-plugin View: nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;nbsp;//depot/project/... //client/... Then it's easy to do p4 clients |grep 'maven-scm-provider-perforce.*maven-release-plugin' to identify which ones ought to be deleted. As for your hint, could you create a property maven.scm.perforce.transient-clientspec to true or false? Support persistent and transient clientspecs Key: SCM-113 URL: http://jira.codehaus.org/browse/SCM-113 Project: Maven SCM Type: New Feature Components: maven-scm-provider-perforce Versions: 1.0-beta-3 Reporter: mike perham Fix For: 1.0-beta-3 Continuum needs a persistent clientspec because it needs to update a project's source code and build it once an hour. On larger projects a complete resync might take 10-20 minutes so it is necessary to keep a clientspec around for that Continuum project build so syncs only take a few seconds. However, the Maven Release plugin may need to be used by tens or even hundreds of developers to release any number of small modules. Currently this would mean lots of clientspecs being created for the release checkout which are reused very infrequently. Here I would prefer to create the clientspec, do the checkout, build and then delete the clientspec. This is what I term a transient clientspec. The Perforce plugin would need to default to one mode and support some sort of hint which tells it which mode to operate in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MEV-258) Reason: Parent: null:plexus-compiler:jar:1.4 of project: unknown:plexus-compiler-api has wrong packaging: jar. Must be 'pom'
Reason: Parent: null:plexus-compiler:jar:1.4 of project: unknown:plexus-compiler-api has wrong packaging: jar. Must be 'pom' Key: MEV-258 URL: http://jira.codehaus.org/browse/MEV-258 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Brozowski no packaging is listed in the plexus-compiler POM file and is causing an error with 2.0.1 which apparently is checking more strictly. Just need to add packagingpom/packaging to the pom 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Java Doc problem with maven 2.0.1 mvn site:site
Hi All, I am getting blank report for javadoc when i run mvn site:site using maven 2.0.1 . Please let me know if you guys have any idea or workaround. Thanks. [YUGENDER RAYABARAPU]
[jira] Commented: (MNG-1509) Profile activation by os doesn't work
[ http://jira.codehaus.org/browse/MNG-1509?page=comments#action_53420 ]
Bernd Bohmann commented on MNG-1509:
Added more Testcases to DefaultProfileManagerTest.java m unfortunately they are
os depend (my os is unix):
public void testOsActivationNotFamilyProfile() throws ProfileActivationException
{
Profile osActivated = new Profile();
osActivated.setId(os-profile);
Activation osActivation = new Activation();
ActivationOS activationOS = new ActivationOS();
activationOS.setFamily(!windows);
osActivation.setOs(activationOS);
osActivated.setActivation(osActivation);
ProfileManager profileManager = new
DefaultProfileManager(getContainer());
profileManager.addProfile(osActivated);
List active = profileManager.getActiveProfiles();
assertNotNull( active );
assertEquals( 1, active.size() );
}
public void testOsActivationFamilyProfile() throws ProfileActivationException
{
Profile osActivated = new Profile();
osActivated.setId(os-profile);
Activation osActivation = new Activation();
ActivationOS activationOS = new ActivationOS();
activationOS.setFamily(unix);
osActivation.setOs(activationOS);
osActivated.setActivation(osActivation);
ProfileManager profileManager = new
DefaultProfileManager(getContainer());
profileManager.addProfile(osActivated);
List active = profileManager.getActiveProfiles();
assertNotNull( active );
assertEquals( 1, active.size() );
}
public void testOsActivationWrongFamilyProfile() throws
ProfileActivationException
{
Profile osActivated = new Profile();
osActivated.setId(os-profile);
Activation osActivation = new Activation();
ActivationOS activationOS = new ActivationOS();
activationOS.setFamily(!unix);
osActivation.setOs(activationOS);
osActivated.setActivation(osActivation);
ProfileManager profileManager = new
DefaultProfileManager(getContainer());
profileManager.addProfile(osActivated);
List active = profileManager.getActiveProfiles();
assertNotNull( active );
assertEquals( 0, active.size() );
}
All these tests runs without a failure.
How can i ensure that this version is used by maven?
Profile activation by os doesn't work
-
Key: MNG-1509
URL: http://jira.codehaus.org/browse/MNG-1509
Project: Maven 2
Type: Bug
Components: Inheritence and Interpolation
Versions: 2.0
Environment: Ubuntu 5.10 maven 2.0
Reporter: Bernd Bohmann
Assignee: John Casey
Fix For: 2.0.1
Attachments: DefaultProfileManagerTest.java.patch,
OperatingSystemProfileActivator.java.patch,
OperatingSystemProfileActivator.java.patch, components.xml.patch
Profile activation by os doesn't work.
OperatingSystemProfileActivator is missing in components.xml.
Implementation of OperatingSystemProfileActivator.isActive is wrong.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1819) StringIndexOutOfBoundsException when running maven
[ http://jira.codehaus.org/browse/MNG-1819?page=comments#action_53424 ] Christopher Cobb commented on MNG-1819: --- I am also running cygwin. If I open a windows cmd shell, I get: C:\downloads\maven-2.0.1\binmvn [INFO] Scanning for projects... [INFO] [ERROR] BUILD FAILURE [INFO] [INFO] You must specify at least one goal. Try 'install' [INFO] [INFO] For more information, run Maven with the -e switch [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Dec 14 11:34:47 EST 2005 [INFO] Final Memory: 1M/2M [INFO] If I open a cygwin rxvt bash shell, I get (whose path has been purified of directories with spaces with PATH=`echo $PATH|tr : '\n'|grep -v | tr '\n' :`), I get: /downloads/maven-2.0.1/bin $ ./mvn [WARNING] Failed to initialize environment variable resolver. Skipping environment substitution in settings. [WARNING] Failed to initialize environment variable resolver. Skipping environment substitution in settings. [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] String index out of range: -1 [INFO] [INFO] Trace java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1768) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:188) at org.codehaus.plexus.util.interpolation.EnvarBasedValueSource.init(EnvarBasedValueSource.java:16) at org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolate(RegexBasedModelInterpolator.java:86) at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:725) at org.apache.maven.project.DefaultMavenProjectBuilder.buildStandaloneSuperProject(DefaultMavenProjectBuilder.java:1334) at org.apache.maven.DefaultMaven.getSuperProject(DefaultMaven.java:333) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:281) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 1 second [INFO] Finished at: Wed Dec 14 11:36:03 EST 2005 [INFO] Final Memory: 1M/2M [INFO] StringIndexOutOfBoundsException when running maven -- Key: MNG-1819 URL: http://jira.codehaus.org/browse/MNG-1819 Project: Maven 2 Type: Bug Versions: 2.0.1 Environment: win xp, cygwin Reporter: Dan Diephouse Just trying out 2.0.1 and I am getting this message below. any ideas? $ mvn.bat [WARNING] Failed to initialize environment variable resolver. Skipping environment substitution in settings. [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] String index out of range: -1 [INFO] [INFO] Trace java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1768) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:188) at org.codehaus.plexus.util.interpolation.EnvarBasedValueSource.init(EnvarBasedValueSource.java:16) at org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolate(RegexBasedModelInterpolator.java:86) at
Java Doc Report problem with mvn site:site maven 2.0.1
Hi All, I am getting blank report for javadoc when i run mvn site:site using maven 2.0.1 . Please let me know if you guys have any idea or workaround. Thanks. [YUGENDER RAYABARAPU] [YUGENDER RAYABARAPU]
[jira] Commented: (SCM-113) Support persistent and transient clientspecs
[ http://jira.codehaus.org/browse/SCM-113?page=comments#action_53427 ] skylab commented on SCM-113: Hi Mike, can we add some additional parameters to the SCM URL? Just the client-name or something else: _x:y:z:url:?myName=skylabperforce.client.name=skylabs-project-on-my-workstationandSoOn_ Support persistent and transient clientspecs Key: SCM-113 URL: http://jira.codehaus.org/browse/SCM-113 Project: Maven SCM Type: New Feature Components: maven-scm-provider-perforce Versions: 1.0-beta-3 Reporter: mike perham Fix For: 1.0-beta-3 Continuum needs a persistent clientspec because it needs to update a project's source code and build it once an hour. On larger projects a complete resync might take 10-20 minutes so it is necessary to keep a clientspec around for that Continuum project build so syncs only take a few seconds. However, the Maven Release plugin may need to be used by tens or even hundreds of developers to release any number of small modules. Currently this would mean lots of clientspecs being created for the release checkout which are reused very infrequently. Here I would prefer to create the clientspec, do the checkout, build and then delete the clientspec. This is what I term a transient clientspec. The Perforce plugin would need to default to one mode and support some sort of hint which tells it which mode to operate in. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact 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-1839) System Scope dependencies don't work
[ http://jira.codehaus.org/browse/MNG-1839?page=comments#action_53429 ] David Boden commented on MNG-1839: -- Sorry, please ignore for the moment. I've just downloaded a newer version than I thought I had installed. I'll close this issue if the bug is fixed in 2.0.1. Thanks. System Scope dependencies don't work Key: MNG-1839 URL: http://jira.codehaus.org/browse/MNG-1839 Project: Maven 2 Type: Bug Components: maven-compiler-plugin Versions: 2.0.1 Reporter: David Boden I've added the following as a dependency: dependency groupIdcom.tibco/groupId artifactIdtibjms/artifactId version4.1.0/version scopesystem/scope systemPathc:/tibjms.jar/systemPath /dependency The compilation process simply does not pick up this jar and put it on the compilation classpath. The compile fails. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - FAILED - update] Wed Dec 14 17:30:00 GMT 2005
Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051214.173000.txt
[jira] Created: (MNG-1840) Increment Model Version and enable stricter checks.
Increment Model Version and enable stricter checks. --- Key: MNG-1840 URL: http://jira.codehaus.org/browse/MNG-1840 Project: Maven 2 Type: Bug Components: POM Versions: 2.1 Reporter: Joakim Erdfelt Fix For: 2.1 Based on discussion with Brett. The 2.1 codebase will introduce some new elements into the pom. * Increment the POM modelVersion. * Enable strict checks option in ModelReader. * Commit MODELLO-44 for required pom elements. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MPSITE-46) maven-site-plugin break maven-javadoc-plugin JavaDocs
maven-site-plugin break maven-javadoc-plugin JavaDocs - Key: MPSITE-46 URL: http://jira.codehaus.org/browse/MPSITE-46 Project: maven-site-plugin Type: Bug Components: plugin Environment: maven-site-plugin-2.0-beta-4 Solaris 5.8SP4 Maven 2.0/2.0.1 Reporter: Alex Mayorga Adame Attachments: javadoc-javadoc-index.html, site-javadoc-index.html When mvn javadoc:javadoc is used \target\docs\apidocs\index.html is created with correct javadocs. but when mvn site:site is used \target\site\apidocs\index.html is created with a JavaDoc link to an empty page. I believe the $bodyContent is not correctly handled by site-plugin. Attached both 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1278) Broken Links on Getting Started page
[ http://jira.codehaus.org/browse/MNG-1278?page=all ] Brett Porter closed MNG-1278: - Resolution: Fixed confirmed (I used the firefox linkcheck plugin) Broken Links on Getting Started page Key: MNG-1278 URL: http://jira.codehaus.org/browse/MNG-1278 Project: Maven 2 Type: Bug Components: documentation - general Versions: 2.0 Reporter: Binil Thomas Priority: Trivial Many links on the Getting Started page (http://maven.apache.org/guides/getting-started/index.html) are broken. For instance, the Introduction to Archetypes page is linked as http://maven.apache.org/guides/getting-started/introduction-to-archetypes.html, but the page exits at http://maven.apache.org/guides/introduction/introduction-to-archetypes.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-257) Please upload ditchnet:ditchnet-tabs-taglib 0.8
[ http://jira.codehaus.org/browse/MEV-257?page=all ] Carlos Sanchez closed MEV-257: -- Assign To: Carlos Sanchez Resolution: Incomplete The structure is right To upload the binaries, read http://maven.apache.org/guides/mini/guide-ibiblio-upload.html Please upload ditchnet:ditchnet-tabs-taglib 0.8 --- Key: MEV-257 URL: http://jira.codehaus.org/browse/MEV-257 Project: Maven Evangelism Type: Wish Reporter: Oliver Siegmar Assignee: Carlos Sanchez The binaries are missing and the structure is not maven2 compliant. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1835) Ability to specify more than 1 check configuration file and file sets for each of these configurations
[ http://jira.codehaus.org/browse/MNG-1835?page=comments#action_53436 ] Joakim Erdfelt commented on MNG-1835: - I was working on a ... configuration configLocations configLocation.../configLocation configLocation.../configLocation /configLocations /configuration ... concept earlier, but my attempts to 'merge' the configs together and run a single checkstyle run against the codebase was fruitless. Instead, I feel that multiple checkstyle runs against the codebase made the most sense. But that introduces the potential for different configurations for the other parts too. Course, in that case, you could just as well make multiple checkstyle plugin entries in your pom. (but that would require the ability to specify the report output filename and title in the project reports navigation links.) Ability to specify more than 1 check configuration file and file sets for each of these configurations -- Key: MNG-1835 URL: http://jira.codehaus.org/browse/MNG-1835 Project: Maven 2 Type: Improvement Components: maven-checkstyle-plugin Reporter: Fabrice BELLINGARD I'm using Eclipse Checkstyle Plug-in, and there's a functionnality I enjoy a lot: the ability to specify as many check configuration files as I want for a projet, and to tell which file sets those configurations should be run on. And as I use this functionnality extensively, I'd love to have it also in the Maven Checkstyle Plug-in :o) To get a look at what the Eclipse plugin does: http://eclipse-cs.sourceforge.net/advanced_file_sets.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1835) Ability to specify more than 1 check configuration file and file sets for each of these configurations
[ http://jira.codehaus.org/browse/MNG-1835?page=comments#action_53435 ] Joakim Erdfelt commented on MNG-1835: - I was working on a ... configuration configLocations configLocation.../configLocation configLocation.../configLocation /configLocations /configuration ... concept earlier, but my attempts to 'merge' the configs together and run a single checkstyle run against the codebase was fruitless. Instead, I feel that multiple checkstyle runs against the codebase made the most sense. But that introduces the potential for different configurations for the other parts too. Course, in that case, you could just as well make multiple checkstyle plugin entries in your pom. (but that would require the ability to specify the report output filename and title in the project reports navigation links.) Ability to specify more than 1 check configuration file and file sets for each of these configurations -- Key: MNG-1835 URL: http://jira.codehaus.org/browse/MNG-1835 Project: Maven 2 Type: Improvement Components: maven-checkstyle-plugin Reporter: Fabrice BELLINGARD I'm using Eclipse Checkstyle Plug-in, and there's a functionnality I enjoy a lot: the ability to specify as many check configuration files as I want for a projet, and to tell which file sets those configurations should be run on. And as I use this functionnality extensively, I'd love to have it also in the Maven Checkstyle Plug-in :o) To get a look at what the Eclipse plugin does: http://eclipse-cs.sourceforge.net/advanced_file_sets.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1834) maven-reporting-impl version 2.0.1 missing component org.codehaus.doxia.site.renderer.SiteRenderer
[ http://jira.codehaus.org/browse/MNG-1834?page=all ]
John Casey updated MNG-1834:
Assign To: John Casey
Fix Version: 2.0.1-1
Remaining Estimate: 30 minutes
Original Estimate: 30 minutes
maven-reporting-impl version 2.0.1 missing component
org.codehaus.doxia.site.renderer.SiteRenderer
--
Key: MNG-1834
URL: http://jira.codehaus.org/browse/MNG-1834
Project: Maven 2
Type: Bug
Versions: 2.0.1
Environment: all
Reporter: Olivier Lamy
Assignee: John Casey
Priority: Blocker
Fix For: 2.0.1-1
Original Estimate: 30 minutes
Remaining: 30 minutes
With using maven-reporting-impl version 2.0.1. (updating my pom to all maven*
2.0.1)
I have the following stack trace :
ComponentRequirement{role='org.codehaus.doxia.site.renderer.SiteRenderer',
roleHint='null', fieldName='siteRenderer'} was missing.
The component org.codehaus.doxia.site.renderer.SiteRenderer is missing.
The workaroung is using maven-reporting-impl version 2.0
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1819) StringIndexOutOfBoundsException when running maven
[ http://jira.codehaus.org/browse/MNG-1819?page=all ] John Casey updated MNG-1819: Assign To: John Casey Fix Version: 2.0.1-1 StringIndexOutOfBoundsException when running maven -- Key: MNG-1819 URL: http://jira.codehaus.org/browse/MNG-1819 Project: Maven 2 Type: Bug Versions: 2.0.1 Environment: win xp, cygwin Reporter: Dan Diephouse Assignee: John Casey Fix For: 2.0.1-1 Just trying out 2.0.1 and I am getting this message below. any ideas? $ mvn.bat [WARNING] Failed to initialize environment variable resolver. Skipping environment substitution in settings. [INFO] Scanning for projects... [INFO] [ERROR] FATAL ERROR [INFO] [INFO] String index out of range: -1 [INFO] [INFO] Trace java.lang.StringIndexOutOfBoundsException: String index out of range: -1 at java.lang.String.substring(String.java:1768) at org.codehaus.plexus.util.cli.CommandLineUtils.getSystemEnvVars(CommandLineUtils.java:188) at org.codehaus.plexus.util.interpolation.EnvarBasedValueSource.init(EnvarBasedValueSource.java:16) at org.apache.maven.project.interpolation.RegexBasedModelInterpolator.interpolate(RegexBasedModelInterpolator.java:86) at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:725) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:632) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:304) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:274) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:515) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:447) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:351) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:278) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:115) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 1 second [INFO] Finished at: Mon Dec 12 16:50:03 PST 2005 [INFO] Final Memory: 1M/2M [INFO] -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] Release Maven 2.0.1-1 critical bugfix version
Hi all, If you've been watching this list, the users list, or JIRA, I'm sure you've noticed that we managed to introduce some new bugs in 2.0.1. Some of these are critical, and will block the use of this version. What I'd like to do is release a bugfix version, 2.0.1-1, to address these critical issues. I've opened a new version on the Maven roadmap in JIRA (http://jira.codehaus.org/browse/MNG) to track these. Currently there are two, and I don't expect that number to climb much more. Please note, this release is only for critical bugs. We're not going to be fixing anything that we can limp along without for a bit longer. Because of the hurried nature of this vote, this email thread will undoubtedly serve as a mechanism for determining which issues are critical to release here; I will make sure JIRA reflects this discussion. Here is my +1. Sincerely, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.1-1 critical bugfix version
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Casey wrote, On 12/14/2005 11:41 AM: Hi all, If you've been watching this list, the users list, or JIRA, I'm sure you've noticed that we managed to introduce some new bugs in 2.0.1. Some of these are critical, and will block the use of this version. What I'd like to do is release a bugfix version, 2.0.1-1, to address these critical issues. I've opened a new version on the Maven roadmap in JIRA (http://jira.codehaus.org/browse/MNG) to track these. Currently there are two, and I don't expect that number to climb much more. Please note, this release is only for critical bugs. We're not going to be fixing anything that we can limp along without for a bit longer. Because of the hurried nature of this vote, this email thread will undoubtedly serve as a mechanism for determining which issues are critical to release here; I will make sure JIRA reflects this discussion. Odd that this won't be a 2.0.2 release. Regards, Alan -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.2 (MingW32) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDoHZV1xC6qnMLUpYRAgLjAJ4ymuIvNkOmZSp52/zlV8OYjm6cvQCfeOsJ wOegA5fFRyvwN7HAXekqw5Y= =h0DH -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.1-1 critical bugfix version
That's what happen when you make a release while you drink beer ;) No more releases during the Hackathon ! Why not call it 2.0.3 ? On 12/14/05, John Casey [EMAIL PROTECTED] wrote: Hi all, If you've been watching this list, the users list, or JIRA, I'm sure you've noticed that we managed to introduce some new bugs in 2.0.1. Some of these are critical, and will block the use of this version. What I'd like to do is release a bugfix version, 2.0.1-1, to address these critical issues. I've opened a new version on the Maven roadmap in JIRA (http://jira.codehaus.org/browse/MNG) to track these. Currently there are two, and I don't expect that number to climb much more. Please note, this release is only for critical bugs. We're not going to be fixing anything that we can limp along without for a bit longer. Because of the hurried nature of this vote, this email thread will undoubtedly serve as a mechanism for determining which issues are critical to release here; I will make sure JIRA reflects this discussion. Here is my +1. Sincerely, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.1-1 critical bugfix version
John Casey wrote: Hi all, If you've been watching this list, the users list, or JIRA, I'm sure you've noticed that we managed to introduce some new bugs in 2.0.1. Some of these are critical, and will block the use of this version. What I'd like to do is release a bugfix version, 2.0.1-1, to address these critical issues. I've opened a new version on the Maven roadmap in JIRA (http://jira.codehaus.org/browse/MNG) to track these. Currently there are two, and I don't expect that number to climb much more. I think the version should be 2.0.2. It is a patch release effectively. I know this means pushing out all the JIRA issues to a 2.0.3. I just did this with surefire where a bug slipped in and I think major.minor.patch is more consistent. Please note, this release is only for critical bugs. We're not going to be fixing anything that we can limp along without for a bit longer. Because of the hurried nature of this vote, this email thread will undoubtedly serve as a mechanism for determining which issues are critical to release here; I will make sure JIRA reflects this discussion. Here is my +1. Sincerely, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1841) maven-site-plugin break maven-javadoc-plugin JavaDocs
[ http://jira.codehaus.org/browse/MNG-1841?page=all ] Emmanuel Venisse updated MNG-1841: -- Fix Version: 2.0.1-1 maven-site-plugin break maven-javadoc-plugin JavaDocs - Key: MNG-1841 URL: http://jira.codehaus.org/browse/MNG-1841 Project: Maven 2 Type: Bug Components: maven-site-plugin Environment: maven-site-plugin-2.0-beta-4 Solaris 5.8SP4 Maven 2.0/2.0.1 Reporter: Alex Mayorga Adame Fix For: 2.0.1-1 Attachments: javadoc-javadoc-index.html, site-javadoc-index.html When mvn javadoc:javadoc is used \target\docs\apidocs\index.html is created with correct javadocs. but when mvn site:site is used \target\site\apidocs\index.html is created with a JavaDoc link to an empty page. I believe the $bodyContent is not correctly handled by site-plugin. Attached both 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.1-1 critical bugfix version
+1 I'd prefer too 2.0.2 I added MNG-1841 because it's blocker for site generation. All our reports are empty in maven site (http://maven.apache.org/maven-reports.html) Emmanuel John Casey a écrit : Hi all, If you've been watching this list, the users list, or JIRA, I'm sure you've noticed that we managed to introduce some new bugs in 2.0.1. Some of these are critical, and will block the use of this version. What I'd like to do is release a bugfix version, 2.0.1-1, to address these critical issues. I've opened a new version on the Maven roadmap in JIRA (http://jira.codehaus.org/browse/MNG) to track these. Currently there are two, and I don't expect that number to climb much more. Please note, this release is only for critical bugs. We're not going to be fixing anything that we can limp along without for a bit longer. Because of the hurried nature of this vote, this email thread will undoubtedly serve as a mechanism for determining which issues are critical to release here; I will make sure JIRA reflects this discussion. Here is my +1. Sincerely, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-1509) Profile activation by os doesn't work
[ http://jira.codehaus.org/browse/MNG-1509?page=all ] John Casey updated MNG-1509: Fix Version: (was: 2.0.1) 2.0.2 Profile activation by os doesn't work - Key: MNG-1509 URL: http://jira.codehaus.org/browse/MNG-1509 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0 Environment: Ubuntu 5.10 maven 2.0 Reporter: Bernd Bohmann Assignee: John Casey Fix For: 2.0.2 Attachments: DefaultProfileManagerTest.java.patch, OperatingSystemProfileActivator.java.patch, OperatingSystemProfileActivator.java.patch, components.xml.patch Profile activation by os doesn't work. OperatingSystemProfileActivator is missing in components.xml. Implementation of OperatingSystemProfileActivator.isActive is wrong. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1841) maven-site-plugin break maven-javadoc-plugin JavaDocs
[ http://jira.codehaus.org/browse/MNG-1841?page=all ] Brett Porter closed MNG-1841: - Assign To: Brett Porter Resolution: Duplicate Fix Version: (was: 2.0.2) maven-site-plugin break maven-javadoc-plugin JavaDocs - Key: MNG-1841 URL: http://jira.codehaus.org/browse/MNG-1841 Project: Maven 2 Type: Bug Components: maven-site-plugin Environment: maven-site-plugin-2.0-beta-4 Solaris 5.8SP4 Maven 2.0/2.0.1 Reporter: Alex Mayorga Adame Assignee: Brett Porter Attachments: javadoc-javadoc-index.html, site-javadoc-index.html When mvn javadoc:javadoc is used \target\docs\apidocs\index.html is created with correct javadocs. but when mvn site:site is used \target\site\apidocs\index.html is created with a JavaDoc link to an empty page. I believe the $bodyContent is not correctly handled by site-plugin. Attached both 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release Maven 2.0.1-1 critical bugfix version
John Casey wrote: I'm not too interested in which version number we use; I only suggested this notation since it's definitely a lot smaller than what we did for 2.0.1, and what we've got slated for 2.0.2...that, and it's meant to modify the 2.0.1 release so it'll work. 2.0.2 is fine with me. I can push the other stuff off to 2.0.3. What about the vote? +1 -j Jason van Zyl wrote: John Casey wrote: Hi all, If you've been watching this list, the users list, or JIRA, I'm sure you've noticed that we managed to introduce some new bugs in 2.0.1. Some of these are critical, and will block the use of this version. What I'd like to do is release a bugfix version, 2.0.1-1, to address these critical issues. I've opened a new version on the Maven roadmap in JIRA (http://jira.codehaus.org/browse/MNG) to track these. Currently there are two, and I don't expect that number to climb much more. I think the version should be 2.0.2. It is a patch release effectively. I know this means pushing out all the JIRA issues to a 2.0.3. I just did this with surefire where a bug slipped in and I think major.minor.patch is more consistent. Please note, this release is only for critical bugs. We're not going to be fixing anything that we can limp along without for a bit longer. Because of the hurried nature of this vote, this email thread will undoubtedly serve as a mechanism for determining which issues are critical to release here; I will make sure JIRA reflects this discussion. Here is my +1. Sincerely, John - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- jvz. Jason van Zyl jason at maven.org http://maven.apache.org First, the taking in of scattered particulars under one Idea, so that everyone understands what is being talked about ... Second, the separation of the Idea into parts, by dividing it at the joints, as nature directs, not breaking any limb in half as a bad carver might. -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[vote] Release maven-javadoc-plugin 2.0-beta-3 (maven 2)
Hi, We've been receiving a lot of questions about the javadoc report, and we've got some critical fixes ready for release which should solve a good deal of these problems. It looks like it's time to release the next beta of this plugin. I'll give it the customary 72 hrs. Here's my +1. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [vote] Release maven-javadoc-plugin 2.0-beta-3 (maven 2)
+1 On 12/14/05, John Casey [EMAIL PROTECTED] wrote: Hi, We've been receiving a lot of questions about the javadoc report, and we've got some critical fixes ready for release which should solve a good deal of these problems. It looks like it's time to release the next beta of this plugin. I'll give it the customary 72 hrs. Here's my +1. -john - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Continuum refactoring
On Wed, 2005-12-14 at 19:30 +0100, Emmanuel Venisse wrote: ok, so we'll have some data object store access (ProjectStore, BuildStore...) and DefaultContinuum will use them. Webwork actions will use them too or they'll use Continuum interface? I still disagree with splitting up the ContinuumStore into a set of DAOs. I've never seen the advantage of having a single DAO for each domain object. On the other hand it might be feasible to split the rather big interface into smaller interfaces, each having the responsible of a distinct set of entities. The User and Group are two classes that naturally fit in a separate store interface. I agree with Brett's idea about making even more actions out of the Continuum implementation, possibly even using something like OS Workflow to actually execute the activities. -- Trygve Emmanuel Brett Porter a écrit : +1 I'm all for splitting up into action components, but retaining a Continuum interface as a single entry point to those - Brett John Casey wrote: I think we have to be careful when splitting up a public api like this. It's possible Continuum may need to be embedded someday, and if so, it would be much better to have a single interface for controlling it...even if it means that interface delegates most of its work. While I think you can probably factor out a lot of the actual logic, we need to preserve that coherent, single-interface accessibility IMO. Besides, we do still have to maintain public API compatibility, since it's only a x.y release... My 2 cents. -john Emmanuel Venisse wrote: Hi, I'd like to know your opinions about the continuum refactoring for 1.1 What we'll do? Replace plexus-summit/velocity by JSP/WebWork/SiteMesh What i'd like to do? Actually, DefaultContinuum class is our centralized code class. With a framework like webwork, i think we can improve the architecture by splitting it with this : - all data manipulations (CRUD) will be in several DAO classes - all utility methods (is*InQueue, checkoutProject, buildProject* will be in several utility classes (or action classes in webwork terms) - in DefaultContinuum, we'll keep only initialization methods With this refactoring, i think it will be more easy to migrate to webwork, and maintenance will be more easy. WDYT? Emmanuel
[jira] Closed: (MNG-1800) surefire:test finds a resource inside a jar, but can't load a class inside it?
[ http://jira.codehaus.org/browse/MNG-1800?page=all ] Matthew Beermann closed MNG-1800: - Resolution: Fixed Fix Version: (was: 2.0.3) Turns out that this wasn't directly caused by MNG-441 or MNG-1303, but the resolution of those allowed me to get a real stack trace (with chained exceptions attached) and get to the root of the problem. surefire:test finds a resource inside a jar, but can't load a class inside it? -- Key: MNG-1800 URL: http://jira.codehaus.org/browse/MNG-1800 Project: Maven 2 Type: Bug Components: maven-surefire-plugin Versions: 2.0 Reporter: Matthew Beermann Priority: Critical We're using Java's SPI mechanism to load implementations at runtime. To be exact, the iface jar looks for a particular file (using ClassLoader.getResource) when the application starts, and reads inside of it to find out what the real implementation is. Then, it uses reflection (ClassLoader.loadClass) to actually load the class. This mechanism works like a dream in Eclipse, JUnit, etc, but fails mysteriously in Maven 2. I say mysteriously, because it locates the file in the impl jar, but then can't manage to load the class inside that jar! Snippets from my build log... sorry for the redacting, but it's not open-source code being built... [DEBUG] Test Classpath : ... [DEBUG] C:\my-implementation.jar --- T E S T S --- ServiceProviderLookupFacility: The class [BasicLoggerManager] configured in the service provider configuration file [jar:file:C:/my-implementation.jar!/META-INF/services/LoggerManager] could not be found and will be skipped. ServiceProviderLookupFacility: java.lang.ClassNotFoundException: BasicLoggerManager at java.net.URLClassLoader$1.run(URLClassLoader.java:200) at java.security.AccessController.doPrivileged(Native Method) at java.net.URLClassLoader.findClass(URLClassLoader.java:188) at java.lang.ClassLoader.loadClass(ClassLoader.java:306) at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:268) at java.lang.ClassLoader.loadClass(ClassLoader.java:251) at org.codehaus.surefire.IsolatedClassLoader.loadClass(IsolatedClassLoader.java:69) where my code called ClassLoader.loadClass Any insights into what's going on here? This seems tremendously broken... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MAVENUPLOAD-629) Jini version 2.1 final starter kit jars
[ http://jira.codehaus.org/browse/MAVENUPLOAD-629?page=comments#action_53447 ] Chris Sterling commented on MAVENUPLOAD-629: I had seen all of the jar files pushed to the Maven 1.x and 2.x repositories, but do not see the zip files uploaded as of yet. Is there anything special that I need to do in order to get these files loaded into the Ibiblio repositories? Thanks. Jini version 2.1 final starter kit jars --- Key: MAVENUPLOAD-629 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-629 Project: maven-upload-requests Type: Bug Reporter: Chris Sterling http://daredskin.homedns.org/checkconfigurationfile-2.1-bundle.jar http://daredskin.homedns.org/checkser-2.1-bundle.jar http://daredskin.homedns.org/classdep-2.1-bundle.jar http://daredskin.homedns.org/classserver-2.1-bundle.jar http://daredskin.homedns.org/computedigest-2.1-bundle.jar http://daredskin.homedns.org/computehttpmdcodebase-2.1-bundle.jar http://daredskin.homedns.org/destroy-2.1-bundle.jar http://daredskin.homedns.org/envcheck-2.1-bundle.jar http://daredskin.homedns.org/group-2.1-bundle.jar http://daredskin.homedns.org/jarwrapper-2.1-bundle.jar http://daredskin.homedns.org/jini-core-2.1-bundle.jar http://daredskin.homedns.org/jini-ext-2.1-bundle.jar http://daredskin.homedns.org/jini-starterkit-2.1-bundle.jar http://daredskin.homedns.org/jini-start-examples-2.1-bundle.jar http://daredskin.homedns.org/jsk-lib-2.1-bundle.jar http://daredskin.homedns.org/jsk-platform-2.1-bundle.jar http://daredskin.homedns.org/jsk-resources-2.1-bundle.jar http://daredskin.homedns.org/sun-util-2.1-bundle.jar http://daredskin.homedns.org/tools-2.1-bundle.jar http://www.jini.org/ This is as close to a team link that I could find: http://www.jini.org/Contrib_Award/index.html Jini version 2.1 specifications and reference implementations are licensed under the Apache 2.0 license. I think it would be great to have the Jini base jars in the Maven repository to support a Maven Jini Plug-in, (http://maven-jini-plugin.jini.org/) that is going version 1.1. Thank you. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (MNG-1373) Broken links and improperly formatted headings in http://maven.apache.org/guides/introduction/introduction-to-repositories.html
[ http://jira.codehaus.org/browse/MNG-1373?page=comments#action_53448 ] Dennis Lundberg commented on MNG-1373: -- See MNG-1686 that also has a patch for this. Broken links and improperly formatted headings in http://maven.apache.org/guides/introduction/introduction-to-repositories.html --- Key: MNG-1373 URL: http://jira.codehaus.org/browse/MNG-1373 Project: Maven 2 Type: Bug Components: documentation - guides Reporter: John Sisson Attachments: introduction-to-repositories.diff Broken links and improperly formatted headings in http://maven.apache.org/guides/introduction/introduction-to-repositories.html * Downloading from a Remote Repository heading has trailing * Link in last line of Downloading from a Remote Repository section is broken * Uploading to Remote Repository heading has trailing * Link in Uploading to Remote Repository section is broken Looks like there is heaps more of these problems in this page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Proposal] Continuum refactoring
On 12/14/05, Trygve Laugstøl [EMAIL PROTECTED] wrote: I still disagree with splitting up the ContinuumStore into a set of DAOs. I've never seen the advantage of having a single DAO for each domain object. They will be reusable in other applicaitons. If we're thinking about creting other applications, like repository manager, we'll share a lot of common objects between them.
[jira] Updated: (MNG-1842) maven/plugins/trunk fails to build on clean system
[ http://jira.codehaus.org/browse/MNG-1842?page=all ] Joakim Erdfelt updated MNG-1842: Attachment: MNG-1842-pom-version.patch maven/plugins/trunk fails to build on clean system -- Key: MNG-1842 URL: http://jira.codehaus.org/browse/MNG-1842 Project: Maven 2 Type: Bug Components: Plugins and Lifecycle Versions: 2.0.1 Reporter: Joakim Erdfelt Fix For: 2.0.1 Attachments: MNG-1842-pom-version.patch The last release (2.0.1) eliminated the ability to perform a complete from scratch clean build of the maven/plugins/trunk. There are several plugins refering to maven 2.0.1-SNAPSHOT artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1529) NPE when inheriting report sets
[ http://jira.codehaus.org/browse/MNG-1529?page=all ] John Casey closed MNG-1529: --- Assign To: John Casey Resolution: Fixed Fix Version: (was: 2.0.3) 2.0.1 forgot to close earlier NPE when inheriting report sets --- Key: MNG-1529 URL: http://jira.codehaus.org/browse/MNG-1529 Project: Maven 2 Type: Bug Components: Inheritence and Interpolation Versions: 2.0 Environment: JDK 1.5.0_05, Kubuntu linux 5.1 Reporter: Arik Kfir Assignee: John Casey Fix For: 2.0.1 Attachments: MNG-1539-test-case.tar.bz2 I have three POMs: A: serves as a template for new projects B: Extends A - the root POM of a multi-module project C: Extends B - a module in the B project One of the things project A defines is the reporting element. However, when I try to build project B, I get the following exception: [EMAIL PROTECTED]:~/projects/swinger$ mvn clean [INFO] Scanning for projects... [INFO] snapshot org.corleon:parent:1.1-SNAPSHOT: checking for updates from corleon [INFO] [ERROR] FATAL ERROR [INFO] [INFO] null [INFO] [INFO] Trace java.lang.NullPointerException at java.util.TreeMap.compare(TreeMap.java:1093) at java.util.TreeMap.getEntry(TreeMap.java:347) at java.util.TreeMap.containsKey(TreeMap.java:204) at org.apache.maven.project.ModelUtils.mergeReportPluginDefinitions(ModelUtils.java:324) at org.apache.maven.project.ModelUtils.mergeReportPluginLists(ModelUtils.java:156) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleReportingInheritance(DefaultModelInheritanceAssembler.java:277) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:170) at org.apache.maven.project.inheritance.DefaultModelInheritanceAssembler.assembleModelInheritance(DefaultModelInheritanceAssembler.java:56) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:605) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromSourceFile(DefaultMavenProjectBuilder.java:298) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:276) at org.apache.maven.DefaultMaven.getProject(DefaultMaven.java:509) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:441) at org.apache.maven.DefaultMaven.collectProjects(DefaultMaven.java:485) at org.apache.maven.DefaultMaven.getProjects(DefaultMaven.java:345) at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:276) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:113) at org.apache.maven.cli.MavenCli.main(MavenCli.java:249) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) [INFO] [INFO] Total time: 1 second [INFO] Finished at: Sat Nov 12 13:45:14 IST 2005 [INFO] Final Memory: 1M/2M [INFO] I tracked down the problem to the reporting element in project A, because when I remove it, things work again. I believe there's a problem in the way maven merges reporting info from parent POMs (well..duh). Here is the reporting data in project A: reporting plugins plugin artifactIdmaven-javadoc-plugin/artifactId reportSets reportSet reports reportjavadoc/report /reports /reportSet /reportSets /plugin plugin artifactIdmaven-project-info-reports-plugin/artifactId reportSets reportSet reports reportdependencies/report reportproject-team/report reportlicense/report reportscm/report /reports /reportSet /reportSets /plugin
[jira] Closed: (MNG-1842) maven/plugins/trunk fails to build on clean system
[ http://jira.codehaus.org/browse/MNG-1842?page=all ] John Casey closed MNG-1842: --- Assign To: John Casey Resolution: Fixed fixed. maven/plugins/trunk fails to build on clean system -- Key: MNG-1842 URL: http://jira.codehaus.org/browse/MNG-1842 Project: Maven 2 Type: Bug Components: Plugins and Lifecycle Versions: 2.0.1 Reporter: Joakim Erdfelt Assignee: John Casey Fix For: 2.0.1 Attachments: MNG-1842-pom-version.patch The last release (2.0.1) eliminated the ability to perform a complete from scratch clean build of the maven/plugins/trunk. There are several plugins refering to maven 2.0.1-SNAPSHOT artifacts. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MPJAR-35) Documentation does not mention need for jar.manifest.classpath property
[ http://jira.codehaus.org/browse/MPJAR-35?page=all ] Lukas Theussl closed MPJAR-35: -- Assign To: (was: Jason van Zyl) Resolution: Fixed Documentation does not mention need for jar.manifest.classpath property --- Key: MPJAR-35 URL: http://jira.codehaus.org/browse/MPJAR-35 Project: maven-jar-plugin Type: Bug Versions: 1.6 Reporter: Erik Husby Fix For: 1.8 Attachments: MPJAR-35.patch The properties documentation indicates that setting the maven.jar.manifest.classpath.add property to true will add a Classpath: entry to the manifest. What is not mentioned is that the jars need to be tagged with the property jar.manifest.classpathtrue/jar.manifest.classpath in the project.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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Process working directory
This debug output seems to imply that execute()'ing a process is not setting the working directory correctly: - Executing: p4 -cbuilder-wsfteam01-maven sync -f ... - stderr: Path '/opt/continuum-1.0.2/bin/linux/...' is not under client's root '/tmp/continuum-work/1'. Bypassing the Commandline and runtime.exec'ing it myself gives the same behavior. Is there some trickery I'm not aware of in order to set a child process's working directory? I swear I am setting it to '/tmp/continuum-work/1'. mike
[jira] Updated: (MRM-42) discover repository metadata
[ http://jira.codehaus.org/browse/MRM-42?page=all ] Maria Odea Ching updated MRM-42: Remaining Estimate: 18 hours Original Estimate: 18 hours discover repository metadata Key: MRM-42 URL: http://jira.codehaus.org/browse/MRM-42 Project: Maven Repository Manager Type: Task Components: discovery Reporter: Brett Porter Assignee: Maria Odea Ching Fix For: 1.0-alpha-1 Original Estimate: 18 hours Remaining: 18 hours -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MEV-258) Reason: Parent: null:plexus-compiler:jar:1.4 of project: unknown:plexus-compiler-api has wrong packaging: jar. Must be 'pom'
[ http://jira.codehaus.org/browse/MEV-258?page=all ] Edwin Punzalan closed MEV-258: -- Assign To: Edwin Punzalan Resolution: Fixed Fixed. NOTE: May take up to 4 hours for the fix to reach central repo. Reason: Parent: null:plexus-compiler:jar:1.4 of project: unknown:plexus-compiler-api has wrong packaging: jar. Must be 'pom' Key: MEV-258 URL: http://jira.codehaus.org/browse/MEV-258 Project: Maven Evangelism Type: Bug Components: Invalid POM Reporter: Matt Brozowski Assignee: Edwin Punzalan no packaging is listed in the plexus-compiler POM file and is causing an error with 2.0.1 which apparently is checking more strictly. Just need to add packagingpom/packaging to the pom 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-1843) Step missing in online Maven Getting Started Guide
Step missing in online Maven Getting Started Guide Key: MNG-1843 URL: http://jira.codehaus.org/browse/MNG-1843 Project: Maven 2 Type: Bug Components: documentation - guides Versions: 2.0.1 Environment: CentOS 2.6.9-22.EL Reporter: Chaim Krause Priority: Minor Installed 2.01 and was going through the Maven Getting Started Guide at http://maven.apache.org/guides/getting-started/index.html and I got an error when I attempted the codemvn compile/code. code ERROR] BUILD ERROR [INFO] [INFO] Cannot execute mojo: resources. It requires a project with an existing pom.xml, but the build is not using one. [INFO] /code I then changed the directory codecd my-app/code and attempted the command again and all went well. It looks like the step to change into the directory needs to be added to the guide. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-631) Upload cglib-2.1.3 to ibiblio
Upload cglib-2.1.3 to ibiblio - Key: MAVENUPLOAD-631 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-631 Project: maven-upload-requests Type: Task Reporter: Matt Raible Hibernate 3.1 depends on cglib 2.1.3 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-632) Upload antlr-2.7.6-rc1 to ibiblio
Upload antlr-2.7.6-rc1 to ibiblio - Key: MAVENUPLOAD-632 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-632 Project: maven-upload-requests Type: Task Reporter: Matt Raible Hibernate 3.1 depends on antlr 2.7.6 RC1 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Outstanding Repository Maintenance: Evangelism
Issue Subscription Filter: Outstanding Repository Maintenance: Evangelism (30 issues) Subscriber: mavendevlist Key Summary MEV-256 jdom 1.0 has invalid dependency: xerces-2.6.0 http://jira.codehaus.org/browse/MEV-256 MEV-251 struts 1.1 pom has servlet-api in compile scope (patch attached) http://jira.codehaus.org/browse/MEV-251 MEV-255 Problem with junit-addons 1.4 http://jira.codehaus.org/browse/MEV-255 MEV-253 javax.persistence.ejb-3.0-public-draft-20050623.pom is not a maven2 pom http://jira.codehaus.org/browse/MEV-253 MEV-232 DWR POM should list dependencies as optional http://jira.codehaus.org/browse/MEV-232 MEV-140 Tapestry POM missing dependencies for javassist (2.6), ognl (2.6.3), commons-fileupload (1.0) http://jira.codehaus.org/browse/MEV-140 MEV-228 dom4j needs xml-apis updated http://jira.codehaus.org/browse/MEV-228 MEV-226 common-collections 2.1 newer than 3.0 http://jira.codehaus.org/browse/MEV-226 MEV-223 commons-email-1.0.pom bad dependencies http://jira.codehaus.org/browse/MEV-223 MEV-220 spring-mock should list spring-web and spring-jdbc as optional http://jira.codehaus.org/browse/MEV-220 MEV-221 transitive dependencies not being picked up http://jira.codehaus.org/browse/MEV-221 MEV-126 poms for som emissing sun xml API + javamail 1.3.3 http://jira.codehaus.org/browse/MEV-126 MEV-217 Relocate springframework http://jira.codehaus.org/browse/MEV-217 MEV-157 Invalid deps in the dumbster pom http://jira.codehaus.org/browse/MEV-157 MEV-202 dependency wrong http://jira.codehaus.org/browse/MEV-202 MEV-201 should have dependency on org.relaxngdatatype.relaxngDatatype http://jira.codehaus.org/browse/MEV-201 MEV-173 xmlpull JARs exist in two different places on ibiblio http://jira.codehaus.org/browse/MEV-173 MEV-175 spring-1.2.pom invalid http://jira.codehaus.org/browse/MEV-175 MEV-2 Broken dependency for groovy http://jira.codehaus.org/browse/MEV-2 MEV-163 Groovy pom has invalid dependencies http://jira.codehaus.org/browse/MEV-163 MEV-161 acegisecurity lacks dependency for oro and commons-codec http://jira.codehaus.org/browse/MEV-161 MEV-4 Misnamed pom for Postgresql http://jira.codehaus.org/browse/MEV-4 MEV-96 Some jars in ibiblio repository are broken http://jira.codehaus.org/browse/MEV-96 MEV-48 openejb poms http://jira.codehaus.org/browse/MEV-48 MEV-45 Full list of poms that doesn't respect the m2 format http://jira.codehaus.org/browse/MEV-45 MEV-38 POM for commons-jelly-tags-ant has incorrect artifact references bogus dependency http://jira.codehaus.org/browse/MEV-38 MEV-36 Exo POM(s) missing dependency versions http://jira.codehaus.org/browse/MEV-36 MEV-33 XOM POM references xercesImpl v.2.2.1 which does not exist in repo http://jira.codehaus.org/browse/MEV-33 MEV-31 XOM POM references xmlParserAPIs v2.6.1 which is not in the repo http://jira.codehaus.org/browse/MEV-31 MEV-20 clean up bad IDs in the repository http://jira.codehaus.org/browse/MEV-20 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Subscription: Outstanding Repository Maintenance: Uploads
Issue Subscription Filter: Outstanding Repository Maintenance: Uploads (4 issues) Subscriber: mavendevlist Key Summary MAVENUPLOAD-632Upload antlr-2.7.6-rc1 to ibiblio http://jira.codehaus.org/browse/MAVENUPLOAD-632 MAVENUPLOAD-631Upload cglib-2.1.3 to ibiblio http://jira.codehaus.org/browse/MAVENUPLOAD-631 MAVENUPLOAD-630Upload hibernate-3.1 to ibiblio http://jira.codehaus.org/browse/MAVENUPLOAD-630 MAVENUPLOAD-629Jini version 2.1 final starter kit jars http://jira.codehaus.org/browse/MAVENUPLOAD-629 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVENUPLOAD-633) Please Upload Registry CDC
Please Upload Registry CDC -- Key: MAVENUPLOAD-633 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-633 Project: maven-upload-requests Type: Task Reporter: Shane Isbell http://prdownloads.sourceforge.net/jvending/registry-cdc-1.0.0-bundle.jar?download http://jvending.sourceforge.net/registry-cdc http://jvending.sourceforge.net/registry-cdc/team-list.html Registry-CDC provides a registry function for storing and finding data, in particular configuration information. Please upload. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[continuum build - SUCCESS - update] Wed Dec 14 19:00:04 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20051214.190005.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20051214.190005.txt
[ANN] POMStrap 1.0.1 (no more dependencies hell ;) )
Hi, POMStrap is a really simple application boostrap and classloader trick that allows dependency classloading without side effect. POMStrap uses Maven2 pom files to resolve dependencies required to launch an application. see http://pomstrap.prefetch.com/ In few words, if your application depends on A-1.0 (and can only work with this version) and B-1.0; and if B-1.0 also depends on A-2.0. well, B-1.0 might not work correctly (because of A-1.0 already loaded). If you tune maven to use the A-2.0 with you application, it wont also work (as you app can only works with A-1.0). So to avoid such dependencies hell, I've quicky dev a minimalistic project including many usecase-samples such as: - Maven2 application launcher plugin - JBoss Service - A webapp with servlet bootstrap I hope this might interest you. -- Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Closed: (MNG-1844) Allow users to disable appending of assembly id to final name.
[ http://jira.codehaus.org/browse/MNG-1844?page=all ] Allan Ramirez closed MNG-1844: -- Resolution: Fixed Applied. Thanks Allow users to disable appending of assembly id to final name. -- Key: MNG-1844 URL: http://jira.codehaus.org/browse/MNG-1844 Project: Maven 2 Type: Improvement Components: maven-assembly-plugin Versions: 2.0.1 Environment: Win XP SP2, Maven 2.0.1 Reporter: Henry S. Isidro Assignee: Allan Ramirez Attachments: AbstractAssemblyMojo.diff, DirectoryMojo.diff The assembly plugin always appends the assembly id to the final name of the assembly. There are times where the final name does not have to end with -bin or - src or -jar-wit-dependencies. The patch adds a parameter, appendAssemblyId to the plugin configuration so that the user can set this to false if he does not want theassembly id to be appended to the assembly final name. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
