[jira] Commented: (MEAR-102) Support for JBoss 5 as well as some missing elements
[ http://jira.codehaus.org/browse/MEAR-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166522#action_166522 ] Stephane Nicoll commented on MEAR-102: -- I would also configure it with some hierarchical object. The problem here is that loadRepository is already defined and has the type String. We can obviously change that but it will break existing projects. Let's do this the non optimal way for now, we can plan to refactor it for the next major release if people complain > Support for JBoss 5 as well as some missing elements > > > Key: MEAR-102 > URL: http://jira.codehaus.org/browse/MEAR-102 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3.2 >Reporter: Daniel Pfeifer >Assignee: Stephane Nicoll > Fix For: 2.3.2 > > Attachments: maven-ear-plugin-jboss-additions.patch > > > I had a little e-mail conversation with Jason van Zyl about some improvements > that I did in the Ear Plugin, he suggested I would post them here. > Following is added: > * Support for JBoss 5 > * Config for loader-repository-config (3.2, 4.0, 4.2, 5.0) > * Config for library-directory (4.2 and 5.0) > * Config for configParserClass (3.2, 4.0, 4.2, 5.0) > * Config for loaderRepositoryClass (3.2, 4.0, 4.2, 5.0) > * A couple of integration test projects for the new features > To be honest, I don't feel 100% comfortable with the way one configures the > loader-repository part in the POM-file (maybe things should be nested to > resemble the jboss-app.xml a little more), however, I didn't want to alter > the plugin too much as to not make it. > Anyway, have a look at the proposed changes and tell me whether you think > they are worth being committed to your code base. -- 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: (MWAR-166) exclude the transitive dependency
[ http://jira.codehaus.org/browse/MWAR-166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stephane Nicoll closed MWAR-166. Resolution: Won't Fix > exclude the transitive dependency > - > > Key: MWAR-166 > URL: http://jira.codehaus.org/browse/MWAR-166 > Project: Maven 2.x War Plugin > Issue Type: New Feature >Affects Versions: 2.1-beta-1 >Reporter: Michael Meng >Assignee: Stephane Nicoll >Priority: Critical > > Would you please add a flag which will allow user to have a flexibility to > include/exclude the transitive dependent jars in the WEB-INF/lib folder? > The true defined inthe dependency is working as desired. > if we have a war project which depends on A.jar and A.jar transitively > depends on B.jar (B.jar is not defined in pom.xml). currently the A.jar and > B.jar are both included in the lib folder. > If we define A.jar as true, then A.jar is exclude from > lib folder, but B.jar are included. > What we really want is A.jar to be in lib and B.jar not to be include. > Thanks -- 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: (MEAR-102) Support for JBoss 5 as well as some missing elements
[ http://jira.codehaus.org/browse/MEAR-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166526#action_166526 ] Stephane Nicoll commented on MEAR-102: -- Ah I forgot I had total control on this thing. I thought it was injected by plexus. Let's implement it the right way then > Support for JBoss 5 as well as some missing elements > > > Key: MEAR-102 > URL: http://jira.codehaus.org/browse/MEAR-102 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3.2 >Reporter: Daniel Pfeifer >Assignee: Stephane Nicoll > Fix For: 2.3.2 > > Attachments: maven-ear-plugin-jboss-additions.patch > > > I had a little e-mail conversation with Jason van Zyl about some improvements > that I did in the Ear Plugin, he suggested I would post them here. > Following is added: > * Support for JBoss 5 > * Config for loader-repository-config (3.2, 4.0, 4.2, 5.0) > * Config for library-directory (4.2 and 5.0) > * Config for configParserClass (3.2, 4.0, 4.2, 5.0) > * Config for loaderRepositoryClass (3.2, 4.0, 4.2, 5.0) > * A couple of integration test projects for the new features > To be honest, I don't feel 100% comfortable with the way one configures the > loader-repository part in the POM-file (maybe things should be nested to > resemble the jboss-app.xml a little more), however, I didn't want to alter > the plugin too much as to not make it. > Anyway, have a look at the proposed changes and tell me whether you think > they are worth being committed to your code base. -- 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: (MEAR-102) Support for JBoss 5 as well as some missing elements
[ http://jira.codehaus.org/browse/MEAR-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166527#action_166527 ] Daniel Pfeifer commented on MEAR-102: - I am not so sure that we would break compatibility. I haven't tried it, but I believe it is possible to fetch the element as a Plexus object rather than directly invoking getValue() on it. After fetching the object, it should be possible to parse the content of the loader-repository element more accurately without breaking compatibility. If you like, I could try and change it. > Support for JBoss 5 as well as some missing elements > > > Key: MEAR-102 > URL: http://jira.codehaus.org/browse/MEAR-102 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3.2 >Reporter: Daniel Pfeifer >Assignee: Stephane Nicoll > Fix For: 2.3.2 > > Attachments: maven-ear-plugin-jboss-additions.patch > > > I had a little e-mail conversation with Jason van Zyl about some improvements > that I did in the Ear Plugin, he suggested I would post them here. > Following is added: > * Support for JBoss 5 > * Config for loader-repository-config (3.2, 4.0, 4.2, 5.0) > * Config for library-directory (4.2 and 5.0) > * Config for configParserClass (3.2, 4.0, 4.2, 5.0) > * Config for loaderRepositoryClass (3.2, 4.0, 4.2, 5.0) > * A couple of integration test projects for the new features > To be honest, I don't feel 100% comfortable with the way one configures the > loader-repository part in the POM-file (maybe things should be nested to > resemble the jboss-app.xml a little more), however, I didn't want to alter > the plugin too much as to not make it. > Anyway, have a look at the proposed changes and tell me whether you think > they are worth being committed to your code base. -- 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: (MEAR-102) Support for JBoss 5 as well as some missing elements
[ http://jira.codehaus.org/browse/MEAR-102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166532#action_166532 ] Stephane Nicoll commented on MEAR-102: -- I actually did it already but there's a bug it seems. In certain circumstances, maven just removes the element value. I am investigating. > Support for JBoss 5 as well as some missing elements > > > Key: MEAR-102 > URL: http://jira.codehaus.org/browse/MEAR-102 > Project: Maven 2.x Ear Plugin > Issue Type: Improvement >Affects Versions: 2.3.2 >Reporter: Daniel Pfeifer >Assignee: Stephane Nicoll > Fix For: 2.3.2 > > Attachments: maven-ear-plugin-jboss-additions.patch > > > I had a little e-mail conversation with Jason van Zyl about some improvements > that I did in the Ear Plugin, he suggested I would post them here. > Following is added: > * Support for JBoss 5 > * Config for loader-repository-config (3.2, 4.0, 4.2, 5.0) > * Config for library-directory (4.2 and 5.0) > * Config for configParserClass (3.2, 4.0, 4.2, 5.0) > * Config for loaderRepositoryClass (3.2, 4.0, 4.2, 5.0) > * A couple of integration test projects for the new features > To be honest, I don't feel 100% comfortable with the way one configures the > loader-repository part in the POM-file (maybe things should be nested to > resemble the jboss-app.xml a little more), however, I didn't want to alter > the plugin too much as to not make it. > Anyway, have a look at the proposed changes and tell me whether you think > they are worth being committed to your code base. -- 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: (MDEPLOY-96) Invalid Task when calling deploy:deploy-file
Invalid Task when calling deploy:deploy-file Key: MDEPLOY-96 URL: http://jira.codehaus.org/browse/MDEPLOY-96 Project: Maven 2.x Deploy Plugin Issue Type: Bug Affects Versions: 2.4 Environment: Windows, JDK 1.6.0_05, M2 2.0.10 Reporter: Daniel Wong Attachments: deploy.txt When calling deploy:deploy-file, it does not recognise my -D parameters and indicates my specified value as an invalid task. mvn deploy:deploy-file -DrepositoryId=dd-repo -Durl=http://localhost:8080/artifactory/libs-release-local -Dfile=target\TestApp3-1.0.jar Invalid task 'dd-repo': you must specify a valid lifecycle phase, or a goal in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal The artifact is successfully uploaded when specified in ... dd-repo Dimension Data Repo http://localhost:8080/artifactory/libs-releases-local ... The settings.xml is also set correctly dd-repo admin ** Attached is 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
[jira] Commented: (MDEPLOY-96) Invalid Task when calling deploy:deploy-file
[ http://jira.codehaus.org/browse/MDEPLOY-96?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166549#action_166549 ] Benjamin Bentmann commented on MDEPLOY-96: -- Did you already try a diifferent Unix/Windows box? The command line you posted works for me on WinXP with Maven 2.0.10 and Sun JDK 1.6.0_07 so there seems to be an environmental aspect. > Invalid Task when calling deploy:deploy-file > > > Key: MDEPLOY-96 > URL: http://jira.codehaus.org/browse/MDEPLOY-96 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Windows, JDK 1.6.0_05, M2 2.0.10 >Reporter: Daniel Wong > Attachments: deploy.txt > > > When calling deploy:deploy-file, it does not recognise my -D parameters and > indicates my specified value as an invalid task. > mvn deploy:deploy-file -DrepositoryId=dd-repo > -Durl=http://localhost:8080/artifactory/libs-release-local > -Dfile=target\TestApp3-1.0.jar > Invalid task 'dd-repo': you must specify a valid lifecycle phase, or a goal > in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal > The artifact is successfully uploaded when specified in > > ... > > > dd-repo > Dimension Data Repo > http://localhost:8080/artifactory/libs-releases-local > > > ... > The settings.xml is also set correctly > > dd-repo > admin > ** > > Attached is 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
[jira] Created: (MNG-4048) Allow to resolve dependencies using version range from reactor
Allow to resolve dependencies using version range from reactor -- Key: MNG-4048 URL: http://jira.codehaus.org/browse/MNG-4048 Project: Maven 2 Issue Type: Improvement Components: Dependencies Affects Versions: 2.1.0-M1, 2.0.10 Reporter: Benjamin Bentmann Currently, the reactor can only resolve dependencies that are specified using a simple version like "1.1-SNAPSHOT". If a consumer declares the dependeny version as "[1.0,)", reactor resolution is no longer possible. -- 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: (MINVOKER-82) invocation-multiple IT fails if MAVEN_OPTS is set in /etc/mavenrc
invocation-multiple IT fails if MAVEN_OPTS is set in /etc/mavenrc -- Key: MINVOKER-82 URL: http://jira.codehaus.org/browse/MINVOKER-82 Project: Maven 2.x Invoker Plugin Issue Type: Bug Reporter: Mark Struberg $> mvn clean verify -Prun-its if MAVEN_OPTS are set in /etc/mavenrc then the currently used file-encoding parameter passing via MAVEN_OPTS="-Dmaven.invoker.test=UTF-8" doesn't work and the invocation-multiple IT fails. after renaming my /etc/mavenrc all ITs passed. -- 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: (DOXIA-290) generated site.css is 0 bytes
generated site.css is 0 bytes - Key: DOXIA-290 URL: http://jira.codehaus.org/browse/DOXIA-290 Project: Maven Doxia Issue Type: Bug Affects Versions: 1.0 Reporter: Brian Fox The site.css that is generated by DOXIA-86 is empty, which causes problems during deploys in some servers. -- 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: (MSITE-386) site is generated with empty site.css file
site is generated with empty site.css file -- Key: MSITE-386 URL: http://jira.codehaus.org/browse/MSITE-386 Project: Maven 2.x Site Plugin Issue Type: Bug Components: doxia integration Affects Versions: 2.0-beta-7 Reporter: Brian Fox The default site gets created with an empty /css/site.css. In some servers, it is rejected upon deploy. The file should simply be non-empty with a comment in it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MSITE-386) site is generated with empty site.css file
[ http://jira.codehaus.org/browse/MSITE-386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox updated MSITE-386: Fix Version/s: 2.0 > site is generated with empty site.css file > -- > > Key: MSITE-386 > URL: http://jira.codehaus.org/browse/MSITE-386 > Project: Maven 2.x Site Plugin > Issue Type: Bug > Components: doxia integration >Affects Versions: 2.0-beta-7 >Reporter: Brian Fox > Fix For: 2.0 > > > The default site gets created with an empty /css/site.css. In some servers, > it is rejected upon deploy. The file should simply be non-empty with a > comment in it. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.codehaus.org/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MENFORCER-67) RequiresFileSize rule does not use the confiugred file list
RequiresFileSize rule does not use the confiugred file list
---
Key: MENFORCER-67
URL: http://jira.codehaus.org/browse/MENFORCER-67
Project: Maven 2.x Enforcer Plugin
Issue Type: Bug
Components: Standard Rules
Affects Versions: 1.0-alpha-4
Environment: Windows XP, Maven 2.0.9
Reporter: Balazs Tothfalussy
I tried to use the requireFilesSize standard rule to validate the filesize of
the build output file, my configuration:
org.apache.maven.plugins
maven-enforcer-plugin
1.0-alpha-4
enforce-ear-filesize
verify
enforce
${project.build.directory}/${project.build.finalName}.ear
500
${project.build.directory}/${project.build.finalName}.ear
I experienced, that whatever I configure in the pom of my project, nothing
happens, although Maven writes out in debug mode, that the rule has been run
I checked the code in enforcer-rules project, and in the execute method I found:
if ( files.length == 0 )
{
try
{
MavenProject project = (MavenProject) helper.evaluate(
"${project}" );
files[0] = project.getArtifact().getFile();
this.log = helper.getLog();
super.execute( helper );
}
catch ( ExpressionEvaluationException e )
{
throw new EnforcerRuleException( "Unable to retrieve the
project.", e );
}
}
This code calls super.execute only if the configured file list contains no
files, in the above configuration requiresFilesExits works, as the execute of
AbstractRequireFiles runs
So I propose a fix, which implements the else branch to call
super.execute(helper) which will call checkFile for every defined file:
if ( files.length == 0 )
{
try
{
MavenProject project = (MavenProject) helper.evaluate(
"${project}" );
files[0] = project.getArtifact().getFile();
this.log = helper.getLog();
super.execute( helper );
}
catch ( ExpressionEvaluationException e )
{
throw new EnforcerRuleException( "Unable to retrieve the
project.", e );
}
}
else {
super.execute(helper);
}
--
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: (DOXIA-290) generated site.css is 0 bytes
[ http://jira.codehaus.org/browse/DOXIA-290?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed DOXIA-290. --- Assignee: Brian Fox Resolution: Fixed Fix Version/s: 1.0 1.1 Fixed in SiteTools 1.0 > generated site.css is 0 bytes > - > > Key: DOXIA-290 > URL: http://jira.codehaus.org/browse/DOXIA-290 > Project: Maven Doxia > Issue Type: Bug >Affects Versions: 1.0 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 1.1, 1.0 > > > The site.css that is generated by DOXIA-86 is empty, which causes problems > during deploys in some servers. -- 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: (MENFORCER-31) Incorrect documentation for writing a custom rule
[
http://jira.codehaus.org/browse/MENFORCER-31?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MENFORCER-31.
--
Resolution: Fixed
> Incorrect documentation for writing a custom rule
> -
>
> Key: MENFORCER-31
> URL: http://jira.codehaus.org/browse/MENFORCER-31
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Rule API
>Affects Versions: 1.0-alpha-3
>Reporter: Ben Lidgey
>Assignee: Brian Fox
> Fix For: 1.0-beta-1
>
>
> The documentation at
> http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html has
> the wrong dependencies and code examples for creating a custom rule.
> It defines
> {code:xml}
>
> org.apache.maven.enforcer
> enforcer-api
> ${api.version}
>
> {code}
> instead of
> {code:xml}
>
> org.apache.maven.shared
> maven-enforcer-rule-api
> 1.0-alpha-2
>
> {code}
> and so the code examples are incorrect because:
> # Incorrect imports:
> #* The imports are for
> #** {{org.apache.maven.enforcer.rule.api.EnforcerRule}}
> #** {{org.apache.maven.enforcer.rule.api.EnforcerRuleException}}
> #** {{org.apache.maven.enforcer.rule.api.EnforcerRuleHelper}}
> #* instead of
> #** {{org.apache.maven.shared.enforcer.rule.api.EnforcerRule}}
> #** {{org.apache.maven.shared.enforcer.rule.api.EnforcerRuleException}}
> #** {{org.apache.maven.shared.enforcer.rule.api.EnforcerRuleHelper}}.
> #* Implementing {{import org.apache.maven.enforcer.rule.api.EnforcerRule}}
> causes the custom plugin invocation to fail with an ArrayStoreException as
> the expected type is {{import
> org.apache.maven.shared.enforcer.rule.api.EnforcerRule}} instead.
> # It shows implementing {{public String getCacheId()}}, {{public boolean
> isCacheable()}}, {{public boolean isResultValid( EnforcerRule arg0 )}} which
> are no longer needed.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (MENFORCER-58) typo in rule-api documentation
[ http://jira.codehaus.org/browse/MENFORCER-58?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-58. -- Resolution: Fixed > typo in rule-api documentation > -- > > Key: MENFORCER-58 > URL: http://jira.codehaus.org/browse/MENFORCER-58 > Project: Maven 2.x Enforcer Plugin > Issue Type: Bug > Components: Rule API >Affects Versions: 1.0-alpha-4 > Environment: N/A >Reporter: James Nord >Assignee: Brian Fox >Priority: Trivial > Fix For: 1.0-beta-1 > > > The page > http://maven.apache.org/enforcer/enforcer-api/writing-a-custom-rule.html has > a typo in the examples. > the word "retrieve" is spelt incorrectly in the sentence: > // retreive any component out of the session directly -- 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] Moved: (DOXIASITETOOLS-17) generated site.css is 0 bytes
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-17?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Lukas Theussl moved DOXIA-290 to DOXIASITETOOLS-17: --- Affects Version/s: (was: 1.0) 1.0-alpha-11 Fix Version/s: (was: 1.0) (was: 1.1) 1.1 1.0 Key: DOXIASITETOOLS-17 (was: DOXIA-290) Project: Maven Doxia Sitetools (was: Maven Doxia) > generated site.css is 0 bytes > - > > Key: DOXIASITETOOLS-17 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-17 > Project: Maven Doxia Sitetools > Issue Type: Bug >Affects Versions: 1.0-alpha-11 >Reporter: Brian Fox >Assignee: Brian Fox > Fix For: 1.0, 1.1 > > > The site.css that is generated by DOXIA-86 is empty, which causes problems > during deploys in some servers. -- 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: (MENFORCER-48) Support for a specific vendor of a JDK
[ http://jira.codehaus.org/browse/MENFORCER-48?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox closed MENFORCER-48. -- Resolution: Fixed Fix Version/s: 1.0-beta-1 docs updated > Support for a specific vendor of a JDK > -- > > Key: MENFORCER-48 > URL: http://jira.codehaus.org/browse/MENFORCER-48 > Project: Maven 2.x Enforcer Plugin > Issue Type: Improvement > Components: Standard Rules >Affects Versions: 1.0-alpha-3 > Environment: maven 2.0.9 >Reporter: David J. M. Karlsen >Assignee: Brian Fox > Fix For: 1.0-beta-1 > > > Support for specifying a vendor string (or regexp?) to match. -- 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: (MENFORCER-62) requirePluginVesions: avoid checking commandline-invoked mojos
[
http://jira.codehaus.org/browse/MENFORCER-62?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Brian Fox closed MENFORCER-62.
--
Assignee: Brian Fox
Resolution: Fixed
Fix Version/s: 1.0-beta-1
converted to a comma separated list
> requirePluginVesions: avoid checking commandline-invoked mojos
> --
>
> Key: MENFORCER-62
> URL: http://jira.codehaus.org/browse/MENFORCER-62
> Project: Maven 2.x Enforcer Plugin
> Issue Type: Bug
> Components: Standard Rules
>Affects Versions: 1.0-alpha-4
> Environment: Maven 2.0.8, 2.0.9
> Linux,Windows
>Reporter: Petr Kozelka
>Assignee: Brian Fox
> Fix For: 1.0-beta-1
>
>
> Locking plugin versions affects also mojos invoked from commandline, which is
> typically undesired.
> Besides that, such mojos cannot be even invoked with fully qualified name.
> I am using following configuration in our corporate pom, to enforce that all
> plugin versions are explicitly declared so that builds are reproducible:
> {noformat}
> ...
> ERROR: Please always define plugin
> versions.
> true
> true
> false
> false
> clean,deploy,install
> ...
> {noformat}
> With this config, I cannot use commandline mojos that are not mentioned with
> exact version.
> One such case is {{mvn idea:idea}} which ends with enforcer failure.
> *Even worse*: in this case I have {color:red}no chance to invoke{color} that
> mojo even with full qualifier - it fails as if I didn't specify version
> (maybe this part is a bug in different component):
> {noformat}
> mvn org.apache.maven.plugins:maven-idea-plugin:2.2:idea
> {noformat}
> I can theoretically add something like this to the corporate pom, and it
> really helps:
> {noformat}
> ...
>
>
> org.apache.maven.plugins:maven-idea-plugin
>
> ...
> {noformat}
> However, this approach is generally unusable, as it requires re-releasing of
> all modules descending from that pom - which is never desired and rarely
> possible.
> h3. A semi-solution idea:
> This might be difficult to fix - but if the list of unchecked plugins was
> somehow externalizable, it would solve my urgent need.
> For instance, add option {{unCheckedPluginList}} containing comma separated
> items - then I can reference a property defined in {{settings.xml}} from
> there.
> That would work for me, because settings are not subject to releasing:
> {noformat}
> ...
>
> ${my.unchecked.plugins}
> ...
> {noformat}
--
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] Moved: (DOXIASITETOOLS-18) Add an enforcer rule RequireSkinVersion
[ http://jira.codehaus.org/browse/DOXIASITETOOLS-18?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox moved MENFORCER-66 to DOXIASITETOOLS-18: -- Key: DOXIASITETOOLS-18 (was: MENFORCER-66) Project: Maven Doxia Sitetools (was: Maven 2.x Enforcer Plugin) > Add an enforcer rule RequireSkinVersion > --- > > Key: DOXIASITETOOLS-18 > URL: http://jira.codehaus.org/browse/DOXIASITETOOLS-18 > Project: Maven Doxia Sitetools > Issue Type: New Feature >Reporter: Benjamin Bentmann >Assignee: Brian Fox >Priority: Minor > Attachments: MENFORCER-35.zip, require-skin-version.patch, > require-skin-version.patch > > > Locking down versions should be possible for every artifacts that Maven might > want to download, so the site skin should be considered as well by the > Enforcer Plugin. > The patch uses the new maven-doxia-tools and hence might need to be deferred > until that gets a first release such that the Maven Enforcer Plugin's release > cycle is not blocked. -- 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] Moved: (MENFORCER-68) Add an enforcer rule RequireSkinVersion
[ http://jira.codehaus.org/browse/MENFORCER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Fox moved DOXIASITETOOLS-18 to MENFORCER-68: -- Key: MENFORCER-68 (was: DOXIASITETOOLS-18) Project: Maven 2.x Enforcer Plugin (was: Maven Doxia Sitetools) > Add an enforcer rule RequireSkinVersion > --- > > Key: MENFORCER-68 > URL: http://jira.codehaus.org/browse/MENFORCER-68 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature >Reporter: Benjamin Bentmann >Assignee: Brian Fox >Priority: Minor > Attachments: MENFORCER-35.zip, require-skin-version.patch, > require-skin-version.patch > > > Locking down versions should be possible for every artifacts that Maven might > want to download, so the site skin should be considered as well by the > Enforcer Plugin. > The patch uses the new maven-doxia-tools and hence might need to be deferred > until that gets a first release such that the Maven Enforcer Plugin's release > cycle is not blocked. -- 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: (MENFORCER-68) Add an enforcer rule RequireSkinVersion
[ http://jira.codehaus.org/browse/MENFORCER-68?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=166592#action_166592 ] Brian Fox commented on MENFORCER-68: On second thought, maybe this should be at enforcer. We have similar requests for other plugins, having rules all over the place is confusing. > Add an enforcer rule RequireSkinVersion > --- > > Key: MENFORCER-68 > URL: http://jira.codehaus.org/browse/MENFORCER-68 > Project: Maven 2.x Enforcer Plugin > Issue Type: New Feature >Reporter: Benjamin Bentmann >Assignee: Brian Fox >Priority: Minor > Attachments: MENFORCER-35.zip, require-skin-version.patch, > require-skin-version.patch > > > Locking down versions should be possible for every artifacts that Maven might > want to download, so the site skin should be considered as well by the > Enforcer Plugin. > The patch uses the new maven-doxia-tools and hence might need to be deferred > until that gets a first release such that the Maven Enforcer Plugin's release > cycle is not blocked. -- 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: (MDEPLOY-96) Invalid Task when calling deploy:deploy-file
[ http://jira.codehaus.org/browse/MDEPLOY-96?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Wong closed MDEPLOY-96. -- Resolution: Not A Bug Sorry.. this was found to be an issue with my environment - my setenv script was stripping the '=' from the commandline > Invalid Task when calling deploy:deploy-file > > > Key: MDEPLOY-96 > URL: http://jira.codehaus.org/browse/MDEPLOY-96 > Project: Maven 2.x Deploy Plugin > Issue Type: Bug >Affects Versions: 2.4 > Environment: Windows, JDK 1.6.0_05, M2 2.0.10 >Reporter: Daniel Wong > Attachments: deploy.txt > > > When calling deploy:deploy-file, it does not recognise my -D parameters and > indicates my specified value as an invalid task. > mvn deploy:deploy-file -DrepositoryId=dd-repo > -Durl=http://localhost:8080/artifactory/libs-release-local > -Dfile=target\TestApp3-1.0.jar > Invalid task 'dd-repo': you must specify a valid lifecycle phase, or a goal > in the format plugin:goal or pluginGroupId:pluginArtifactId:pluginVersion:goal > The artifact is successfully uploaded when specified in > > ... > > > dd-repo > Dimension Data Repo > http://localhost:8080/artifactory/libs-releases-local > > > ... > The settings.xml is also set correctly > > dd-repo > admin > ** > > Attached is 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
