[jira] Commented: (MNG-5030) Provide a way to get a raw XML for plugin to read
[
https://jira.codehaus.org/browse/MNG-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=275223#comment-275223
]
Evgeny Goldin commented on MNG-5030:
Another use case that can be *very* helpful to plugin authors is knowing a line
number of raw XML data. So first, plugin can be validated and
if error is found a message can be displayed specifying the line where user
made a mistake in configuring a plugin.
> Provide a way to get a raw XML for plugin to read
> -
>
> Key: MNG-5030
> URL: https://jira.codehaus.org/browse/MNG-5030
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Plugin API
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> As a plugin author I may need to read its *{{}}* slightly
> different than Maven does it. It would be very nice to get a raw XML as an
> alternative to standard fields injection.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
Both Maven 2 and 3 fail to retrieve a that is larger than
Integer.MAX_VALUE
Key: MNG-4977
URL: http://jira.codehaus.org/browse/MNG-4977
Project: Maven 2 & 3
Issue Type: Bug
Components: Dependencies
Affects Versions: 3.0.2
Reporter: Evgeny Goldin
We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
*{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
*{{2147483647}}* size to be downloaded to local maven repo, which is exactly
231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4998) Variables interpolation: dynamic in Maven 2, static in Maven 3
Variables interpolation: dynamic in Maven 2, static in Maven 3
--
Key: MNG-4998
URL: http://jira.codehaus.org/browse/MNG-4998
Project: Maven 2 & 3
Issue Type: Bug
Components: POM
Affects Versions: 3.0.2
Reporter: Evgeny Goldin
Please, see
http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-td3360336.html.
It demonstrates two examples where expression with ${variables} are
interpolated differently in Maven 2 and Maven 3: Maven 2 allows to update
and effect expressions interpolated later, Maven 3 also allows to
update but all expressions are interpolated with their old values.
I believe Maven 2 dynamic behavior is much more preferable than Maven 3
Ant-like "stickiness" to what's defined in .
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253437#action_253437
]
Evgeny Goldin commented on MNG-4977:
Hi Mark,
We use Artifactory and downloading over HTTP works Ok with it. I'll see what
headers are sent in response when Maven is making a request for .
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253438#action_253438
]
Evgeny Goldin commented on MNG-4977:
I tried to sniff the headers when dependency is sent but it's not that easy.
IEInspector HTTP Analyzer crashes, WireShark freezes and I can't see the
headers. But on one occasion before HTTP Analyzer crashed I saw the correct
response length header was sent. I'll try to see if there are other ways to see
the headers. May be you can also reproduce this problem and sniff the traffic
with better tools or better machines than mine.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253441#action_253441
]
Evgeny Goldin commented on MNG-4977:
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Goldin updated MNG-4977:
---
Attachment: 1.png
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253441#action_253441
]
Evgeny Goldin edited comment on MNG-4977 at 1/28/11 8:18 PM:
-
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent. Was running Maven 3.0.2.
was (Author: evgeny.goldin):
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253441#action_253441
]
Evgeny Goldin edited comment on MNG-4977 at 1/28/11 8:19 PM:
-
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent. Was running Maven 2.2.1< will try to reproduce it again
with 3.0.2.
was (Author: evgeny.goldin):
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent. Was running Maven 3.0.2.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253441#action_253441
]
Evgeny Goldin edited comment on MNG-4977 at 1/28/11 8:19 PM:
-
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent. Was running Maven 2.2.1, will try to reproduce it again
with 3.0.2.
was (Author: evgeny.goldin):
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent. Was running Maven 2.2.1< will try to reproduce it again
with 3.0.2.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Updated: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Goldin updated MNG-4977:
---
Attachment: 2.png
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png, 2.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-4977) Both Maven 2 and 3 fail to retrieve a that is larger than Integer.MAX_VALUE
[
http://jira.codehaus.org/browse/MNG-4977?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253441#action_253441
]
Evgeny Goldin edited comment on MNG-4977 at 1/31/11 2:26 AM:
-
Managed to grab headers again, before the sniffer crashed (see images
attached). Yes, the correct length is sent. Was running Maven 2.2.1 and 3.0.2.
was (Author: evgeny.goldin):
Managed to grab headers again, before the sniffer crashed (1.png). Yes, the
correct length is sent. Was running Maven 2.2.1, will try to reproduce it again
with 3.0.2.
> Both Maven 2 and 3 fail to retrieve a that is larger than
> Integer.MAX_VALUE
>
>
> Key: MNG-4977
> URL: http://jira.codehaus.org/browse/MNG-4977
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: Dependencies
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
> Attachments: 1.png, 2.png
>
>
> We have a *{{*.tar}}* file stored in corporate Maven repository, its size is
> *{{2.5Gb}}*. Trying to bring it with Maven (both 2 and 3) causes file of
> *{{2147483647}}* size to be downloaded to local maven repo, which is exactly
> 231-1.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-4998) Variables interpolation: dynamic in Maven 2, static in Maven 3
[
http://jira.codehaus.org/browse/MNG-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=253919#action_253919
]
Evgeny Goldin commented on MNG-4998:
Hi Luke,
I think it can work as a workaround, i.e., not having a predefined property.
But in my case I have them with nice default values which are sometimes
overridden later. But having no choice I'll give up on defaults, of course.
> Variables interpolation: dynamic in Maven 2, static in Maven 3
> --
>
> Key: MNG-4998
> URL: http://jira.codehaus.org/browse/MNG-4998
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> Please, see
> http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-td3360336.html.
> It demonstrates two examples where expression with ${variables} are
> interpolated differently in Maven 2 and Maven 3: Maven 2 allows to update
> and effect expressions interpolated later, Maven 3 also allows
> to update but all expressions are interpolated with their old
> values.
> I believe Maven 2 dynamic behavior is much more preferable than Maven 3
> Ant-like "stickiness" to what's defined in .
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-5030) Provide a way to get a raw XML for plugin to read
Provide a way to get a raw XML for plugin to read
-
Key: MNG-5030
URL: http://jira.codehaus.org/browse/MNG-5030
Project: Maven 2 & 3
Issue Type: New Feature
Components: Plugin API
Affects Versions: 3.0.2
Reporter: Evgeny Goldin
As a plugin author I may need to read its *{{}}* slightly
different than Maven does it. It would be very nice to get a raw XML as an
alternative to standard fields injection.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5030) Provide a way to get a raw XML for plugin to read
[
http://jira.codehaus.org/browse/MNG-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258043#action_258043
]
Evgeny Goldin commented on MNG-5030:
Sure. In my plugins I
[http://evgeny-goldin.com/wiki/Maven-copy-plugin#.3Cconfiguration.3E don't
like] wrapping single tag with a plural option:
{code}
data
{code}
When there is a single tag, one can specify it:
{code}
data
{code}
I achieve this by
[https://github.com/evgeny-goldin/maven-plugins/blob/0.2.1/maven-copy-plugin/src/main/groovy/com/goldin/plugins/copy/CopyMojo.groovy#L83
having]
{code}
String tag
String[] tags
{code}
in my POJO and then
[https://github.com/evgeny-goldin/maven-plugins/blob/0.2.1/maven-copy-plugin/src/main/groovy/com/goldin/plugins/copy/CopyMojo.groovy#L88
analyze] what was actually set. The problem begins when a user does a mistake
and forgets to wrap multiple tags:
{code}
data1
data2/tag>
data3
{code}
In this case Maven overrides each previous *{{}}* with the following one
so in the end when *{{execute()}}* fires only *{{data3}}* is
actually set while *{{data1}}* and *{{data2}}* are
silently ignored.
If I had *{{}}* XML I could check this case and throw an error.
In general, having _some_ way of injection control could be very helpful.
> Provide a way to get a raw XML for plugin to read
> -
>
> Key: MNG-5030
> URL: http://jira.codehaus.org/browse/MNG-5030
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Plugin API
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> As a plugin author I may need to read its *{{}}* slightly
> different than Maven does it. It would be very nice to get a raw XML as an
> alternative to standard fields injection.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Issue Comment Edited: (MNG-5030) Provide a way to get a raw XML for plugin to read
[
http://jira.codehaus.org/browse/MNG-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258043#action_258043
]
Evgeny Goldin edited comment on MNG-5030 at 2/28/11 6:20 PM:
-
Sure. In my plugins I [don't
like|http://evgeny-goldin.com/wiki/Maven-copy-plugin#.3Cconfiguration.3E]
wrapping single tag with a plural option:
{code}
data
{code}
When there is a single tag, one can specify it:
{code}
data
{code}
I achieve this by
[having|https://github.com/evgeny-goldin/maven-plugins/blob/0.2.1/maven-copy-plugin/src/main/groovy/com/goldin/plugins/copy/CopyMojo.groovy#L83]
{code}
String tag
String[] tags
{code}
in my POJO and then
[analyze|https://github.com/evgeny-goldin/maven-plugins/blob/0.2.1/maven-copy-plugin/src/main/groovy/com/goldin/plugins/copy/CopyMojo.groovy#L88]
what was actually set. The problem begins when a user does a mistake and
forgets to wrap multiple tags:
{code}
data1
data2/tag>
data3
{code}
In this case Maven overrides each previous *{{}}* with the following one
so in the end when *{{execute()}}* fires only *{{data3}}* is
actually set while *{{data1}}* and *{{data2}}* are
silently ignored.
If I had *{{}}* XML I could check this case and throw an error.
In general, having _some_ way of injection control could be very helpful.
was (Author: evgeny.goldin):
Sure. In my plugins I
[http://evgeny-goldin.com/wiki/Maven-copy-plugin#.3Cconfiguration.3E don't
like] wrapping single tag with a plural option:
{code}
data
{code}
When there is a single tag, one can specify it:
{code}
data
{code}
I achieve this by
[https://github.com/evgeny-goldin/maven-plugins/blob/0.2.1/maven-copy-plugin/src/main/groovy/com/goldin/plugins/copy/CopyMojo.groovy#L83
having]
{code}
String tag
String[] tags
{code}
in my POJO and then
[https://github.com/evgeny-goldin/maven-plugins/blob/0.2.1/maven-copy-plugin/src/main/groovy/com/goldin/plugins/copy/CopyMojo.groovy#L88
analyze] what was actually set. The problem begins when a user does a mistake
and forgets to wrap multiple tags:
{code}
data1
data2/tag>
data3
{code}
In this case Maven overrides each previous *{{}}* with the following one
so in the end when *{{execute()}}* fires only *{{data3}}* is
actually set while *{{data1}}* and *{{data2}}* are
silently ignored.
If I had *{{}}* XML I could check this case and throw an error.
In general, having _some_ way of injection control could be very helpful.
> Provide a way to get a raw XML for plugin to read
> -
>
> Key: MNG-5030
> URL: http://jira.codehaus.org/browse/MNG-5030
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Plugin API
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> As a plugin author I may need to read its *{{}}* slightly
> different than Maven does it. It would be very nice to get a raw XML as an
> alternative to standard fields injection.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (MNG-5030) Provide a way to get a raw XML for plugin to read
[
http://jira.codehaus.org/browse/MNG-5030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=258353#action_258353
]
Evgeny Goldin commented on MNG-5030:
Good, thanks! But it only works with maven 3, right? If I have an adder - Maven
2 will ignore it?
> Provide a way to get a raw XML for plugin to read
> -
>
> Key: MNG-5030
> URL: http://jira.codehaus.org/browse/MNG-5030
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: Plugin API
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> As a plugin author I may need to read its *{{}}* slightly
> different than Maven does it. It would be very nice to get a raw XML as an
> alternative to standard fields injection.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4998) Variables interpolation: dynamic in Maven 2, static in Maven 3
[
https://jira.codehaus.org/browse/MNG-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299889#comment-299889
]
Evgeny Goldin commented on MNG-4998:
Darshak, I've used
[{{}}|http://evgeny-goldin.com/wiki/Properties-maven-plugin#.3CrawProperties.3E]
in my own
[{{"properties-maven-plugin"}}|http://evgeny-goldin.com/wiki/Properties-maven-plugin].
This way default properties are also created dynamically and thus can be
overridden later. I'm very sceptic about seeing this behavior changed in Maven
3.
> Variables interpolation: dynamic in Maven 2, static in Maven 3
> --
>
> Key: MNG-4998
> URL: https://jira.codehaus.org/browse/MNG-4998
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> Please, see
> http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-td3360336.html.
> It demonstrates two examples where expression with ${variables} are
> interpolated differently in Maven 2 and Maven 3: Maven 2 allows to update
> and effect expressions interpolated later, Maven 3 also allows
> to update but all expressions are interpolated with their old
> values.
> I believe Maven 2 dynamic behavior is much more preferable than Maven 3
> Ant-like "stickiness" to what's defined in .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4998) Variables interpolation: dynamic in Maven 2, static in Maven 3
[
https://jira.codehaus.org/browse/MNG-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=299889#comment-299889
]
Evgeny Goldin edited comment on MNG-4998 at 5/28/12 2:06 PM:
-
Darshak, I've used
[{{}}|http://evgeny-goldin.com/wiki/Properties-maven-plugin#.3CrawProperties.3E]
in my own
[{{"properties-maven-plugin"}}|http://evgeny-goldin.com/wiki/Properties-maven-plugin]
to bypass this problem. This way default properties are also created
dynamically and thus can be overridden later. I'm very sceptical about seeing
this behavior changed in Maven 3.
was (Author: evgeny.goldin):
Darshak, I've used
[{{}}|http://evgeny-goldin.com/wiki/Properties-maven-plugin#.3CrawProperties.3E]
in my own
[{{"properties-maven-plugin"}}|http://evgeny-goldin.com/wiki/Properties-maven-plugin].
This way default properties are also created dynamically and thus can be
overridden later. I'm very sceptic about seeing this behavior changed in Maven
3.
> Variables interpolation: dynamic in Maven 2, static in Maven 3
> --
>
> Key: MNG-4998
> URL: https://jira.codehaus.org/browse/MNG-4998
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> Please, see
> http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-td3360336.html.
> It demonstrates two examples where expression with ${variables} are
> interpolated differently in Maven 2 and Maven 3: Maven 2 allows to update
> and effect expressions interpolated later, Maven 3 also allows
> to update but all expressions are interpolated with their old
> values.
> I believe Maven 2 dynamic behavior is much more preferable than Maven 3
> Ant-like "stickiness" to what's defined in .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] (MNG-4998) Variables interpolation: dynamic in Maven 2, static in Maven 3
[
https://jira.codehaus.org/browse/MNG-4998?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=300342#comment-300342
]
Evgeny Goldin commented on MNG-4998:
Thanks for your kind words, Darshak. Appreciate it. Let me know if you have any
ideas to make it better. So far it helped me a lot with creating dynamic Maven
properties using Groovy expressions. And sorry for off-topic, guys.
> Variables interpolation: dynamic in Maven 2, static in Maven 3
> --
>
> Key: MNG-4998
> URL: https://jira.codehaus.org/browse/MNG-4998
> Project: Maven 2 & 3
> Issue Type: Bug
> Components: POM
>Affects Versions: 3.0.2
>Reporter: Evgeny Goldin
>
> Please, see
> http://maven.40175.n5.nabble.com/Variables-interpolation-dynamic-in-Maven-2-static-in-Maven-3-td3360336.html.
> It demonstrates two examples where expression with ${variables} are
> interpolated differently in Maven 2 and Maven 3: Maven 2 allows to update
> and effect expressions interpolated later, Maven 3 also allows
> to update but all expressions are interpolated with their old
> values.
> I believe Maven 2 dynamic behavior is much more preferable than Maven 3
> Ant-like "stickiness" to what's defined in .
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.codehaus.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Created: (MNG-4220) When building a module - display it's : rather than just a
When building a module - display it's : rather than just a
--
Key: MNG-4220
URL: http://jira.codehaus.org/browse/MNG-4220
Project: Maven 2
Issue Type: Improvement
Components: Logging
Affects Versions: 2.1.0
Environment: Java 6
Reporter: Evgeny Goldin
When building a module - Maven logs the following message:
[INFO]
[INFO] Building maven-find-plugin
[INFO]task-segment: [clean, install]
[INFO]
The corresponding line in
org.apache.maven.lifecycle.DefaultLifecycleExecutor:executeTaskSegments() is
following:
getLogger().info("Building " + rootProject.getName());
How about the following:
getLogger().info("Building " + rootProject.getGroupId() + ":" +
rootProject.getArtifactId());
I'd prefer an exact : rather than just a
--
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
