[jira] [Commented] (MENFORCER-422) Support declaring external banned dependencies in an external file/URL

2022-11-18 Thread George Gastaldi (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635870#comment-17635870
 ] 

George Gastaldi commented on MENFORCER-422:
---

That's the plugin's classpath. The idea is that you bundle the enforcer rules 
in a maven artifact and add a \{{}} to that artifact in the 
maven-enforcer-plugin dependencies' element

> Support declaring external banned dependencies in an external file/URL
> --
>
> Key: MENFORCER-422
> URL: https://issues.apache.org/jira/browse/MENFORCER-422
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>Reporter: George Gastaldi
>Assignee: Peter Palaga
>Priority: Major
> Fix For: next-release
>
>
> There are some use cases where the list of banned dependencies declared in an 
> enforcer plugin configuration needs to be reused in another project. It would 
> be nice if the {{bannedDependencies}} rule could read the list of banned 
> dependencies from an external file/URL



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MENFORCER-422) Support declaring external banned dependencies in an external file/URL

2022-11-17 Thread George Gastaldi (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17635427#comment-17635427
 ] 

George Gastaldi commented on MENFORCER-422:
---

[~lfvjimisola] if you need this feature soon and cannot wait for a release 
(which god knows when it will happen - :)), you can use 
[https://github.com/gastaldi/enforcer-rules] meanwhile. Feel free to submit a 
PR supporting URLs there if you want ;)

> Support declaring external banned dependencies in an external file/URL
> --
>
> Key: MENFORCER-422
> URL: https://issues.apache.org/jira/browse/MENFORCER-422
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>Reporter: George Gastaldi
>Priority: Major
>
> There are some use cases where the list of banned dependencies declared in an 
> enforcer plugin configuration needs to be reused in another project. It would 
> be nice if the {{bannedDependencies}} rule could read the list of banned 
> dependencies from an external file/URL



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MENFORCER-422) Support declaring external banned dependencies in an external file/URL

2022-11-14 Thread George Gastaldi (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17633957#comment-17633957
 ] 

George Gastaldi commented on MENFORCER-422:
---

Hi [~lfvjimisola], 
{quote}We have a similar request and I was wondering if it could be handled 
together or it might already be. Looking at the PR and 
[docs|https://github.com/apache/maven-enforcer/pull/180/files#diff-52ca79536e0b1dc2298afdae5b7e6357c5af22eef6b5c63444237c5e189a037b]
 it seems as if it's the entire  section that can be externalized. 
However, only to a file or classpath. Or am I missing that an URL is supported?
{quote}
Because that could introduce security risks (and it would need to reuse 
existing proxy settings), I decided to not support external URLs in the initial 
implementation, but they could be added if there is a compelling use case.

Another idea is to download the external file (as a separate maven plugin - see 
[https://github.com/maven-download-plugin/maven-download-plugin])  before the 
enforcer plugin is executed. This would allow you to cache responses and avoid 
unnecessary network roundtrips - also would require no changes in this plugin. 
{quote}What is the status of this issue and PR(s)? What release can it be 
suspected to be released with? And will URLs be supported?
{quote}
[The Pull Request|https://github.com/apache/maven-enforcer/pull/180] was merged 
but I don't think there is a release in central with this feature yet. Maybe 
[~ppalaga] can answer that. Feel free to add support for URLs if you think it 
makes sense. I'd suggest to make sure the implementation reuses any existing 
proxy settings defined in settings.xml.
{quote}Are there any other plugins that use something similar to "classpath:" 
but for URLs that we could/should align with, e.g. "url:" vs "uri:"?
{quote}
I asked the same in 
[https://github.com/apache/maven-enforcer/pull/180#discussion_r943902433,] but 
apparently there is none
 

> Support declaring external banned dependencies in an external file/URL
> --
>
> Key: MENFORCER-422
> URL: https://issues.apache.org/jira/browse/MENFORCER-422
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>Reporter: George Gastaldi
>Priority: Major
>
> There are some use cases where the list of banned dependencies declared in an 
> enforcer plugin configuration needs to be reused in another project. It would 
> be nice if the {{bannedDependencies}} rule could read the list of banned 
> dependencies from an external file/URL



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MENFORCER-422) Support declaring external banned dependencies in an external file/URL

2022-08-11 Thread George Gastaldi (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17578571#comment-17578571
 ] 

George Gastaldi commented on MENFORCER-422:
---

Based on the ideas in this issue, I have created a PR in 
[https://github.com/apache/maven-enforcer/pull/180|https://github.com/apache/maven-enforcer/pull/180/]

Open for discussions. Thanks!

> Support declaring external banned dependencies in an external file/URL
> --
>
> Key: MENFORCER-422
> URL: https://issues.apache.org/jira/browse/MENFORCER-422
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>Reporter: George Gastaldi
>Priority: Major
>
> There are some use cases where the list of banned dependencies declared in an 
> enforcer plugin configuration needs to be reused in another project. It would 
> be nice if the {{bannedDependencies}} rule could read the list of banned 
> dependencies from an external file/URL



--
This message was sent by Atlassian Jira
(v8.20.10#820010)


[jira] [Commented] (MENFORCER-422) Support declaring external banned dependencies in an external file/URL

2022-06-23 Thread George Gastaldi (Jira)


[ 
https://issues.apache.org/jira/browse/MENFORCER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17558204#comment-17558204
 ] 

George Gastaldi commented on MENFORCER-422:
---

[~michael-o] that's a good idea

> Support declaring external banned dependencies in an external file/URL
> --
>
> Key: MENFORCER-422
> URL: https://issues.apache.org/jira/browse/MENFORCER-422
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>Reporter: George Gastaldi
>Priority: Major
>
> There are some use cases where the list of banned dependencies declared in an 
> enforcer plugin configuration needs to be reused in another project. It would 
> be nice if the {{bannedDependencies}} rule could read the list of banned 
> dependencies from an external file/URL



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Updated] (MENFORCER-422) Support declaring external banned dependencies in an external file/URL

2022-06-23 Thread George Gastaldi (Jira)


 [ 
https://issues.apache.org/jira/browse/MENFORCER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MENFORCER-422:
--
Summary: Support declaring external banned dependencies in an external 
file/URL  (was: Support declaring external banned dependencies in an external 
file)

> Support declaring external banned dependencies in an external file/URL
> --
>
> Key: MENFORCER-422
> URL: https://issues.apache.org/jira/browse/MENFORCER-422
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>Reporter: George Gastaldi
>Priority: Major
>
> There are some use cases where the list of banned dependencies declared in an 
> enforcer plugin configuration needs to be reused in another project. It would 
> be nice if the {{bannedDependencies}} rule could read the list of banned 
> dependencies from an external file/URL



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Updated] (MENFORCER-422) Support declaring external banned dependencies in an external file

2022-06-23 Thread George Gastaldi (Jira)


 [ 
https://issues.apache.org/jira/browse/MENFORCER-422?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MENFORCER-422:
--
Description: There are some use cases where the list of banned dependencies 
declared in an enforcer plugin configuration needs to be reused in another 
project. It would be nice if the {{bannedDependencies}} rule could read the 
list of banned dependencies from an external file/URL  (was: There are some use 
cases where the list of banned dependencies declared in an enforcer plugin 
configuration needs to be reused in another project. It would be nice if the 
\{{bannedDependencies}} rule could read the list of banned dependencies from an 
external file)

> Support declaring external banned dependencies in an external file
> --
>
> Key: MENFORCER-422
> URL: https://issues.apache.org/jira/browse/MENFORCER-422
> Project: Maven Enforcer Plugin
>  Issue Type: New Feature
>Reporter: George Gastaldi
>Priority: Major
>
> There are some use cases where the list of banned dependencies declared in an 
> enforcer plugin configuration needs to be reused in another project. It would 
> be nice if the {{bannedDependencies}} rule could read the list of banned 
> dependencies from an external file/URL



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Created] (MENFORCER-422) Support declaring external banned dependencies in an external file

2022-06-23 Thread George Gastaldi (Jira)
George Gastaldi created MENFORCER-422:
-

 Summary: Support declaring external banned dependencies in an 
external file
 Key: MENFORCER-422
 URL: https://issues.apache.org/jira/browse/MENFORCER-422
 Project: Maven Enforcer Plugin
  Issue Type: New Feature
Reporter: George Gastaldi


There are some use cases where the list of banned dependencies declared in an 
enforcer plugin configuration needs to be reused in another project. It would 
be nice if the \{{bannedDependencies}} rule could read the list of banned 
dependencies from an external file



--
This message was sent by Atlassian Jira
(v8.20.7#820007)


[jira] [Created] (MNG-7253) Relocation message is never shown

2021-09-16 Thread George Gastaldi (Jira)
George Gastaldi created MNG-7253:


 Summary: Relocation message is never shown
 Key: MNG-7253
 URL: https://issues.apache.org/jira/browse/MNG-7253
 Project: Maven
  Issue Type: Bug
  Components: Core
Affects Versions: 3.8.2
Reporter: George Gastaldi


The {{relocation}} element as defined in 
[https://maven.apache.org/ref/3.8.2/maven-model/maven.html#class_relocation] 
shows that you can specify an additional message to show the user about the 
move, such as the reason. 

However this message is never shown while the relocated artifact is being 
resolved as a dependency.

 

The message displayed instead is: 
https://github.com/apache/maven/blob/c3cf29438e3d65d6ee5c5726f8611af99d9a649a/maven-core/src/main/java/org/apache/maven/project/DefaultProjectDependenciesResolver.java#L189-L196



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-12-25 Thread George Gastaldi (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17254925#comment-17254925
 ] 

George Gastaldi commented on MNG-6979:
--

Thank you so much [~famod]!

> MavenSession.getCurrentProject may return an incorrect project in a 
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Major
> Fix For: waiting-for-feedback
>
> Attachments: MNG-6979.zip, project.zip
>
>
> Having an extension that just displays the current project, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws 
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
> 
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a 
> project that depends on a module with the same parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-08-28 Thread George Gastaldi (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17186794#comment-17186794
 ] 

George Gastaldi commented on MNG-6979:
--

[~michael-o] you mean the snippet in 
[https://github.com/vackosar/gitflow-incremental-builder/blob/23f36d0a70c5205b810c56e1247d4084b74168dc/src/main/java/com/vackosar/gitflowincrementalbuild/boundary/UnchangedProjectsRemover.java#L134-L144?|https://github.com/vackosar/gitflow-incremental-builder/blob/23f36d0a70c5205b810c56e1247d4084b74168dc/src/main/java/com/vackosar/gitflowincrementalbuild/boundary/UnchangedProjectsRemover.java#L134-L144]

I haven't run against the Maven Core ITs, but this change fixes the bug in my 
case.

> MavenSession.getCurrentProject may return an incorrect project in a 
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws 
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
> 
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a 
> project that depends on a module with the same parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-08-26 Thread George Gastaldi (Jira)


 [ 
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-6979:
-
Priority: Major  (was: Critical)

> MavenSession.getCurrentProject may return an incorrect project in a 
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws 
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
> 
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a 
> project that depends on a module with the same parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-08-25 Thread George Gastaldi (Jira)


 [ 
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-6979:
-
Issue Type: Bug  (was: Improvement)

> MavenSession.getCurrentProject may return an incorrect project in a 
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
>  Issue Type: Bug
>  Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Critical
> Attachments: project.zip
>
>
> Having an extension that just displays the current project, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws 
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
> 
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a 
> project that depends on a module with the same parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-08-25 Thread George Gastaldi (Jira)


 [ 
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-6979:
-
Priority: Critical  (was: Major)

> MavenSession.getCurrentProject may return an incorrect project in a 
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Critical
> Attachments: project.zip
>
>
> Having an extension that just displays the current project, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws 
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
> 
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a 
> project that depends on a module with the same parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-08-25 Thread George Gastaldi (Jira)


 [ 
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-6979:
-
Description: 
Having an extension that just displays the current project, like in:
{code:java}
@Singleton
@Named
public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {

@Inject
private Logger logger;

@Override
public void afterProjectsRead(MavenSession session) throws 
MavenExecutionException {
logger.info(session.getCurrentProject().toString());

session.setProjects(Collections.singletonList(session.getCurrentProject()));
}
}
{code}
Will fail to resolve the current project when executed in the root of a project 
that depends on a module with the same parent.

  was:

Having an extension that just displays the current project name, like in:

{code:java}
@Singleton
@Named
public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {

@Inject
private Logger logger;

@Override
public void afterProjectsRead(MavenSession session) throws 
MavenExecutionException {
logger.info(session.getCurrentProject().toString());

session.setProjects(Collections.singletonList(session.getCurrentProject()));
}
}
{code}

Will fail to resolve the current project when executed in the root of a project 
that depends on a module with the same parent.





> MavenSession.getCurrentProject may return an incorrect project in a 
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws 
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
> 
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a 
> project that depends on a module with the same parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-08-25 Thread George Gastaldi (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184880#comment-17184880
 ] 

George Gastaldi commented on MNG-6979:
--

The bug is here: 
https://github.com/apache/maven/blob/master/maven-core/src/main/java/org/apache/maven/execution/MavenSession.java#L86

This assignment is only valid if the execution root directory matches the 
{{MavenProject}}

> MavenSession.getCurrentProject may return an incorrect project in a 
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project name, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws 
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
> 
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a 
> project that depends on a module with the same parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-08-25 Thread George Gastaldi (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184878#comment-17184878
 ] 

George Gastaldi commented on MNG-6979:
--

This is a temporary fix for this bug

> MavenSession.getCurrentProject may return an incorrect project in a 
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project name, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws 
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
> 
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a 
> project that depends on a module with the same parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-08-25 Thread George Gastaldi (Jira)


[ 
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17184876#comment-17184876
 ] 

George Gastaldi commented on MNG-6979:
--

Please find attached a sample project with the structure described above

> MavenSession.getCurrentProject may return an incorrect project in a 
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project name, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws 
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
> 
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a 
> project that depends on a module with the same parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-08-25 Thread George Gastaldi (Jira)


 [ 
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-6979:
-
Attachment: (was: project.zip)

> MavenSession.getCurrentProject may return an incorrect project in a 
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project name, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws 
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
> 
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a 
> project that depends on a module with the same parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-08-25 Thread George Gastaldi (Jira)


 [ 
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-6979:
-
Attachment: project.zip

> MavenSession.getCurrentProject may return an incorrect project in a 
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project name, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws 
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
> 
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a 
> project that depends on a module with the same parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-08-25 Thread George Gastaldi (Jira)


 [ 
https://issues.apache.org/jira/browse/MNG-6979?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-6979:
-
Attachment: project.zip

> MavenSession.getCurrentProject may return an incorrect project in a 
> multimodule build
> -
>
> Key: MNG-6979
> URL: https://issues.apache.org/jira/browse/MNG-6979
> Project: Maven
>  Issue Type: Improvement
>  Components: core
>Affects Versions: 3.6.3
>Reporter: George Gastaldi
>Priority: Major
> Attachments: project.zip
>
>
> Having an extension that just displays the current project name, like in:
> {code:java}
> @Singleton
> @Named
> public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {
> @Inject
> private Logger logger;
> @Override
> public void afterProjectsRead(MavenSession session) throws 
> MavenExecutionException {
> logger.info(session.getCurrentProject().toString());
> 
> session.setProjects(Collections.singletonList(session.getCurrentProject()));
> }
> }
> {code}
> Will fail to resolve the current project when executed in the root of a 
> project that depends on a module with the same parent.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (MNG-6979) MavenSession.getCurrentProject may return an incorrect project in a multimodule build

2020-08-25 Thread George Gastaldi (Jira)
George Gastaldi created MNG-6979:


 Summary: MavenSession.getCurrentProject may return an incorrect 
project in a multimodule build
 Key: MNG-6979
 URL: https://issues.apache.org/jira/browse/MNG-6979
 Project: Maven
  Issue Type: Improvement
  Components: core
Affects Versions: 3.6.3
Reporter: George Gastaldi



Having an extension that just displays the current project name, like in:

{code:java}
@Singleton
@Named
public class BuildModuleSelector extends AbstractMavenLifecycleParticipant {

@Inject
private Logger logger;

@Override
public void afterProjectsRead(MavenSession session) throws 
MavenExecutionException {
logger.info(session.getCurrentProject().toString());

session.setProjects(Collections.singletonList(session.getCurrentProject()));
}
}
{code}

Will fail to resolve the current project when executed in the root of a project 
that depends on a module with the same parent.






--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MCOMPILER-320) Allow additional class path items to be given during compilation

2019-11-01 Thread George Gastaldi (Jira)


[ 
https://issues.apache.org/jira/browse/MCOMPILER-320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16964890#comment-16964890
 ] 

George Gastaldi commented on MCOMPILER-320:
---

[~rfscholte] I don't get why this issue is closed as Won't fix and the 
reluctance in merging [https://github.com/apache/maven-compiler-plugin/pull/1] .

David has clearly proven that this is necessary and this parameter has existed 
in our forked compiler plugin for years now and it works great for our use 
cases. It shouldn't impact any existing behavior. What else do you need? 

> Allow additional class path items to be given during compilation
> 
>
> Key: MCOMPILER-320
> URL: https://issues.apache.org/jira/browse/MCOMPILER-320
> Project: Maven Compiler Plugin
>  Issue Type: New Feature
>Reporter: David M. Lloyd
>Assignee: Robert Scholte
>Priority: Major
>
> At present it is very difficult to include additional class path items during 
> compilation that are not dependencies.  But this is a very useful capability, 
> especially when doing partial builds, MR JARs, JDK API stubbing, including 
> dependency items that cannot be included in any other build phase or 
> execution, etc.
> This enhancement and pull request are to request the addition of a 
> {{additionalCompilePathItems}} property in CompilerMojo or 
> AbstractCompilerMojo which includes additional filesystem paths in the 
> compilation class path.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (MNG-6389) Move the toolchains model to a separate artifactId

2018-04-04 Thread George Gastaldi (JIRA)

[ 
https://issues.apache.org/jira/browse/MNG-6389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16425967#comment-16425967
 ] 

George Gastaldi commented on MNG-6389:
--

Created a PR generating this artifact back with the same coordinates 
https://github.com/apache/maven/pull/162

> Move the toolchains model to a separate artifactId
> --
>
> Key: MNG-6389
> URL: https://issues.apache.org/jira/browse/MNG-6389
> Project: Maven
>  Issue Type: Improvement
>  Components: Toolchains
>Affects Versions: 3.5.3
>Reporter: George Gastaldi
>Priority: Major
>
> Just as maven-model and maven-settings, it would be nice to have a 
> maven-toolchains artifactId containing only the model. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] [Created] (MNG-6389) Move the toolchains model to a separate artifactId

2018-04-04 Thread George Gastaldi (JIRA)
George Gastaldi created MNG-6389:


 Summary: Move the toolchains model to a separate artifactId
 Key: MNG-6389
 URL: https://issues.apache.org/jira/browse/MNG-6389
 Project: Maven
  Issue Type: Improvement
  Components: Toolchains
Affects Versions: 3.5.3
Reporter: George Gastaldi


Just as maven-model and maven-settings, it would be nice to have a 
maven-toolchains artifactId containing only the model. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)


[jira] (MNG-5680) java.lang.UnsupportedOperationException on DefaultProjectBuilder.build

2014-12-04 Thread George Gastaldi (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358645#comment-358645
 ] 

George Gastaldi commented on MNG-5680:
--

Yes, it looks like a duplicate of MNG-5368, it should be reopened and fixed

> java.lang.UnsupportedOperationException on DefaultProjectBuilder.build
> --
>
> Key: MNG-5680
> URL: https://jira.codehaus.org/browse/MNG-5680
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap & Build
>Affects Versions: 3.2.3
>Reporter: George Gastaldi
>Priority: Critical
> Attachments: pom.xml
>
>
> {code}
> ProjectBuildingRequest request = ...
> ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
> builder.build(file, request);
> {code}
> When the build method is called, the following exception is thrown: 
> {code}
> java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> {code}
> The code should be reviewed. This is the offending code inside 
> DefaultProjectBuilder: 
> {code}
> Artifact artifact = 
> repositorySystem.createDependencyArtifact( d );
> if ( artifact == null )
> {
> map = Collections.emptyMap();
> }
> map.put( d.getManagementKey(), artifact );
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5680) java.lang.UnsupportedOperationException on DefaultProjectBuilder.build

2014-12-04 Thread George Gastaldi (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=358644#comment-358644
 ] 

George Gastaldi commented on MNG-5680:
--

I am using Fedora 20, running on Maven 3.2.3 on JDK 1.8.0_11. I am not using 
homebrew

> java.lang.UnsupportedOperationException on DefaultProjectBuilder.build
> --
>
> Key: MNG-5680
> URL: https://jira.codehaus.org/browse/MNG-5680
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap & Build
>Affects Versions: 3.2.3
>Reporter: George Gastaldi
>Priority: Critical
> Attachments: pom.xml
>
>
> {code}
> ProjectBuildingRequest request = ...
> ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
> builder.build(file, request);
> {code}
> When the build method is called, the following exception is thrown: 
> {code}
> java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> {code}
> The code should be reviewed. This is the offending code inside 
> DefaultProjectBuilder: 
> {code}
> Artifact artifact = 
> repositorySystem.createDependencyArtifact( d );
> if ( artifact == null )
> {
> map = Collections.emptyMap();
> }
> map.put( d.getManagementKey(), artifact );
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5680) java.lang.UnsupportedOperationException on DefaultProjectBuilder.build

2014-08-18 Thread George Gastaldi (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351592#comment-351592
 ] 

George Gastaldi commented on MNG-5680:
--

This error doesn't happen in 3.2.2 and earlier versions

> java.lang.UnsupportedOperationException on DefaultProjectBuilder.build
> --
>
> Key: MNG-5680
> URL: https://jira.codehaus.org/browse/MNG-5680
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap & Build
>Affects Versions: 3.2.3
>Reporter: George Gastaldi
>Priority: Critical
> Attachments: pom.xml
>
>
> {code}
> ProjectBuildingRequest request = ...
> ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
> builder.build(file, request);
> {code}
> When the build method is called, the following exception is thrown: 
> {code}
> java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> {code}
> The code should be reviewed. This is the offending code inside 
> DefaultProjectBuilder: 
> {code}
> Artifact artifact = 
> repositorySystem.createDependencyArtifact( d );
> if ( artifact == null )
> {
> map = Collections.emptyMap();
> }
> map.put( d.getManagementKey(), artifact );
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5680) java.lang.UnsupportedOperationException on DefaultProjectBuilder.build

2014-08-18 Thread George Gastaldi (JIRA)

 [ 
https://jira.codehaus.org/browse/MNG-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-5680:
-

Priority: Critical  (was: Blocker)

> java.lang.UnsupportedOperationException on DefaultProjectBuilder.build
> --
>
> Key: MNG-5680
> URL: https://jira.codehaus.org/browse/MNG-5680
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap & Build
>Affects Versions: 3.2.3
>Reporter: George Gastaldi
>Priority: Critical
> Attachments: pom.xml
>
>
> {code}
> ProjectBuildingRequest request = ...
> ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
> builder.build(file, request);
> {code}
> When the build method is called, the following exception is thrown: 
> {code}
> java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> {code}
> The code should be reviewed. This is the offending code inside 
> DefaultProjectBuilder: 
> {code}
> Artifact artifact = 
> repositorySystem.createDependencyArtifact( d );
> if ( artifact == null )
> {
> map = Collections.emptyMap();
> }
> map.put( d.getManagementKey(), artifact );
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5680) java.lang.UnsupportedOperationException on DefaultProjectBuilder.build

2014-08-18 Thread George Gastaldi (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351591#comment-351591
 ] 

George Gastaldi commented on MNG-5680:
--

To reproduce, run mvn clean install in the attached pom.xml

> java.lang.UnsupportedOperationException on DefaultProjectBuilder.build
> --
>
> Key: MNG-5680
> URL: https://jira.codehaus.org/browse/MNG-5680
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap & Build
>Affects Versions: 3.2.3
>Reporter: George Gastaldi
>Priority: Blocker
> Attachments: pom.xml
>
>
> {code}
> ProjectBuildingRequest request = ...
> ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
> builder.build(file, request);
> {code}
> When the build method is called, the following exception is thrown: 
> {code}
> java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> {code}
> The code should be reviewed. This is the offending code inside 
> DefaultProjectBuilder: 
> {code}
> Artifact artifact = 
> repositorySystem.createDependencyArtifact( d );
> if ( artifact == null )
> {
> map = Collections.emptyMap();
> }
> map.put( d.getManagementKey(), artifact );
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5680) java.lang.UnsupportedOperationException on DefaultProjectBuilder.build

2014-08-18 Thread George Gastaldi (JIRA)

 [ 
https://jira.codehaus.org/browse/MNG-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-5680:
-

Attachment: pom.xml

pom.xml to reproduce problem attached

> java.lang.UnsupportedOperationException on DefaultProjectBuilder.build
> --
>
> Key: MNG-5680
> URL: https://jira.codehaus.org/browse/MNG-5680
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap & Build
>Affects Versions: 3.2.3
>Reporter: George Gastaldi
>Priority: Blocker
> Attachments: pom.xml
>
>
> {code}
> ProjectBuildingRequest request = ...
> ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
> builder.build(file, request);
> {code}
> When the build method is called, the following exception is thrown: 
> {code}
> java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> {code}
> The code should be reviewed. This is the offending code inside 
> DefaultProjectBuilder: 
> {code}
> Artifact artifact = 
> repositorySystem.createDependencyArtifact( d );
> if ( artifact == null )
> {
> map = Collections.emptyMap();
> }
> map.put( d.getManagementKey(), artifact );
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5680) java.lang.UnsupportedOperationException on DefaultProjectBuilder.build

2014-08-18 Thread George Gastaldi (JIRA)

 [ 
https://jira.codehaus.org/browse/MNG-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-5680:
-

Description: 
{code}
ProjectBuildingRequest request = ...
ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
builder.build(file, request);
{code}

When the build method is called, the following exception is thrown: 
{code}
java.lang.UnsupportedOperationException
at java.util.AbstractMap.put(AbstractMap.java:209)
at 
org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
{code}

The code should be reviewed. This is the offending code inside 
DefaultProjectBuilder: 
{code}
Artifact artifact = 
repositorySystem.createDependencyArtifact( d );

if ( artifact == null )
{
map = Collections.emptyMap();
}

map.put( d.getManagementKey(), artifact );

{code}

  was:
{code}
ProjectBuildingRequest request = ...
ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
builder.build(file, request);
{code}

When the build method is called, the following exception is thrown: 
{code}
java.lang.UnsupportedOperationException
at java.util.AbstractMap.put(AbstractMap.java:209)
at 
org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
{code}


> java.lang.UnsupportedOperationException on DefaultProjectBuilder.build
> --
>
> Key: MNG-5680
> URL: https://jira.codehaus.org/browse/MNG-5680
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap & Build
>Affects Versions: 3.2.3
>Reporter: George Gastaldi
>Priority: Blocker
>
> {code}
> ProjectBuildingRequest request = ...
> ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
> builder.build(file, request);
> {code}
> When the build method is called, the following exception is thrown: 
> {code}
> java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> {code}
> The code should be reviewed. This is the offending code inside 
> DefaultProjectBuilder: 
> {code}
> Artifact artifact = 
> repositorySystem.createDependencyArtifact( d );
> if ( artifact == null )
> {
> map = Collections.emptyMap();
> }
> map.put( d.getManagementKey(), artifact );
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5680) java.lang.UnsupportedOperationException on DefaultProjectBuilder.build

2014-08-18 Thread George Gastaldi (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=351589#comment-351589
 ] 

George Gastaldi commented on MNG-5680:
--

Raising the priority, since DefaultProjectBuilder is unusable without fixing 
this 

> java.lang.UnsupportedOperationException on DefaultProjectBuilder.build
> --
>
> Key: MNG-5680
> URL: https://jira.codehaus.org/browse/MNG-5680
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap & Build
>Affects Versions: 3.2.3
>Reporter: George Gastaldi
>Priority: Blocker
>
> {code}
> ProjectBuildingRequest request = ...
> ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
> builder.build(file, request);
> {code}
> When the build method is called, the following exception is thrown: 
> {code}
> java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5680) java.lang.UnsupportedOperationException on DefaultProjectBuilder.build

2014-08-18 Thread George Gastaldi (JIRA)

 [ 
https://jira.codehaus.org/browse/MNG-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-5680:
-

Priority: Blocker  (was: Major)

> java.lang.UnsupportedOperationException on DefaultProjectBuilder.build
> --
>
> Key: MNG-5680
> URL: https://jira.codehaus.org/browse/MNG-5680
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap & Build
>Affects Versions: 3.2.3
>Reporter: George Gastaldi
>Priority: Blocker
>
> {code}
> ProjectBuildingRequest request = ...
> ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
> builder.build(file, request);
> {code}
> When the build method is called, the following exception is thrown: 
> {code}
> java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5680) java.lang.UnsupportedOperationException on DefaultProjectBuilder.build

2014-08-18 Thread George Gastaldi (JIRA)

 [ 
https://jira.codehaus.org/browse/MNG-5680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-5680:
-

Description: 
{code}
ProjectBuildingRequest request = ...
ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
builder.build(file, request);
{code}

When the build method is called, the following exception is thrown: 
{code}
java.lang.UnsupportedOperationException
at java.util.AbstractMap.put(AbstractMap.java:209)
at 
org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
{code}

  was:
{code}
ProjectBuildingRequest request = ...
ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
builder.build(file, request);
{code}

{code}
java.lang.UnsupportedOperationException
at java.util.AbstractMap.put(AbstractMap.java:209)
at 
org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
{code}


> java.lang.UnsupportedOperationException on DefaultProjectBuilder.build
> --
>
> Key: MNG-5680
> URL: https://jira.codehaus.org/browse/MNG-5680
> Project: Maven
>  Issue Type: Bug
>  Components: Bootstrap & Build
>Affects Versions: 3.2.3
>Reporter: George Gastaldi
>
> {code}
> ProjectBuildingRequest request = ...
> ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
> builder.build(file, request);
> {code}
> When the build method is called, the following exception is thrown: 
> {code}
> java.lang.UnsupportedOperationException
>   at java.util.AbstractMap.put(AbstractMap.java:209)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
>   at 
> org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
> {code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5680) java.lang.UnsupportedOperationException on DefaultProjectBuilder.build

2014-08-18 Thread George Gastaldi (JIRA)
George Gastaldi created MNG-5680:


 Summary: java.lang.UnsupportedOperationException on 
DefaultProjectBuilder.build
 Key: MNG-5680
 URL: https://jira.codehaus.org/browse/MNG-5680
 Project: Maven
  Issue Type: Bug
  Components: Bootstrap & Build
Affects Versions: 3.2.3
Reporter: George Gastaldi


{code}
ProjectBuildingRequest request = ...
ProjectBuilder builder = plexus.lookup(ProjectBuilder.class);
builder.build(file, request);
{code}

{code}
java.lang.UnsupportedOperationException
at java.util.AbstractMap.put(AbstractMap.java:209)
at 
org.apache.maven.project.DefaultProjectBuilder.initProject(DefaultProjectBuilder.java:815)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:174)
at 
org.apache.maven.project.DefaultProjectBuilder.build(DefaultProjectBuilder.java:118)
{code}



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5663) [regression] resolution of import-scoped transitive dependencies ignores additional repositories

2014-07-19 Thread George Gastaldi (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=350017#comment-350017
 ] 

George Gastaldi commented on MNG-5663:
--

When is 3.2.3 coming up?

> [regression] resolution of import-scoped transitive dependencies ignores 
> additional repositories
> 
>
> Key: MNG-5663
> URL: https://jira.codehaus.org/browse/MNG-5663
> Project: Maven
>  Issue Type: Bug
>  Components: Artifacts and Repositories, Dependencies
>Affects Versions: 3.2.2
>Reporter: Fred Bricon
>Assignee: Jason van Zyl
> Fix For: 3.2.3
>
>
> We (JBoss) use BOM poms extensively, notably in a number of project 
> archetypes or project examples available via JBoss Tools and Red Hat 
> Developer Studio . Some of these BOM poms (and their dependencies) are 
> available from a dedicated Maven repository 
> (http://maven.repository.redhat.com/techpreview/all/). 
> Maven 3.2.2 introduced a regression that breaks resolution of these BOM 
> dependencies, by ignoring additional repositories during artifact resolution.
> {noformat}
> http://maven.apache.org/POM/4.0.0"; 
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
>   xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 
> http://maven.apache.org/xsd/maven-4.0.0.xsd";>
>   4.0.0
>   foo
>   bar
>   0.0.1-SNAPSHOT
>   
>   
>   
>   org.jboss.bom.wfk
>   
> jboss-javaee-6.0-with-tools
>   2.4.0-redhat-2
>   pom
>   import
>   
>   
>   
>   
>   
>   redhat-techpreview-all-repository
>   
> http://maven.repository.redhat.com/techpreview/all/
>   
>   
> 
> {noformat}
> yields :
> {noformat}
> ➜  bar  mvn compile
> [INFO] Scanning for projects...
> Downloading: 
> http://maven.repository.redhat.com/techpreview/all/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.4.0-redhat-2/jboss-javaee-6.0-with-tools-2.4.0-redhat-2.pom
> Downloaded: 
> http://maven.repository.redhat.com/techpreview/all/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.4.0-redhat-2/jboss-javaee-6.0-with-tools-2.4.0-redhat-2.pom
>  (8 KB at 5.1 KB/sec)
> Downloading: 
> http://maven.repository.redhat.com/techpreview/all/org/jboss/bom/wfk/jboss-wfk-bom-parent/2.4.0-redhat-2/jboss-wfk-bom-parent-2.4.0-redhat-2.pom
> Downloaded: 
> http://maven.repository.redhat.com/techpreview/all/org/jboss/bom/wfk/jboss-wfk-bom-parent/2.4.0-redhat-2/jboss-wfk-bom-parent-2.4.0-redhat-2.pom
>  (7 KB at 6.8 KB/sec)
> Downloading: 
> http://repo.maven.apache.org/maven2/org/jboss/spec/jboss-javaee-6.0/3.0.2.Final-redhat-4/jboss-javaee-6.0-3.0.2.Final-redhat-4.pom
> [ERROR] The build could not read 1 project -> [Help 1]
> [ERROR]
> [ERROR]   The project foo:bar:0.0.1-SNAPSHOT 
> (/Users/fbricon/Dev/workspaces/runtime-hosted/bar/pom.xml) has 2 errors
> [ERROR] Non-resolvable import POM: Could not find artifact 
> org.jboss.spec:jboss-javaee-6.0:pom:3.0.2.Final-redhat-4 in central 
> (http://repo.maven.apache.org/maven2) @ 
> org.jboss.bom.wfk:jboss-javaee-6.0-with-tools:[unknown-version], 
> /Users/fbricon/Dev/maven/repository/org/jboss/bom/wfk/jboss-javaee-6.0-with-tools/2.4.0-redhat-2/jboss-javaee-6.0-with-tools-2.4.0-redhat-2.pom,
>  line 42, column 25 -> [Help 2]
> [ERROR] 'dependencies.dependency.version' for 
> javax.enterprise:cdi-api:jar is missing. @ line 27, column 15
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e 
> switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please 
> read the following articles:
> [ERROR] [Help 1] 
> http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
> [ERROR] [Help 2] 
> http://cwiki.apache.org/confluence/display/MAVEN/UnresolvableModelException
> ➜  bar
> {noformat}
> This kind of resolution used to work in maven 3.2.1 and before. The missing 
> pom is available at 
> http://maven.repository.redhat.com/techpreview/all/org/jboss/spec/jboss-javaee-6.0/3.0.2.Final-redhat-4/jboss-javaee-6.0-3.0.2.Final-redhat-4.pom



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (SUREFIRE-790) Allow forked process to access the Maven session of parent

2014-07-01 Thread George Gastaldi (JIRA)

[ 
https://jira.codehaus.org/browse/SUREFIRE-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=349045#comment-349045
 ] 

George Gastaldi commented on SUREFIRE-790:
--

We use Aether in our tests (they are not Mojos). We want to use the same 
settings provided by maven with the {{mvn -s}} parameter, however there isn't 
any system property with this info. Can we please fix this issue with Karel's 
changes? 

> Allow forked process to access the Maven session of parent
> --
>
> Key: SUREFIRE-790
> URL: https://jira.codehaus.org/browse/SUREFIRE-790
> Project: Maven Surefire
>  Issue Type: New Feature
>  Components: process forking
>Affects Versions: 2.10
>Reporter: Karel Piwko
>
> Forked process should be able to get information from a "parent process", 
> which is a Maven build execution.
> This will allow the test to access information like which pom.xml file being 
> processed, settings.xml and Maven Reactor plugin. 
> This feature is needed to any test which want to interfere with Maven 
> repositories with Aether, for instance.



--
This message was sent by Atlassian JIRA
(v6.1.6#6162)


[jira] (MNG-5498) LinkageError with Maven Plugin using Aether

2013-07-29 Thread George Gastaldi (JIRA)

 [ 
https://jira.codehaus.org/browse/MNG-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-5498:
-

Summary: LinkageError with Maven Plugin using Aether  (was: VerifyError 
with Maven Plugin using Aether)

> LinkageError with Maven Plugin using Aether
> ---
>
> Key: MNG-5498
> URL: https://jira.codehaus.org/browse/MNG-5498
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Class Loading
>Affects Versions: 3.0.5
> Environment: Maven 3.0.5
>Reporter: George Gastaldi
>
> Full description here: 
> http://stackoverflow.com/questions/17837651/verifyerror-with-maven-plugin-using-aether

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] (MNG-5498) LinkageError with Maven Plugin using Aether 1.13.1

2013-07-29 Thread George Gastaldi (JIRA)

 [ 
https://jira.codehaus.org/browse/MNG-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-5498:
-

Summary: LinkageError with Maven Plugin using Aether 1.13.1  (was: 
LinkageError with Maven Plugin using Aether)

> LinkageError with Maven Plugin using Aether 1.13.1
> --
>
> Key: MNG-5498
> URL: https://jira.codehaus.org/browse/MNG-5498
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Class Loading
>Affects Versions: 3.0.5
> Environment: Maven 3.0.5
>Reporter: George Gastaldi
>
> Full description here: 
> http://stackoverflow.com/questions/17837651/verifyerror-with-maven-plugin-using-aether

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] (MNG-5498) VerifyError with Maven Plugin using Aether

2013-07-25 Thread George Gastaldi (JIRA)

[ 
https://jira.codehaus.org/browse/MNG-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=329519#comment-329519
 ] 

George Gastaldi commented on MNG-5498:
--

For the record, the real exception was only shown when I executed maven with 
"-noverify" JVM option 

> VerifyError with Maven Plugin using Aether
> --
>
> Key: MNG-5498
> URL: https://jira.codehaus.org/browse/MNG-5498
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Class Loading
>Affects Versions: 3.0.5
> Environment: Maven 3.0.5
>Reporter: George Gastaldi
>
> Full description here: 
> http://stackoverflow.com/questions/17837651/verifyerror-with-maven-plugin-using-aether

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] (MNG-5498) VerifyError with Maven Plugin using Aether

2013-07-25 Thread George Gastaldi (JIRA)

 [ 
https://jira.codehaus.org/browse/MNG-5498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated MNG-5498:
-

Complexity: Expert  (was: Intermediate)

> VerifyError with Maven Plugin using Aether
> --
>
> Key: MNG-5498
> URL: https://jira.codehaus.org/browse/MNG-5498
> Project: Maven 2 & 3
>  Issue Type: Bug
>  Components: Class Loading
>Affects Versions: 3.0.5
> Environment: Maven 3.0.5
>Reporter: George Gastaldi
>
> Full description here: 
> http://stackoverflow.com/questions/17837651/verifyerror-with-maven-plugin-using-aether

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] (MNG-5498) VerifyError with Maven Plugin using Aether

2013-07-25 Thread George Gastaldi (JIRA)
George Gastaldi created MNG-5498:


 Summary: VerifyError with Maven Plugin using Aether
 Key: MNG-5498
 URL: https://jira.codehaus.org/browse/MNG-5498
 Project: Maven 2 & 3
  Issue Type: Bug
  Components: Class Loading
Affects Versions: 3.0.5
 Environment: Maven 3.0.5
Reporter: George Gastaldi



Full description here: 
http://stackoverflow.com/questions/17837651/verifyerror-with-maven-plugin-using-aether

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira


[jira] Created: (WAGON-263) Support Upload artifact produced in pom

2009-04-30 Thread George Gastaldi (JIRA)
Support Upload artifact produced in pom
---

 Key: WAGON-263
 URL: http://jira.codehaus.org/browse/WAGON-263
 Project: Maven Wagon
  Issue Type: New Feature
Reporter: George Gastaldi


Upload:single-file could use the artifact produced in current pom to upload 
(like deploy plugin does, but without the repository layout).

Workaround is specifying the path in  configuration.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (SCM-262) scm:tag for subversion tagging from local version of code, not directly from repository

2009-03-15 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=169742#action_169742
 ] 

George Gastaldi commented on SCM-262:
-

Olivier,

Yes, this is something that I could not figure out how to solve. 
I guess this is the right way.


> scm:tag for subversion tagging from local version of code, not directly from 
> repository
> ---
>
> Key: SCM-262
> URL: http://jira.codehaus.org/browse/SCM-262
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Reporter: Stephan Heilner
>Assignee: Olivier Lamy
> Fix For: 1.2
>
> Attachments: SvnTagCommand.patch
>
>
> In theory, you shouldn't tag or branch from a local and potentially different 
> version of the code.  From what I can tell, the scm:tag imports your existing 
> code into a new tag.  With subversion, tagging is very lightweight if you do 
> a 'svn copy trunk_url tag_url'.  The way it currently works make sense for 
> other repositories such as CVS but not for subversion.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (SCM-406) scm tag does not work with Subversion 1.5.1

2008-12-10 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=157592#action_157592
 ] 

George Gastaldi commented on SCM-406:
-

Al,

You may upgrade your server to svn 1.5, and use svn client 1.5.0 (download link 
in previous comments). This is what I am using now.

Regards,

George Gastaldi

> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error 
> occurs:
> {code}
> svn: File 
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
>  already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (SCM-262) scm:tag for subversion tagging from local version of code, not directly from repository

2008-11-30 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155903#action_155903
 ] 

George Gastaldi commented on SCM-262:
-

Yann,

I may be wrong, but  I know that there are some OS (Windows, for instance) that 
do not allow locking in SVN. 
Also,locking the entire trunk would be overkill in a big team (take any apache 
project and you will see that).

> scm:tag for subversion tagging from local version of code, not directly from 
> repository
> ---
>
> Key: SCM-262
> URL: http://jira.codehaus.org/browse/SCM-262
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Reporter: Stephan Heilner
> Fix For: future
>
>
> In theory, you shouldn't tag or branch from a local and potentially different 
> version of the code.  From what I can tell, the scm:tag imports your existing 
> code into a new tag.  With subversion, tagging is very lightweight if you do 
> a 'svn copy trunk_url tag_url'.  The way it currently works make sense for 
> other repositories such as CVS but not for subversion.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (SCM-406) scm tag does not work with Subversion 1.5.1

2008-11-27 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155642#action_155642
 ] 

George Gastaldi commented on SCM-406:
-

And how about using SVNKit (http://www.svnkit.com) as the SVN provider ?  
Or another java implementation of SVN Client ? Is that possible ?

> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error 
> occurs:
> {code}
> svn: File 
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
>  already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (SCM-262) scm:tag for subversion tagging from local version of code, not directly from repository

2008-11-27 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155599#action_155599
 ] 

George Gastaldi commented on SCM-262:
-

If applied that patch, you could not solve the worst scenario: others may 
commit on trunk, so the tag created could not really be the one that you 
checked out and ran tests/packaged locally.

What do you think about it ?

> scm:tag for subversion tagging from local version of code, not directly from 
> repository
> ---
>
> Key: SCM-262
> URL: http://jira.codehaus.org/browse/SCM-262
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Reporter: Stephan Heilner
> Fix For: future
>
>
> In theory, you shouldn't tag or branch from a local and potentially different 
> version of the code.  From what I can tell, the scm:tag imports your existing 
> code into a new tag.  With subversion, tagging is very lightweight if you do 
> a 'svn copy trunk_url tag_url'.  The way it currently works make sense for 
> other repositories such as CVS but not for subversion.  

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (SCM-406) scm tag does not work with Subversion 1.5.1

2008-11-27 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=155597#action_155597
 ] 

George Gastaldi commented on SCM-406:
-

Torsten,

If applied that patch, you could not solve the worst scenario: others may 
commit on trunk, so the tag created could not really be the one that you 
checked out and ran tests/packaged locally. 

What do you guys think about it ?

> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error 
> occurs:
> {code}
> svn: File 
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
>  already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (SCM-406) scm tag does not work with Subversion 1.5.1

2008-11-17 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/SCM-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=154540#action_154540
 ] 

George Gastaldi commented on SCM-406:
-

Kalle, I upgraded to 1.5.4 and the problem was not solved.

> scm tag does not work with Subversion 1.5.1
> ---
>
> Key: SCM-406
> URL: http://jira.codehaus.org/browse/SCM-406
> Project: Maven SCM
>  Issue Type: Bug
>  Components: maven-scm-provider-svn
>Affects Versions: 1.0
>Reporter: James William Dumay
> Fix For: 1.1.1
>
>
> scm:checkin does not work with Subversion 1.5.1
> On release:perform (which I assume calls scm:checkin) the following error 
> occurs:
> {code}
> svn: File 
> '/svn/private/atlassian/confluence/tags/confluence-project-2.10-m1/conf-acceptance-test/pom.xml'
>  already exists
> {code}
> Using subversion 1.4.x is a good enough workaround.

-- 
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: (MSITE-211) Can't deploy site using site:deploy due to a ProxyHTTP error

2008-03-07 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/MSITE-211?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_126458
 ] 

George Gastaldi commented on MSITE-211:
---

When will this be fixed ?

> Can't deploy site using site:deploy due to a ProxyHTTP error
> 
>
> Key: MSITE-211
> URL: http://jira.codehaus.org/browse/MSITE-211
> Project: Maven 2.x Site Plugin
>  Issue Type: Bug
>  Components: site:deploy
>Affects Versions: 2.0-beta-5
> Environment: linux ubuntu dapper drake
>Reporter: Elid OR
>Priority: Blocker
> Attachments: MSITE-211.patch
>
>
> When I execute the site deployment (with version that comes with maven 2.0.5) 
> "mvn site:deploy " I got an error see log en debug mode below. This used to 
> work correctly with maven version 2.04 (so maybe site plugin version 
> 2.0-beta-4 :
> [INFO] 
> 
> [ERROR] BUILD ERROR
> [INFO] 
> 
> [INFO] Error uploading site
> Embedded error: Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy 
> error: Forbidden
> [INFO] 
> 
> [DEBUG] Trace
> org.apache.maven.lifecycle.LifecycleExecutionException: Error uploading site
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal(DefaultLifecycleExecutor.java:493)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:311)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:143)
> at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:330)
> at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:123)
> at org.apache.maven.cli.MavenCli.main(MavenCli.java:272)
> 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:324)
> 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.MojoExecutionException: Error uploading 
> site
> at 
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:184)
> at 
> org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:420)
> at 
> org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
> ... 16 more
> Caused by: org.apache.maven.wagon.authentication.AuthenticationException: 
> Cannot connect. Reason: ProxyHTTP: java.io.IOException: proxy error: 
> Forbidden
> at 
> org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:186)
> at 
> org.apache.maven.wagon.AbstractWagon.connect(AbstractWagon.java:143)
> at 
> org.apache.maven.plugins.site.SiteDeployMojo.execute(SiteDeployMojo.java:149)
> ... 18 more
> Caused by: com.jcraft.jsch.JSchException: ProxyHTTP: java.io.IOException: 
> proxy error: Forbidden
> at com.jcraft.jsch.ProxyHTTP.connect(Unknown Source)
> at com.jcraft.jsch.Session.connect(Unknown Source)
> at com.jcraft.jsch.Session.connect(Unknown Source)
> at 
> org.apache.maven.wagon.providers.ssh.jsch.AbstractJschWagon.openConnection(AbstractJschWagon.java:158)
> ... 20 more
> [INFO] 
> 
> [INFO] Total time: 3 seconds
> [INFO] Finished at: Wed Feb 21 12:00:41 CET 2007
> [INFO] Final Memory: 3M/7M
> [INFO] 
> 

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (MSITE-260) Bundle for Portuguese-BR is not correct

2007-10-16 Thread George Gastaldi (JIRA)
Bundle for Portuguese-BR is not correct
---

 Key: MSITE-260
 URL: http://jira.codehaus.org/browse/MSITE-260
 Project: Maven 2.x Site Plugin
  Issue Type: Bug
  Components: internationalization, localization
Reporter: George Gastaldi
Priority: Minor
 Attachments: site-plugin_pt_BR.properties

Since portuguese-brazilian contains special characters, unicode must be used 
for file site-plugin_pt_BR.properties. 

Attached is the corrected file.Please replace 
http://svn.apache.org/repos/asf/maven/plugins/trunk/maven-site-plugin/src/main/resources/site-plugin_pt_BR.properties
 with this

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (CONTINUUM-1499) Translate to Brazilian Portuguese

2007-10-07 Thread George Gastaldi (JIRA)

 [ 
http://jira.codehaus.org/browse/CONTINUUM-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated CONTINUUM-1499:
---

Attachment: CONTINUUM-1499-gastaldi-3.patch

Another Patch to strings (Better organization and fixes some strings)

> Translate to Brazilian Portuguese
> -
>
> Key: CONTINUUM-1499
> URL: http://jira.codehaus.org/browse/CONTINUUM-1499
> Project: Continuum
>  Issue Type: Sub-task
>  Components: Web - UI
>Reporter: George Gastaldi
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 1.1-beta-4
>
> Attachments: CONTINUUM-1499-gastaldi-2.patch, 
> CONTINUUM-1499-gastaldi-3.patch, CONTINUUM-1499-gastaldi.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




[jira] Created: (CONTINUUM-1514) Legend is hardcoded

2007-10-07 Thread George Gastaldi (JIRA)
Legend is hardcoded
---

 Key: CONTINUUM-1514
 URL: http://jira.codehaus.org/browse/CONTINUUM-1514
 Project: Continuum
  Issue Type: Improvement
  Components: Web - UI
Affects Versions: 1.1-beta-3
Reporter: George Gastaldi
Priority: Trivial


The legend is hardcoded 
(\continuum-webapp\src\main\webapp\WEB-INF\jsp\navigations\Menu.jsp). Strings 
as "Build Now", etc should be moved to continuum.properties. 

-- 
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: (MWAR-104) handle zip dependencies in war plugin

2007-10-06 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/MWAR-104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109194
 ] 

George Gastaldi commented on MWAR-104:
--

When will this issue be resolved ? This is the last issue for 2.1-alpha-1 
release

> handle zip dependencies in war plugin
> -
>
> Key: MWAR-104
> URL: http://jira.codehaus.org/browse/MWAR-104
> Project: Maven 2.x War Plugin
>  Issue Type: Improvement
> Environment: all
>Reporter: Olivier Lamy
>Assignee: Stephane Nicoll
> Fix For: 2.1-alpha-1
>
> Attachments: foobar.zip, MWAR-104
>
>
> As MNG-1683 has been applied, the zip artifact must be handled in the war 
> 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




[jira] Created: (CONTINUUM-1513) Release does not work when maven 2 executable is not on PATH

2007-10-05 Thread George Gastaldi (JIRA)
Release does not work when maven 2 executable is not on PATH


 Key: CONTINUUM-1513
 URL: http://jira.codehaus.org/browse/CONTINUUM-1513
 Project: Continuum
  Issue Type: Bug
  Components: Environmental
Affects Versions: 1.1-beta-3
 Environment: Maven 2 executable NOT ON PATH, just on profile
Reporter: George Gastaldi
 Attachments: wrapper.20071005.log

When trying to release a project, when maven 2 is not on the path, the 
following error occurs:

{code}
[INFO] Updating local copy against the scm...
[INFO] Verifying that there are no local modifications...
[INFO] Checking dependencies and plugins for snapshots ...
[INFO] Transforming 'aarh-bridge_visao'...
[INFO] Not generating release POMs
[ERROR] org.apache.maven.shared.release.ReleaseExecutionException: Maven 
execution failed, exit code: '127'
at 
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:66)
at 
org.apache.maven.shared.release.phase.RunPrepareGoalsPhase.execute(RunPrepareGoalsPhase.java:42)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepare(DefaultReleaseManager.java:194)
at 
org.apache.maven.shared.release.DefaultReleaseManager.prepareWithResult(DefaultReleaseManager.java:107)
at 
org.apache.maven.continuum.release.executors.PrepareReleaseTaskExecutor.execute(PrepareReleaseTaskExecutor.java:43)
at 
org.apache.maven.continuum.release.executors.AbstractReleaseTaskExecutor.executeTask(AbstractReleaseTaskExecutor.java:67)
at 
org.codehaus.plexus.taskqueue.execution.ThreadedTaskQueueExecutor$ExecutorRunnable$1.run(ThreadedTaskQueueExecutor.java:116)
at 
edu.emory.mathcs.backport.java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:442)
at 
edu.emory.mathcs.backport.java.util.concurrent.FutureTask.run(FutureTask.java:176)
at 
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:665)
at 
edu.emory.mathcs.backport.java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:690)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.apache.maven.shared.release.exec.MavenExecutorException: Maven 
execution failed, exit code: '127'
at 
org.apache.maven.shared.release.exec.ForkedMavenExecutor.executeGoals(ForkedMavenExecutor.java:103)
at 
org.apache.maven.shared.release.exec.ForkedMavenExecutor.executeGoals(ForkedMavenExecutor.java:121)
at 
org.apache.maven.shared.release.phase.AbstractRunGoalsPhase.execute(AbstractRunGoalsPhase.java:59)
... 11 more
{code}

It appears that the continuum release feature do not respect the build profile 
for maven 2.
Attached is the log file.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (CONTINUUM-1512) Constraint Violation Exception when deleting an empty group

2007-10-05 Thread George Gastaldi (JIRA)
Constraint Violation Exception when deleting an empty group
---

 Key: CONTINUUM-1512
 URL: http://jira.codehaus.org/browse/CONTINUUM-1512
 Project: Continuum
  Issue Type: Bug
  Components: Database, Web - UI
Affects Versions: 1.1-beta-3
Reporter: George Gastaldi
Priority: Minor


Steps to reproduce the problem:

1) Create a Group.
2) Add a Maven 2 Project on it.
3) Force Build
4) Create another Group
5) Move the project to the other group
6) Try to delete the old group (The exception will be raised, complaining that 
there are )

Workarounds: 

Delete all the build history for the moved projects before attempting to delete 
the old group.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (CONTINUUM-1512) Constraint Violation Exception when deleting an empty group

2007-10-05 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/CONTINUUM-1512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109131
 ] 

George Gastaldi commented on CONTINUUM-1512:


...
6) Try to delete the old group (The exception will be raised, complaining that 
there are some build history associated to the group)

> Constraint Violation Exception when deleting an empty group
> ---
>
> Key: CONTINUUM-1512
> URL: http://jira.codehaus.org/browse/CONTINUUM-1512
> Project: Continuum
>  Issue Type: Bug
>  Components: Database, Web - UI
>Affects Versions: 1.1-beta-3
>Reporter: George Gastaldi
>Priority: Minor
>
> Steps to reproduce the problem:
> 1) Create a Group.
> 2) Add a Maven 2 Project on it.
> 3) Force Build
> 4) Create another Group
> 5) Move the project to the other group
> 6) Try to delete the old group (The exception will be raised, complaining 
> that there are )
> Workarounds: 
> Delete all the build history for the moved projects before attempting to 
> delete the old group.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (CONTINUUM-1130) can't delete default project group

2007-10-04 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/CONTINUUM-1130?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_109076
 ] 

George Gastaldi commented on CONTINUUM-1130:


It is still a problem in version 1.1-beta-3.

> can't delete default project group
> --
>
> Key: CONTINUUM-1130
> URL: http://jira.codehaus.org/browse/CONTINUUM-1130
> Project: Continuum
>  Issue Type: Bug
>  Components: Core system, Database
>Affects Versions: 1.1-alpha-1
>Reporter: Brett Porter
> Fix For: Future
>
>
> I don't really want/need this - but after deleting it, it keeps coming back

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (CONTINUUM-1499) Translate to Brazilian Portuguese

2007-10-04 Thread George Gastaldi (JIRA)

 [ 
http://jira.codehaus.org/browse/CONTINUUM-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated CONTINUUM-1499:
---

Attachment: CONTINUUM-1499-gastaldi-2.patch

Here comes the patch !! Some strings were corrected on 
Continuum_pt_BR.properties too

> Translate to Brazilian Portuguese
> -
>
> Key: CONTINUUM-1499
> URL: http://jira.codehaus.org/browse/CONTINUUM-1499
> Project: Continuum
>  Issue Type: Sub-task
>  Components: Web - UI
>Reporter: George Gastaldi
>Assignee: Olivier Lamy
>Priority: Minor
> Fix For: 1.1-beta-4
>
> Attachments: CONTINUUM-1499-gastaldi-2.patch, 
> CONTINUUM-1499-gastaldi.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




[jira] Created: (CONTINUUM-1508) NullPointerException when adding an empty installation to a profile

2007-10-03 Thread George Gastaldi (JIRA)
NullPointerException when adding an empty installation to a profile
---

 Key: CONTINUUM-1508
 URL: http://jira.codehaus.org/browse/CONTINUUM-1508
 Project: Continuum
  Issue Type: Bug
  Components: Web interface
Affects Versions: 1.1-beta-3
Reporter: George Gastaldi
Priority: Minor


Steps to reproduce the problem:
1) Install Continuum;
2) Go to "Profiles"
3) Create a new profile
4) Click the "Add" button (is empty, no installation defined).

BTW, Profiles must be enabled only when an installation exist

StackTrace:
{code}
java.lang.NullPointerException
at 
org.apache.maven.continuum.profile.DefaultProfileService.addInstallationInProfile(DefaultProfileService.java:180)
at 
org.apache.maven.continuum.web.action.admin.ProfileAction.addInstallation(ProfileAction.java:155)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
at java.lang.reflect.Method.invoke(Unknown Source)
at 
com.opensymphony.xwork.DefaultActionInvocation.invokeAction(DefaultActionInvocation.java:358)
at 
com.opensymphony.xwork.DefaultActionInvocation.invokeActionOnly(DefaultActionInvocation.java:218)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:192)
at 
org.codehaus.plexus.xwork.interceptor.PlexusReleaseComponentInterceptor.intercept(PlexusReleaseComponentInterceptor.java:69)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
at 
com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
at 
com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
org.apache.maven.continuum.web.interceptor.ForceContinuumConfigurationInterceptor.intercept(ForceContinuumConfigurationInterceptor.java:72)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
org.codehaus.plexus.redback.xwork.interceptor.PolicyEnforcementInterceptor.intercept(PolicyEnforcementInterceptor.java:118)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
org.codehaus.plexus.redback.xwork.interceptor.SecureActionInterceptor.intercept(SecureActionInterceptor.java:159)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
org.codehaus.plexus.xwork.interceptor.ExceptionMappingInterceptor.intercept(ExceptionMappingInterceptor.java:58)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
com.opensymphony.xwork.interceptor.DefaultWorkflowInterceptor.doIntercept(DefaultWorkflowInterceptor.java:175)
at 
com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
com.opensymphony.xwork.validator.ValidationInterceptor.doIntercept(ValidationInterceptor.java:115)
at 
com.opensymphony.xwork.interceptor.MethodFilterInterceptor.intercept(MethodFilterInterceptor.java:86)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
com.opensymphony.webwork.interceptor.FileUploadInterceptor.intercept(FileUploadInterceptor.java:174)
at 
com.opensymphony.xwork.DefaultActionInvocation.invoke(DefaultActionInvocation.java:190)
at 
com.opensymphony.xwork.interceptor.AroundInterceptor.intercept(AroundInterceptor.java:31)
at 
com.opensymphony.xwork.De

[jira] Updated: (CONTINUUM-1499) Translate to Brazilian Portuguese

2007-09-28 Thread George Gastaldi (JIRA)

 [ 
http://jira.codehaus.org/browse/CONTINUUM-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated CONTINUUM-1499:
---

Attachment: CONTINUUM-1499-gastaldi.patch

patch included

> Translate to Brazilian Portuguese
> -
>
> Key: CONTINUUM-1499
> URL: http://jira.codehaus.org/browse/CONTINUUM-1499
> Project: Continuum
>  Issue Type: Sub-task
>  Components: Web - UI
>Reporter: George Gastaldi
>Priority: Minor
> Attachments: CONTINUUM-1499-gastaldi.patch, 
> Continuum_pt_BR.properties, PTBR.zip
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (CONTINUUM-1499) Translate to Brazilian Portuguese

2007-09-28 Thread George Gastaldi (JIRA)

 [ 
http://jira.codehaus.org/browse/CONTINUUM-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated CONTINUUM-1499:
---

Attachment: Continuum_pt_BR.properties
PTBR.zip

PTBR contains the Files on the action* folder
The properties is a beggining for PT_BR. (Not finished)



> Translate to Brazilian Portuguese
> -
>
> Key: CONTINUUM-1499
> URL: http://jira.codehaus.org/browse/CONTINUUM-1499
> Project: Continuum
>  Issue Type: Sub-task
>  Components: Web - UI
>Reporter: George Gastaldi
>Priority: Minor
> Attachments: Continuum_pt_BR.properties, PTBR.zip
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (CONTINUUM-1499) Translate to Brazilian Portuguese

2007-09-28 Thread George Gastaldi (JIRA)
Translate to Brazilian Portuguese
-

 Key: CONTINUUM-1499
 URL: http://jira.codehaus.org/browse/CONTINUUM-1499
 Project: Continuum
  Issue Type: Sub-task
  Components: Web - UI
Reporter: George Gastaldi
Priority: Minor




-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Updated: (CONTINUUM-546) Translate Continuum interface

2007-09-28 Thread George Gastaldi (JIRA)

 [ 
http://jira.codehaus.org/browse/CONTINUUM-546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi updated CONTINUUM-546:
--

Attachment: Continuum_pt_BR.properties

I candidate myself for the brazilian-portuguese version. Here is the file

> Translate Continuum interface
> -
>
> Key: CONTINUUM-546
> URL: http://jira.codehaus.org/browse/CONTINUUM-546
> Project: Continuum
>  Issue Type: Improvement
>  Components: Web interface
>Reporter: Emmanuel Venisse
> Fix For: Future
>
> Attachments: Continuum_pt_BR.properties
>
>


-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Closed: (CONTINUUM-1498) Provide a live demo for Continuum

2007-09-28 Thread George Gastaldi (JIRA)

 [ 
http://jira.codehaus.org/browse/CONTINUUM-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi closed CONTINUUM-1498.
--

Resolution: Fixed

Demo live: http://vmbuild.apache.org/continuum/

> Provide a live demo for Continuum
> -
>
> Key: CONTINUUM-1498
> URL: http://jira.codehaus.org/browse/CONTINUUM-1498
> Project: Continuum
>  Issue Type: Wish
>Reporter: George Gastaldi
>Priority: Minor
>
> Continuum should be installed on a live server, so that users may check the 
> latest features without downloading/installing 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] Closed: (CONTINUUM-1497) Continuum should support multiple languages

2007-09-28 Thread George Gastaldi (JIRA)

 [ 
http://jira.codehaus.org/browse/CONTINUUM-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi closed CONTINUUM-1497.
--

Resolution: Duplicate

Duplicate of CONTINUUM-546

> Continuum should support multiple languages
> ---
>
> Key: CONTINUUM-1497
> URL: http://jira.codehaus.org/browse/CONTINUUM-1497
> Project: Continuum
>  Issue Type: Wish
>  Components: Web - UI
>Affects Versions: 1.1-beta-3
>Reporter: George Gastaldi
>Priority: Minor
>
> Continuum should support multiple languages (English, German, 
> Portuguese-Brazilian, etc.. ) .

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (CONTINUUM-1498) Provide a live demo for Continuum

2007-09-28 Thread George Gastaldi (JIRA)
Provide a live demo for Continuum
-

 Key: CONTINUUM-1498
 URL: http://jira.codehaus.org/browse/CONTINUUM-1498
 Project: Continuum
  Issue Type: Wish
Reporter: George Gastaldi
Priority: Minor


Continuum should be installed on a live server, so that users may check the 
latest features without downloading/installing 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] Commented: (CONTINUUM-1497) Continuum should support multiple languages

2007-09-28 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/CONTINUUM-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108557
 ] 

George Gastaldi commented on CONTINUUM-1497:


I can translate for Brazilian-Portuguese. Just need the english properties file.

> Continuum should support multiple languages
> ---
>
> Key: CONTINUUM-1497
> URL: http://jira.codehaus.org/browse/CONTINUUM-1497
> Project: Continuum
>  Issue Type: Wish
>  Components: Web - UI
>Affects Versions: 1.1-beta-3
>Reporter: George Gastaldi
>Priority: Minor
>
> Continuum should support multiple languages (English, German, 
> Portuguese-Brazilian, etc.. ) .

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (CONTINUUM-1497) Continuum should support multiple languages

2007-09-28 Thread George Gastaldi (JIRA)
Continuum should support multiple languages
---

 Key: CONTINUUM-1497
 URL: http://jira.codehaus.org/browse/CONTINUUM-1497
 Project: Continuum
  Issue Type: Wish
  Components: Web - UI
Affects Versions: 1.1-beta-3
Reporter: George Gastaldi
Priority: Minor


Continuum should support multiple languages (English, German, 
Portuguese-Brazilian, etc.. ) .

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (CONTINUUM-670) State of a project

2007-09-21 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/CONTINUUM-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_108001
 ] 

George Gastaldi commented on CONTINUUM-670:
---

This is surely a "must" for continuum

> State of a project
> --
>
> Key: CONTINUUM-670
> URL: http://jira.codehaus.org/browse/CONTINUUM-670
> Project: Continuum
>  Issue Type: New Feature
>  Components: Core system
>Reporter: Reinhard Spisser
> Fix For: Future
>
>
> I suggest to introduce states of the projects: active, disabled and archived
> - active: continuum will check for modifications and build it
> - disabled: the project remains on the same "project list" as the
> active project (the continuum homepage), but the project links are
> greyed out. Continuum will not check for modifications. Projects can
> be enabled again to become active.
> - archived: the project is not show on the main project list, but on a
> "Archived Projects" tab (or something similar). These projects will
> not be build, but build history will remain.
> With this states, someone could write a program that disables a
> project if no commits were done in the last x weeks and archives a
> project if no commits were done in the last x months. Also, if a
> commit is done in a disabled project then the project is enabled
> again.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (CONTINUUM-1486) Show the type of artifact produced and allow downloads of artifacts

2007-09-21 Thread George Gastaldi (JIRA)
Show the type of artifact produced and allow downloads of artifacts
---

 Key: CONTINUUM-1486
 URL: http://jira.codehaus.org/browse/CONTINUUM-1486
 Project: Continuum
  Issue Type: Wish
  Components: Web interface
Affects Versions: 1.1-beta-2
Reporter: George Gastaldi


Each project should show the type of artifact produced as a image (JAR, WAR, 
EAR, ZIP, etc...)  and if possible, a link to download from the repository via 
continuum.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (CONTINUUM-1479) Test Notifier Mechanism

2007-09-20 Thread George Gastaldi (JIRA)
Test Notifier Mechanism
---

 Key: CONTINUUM-1479
 URL: http://jira.codehaus.org/browse/CONTINUUM-1479
 Project: Continuum
  Issue Type: Wish
  Components: Notification Subsystem
Affects Versions: 1.1-beta-2
Reporter: George Gastaldi
Priority: Trivial


Provide a button (or something) to allow user testing of notification (MSN, 
Email, etc..) and check for service availability (if 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] Created: (CONTINUUM-1478) Place a "Check All / Check None" checkbox for projects

2007-09-20 Thread George Gastaldi (JIRA)
Place a "Check All / Check None" checkbox for projects
--

 Key: CONTINUUM-1478
 URL: http://jira.codehaus.org/browse/CONTINUUM-1478
 Project: Continuum
  Issue Type: Improvement
  Components: Web interface
Reporter: George Gastaldi
Priority: Trivial


To select and de-select projects for building.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (CONTINUUM-1477) Member group list should be ordered by build order

2007-09-20 Thread George Gastaldi (JIRA)
Member group list should be ordered by build order 
---

 Key: CONTINUUM-1477
 URL: http://jira.codehaus.org/browse/CONTINUUM-1477
 Project: Continuum
  Issue Type: Improvement
  Components: Web interface
Affects Versions: 1.1-beta-2
Reporter: George Gastaldi
Priority: Trivial


The member group list should be ordered by build order, so that is possible to 
know the sequence of build when "Build All Projects" is selected.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Commented: (CONTINUUM-1253) Allow to deploy artifact without timestamps

2007-09-16 Thread George Gastaldi (JIRA)

[ 
http://jira.codehaus.org/browse/CONTINUUM-1253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_107525
 ] 

George Gastaldi commented on CONTINUUM-1253:


This occurs in 1.1-beta 2  also. mvn deploy does not work. Please, see this 
ASAP.

> Allow to deploy artifact without timestamps
> ---
>
> Key: CONTINUUM-1253
> URL: http://jira.codehaus.org/browse/CONTINUUM-1253
> Project: Continuum
>  Issue Type: New Feature
>  Components: Core system, Integration - Maven 2, Web - UI
>Affects Versions: 1.0.3
>Reporter: Damian Golda
>Assignee: Emmanuel Venisse
>
> In our organisation we don't use unique names of jars in repository. So we 
> have set uniqueVersion to false in pom.xml:
> 
> 
>   maven2-repo
>   Maven2 Repository
>   file://${repoPath}
>   false
> 
>   
> And it works while running mvn from command line.
> But when we build project from continuum, it deploys built jar into 
> Deployment Repository Directory and unfortunately always adds timestamps to 
> filename.
> The reason is that in 
> org.apache.maven.continuum.core.action.DeployArtifactContinuumAction is 
> specified "true" as uniqueVersion parameter of 
> ArtifactRepositoryFactory.createDeploymentArtifactRepository method:
>  ArtifactRepository deploymentRepository =
> 
> artifactRepositoryFactory.createDeploymentArtifactRepository( 
> "deployment-repository", location,
>   
> repositoryLayout, true );
> PLEASE, change it, and allow to set required behavior by admin in Edit 
> Configuration page. 
> We have strange problems with hundreds of fat jars in repository, caused by 
> unique names of them.
> I think it's needed to:
> -add to Configuration new field, for example DeployWithUniqueVersion 
> -change DeployArtifactContinuumAction, to uset that field instead of 
> hard-coded true
> -add new field to EditContinuumConfiguration.vm 
> -add some code to ConfigurationAction and InitializationChecker

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (CONTINUUM-1427) Place a drop down list right next to the 'Build all projects' button

2007-09-02 Thread George Gastaldi (JIRA)
Place a drop down list right next to the 'Build all projects' button


 Key: CONTINUUM-1427
 URL: http://jira.codehaus.org/browse/CONTINUUM-1427
 Project: Continuum
  Issue Type: Improvement
Reporter: George Gastaldi


Show in the 'Group Actions' section, so only group-level build definitions 
should be shown.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Closed: (CONTINUUM-1426) Provide RSS Feeds for build monitoring

2007-09-02 Thread George Gastaldi (JIRA)

 [ 
http://jira.codehaus.org/browse/CONTINUUM-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

George Gastaldi closed CONTINUUM-1426.
--

Resolution: Duplicate

Duplicate of CONTINUUM-418

> Provide RSS Feeds for build monitoring
> --
>
> Key: CONTINUUM-1426
> URL: http://jira.codehaus.org/browse/CONTINUUM-1426
> Project: Continuum
>  Issue Type: Wish
>  Components: Notification Subsystem
>Reporter: George Gastaldi
>
> Provide RSS Feeds for build monitoring. User may monitor build activities 
> without requiring a mail account.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (CONTINUUM-1426) Provide RSS Feeds for build monitoring

2007-09-02 Thread George Gastaldi (JIRA)
Provide RSS Feeds for build monitoring
--

 Key: CONTINUUM-1426
 URL: http://jira.codehaus.org/browse/CONTINUUM-1426
 Project: Continuum
  Issue Type: Wish
  Components: Notification Subsystem
Reporter: George Gastaldi


Provide RSS Feeds for build monitoring. User may monitor build activities 
without requiring a mail account.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: 
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] Created: (CONTINUUM-1425) URL in Company Pom should open in a new Window

2007-09-02 Thread George Gastaldi (JIRA)
URL in Company Pom should open in a new Window
--

 Key: CONTINUUM-1425
 URL: http://jira.codehaus.org/browse/CONTINUUM-1425
 Project: Continuum
  Issue Type: Improvement
  Components: Web - UI
Reporter: George Gastaldi
Priority: Trivial


The URL provided in the company POM should open in a new browser window.

-- 
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