[jira] Commented: (MASSEMBLY-414) Allow regular expressions in include/exclude patterns for filesets
[
http://jira.codehaus.org/browse/MASSEMBLY-414?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=192693#action_192693
]
Mark Hobson commented on MASSEMBLY-414:
---
Note that this somewhat contradicts:
http://maven.apache.org/plugins/maven-assembly-plugin/examples/single/including-and-excluding-artifacts.html
Allow regular expressions in include/exclude patterns for filesets
--
Key: MASSEMBLY-414
URL: http://jira.codehaus.org/browse/MASSEMBLY-414
Project: Maven 2.x Assembly Plugin
Issue Type: Bug
Affects Versions: 2.2-beta-3
Reporter: John Casey
Assignee: John Casey
Fix For: 2.2-beta-4
In certain cases, it's very difficult to accomplish the right blend of
inclusions and exclusions for fileSets. For instance, if a project contains
${basedir}/target and ${basedir}/src/site/resources/examples/target/blah, and
also contains child modules with similar constructs, it can be next to
impossible to include all of the legit sources for the project structure
while at the same time excluding the target directories generated during a
build.
With regex and negative-lookahead, we could handle this case. Therefore, we
should provide some syntax for embedding a regular expression in an
include/exclude pattern. This will help the assembly plugin to generate a
release source bundle for ASF projects.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MNG-4381) Allow extension plugins to contribute non-core components to be reused by other plugins
[ http://jira.codehaus.org/browse/MNG-4381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benjamin Bentmann closed MNG-4381. -- Assignee: Benjamin Bentmann Resolution: Fixed Fix Version/s: 3.0-alpha-3 Done in [r819540|http://svn.apache.org/viewvc?view=revrevision=819540], see also [Maven 3.x Class Loading|http://cwiki.apache.org/confluence/display/MAVEN/Maven+3.x+Class+Loading] Allow extension plugins to contribute non-core components to be reused by other plugins --- Key: MNG-4381 URL: http://jira.codehaus.org/browse/MNG-4381 Project: Maven 2 Issue Type: New Feature Components: Plugins and Lifecycle Affects Versions: 2.x Reporter: Benjamin Bentmann Assignee: Benjamin Bentmann Fix For: 3.0-alpha-3 In Maven 2.x, build extensions can only contribute components that realize a custom impl of some API defined by the Maven core like artifact handlers and lifecycle mappings. However, to support things like Tycho in a stock Maven distro, we need a build extension to provide components that a) realize APIs defined merely by the extension and are unknown to Maven itself b) can be looked up and accessed via API from the extension and other plugins in the same project c) can be shared among all projects in the reactor using the same extension, including state kept by singletons See also https://issues.sonatype.org/browse/TYCHO-236. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4383) Uninterpolated expressions should cause an error
[
http://jira.codehaus.org/browse/MNG-4383?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=192731#action_192731
]
Anders Kr. Andersen commented on MNG-4383:
--
Hi Paul
Yes it seems to be an error here.
On the other hand expression language is always like that. If the variable
cannot be looked up in the map, the variable key is printed.
I find it relative problematic to start evaluating the importance of a missing
key.
Here an exception could be nice, but many other places ... and the way EL works
in general .. it would be the key you will see.
So I think that ${x} is the error message you will get. So this is really
not an error, but a feature
/Anders Kr.
Uninterpolated expressions should cause an error
Key: MNG-4383
URL: http://jira.codehaus.org/browse/MNG-4383
Project: Maven 2
Issue Type: Bug
Components: Dependencies
Affects Versions: 2.2.1, 3.0-alpha-2
Reporter: Paul Benedict
I declared a dependency as such:
{noformat}dependency
groupIdorg.slf4j/groupId
artifactIdslf4j-api/artifactId
version${slf4j.version}/version
/dependency{noformat}
But did not define the *slf4j.version* property. Obviously ${...} is an
expression and if the expression is not resolved, why allow it? Here was the
output:
{noformat} Downloading:
http://repo1.maven.org/maven2/org/slf4j/slf4j-api/${slf4j.version}/slf4j-api-${slf4j.version}.pom{noformat}
In terms of usability, an obvious expression should be interpolated. If it
cannot, it should be a runtime error.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly 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: (MREPOSITORY-19) Require SCM information to help tooling for project materialization from the repository
[ http://jira.codehaus.org/browse/MREPOSITORY-19?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] John Casey updated MREPOSITORY-19: -- Fix Version/s: 2.3 Require SCM information to help tooling for project materialization from the repository --- Key: MREPOSITORY-19 URL: http://jira.codehaus.org/browse/MREPOSITORY-19 Project: Maven 2.x Repository Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: John Casey Assignee: John Casey Fix For: 2.3 if we require SCM information to be included in uploaded POMs it will drastically improve the ability of tooling to materialize/checkout these project sources for reference on-demand. This makes software development immeasurably easier, especially for working with open source projects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MREPOSITORY-19) Require SCM information to help tooling for project materialization from the repository
Require SCM information to help tooling for project materialization from the repository --- Key: MREPOSITORY-19 URL: http://jira.codehaus.org/browse/MREPOSITORY-19 Project: Maven 2.x Repository Plugin Issue Type: Improvement Affects Versions: 2.2 Reporter: John Casey if we require SCM information to be included in uploaded POMs it will drastically improve the ability of tooling to materialize/checkout these project sources for reference on-demand. This makes software development immeasurably easier, especially for working with open source projects. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MECLIPSE-389) After running clean phase, eclipse detects some errors due to missing folder.
[
http://jira.codehaus.org/browse/MECLIPSE-389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=192752#action_192752
]
Andreas Veithen commented on MECLIPSE-389:
--
A workaround for this issue is to configure the maven-clean-plugin to skip the
directory containing the files generated by the eclipse:eclipse goal:
plugin
artifactIdmaven-clean-plugin/artifactId
version2.3/version
configuration
excludeDefaultDirectoriestrue/excludeDefaultDirectories
filesets
fileset
directory${project.build.directory}/directory
excludes
excludegenerated-resources/eclipse/**/exclude
/excludes
/fileset
/filesets
/configuration
/plugin
After running clean phase, eclipse detects some errors due to missing
folder.
---
Key: MECLIPSE-389
URL: http://jira.codehaus.org/browse/MECLIPSE-389
Project: Maven 2.x Eclipse Plugin
Issue Type: Bug
Components: WTP support
Affects Versions: 2.5
Reporter: pkernevez
We are using the configuration point out at the bottom of the page :
http://maven.apache.org/plugins/maven-eclipse-plugin/examples/multi-module-projects.html
The presence of the wtpmanifesttrue/wtpmanifest creates the folder
target\generated-resources\eclipse\META-INF\ (due to the creation of the
file target\generated-resources\eclipse\META-INF\MANIFEST.MF) during the
eclipse:eclipse goal.
First trouble, when we run the phase clean this folder is deleted and never
recreated, even if we run other phases (like install). When Eclipse refresh
its folder tree it indicates an error due to this sources missing folder.
Another trouble, is that the name of this Manifest file is hardcoded in the
class EclipseManifestWriter
See
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-eclipse-plugin/src/main/java/org/apache/maven/plugin/eclipse/writers/EclipseManifestWriter.java?revision=618468view=markup
The plugin manifest is not used, neither the plugin configuration:
manifest
${basedir}/src/main/resources/META-INF/MANIFEST.MF
/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
[jira] Commented: (MANTRUN-86) Cannot handle multiple tasks elements
[
http://jira.codehaus.org/browse/MANTRUN-86?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=192776#action_192776
]
Kathy Hale commented on MANTRUN-86:
---
To give you some context, I was trying import 3 targets: start web server, stop
web server, and start webserver as debug. They really aren't related to the
lifecycle as I see it, but they're still a nice developer tool to have scripted
to avoid using services and shell scripts.
So these seem like my only options unless the plugin was improved/fixed, none
of which sound very appealing:
# Mash 3 targets into one maven target, and use if/else's to control which is
called
# Leave these 3 targets in ANT and don't migrate to maven
# Bind the targets to arbitrary lifecycle phases (which doesn't really make
sense) so I can use {{execute}}
Cannot handle multiple tasks elements
-
Key: MANTRUN-86
URL: http://jira.codehaus.org/browse/MANTRUN-86
Project: Maven 2.x Antrun Plugin
Issue Type: Bug
Affects Versions: 1.1
Reporter: Thomas Diesler
{code:xml}
plugin
artifactIdmaven-antrun-plugin/artifactId
executions
execution
phaseinstall/phase
goals
goalrun/goal
/goals
configuration
tasks if=jboss.local.repository
property name=version.id value=${project.version}/
property name=jboss.local.repository
value=${jboss.local.repository}/
ant antfile=ant/build-install.xml target=install/
/tasks
tasks unless=jboss.local.repository
echo message=Cannot install to
jboss.local.repository=${jboss.local.repository}/
/tasks
/configuration
/execution
/executions
/plugin
{code}
Always executes the last tasks element although 'jboss.local.repository' is
set
[INFO] [antrun:run {execution: default}]
[INFO] Executing tasks
[echo] Cannot install to
jboss.local.repository=/home/tdiesler/svn/jboss.local.repository
[INFO] Executed tasks
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDOAP-24) programing-language, os and name properties should be an RDF literals, not a RDF resources.
programing-language, os and name properties should be an RDF literals, not a RDF resources. --- Key: MDOAP-24 URL: http://jira.codehaus.org/browse/MDOAP-24 Project: Maven 2.x DOAP Plugin Issue Type: Bug Affects Versions: 1.1 Environment: Any Reporter: Tim Fliss Priority: Minor Attachments: doap-language-bugreport.tgz, maven-doap-plugin.diff Summary The programming-language, os, and name properties are literals, not URIs. They should not be written as rdf:resources in the RDF output. The Problem While the resulting RDF will validate, what happens is that an RDF parser will interpret programming-language rdf:resource=java / as a URI fragment. (see the attached incorrect doap-language-bugreport.tgz:/target/site/doap_doap-language.rdf) Since there is no explicit xml:base in the DoaP file generated by the plugin, the resulting URL is based on the default supplied by the RDF parser. For example using the W3C RDF Validator yields: http://www.w3.org/RDF/Validator/run/java rather than simply java XML Base for RDF is specified at: see http://www.w3.org/TR/2003/PR-rdf-syntax-grammar-20031215/#section-Syntax-ID-xml-base Also note that the Apache Doap instructions correctly do not have rdf:resource for the programming language element: http://projects.apache.org/languages.html The Fix Instead of programming-language rdf:resource=java /, the plugin should generate programming-languagejava/programming-language. Similar changes apply to the os and name properties. Validation I am attaching diffs that include changes to the unit tests. Also, the RDF validator at http://www.w3.org/RDF/Validator/direct may be used to demonstrate that the progamming language, etc. elements are getting resolved to: http://www.w3.org/RDF/Validator/run/java rather than simply java. Simply java is what it should be. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MAVENUPLOAD-2616) synchronize project joost to the central repository
synchronize project joost to the central repository --- Key: MAVENUPLOAD-2616 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2616 Project: Maven Upload Requests Issue Type: Wish Reporter: Oliver Becker net.sf.joost,mavens...@web.sourceforge.net:/home/groups/j/jo/joost/htdocs/m2repo,rsync_ssh,Oliver Becker,obec...@users.sourceforge.net -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MDOAP-25) foaf:Organization usage doesn't comply with DoaP/FoaF specs.
foaf:Organization usage doesn't comply with DoaP/FoaF specs. Key: MDOAP-25 URL: http://jira.codehaus.org/browse/MDOAP-25 Project: Maven 2.x DOAP Plugin Issue Type: Bug Affects Versions: 1.1 Environment: Any Reporter: Tim Fliss Priority: Minor Attachments: doap-organization-bugreport.tgz Summary The foaf:Organization node is misplaced inside the foaf:Person node. It is not compliant with the FoaF or Doap specs. The Problem This is an instance of the issue described here: http://lists.foaf-project.org/pipermail/foaf-dev/2009-January/009452.html foaf:Organization like foaf:Group is a foaf:Agent (see http://xmlns.com/foaf/spec/#term_Agent), so the issue is the same. The recommended syntax from the DoaP project examples is to use the foaf:member property between the foaf:Organization node and the foaf:Person node. Unfortunately, per the FoaF spec, the relation only goes in that direction (Organization-member-Person) with no convenient inverse property. The Fix The best fix I can currently find is to use blank nodes and a separate Organization element that is not nested in the person element. Unfortunately, because the DoaP plugin isn't using native RDF tools internally, this will require a little more bookkeeping. rdf:RDF doap:Project maintainer rdf:nodeID=jdoe/ founder rdf:nodeID=jdoe/ /doap:Project Person nodeID=jdoe nameJohn Doe/name mbox rdf:resource=mailto:j...@example.org; / /Person doap:Organization doap:homepage rdf:resource=http://www.example.org; / doap:member rdf:nodeID=jdoe / /doap:Organization /rdf:RDF Additional Info Info about rdf:nodeID is available at: http://www.w3.org/TR/rdf-syntax-grammar/#section-Syntax-blank-nodes -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MANTTASKS-124) Setting dependencies with the provided scope does not work
[ http://jira.codehaus.org/browse/MANTTASKS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=192814#action_192814 ] John Gibson commented on MANTTASKS-124: --- The fix delivered by MANTTASKS-147 for 2.0.10 basically corrects the issue for me. useScope=provided still doesn't work for me, but scopes=provided does. Using the same POM that I described above, with scopes instead of useScope gives me a classpath containing all of the dependencies in the provided. So, I'm not sure if the issue should be closed or just downgraded from Major. Setting dependencies with the provided scope does not work -- Key: MANTTASKS-124 URL: http://jira.codehaus.org/browse/MANTTASKS-124 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: dependencies task Affects Versions: 2.0.9 Environment: OS X 10.4.11, Java 5, Ant 1.7.0, Ant 1.6.5 Reporter: John Gibson If you use the provided scope to pull in dependences like this: artifact:dependencies pathId=osgi.provided.classpath filesetId=osgi.provided.fileset verbose=true useScope=provided pom refid=osgi.maven.project / remoteRepository refid=m2.repository/ /artifact:dependencies Then the result classpath and fileset are empty despite the POM containing definitions like this: ... dependencies dependency groupIdorg.osgi/groupId artifactIdosgi-compendium/artifactId version4.1.0/version scopeprovided/scope /dependency dependency groupIdorg.osgi/groupId artifactIdosgi-core/artifactId version4.1.0/version scopeprovided/scope /dependency ... /dependencies I would expect to have the path/fileset contain at least those two jars (I'm not sure about transitive dependencies, however). Other users have encountered this issue, see here: http://www.nabble.com/maven-ant-tasks-and-the-provided-scope-td19662878.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
[jira] Issue Comment Edited: (MANTTASKS-124) Setting dependencies with the provided scope does not work
[ http://jira.codehaus.org/browse/MANTTASKS-124?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=192814#action_192814 ] John Gibson edited comment on MANTTASKS-124 at 9/29/09 6:28 PM: The fix delivered by MANTTASKS-147 for 2.0.10 basically corrects the issue for me. useScope=provided still doesn't work for me, but scopes=provided does. Using the same POM that I described above, with scopes instead of useScope gives me a classpath containing all of the dependencies in the provided scope. So, I'm not sure if the issue should be closed or just downgraded from Major. was (Author: redshadow): The fix delivered by MANTTASKS-147 for 2.0.10 basically corrects the issue for me. useScope=provided still doesn't work for me, but scopes=provided does. Using the same POM that I described above, with scopes instead of useScope gives me a classpath containing all of the dependencies in the provided. So, I'm not sure if the issue should be closed or just downgraded from Major. Setting dependencies with the provided scope does not work -- Key: MANTTASKS-124 URL: http://jira.codehaus.org/browse/MANTTASKS-124 Project: Maven 2.x Ant Tasks Issue Type: Bug Components: dependencies task Affects Versions: 2.0.9 Environment: OS X 10.4.11, Java 5, Ant 1.7.0, Ant 1.6.5 Reporter: John Gibson If you use the provided scope to pull in dependences like this: artifact:dependencies pathId=osgi.provided.classpath filesetId=osgi.provided.fileset verbose=true useScope=provided pom refid=osgi.maven.project / remoteRepository refid=m2.repository/ /artifact:dependencies Then the result classpath and fileset are empty despite the POM containing definitions like this: ... dependencies dependency groupIdorg.osgi/groupId artifactIdosgi-compendium/artifactId version4.1.0/version scopeprovided/scope /dependency dependency groupIdorg.osgi/groupId artifactIdosgi-core/artifactId version4.1.0/version scopeprovided/scope /dependency ... /dependencies I would expect to have the path/fileset contain at least those two jars (I'm not sure about transitive dependencies, however). Other users have encountered this issue, see here: http://www.nabble.com/maven-ant-tasks-and-the-provided-scope-td19662878.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
[jira] Commented: (MAVENUPLOAD-2598) Rsync for MySQL Connector/J broken somewhere
[ http://jira.codehaus.org/browse/MAVENUPLOAD-2598?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=192816#action_192816 ] Mark Matthews commented on MAVENUPLOAD-2598: We've now updated rssh on rsync.mysql.com. Is there any chance someone could attempt to get this to sync again? Note that the host key has changed, so someone will probably have to run the rsync by hand at least once. Rsync for MySQL Connector/J broken somewhere Key: MAVENUPLOAD-2598 URL: http://jira.codehaus.org/browse/MAVENUPLOAD-2598 Project: Maven Upload Requests Issue Type: Bug Reporter: Mark Matthews It seems that the rsync of the bundles that we (MySQL) put up to be synchronized into the repository has broken somewhere. Are you receiving errors on your end? -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
