[jira] Updated: (CONTINUUM-267) SizeLimitExceededException on upload M1 project file
[ http://jira.codehaus.org/browse/CONTINUUM-267?page=all ] Emmanuel Venisse updated CONTINUUM-267: --- Complexity: Novice (was: Intermediate) Remaining Estimate: 1 hour Original Estimate: 3600 SizeLimitExceededException on upload M1 project file Key: CONTINUUM-267 URL: http://jira.codehaus.org/browse/CONTINUUM-267 Project: Continuum Type: Bug Components: continuum-web Environment: Continuum builded from CVS. WinXP. jdk 142_09 Reporter: Anatol Pomozov Assignee: Emmanuel Venisse Priority: Minor Fix For: 1.0-alpha-4 Original Estimate: 1 hour Remaining: 1 hour When I try to upload M1 project.xml file I get following exception. Size of file is 23,5kb. I don't think that is too much for project file. 2005-08-17 13:05:39,828 [SocketListener0-2] ERROR RequestParameterParser - FileUpload failed org.apache.commons.fileupload.FileUploadBase$SizeLimitExceededException: the request was rejected because it's size exceeds allowed range at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:317) at org.codehaus.plexus.summit.parameters.BaseRequestParameterParser.processFileUploadItems(BaseRequestParameterParser.java:175) at org.codehaus.plexus.summit.parameters.BaseRequestParameterParser.parse(BaseRequestParameterParser.java:127) at org.codehaus.plexus.summit.rundata.AbstractRunData.setRequest(AbstractRunData.java:156) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:44) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) -- 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] Assigned: (CONTINUUM-267) SizeLimitExceededException on upload M1 project file
[ http://jira.codehaus.org/browse/CONTINUUM-267?page=all ] Emmanuel Venisse reassigned CONTINUUM-267: -- Assign To: Emmanuel Venisse SizeLimitExceededException on upload M1 project file Key: CONTINUUM-267 URL: http://jira.codehaus.org/browse/CONTINUUM-267 Project: Continuum Type: Bug Components: continuum-web Environment: Continuum builded from CVS. WinXP. jdk 142_09 Reporter: Anatol Pomozov Assignee: Emmanuel Venisse Priority: Minor Fix For: 1.0-alpha-4 When I try to upload M1 project.xml file I get following exception. Size of file is 23,5kb. I don't think that is too much for project file. 2005-08-17 13:05:39,828 [SocketListener0-2] ERROR RequestParameterParser - FileUpload failed org.apache.commons.fileupload.FileUploadBase$SizeLimitExceededException: the request was rejected because it's size exceeds allowed range at org.apache.commons.fileupload.FileUploadBase.parseRequest(FileUploadBase.java:317) at org.codehaus.plexus.summit.parameters.BaseRequestParameterParser.processFileUploadItems(BaseRequestParameterParser.java:175) at org.codehaus.plexus.summit.parameters.BaseRequestParameterParser.parse(BaseRequestParameterParser.java:127) at org.codehaus.plexus.summit.rundata.AbstractRunData.setRequest(AbstractRunData.java:156) at org.codehaus.plexus.summit.Summit.doGet(Summit.java:44) at org.codehaus.plexus.summit.Summit.doPost(Summit.java:108) at javax.servlet.http.HttpServlet.service(HttpServlet.java:615) at javax.servlet.http.HttpServlet.service(HttpServlet.java:688) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:358) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:567) at org.mortbay.http.HttpContext.handle(HttpContext.java:1807) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:525) at org.mortbay.http.HttpContext.handle(HttpContext.java:1757) at org.mortbay.http.HttpServer.service(HttpServer.java:879) at org.mortbay.http.HttpConnection.service(HttpConnection.java:789) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:960) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:806) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:218) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:331) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:520) -- 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 - SUCCESS - checkout] Tue Aug 23 00:30:00 GMT 2005
Distribution: http://maven.zones.apache.org/~continuum/builds/continuum-20050823.003000.tar.gz Log: http://maven.zones.apache.org/~continuum/logs/continuum-build-log-20050823.003000.txt
[jira] Commented: (CONTINUUM-293) no output in the mail notifier
[ http://jira.codehaus.org/browse/CONTINUUM-293?page=comments#action_44994 ] Brett Porter commented on CONTINUUM-293: no, there should be output in there, its just not working I think no output in the mail notifier -- Key: CONTINUUM-293 URL: http://jira.codehaus.org/browse/CONTINUUM-293 Project: Continuum Type: Bug Reporter: Brett Porter Fix For: 1.0-alpha-4 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-671) implement a license clickthrough
[ http://jira.codehaus.org/browse/MNG-671?page=all ] Brett Porter updated MNG-671: - Fix Version: (was: 2.0-beta-1) 2.0-beta-2 implement a license clickthrough Key: MNG-671 URL: http://jira.codehaus.org/browse/MNG-671 Project: Maven 2 Type: New Feature Reporter: Brett Porter Fix For: 2.0-beta-2 we need some basic license acceptance policy for downloadable artifacts. For now, this can just be a Y/N that is saved forever. -- 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-759) Empty artifacts when not using maven-core's default lifecycles
[ http://jira.codehaus.org/browse/MNG-759?page=all ] Brett Porter updated MNG-759: - Priority: Blocker (was: Major) Empty artifacts when not using maven-core's default lifecycles --- Key: MNG-759 URL: http://jira.codehaus.org/browse/MNG-759 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0-beta-1 Environment: xp Reporter: Dan Tran Priority: Blocker Fix For: 2.0-beta-1 maven project that uses external build lifecycle out side maven-core do not see it artifact list. in my case of using maven-native-plugin, my dll project has a .lib dependency, therefore the link phase will fail since the artifacts is empty ( project.getArtifacts() returns empty set) and the linker do not have the required lib file to link to This is a blocking bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-643) Support includes and excludes for the source and testSource directories.
[ http://jira.codehaus.org/browse/MNG-643?page=all ] Brett Porter updated MNG-643: - Priority: Critical (was: Major) Support includes and excludes for the source and testSource directories. Key: MNG-643 URL: http://jira.codehaus.org/browse/MNG-643 Project: Maven 2 Type: Improvement Components: maven-plugins Versions: 2.0-alpha-3 Environment: jdk 1.4.x, gentoo linux Reporter: Corridor Software Developer Assignee: John Casey Priority: Critical Fix For: 2.0-beta-1 Attachments: FilterCriteriaForCompilerPlugin.patch, FilterCriteriaForCompilerPlugin.patch, FilterCriteriaForCompilerPlugin.patch Original Estimate: 1 week Remaining: 1 week m2 currently supports FileSets in resources and testResources which allow for the inclusion and exclusion of files based on a pattern. Users may benefit from having this functionality in the source and testSource directory definitions as well. Here are some scenarios: 1) a volative package of java files may be excluded from a build to permit developers to continue building the other source files without having to delete or resolve issues for the problem files. 2) Source files and test source files may be kept in the same source tree in the same manner that resources and testResources may currently be kept in a single directory. 3) The change will allow for a parent pom.xml which applies a custom plugin against all source files for subprojects (modules) and subprojects which only compile subsets of these files to all point at the same directory. 4) Some development environments keep their source files in a single directory regardless of the deployment breakout. One reason is it isn't always obvious which artifact a particular source file is located in and consolidation eliminates the need to look around. 5) Elegant way of continuing to maintain Maven's one project one source set mantra in a multi-project environment without increasing the number of source directories. In an effort to avoid breaking the existing pom format, the following tags would be supported: sourceDirectory../../src/java/sourceDirectory xor source directory../../src/java/directory includes include**/package/*.java/include /includes excludes exclude**/*Test.java/exclude /excludes /source and testSourceDirectory../../src/java/testSourceDirectory xor testSource directory../../src/java/directory includes include**/*Test.java/include /includes /testSource This issue is NOT endorsing the support of multiple source directories. It would simply be possible to exclude some source files from the single directory. The change creates a path for deprecating the existing format later if desired. The change would not break existing pom.xml files. If a patch is not included with this issue, expect one soon. This f(x) is a blocker for our development environment because we have several critical tools which traverse all source files in a company project, not just a single artifact's files. So either support for multiple source directories by a parent project (ugh!) or filters on a single directory is a must have. I am currently working on the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-586) Do not include the third party Jsch libraries
[ http://jira.codehaus.org/browse/MNG-586?page=all ] Brett Porter updated MNG-586: - Priority: Critical (was: Major) Do not include the third party Jsch libraries -- Key: MNG-586 URL: http://jira.codehaus.org/browse/MNG-586 Project: Maven 2 Type: Wish Components: maven-artifact-ant Reporter: Jason van Zyl Assignee: Brett Porter Priority: Critical Fix For: 2.0-beta-1 Hello, Can I request that the Ant tasks for Maven do not include the third party Jsch libraries in their own jar It may seem a good solution to your dependencies -bundle them in your own JAR, but the consequences are -unless you release the libs in perfect syncrhonisation with the jsch releases, your version will be behind -if someone has a different version of the jsch stuff on the classpath, they may not get what they want -the ant team ends up fielding the bug reports We have problems with existing libraries including stuff like oro and antlr, and have documented it http://ant.apache.org/manual/install.html#librarydependencies Please dont add to the list. I understand the value in secure downloads, but feel this is the wrong tactic. If having the library is a prerequisite, please point to the library at download time. Otherwise, well, surely dynamic downloading of stuff is what the library is meant to be good at? -- 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-139) server definitions should be reusable
[ http://jira.codehaus.org/browse/MNG-139?page=all ] Brett Porter updated MNG-139: - Priority: Critical (was: Major) server definitions should be reusable - Key: MNG-139 URL: http://jira.codehaus.org/browse/MNG-139 Project: Maven 2 Type: Task Components: design Reporter: Brett Porter Priority: Critical Fix For: 2.0-beta-1 currently if multiple projects use the same server for deployment, we are relying on inheritence to share the definition, or it must be copied. This applies similarly to the SCM connection and the dist/site management settings. It would be a good idea to be able to declare these elements in a deployed artifact. It may still be reasonable to do this through inheritence, but there is a chance we'll hit the need for multiple inheritence (because multiple projects inherit things from different sources), so we should enumerate the use cases and verify it. eg. A B / \ / \ C D E Where A and B declare two different things that D uses both of, but which C and E desire only to inherit one of. This essentially using composition for some elements instead of inheritence. -- 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-626) mojos/plexus needs to work with setter based injection
[ http://jira.codehaus.org/browse/MNG-626?page=all ] Brett Porter updated MNG-626: - Priority: Critical (was: Major) mojos/plexus needs to work with setter based injection -- Key: MNG-626 URL: http://jira.codehaus.org/browse/MNG-626 Project: Maven 2 Type: Task Components: maven-plugin-api Reporter: Brett Porter Priority: Critical Fix For: 2.0-beta-1 we've talked about putting setters on mojos for reusability - plexus needs to be able to actually use them (in the case where they do more than just assignment) instead of the private field injection. -- 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-555) POM XSD and site doco out of sync and both may be out of sync with code
[ http://jira.codehaus.org/browse/MNG-555?page=all ] Brett Porter updated MNG-555: - Priority: Critical (was: Major) POM XSD and site doco out of sync and both may be out of sync with code --- Key: MNG-555 URL: http://jira.codehaus.org/browse/MNG-555 Project: Maven 2 Type: Bug Components: maven-model Versions: 2.0-alpha-3 Environment: Win 2K, Java 1.4.2 Java 1.5.0 Reporter: Andy Glick Priority: Critical Fix For: 2.0-beta-1 It looks as if the XML schema is out of sync with the POM documentation page and both may be out of sync with the code. The following fragment from Plugin type's definition on the POM documentation page does not appear in the published XSD: http://maven.apache.org/maven2/maven-model/maven.html executions pluginExecution id/ phase/ goals/ inherited/ configuration/ /pluginExecution /executions Maven 2 XSD http://maven.apache.org/maven-v4_0_0.xsd In addition, in a post from the Maven User mailing list the following fragment was reported to work, and it matches neither of the published formats: executions execution goals goalsablecc/goal /goals /execution /executions http://marc.theaimsgroup.com/?l=turbine-maven-userm=112064009313457w=2 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-766) provided scoped dependencies is not made available during tests, making the tests fail with errors.
[ http://jira.codehaus.org/browse/MNG-766?page=all ] Brett Porter updated MNG-766: - Priority: Critical (was: Major) provided scoped dependencies is not made available during tests, making the tests fail with errors. - Key: MNG-766 URL: http://jira.codehaus.org/browse/MNG-766 Project: Maven 2 Type: Bug Reporter: Edwin Punzalan Priority: Critical Fix For: 2.0-beta-1 -- 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-742) Added functionality to maven-archiver so plug-ins can add custom entries to the archiver's manifest
[ http://jira.codehaus.org/browse/MNG-742?page=all ]
Brett Porter updated MNG-742:
-
Priority: Critical (was: Major)
Added functionality to maven-archiver so plug-ins can add custom entries to
the archiver's manifest
---
Key: MNG-742
URL: http://jira.codehaus.org/browse/MNG-742
Project: Maven 2
Type: Improvement
Components: maven-archiver
Versions: 2.0-alpha-3
Reporter: Timothy Bennett
Priority: Critical
Fix For: 2.0-beta-1
Attachments: MavenArchiveConfiguration.java, MavenArchiver.java
Added functionality to the maven-archiver plugin so that other plugins can
add custom manifest entries. Made some fairly minor changes to both
MavenArchiveConfiguration.java and MavenArchiver.java. Description of
changes below, and I've attached my marked up changes to the M2 HEAD of both
files.
MavenArchiveConfiguration.java
=
Added the following methods (along with appropriate imports):
private Map manifestEntries = new HashMap();
public void addManifestEntry(Object key, Object value) {
manifestEntries.put(key, value);
}
public void addManifestEntries(Map map) {
manifestEntries.putAll(map);
}
public boolean isManifestEntriesEmpty() {
return manifestEntries.isEmpty();
}
public Map getManifestEntries() {
return manifestEntries;
}
Changes maintain a collection of custom manifest entries stored a name-value
pairs. Plugins use the first two methods to add custom manifest entries to
the collection. MavenArchiver uses the last two methods to retrieve the set
of entries and add them to the archive's manifest.
===
MavenArchiver.java
===
In the createArchive() method of MavenArchiver, added the following marked
code block to retrieve the custom manifest entries (if any available) from
the MavenArchiveConfiguration and add them to the archive's manifest.
Manifest manifest = getManifest( project,
archiveConfiguration.getManifest() );
// THIS IS THE START OF THE CODE BLOCK I ADDED
// any custom manifest entries in the archive configuration
manifest?
if (!archiveConfiguration.isManifestEntriesEmpty()) {
Map entries = archiveConfiguration.getManifestEntries();
Set keys = entries.keySet();
for (Iterator iter = keys.iterator(); iter.hasNext(); )
{
String key = (String) iter.next();
String value = (String) entries.get(key);
Manifest.Attribute attr = new
Manifest.Attribute(key, value);
manifest.addConfiguredAttribute(attr);
}
}
// THIS IS THE END OF THE CODE BLOCK I ADDED
// Configure the jar
archiver.addConfiguredManifest( manifest );
--
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-634) Scope needs to be taken into account when providing dependencies by ant tasks
[ http://jira.codehaus.org/browse/MNG-634?page=all ] Brett Porter updated MNG-634: - Priority: Critical (was: Major) Scope needs to be taken into account when providing dependencies by ant tasks - Key: MNG-634 URL: http://jira.codehaus.org/browse/MNG-634 Project: Maven 2 Type: Improvement Components: maven-artifact-ant Versions: 2.0-alpha-3 Environment: any Reporter: Matthias Unverzagt Assignee: Brett Porter Priority: Critical Fix For: 2.0-beta-1 Best practise would be to have all depency info inside pom.xml files, none within build.xml files. One of this info is the 'scope' information. Suppose you declare a dependency that is needed for compiling but not in your runtime environment because it is provided by e.g. the container then you - would like to have the dependency on your compile classpath (e.g. to be independend of the container) - would like to have a fileset representing the runtime requirement - omitting the provided dependency Therefore there needs to be some kind of scope filter insided the dependencies task. Example: artifact:dependencies pathId=dependency.compile.classpath scope=compile pom refid=maven.project/ localRepository refid=repo.localrepo/ /artifact:dependencies artifact:dependencies filesetId=dependency.runtime.fileset scope=runtime pom refid=maven.project/ localRepository refid=repo.localrepo/ /artifact:dependencies CONCERNING PRIORITY: Without such a scope attribute you need to duplicate the scope information that is in the pom.xml in some sense inside the build.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]
[jira] Updated: (MNG-732) Improve plugin configuration property merge algorithm
[ http://jira.codehaus.org/browse/MNG-732?page=all ]
Brett Porter updated MNG-732:
-
Priority: Critical (was: Major)
Improve plugin configuration property merge algorithm
-
Key: MNG-732
URL: http://jira.codehaus.org/browse/MNG-732
Project: Maven 2
Type: Improvement
Components: maven-core
Versions: 2.0-alpha-3
Reporter: Vincent Massol
Priority: Critical
Fix For: 2.0-beta-1
If the property are the same in the parent and the child project, then the
parent property is not inherited. This is fine for simple properties but
breaks for complex properties such as lists. Here's an example:
My parent POM:
build
pluginManagement
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
systemProperties
property
namecargo.resin3x.port/name
value8280/value
/property
property
namecargo.resin3x.url/name
valuehttp://www.caucho.com/download/resin-3.0.9.zip/value
/property
/systemProperties
/configuration
/plugin
/plugins
/pluginManagement
/build
My child POM:
build
plugins
plugin
artifactIdmaven-surefire-plugin/artifactId
configuration
systemProperties
!-- Default list of containers to run on. If you want to shorten
or change the
execution of 'samples', simply specify a shorter list of
containers on the
command line or in your settings --
property
namecargo.containers/name
valueresin3x, orion2x, tomcat5x, jetty4xEmbedded/value
/property
!-- Location where to download and install the containers for
the tests --
property
namecargo.install.dir/name
value${basedir}/../../target/installs/value
/property
/systemProperties
/configuration
/plugin
/plugins
/build
It sounds a reasonable expectations that the system properties will get
merged.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-702) Add ability to exclude all transitive dependencies except those specified as inclusions
[ http://jira.codehaus.org/browse/MNG-702?page=all ] Brett Porter updated MNG-702: - Priority: Critical (was: Major) Add ability to exclude all transitive dependencies except those specified as inclusions --- Key: MNG-702 URL: http://jira.codehaus.org/browse/MNG-702 Project: Maven 2 Type: Improvement Versions: 2.0-alpha-3 Reporter: Ken Weiner Priority: Critical Fix For: 2.0-beta-1 Currently there is an ability to specify an optional exclusions element as a child of dependency within a POM. This has the effect of excluding one or more of a dependency's transitive dependencies. It is often the case that a dependency itself has many dependencies needed for compilation, but are not necessarily needed at runtime. This is a request to add an optional inclusions element as a child to dependency within a POM so that it is possible to express the instruction Don't get any of the transitive dependencies except for X, Y, Z, etc. For example: dependency groupIdspringframework/groupId artifactIdspring/artifactId version1.2.2/version scopecompile/scope inclusions inclusion groupIdhibernate/groupId artifactIdhibernate/artifactId /inclusion /inclusions /dependency Brett Porter pointed out on the maven users mailing list that this approach could have some pitfalls, but that I should still submit the issue for discussion. -- 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-758) final clarifications of Mojo API
[ http://jira.codehaus.org/browse/MNG-758?page=all ] Brett Porter updated MNG-758: - Priority: Critical (was: Major) final clarifications of Mojo API Key: MNG-758 URL: http://jira.codehaus.org/browse/MNG-758 Project: Maven 2 Type: Improvement Components: maven-plugin-api Reporter: Brett Porter Priority: Critical Fix For: 2.0-beta-1 I'm finding the expression vs default-value a bit confusing - I think we have discussed this before. expression is often being used as the default value - sometimes by necessity because default-value doesn't accept expressions. Suggestions: - default-value should accept expressions - add a @component role=... roleHint=... to replace the component expression - expression should be the value (And if null, use the default-value). THis usually represents the project field to look up, or the system property to use -- 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-666) need to be able to operate on a Maven 1 repository
[ http://jira.codehaus.org/browse/MNG-666?page=all ] Brett Porter updated MNG-666: - Priority: Critical (was: Major) need to be able to operate on a Maven 1 repository -- Key: MNG-666 URL: http://jira.codehaus.org/browse/MNG-666 Project: Maven 2 Type: Bug Components: maven-artifact Versions: 2.0-alpha-3 Environment: Not of importance. Reporter: Davy Toch Assignee: John Casey Priority: Critical Fix For: 2.0-beta-1 I have an ANT script using maven antlib (alpha-3) as follows: ... target name=getdeps artifact:remoteRepository id=remote.repository url=http://172.16.40.249/ourrepo; layout=legacy/ artifact:dependencies verbose=true remoteRepository refid=remote.repository/ dependency groupId=sis2 artifactId=sis2-common version=0.1/ /artifact:dependencies /target ... The central repository contains only artifacts with model-3.0.0 POMs (generated by Maven 1.1) However when executing the ANT target I get the following exception: --- Nested Exception --- org.apache.maven.artifact.resolver.TransitiveArtifactResolutionException: Unable to read the metadata file sis2:sis2-common:0.1:jar from the specified remote repositories: http://172.16.40.249/ourrepo Path to dependency: 1) unspecified:unspecified:jar:0.0 at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:164) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.collect(DefaultArtifactCollector.java:66) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:173) at org.apache.maven.artifact.resolver.DefaultArtifactResolver.resolveTransitively(DefaultArtifactResolver.java:199) at org.apache.maven.artifact.ant.DependenciesTask.execute(DependenciesTask.java:115) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:275) at org.apache.tools.ant.Task.perform(Task.java:364) at org.apache.tools.ant.Target.execute(Target.java:341) at org.apache.tools.ant.Target.performTasks(Target.java:369) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1216) at org.apache.tools.ant.Project.executeTarget(Project.java:1185) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:40) at org.apache.tools.ant.Project.executeTargets(Project.java:1068) at org.apache.tools.ant.Main.runBuild(Main.java:668) at org.apache.tools.ant.Main.startAnt(Main.java:187) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:246) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:67) Caused by: org.apache.maven.artifact.metadata.ArtifactMetadataRetrievalException: Unable to read the metadata file at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:88) at org.apache.maven.artifact.resolver.DefaultArtifactCollector.recurse(DefaultArtifactCollector.java:151) ... 16 more Caused by: org.apache.maven.project.ProjectBuildingException: Failed to validate POM for 'Artifact [sis2:sis2-common:pom:0.1]'. Reason(s): [0] 'modelVersion' is missing. at org.apache.maven.project.DefaultMavenProjectBuilder.processProjectLogic(DefaultMavenProjectBuilder.java:439) at org.apache.maven.project.DefaultMavenProjectBuilder.build(DefaultMavenProjectBuilder.java:317) at org.apache.maven.project.DefaultMavenProjectBuilder.buildFromRepository(DefaultMavenProjectBuilder.java:220) at org.apache.maven.project.artifact.MavenMetadataSource.retrieve(MavenMetadataSource.java:81) ... 17 more The problem is that in the class DefaultModelValidator (apparently always called when retrieving a dependency) a check is done to verify whether the element modelVersion is present in the POM. However for model-3.0.0 POMs this element isn't defined in the XSD! Regards, Davy Toch -- 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-605) allow updates of repository metadata (currently plugins.xml)
[ http://jira.codehaus.org/browse/MNG-605?page=all ] Brett Porter updated MNG-605: - Priority: Critical (was: Major) allow updates of repository metadata (currently plugins.xml) Key: MNG-605 URL: http://jira.codehaus.org/browse/MNG-605 Project: Maven 2 Type: Bug Reporter: Brett Porter Priority: Critical Fix For: 2.0-beta-1 currently, local changes get blown away by remote updates. We need to be able to merge the changes. This can be done by timestamping the last update of an entry. Any newer ones get updated from the remote source. Removal of elements will require replacing with an empty element instead of just removing it, otherwise the merge process will not be able to determine if it was removed locally, or new remotely. -- 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-763) consider include source root
[ http://jira.codehaus.org/browse/MNG-763?page=all ] Brett Porter updated MNG-763: - Priority: Critical (was: Major) consider include source root Key: MNG-763 URL: http://jira.codehaus.org/browse/MNG-763 Project: Maven 2 Type: New Feature Reporter: Brett Porter Priority: Critical Fix For: 2.0-beta-1 this is something used by the native plugin but could be used by several plugins that deal with C/C++ and maybe other languages. We should consider adding it to the build section and the MavenProject object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-730) Ability to use single lifecle with dynamic extension
[ http://jira.codehaus.org/browse/MNG-730?page=all ] Brett Porter updated MNG-730: - Priority: Critical (was: Major) Ability to use single lifecle with dynamic extension Key: MNG-730 URL: http://jira.codehaus.org/browse/MNG-730 Project: Maven 2 Type: Bug Versions: 2.0-beta-1 Environment: xp Reporter: Dan Tran Priority: Critical Fix For: 2.0-beta-1 Currently maven-project, via maven-artifact-manager , uses pom packaging's value (also use by lifecycle) to lookup a ArtifcactHandler and then get the extension out of that artifact handler. This is one to one relationship, one lifecyle per artifact extension. Because of this issue, I have to use one lifecycle per extension ( ie native-dll artifact hanlder will have dll extension) for maven-native-plugin which has the following extension .dll, .exe, .lib, .so, si, .a and may be more The work around still need the fix for MNG-729 -- 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-605) allow updates of repository metadata (currently plugins.xml)
[ http://jira.codehaus.org/browse/MNG-605?page=all ] Brett Porter updated MNG-605: - Priority: Blocker (was: Critical) allow updates of repository metadata (currently plugins.xml) Key: MNG-605 URL: http://jira.codehaus.org/browse/MNG-605 Project: Maven 2 Type: Bug Reporter: Brett Porter Priority: Blocker Fix For: 2.0-beta-1 currently, local changes get blown away by remote updates. We need to be able to merge the changes. This can be done by timestamping the last update of an entry. Any newer ones get updated from the remote source. Removal of elements will require replacing with an empty element instead of just removing it, otherwise the merge process will not be able to determine if it was removed locally, or new remotely. -- 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-626) mojos/plexus needs to work with setter based injection
[ http://jira.codehaus.org/browse/MNG-626?page=all ] Brett Porter updated MNG-626: - Priority: Blocker (was: Critical) mojos/plexus needs to work with setter based injection -- Key: MNG-626 URL: http://jira.codehaus.org/browse/MNG-626 Project: Maven 2 Type: Task Components: maven-plugin-api Reporter: Brett Porter Priority: Blocker Fix For: 2.0-beta-1 we've talked about putting setters on mojos for reusability - plexus needs to be able to actually use them (in the case where they do more than just assignment) instead of the private field injection. -- 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-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=all ] Brett Porter updated MNG-624: - Priority: Critical (was: Major) automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Type: Improvement Reporter: Brett Porter Priority: Critical Fix For: 2.0-beta-1 (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-734) java.lang.InstantiationException while deploying snapshot
[ http://jira.codehaus.org/browse/MNG-734?page=all ] Brett Porter closed MNG-734: Assign To: Brett Porter (was: John Casey) Resolution: Duplicate Fix Version: (was: 2.0-beta-1) java.lang.InstantiationException while deploying snapshot - Key: MNG-734 URL: http://jira.codehaus.org/browse/MNG-734 Project: Maven 2 Type: Bug Components: maven-plugins Versions: 2.0-beta-1 Reporter: Bob Allison Assignee: Brett Porter Setting up a project to deploy a snapshot. From comments of others, I have a bad POM in one of my dependencies (haven't tracked that down yet). When I set the project's version to 3.0, the jar is deployed properly. When I set the project's version to 3.0-SNAPSHOT, I get the following stack dump: [INFO] [ERROR] BUILD ERROR [INFO] [INFO] Diagnosis: Error configuring plugin for execution of 'deploy:deploy'. [INFO] [ERROR] Cause: org.apache.maven.plugin.MojoExecutionException: Error configuring plugin for execution of 'deploy:deploy'. at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:342) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:472) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:445) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:431) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:268) at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:127) at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:186) at org.apache.maven.cli.MavenCli.main(MavenCli.java:292) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315) at org.codehaus.classworlds.Launcher.launch(Launcher.java:255) at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430) at org.codehaus.classworlds.Launcher.main(Launcher.java:375) Caused by: org.apache.maven.plugin.PluginConfigurationException: Unable to parse the created DOM for plugin configuration at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1022) at org.apache.maven.plugin.DefaultPluginManager.getConfiguredMojo(DefaultPluginManager.java:522) at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:337) ... 15 more Caused by: org.codehaus.plexus.component.configurator.ComponentConfigurationException: Class 'org.apache.maven.artifact.repository.ArtifactRepository' cannot be instantiated at org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:120) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.fromConfiguration(ObjectWithFieldsConverter.java:83) at org.codehaus.plexus.component.configurator.converters.composite.ObjectWithFieldsConverter.processConfiguration(ObjectWithFieldsConverter.java:118) at org.codehaus.plexus.component.configurator.BasicComponentConfigurator.configureComponent(BasicComponentConfigurator.java:55) at org.apache.maven.plugin.DefaultPluginManager.populatePluginFields(DefaultPluginManager.java:1017) ... 17 more Caused by: java.lang.InstantiationException: org.apache.maven.artifact.repository.ArtifactRepository at java.lang.Class.newInstance0(Class.java:335) at java.lang.Class.newInstance(Class.java:303) at org.codehaus.plexus.component.configurator.converters.AbstractConfigurationConverter.instantiateObject(AbstractConfigurationConverter.java:110) ... 21 more -- 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
[jira] Updated: (MNG-758) final clarifications of Mojo API
[ http://jira.codehaus.org/browse/MNG-758?page=all ] Brett Porter updated MNG-758: - Priority: Blocker (was: Critical) final clarifications of Mojo API Key: MNG-758 URL: http://jira.codehaus.org/browse/MNG-758 Project: Maven 2 Type: Improvement Components: maven-plugin-api Reporter: Brett Porter Priority: Blocker Fix For: 2.0-beta-1 I'm finding the expression vs default-value a bit confusing - I think we have discussed this before. expression is often being used as the default value - sometimes by necessity because default-value doesn't accept expressions. Suggestions: - default-value should accept expressions - add a @component role=... roleHint=... to replace the component expression - expression should be the value (And if null, use the default-value). THis usually represents the project field to look up, or the system property to use -- 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-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=all ] Brett Porter updated MNG-624: - Priority: Blocker (was: Critical) automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Type: Improvement Reporter: Brett Porter Priority: Blocker Fix For: 2.0-beta-1 (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-759) Empty artifacts when not using maven-core's default lifecycles
[ http://jira.codehaus.org/browse/MNG-759?page=all ] Dan Tran updated MNG-759: - Attachment: pom.xml Here are important info about the attached pom.xml - packaging = dll , i have my own lifecycle defined in my maven-native-plugin's components.xml - I have a dependency of type libanother lifecycle - in the linkerStartOption, i have to hardcode the .lib file inorder to link linkerStartOption ..\common\target\modiiop-windows-x86-common-7.0-SNAPSHOT.lib /linkerStartOption - I dont have ArtifactHandler for type dll, lib. M2 uses the lifecycle name as extention name when It is not able to find the artifact Handler Empty artifacts when not using maven-core's default lifecycles --- Key: MNG-759 URL: http://jira.codehaus.org/browse/MNG-759 Project: Maven 2 Type: Bug Components: maven-core Versions: 2.0-beta-1 Environment: xp Reporter: Dan Tran Priority: Blocker Fix For: 2.0-beta-1 Attachments: pom.xml maven project that uses external build lifecycle out side maven-core do not see it artifact list. in my case of using maven-native-plugin, my dll project has a .lib dependency, therefore the link phase will fail since the artifacts is empty ( project.getArtifacts() returns empty set) and the linker do not have the required lib file to link to This is a blocking bug. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-591) Integration tests lifecycle
[ http://jira.codehaus.org/browse/MNG-591?page=all ] Brett Porter updated MNG-591: - Assign To: Brett Porter (was: John Casey) Remaining Estimate: 1 day Original Estimate: 86400 Integration tests lifecycle --- Key: MNG-591 URL: http://jira.codehaus.org/browse/MNG-591 Project: Maven 2 Type: Improvement Reporter: Kenney Westerhof Assignee: Brett Porter Priority: Blocker Fix For: 2.0-beta-1 Original Estimate: 1 day Remaining: 1 day I'm trying to do an integration test that depends on a war/ear to be deployed. What i'm missing is: - integration-test-compile stage and/or: - a way to specify an integrationTestSourceDirectory or multiple testSourceDirectories in the pom I can't put the test sources in src/test/java because then surefire will run them in the test stage, when there's no artifact to deploy yet. [Btw, I'm doing this while creating a cactus plugin, for the moment using cargo in the TestSuite itself to deploy.] The idea is that the integration test sources go in src/itest/*; that there be a integration-test-compile, integration-test-package and/or integration-test-appdeploy[or something] and that surefire is also bound to integration-test. Maybe something can be done using the src/test/project/some-project/ approach seen in maven-javadoc-plugin, maven-site-plugin and maven-eclipse-plugin (i'd like to see some of that standardized anyway to allow plugin testing generally - which can also be seen as integration testing). Thoughts, comments, approaches? -- 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: (MPMULTIPROJECT-54) bug interacting with the cactus-plugin 1.7
[ http://jira.codehaus.org/browse/MPMULTIPROJECT-54?page=all ] Brett Porter updated MPMULTIPROJECT-54: --- Description: I have found a strange bug in the combination of the cactus-plugin 1.7 and the multiproject-plugin 1.4.1. When using the cactus goal in the sub-project, everything works fine here is an extract of the subproject maven.xml : goal name=project:clean attainGoal name=clean/ /goal goal name=project:snapshot attainGoal name=test/ attainGoal name=cactus/ /goal goal name=project:clean-snapshot attainGoal name=project:clean/ attainGoal name=project:snapshot/ /goal goal name=project:dist-src attainGoal name=project:clean-snapshot/ attainGoal name=site/ attainGoal name=dist:build-src/ /goal project:dist-src is the goal i call in the subproject directory. when i call the same goal (using the multiproject plugin from the englober project) it doesn't works. here is an extract of the project englober maven.xml goal name=project:multi-dist-src j:set var=goal value=project:dist-src/ attainGoal name=multiproject:goal/ /goal and project:multi-dist-src is the goal i call from the project englober directory. I have attached the console results of both the only local working goal (war.txt) and the englober log (englober.txt) I have also snipped the logs for more clarity. was: I have found a strange bug in the combination of the cactus-plugin 1.7 and the multiproject-plugin 1.4.1. When using the cactus goal in the sub-project, everything works fine here is an extract of the subproject maven.xml : goal name=project:clean attainGoal name=clean/ /goal goal name=project:snapshot attainGoal name=test/ attainGoal name=cactus/ /goal goal name=project:clean-snapshot attainGoal name=project:clean/ attainGoal name=project:snapshot/ /goal goal name=project:dist-src attainGoal name=project:clean-snapshot/ attainGoal name=site/ attainGoal name=dist:build-src/ /goal project:dist-src is the goal i call in the subproject directory. when i call the same goal (using the multiproject plugin from the englober project) it doesn't works. here is an extract of the project englober maven.xml goal name=project:multi-dist-src j:set var=goal value=project:dist-src/ attainGoal name=multiproject:goal/ /goal and project:multi-dist-src is the goal i call from the project englober directory. I have attached the console results of both the only local working goal (war.txt) and the englober log (englober.txt) I have also snipped the logs for more clarity. Remaining Estimate: (was: 4 hours) Original Estimate: (was: 14400) bug interacting with the cactus-plugin 1.7 -- Key: MPMULTIPROJECT-54 URL: http://jira.codehaus.org/browse/MPMULTIPROJECT-54 Project: maven-multiproject-plugin Type: Bug Versions: 1.4.1 Environment: WinXP maven-1.0.2 Reporter: Raphaël Piéroni Assignee: Brett Porter Attachments: englober.txt, war.txt I have found a strange bug in the combination of the cactus-plugin 1.7 and the multiproject-plugin 1.4.1. When using the cactus goal in the sub-project, everything works fine here is an extract of the subproject maven.xml : goal name=project:clean attainGoal name=clean/ /goal goal name=project:snapshot attainGoal name=test/ attainGoal name=cactus/ /goal goal name=project:clean-snapshot attainGoal name=project:clean/ attainGoal name=project:snapshot/ /goal goal name=project:dist-src attainGoal name=project:clean-snapshot/ attainGoal name=site/ attainGoal name=dist:build-src/ /goal project:dist-src is the goal i call in the subproject directory. when i call the same goal (using the multiproject plugin from the englober project) it doesn't works. here is an extract of the project englober maven.xml goal name=project:multi-dist-src j:set var=goal value=project:dist-src/ attainGoal name=multiproject:goal/ /goal and project:multi-dist-src is the goal i call from the project englober directory. I have attached the console results of both the only local working goal (war.txt) and the englober log (englober.txt) I have also snipped the logs for more clarity. -- 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: (MAVEN-1452) Documentation: Windows Repository: Maven Repository, Roaming Profiles
[ http://jira.codehaus.org/browse/MAVEN-1452?page=all ] Brett Porter updated MAVEN-1452: Description: Hi there The default behaviour of maven is to store the MAVEN_REPO under %USERPROFILE%\.maven\.. On Windows. This is all o.k. BUT: if you are logged on a Win-NT Domain and use Roaming Profiles the is a little problem: - the Maven Repo get copied all the time (due to roaming, and the location of the maven repo) - longer Login-times - Problems with the profile space (if limited) I don't think that the default location of the repo should be changed. But at least there should be a remark on http://maven.apache.org/start/install.html How to change the it (%USERPROFILE%\build.properties [maven.repo.local=C:/x/y/z] -?) CHECK: http://www.mail-archive.com/[EMAIL PROTECTED]/msg11654.html was: Hi there The default behaviour of maven is to store the MAVEN_REPO under %USERPROFILE%\.maven\.. On Windows. This is all o.k. BUT: if you are logged on a Win-NT Domain and use Roaming Profiles the is a little problem: - the Maven Repo get copied all the time (due to roaming, and the location of the maven repo) - longer Login-times - Problems with the profile space (if limited) I don't think that the default location of the repo should be changed. But at least there should be a remark on http://maven.apache.org/start/install.html How to change the it (%USERPROFILE%\build.properties [maven.repo.local=C:/x/y/z] -?) CHECK: http://www.mail-archive.com/[EMAIL PROTECTED]/msg11654.html Remaining Estimate: (was: 2 hours) Original Estimate: (was: 7200) Documentation: Windows Repository: Maven Repository, Roaming Profiles - Key: MAVEN-1452 URL: http://jira.codehaus.org/browse/MAVEN-1452 Project: Maven Type: Improvement Components: documentation Environment: Windows Reporter: Rolf Schmidiger Assignee: Brett Porter Fix For: 1.1-beta-2 Attachments: roaming.patch Hi there The default behaviour of maven is to store the MAVEN_REPO under %USERPROFILE%\.maven\.. On Windows. This is all o.k. BUT: if you are logged on a Win-NT Domain and use Roaming Profiles the is a little problem: - the Maven Repo get copied all the time (due to roaming, and the location of the maven repo) - longer Login-times - Problems with the profile space (if limited) I don't think that the default location of the repo should be changed. But at least there should be a remark on http://maven.apache.org/start/install.html How to change the it (%USERPROFILE%\build.properties [maven.repo.local=C:/x/y/z] -?) CHECK: http://www.mail-archive.com/[EMAIL PROTECTED]/msg11654.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: (MAVEN-125) Documentation enhancements
[ http://jira.codehaus.org/browse/MAVEN-125?page=all ] Brett Porter updated MAVEN-125: --- Description: Ok, Here are some changes I would recommend (as dIon asked for it ;-): 1) Change the welcome page to have direct links to gettting started. This is what I want to see when I visit the front page 2) The user guide should have information from the download and install sections to make it a more complete user's guide 3) getting started and user's guide should possibly be rethought into user's guide and developer's guide. 4) The plug-ins should be split into core and additional (or optional) 5) Someone who has written a plug-in should write a plug-in development howto and integrate that with the developer's guide. 6) Plug-ins should be described on the listing page 7) In the user's guide it would be nice to have a link to an example maven.xml file Let me know what you guys think, when I get a chance to look at it further I may have some further suggestions (and maybe patches ;-). -warner +warner onstine+ was: Ok, Here are some changes I would recommend (as dIon asked for it ;-): 1) Change the welcome page to have direct links to gettting started. This is what I want to see when I visit the front page 2) The user guide should have information from the download and install sections to make it a more complete user's guide 3) getting started and user's guide should possibly be rethought into user's guide and developer's guide. 4) The plug-ins should be split into core and additional (or optional) 5) Someone who has written a plug-in should write a plug-in development howto and integrate that with the developer's guide. 6) Plug-ins should be described on the listing page 7) In the user's guide it would be nice to have a link to an example maven.xml file Let me know what you guys think, when I get a chance to look at it further I may have some further suggestions (and maybe patches ;-). -warner +warner onstine+ Remaining Estimate: (was: 1 week) Original Estimate: (was: 604800) Environment: Documentation enhancements -- Key: MAVEN-125 URL: http://jira.codehaus.org/browse/MAVEN-125 Project: Maven Type: Improvement Components: documentation Reporter: dion gillard Assignee: Brett Porter Priority: Minor Fix For: 1.1-beta-2 Ok, Here are some changes I would recommend (as dIon asked for it ;-): 1) Change the welcome page to have direct links to gettting started. This is what I want to see when I visit the front page 2) The user guide should have information from the download and install sections to make it a more complete user's guide 3) getting started and user's guide should possibly be rethought into user's guide and developer's guide. 4) The plug-ins should be split into core and additional (or optional) 5) Someone who has written a plug-in should write a plug-in development howto and integrate that with the developer's guide. 6) Plug-ins should be described on the listing page 7) In the user's guide it would be nice to have a link to an example maven.xml file Let me know what you guys think, when I get a chance to look at it further I may have some further suggestions (and maybe patches ;-). -warner +warner onstine+ -- 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-643) Support includes and excludes for the source and testSource directories.
[ http://jira.codehaus.org/browse/MNG-643?page=all ] Brett Porter updated MNG-643: - Remaining Estimate: (was: 1 week) Original Estimate: (was: 604800) Support includes and excludes for the source and testSource directories. Key: MNG-643 URL: http://jira.codehaus.org/browse/MNG-643 Project: Maven 2 Type: Improvement Components: maven-plugins Versions: 2.0-alpha-3 Environment: jdk 1.4.x, gentoo linux Reporter: Corridor Software Developer Assignee: John Casey Priority: Critical Fix For: 2.0-beta-1 Attachments: FilterCriteriaForCompilerPlugin.patch, FilterCriteriaForCompilerPlugin.patch, FilterCriteriaForCompilerPlugin.patch m2 currently supports FileSets in resources and testResources which allow for the inclusion and exclusion of files based on a pattern. Users may benefit from having this functionality in the source and testSource directory definitions as well. Here are some scenarios: 1) a volative package of java files may be excluded from a build to permit developers to continue building the other source files without having to delete or resolve issues for the problem files. 2) Source files and test source files may be kept in the same source tree in the same manner that resources and testResources may currently be kept in a single directory. 3) The change will allow for a parent pom.xml which applies a custom plugin against all source files for subprojects (modules) and subprojects which only compile subsets of these files to all point at the same directory. 4) Some development environments keep their source files in a single directory regardless of the deployment breakout. One reason is it isn't always obvious which artifact a particular source file is located in and consolidation eliminates the need to look around. 5) Elegant way of continuing to maintain Maven's one project one source set mantra in a multi-project environment without increasing the number of source directories. In an effort to avoid breaking the existing pom format, the following tags would be supported: sourceDirectory../../src/java/sourceDirectory xor source directory../../src/java/directory includes include**/package/*.java/include /includes excludes exclude**/*Test.java/exclude /excludes /source and testSourceDirectory../../src/java/testSourceDirectory xor testSource directory../../src/java/directory includes include**/*Test.java/include /includes /testSource This issue is NOT endorsing the support of multiple source directories. It would simply be possible to exclude some source files from the single directory. The change creates a path for deprecating the existing format later if desired. The change would not break existing pom.xml files. If a patch is not included with this issue, expect one soon. This f(x) is a blocker for our development environment because we have several critical tools which traverse all source files in a company project, not just a single artifact's files. So either support for multiple source directories by a parent project (ugh!) or filters on a single directory is a must have. I am currently working on the patch. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPJNLP-20) 'Update Manifest' feature should be optional
[ http://jira.codehaus.org/browse/MPJNLP-20?page=all ] Brett Porter updated MPJNLP-20: --- Description: The maven-jnlp-plugin strips out all JAR manifest attributes and replaces them with a bare-bones manifest that looks like this: Created-By: Apache Maven Manifest-Version: 1.0 (Plus the SHA1-Digest attributes for each .class entry) Apparently this was to work around bugs in Java Web Start in the 1.3.x versions of Java. My App requires 1.4.x, so I created a patched version of maven-jnlp-plugin that adds a property called 'maven.jnlp.update.manifest' which defaults to 'true' for backward compatibility. Setting maven.jnlp.update.manifest=false will preserve attributes in the signed JNLP JARs and seems to work fine with JWS in Java 1.4.2. I'm hoping someone will commit the patch and make a 1.4.2 release of the plugin... was: The maven-jnlp-plugin strips out all JAR manifest attributes and replaces them with a bare-bones manifest that looks like this: Created-By: Apache Maven Manifest-Version: 1.0 (Plus the SHA1-Digest attributes for each .class entry) Apparently this was to work around bugs in Java Web Start in the 1.3.x versions of Java. My App requires 1.4.x, so I created a patched version of maven-jnlp-plugin that adds a property called 'maven.jnlp.update.manifest' which defaults to 'true' for backward compatibility. Setting maven.jnlp.update.manifest=false will preserve attributes in the signed JNLP JARs and seems to work fine with JWS in Java 1.4.2. I'm hoping someone will commit the patch and make a 1.4.2 release of the plugin... Remaining Estimate: (was: 1 hour) Original Estimate: (was: 3600) 'Update Manifest' feature should be optional Key: MPJNLP-20 URL: http://jira.codehaus.org/browse/MPJNLP-20 Project: maven-jnlp-plugin Type: Improvement Environment: Mac OS X, Java 1.4.2 Reporter: M. Sean Gilligan Assignee: Emmanuel Venisse Fix For: 1.4.1 Attachments: maven-jnlp-plugin.diff The maven-jnlp-plugin strips out all JAR manifest attributes and replaces them with a bare-bones manifest that looks like this: Created-By: Apache Maven Manifest-Version: 1.0 (Plus the SHA1-Digest attributes for each .class entry) Apparently this was to work around bugs in Java Web Start in the 1.3.x versions of Java. My App requires 1.4.x, so I created a patched version of maven-jnlp-plugin that adds a property called 'maven.jnlp.update.manifest' which defaults to 'true' for backward compatibility. Setting maven.jnlp.update.manifest=false will preserve attributes in the signed JNLP JARs and seems to work fine with JWS in Java 1.4.2. I'm hoping someone will commit the patch and make a 1.4.2 release of the plugin... -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPJNLP-16) Handle shortcut properties in jnlp-file
[ http://jira.codehaus.org/browse/MPJNLP-16?page=all ] Brett Porter updated MPJNLP-16: --- Description: The JNLP File handles a property shortcut, that tells the jnlp client how to handle shortcuts for the application the jnlp-file describes. These properties are not managed by maven-jnlp-plugin atm. I would like to contribute an extension to the plugin.jelly file, so I dont have to patch the file myself everytime. Greetings, Christian Domsch was: The JNLP File handles a property shortcut, that tells the jnlp client how to handle shortcuts for the application the jnlp-file describes. These properties are not managed by maven-jnlp-plugin atm. I would like to contribute an extension to the plugin.jelly file, so I dont have to patch the file myself everytime. Greetings, Christian Domsch Remaining Estimate: (was: 15 minutes) Original Estimate: (was: 900) Handle shortcut properties in jnlp-file --- Key: MPJNLP-16 URL: http://jira.codehaus.org/browse/MPJNLP-16 Project: maven-jnlp-plugin Type: New Feature Versions: 1.4 Environment: Windows XP, jdk 5.0 Reporter: Christian Domsch Assignee: Emmanuel Venisse Attachments: plugin.jelly.diff The JNLP File handles a property shortcut, that tells the jnlp client how to handle shortcuts for the application the jnlp-file describes. These properties are not managed by maven-jnlp-plugin atm. I would like to contribute an extension to the plugin.jelly file, so I dont have to patch the file myself everytime. Greetings, Christian Domsch -- 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: (MPJNLP-27) Unable to specify expressions for maven.jnlp.description
[ http://jira.codehaus.org/browse/MPJNLP-27?page=all ]
Brett Porter updated MPJNLP-27:
---
Remaining Estimate: (was: 5 minutes)
Original Estimate: (was: 300)
Unable to specify expressions for maven.jnlp.description
Key: MPJNLP-27
URL: http://jira.codehaus.org/browse/MPJNLP-27
Project: maven-jnlp-plugin
Type: Bug
Versions: 1.4.1
Environment: Windows XP
Reporter: Bjorn Martensson
Assignee: Emmanuel Venisse
I tried to assign a variable like this:
maven.jnlp.description=${projectDescription}
When I did maven jnlp I got the following error:
BUILD FAILED
File.. C:\Documents and
Settings\Bjorn\.maven\cache\maven-jnlp-plugin-1.4.1\plugin.jelly
Element... maven:property
Line.. 60
Column 90
org.apache.commons.jelly.expression.ConstantExpression
Total time: 9 seconds
Finished at: Sat Jul 23 12:58:49 BST 2005
I modified the plugin in my local repository and came up with the following
solution:
1. Uncomment the default value for maven.jnlp.description in the
plugin.properties file. (Why was it commented out?)
2. Delete line 60 from the plugin.jelly file (line 60: maven:property
name=maven.jnlp.description defaultValue=${pom.description}/ )
--
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: (MPJBUILDER-15) Allow defenition of short list for goals shown
[ http://jira.codehaus.org/browse/MPJBUILDER-15?page=all ] Brett Porter updated MPJBUILDER-15: --- Description: It would be nice to allow the user to define a list of most often used goals so that it is easier to navigate. project.xml - goal 1 - goal 2 - goal 3 - goal x - other goals - current view of goals I think this should be an improvement since most developers only use 3 to 5 goals from their ide. was: It would be nice to allow the user to define a list of most often used goals so that it is easier to navigate. project.xml - goal 1 - goal 2 - goal 3 - goal x - other goals - current view of goals I think this should be an improvement since most developers only use 3 to 5 goals from their ide. Remaining Estimate: (was: 2 days) Original Estimate: (was: 172800) Allow defenition of short list for goals shown -- Key: MPJBUILDER-15 URL: http://jira.codehaus.org/browse/MPJBUILDER-15 Project: maven-jbuilder-plugin Type: New Feature Environment: Windows XP. Jbuilder Enterprise X. Maven 1.0 Reporter: Marteijn Nouwens Assignee: Emmanuel Venisse Priority: Minor It would be nice to allow the user to define a list of most often used goals so that it is easier to navigate. project.xml - goal 1 - goal 2 - goal 3 - goal x - other goals - current view of goals I think this should be an improvement since most developers only use 3 to 5 goals from their ide. -- 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: (MPJCOVERAGE-28) Instrumentation fails on windows due to command line arg length.
[ http://jira.codehaus.org/browse/MPJCOVERAGE-28?page=all ] Brett Porter updated MPJCOVERAGE-28: Description: When starting with a clean project jcoverage fails when compiling the test classes to it's maven.jcoverage.dir with tons of cannot resolve symbol errors. The underlying error has already happend before. Instrumentation failed: [instrument] [ERROR] java.io.IOException: CreateProcess: C:\j2sdk1.4.1\jre\bin\java.exe -classpath C:\Dokumente und Einstellungen\westermann\.maven\repository\jcoverage\jars\jcoverage-1.0.5.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\bcel\jars\bcel-5.1.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\urbanophile\jars\java-getopt-1.0.9.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\log4j\jars\log4j-1.2.8.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\oro\jars\oro-2.0.7.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\junit\jars\junit-3.8.1.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\xerces\jars\xercesImpl-2.6.2.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\xerces\jars\xmlParserAPIs-2.2.1.jar com.jcoverage.coverage.Instrument -d C:\build\jcoverage\classes -basedir C:\build\classes org\opencms\workplace\CmsWorkplace.class org\opencms\main\CmsRuntimeException.class org\opencms\file\TestSiblings$1.class com\opencms\workplace\CmsRepla? This leads to the fact that the classes required by the test sources which should be the instrumented ones are not in maven.jcoverage.dir thus missing from jcoverage classpath. Occurrance: Only on Windows, not on RH Linux 7.3. Assumption: On Windows the maximum command line length is exceeded. I have experienced similar behaviour in build-systems with makefile before. Look at the trainling '?' - The argument seems to have been truncated. The error hits back to the current process at the process creation for the instrumentation task. Suggestion: A) Perhaps use files for the arguments and a new -file argument to the com.jcoverage.coverage.Instrument class. Or lay open the underlying fork argument of the ANT javac task: Without forking this would not happen. The fallback could be possible memory problems. B) Fail the goal immediately when instrumentation fails. Errors that result are hard to find. Thanks for jcoverage, Achim was: When starting with a clean project jcoverage fails when compiling the test classes to it's maven.jcoverage.dir with tons of cannot resolve symbol errors. The underlying error has already happend before. Instrumentation failed: [instrument] [ERROR] java.io.IOException: CreateProcess: C:\j2sdk1.4.1\jre\bin\java.exe -classpath C:\Dokumente und Einstellungen\westermann\.maven\repository\jcoverage\jars\jcoverage-1.0.5.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\bcel\jars\bcel-5.1.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\urbanophile\jars\java-getopt-1.0.9.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\log4j\jars\log4j-1.2.8.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\oro\jars\oro-2.0.7.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\junit\jars\junit-3.8.1.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\xerces\jars\xercesImpl-2.6.2.jar;C:\Dokumente und Einstellungen\westermann\.maven\repository\xerces\jars\xmlParserAPIs-2.2.1.jar com.jcoverage.coverage.Instrument -d C:\build\jcoverage\classes -basedir C:\build\classes org\opencms\workplace\CmsWorkplace.class org\opencms\main\CmsRuntimeException.class org\opencms\file\TestSiblings$1.class com\opencms\workplace\CmsRepla? This leads to the fact that the classes required by the test sources which should be the instrumented ones are not in maven.jcoverage.dir thus missing from jcoverage classpath. Occurrance: Only on Windows, not on RH Linux 7.3. Assumption: On Windows the maximum command line length is exceeded. I have experienced similar behaviour in build-systems with makefile before. Look at the trainling '?' - The argument seems to have been truncated. The error hits back to the current process at the process creation for the instrumentation task. Suggestion: A) Perhaps use files for the arguments and a new -file argument to the com.jcoverage.coverage.Instrument class. Or lay open the underlying fork argument of the ANT javac task: Without forking this would not happen. The fallback could be possible memory problems. B) Fail the goal immediately when instrumentation fails. Errors that result are hard to find. Thanks for jcoverage, Achim Remaining Estimate: (was: 4 hours) Original Estimate: (was: 14400) Instrumentation fails on windows due to command line arg length. Key:
[jira] Updated: (MNG-758) final clarifications of Mojo API
[ http://jira.codehaus.org/browse/MNG-758?page=all ] Brett Porter updated MNG-758: - Assign To: Brett Porter Remaining Estimate: 3 hours Original Estimate: 10800 final clarifications of Mojo API Key: MNG-758 URL: http://jira.codehaus.org/browse/MNG-758 Project: Maven 2 Type: Improvement Components: maven-plugin-api Reporter: Brett Porter Assignee: Brett Porter Priority: Blocker Fix For: 2.0-beta-1 Original Estimate: 3 hours Remaining: 3 hours I'm finding the expression vs default-value a bit confusing - I think we have discussed this before. expression is often being used as the default value - sometimes by necessity because default-value doesn't accept expressions. Suggestions: - default-value should accept expressions - add a @component role=... roleHint=... to replace the component expression - expression should be the value (And if null, use the default-value). THis usually represents the project field to look up, or the system property to use -- 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-624) automatic parent versioning
[ http://jira.codehaus.org/browse/MNG-624?page=all ] Brett Porter updated MNG-624: - Assign To: Brett Porter Remaining Estimate: 4 hours Original Estimate: 14400 automatic parent versioning --- Key: MNG-624 URL: http://jira.codehaus.org/browse/MNG-624 Project: Maven 2 Type: Improvement Reporter: Brett Porter Assignee: Brett Porter Priority: Blocker Fix For: 2.0-beta-1 Original Estimate: 4 hours Remaining: 4 hours (this may be bumped to 2.1 or even made WON't FIX as it is contentious - see MNG-521) currently, you have to specify the parent version when extending which makes a project stand alone very easily, but has the drawback of being a maintainance problem when you start development on a new version. Tools can help, but it would be nice not to have to rely on them. One alternative is to allow the parent version to be omitted, and when it is it is assumed you want the latest. The parent is used from the reactor or the universal source directory. IT may also be read from a LATEST in the repository though this is contentious - it may be better to simply fail in that environment and require builds be in a known checkout structure for building individual projects. This also introduces the need for tool support to populate the version on release and deployment for reproducibility. -- 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-586) Do not include the third party Jsch libraries
[ http://jira.codehaus.org/browse/MNG-586?page=all ] Brett Porter updated MNG-586: - Remaining Estimate: 2 hours Original Estimate: 7200 Do not include the third party Jsch libraries -- Key: MNG-586 URL: http://jira.codehaus.org/browse/MNG-586 Project: Maven 2 Type: Wish Components: maven-artifact-ant Reporter: Jason van Zyl Assignee: Brett Porter Priority: Critical Fix For: 2.0-beta-1 Original Estimate: 2 hours Remaining: 2 hours Hello, Can I request that the Ant tasks for Maven do not include the third party Jsch libraries in their own jar It may seem a good solution to your dependencies -bundle them in your own JAR, but the consequences are -unless you release the libs in perfect syncrhonisation with the jsch releases, your version will be behind -if someone has a different version of the jsch stuff on the classpath, they may not get what they want -the ant team ends up fielding the bug reports We have problems with existing libraries including stuff like oro and antlr, and have documented it http://ant.apache.org/manual/install.html#librarydependencies Please dont add to the list. I understand the value in secure downloads, but feel this is the wrong tactic. If having the library is a prerequisite, please point to the library at download time. Otherwise, well, surely dynamic downloading of stuff is what the library is meant to be good at? -- 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-634) Scope needs to be taken into account when providing dependencies by ant tasks
[ http://jira.codehaus.org/browse/MNG-634?page=all ] Brett Porter updated MNG-634: - Remaining Estimate: 2 hours Original Estimate: 7200 Scope needs to be taken into account when providing dependencies by ant tasks - Key: MNG-634 URL: http://jira.codehaus.org/browse/MNG-634 Project: Maven 2 Type: Improvement Components: maven-artifact-ant Versions: 2.0-alpha-3 Environment: any Reporter: Matthias Unverzagt Assignee: Brett Porter Priority: Critical Fix For: 2.0-beta-1 Original Estimate: 2 hours Remaining: 2 hours Best practise would be to have all depency info inside pom.xml files, none within build.xml files. One of this info is the 'scope' information. Suppose you declare a dependency that is needed for compiling but not in your runtime environment because it is provided by e.g. the container then you - would like to have the dependency on your compile classpath (e.g. to be independend of the container) - would like to have a fileset representing the runtime requirement - omitting the provided dependency Therefore there needs to be some kind of scope filter insided the dependencies task. Example: artifact:dependencies pathId=dependency.compile.classpath scope=compile pom refid=maven.project/ localRepository refid=repo.localrepo/ /artifact:dependencies artifact:dependencies filesetId=dependency.runtime.fileset scope=runtime pom refid=maven.project/ localRepository refid=repo.localrepo/ /artifact:dependencies CONCERNING PRIORITY: Without such a scope attribute you need to duplicate the scope information that is in the pom.xml in some sense inside the build.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]
[jira] Updated: (MNG-763) consider include source root
[ http://jira.codehaus.org/browse/MNG-763?page=all ] Brett Porter updated MNG-763: - Assign To: Brett Porter Remaining Estimate: 1 hour Original Estimate: 3600 consider include source root Key: MNG-763 URL: http://jira.codehaus.org/browse/MNG-763 Project: Maven 2 Type: New Feature Reporter: Brett Porter Assignee: Brett Porter Priority: Critical Fix For: 2.0-beta-1 Original Estimate: 1 hour Remaining: 1 hour this is something used by the native plugin but could be used by several plugins that deal with C/C++ and maybe other languages. We should consider adding it to the build section and the MavenProject object. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MNG-605) allow updates of repository metadata (currently plugins.xml)
[ http://jira.codehaus.org/browse/MNG-605?page=all ] Brett Porter updated MNG-605: - Assign To: Brett Porter Remaining Estimate: 3 hours Original Estimate: 10800 allow updates of repository metadata (currently plugins.xml) Key: MNG-605 URL: http://jira.codehaus.org/browse/MNG-605 Project: Maven 2 Type: Bug Reporter: Brett Porter Assignee: Brett Porter Priority: Blocker Fix For: 2.0-beta-1 Original Estimate: 3 hours Remaining: 3 hours currently, local changes get blown away by remote updates. We need to be able to merge the changes. This can be done by timestamping the last update of an entry. Any newer ones get updated from the remote source. Removal of elements will require replacing with an empty element instead of just removing it, otherwise the merge process will not be able to determine if it was removed locally, or new remotely. -- 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-613) improve release selection for ranges
[ http://jira.codehaus.org/browse/MNG-613?page=all ] Brett Porter updated MNG-613: - Assign To: Brett Porter Remaining Estimate: 6 hours Original Estimate: 21600 improve release selection for ranges Key: MNG-613 URL: http://jira.codehaus.org/browse/MNG-613 Project: Maven 2 Type: Improvement Components: maven-artifact Reporter: Brett Porter Assignee: Brett Porter Priority: Critical Fix For: 2.0-beta-1 Original Estimate: 6 hours Remaining: 6 hours currently, ranges such as (,1.0) do not work, as it is incapable of locating the newest version 1.0. Also, ranges such as [1.0,) result in RELEASE, which may not be present for all artifacts. We should replace or augment RELEASE with a full listing of versions for an artifact in the repository. This would be repository metadata of the same fashion as the plugin prefix - id mapping. -- 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-612) implement conflict resolution techniques
[ http://jira.codehaus.org/browse/MNG-612?page=all ] Brett Porter updated MNG-612: - Assign To: Brett Porter Remaining Estimate: 1 day Original Estimate: 86400 implement conflict resolution techniques Key: MNG-612 URL: http://jira.codehaus.org/browse/MNG-612 Project: Maven 2 Type: New Feature Components: maven-artifact Reporter: Brett Porter Assignee: Brett Porter Priority: Critical Fix For: 2.0-beta-1 Original Estimate: 1 day Remaining: 1 day currently, the collector only: - selects nearest suggested version in a valid range - latest version from the valid ranges if none suggested - fails if ranges are over-constrained This needs to be configurable: - select newest, even if there is a nearer suggestion - select oldest, even if there is a nearer suggestion - fail if all suggestions don't equate or a range results instead of a single version - ignore over constrained ranges and fallback to some other algorithm - select snapshots even if they weren't explicitly specified -- 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-139) server definitions should be reusable
[ http://jira.codehaus.org/browse/MNG-139?page=all ] Brett Porter updated MNG-139: - Assign To: Brett Porter Remaining Estimate: 4 hours Original Estimate: 14400 server definitions should be reusable - Key: MNG-139 URL: http://jira.codehaus.org/browse/MNG-139 Project: Maven 2 Type: Task Components: design Reporter: Brett Porter Assignee: Brett Porter Priority: Critical Fix For: 2.0-beta-1 Original Estimate: 4 hours Remaining: 4 hours currently if multiple projects use the same server for deployment, we are relying on inheritence to share the definition, or it must be copied. This applies similarly to the SCM connection and the dist/site management settings. It would be a good idea to be able to declare these elements in a deployed artifact. It may still be reasonable to do this through inheritence, but there is a chance we'll hit the need for multiple inheritence (because multiple projects inherit things from different sources), so we should enumerate the use cases and verify it. eg. A B / \ / \ C D E Where A and B declare two different things that D uses both of, but which C and E desire only to inherit one of. This essentially using composition for some elements instead of inheritence. -- 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-629) report executor doesn't perform lifecycle
[ http://jira.codehaus.org/browse/MNG-629?page=all ] Brett Porter updated MNG-629: - Assign To: Brett Porter Remaining Estimate: 6 hours Original Estimate: 21600 report executor doesn't perform lifecycle - Key: MNG-629 URL: http://jira.codehaus.org/browse/MNG-629 Project: Maven 2 Type: Bug Reporter: Brett Porter Assignee: Brett Porter Priority: Critical Fix For: 2.0-beta-1 Original Estimate: 6 hours Remaining: 6 hours eg, for clover - it has @execute phase=test, but the report is run directly ignoring this. This means that the clover database is not created. -- 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-18) Add offline mode
[ http://jira.codehaus.org/browse/MNG-18?page=all ] Brett Porter updated MNG-18: Description: Remaining Estimate: 2 days Environment: Add offline mode Key: MNG-18 URL: http://jira.codehaus.org/browse/MNG-18 Project: Maven 2 Type: Improvement Reporter: Trygve Laugstol Assignee: John Casey Fix For: 2.0-beta-1 Time Spent: 4 hours Remaining: 2 days -- 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-767) NPE in offline mode
NPE in offline mode --- Key: MNG-767 URL: http://jira.codehaus.org/browse/MNG-767 Project: Maven 2 Type: Bug Reporter: Brett Porter Fix For: 2.0-beta-2 remove the ~/.m2/repository/org/apache/maven/plugins dir and try to build maven-plugins using m2 install -o. It NPE's in ArtifactVersionTransformation comparing 2 versions (artifact and 'extracted' pom) which probably both are null. -- 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-18) Add offline mode
[ http://jira.codehaus.org/browse/MNG-18?page=all ] Brett Porter closed MNG-18: --- Resolution: Fixed Fix Version: (was: 2.0-beta-1) 2.0-alpha-1 Add offline mode Key: MNG-18 URL: http://jira.codehaus.org/browse/MNG-18 Project: Maven 2 Type: Improvement Reporter: Trygve Laugstol Assignee: John Casey Fix For: 2.0-alpha-1 Time Spent: 4 hours Remaining: 2 days -- 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-768) finish offline mode
finish offline mode --- Key: MNG-768 URL: http://jira.codehaus.org/browse/MNG-768 Project: Maven 2 Type: New Feature Reporter: Brett Porter Fix For: 2.0-beta-2 discussion in maven-components/maven-core/src/site/apt/offline-mode.apt. Need to find a good way to propagate the offline flag into the artifact resolver, or else provide a more centralized way of managing artifact resolution. -- 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-760) m2 eclipse plugin improvements (source download and attachment, customization of natures/builders/conclasspath, flexible project dupport) and refactoring
[ http://jira.codehaus.org/browse/MNG-760?page=all ] Brett Porter updated MNG-760: - Remaining Estimate: (was: 1 hour) Original Estimate: (was: 3600) m2 eclipse plugin improvements (source download and attachment, customization of natures/builders/conclasspath, flexible project dupport) and refactoring - Key: MNG-760 URL: http://jira.codehaus.org/browse/MNG-760 Project: Maven 2 Type: Improvement Components: maven-plugins Versions: 2.0-beta-1 Reporter: fabrizio giustina Fix For: 2.0-beta-1 Attachments: MNG-760.diff This patch adds the following to the M2 eclipse plugin: - downloading of source attachments and configuration in .classpath - customization of project builders and natures in .project (like in the m1 plugin) - additional conclasspath entries in .classpath (like in the m1 plugin) - fix: don't add duplicate directories if main/resources directories overlap (like in the m1 plugin) - support for flexible projects (.wtpmodules file generation for utility modules, wars, ejbs) Along with these new features the plugin has been refactored, splitting the single big EclipseWriter class to several specific classes and all the messages have been externalized in a property file. There are still some todos in the code, which probably some M2 guru could look at, but anyway all the existing functionalities continue to work and some other tests have been added. Due to the refactoring the patch looks more like a complete rewrite: sorry for that, but adding new features without splitting the existing file was ugly -- 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-765) make it possible to use ${basedir}/xdocs for xdoc source in site plugin
[ http://jira.codehaus.org/browse/MNG-765?page=comments#action_44878 ]
Emmanuel Venisse commented on MNG-765:
--
why do you want this?
I suppose it's for m1 project migration. user need to rewrite his poms, he can
move his xdocs directory too. And he need to write a site.xml file.
make it possible to use ${basedir}/xdocs for xdoc source in site plugin
---
Key: MNG-765
URL: http://jira.codehaus.org/browse/MNG-765
Project: Maven 2
Type: Improvement
Reporter: Brett Porter
Fix For: 2.0-beta-2
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-769) m2 eclipse:eclipse - duplicate ressources
m2 eclipse:eclipse - duplicate ressources - Key: MNG-769 URL: http://jira.codehaus.org/browse/MNG-769 Project: Maven 2 Type: Bug Versions: 2.0-alpha-3 Reporter: Gilles Scokart Priority: Minor When we have a pom.xml that contains 2 ressources with the same directory (but with different includes), the eclipse plugin generate a .classpath that contains two time the same classpath entry. Such a project can not be opened in eclipse. It' normal to not have exactely the same behavior (eclipse doesn't suport patterns for inclusion/exclusion), but it would be better to have only one classpath entries genereted if two ressources are linked to the same directory. The semantic stay the same as the current one, but there is no errors anymore in the .classpath. -- 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-770) m2 eclipse:eclipse should look at the JDK versions
m2 eclipse:eclipse should look at the JDK versions -- Key: MNG-770 URL: http://jira.codehaus.org/browse/MNG-770 Project: Maven 2 Type: Improvement Versions: 2.0-alpha-3 Reporter: Gilles Scokart Priority: Minor Currently, the option : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration /plugin are not read by the eclipse plugin. The generated project use the default workspace source and target. Since eclipse 3.x, there is a .settings directory in which we can place such options. I don't know if one plug-in can read options of an other one, but if it can, it would be nice the the eclipse plugin use this information when generating the project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MAVEN-1669) ejb-client Dependency is not working
ejb-client Dependency is not working -- Key: MAVEN-1669 URL: http://jira.codehaus.org/browse/MAVEN-1669 Project: Maven Type: Bug Components: core Versions: 1.1-beta-1 Reporter: Vincent Massol Fix For: 1.1-beta-2 The following does not work with Mavn 1.1 from trunk (as of 22 August 2005 - 11:57 GMT+1): dependency groupId.../groupId artifactId.../artifactId version.../version typeejb-client/type /dependency Maven cannot find the dependency. -- 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: (MPEJB-19) EJBArtifactTypeHandler should append -client to artifactId, not version string?
[ http://jira.codehaus.org/browse/MPEJB-19?page=comments#action_44890 ] Vincent Massol commented on MPEJB-19: - Just to be clear: This is a bug in Maven 1.1. It won't work even if you build 1.1 from trunk. See MAVEN-1669. EJBArtifactTypeHandler should append -client to artifactId, not version string? - Key: MPEJB-19 URL: http://jira.codehaus.org/browse/MPEJB-19 Project: maven-ejb-plugin Type: Bug Versions: 1.7 Environment: Maven 1.0.2, maven-ejb-plugin 1.7-SNAPSHOT Reporter: Fredrik Vraalsen Assignee: Brett Porter Attachments: ejb-client-name-testcase.patch, ejb-client-name.patch I just checked out the latest version of the maven-ejb-plugin which installs ejb-client jars with a different name. Thanks for the good work! However, I'm wondering why the ejb-client jar appends -client to the version string rather than the artifactId, which seems more appropriate to me at least? The attached patch changes this. Cheers, Fredrik -- 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-769) m2 eclipse:eclipse - duplicate ressources
[ http://jira.codehaus.org/browse/MNG-769?page=comments#action_44892 ] Joerg Schaible commented on MNG-769: Just as a side note: Eclipse can inculde/exclude! An extract from one of my used .classpath files: classpathentry excluding=ejb/XLocal.java|ejb/XRemote.java|ejb/X.java|ejb/XHome.java|ejb/XHomeLocal.java|ejb/XLocal.java kind=src path=src/java/ I am just not sure, when Eclipse started to support it. m2 eclipse:eclipse - duplicate ressources - Key: MNG-769 URL: http://jira.codehaus.org/browse/MNG-769 Project: Maven 2 Type: Bug Versions: 2.0-alpha-3 Reporter: Gilles Scokart Priority: Minor When we have a pom.xml that contains 2 ressources with the same directory (but with different includes), the eclipse plugin generate a .classpath that contains two time the same classpath entry. Such a project can not be opened in eclipse. It' normal to not have exactely the same behavior (eclipse doesn't suport patterns for inclusion/exclusion), but it would be better to have only one classpath entries genereted if two ressources are linked to the same directory. The semantic stay the same as the current one, but there is no errors anymore in the .classpath. -- 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]
svn commit: r234462 - /maven/components/trunk/maven-plugins/maven-ear-plugin/src/main/java/org/apache/maven/plugin/ear/EarMojo.java
Author: snicoll
Date: Mon Aug 22 03:08:55 2005
New Revision: 234462
URL: http://svn.apache.org/viewcvs?rev=234462view=rev
Log:
Now allowing custom manifest file to be set in the generated EAR file.
Modified:
maven/components/trunk/maven-plugins/maven-ear-plugin/src/main/java/org/apache/maven/plugin/ear/EarMojo.java
Modified:
maven/components/trunk/maven-plugins/maven-ear-plugin/src/main/java/org/apache/maven/plugin/ear/EarMojo.java
URL:
http://svn.apache.org/viewcvs/maven/components/trunk/maven-plugins/maven-ear-plugin/src/main/java/org/apache/maven/plugin/ear/EarMojo.java?rev=234462r1=234461r2=234462view=diff
==
---
maven/components/trunk/maven-plugins/maven-ear-plugin/src/main/java/org/apache/maven/plugin/ear/EarMojo.java
(original)
+++
maven/components/trunk/maven-plugins/maven-ear-plugin/src/main/java/org/apache/maven/plugin/ear/EarMojo.java
Mon Aug 22 03:08:55 2005
@@ -50,7 +50,6 @@
* The location of the manifest file to be used within the ear file.
*
* @parameter
expression=${basedir}/src/main/application/META-INF/MANIFEST.MF
- * @TODO handle this field
*/
private String manifestLocation;
@@ -113,7 +112,7 @@
if ( !sourceFile.isFile() )
{
-throw new MojoExecutionException( Cannot copy a
directory: + sourceFile.getAbsolutePath() +
+throw new MojoExecutionException( Cannot copy a
directory: + sourceFile.getAbsolutePath() +
; Did you package/install +
module.getArtifact().getId() + ? );
}
@@ -154,6 +153,9 @@
MavenArchiver archiver = new MavenArchiver();
archiver.setOutputFile( earFile );
+// Include custom manifest if necessary
+includeCustomManifestFile();
+
archiver.getArchiver().addDirectory( getBuildDir() );
archiver.createArchive( getProject(), archive );
@@ -168,5 +170,19 @@
private static File buildDestinationFile( File buildDir, String uri )
{
return new File( buildDir, uri );
+}
+
+private void includeCustomManifestFile()
+{
+File customManifestFile = new File( manifestLocation );
+if ( !customManifestFile.exists() )
+{
+// Does not exist so will use default
+}
+else
+{
+getLog().info( Including custom manifest file[ +
customManifestFile + ] );
+archive.setManifestFile( customManifestFile );
+}
}
}
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to contribute to the Maven project
One remark though. I think the Jira's filters should be updated to take only Unassigned issues. If the issue is currently assigned, we could assume someone is taking care of it, right? WDYT? Cheers, Stéphane On 8/17/05, Stephane Nicoll [EMAIL PROTECTED] wrote: I've seen the page yesterday and I must say it's an excellent idea! Cheers, Stéphane On 8/16/05, Trygve Laugstøl [EMAIL PROTECTED] wrote: Hi! I've added a field to our JIRA instance called Complexity. This field is an indicator on how hard the issue will be, for the actual definition, please read[1]. There's a wiki page at our Codehaus Confluence that reads from JIRA and shows an updated list[2]. The intention is to make it easier for new folks that would like to help out on Maven development. Please try to set the field if you feel that it something a non-committer should be able to solve. [1]: http://maven.apache.org/maven2/developers/development-guide.html [2]: http://docs.codehaus.org/display/MAVEN/How+to+help -- Trygve on behalf of the Maven team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDAkr24EbM92cyCUURAmv3AKCQw4ajgtQJqfgTzzX8EdzXxedNKgCcDqhe lB37227GbEmOlmc86o3aF34= =wbvN -END PGP SIGNATURE- -- .::You're welcome ::. -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (MNG-771) dependencies not set inside ibiblio repository.
dependencies not set inside ibiblio repository. --- Key: MNG-771 URL: http://jira.codehaus.org/browse/MNG-771 Project: Maven 2 Type: Bug Versions: 2.0-alpha-3 Reporter: Gilles Scokart Priority: Minor I'm not sure where to put it, I already tried : http://jira.codehaus.org/browse/JMOCK-78 (without success) The file jmock-cglib-1.0.1.pom stored on ibiblio, used by maven don't contains a dependency with cglib, but it should. Because of that, the users of maven2 are still forced to place the dependency themself, with the risk of taking a wrong version. I also found that velocity doesn't have a dependency to velocity-dep. -- 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: How to contribute to the Maven project
On Mon, Aug 22, 2005 at 12:15:59PM +0200, Stephane Nicoll wrote: One remark though. I think the Jira's filters should be updated to take only Unassigned issues. If the issue is currently assigned, we could assume someone is taking care of it, right? WDYT? Hm, that's a good point. Unless someone objects to this I'll do it later today. -- Trygve Cheers, Stéphane On 8/17/05, Stephane Nicoll [EMAIL PROTECTED] wrote: I've seen the page yesterday and I must say it's an excellent idea! Cheers, Stéphane On 8/16/05, Trygve Laugstøl [EMAIL PROTECTED] wrote: Hi! I've added a field to our JIRA instance called Complexity. This field is an indicator on how hard the issue will be, for the actual definition, please read[1]. There's a wiki page at our Codehaus Confluence that reads from JIRA and shows an updated list[2]. The intention is to make it easier for new folks that would like to help out on Maven development. Please try to set the field if you feel that it something a non-committer should be able to solve. [1]: http://maven.apache.org/maven2/developers/development-guide.html [2]: http://docs.codehaus.org/display/MAVEN/How+to+help -- Trygve on behalf of the Maven team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDAkr24EbM92cyCUURAmv3AKCQw4ajgtQJqfgTzzX8EdzXxedNKgCcDqhe lB37227GbEmOlmc86o3aF34= =wbvN -END PGP SIGNATURE- -- .::You're welcome ::. -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] signature.asc Description: Digital signature
[maven2 build - SUCCESS - update] Mon Aug 22 10:15:00 GMT 2005
Distribution: http://maven.zones.apache.org/~maven/builds/m2-20050822.101500.tar.gz Log: http://maven.zones.apache.org/~maven/logs/m2-build-log-20050822.101500.txt - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Moved: (MEV-65) dependencies not set inside ibiblio repository.
[ http://jira.codehaus.org/browse/MEV-65?page=all ] Trygve Laugstol moved MNG-771 to MEV-65: Priority: (was: Minor) Group ID: jmock Version: (was: 2.0-alpha-3) Artifact ID: jmock-cglib Version: 1.0.1 Complexity: (was: Intermediate) Workflow: jira (was: Maven) Key: MEV-65 (was: MNG-771) Project: Maven Evangelism (was: Maven 2) dependencies not set inside ibiblio repository. --- Key: MEV-65 URL: http://jira.codehaus.org/browse/MEV-65 Project: Maven Evangelism Type: Bug Reporter: Gilles Scokart I'm not sure where to put it, I already tried : http://jira.codehaus.org/browse/JMOCK-78 (without success) The file jmock-cglib-1.0.1.pom stored on ibiblio, used by maven don't contains a dependency with cglib, but it should. Because of that, the users of maven2 are still forced to place the dependency themself, with the risk of taking a wrong version. I also found that velocity doesn't have a dependency to velocity-dep. -- 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: How to contribute to the Maven project
Be careful with this rule A lot of plugins (in m1) are auto-assigned to the plugin's manager. I must deactivate this rules for my plugins but I always forgot to do it Actually I have more than one hundred of issues assigned to me. I know that Jason had also a lot of issues. Arnaud On 8/22/05, Trygve Laugstøl [EMAIL PROTECTED] wrote: On Mon, Aug 22, 2005 at 12:15:59PM +0200, Stephane Nicoll wrote: One remark though. I think the Jira's filters should be updated to take only Unassigned issues. If the issue is currently assigned, we could assume someone is taking care of it, right? WDYT? Hm, that's a good point. Unless someone objects to this I'll do it later today. -- Trygve Cheers, Stéphane On 8/17/05, Stephane Nicoll [EMAIL PROTECTED] wrote: I've seen the page yesterday and I must say it's an excellent idea! Cheers, Stéphane On 8/16/05, Trygve Laugstøl [EMAIL PROTECTED] wrote: Hi! I've added a field to our JIRA instance called Complexity. This field is an indicator on how hard the issue will be, for the actual definition, please read[1]. There's a wiki page at our Codehaus Confluence that reads from JIRA and shows an updated list[2]. The intention is to make it easier for new folks that would like to help out on Maven development. Please try to set the field if you feel that it something a non-committer should be able to solve. [1]: http://maven.apache.org/maven2/developers/development-guide.html [2]: http://docs.codehaus.org/display/MAVEN/How+to+help -- Trygve on behalf of the Maven team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDAkr24EbM92cyCUURAmv3AKCQw4ajgtQJqfgTzzX8EdzXxedNKgCcDqhe lB37227GbEmOlmc86o3aF34= =wbvN -END PGP SIGNATURE- -- .::You're welcome ::. -- .::You're welcome ::. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDCaa54EbM92cyCUURAgMuAJwMmzSr5w+W5y+YBs4HPcMXW/U3cgCfcw9t 8MuddEw60NmQnxw+oO2AvOw= =p/R3 -END PGP SIGNATURE-
[jira] Commented: (MNG-769) m2 eclipse:eclipse - duplicate ressources
[ http://jira.codehaus.org/browse/MNG-769?page=comments#action_44899 ] fabrizio giustina commented on MNG-769: --- I think this is solved by MNG-760. Fabrizio: can you verify this? yes, it should be solved by the patch, duplicated directories are not added anymore m2 eclipse:eclipse - duplicate ressources - Key: MNG-769 URL: http://jira.codehaus.org/browse/MNG-769 Project: Maven 2 Type: Bug Versions: 2.0-alpha-3 Reporter: Gilles Scokart Priority: Minor When we have a pom.xml that contains 2 ressources with the same directory (but with different includes), the eclipse plugin generate a .classpath that contains two time the same classpath entry. Such a project can not be opened in eclipse. It' normal to not have exactely the same behavior (eclipse doesn't suport patterns for inclusion/exclusion), but it would be better to have only one classpath entries genereted if two ressources are linked to the same directory. The semantic stay the same as the current one, but there is no errors anymore in the .classpath. -- 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-770) m2 eclipse:eclipse should look at the JDK versions
[ http://jira.codehaus.org/browse/MNG-770?page=comments#action_44900 ] fabrizio giustina commented on MNG-770: --- This feature has already been added to the version in svn (already committed, it's not related to my patch for MNG-760). The issue can be closed. m2 eclipse:eclipse should look at the JDK versions -- Key: MNG-770 URL: http://jira.codehaus.org/browse/MNG-770 Project: Maven 2 Type: Improvement Versions: 2.0-alpha-3 Reporter: Gilles Scokart Priority: Minor Currently, the option : plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-compiler-plugin/artifactId configuration source1.5/source target1.5/target /configuration /plugin are not read by the eclipse plugin. The generated project use the default workspace source and target. Since eclipse 3.x, there is a .settings directory in which we can place such options. I don't know if one plug-in can read options of an other one, but if it can, it would be nice the the eclipse plugin use this information when generating the project. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: How to contribute to the Maven project
On Mon, Aug 22, 2005 at 12:37:37PM +0200, Arnaud HERITIER wrote: Be careful with this rule A lot of plugins (in m1) are auto-assigned to the plugin's manager. I must deactivate this rules for my plugins but I always forgot to do it Actually I have more than one hundred of issues assigned to me. I know that Jason had also a lot of issues. The lists are currently only for Maven 2 issues but there is no reason why they shouldn't cover Maven 1 issues in the future. IMO there shouldn't be a default assignee, WDYT? -- Trygve signature.asc Description: Digital signature
Re: marmalade
I believe M2 has Groovy integration on its TODO list. Groovy, which is well documented, is gaining a lot of momentum and integrates with Ant. http://groovy.codehaus.org/ Cheers, Thomas On 8/21/05, John Casey [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Ralph, I'm sorry I haven't responded to this thread earlier, but I'm the guy to talk to wrt marmalade. Unfortunately, since we've been trying like hell to get maven 2.0 out the door for the last several months, I have let marmalade slip a bit. However, I should mention that despite it's lack of documentation, this is a stable and (I believe) completely usable set of libraries. I'm not likely to have time to document the project for awhile to come (since I'm sure you've noticed, maven 2.0 isn't out yet...and that's my first priority), but if you have specific questions I'd be happy to answer them. I'll start by replying inline to your comments below: Ralph Goers wrote: snip/ | | As for Marmalade, I am looking for an XML tag framework that I can limit | to either a fixed set of tags that I implement, or an XML language that | is easy to understand and can only perform operations on the objects it | is provided with. As far as limiting the taglibs that are available, Marmalade uses a stacked resolution strategy to discover tag libraries. This means it's pretty simple to add your own strategy class as either the first-line strategy, or as the only one...your strategy class might only allow taglibs on an approved list to be discovered, and throw an exception otherwise... As for only working with the objects it's given, Marmalade operates on a Context which is essentially a scope-enabled hierarchy of maps, meaning that the entire context is visible from any one point, but child contexts can be added or removed to add/remove the variables associated with those lower scopes. Anything in this context is available for reading or manipulation, using a variety of expression languages (or direct access from the tag implementation itself). Also, I noticed that you previously mentioned running Marmalade from the command-line(?) or at least executing it outside of maven. I've created the MarmaladeLauncher class to aid in this task, although I haven't had time to write a CLI wrapper library for direct execution from the command-line. Such a CLI would have to have a pretty sophisticated parser IMO, in order to support stacking of discovery strategies, etc. However, for specialized - and somewhat limited - purposes, writing a simple Main class to launch marmalade by wrapping the MarmaladeLauncher should be pretty trivial. The only real hurdle is understanding the concepts of Marmalade, which I'll admit are poorly articulated the what passes for current documentation. I'd suggest that you look at the plexus-marmalade-factory or the MarmaladeLauncher unit tests for a crash course in how that works. I have a couple of uses for these: | 1. I'd like to use it to create symantic modules in drools For this, you'd just need something that would initialize the marmalade context and launch the script...right? Sounds pretty simple. | 2. I'd like to create an event based flow controller for Cocoon | (something like a more limited version of Javaflow - if that means | anything to you). I'm not familiar with Javaflow, and this topic is a bit outside my day-to-day wanderings. However, it seems to me that the event framework is bound to be outside of Marmalade proper, with event actions being Marmalade scripts or scriptlets...right? Again, it's just a matter of initializing the context and launching the script via MarmaladeLauncher...shouldn't be too difficult. Again, I want to reiterate that I'm available for specific questions. That's the best I can offer until I have time to write up more doco on Marmalade concepts and usage. Good luck! - -john | | BTW - I'm very familiar with the memory leak in jelly. I had to pretty | much gut the multiproject plugin so it could build our website. It would | die before it got half way through. | | And thanks for your time and the help. | | Ralph | snip/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFDCKBvK3h2CZwO/4URAlRjAJ9TgWQIqapToWwiZg6TlOqOOM21LACfSoOl u6VfTwsXEWeTdZo7l8LZRRQ= =4YSF -END PGP SIGNATURE- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPXDOC-113) Logo relative path not correct
[ http://jira.codehaus.org/browse/MPXDOC-113?page=all ] Arnaud Heritier updated MPXDOC-113: --- Assign To: (was: Arnaud Heritier) Logo relative path not correct -- Key: MPXDOC-113 URL: http://jira.codehaus.org/browse/MPXDOC-113 Project: maven-xdoc-plugin Type: Bug Versions: 1.7.1 Reporter: Matt Read The documentation states that both logo elements can contain relative or absolute paths. I'm using the following: organization nameConcise/name urlhttp://lee//url logo/images/logos/concise.gif/logo /organization !-- url to the projects logo -- logo/images/logos/corppay.gif/logo Which gets rendered in the HTML as: img alt=Concise src=./images/logos/concise.gif/img and img alt=PPR3 src=./images/logos/corppay.gif/img respectively. Obviously this is fine on the home page but incorrect on all pages in directories below the root. -- 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: (MPJAVADOC-60) Allow declaration of jar javadoc location in pom
[ http://jira.codehaus.org/browse/MPJAVADOC-60?page=all ] Arnaud Heritier updated MPJAVADOC-60: - Assign To: (was: Arnaud Heritier) Allow declaration of jar javadoc location in pom Key: MPJAVADOC-60 URL: http://jira.codehaus.org/browse/MPJAVADOC-60 Project: maven-javadoc-plugin Type: New Feature Reporter: thierry lach Priority: Minor Search the pom artifacts properties for javadoc.link and add that to the maven.javadoc.links. Example: dependency groupIdcommons-lang/groupId artifactIdcommons-lang/artifactId version2.0/version typejar/type properties javadoc.linkhttp://jakarta.apache.org/commons/lang/apidocs/javadoc.link /properties /dependency -- 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: (MPXDOC-134) rewrite - scm support for xdoc plugin
[ http://jira.codehaus.org/browse/MPXDOC-134?page=all ] Arnaud Heritier updated MPXDOC-134: --- Assign To: (was: Arnaud Heritier) rewrite - scm support for xdoc plugin - Key: MPXDOC-134 URL: http://jira.codehaus.org/browse/MPXDOC-134 Project: maven-xdoc-plugin Type: Improvement Reporter: Henning Schmiedehausen Attachments: xdoc.patch Original Estimate: 1 hour Remaining: 1 hour This patch removes a lot of CVS'isms from the xdoc plugin and allows to plug in documentation for other scm systems instead of blindlingly parsing cvs-usage.xml. It splits the page into a -public and -developer fragment which is pulled into the scm-usage.xml page dynamically. It also allows for the possible situation that the public repository is of type A (let's say CVS) and the developer repository is of type B (let's say Subversion), skips around some bad (cvs-specific) code in org.apache.maven.project.repository) and adds a few new features to the CVS page (such as displaying the anonymous user and possible password when they are present in the pom). This patch should not be applied as is, it is a diff of our internal development tree against the SVN trunk. There are changes e.g. to the project.xml file that one does not want to have inside the Apache SVN tree. Just as the changelog plugin: If I get karma, I'm willing to apply these patches myself. -- 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: (MPPDF-40) Can't use 2 subsections with the same name
[ http://jira.codehaus.org/browse/MPPDF-40?page=all ] Arnaud Heritier updated MPPDF-40: - Assign To: (was: Arnaud Heritier) Can't use 2 subsections with the same name -- Key: MPPDF-40 URL: http://jira.codehaus.org/browse/MPPDF-40 Project: maven-pdf-plugin Type: Bug Versions: 2.3 Reporter: Arnaud Heritier Priority: Critical Attachments: MPPDF-40.patch If 2 subsections have the same name the pdf generation fails because they have the same id. For exemple : section name=Section 1 subsection name=SubSection /subsection /section section name=Section2 subsection name=SubSection /subsection /section -- 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: (MPXDOC-91) bundled css files contain no filter tokens for ui property values
[ http://jira.codehaus.org/browse/MPXDOC-91?page=all ] Arnaud Heritier updated MPXDOC-91: -- Assign To: (was: Arnaud Heritier) bundled css files contain no filter tokens for ui property values - Key: MPXDOC-91 URL: http://jira.codehaus.org/browse/MPXDOC-91 Project: maven-xdoc-plugin Type: Bug Environment: linux Reporter: David Weinkauf the maven-base.css, maven-theme.css and print.css files currently in CVS and distributed with the latest version (1.6) appear to not have any filter tokens for the properties set in ui.properties and, as a result, any user-defined xdoc ui properties are not set in the CSS files. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPJAVADOC-34) Javadoc links don't work behind a proxy
[ http://jira.codehaus.org/browse/MPJAVADOC-34?page=all ] Arnaud Heritier updated MPJAVADOC-34: - Assign To: (was: Arnaud Heritier) Javadoc links don't work behind a proxy --- Key: MPJAVADOC-34 URL: http://jira.codehaus.org/browse/MPJAVADOC-34 Project: maven-javadoc-plugin Type: Improvement Versions: 1.5, 1.1, 1.2, 1.3, 1.4 Reporter: Carlos Sanchez Priority: Minor Attachments: javadoc.txt Links doesn't work behind a proxy javadoc: Error fetching URL: http://java.sun.com/j2se/1.4.2/docs/api/package-list I've found some information in the net: It is possible to pass proxy information to javadoc. Try: javadoc -J-DproxyHost=myproxyhost.com -J-DproxyPort=8080 -link http://java.sun.com/products/jdk/1.3/docs/api *.java You have to pass http.proxyhost and http.proxyport properties to the JVM. -Dhttp.proxyhost=proxy -Dhttp.proxyport=3128 The problem is that javadoc ant task starts in another jvm (as stated in ant docs) Also I've tried the setProxy ant task and it doesn't work either. ant:setproxy proxyhost=proxy proxyport=3128/ -- 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: (MPXDOC-15) misplaced text in xdocs should be reported
[ http://jira.codehaus.org/browse/MPXDOC-15?page=all ] Arnaud Heritier updated MPXDOC-15: -- Assign To: (was: Arnaud Heritier) misplaced text in xdocs should be reported -- Key: MPXDOC-15 URL: http://jira.codehaus.org/browse/MPXDOC-15 Project: maven-xdoc-plugin Type: Improvement Reporter: Ramon Casha If some text or tag in an xdoc is placed outside the correct place, it is silently skipped. eg: if some documentation text is inadvertently placed outside a section tag, it will simply disappear. Ideally this should be reported as a warning/error by the plugin, but a quick workaround might be to add a catch-all xsl tag which highlights the text in question at the end of a 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]
[jira] Updated: (MPGENAPP-12) Artifact strutstest-2.1.0.jar doesn't exist
[ http://jira.codehaus.org/browse/MPGENAPP-12?page=all ] Arnaud Heritier updated MPGENAPP-12: Assign To: (was: Arnaud Heritier) Artifact strutstest-2.1.0.jar doesn't exist --- Key: MPGENAPP-12 URL: http://jira.codehaus.org/browse/MPGENAPP-12 Project: maven-genapp-plugin Type: Bug Environment: Windows XP Java 1.4.2_03 Maven 1.0-rc2 Reporter: Filippo Vitale Priority: Minor Original Estimate: 3 minutes Remaining: 3 minutes The artifact strutstest-2.1.0.jar doesn't exist in http://www.ibiblio.org/maven/strutstestcase/jars/ A workaround (solution?) may it be: - artifactIdstrutstest/artifactId - version2.1.0/version + artifactIdstrutstestcase/artifactId + version2.1-1.1-2.3/version It works for me -- 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: (MPJAVADOC-52) Cannot set -sourcepath to add paths for inherited javadocs
[ http://jira.codehaus.org/browse/MPJAVADOC-52?page=all ] Arnaud Heritier updated MPJAVADOC-52: - Assign To: (was: Arnaud Heritier) Cannot set -sourcepath to add paths for inherited javadocs -- Key: MPJAVADOC-52 URL: http://jira.codehaus.org/browse/MPJAVADOC-52 Project: maven-javadoc-plugin Type: Bug Versions: 1.7 Environment: Solaris 9 x86, Windows XP Professional, javac 1.5.0-beta2. Reporter: Bernard Marshall In version 1.5 of the javadoc plugin it was possible to specify: maven.javadoc.additionalparam=-sourcepath /usr/java/src so that you could include source paths where you had used the [EMAIL PROTECTED] tag. Unfortunately this is broken in version 1.7. A look at the jelly source shows that 1.7 uses ant:sourcepath to define where the compiled source files live. It does not seem possible to now define other paths to be set for sourcepath. Note that javadoc only allows one -sourcepath argument (it complains if you give more), and since this is controlled by the plugin you cannot extend it. It would be good if there was a: maven.javadoc.extrasourcepath=path1;path2;... setting that would append to the javadoc -sourcepath argument. Without some sort of modification I cannot see how [EMAIL PROTECTED] tags can work (esp. since Sun fixed them up in 1.5). -- 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: (MPXDOC-11) Unicode entities from projext.xml are not shown in generated site in HTML or even in XML
[ http://jira.codehaus.org/browse/MPXDOC-11?page=all ] Arnaud Heritier updated MPXDOC-11: -- Assign To: (was: Arnaud Heritier) Unicode entities from projext.xml are not shown in generated site in HTML or even in XML Key: MPXDOC-11 URL: http://jira.codehaus.org/browse/MPXDOC-11 Project: maven-xdoc-plugin Type: Bug Environment: JDK 1.4.2, Linux 2.4.17, Debian Unstable Reporter: Norbert Pabis Unicode entities from projext.xml are not shown in generated site in HTML or even in XML. For example if there is a developer name with letter #x15b;, in project.xml then in generated xml i html his named name with letter ?. project.xml encoding does not matter here. Setting any encoding e.g. ISO-8859-2, does not work either. -- 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: (MPGENAPP-13) .cvsignore and .svnignore files should be included in the genapped applications
[ http://jira.codehaus.org/browse/MPGENAPP-13?page=all ] Arnaud Heritier updated MPGENAPP-13: Assign To: (was: Arnaud Heritier) .cvsignore and .svnignore files should be included in the genapped applications --- Key: MPGENAPP-13 URL: http://jira.codehaus.org/browse/MPGENAPP-13 Project: maven-genapp-plugin Type: Improvement Reporter: Archimedes Trajano Attachments: .cvsignore .cvsignore and .svnignore files should be included in the genapped applications to prevent users from accidentally including the generated directories in their source repository. -- 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: (MPANT-15) Merge generated tasks with custom tasks
[ http://jira.codehaus.org/browse/MPANT-15?page=all ] Arnaud Heritier updated MPANT-15: - Assign To: (was: Arnaud Heritier) Merge generated tasks with custom tasks --- Key: MPANT-15 URL: http://jira.codehaus.org/browse/MPANT-15 Project: maven-ant-plugin Type: Wish Reporter: Jan Arend Jansen Priority: Minor I would like to generate ant build files from maven that include custom ant tasks that already exist. For example: I use ejbdoclet and webdoclet custom tasks in the maven project to use XDoclet. When I use maven ant to generate the build file from ant, I loose the custom targets, ant the project won't build -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPSITE-34) site:sshdeploy now always fails for any remote error
[ http://jira.codehaus.org/browse/MPSITE-34?page=all ]
Arnaud Heritier updated MPSITE-34:
--
Assign To: (was: Arnaud Heritier)
site:sshdeploy now always fails for any remote error
Key: MPSITE-34
URL: http://jira.codehaus.org/browse/MPSITE-34
Project: maven-site-plugin
Type: Bug
Components: plugin
Versions: 1.6.2
Reporter: fabrizio giustina
after the patch for MPSITE-28 (Maven site 1.6.1 plugin always results in
'Build Successful') now sshdeploy fails for any minor error: for example if
tar can't overwrite a file or if the remote user doesn't have the needed
rights to change the permission for the root site directory (which is pretty
common, like for the htdocs dir on sourceforge).
This is also more annoying considering that an incomplete deploy can leave a
remote *.tar file, which by default is not overwritten and that will make any
further build fail till manually removed.
for refence, this is the patch previously applied by Arnaud:
http://svn.apache.org/viewcvs.cgi/maven/maven-1/plugins/trunk/site/plugin.jelly?rev=202438r1=189828r2=202438diff_format=h
what about leaving the failonerror parameter in last snippet to false or
at least making it configurable?
exec dir=. executable=${maven.ssh.executable} failonerror=true
-- will make the build fail if any of the commands will report an
innocent error
arg line=${maven.ssh.args} -l ${siteUsername} ${siteAddress} 'cd
${maven.homepage} amp;amp;
${maven.site.gunzip.executable} ${maven.final.name}-site.tar.gz amp;amp;
${maven.site.tar.executable}
${maven.site.tar.options} ${maven.final.name}-site.tar amp;amp; chmod -Rf
g+u * . amp;amp; rm
${maven.final.name}-site.tar'/
/exec
--
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: (MPXDOC-30) Not very informative error message on xdoc template error
[ http://jira.codehaus.org/browse/MPXDOC-30?page=all ] Arnaud Heritier updated MPXDOC-30: -- Assign To: (was: Arnaud Heritier) Not very informative error message on xdoc template error - Key: MPXDOC-30 URL: http://jira.codehaus.org/browse/MPXDOC-30 Project: maven-xdoc-plugin Type: Improvement Reporter: Per Olesen Priority: Trivial Hi, Had a problem where a wrong value inside the project.xml repositoryconnection element gave me a not very informative error message: File.. file:/home/polesen/.maven/plugins/maven-xdoc-plugin-1.4/ Element... velocity:merge Line.. 399 Column 9 Invocation of method 'getCvsRoot' in class org.apache.maven.project.Repository threw exception class java.lang.IllegalArgumentException : repository connection string contains more than six tokens It took me some time, and some searching around inside the xdoc plugin files, to find out what my problem was. I do not know if it is easy to give a better message, or if it is a result of the use of velocity templates!? Anyways, I think a newcomer will have some problems finding out what's wrong! /Per -- 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: (MPXDOC-23) Provide a way to exclude some XML files from xdoc transformation
[ http://jira.codehaus.org/browse/MPXDOC-23?page=all ] Arnaud Heritier updated MPXDOC-23: -- Assign To: (was: Arnaud Heritier) Provide a way to exclude some XML files from xdoc transformation Key: MPXDOC-23 URL: http://jira.codehaus.org/browse/MPXDOC-23 Project: maven-xdoc-plugin Type: Improvement Reporter: Jeff French Priority: Minor Sometimes we have XML files that are used as examples in the documentation, but are not documents to be transformed themselves. It would help if we could specify files in a property or file set to exclude from transformation. Those files would just be copied over like non-XML files currently are. A workaround I found is to rename those XML files to *.xxml. Then they get copied over without transformation. You just need to make sure that other documents refer to the new 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]
[jira] Updated: (MPPDF-37) Page numbering not correct with more than 10 items in menu
[ http://jira.codehaus.org/browse/MPPDF-37?page=all ] Arnaud Heritier updated MPPDF-37: - Assign To: (was: Arnaud Heritier) Page numbering not correct with more than 10 items in menu --- Key: MPPDF-37 URL: http://jira.codehaus.org/browse/MPPDF-37 Project: maven-pdf-plugin Type: Bug Versions: 2.2 Environment: any Reporter: Lukas Theussl Priority: Minor Original Estimate: 1 hour Remaining: 1 hour With the following menus in my navigation.xml file: menu name=User Guide item name=Home href=/index.html/ item name=Introduction href=/intro.html/ item name=Installation href=/install.html/ item name=Screen Elements href=/screen.html/ item name=Usagehref=/usage.html/ item name=Known Problems href=/problems.html/ item name=Documentationhref=/doc.html/ item name=History href=/history.html/ item name=Credits href=/credits.html/ item name=Style Files href=/style.html/ item name=License href=/license.html/ /menu menu name=Appendix item name=Bibliography href=/bib.html/ /menu the page number of the pdf file gets reset to one at the 11th section (License). Interestingly, if I move 10 items from the first into the second menu, the page numbering stays correct, so it only seems to affect the first menu. -- 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: (MPJAVADOC-2) I would like more control over the packages that javadoc uses to generate online documentation
[ http://jira.codehaus.org/browse/MPJAVADOC-2?page=all ] Arnaud Heritier updated MPJAVADOC-2: Assign To: (was: Arnaud Heritier) I would like more control over the packages that javadoc uses to generate online documentation -- Key: MPJAVADOC-2 URL: http://jira.codehaus.org/browse/MPJAVADOC-2 Project: maven-javadoc-plugin Type: Improvement Reporter: Julian Payne Today the javadoc plugin takes the list of packages to be what is in the POM and it then appends .* on the end of pom.package. In our case we will put a.b.c as the package but there are some sub-packages that should not be documented via javadoc. In this case I would like to be able to specify a.b.c.d,a.b.c.e.f as the list of packages to document. I can suggest 2 possible ways to implement this: 1) If pom.package has a comma in it then don't add the .* 2) Add a new property for the plugin that overrides the pom.package if, and only if, it exists Thanks, Julian Payne -- 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: (MPPDF-18) PDF Plugin Error on Table with Many Columns
[ http://jira.codehaus.org/browse/MPPDF-18?page=all ] Arnaud Heritier updated MPPDF-18: - Assign To: (was: Arnaud Heritier) PDF Plugin Error on Table with Many Columns --- Key: MPPDF-18 URL: http://jira.codehaus.org/browse/MPPDF-18 Project: maven-pdf-plugin Type: Bug Versions: 2.2 Environment: Fedora Core 1 Linux, Java Runtime 1.4.2_05 Reporter: Jojo Paderes PDF Plugin failed to generate file while processing Xdoc XML data containing table with 19 columns. Here's the debug log while running PDF plugin: __ __ | \/ |__ _Apache__ ___ | |\/| / _` \ V / -_) ' \ ~ intelligent projects ~ |_| |_\__,_|\_/\___|_||_| v. 1.0 build:start: xdoc:init: [mkdir] Created dir: /home/jojo/projects/java/u2/u2_release_1_0_bug/target/generated-xdocs [mkdir] Created dir: /home/jojo/projects/java/u2/u2_release_1_0_bug/target/docs pdf:init: [echo] ### Debug mode is on ### == === xdoc plugin properties === == maven.docs.src = [/home/jojo/projects/java/u2/u2_release_1_0_bug/xdocs] maven.docs.dest = [/home/jojo/projects/java/u2/u2_release_1_0_bug/target/docs] maven.gen.docs = [/home/jojo/projects/java/u2/u2_release_1_0_bug/target/generated-xdocs] maven.xdoc.date.format = [dd ] maven.xdoc.date.locale = [en] == === pdf plugin properties === == maven.pdf.confidential = [false] maven.pdf.paperType = [A4] maven.pdf.companyIncName= [Company] maven.pdf.copyrightYear = [2003] maven.pdf.imageDpi = [72] maven.pdf.debug = [true] maven.pdf.navigationFile= [navigation.xml] maven.pdf.navigationFilePath= [/home/jojo/projects/java/u2/u2_release_1_0_bug/xdocs] maven.pdf.pdfName = [project.pdf] maven.pdf.cover.projectCompany = [Company] maven.pdf.cover.projectName = [Project] maven.pdf.cover.type= [Project Documentation] maven.pdf.cover.version = [1.0] maven.pdf.cover.date= [14 October 2004] maven.pdf.projectLogo = [] maven.pdf.companyLogo = [] == === pdf internal variables === == internal_pdf_workingDir = [/home/jojo/projects/java/u2/u2_release_1_0_bug/target/pdf] [mkdir] Created dir: /home/jojo/projects/java/u2/u2_release_1_0_bug/target/pdf pdf:prepare: [copy] Copying 3 files to /home/jojo/projects/java/u2/u2_release_1_0_bug/target/pdf [copy] Copying 7 files to /home/jojo/projects/java/u2/u2_release_1_0_bug/target/pdf fo:fo: [echo] Generating /home/jojo/projects/java/u2/u2_release_1_0_bug/target/docs/project.fo from /home/jojo/projects/java/u2/u2_release_1_0_bug/xdocs/navigation.xml ... [style] Processing /home/jojo/projects/java/u2/u2_release_1_0_bug/xdocs/navigation.xml to /home/jojo/projects/java/u2/u2_release_1_0_bug/target/pdf/project.fo [style] Loading stylesheet /home/jojo/.maven/cache/maven-pdf-plugin-2.2/plugin-resources/project2fo.xslt [style] home/jojo/.maven/cache/maven-pdf-plugin-2.2/plugin-resources/project2fo.xslt:153:46: Warning! Creating XSL:FO for /home/jojo/projects/java/u2/u2_release_1_0_bug/target/pdf/installation/configuration.xml [style] file:/home/jojo/.maven/cache/maven-pdf-plugin-2.2/plugin-resources/fo-table-column-widths.xslt:349:26: Warning! Cell (1,1) text()='CODE' rowspan=1 colspan=1 width=NaN [style] file:/home/jojo/.maven/cache/maven-pdf-plugin-2.2/plugin-resources/fo-table-column-widths.xslt:351:26: Warning! Current cell mask: --in 1-out [style] file:/home/jojo/.maven/cache/maven-pdf-plugin-2.2/plugin-resources/fo-table-column-widths.xslt:352:26: Warning! Next row mask: --in --out [style] file:/home/jojo/.maven/cache/maven-pdf-plugin-2.2/plugin-resources/fo-table-column-widths.xslt:353:26: Warning! Estimated cell widths: [style] file:/home/jojo/.maven/cache/maven-pdf-plugin-2.2/plugin-resources/fo-table-column-widths.xslt:355:26: Warning! Cell widths so far : 5? 5? 5? 5? 5? 5? 5? 5? 5? 5? [style] file:/home/jojo/.maven/cache/maven-pdf-plugin-2.2/plugin-resources/fo-table-column-widths.xslt:349:26: Warning! Cell (1,2) text()='M' rowspan=1 colspan=1 width=NaN [style] file:/home/jojo/.maven/cache/maven-pdf-plugin-2.2/plugin-resources/fo-table-column-widths.xslt:351:26: Warning! Current cell mask: 1-in 11out [style] file:/home/jojo/.maven/cache/maven-pdf-plugin-2.2/plugin-resources/fo-table-column-widths.xslt:352:26: Warning! Next row mask: --in
[jira] Updated: (MPXDOC-108) setting maven.xdoc.jsl does not work with multiproject
[ http://jira.codehaus.org/browse/MPXDOC-108?page=all ]
Arnaud Heritier updated MPXDOC-108:
---
Assign To: (was: Arnaud Heritier)
setting maven.xdoc.jsl does not work with multiproject
--
Key: MPXDOC-108
URL: http://jira.codehaus.org/browse/MPXDOC-108
Project: maven-xdoc-plugin
Type: Bug
Versions: 1.7.1
Environment: WinXP German, Cygwin, Maven 1.0 RC3
Reporter: Joerg Schaible
You cannot use a modified site.jsl for all projects in a multiproject
environment. The value of the property is always interpreted as relative file
name to the directory where the site goal was invoked. Example:
root
+- sub1/*
+- sub2/*
+- site.jsl
+- project.properties
You can set maven.xdoc.jsl=site.jsl in project.properties to build
multiproject:site, but calling site in one of the subprojects fails, because
site.jsl is not found (value inherited in RC3). Setting
maven.xdoc.jsl=${maven.multiproject.basedir}/site.jsl fails also, because the
plugin internally prepends ${basedir} resulting in an invalid filename:
BUILD FAILED
org.apache.commons.jelly.JellyException: null:-1:-1: null Could not parse
Jelly script
at
org.apache.commons.jelly.JellyContext.compileScript(JellyContext.java:491)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:608)
at
org.apache.commons.jelly.JellyContext.runScript(JellyContext.java:584)
at
org.apache.commons.jelly.tags.core.IncludeTag.doTag(IncludeTag.java:143)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.FileTag.writeBody(FileTag.java:207)
at org.apache.commons.jelly.tags.core.FileTag.doTag(FileTag.java:103)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:145)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.impl.DynamicTag.doTag(DynamicTag.java:125)
at
org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:145)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:233)
at
org.apache.commons.jelly.tags.util.AvailableTag.doTag(AvailableTag.java:110)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.Goal.attainPrecursors(Goal.java:488)
at com.werken.werkz.Goal.attain(Goal.java:573)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.jelly.tags.werkz.MavenAttainGoalTag.doTag(MavenAttainGoalTag.java:126)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:279)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:135)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag.runBodyTag(MavenGoalTag.java:79)
at
org.apache.maven.jelly.tags.werkz.MavenGoalTag$MavenGoalAction.performAction(MavenGoalTag.java:110)
at com.werken.werkz.Goal.fire(Goal.java:639)
at com.werken.werkz.Goal.attain(Goal.java:575)
at com.werken.werkz.WerkzProject.attainGoal(WerkzProject.java:193)
at
org.apache.maven.plugin.PluginManager.attainGoals(PluginManager.java:610)
at
[jira] Updated: (MPPDF-7) PDF generation does not utilise proxy settings for external resources
[ http://jira.codehaus.org/browse/MPPDF-7?page=all ] Arnaud Heritier updated MPPDF-7: Assign To: (was: Arnaud Heritier) PDF generation does not utilise proxy settings for external resources - Key: MPPDF-7 URL: http://jira.codehaus.org/browse/MPPDF-7 Project: maven-pdf-plugin Type: Bug Versions: 2.0 Reporter: Brett Porter PDF generation does not utilise proxy settings for external resources -- 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: (MPXDOC-149) DT is appearing same way as subsection
[ http://jira.codehaus.org/browse/MPXDOC-149?page=all ] Arnaud Heritier updated MPXDOC-149: --- Assign To: (was: Arnaud Heritier) DT is appearing same way as subsection Key: MPXDOC-149 URL: http://jira.codehaus.org/browse/MPXDOC-149 Project: maven-xdoc-plugin Type: Bug Versions: 1.9 Environment: HTML generated Reporter: Benoit Xhenseval Attachments: xdocissue.PNG Hi I have noticed a difference between the stylesheet in XDOC 1.8 and 1.9.1 the XDOCs I have are using DL DT html tags for definition list/term. The new xdoc plugin seems to treat the SUBSECTION and DT the same way, which make the DL/DT look rather strange... I enclose a screenshot. -- 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: (MPXDOC-125) url and timezone not used for contributor
[ http://jira.codehaus.org/browse/MPXDOC-125?page=all ] Arnaud Heritier updated MPXDOC-125: --- Assign To: (was: Arnaud Heritier) url and timezone not used for contributor - Key: MPXDOC-125 URL: http://jira.codehaus.org/browse/MPXDOC-125 Project: maven-xdoc-plugin Type: Improvement Versions: 1.9 Reporter: Shinobu Kawai Yoshida Priority: Minor Attachments: contributor.url.timezone.patch Is there a reason why the url and timezone are not used for the contributors? http://maven.apache.org/reference/project-descriptor.html#contributor -- 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: (MPXDOC-150) maven.xdoc.date.format does not seem to have any effect?
[ http://jira.codehaus.org/browse/MPXDOC-150?page=all ] Arnaud Heritier updated MPXDOC-150: --- Assign To: (was: Arnaud Heritier) maven.xdoc.date.format does not seem to have any effect? Key: MPXDOC-150 URL: http://jira.codehaus.org/browse/MPXDOC-150 Project: maven-xdoc-plugin Type: Bug Versions: 1.9 Environment: XP Reporter: Benoit Xhenseval Fix For: 1.9.2 Hello I believe that the maven.xdoc.date.format property put in my project.properties file has no effect. Regardless of what I put there, the date format seems to be: June 22, 2005 9:04:09 PM BST despite having: maven.xdoc.date.format=dd MMM HH:mm z The properties file is taken into account as I can change where the date is: maven.xdoc.date=left or maven.xdoc.date=right Thanks Benoit -- 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: (MPJAVADOC-25) Generate javadoc linked to source X ref
[ http://jira.codehaus.org/browse/MPJAVADOC-25?page=all ] Arnaud Heritier updated MPJAVADOC-25: - Assign To: (was: Arnaud Heritier) Generate javadoc linked to source X ref --- Key: MPJAVADOC-25 URL: http://jira.codehaus.org/browse/MPJAVADOC-25 Project: maven-javadoc-plugin Type: Improvement Reporter: Miguel Griffa Priority: Minor When nagivating source, if javadoc is cliecked there's no way back (do not count browser button since many links on javadoc shuold be available for navigation) a nice 'view source' link on the javadoc would be great to ehance the documentation navigation -- 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: How to contribute to the Maven project
Yes I think it's not a good practice to assign by default the issue to someone. The person shhould assign it to himself when he wants to work on it. I just removed the default assignement for my plugin in m1 ;-) Arnaud On 8/22/05, Trygve Laugstøl [EMAIL PROTECTED] wrote: On Mon, Aug 22, 2005 at 12:37:37PM +0200, Arnaud HERITIER wrote: Be careful with this rule A lot of plugins (in m1) are auto-assigned to the plugin's manager. I must deactivate this rules for my plugins but I always forgot to do it Actually I have more than one hundred of issues assigned to me. I know that Jason had also a lot of issues. The lists are currently only for Maven 2 issues but there is no reason why they shouldn't cover Maven 1 issues in the future. IMO there shouldn't be a default assignee, WDYT? -- Trygve -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) iD8DBQFDCa9K4EbM92cyCUURAheeAKChyoOx7Nz0cOEHBhYWR7yRi8cqgQCeMyeq ZX5hobENL1ojp9cwHQ6KCXY= =nucO -END PGP SIGNATURE-
[jira] Updated: (MPJAVADOC-4) add self-referencing properties
[ http://jira.codehaus.org/browse/MPJAVADOC-4?page=all ]
Arnaud Heritier updated MPJAVADOC-4:
Assign To: (was: Arnaud Heritier)
add self-referencing properties
---
Key: MPJAVADOC-4
URL: http://jira.codehaus.org/browse/MPJAVADOC-4
Project: maven-javadoc-plugin
Type: Improvement
Environment: every
Reporter: Martin Skopp
Original Estimate: 1 hour
Remaining: 1 hour
Add the ability to set self-referencing properties in the *.properties files
of maven. This could be useful e.g. for javadoc plugin for a (hypothetical)
javadoc.offlineUrl property, which points to where the offline javadocs are
located:
project.properties could contain such locations which are part of the
project, e.g.
javadoc.offlineUrl=apidoc/package1/apidoc/packages.html:apidoc/package2/apidoc/packages.html
$HOME/build.properties then should be able to _extend_ the property by adding
further offline URLs, e.g.
javadoc.offlineUrl=${javadoc.offlineUrl}:/usr/share/j2sdk1.4.1/docs/api/
Of course, a general self-referencing properties could be useful for
several other cases.
As far as I was able to test this feature, a self-referencing properties
-used like above- causes a Exception.
I have no idea which code needs to be changed, so sorry, there's no patch
attached.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (MPXDOC-127) Show organization in header even if logo not set
[ http://jira.codehaus.org/browse/MPXDOC-127?page=all ] Arnaud Heritier updated MPXDOC-127: --- Assign To: (was: Arnaud Heritier) Show organization in header even if logo not set Key: MPXDOC-127 URL: http://jira.codehaus.org/browse/MPXDOC-127 Project: maven-xdoc-plugin Type: Wish Versions: 1.9 Environment: When the organization logo is not set in project.xml Reporter: Shinobu Kawai Yoshida Priority: Minor Attachments: xdoc.organizationLogo.patch Currently, if the organization logo is not set, it does not appear in the header. Whereas for the project, it shows a text of the project name instead if the logo is not set. It would be great if it did the same with the organization. ie, show the organization name if the logo is not set. -- 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: (MPGENAPP-3) Genapp to prompt for project root
[ http://jira.codehaus.org/browse/MPGENAPP-3?page=all ]
Arnaud Heritier updated MPGENAPP-3:
---
Assign To: (was: Arnaud Heritier)
Genapp to prompt for project root
-
Key: MPGENAPP-3
URL: http://jira.codehaus.org/browse/MPGENAPP-3
Project: maven-genapp-plugin
Type: Improvement
Environment: All
Reporter: Sri Sankaran
Priority: Trivial
Original Estimate: 3 hours
Remaining: 3 hours
Currently, the genapp plugin assumes that ${basedir} is to be the top-level
of the project being 'gen'ed. The user doesn't realize that the plugin is
going to write a bunch of files/directories to the current directory until
*after* running it.
It would be nice if we could prompt for a location. I have tested that with
simple code modifications to plugin.jelly plugin.properties
plugin.jelly:
Step 1
Replace all occurences of ${basedir} with ${projectRoot}.
Step 2
Add the following lines at line 92
!-- Get the project root --
j:set var=projectRoot value=${maven.genapp.projectRoot}/
j:if test=${empty(projectRoot)}
i:ask question=${maven.genapp.prompt.projectRoot}
answer=projectRoot
default=${basedir}/${maven.genapp.template.name}/
/j:if
plugin.properties:
Added the property setting
maven.genapp.prompt.projectRoot=Please specify the project root directory:
I can provide the modified files -- and related changes to properties.xml --
if you wish.
--
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: (MPXDOC-22) branches info project descriptor should be shown in generated site
[ http://jira.codehaus.org/browse/MPXDOC-22?page=all ] Arnaud Heritier updated MPXDOC-22: -- Assign To: (was: Arnaud Heritier) branches info project descriptor should be shown in generated site -- Key: MPXDOC-22 URL: http://jira.codehaus.org/browse/MPXDOC-22 Project: maven-xdoc-plugin Type: Wish Reporter: Norbert Pabis Priority: Minor Branches info project descriptor should be shown in generated site. It could be visualised similira to changes-plugin output. -- 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: (MPXDOC-106) one cannot call xdoc:copy-user-resources directly
[ http://jira.codehaus.org/browse/MPXDOC-106?page=all ] Arnaud Heritier updated MPXDOC-106: --- Assign To: (was: Arnaud Heritier) one cannot call xdoc:copy-user-resources directly - Key: MPXDOC-106 URL: http://jira.codehaus.org/browse/MPXDOC-106 Project: maven-xdoc-plugin Type: Improvement Environment: maven 1.0rc2 Reporter: Jerome Lacoste Priority: Trivial Attachments: maven-1.0rc2-maven-xdoc-plugin-1.6_patch_copy_user_resource_standalone.txt Original Estimate: 5 minutes Remaining: 5 minutes In the xdoc plugin found in 1.0rc2. property maven.docs.src.available doesn't exist when one calls $MAVEN_HOME/bin/maven xdoc:copy-user-resources -- 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]
