Re: Mailing list links broken?

[Jason Dillon]

Links look better now.  Thanks!

—jason


On July 28, 2018 at 2:05:02 AM, Karl Heinz Marbaise (khmarba...@gmx.de) wrote:

Hi Jason,  

On 27/07/18 23:41, Jason Dillon wrote:  
> On this page:  
>  
> https://maven.apache.org/mailing-lists.html  
>  
> It looks like the sub/unsub/post links like:  
>  
> https://maven.apache.org/users-subscr...@maven.apache.org  
> https://maven.apache.org/users-unsubscr...@maven.apache.org  
> https://maven.apache.org/us...@maven.apache.org  
>  
> Are broken.  These end up showing a “Page Not Found”.  

Unfortunately you are right...  

>  
> The Archive links look okay.  
>  
> The Other Archives are mostly okay, but the nabble.com links are broken too?  

The issue was: Nabble seemed to available http only instead of  
https...fixed as well..  

>  
>  * * *  
>  
> Is anyone aware of this and/or is there a way to fix these so that community 
> members can sub/unsub to lists?  
>  
> —jason  
>  


We have not been aware of this and many thanks for reporting this...  

I have fixed the issues..  

Can you check if I have missed something?  

Kind regards  
Karl Heinz Marbaise  

Mailing list links broken?

[Jason Dillon]

On this page: 

https://maven.apache.org/mailing-lists.html

It looks like the sub/unsub/post links like:

https://maven.apache.org/users-subscr...@maven.apache.org
https://maven.apache.org/users-unsubscr...@maven.apache.org
https://maven.apache.org/us...@maven.apache.org

Are broken.  These end up showing a “Page Not Found”.

The Archive links look okay.

The Other Archives are mostly okay, but the nabble.com links are broken too?

 * * *

Is anyone aware of this and/or is there a way to fix these so that community 
members can sub/unsub to lists?

—jason

Re: convert maven-resolver-provider to jsr330

[Jason Dillon]

Yes please, thank you :-]

—jason


On May 24, 2017 at 2:38:24 PM, Igor Fedorenko (i...@ifedorenko.com) wrote:

I'd like to ask for somebody to second my change described in  
[MNG-6233]. The change cleans up mixture of jsr330 and plexus  
annotations used in maven-resolver-provider, leaving only jsr330. The  
change is small and I believe safe, does not change any user-observable  
behaviour during normal maven build and all ITs pass.  

[MNG-6233] https://issues.apache.org/jira/browse/MNG-6233  

--  
Regards,  
Igor  

PS: Unfortunately I already submitted the change to master (by bad,  
sorry about that) but will revert the change if I don't get +1s or get  
any -1s within usual 72h.  

-  
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org  
For additional commands, e-mail: dev-h...@maven.apache.org  

Maven Shell

[Jason Dillon]

Folks, just a quick not that I’ve updated Maven Shell for the latest release, 
can be found with the latest SNAPSHOT:

https://oss.sonatype.org/content/repositories/snapshots/com/planet57/maven/shell/dist/mvnsh-assembly/1.2.0-SNAPSHOT/

Locally seems to be fully functional.  I’ve been updating GShell (which mvnsh 
is based on) as well.

I’m considering augmenting the release versions of mvnsh to match the upstream 
versions.

I’m also eventually gonna update the jline support as I think jline3 is much 
much improved, thanks to gnodet, but I haven’t done that yet.

If there are folks that may still be using older versions of the shell, I’d 
like to ask them to test the latest SNAPSHOTS and report back any issues.

Cheers,

—jason

Re: Maven 3.4.0 color output and default slf4j implementation

[Jason Dillon]

Okay, good luck.  Let me know if you change your mind and need improvements to 
gossip.

Cheers,

—jason


On October 22, 2016 at 10:20:08 AM, Hervé BOUTEMY (herve.bout...@free.fr) wrote:

thanks for sharing what you had, this really helped me work on the topic,  
testing and learning misc approaches.  


Now, the first feedback we've got on slf4j-simple to Gossip provider change  
is:  
- mailing list: some missing features  
- MNG-6044: missing documentation and integration improvements required  
(config file in conf/logging)  

And that was only a first feedback with a few testers: the change may cause  
more feedback to manage once released.  


I'm convinced the slf4j-simple monkey patch approach will avoid a lot of  
change management, with a solution that is manageable (nothing complex).  


Then I won't personnally put more efforts on Gossip integration: the issue is  
not Gossip itself, but it's users change management. And since I found a  
solution that avoids this critical issue, I prefer avoid the change.  

If others want to work on it and want to manage the change, feel free to take  
the job.  


Really thank you Jason for sharing your work: without it, I wouldn't have done  
what I did and I fear color output would still be in limbo.  

Regards,  

Hervé  

Le vendredi 21 octobre 2016 14:25:01 vous avez écrit :  
> FTR I choose Gossip because it was an slf4j impl I created which had more  
> features than slf4j-simple but was also very small, and I had already  
> previously implemented a ANSI color rendering scheme for it, as it was used  
> by Maven Shell.  
>  
> Its true that Gossip doesn’t have the same features as slf4j-simple, because  
> my use-cases didn’t need it and thus I didn’t add code bloat for things I  
> did not need. I think I mentioned before its possible to change that, but  
> it also wasn’t quite clear what was needed and I certainly don’t remember  
> now.  
>  
> FTR I didn’t realize that there were strong use-cases for folks fiddling  
> with the logging impl/config so much, vs just using the tool as it comes.  
>  
> If you folks want to drop it and hack in something else, it won’t hurt my  
> feelings. If you need help to adjust Gossip to do something I can probably  
> help.  
>  
> —jason  


-  
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org  
For additional commands, e-mail: dev-h...@maven.apache.org  

Re: Maven 3.4.0 color output and default slf4j implementation

[Jason Dillon]

FTR I choose Gossip because it was an slf4j impl I created which had more 
features than slf4j-simple but was also very small, and I had already 
previously implemented a ANSI color rendering scheme for it, as it was used by 
Maven Shell.  

Its true that Gossip doesn’t have the same features as slf4j-simple, because my 
use-cases didn’t need it and thus I didn’t add code bloat for things I did not 
need.  I think I mentioned before its possible to change that, but it also 
wasn’t quite clear what was needed and I certainly don’t remember now.

FTR I didn’t realize that there were strong use-cases for folks fiddling with 
the logging impl/config so much, vs just using the tool as it comes.

If you folks want to drop it and hack in something else, it won’t hurt my 
feelings.  If you need help to adjust Gossip to do something I can probably 
help.

—jason

Re: Maven 3.4.0 and documentation of gossip logging

[Jason Dillon]

Gossip presently doesn’t allow you to set adhoc logging configuration via
system properties, but as you have discovered uses a configurable
properties file to allow a profile to be configured to adjust your logging
as needed.  I suppose that feature could be added, either to gossip proper
to as a customized source in the maven implementation.

For "backwards compatibility" I think gossip needs to add an option
for a relative timestamp (since creation of the loggers) and maybe an
easy way to set single log levels from the command line.

Likely easy enough to add, the basic renderer is here:

https://github.com/jdillon/gossip/blob/master/gossip-bootstrap/src/main/java/com/planet57/gossip/render/PatternRenderer.java

Though unsure how its “backwards compatible”.  If you want to use features
of another slf4j impl you are still free to switch it back to slf4j-simple
or something else and get a lot more control over logging with your
favorite backend.

—jason

Re: maven git commit: [MNG-3507] keep green for success: INFO in blue (DEBUG is cyan)

[Jason Dillon]

> And if folks really just want any use of green to become blue, then yes 
> you can do that now and there is no reason to change anything further. 
> Though I kinda doubt that is what folks want when then think about 
> customization of colors. I expect folks really want more control over 
> “logger-level-info” is blue or green, similar to how IDEA or Eclipse can 
> let you configure colors based on context, and not simply doing color 
> replacements (i.e. everything green is now blue). 
> 

Ok. Maybe we should not export jansi to plugin classpaths' then. We may 
need to provide a more sophisticated logging API supporting things like 
color and bold, italic, etc. If plugin developers start using jansi to 
provide ANSI escapes in log messages we cannot change anything to what 
they do later. 
I’d recommend the simple impl to see how the community takes to colors and 
gather feedback and ideas before doing anything more.

I do think if folks are keen to the colors that perhaps a larger change to 
normalize how output is handled is probably in order, and that is why I didn’t 
try to go adding ansi directly to the plugin development api yet, but left it 
just in the logging system.

I’m also not sure I’d want to expose ansi sequences directly to plugin 
development, but perhaps instead using an AnsiRenderer ( 
https://github.com/fusesource/jansi/blob/master/jansi/src/main/java/org/fusesource/jansi/AnsiRenderer.java
 ) style abstraction over the streams.  Here I could imagine it fairly trivial 
to externalize the color attributes to a mapping model.

I also don’t think that colors should be over-used, so exposing directly as api 
to all plugins could end up with pretty rainbow vomit on the console which 
could potentially negate the value of having colors to help signify bad or good 
things.  Adding colors presently is a simple easy way at a glance to see these. 
 But if it was up to each plugin to color as it felt, then the brain power 
needed to comprehend the output would grow exponentially, unless there was some 
abstraction over “good”, “bad”, “warning”, etc concepts.

 * * *

In short, I would not recommend jumping directly into making ansi coloring of 
output part of the api proper and exposing to the community for extension at 
this time w/o further consideration and planning for how it would impact the 
platform generally.

—jason

Re: maven git commit: [MNG-3507] keep green for success: INFO in blue (DEBUG is cyan)

[Jason Dillon]

On June 15, 2016 at 12:07:32 AM, Christian Schulte (c...@schulte.it) wrote:
Am 06/15/16 um 00:17 schrieb Jason Dillon: 
> Making the colors configurable seems like a lot of overhead for what is 
> otherwise fairly simple. 
> 
> I’d recommend leaving the colors asis for now, get this out to let users 
> actually make use of it, and then consider adding complexity later to make 
> colors configurable. 
> 
> I don’t see a clean way to make colors configurable w/o adding some sort of 
> layer to make color names abstracted to symbols, which means adding 
> additional logic to resolve the color symbol name to real color, and likely a 
> completely different api to render text with these abstract names. 
> 

Isn't this the job of the terminal in use? It can map the ANSI colors to 
something different already, I think. 
That would only work to change all instances of a standard ANSI color to 
another.  Not to customize what the colors of various bits are.  For example if 
you like [INFO] as green, but someone else likes [INFO] as blue ( 
https://github.com/apache/maven/commit/e7a783db1f577a340a91f6c958f1b9319c52c176 
).  Using the terminal here could only change any use of fgGreen to whatever 
color you preferred, not just specifically the [INFO] segment.

And if folks really just want any use of green to become blue, then yes you can 
do that now and there is no reason to change anything further.  Though I kinda 
doubt that is what folks want when then think about customization of colors.  I 
expect folks really want more control over “logger-level-info” is blue or 
green, similar to how IDEA or Eclipse can let you configure colors based on 
context, and not simply doing color replacements (i.e. everything green is now 
blue).

—jason

Re: maven git commit: [MNG-3507] keep green for success: INFO in blue (DEBUG is cyan)

[Jason Dillon]

Making the colors configurable seems like a lot of overhead for what is 
otherwise fairly simple.

I’d recommend leaving the colors asis for now, get this out to let users 
actually make use of it, and then consider adding complexity later to make 
colors configurable.

I don’t see a clean way to make colors configurable w/o adding some sort of 
layer to make color names abstracted to symbols, which means adding additional 
logic to resolve the color symbol name to real color, and likely a completely 
different api to render text with these abstract names.

This is IMO overkill for a first release of mvn + ansi color support.

—jason


On June 14, 2016 at 3:04:20 PM, Olivier Lamy (ol...@apache.org) wrote:

On 15 June 2016 at 05:25,  wrote:  

> Repository: maven  
> Updated Branches:  
> refs/heads/master ecdb0bc2b -> e7a783db1  
>  
>  
> [MNG-3507] keep green for success: INFO in blue (DEBUG is cyan)  
>  
> Project: http://git-wip-us.apache.org/repos/asf/maven/repo  
> Commit: http://git-wip-us.apache.org/repos/asf/maven/commit/e7a783db  
> Tree: http://git-wip-us.apache.org/repos/asf/maven/tree/e7a783db  
> Diff: http://git-wip-us.apache.org/repos/asf/maven/diff/e7a783db  
>  
> Branch: refs/heads/master  
> Commit: e7a783db1f577a340a91f6c958f1b9319c52c176  
> Parents: ecdb0bc  
> Author: Hervé Boutemy   
> Authored: Tue Jun 14 21:25:02 2016 +0200  
> Committer: Hervé Boutemy   
> Committed: Tue Jun 14 21:25:02 2016 +0200  
>  
> --  
> .../org/apache/maven/cli/logging/impl/gossip/ColorRenderer.java | 2 +-  
> 1 file changed, 1 insertion(+), 1 deletion(-)  
> --  
>  
>  
>  
> http://git-wip-us.apache.org/repos/asf/maven/blob/e7a783db/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/ColorRenderer.java
>   
> --  
> diff --git  
> a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/ColorRenderer.java
>   
> b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/ColorRenderer.java
>   
> index 7cc..52e0489 100644  
> ---  
> a/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/ColorRenderer.java
>   
> +++  
> b/maven-embedder/src/main/java/org/apache/maven/cli/logging/impl/gossip/ColorRenderer.java
>   
> @@ -50,7 +50,7 @@ extends com.planet57.gossip.render.PatternRenderer  
> break;  
>  
> case INFO:  
> - buff.append( ansi().bold().fgGreen().a( level.name()  
> ).reset() );  
> + buff.append( ansi().bold().fgBlue().a( level.name()  
> ).reset() );  
>  


What about having color configurable? Ask few people they will all have  
different opinions about the color to use.  
So to avoid all of complains and jira issue asking color change etc...  
having some configuration could IMHO ease our life :-) (french part you  
know "les goûts et les couleurs" :-) )  

Well not sure how as the current configuration file is included in the jar.  
Furthermore I have no idea our externalise that.  





> break;  
>  
> case WARN:  
>  
>  

Re: Maven Memory Consumption

[Jason Dillon]

colors for Linux are not exactly the same as the screen dump: yellow from the 
screen dump is bold white on Linux. This is ok for me 
Terminals can render whatever colors they want for the ANSI colors and many 
have this configurable.

To be clear my terminal env has bold color rendering as yellow (very very very 
old preference I’ve had for a long time so much I forgot it was my preference).

We can certainly make things explicitly yellow though if that is preferred over 
simply bold.

—jason

Re: Maven Memory Consumption

[Jason Dillon]

If its on by default I would expect folks to set 
MAVEN_OPTS=-Dmaven.logging=plain instead of magically making —batch do that.

If we mutate the cli api slightly to expose more details about the cli 
configuration to the Slf4jConfiguration then regular -Dmaven.logging=plain on 
command line would probably work too.  Right now the logging configuration has 
no context of the command-line params and can only use System.properties to 
fiddle with configuration.

If ^^^ was done then could also consider adding —color={yes|no} flag, though I 
felt odd hacking that in given that this is a pluggable aspect, and if you were 
using logbook backend it would be meaningless and potentially confusing.

—jason


On June 2, 2016 at 8:37:18 PM, Manfred Moser (manf...@simpligility.com) wrote:

If we plan to switch it to on be default at a later stage we could 
automatically disable it in batch mode. And tell people to run in batch mode on 
a CI server.  

Just a thought..  

Manfred  

Jason van Zyl wrote on 2016-06-02 19:52:  

> If the output comes out decently in color in CI consoles then it’s probably  
> not an issue putting the color on by default. But I haven’t checked and  
> suggested that the color be off by default to start with.  
>  
>> On Jun 2, 2016, at 5:15 PM, Hervé BOUTEMY  wrote:  
>>  
>> I merged the PR in the slf4j-gossip branch (and added a little improvement)  
>>  
>> core ITs are ok (notice: ran without activating colors)  
>> colors for Linux are not exactly the same as the screen dump: yellow from 
>> the  
>> screen dump is bold white on Linux. This is ok for me  
>>  
>> Now, what's annoying is that:  
>> - color is not enabled by default: I had to configure MAVEN_OPTS="-  
>> Dmaven.logging=color"  
>> - when redirecting content to file, color is not disabled automatically  
>>  
>> I don't know if this is a showstopper or not  
>> I will continue to use it to see if there are unexpected side effects  
>>  
>> Regards,  
>>  
>> Hervé  
>>  
>> Le jeudi 2 juin 2016 09:21:46 Tamás Cservenák a écrit :  
>>> Olivier, if you refer to the slf4j-gossip branch, that IMHO Jason's PR  
>>> supersedes it.  
>>> Will drop that branch.  
>>>  
>>> On Thu, Jun 2, 2016 at 8:38 AM Olivier Lamy  wrote:  
 well I think this color stuff has already been done differently but never  
 accepted..  
  
 On 2 June 2016 at 16:28, Hervé BOUTEMY  wrote:  
> another feature that would be great for this release:  
> https://github.com/apache/maven/pull/81  
>  
> I still didn't have time to work on it, but I like the screenshot  
> The only thing that I'd like to check is: is tty detection working? ie  
  
 does  
  
> color automatically disappear if there is no tty?  
>  
> Regards,  
>  
> Hervé  
>  
> Le jeudi 2 juin 2016 08:23:57 Hervé BOUTEMY a écrit :  
>> +1  
>> this is something that was often seen: this is great that it is fixed!  
>>  
>> For example, the last time I published Maven core site, the build  
  
 simply  
  
>> failed because of PermgenSpace: now it is working like a charm...  
>>  
>> This release will be a must!  
>>  
>> Regards,  
>>  
>> Hervé  
>>  
>> Le mercredi 1 juin 2016 20:12:33 Karl Heinz Marbaise a écrit :  
>>> Hi Manfred,  
>>>  
>>> On 6/1/16 12:24 AM, Manfred Moser wrote:  
 I can feel your excitement coming through in the emails.. ;-)  
>>>  
>>> Of course I'm excited ;-)  
>>>  
>>> ...cause it's very important...I have had heard many customers  
>>> saying  
>>> they will not upgrade to newer versions of Maven exactly based on  
  
 such  
  
>>> issue(s)...  
>>>  
>>> which is in general bad ...  
>>>  
>>>  
>>> This will break their argument ;-)...  
>>>  
 Karl Heinz Marbaise wrote on 2016-05-31 15:14:  
> Hi,  
>  
> tested without the patch (-Xmx6g) ...run time for the test  
> project  
>  
> more  
>  
> than two 2 Minutes  
>  
> running with the patch (-Xmx1g):  
>  
> Run time ca. 27 seconds...  
>  
> also worked with -Xmx768m ...ca. 30 seconds...  
>  
> so looks very good...  
>  
> Let us wait what the IT's say...  
>  
> Kind regards  
> Karl Heinz Marbaise  
>  
> On 5/31/16 10:49 PM, Karl Heinz Marbaise wrote:  
>> Hi,  
>>  
>> after more investigation and an extremly good tip of  
  
 Andriy...(see  
  
>> MNG-6030) and in the end the solution:  
>>  
>> Using test project with 5000 modules just doing:  
>>  
>> mvn clean  
>>  
>> using the patch now in master  
>> (41144e7ecf52e7ec3850f3e78d81f42f505f4af8)  
>> extremely reduces the memory f

Re: Maven Memory Consumption

[Jason Dillon]

On June 2, 2016 at 3:15:35 PM, Hervé BOUTEMY (herve.bout...@free.fr) wrote:
I merged the PR in the slf4j-gossip branch (and added a little improvement) 

core ITs are ok (notice: ran without activating colors) 
The testsuite certainly will not be very happy with color enabled as many tests 
are expecting exact strings in the output.  I had considered setting 
MAVEN_SKIP_RC env-var to avoid any local customization from polluting the 
testsuite execution.



colors for Linux are not exactly the same as the screen dump: yellow from the 
screen dump is bold white on Linux. This is ok for me 
Terminals can render whatever colors they want for the ANSI colors and many 
have this configurable.



Now, what's annoying is that: 
- color is not enabled by default: I had to configure MAVEN_OPTS="- 
Dmaven.logging=color" 
Seemed safer off by default then breaking the output for users where ansi is 
not supported and for whatever reason its not been detected as such to strip 
out.



- when redirecting content to file, color is not disabled automatically 
It may depend on how its redirected, my local testing shows that `mvn > foo’ 
disables ansi sequences, though I can not say I’ve done any exhaustive testing 
of this.

To be able to tell if System.out is an ANSI-aware terminal it may need a bit 
more love ala jline or more helpers in jansi to do more properly?

—jason

Re: Why no mvn daemon?

[Jason Dillon]

Jason, if you have a built version, do you mind adding it as a download to 
the release files? 
I can make a binary of this, though I do plan on fixing it up so that folks can 
build it in the near future.

Build up here for the moment:

https://www.dropbox.com/sh/yvt1g43r2pr2scj/AADqM__VhJaFf_x57OiUEZXva?dl=0

gshell:master should be buildable with just central now, dangling ref to older 
version of jline for classifer=tests which was unused and polluting the build 
dependencies.

—jason

Re: Why no mvn daemon?

[Jason Dillon]

On March 8, 2016 at 7:45:53 AM, Jeff Jensen (jeffjen...@upstairstechnology.com) 
wrote:
FYI Just cloned and tried build but Jansi 1.2 is not in Central: "Could not 
find artifact org.fusesource.jansi:jansi:jar:1.2". 
http://search.maven.org/#search|gav|1|g%3A%22org.fusesource.jansi%22%20AND%20a%3A%22jansi%22
 

I noted the issue tracker no longer exists so replying here to start. 

jansi is not declared in the POMs, so assuming transitive. Found it is 
only referenced by 
"mvnsh-commands/mvnsh-maven/src/main/java/org/sonatype/maven/shell/commands/maven/ColorizingStream.java"
 
in mvnsh-commands/mvnsh-maven. 
I'm out of time to look further at the moment. 
I’m aware of this.  I took a brief look at upgrading to the latest jline but 
its a bit more work.  There is another sonatype version of jline that may work 
better in the short-term until moving to the official jline2 stuff can be done.



Jason, if you have a built version, do you mind adding it as a download to 
the release files? 
I can make a binary of this, though I do plan on fixing it up so that folks can 
build it in the near future.


Do you have interest in supporting further or prefer not to continue with 
it? 
I’ve recently put in a bit more effort to bring this stuff up to speed 
w/changes to maven.  I’m not sure I’ll be spending a ton of effort around it 
but I’m not sure how much effort is required.  Certainly though if folks are 
actually using this then I’ll do what I can to support its continued use.

There is another maven shell which may have more legs in terms of longer term 
community support, but I’m not yet sure where that is in terms of public 
availability.

—jason

Re: Why no mvn daemon?

[Jason Dillon]

On March 3, 2016 at 5:42:56 AM, Tamás Cservenák (ta...@cservenak.net) wrote:
Maven Shell? 

https://github.com/jdillon/mvnsh 

Does anyone actually use this?

—jason

Surefire 2.13?

[Jason Dillon]

Any idea when this will get released? 

11 issues fixed.

--jason 



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

fluido skin twitter button could use some padding

[Jason Dillon]

This would be slightly better if the titter button was floating in the topBar 
with some padding around it… instead of sticking to the top.  

--jason  



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

maven-fluido-skin github ribbon covered by topBar

[Jason Dillon]

The github ribbon muck in maven-fluido-skin 1.2.2 covers the topBar.  

… would actually like a bottom-right or something instead.

Is bottom locations on the roadmap, or at least updated skin to fix the zorder?

--jason  



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Missing requirement in maven-core components.xml

[Jason Dillon]

The DefaultSecDispatcher defined in 
https://github.com/apache/maven-3/blob/trunk/maven-core/src/main/resources/META-INF/plexus/components.xml
 is missing a requirement: 


org.sonatype.plexus.components.sec.dispatcher.PasswordDecryptor
_decryptors




Looks like an oversight, but w/o this the pluggable PasswordDecryptor bits 
don't work so well ;-)

https://github.com/apache/maven-3/pull/4

--jason 



-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Security trouble

[Jason Dillon]

Why don't you just fix the parsers in older mavens (ie. make a new release of 
old-maven-version-x w/fixed parser) that allows for changes in newer versions?

Seems like if you can never add new information to the pom to solve 
problems/add features in Maven 3 w/o completely breaking Maven 2, then Maven 3 
really can not effectively grow and mature. 


On Wednesday, March 21, 2012 at 6:57 AM, Brian Fox wrote:

> On Wed, Mar 21, 2012 at 4:35 AM, Sascha Scholz  (mailto:sascha.sch...@gmail.com)> wrote:
> > Hi,
> > 
> > On Tue, Mar 20, 2012 at 11:28 PM, Olivier Lamy  > (mailto:ol...@apache.org)> wrote:
> > > BTW do we consider adding a warning in 3.0.5 if id != host and fail in 
> > > 3.0.6
> > > or fail directly in 3.0.5
> > > 
> > 
> > 
> > Why not deprecate the id entry then instead of forcing users to set
> > both to the same value?
> > 
> 
> 
> The xml parsing of older maven's isn't flexible enough to allow this.
> 
> > BTW, I don't see that preemptive authentication makes things worse
> > regarding security because an attacker could answer with a 401 to get
> > the credentials even without preemptive authentication.
> > 
> 
> 
> Correct.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> (mailto:dev-unsubscr...@maven.apache.org)
> For additional commands, e-mail: dev-h...@maven.apache.org 
> (mailto:dev-h...@maven.apache.org)
> 
> 

Re: Maven nightlies removed from grid.sonatype.org?

[Jason Dillon]

There are running up here no?

https://builds.apache.org/hudson/view/M-R/view/Maven/

--jason


On Apr 25, 2011, at 5:16 PM, Mark Derricutt wrote:

> Hey all,
> 
> I see they maven nightly/ci build no longer seems to be on
> https://grid.sonatype.org/ci - has it moved somewhere?
> 
> Mark
> 
> -- 
> "Great artists are extremely selfish and arrogant things" — Steven Wilson,
> Porcupine Tree


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [vote] release maven enforcer plugin 1.0 take 2

[Jason Dillon]

I didn't see the take 2... make it so

+1

--jason


On Nov 4, 2010, at 10:52 AM, Brian Fox wrote:

> noone wants an enforcer release?
> 
> On Tue, Nov 2, 2010 at 5:52 PM, Brian Fox  wrote:
>> Hi,
>> 
>> Take 2, I added MENFORCER-109.
>> 
>> Changelog:
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=13616
>> 
>> Staging repo:
>> https://repository.apache.org/content/groups/maven_promotion-013/
>> 
>> ( i promoted it along with the parent to a single repo)
>> 
>> Staging site:
>> http://people.apache.org/~brianf/enforcer-stage/plugins/maven-enforcer-plugin/
>> 
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>> 
>> Vote open for 72 hours.
>> 
>> [ ] +1
>> [ ] +0
>> [ ] -1
>> 
>> +1
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [vote] release maven enforcer plugin 1.0

[Jason Dillon]

+1

--jason


On Nov 2, 2010, at 10:47 AM, Brian Fox wrote:

> Hi,
> 
> Changelog:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=13616
> 
> Staging repo:
> https://repository.apache.org/content/repositories/maven-009/
> 
> Staging site:
> http://people.apache.org/~brianf/enforcer-stage/plugins/maven-enforcer-plugin/
> 
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
> 
> Vote open for 72 hours.
> 
> [ ] +1
> [ ] +0
> [ ] -1
> 
> +1
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: cvs exe version on the grid (windows node)

[Jason Dillon]

I upgraded to 1.11.22 a few hours ago and started a new build of maven-scm, 
still failing some tests, but looking better:

https://grid.sonatype.org/ci/job/maven-scm/jdk=1.5,label=windows/128/

--jason


On May 16, 2010, at 12:37 AM, Olivier Lamy wrote:

> ping !
> 
> 
> 2010/5/8 Olivier Lamy :
>> By any chance, this windauze use a cvs 1.12.13 ?
>> It looks to have an issue with this version and local cvs repository.
>> I have tested with 1.11.22 and no problem.
>> 
>> Related thread : http://www.mail-archive.com/bug-...@nongnu.org/msg01258.html
>> 
>> Any chance to change the cvs exe version ?
>> 
>> 2010/5/8 Hudson :
>>> See 
>>> 
>>> 
>>> Changes:
>>> 
>>> [Olivier Lamy] upgrade parent
>>> 
>>> --
>>> [...truncated 3760 lines...]
>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.293 sec
>>> Running 
>>> org.apache.maven.scm.provider.vss.commands.checkout.VssCheckOutCommandTest
>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.536 sec
>>> Running 
>>> org.apache.maven.scm.provider.vss.commands.status.VssStatusConsumerTest
>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.029 sec
>>> Running org.apache.maven.scm.provider.vss.commands.VssCommandLineUtilsTest
>>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.058 sec
>>> Running org.apache.maven.scm.provider.vss.commands.edit.VssEditCommandTest
>>> Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.36 sec
>>> Running org.apache.maven.scm.provider.vss.VssScmProviderTest
>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.015 sec
>>> Running 
>>> org.apache.maven.scm.provider.vss.commands.status.VssStatusCommandTest
>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.035 sec
>>> Running 
>>> org.apache.maven.scm.provider.vss.commands.update.VssUpdateCommandTest
>>> Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.048 sec
>>> Running org.apache.maven.scm.provider.vss.commands.add.VssAddCommandTest
>>> Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.059 sec
>>> 
>>> Results :
>>> 
>>> Tests run: 14, Failures: 0, Errors: 0, Skipped: 0
>>> 
>>> [INFO]
>>> [INFO] --- maven-jar-plugin:2.3:jar (default-jar) @ maven-scm-provider-vss 
>>> ---
>>> [INFO] Building jar: 
>>> C:\home\hudson\workspace\maven-scm\jdk\1.5\label\windows\trunk\maven-scm-providers\maven-scm-provider-vss\target\maven-scm-provider-vss-1.4-SNAPSHOT.jar
>>> [INFO]
>>> [INFO] --- maven-install-plugin:2.3:install (default-install) @ 
>>> maven-scm-provider-vss ---
>>> [INFO] Installing 
>>> C:\home\hudson\workspace\maven-scm\jdk\1.5\label\windows\trunk\maven-scm-providers\maven-scm-provider-vss\target\maven-scm-provider-vss-1.4-SNAPSHOT.jar
>>>  to 
>>> C:\opt\repos\scm\org\apache\maven\scm\maven-scm-provider-vss\1.4-SNAPSHOT\maven-scm-provider-vss-1.4-SNAPSHOT.jar
>>> [INFO]
>>> [INFO] --- maven-deploy-plugin:2.5:deploy (default-deploy) @ 
>>> maven-scm-provider-vss ---
>>> [INFO] Retrieving previous build number from apache.snapshots.https
>>> [INFO] repository metadata for: 'snapshot 
>>> org.apache.maven.scm:maven-scm-provider-vss:1.4-SNAPSHOT' could not be 
>>> found on repository: apache.snapshots.https, so will be created
>>> Uploading: 
>>> file:/opt/repos/deploy-junk/org/apache/maven/scm/maven-scm-provider-vss/1.4-SNAPSHOT/maven-scm-provider-vss-1.4-20100508.133653-1.jar
>>> 67 KB uploaded at 11058.9 KB/sec
>>> [INFO] Retrieving previous metadata from apache.snapshots.https
>>> [INFO] repository metadata for: 'artifact 
>>> org.apache.maven.scm:maven-scm-provider-vss' could not be found on 
>>> repository: apache.snapshots.https, so will be created
>>> [INFO] Uploading repository metadata for: 'artifact 
>>> org.apache.maven.scm:maven-scm-provider-vss'
>>> [INFO] Retrieving previous metadata from apache.snapshots.https
>>> [INFO] repository metadata for: 'snapshot 
>>> org.apache.maven.scm:maven-scm-provider-vss:1.4-SNAPSHOT' could not be 
>>> found on repository: apache.snapshots.https, so will be created
>>> [INFO] Uploading repository metadata for: 'snapshot 
>>> org.apache.maven.scm:maven-scm-provider-vss:1.4-SNAPSHOT'
>>> [INFO] Uploading project information for maven-scm-provider-vss 
>>> 1.4-20100508.133653-1
>>> [INFO]
>>> [INFO] 
>>> 
>>> [INFO] Building Maven SCM TFS Provider 1.4-SNAPSHOT
>>> [INFO] 
>>> 
>>> [INFO]
>>> [INFO] --- maven-clean-plugin:2.4:clean (default-clean) @ 
>>> maven-scm-provider-tfs ---
>>> [INFO] Deleting 
>>> C:\home\hudson\workspace\maven-scm\jdk\1.5\label\windows\trunk\maven-scm-providers\maven-scm-provider-tfs\target
>>> [INFO]
>>> [INFO] --- maven-remote-resources-plugin:1.1:process (default) @ 
>>> maven-scm-provider-tfs ---
>>> [INF

Re: Grid: Maven-2.2.x marked as success - console gives IOExceptions...

[Jason Dillon]

Its the repo trigger that is barfing... it will soon be replaced.  You can 
ignore this error, it only means that Hudson will not be able to trigger the 
build when a SNAPSHOT changed.

--jason


On May 6, 2010, at 10:44 PM, Barrie Treloar wrote:

> There are errors but the build is marked as success.
> Could someone look into this please?
> 
> See https://grid.sonatype.org/ci/view/Maven/job/Maven-2.2.x/72/console
> 
> The error is:
> Triggering 1.5,windows
> hudson.util.IOException2: remote file operation failed
>   at hudson.FilePath.act(FilePath.java:672)
>   at hudson.FilePath.act(FilePath.java:660)
>   at 
> hudson.plugins.mavenrepotrigger.MavenRepoTriggerRunListener.onCompleted(MavenRepoTriggerRunListener.java:68)
>   at 
> hudson.plugins.mavenrepotrigger.MavenRepoTriggerRunListener.onCompleted(MavenRepoTriggerRunListener.java:25)
>   at 
> hudson.model.listeners.RunListener.fireCompleted(RunListener.java:129)
>   at hudson.model.Run.run(Run.java:1165)
>   at hudson.matrix.MatrixBuild.run(MatrixBuild.java:148)
>   at hudson.model.ResourceController.execute(ResourceController.java:93)
>   at hudson.model.Executor.run(Executor.java:122)
> Caused by: java.io.IOException: Remote call failed
>   at hudson.remoting.Channel.call(Channel.java:545)
>   at hudson.FilePath.act(FilePath.java:667)
>   ... 8 more
> Caused by: java.lang.NoClassDefFoundError:
> org/apache/maven/project/ProjectBuildingException
> ...
> Finished: SUCCESS
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
> 


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [ANN] Maven Plugin Tools 2.5 Released

[Jason Dillon]

http://maven.apache.org/plugins/ version needs to be updated.

--jason


On Feb 27, 2009, at 9:24 AM, John Casey wrote:

The Maven team is pleased to announce the release of version 2.5 of  
Maven Plugin Tools, including the Maven Plugin Plugin.


These libraries are used to generate plugin descriptors,  
documentation, and the implicit help mojo (as in: 'mvn  
installer:help').


http://maven.apache.org/plugin-tools
http://maven.apache.org/plugins/maven-plugin-plugin

You should specify the version in your project's plugin configuration:


 org.apache.maven.plugins
 maven-plugin-plugin
 2.5


If you're creating a plugin that uses Ant-based mojos, you should  
also include the Ant tools library:



 org.apache.maven.plugins
 maven-plugin-plugin
 2.5
 
   
 org.apache.maven.plugin-tools
 maven-plugin-tools-ant
 2.5
   
 



Release Notes - Maven 2.x Plugin Tools - Version 2.5


** Bug
   * [MPLUGIN-106] - remove no mojo deprecation warning and throw an  
exception
   * [MPLUGIN-109] - Misleading warning when creating a Maven plugin  
defining a custom packaging
   * [MPLUGIN-135] - Deprecated info in parameter table of goal page  
contains garbage
   * [MPLUGIN-136] - maven-plugin-tools-api requires relative script  
root paths
   * [MPLUGIN-137] - PluginDescriptorGenerator doesn't write plugin  
name

   * [MPLUGIN-140] - Plugin report states wrong JDK requirement

** Improvement
   * [MPLUGIN-100] - Allow customization of file encoding used for  
generated help goal
   * [MPLUGIN-101] - Allow customization of file encoding used for  
mojo extraction

   * [MPLUGIN-111] - Warn about usage of platform encoding
   * [MPLUGIN-138] - Suppress bogus warning in case goalPrefix has  
been set to default goal prefix
   * [MPLUGIN-141] - Output warning for deprecated component  
expressions
   * [MPLUGIN-145] - Improve Ant-Mojo support to provide parity with  
antrun plugin



** Task
   * [MPLUGIN-110] - Make easier to pass parameters into  
MojoDescriptorExtractors



Enjoy,

-The Maven team


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [ANN] Maven Enforcer Plugin 1.0-beta-1

[Jason Dillon]

http://maven.apache.org/plugins/ version needs to be updated.

--jason


On Feb 26, 2009, at 10:40 AM, Brian Fox wrote:


The Maven team is pleased to announce the release of the Maven
Enforcer Plugin, version 1.0-beta-1

The Enforcer plugin is used to fail a build if certain constraints are
not met. There are too many standard rules to describe here, but check
out the site for more details:

http://maven.apache.org/plugins/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


org.apache.maven.plugins
maven-enforcer-plugin
1.0-beta-1



Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-beta-1

** Bug
   * [MENFORCER-30] - RequirePluginVersions breaks when using
project.parent.groupId and project.parent.version.
   * [MENFORCER-31] - Incorrect documentation for writing a custom  
rule

   * [MENFORCER-53] - incorrect documentation: states
uncheckedPlugins parameter of Require Plugin Versions, but is
unCheckedPlugins (wrong case)
   * [MENFORCER-55] - requirePluginVersions is not compatable with
Maven embedder (used in IDEs)
   * [MENFORCER-56] - NPE if  contains an unset  
variable

   * [MENFORCER-57] - Enforcer does not resolve local parent pom
   * [MENFORCER-58] - typo in rule-api documentation
   * [MENFORCER-60] - throw an error instead of failing the rule if
the beanshell is invalid
   * [MENFORCER-62] - requirePluginVesions: avoid checking
commandline-invoked mojos

** Improvement
   * [MENFORCER-48] - Support for a specific vendor of a JDK
   * [MENFORCER-59] - add the ability to be more selective with
banned repositories

Enjoy,
The Maven Team

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [vote] release maven-enforcer-plugin 1.0-beta-1

[Jason Dillon]

+1

--jason


On Feb 23, 2009, at 10:19 AM, Brian E. Fox wrote:


Time to release a beta with a few bug fixes:



Release Notes:

http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14948&styleName
=Html&projectId=11530&Create=Create



Staged site:

http://people.apache.org/~brianf/staging/people.apache.org/www/maven.apa
che.org/enforcer/



Artifacts Staged at:

https://repository.apache.org/content/repositories/maven-staging-49da452
d70c062/



72hrs, +1



--

Brian Fox

Apache Maven PMC

http://blogs.sonatype.com/brian/






-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [vote] release mercury-1.0.0-alpha-3

[Jason Dillon]

+1

--jason


On Jan 24, 2009, at 1:40 PM, Oleg Gusakov wrote:

I feel I owe an explanation about what was going with the release.  
As we tried to refactor out jetty server code out of the transport  
provider, we hit a few bumps on the road. But with the help from  
Jetty community, who were kind enough to fix it and release jetty  
6.1.15.rc2 today -  everything seem to be  in order now.


3rd time is a charm, so here it goes:

This is iterative improvements release of Mercury.

Most important are:
- repository exception handling adjusted for clearer client  
notifications. For example - absence of metadata did produce NPE  
result, now it throws a checked exception
- plexus component now correctly resolves multiple artifacts, not  
just one as it used to
- put Mercury on a diet - made encryption optional, factored out  
jetty server artifact


8 issues fixed: http://jira.codehaus.org/browse/MERCURY/fixforversion/14748

One known issue will be fixed in maven-mercury component -  
[MERCURY-75]


Staged release in repository at 
http://people.apache.org/~ogusakov/repos/staging/

Site at http://people.apache.org/~ogusakov/sites/mercury

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Thanks,
Oleg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: {VOTE] Release Mercury 1.0.0-alpha-2 results

[Jason Dillon]

Oh, I thought it was the same sync'ing as with sites, every few hours,  
or has that changed now too?


--jason


On Dec 12, 2008, at 3:05 PM, Brett Porter wrote:

The sync is only once a day. They are already at the apache rsync  
repo.


- Brett

On 12/12/2008, at 7:01 PM, Jason Dillon wrote:

Have you published the artifacts to central?  Its been 2 hours and  
I still don't see them.


--jason


On Dec 12, 2008, at 1:02 PM, Oleg Gusakov wrote:


6 votes casted

[+1] 6: 4 binding, 2 non-binding
[-1]
[0]

I released Mercury 1.0.0-alpha-2, site at http://maven.apache.org/mercury

Thanks,
Oleg

Oleg Gusakov wrote:

Dear All,

This is the first release of Mercury with all major [mercury]  
functionality enabled: repository access + dependency resolution.  
You can try using it for resolving artifacts and then writing  
them into a local repo in a standalone application, event system  
helps to understand what is going on inside (and for how long it  
does that). Example of using Mercury is available in mercury- 
plexus unit test.

More detailed discussion - http://docs.codehaus.org/display/MAVEN/Mercury

Special thanks to Herve Bouteme and Benjamin Bentmann for helping  
to make this happen!


We solved 20 issues: 
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11816&styleName=Html&version=14629

Staging repo: http://people.apache.org/~ogusakov/repos/staging

Staging site: http://maven.apache.org/mercury/staging

Vote open for 72 hours.

Thanks,
Oleg




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org



--
Brett Porter
br...@apache.org
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: {VOTE] Release Mercury 1.0.0-alpha-2 results

[Jason Dillon]

Have you published the artifacts to central?  Its been 2 hours and I  
still don't see them.


--jason


On Dec 12, 2008, at 1:02 PM, Oleg Gusakov wrote:


6 votes casted

[+1] 6: 4 binding, 2 non-binding
[-1]
[0]

I released Mercury 1.0.0-alpha-2, site at http://maven.apache.org/mercury

Thanks,
Oleg

Oleg Gusakov wrote:

Dear All,

This is the first release of Mercury with all major [mercury]  
functionality enabled: repository access + dependency resolution.  
You can try using it for resolving artifacts and then writing them  
into a local repo in a standalone application, event system helps  
to understand what is going on inside (and for how long it does  
that). Example of using Mercury is available in mercury-plexus unit  
test.

More detailed discussion - http://docs.codehaus.org/display/MAVEN/Mercury

Special thanks to Herve Bouteme and Benjamin Bentmann for helping  
to make this happen!


We solved 20 issues: 
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11816&styleName=Html&version=14629

Staging repo: http://people.apache.org/~ogusakov/repos/staging

Staging site: http://maven.apache.org/mercury/staging

Vote open for 72 hours.

Thanks,
Oleg




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: {VOTE] Release Mercury 1.0.0-alpha-2

[Jason Dillon]

+1

--jason


On Dec 8, 2008, at 2:18 PM, Oleg Gusakov  
<[EMAIL PROTECTED]> wrote:



Dear All,

This is the first release of Mercury with all major [mercury]  
functionality enabled: repository access + dependency resolution.  
You can try using it for resolving artifacts and then writing them  
into a local repo in a standalone application, event system helps to  
understand what is going on inside (and for how long it does that).  
Example of using Mercury is available in mercury-plexus unit test.

More detailed discussion - http://docs.codehaus.org/display/MAVEN/Mercury

Special thanks to Herve Bouteme and Benjamin Bentmann for helping to  
make this happen!


We solved 20 issues: 
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11816&styleName=Html&version=14629

Staging repo: http://people.apache.org/~ogusakov/repos/staging

Staging site: http://maven.apache.org/mercury/staging

Vote open for 72 hours.

Thanks,
Oleg


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: project creation rejected on codehaus ?

[Jason Dillon]

Doesn't seem like it should have been rejected.  Why are you posting  
this to the maven list though?


--jason


On Oct 9, 2008, at 5:28 PM, nicolas de loof wrote:


Hi
I have asked to create a JIRA project for the Mojo GWT-maven-plugin,  
before

I call for a vote and promotion from sandbox.
This request has been rejected. How am I supposed to have a  
dedicated JIRA

project for this plugin, as expected for graduated Mojo plugins ?

Nicolas



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] release and promote Mercury 1.0.0-alpha-1

[Jason Dillon]

+1

Will this also include the non-transport bits?  I'm looking to consume  
those in gshell ASAP to replace maven-artifact.


--jason


On Oct 4, 2008, at 12:02 PM, Oleg Gusakov wrote:

I open this vote to release mercury 1.0.0-alpha-1 and promote it out  
of sandbox, so that we can start using the transport piece - mercury  
wagon - right away.


For the past several months a group of some 5 community members has  
been working on Mercury - http://docs.codehaus.org/display/MAVEN/Mercury


The transport layer of the project has reached maturity to the  
extent that a mercury based wagon passes all the ITs in maven 2.1.x (http://jira.codehaus.org/browse/MERCURY-12 
) and 2.2.x(http://jira.codehaus.org/browse/MERCURY-11) branches,  
except for one, which did fail with previous wagon implementations.


I also ported un-uber from 3.0 tip into 2.1.x. I have not commited  
these changes, but the distributed maven-mercury bundle is built  
with it.


Issues resolved: 4
Detals: http://docs.codehaus.org/display/MAVEN/Mercury+Wagon
Staging Repository: http://people.apache.org/~ogusakov/repos/staging
Maven-mercury bundle 2.1.0-M2-SNAPSHOT: http://people.apache.org/~ogusakov/repos/staging/org/apache/maven/apache-maven/2.1.0-M2-SNAPSHOT/apache-maven-2.1.0-M2-20081003.231722-1-bin.gz 
 and http://people.apache.org/~ogusakov/repos/staging/org/apache/maven/apache-maven/2.1.0-M2-SNAPSHOT/apache-maven-2.1.0-M2-20081003.231800-2-bin.zip



Thanks,
Oleg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Maven archetype plugin version 2.0-alpha-4

[Jason Dillon]

+1

--jason


On Sep 23, 2008, at 2:14 AM, Raphaël Piéroni wrote:


Hi,

We solved 19 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14253

Staging repo:
http://people.apache.org/~rafale/archetype-stage-repository/
Beware of MNG-2974, a workaround is currently to use a repository  
manager.


Staging site:
http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-4/
Sync not made at writing time, meanwhile please use
http://people.apache.org/~rafale/site/maven-archetype-plugin/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Regards,

Raphaël Piéroni



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release maven-reactor-plugin 1.0

[Jason Dillon]

+1

--jason


On Sep 17, 2008, at 8:53 AM, Dan Fabulich wrote:



This plugin can build a subset of interdependent projects in a  
reactor. It should be useful in large reactor builds that include  
irrelevant stuff you're not working on.


http://maven.apache.org/plugins/maven-reactor-plugin/

A few important notes:

* This is maven-reactor-plugin's first official release.  I know  
it's traditional for us to call the first few releases 1.0-alpha-X  
for a while, but it can often be difficult to decide when to drop  
the "-alpha" qualifier, and I don't think very many people actually  
like that old tradition. :-)


* One weird thing about the maven-reactor-plugin is that three of  
its goals (reactor:make, reactor:make-dependents, reactor:resume)  
are now features in the maven-2.1.x branch; they will presumably get  
released as part of 2.1.0-M2.


I still think this plugin is worth releasing, for three reasons:

1) reactor:make-scm-changes will probably never become part of the  
Maven core, and probably should never, so at least one goal has long  
term value.


2) While I'd expected most people to use this goal from the command- 
line, it will also work wired up as part of a POM, e.g. as the  
default goal for particular profiles.  The new core features are  
command-line only.


3) A lot of people are on 2.0 and may be on 2.0 for a while yet  
(even if we release 2.1 very quickly).


There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11831&status=1

The biggest remaining issue is MREACTOR-1.  It's pretty bad, but I  
don't think it should hold up a 1.0 release.

http://jira.codehaus.org/browse/MREACTOR-1

Staging repo:
http://people.apache.org/~dfabulich/staging-repo/maven-reactor-plugin/

Staging site:
http://maven.apache.org/plugins/maven-reactor-plugin/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release Maven 2.1.0-M1

[Jason Dillon]

+1

--jason


On Sep 16, 2008, at 4:12 AM, John Casey wrote:


Hi everyone,

After fixing 70 issues and spending about 2 months going through  
release candidate after release candidate, we finally have a stable  
codebase!


To that end, I'd like to put Maven 2.1.0-M1 up for a vote. The  
release notes are here:


http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&styleName=Html&version=14503

and the staged binary is here:

http://people.apache.org/~jdcasey/stage/apache-maven/2.1.0-M1/org/apache/maven/apache-maven/2.1.0-M1

This vote will be open for 72h. Please vote +1/+0/-1.

Here's my +1.

Thanks,

-john

---
John Casey
Developer and PMC Member, Apache Maven (http://maven.apache.org)
Member, Apache Software Foundation
Blog: http://www.ejlife.net/blogs/buildchimp

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] release maven enforcer plugin 1.0-alpha-4

[Jason Dillon]

Mix-ins would be wonderful IMO...  :-)

--jason


On Sep 12, 2008, at 5:51 AM, Brian E. Fox wrote:

Alright, I'm pulling the trigger on this one and cancelling the  
vote. I

have to monkey with the poms some more to line up the plugin with the
values in the maven-plugin-parent. This is a good use case for the
mix-ins because I need to inherit default values from the enforcer and
from the maven-plugin-parent at the same time.

-Original Message-
From: Andreas Christoforides [mailto:[EMAIL PROTECTED]
Sent: Thursday, September 11, 2008 5:02 PM
To: Maven Developers List
Subject: Re: [vote] release maven enforcer plugin 1.0-alpha-4

Brian,

It looks like the "Goals" link is broken.

By the way, very useful plugin. I already added it to our company POM
and I have a bunch of rules commented out until alpha-4 comes  :)

Thanks,
Andreas

Brian E. Fox wrote:

Ok the site is restaged, and the links are in the menu now. (looks

much

better btw)

http://people.apache.org/~brianf/plugins/maven-enforcer-plugin/

http://people.apache.org/~brianf/enforcer/


-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 10, 2008 11:11 PM
To: Maven Developers List
Subject: RE: [vote] release maven enforcer plugin 1.0-alpha-4

Ok, I'll fix the site from the tag and restage just the site.

-Original Message-
From: Dennis Lundberg [mailto:[EMAIL PROTECTED]
Sent: Wednesday, September 10, 2008 5:32 PM
To: Maven Developers List
Subject: Re: [vote] release maven enforcer plugin 1.0-alpha-4

The whole  element needs to be removed from site.xml if you  
are
using parent-9. Those links have moved to  and are now  
inherited

from parent-9. Otherwise the top navigation is all screwed up, as can

be

seen on the staged site.

Brian E. Fox wrote:


Time to release the enforcer with all its new rules.



The plugin is staged here:

http://people.apache.org/~brianf/stage/



The site is staged here:

http://people.apache.org/~brianf/plugins/maven-enforcer-plugin/

http://people.apache.org/~brianf/enforcer/



Release Notes






http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14550&styleName



=Html&projectId=11530&Create=Create



Vote is open for 72hrs.



+1



--

Brian Fox

Apache Maven PMC

http://blogs.sonatype.com/brian/








--
Dennis Lundberg

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] release maven enforcer plugin 1.0-alpha-4

[Jason Dillon]

+1

--jason


On Sep 9, 2008, at 7:38 AM, Brian E. Fox wrote:


Time to release the enforcer with all its new rules.



The plugin is staged here:

http://people.apache.org/~brianf/stage/



The site is staged here:

http://people.apache.org/~brianf/plugins/maven-enforcer-plugin/

http://people.apache.org/~brianf/enforcer/



Release Notes

http://jira.codehaus.org/secure/ReleaseNote.jspa?version=14550&styleName
=Html&projectId=11530&Create=Create



Vote is open for 72hrs.



+1



--

Brian Fox

Apache Maven PMC

http://blogs.sonatype.com/brian/






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

GMaven 1.0-rc-4-SNAPSHOT

[Jason Dillon]

Folks a new snapshot of GMaven is out, this one mainly fixes problems  
with Maven 2.1 usage, and IDE integration which uses the Maven 2.1  
embedder.


Give it a whirl and report any issues, will release in a few days if I  
don't hear of any problems.  This should sort out the last of the  
major issues before 1.0.


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: preparing for enforcer alpha-4 release

[Jason Dillon]

Seems to work fine for me.

--jason


On Sep 5, 2008, at 1:02 AM, Brian E. Fox wrote:

I updated the maven dependencies in the enforcer from 2.0.6 to 2.0.9  
and
pushed out a 1.0-alpha-4-SNAPSHOT, please try it out and let me know  
if

you see any problems. If nothing turns up, then I'll stage it tomorrow
or this weekend for a vote.



Thanks.



--

Brian Fox

Apache Maven PMC

http://blogs.sonatype.com/brian/






-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: When will m-enforcer-p be released so that requirePluginVersions is available?

[Jason Dillon]

Thanks!

--jason


On Aug 29, 2008, at 7:39 PM, Brian E. Fox wrote:


My vacation, but I'll try to find time this weekend to get it done.

-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason
Dillon
Sent: Friday, August 29, 2008 3:56 AM
To: Maven Developers List
Subject: When will m-enforcer-p be released so that
requirePluginVersions is available?

Its been a long time... still waiting for a release so I can use the
requirePluginVersions rule.  What is holding it back from a release?

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

When will m-enforcer-p be released so that requirePluginVersions is available?

[Jason Dillon]

Its been a long time... still waiting for a release so I can use the  
requirePluginVersions rule.  What is holding it back from a release?


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Known problem with SVN 1.5.x and maven-release-plugin?

[Jason Dillon]

Anyone?

--jason


On Thu, Aug 21, 2008 at 3:52 PM, Jason Dillon <[EMAIL PROTECTED]> wrote:
> Seems that with svn 1.4.4 the maven-release-plugin works just fine... whats
> going on with SVN 1.5.x?
>
> --jason
>
>
> On Aug 21, 2008, at 2:15 PM, Jason Dillon wrote:
>
>> I'm having lots of problems using the maven-release-plugin with SVN 1.5.x
>> on my Mac.  I found this thread:
>>
>>
>> http://www.nabble.com/Mac-OS-X-%2B-SVN-1.5.1-%3D-Branch-problem-td19017538.html
>>
>> Didn't find any solution though... except to use SVN 1.4.x, though seems
>> like I can't checkout with 1.4 something which was previously checked in
>> with 1.5.
>>
>> Anyone know what is going on with SVN 1.5 and the release plugin?
>>
>> --jason
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: How to add GMaven archetype muck to the default catalog, or use custom?

[Jason Dillon]

I'm about to leave for Phuket for a few days, will follow up on this  
when I get back.  I'd like to get this sorted... so folks stop  
complaining about them being broken ;-)


--jason


On Aug 20, 2008, at 2:53 PM, Raphaël Piéroni wrote:


Hi Jason,

To have gmaven archetypes in the internal catalog, please add the
archetypes to the list (on mavenuser's confluence)
It will be taken into account on the next release, as i take care of
generating the internal catalog from this list before any release.

Meanwhile, you can create a catalog file. take the internal catalog as
an example (in archetype-common project/ src/main/resources IIRC)
in a catalog if you don't define a repository URL, the base URL of the
catalog is assumed to be the root of the repository.

If you need any help on this, please just ask for help.


Regards,


Raphaël

PS to any one interrested, i would like to make a release 2.0-alpha4  
soon


2008/8/20 Jason Dillon <[EMAIL PROTECTED]>:

Hiya, I'm getting lots of user reports of problems using the GMaven
archetypes... could be my fault for not really understanding how  
the new

stuff works fully.  But seems like folks that don't already have the
artifacts in their local repo (most users) can't use them.  I  
_thought_ that

this would simply work for them:


mvn archetype:generate
-DarchetypeGroupId=org.codehaus.groovy.maven.archetypes
-DarchetypeArtifactId=gmaven-archetype-basic -Dversion=1.0-rc-3


I also tried setting {{-DarchetypeCatalog=remote}}, but that fails  
with:



INFO] [archetype:generate]
[INFO] Generating project in Interactive mode
[WARNING] Error reading archetype catalog http://repo1.maven.org/maven2
org.apache.maven.wagon.ResourceDoesNotExistException: Unable to  
locate

resource in repository
  at
org 
.apache 
.maven 
.wagon 
.providers 
.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java: 
100)

  at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68)
  at
org 
.apache 
.maven 
.archetype 
.source 
.RemoteCatalogArchetypeDataSource 
.getArchetypeCatalog(RemoteCatalogArchetypeDataSource.java:74)

  at
org 
.apache 
.maven 
.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java: 
203)

  at
org 
.apache 
.maven 
.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java: 
192)

  at
org 
.apache 
.maven 
.archetype 
.ui 
.DefaultArchetypeSelector 
.getArchetypesByCatalog(DefaultArchetypeSelector.java:244)

  at
org 
.apache 
.maven 
.archetype 
.ui 
.DefaultArchetypeSelector 
.selectArchetype(DefaultArchetypeSelector.java:74)

  at
org 
.apache 
.maven 
.archetype 
.mojos 
.CreateProjectFromArchetypeMojo 
.execute(CreateProjectFromArchetypeMojo.java:180)

  at
org 
.apache 
.maven 
.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java: 
451)

  at
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeGoals(DefaultLifecycleExecutor.java:558)

  at
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)

  at
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java: 
482)

  at
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)

  at
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeTaskSegments(DefaultLifecycleExecutor.java:227)

  at
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)
  at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java: 
336)

  at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
  at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
  at
sun 
.reflect 
.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)

  at
sun 
.reflect 
.DelegatingMethodAccessorImpl 
.invoke(DelegatingMethodAccessorImpl.java:25)

  at java.lang.reflect.Method.invoke(Method.java:585)
  at
org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
  at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
  at
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
  at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.io.FileNotFoundException:
http://repo1.maven.org/maven2/archetype-catalog.xml
  at
sun 
.net 
.www 
.protocol 
.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1168)

  at
org 
.apache 
.maven 
.wagon 
.providers 
.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java: 
83)

  ... 25 more
[WARNING] Specified archetype not found.
[INFO] No archetype defined. Using maven-archetype-quickstart
(org.apache.maven.archetypes:maven-archetype-quickstart:1.0)


* * *

So, my question is how can a user use the new arch

Re: How to add GMaven archetype muck to the default catalog, or use custom?

[Jason Dillon]

On Aug 20, 2008, at 11:35 AM, Jason van Zyl wrote:

Do your archetypes refer to repositories that you defined?


Not sure what you mean... :-\

--jason




On 19-Aug-08, at 8:36 PM, Jason Dillon wrote:

Hiya, I'm getting lots of user reports of problems using the GMaven  
archetypes... could be my fault for not really understanding how  
the new stuff works fully.  But seems like folks that don't already  
have the artifacts in their local repo (most users) can't use  
them.  I _thought_ that this would simply work for them:



mvn archetype:generate - 
DarchetypeGroupId=org.codehaus.groovy.maven.archetypes - 
DarchetypeArtifactId=gmaven-archetype-basic -Dversion=1.0-rc-3



I also tried setting {{-DarchetypeCatalog=remote}}, but that fails  
with:



INFO] [archetype:generate]
[INFO] Generating project in Interactive mode
[WARNING] Error reading archetype catalog http://repo1.maven.org/maven2
org.apache.maven.wagon.ResourceDoesNotExistException: Unable to  
locate resource in repository
	at  
org 
.apache 
.maven 
.wagon 
.providers 
.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java: 
100)

at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68)
	at  
org 
.apache 
.maven 
.archetype 
.source 
.RemoteCatalogArchetypeDataSource 
.getArchetypeCatalog(RemoteCatalogArchetypeDataSource.java:74)
	at  
org 
.apache 
.maven 
.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java: 
203)
	at  
org 
.apache 
.maven 
.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java: 
192)
	at  
org 
.apache 
.maven 
.archetype 
.ui 
.DefaultArchetypeSelector 
.getArchetypesByCatalog(DefaultArchetypeSelector.java:244)
	at  
org 
.apache 
.maven 
.archetype 
.ui 
.DefaultArchetypeSelector 
.selectArchetype(DefaultArchetypeSelector.java:74)
	at  
org 
.apache 
.maven 
.archetype 
.mojos 
.CreateProjectFromArchetypeMojo 
.execute(CreateProjectFromArchetypeMojo.java:180)
	at  
org 
.apache 
.maven 
.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java: 
451)
	at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeGoals(DefaultLifecycleExecutor.java:558)
	at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
	at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java: 
482)
	at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
	at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeTaskSegments(DefaultLifecycleExecutor.java:227)
	at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at  
sun 
.reflect 
.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
	at  
sun 
.reflect 
.DelegatingMethodAccessorImpl 
.invoke(DelegatingMethodAccessorImpl.java:25)

at java.lang.reflect.Method.invoke(Method.java:585)
	at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java: 
315)

at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
	at  
org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.io.FileNotFoundException: 
http://repo1.maven.org/maven2/archetype-catalog.xml
	at  
sun 
.net 
.www 
.protocol 
.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1168)
	at  
org 
.apache 
.maven 
.wagon 
.providers 
.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java: 
83)

... 25 more
[WARNING] Specified archetype not found.
[INFO] No archetype defined. Using maven-archetype-quickstart  
(org.apache.maven.archetypes:maven-archetype-quickstart:1.0)



* * *

So, my question is how can a user use the new archetype plugin with  
an archetype that is not in the "internal" catalog?


I have played a little with the "local" catalog, which seems to  
allow the GMaven archetypes to resolve, though it ignores the  
version (if I ask for a release, but I have previously built a  
snapshot, I get the snapshot version).


Anyways, I could use some advise on what is the proper/supported  
way to use custom archetypes.  I have 2 of them right now:


  
http://repo1.maven.org/maven2/org/codehaus/groovy/maven/archetypes/gmaven-archetype-basic/
  
http://repo1.maven.org/maven2/org/codehaus/groovy/maven/archetypes/gmaven-archetype-mojo/

Thanks,

--jason



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: 

Re: Known problem with SVN 1.5.x and maven-release-plugin?

[Jason Dillon]

Seems that with svn 1.4.4 the maven-release-plugin works just fine...  
whats going on with SVN 1.5.x?


--jason


On Aug 21, 2008, at 2:15 PM, Jason Dillon wrote:

I'm having lots of problems using the maven-release-plugin with SVN  
1.5.x on my Mac.  I found this thread:


   
http://www.nabble.com/Mac-OS-X-%2B-SVN-1.5.1-%3D-Branch-problem-td19017538.html

Didn't find any solution though... except to use SVN 1.4.x, though  
seems like I can't checkout with 1.4 something which was previously  
checked in with 1.5.


Anyone know what is going on with SVN 1.5 and the release plugin?

--jason



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Known problem with SVN 1.5.x and maven-release-plugin?

[Jason Dillon]

I'm having lots of problems using the maven-release-plugin with SVN  
1.5.x on my Mac.  I found this thread:



http://www.nabble.com/Mac-OS-X-%2B-SVN-1.5.1-%3D-Branch-problem-td19017538.html

Didn't find any solution though... except to use SVN 1.4.x, though  
seems like I can't checkout with 1.4 something which was previously  
checked in with 1.5.


Anyone know what is going on with SVN 1.5 and the release plugin?

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

How to add GMaven archetype muck to the default catalog, or use custom?

[Jason Dillon]

Hiya, I'm getting lots of user reports of problems using the GMaven  
archetypes... could be my fault for not really understanding how the  
new stuff works fully.  But seems like folks that don't already have  
the artifacts in their local repo (most users) can't use them.  I  
_thought_ that this would simply work for them:



mvn archetype:generate - 
DarchetypeGroupId=org.codehaus.groovy.maven.archetypes - 
DarchetypeArtifactId=gmaven-archetype-basic -Dversion=1.0-rc-3



I also tried setting {{-DarchetypeCatalog=remote}}, but that fails with:


INFO] [archetype:generate]
[INFO] Generating project in Interactive mode
[WARNING] Error reading archetype catalog http://repo1.maven.org/maven2
org.apache.maven.wagon.ResourceDoesNotExistException: Unable to locate  
resource in repository
	at  
org 
.apache 
.maven 
.wagon 
.providers 
.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:100)

at org.apache.maven.wagon.StreamWagon.get(StreamWagon.java:68)
	at  
org 
.apache 
.maven 
.archetype 
.source 
.RemoteCatalogArchetypeDataSource 
.getArchetypeCatalog(RemoteCatalogArchetypeDataSource.java:74)
	at  
org 
.apache 
.maven 
.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java:203)
	at  
org 
.apache 
.maven 
.archetype.DefaultArchetype.getRemoteCatalog(DefaultArchetype.java:192)
	at  
org 
.apache 
.maven 
.archetype 
.ui 
.DefaultArchetypeSelector 
.getArchetypesByCatalog(DefaultArchetypeSelector.java:244)
	at  
org 
.apache 
.maven 
.archetype 
.ui 
.DefaultArchetypeSelector 
.selectArchetype(DefaultArchetypeSelector.java:74)
	at  
org 
.apache 
.maven 
.archetype 
.mojos 
.CreateProjectFromArchetypeMojo 
.execute(CreateProjectFromArchetypeMojo.java:180)
	at  
org 
.apache 
.maven 
.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:451)
	at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java: 
558)
	at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeStandaloneGoal(DefaultLifecycleExecutor.java:512)
	at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:482)
	at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
	at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor 
.executeTaskSegments(DefaultLifecycleExecutor.java:227)
	at  
org 
.apache 
.maven 
.lifecycle 
.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:142)

at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:336)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:129)
at org.apache.maven.cli.MavenCli.main(MavenCli.java:287)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at  
sun 
.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 
39)
	at  
sun 
.reflect 
.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 
25)

at java.lang.reflect.Method.invoke(Method.java:585)
at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
at org.codehaus.classworlds.Launcher.launch(Launcher.java:255)
	at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java: 
430)

at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: java.io.FileNotFoundException: 
http://repo1.maven.org/maven2/archetype-catalog.xml
	at  
sun 
.net 
.www 
.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java: 
1168)
	at  
org 
.apache 
.maven 
.wagon 
.providers 
.http.LightweightHttpWagon.fillInputData(LightweightHttpWagon.java:83)

... 25 more
[WARNING] Specified archetype not found.
[INFO] No archetype defined. Using maven-archetype-quickstart  
(org.apache.maven.archetypes:maven-archetype-quickstart:1.0)



 * * *

So, my question is how can a user use the new archetype plugin with an  
archetype that is not in the "internal" catalog?


I have played a little with the "local" catalog, which seems to allow  
the GMaven archetypes to resolve, though it ignores the version (if I  
ask for a release, but I have previously built a snapshot, I get the  
snapshot version).


Anyways, I could use some advise on what is the proper/supported way  
to use custom archetypes.  I have 2 of them right now:



http://repo1.maven.org/maven2/org/codehaus/groovy/maven/archetypes/gmaven-archetype-basic/

http://repo1.maven.org/maven2/org/codehaus/groovy/maven/archetypes/gmaven-archetype-mojo/

Thanks,

--jason



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] GMaven 1.0-rc-3 Released

[Jason Dillon]

Its been a while, but its finally out.  Read about it more here:

http://groovy.codehaus.org/GMaven+-+1.0-rc-3+Release

Will probably take a few hours to sync to central.  I'm pushing out  
the new generated documentation now, which will take much longer I  
suspect.


Cheers,

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Decent size icon for Nexus?

[Jason Dillon]

yay!  thx :-)

--jason


On Aug 14, 2008, at 10:57 PM, Eugene Kuleshov wrote:




Jason Dillon wrote:


Is there a decent size icon for Nexus somewhere... suitable for using
to setup a SSB via Fluidapp?



 Jason, yo can try this one
http://www.nabble.com/file/p18984465/nx-big.png nx-big.png

 regards,
 Eugene


--
View this message in context: 
http://www.nabble.com/Decent-size-icon-for-Nexus--tp18902224p18984465.html
Sent from the Maven Developers mailing list archive at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Plugin to notify about updated plugins

[Jason Dillon]

Is there any nice plugin which I can run which will look at the  
current project and tell me which plugins are out of date?


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [groovy-user] New GMaven 1.0-rc-3-SNAPSHOT deployed; Please Test

[Jason Dillon]

Okay, so far no negative news.  If this is still the case tomorrow I  
am going to publish the release... so if you have any problems with  
the latest snapshot, lemme know NOW :-)


--jason


On Aug 12, 2008, at 8:08 AM, Garvin LeClaire wrote:

Looks good to me.   I am using it for the Maven Findbugs plugin as  
well as the SHITTY plugin and all is fine here.


Regards,



Garvin LeClaire
[EMAIL PROTECTED]



Andres Almiray wrote:


Will give it a try with GB 0.7-SNAPSHOT and let you know. Like the  
new

console upgrade :-)


Jason Dillon wrote:


I've just deployed a new set of snapshots for GMaven 1.0-rc-3-
SNAPSHOT.  This contains a bunch of stuff.  See the road-map for  
more

details:


http://jira.codehaus.org/browse/MGROOVY?report=com.atlassian.jira.plugin.system.project:roadmap-panel

Anyways, just wanted folks to give this new snap a test and if its  
all
happy happy I'm going to release it shortly.  So, please, please  
give

it a try and let me know if anything breaks.

Thanks,

--jason

New GMaven 1.0-rc-3-SNAPSHOT deployed; Please Test

[Jason Dillon]

I've just deployed a new set of snapshots for GMaven 1.0-rc-3- 
SNAPSHOT.  This contains a bunch of stuff.  See the road-map for more  
details:



http://jira.codehaus.org/browse/MGROOVY?report=com.atlassian.jira.plugin.system.project:roadmap-panel

Anyways, just wanted folks to give this new snap a test and if its all  
happy happy I'm going to release it shortly.  So, please, please give  
it a try and let me know if anything breaks.


Thanks,

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Decent size icon for Nexus?

[Jason Dillon]

Um, sure its Jetty... but thats the *server* not the console, which  
was what I was talking about.


--jason


On Aug 9, 2008, at 11:10 PM, Brian E. Fox wrote:


Nexus already is standalone with the built in Jettybut the Nx icon
was made for the 16x16 icon size, we haven't yet made anything larger.

-Original Message-
From: Jason Dillon [mailto:[EMAIL PROTECTED] On Behalf Of Jason
Dillon
Sent: Saturday, August 09, 2008 1:52 AM
To: Maven Developers List
Subject: Re: Decent size icon for Nexus?

You haven't played with Fluid yet?

http://fluidapp.com/

Its pimp, lets you make a web-app into more of a standalone  
application.


--jason


On Aug 9, 2008, at 12:15 PM, Jason van Zyl wrote:


I have no idea what you're talking about ...

Sent from my iPhone

On Aug 8, 2008, at 9:50 PM, Jason Dillon <[EMAIL PROTECTED]> wrote:


Is there a decent size icon for Nexus somewhere... suitable for
using to setup a SSB via Fluidapp?

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Decent size icon for Nexus?

[Jason Dillon]

You haven't played with Fluid yet?

http://fluidapp.com/

Its pimp, lets you make a web-app into more of a standalone application.

--jason


On Aug 9, 2008, at 12:15 PM, Jason van Zyl wrote:


I have no idea what you're talking about ...

Sent from my iPhone

On Aug 8, 2008, at 9:50 PM, Jason Dillon <[EMAIL PROTECTED]> wrote:

Is there a decent size icon for Nexus somewhere... suitable for  
using to setup a SSB via Fluidapp?


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Decent size icon for Nexus?

[Jason Dillon]

Is there a decent size icon for Nexus somewhere... suitable for using  
to setup a SSB via Fluidapp?


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release maven-artifact-3.0-alpha-1

[Jason Dillon]

+1

--jason


On Jul 18, 2008, at 8:58 AM, Oleg Gusakov wrote:


Hi,

16 issues fixed, no outstanding

Staging repo:
http://repository.sonatype.org:8081/nexus/content/repositories/staged-releases/maven-artifact/org/apache/maven/artifact/maven-artifact/3.0-alpha-1/

Staging site:
http://maven.apache.org/ref/maven-artifact-3.0-alpha-1/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Pom user-configured goal+phase aliases

[Jason Dillon]

Just had a thought, would be nice if the pom exposed someway to define  
aliases for a set of goals/phases.


This would allow project specific names to be used to invoke a set of  
standard maven phases or a set of plugins.


Like I might want o have a "release" alias, which actually invokes:

mvn clean release:prepare release:preform

Or a "rebuild" alias which actually invokes:

mvn clean install

With pom configuration something like:

8<




rebuild

clean
install





>8

Just a thought...

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Commit Privs for Oleg Gusakov

[Jason Dillon]

+1

--jason


On Jun 13, 2008, at 9:30 PM, John Casey wrote:


+1

-john

Jason van Zyl wrote:

Hi,

Oleg has been contributing patches to the artifact mechanism for  
well over 6 months and has gone through some steps to look at graph- 
based resolution, and subsequently moved on to the boolean solver  
method of performing version selection in artifact resolution. This  
is the method that p2 is using in Eclipse, and Daniel Le Berre (the  
author of the SAT4J library we are using) has been kind enough to  
introduce us to some of the Linux distro folks who are using the  
same methods to resolve ranges in their package managers which is  
not an easy problem.


Oleg has been studying the math and working with Daniel and I  
believe has provided us with a path to world-class artifact  
resolution. We need to get rid of what we have because there is  
simply no way to do ranges correctly without some form of solver,  
it's just impossible and this is generally accepted by the  
community of people dealing with dependency and packaging problems.


I've been applying Oleg's patches for a long time, and I would like  
to give him commit access to continue his work which I believe is  
part of the future for Maven's artifact resolution mechanism.


+1

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

We know what we are, but know not what we may be.

-- Shakespeare



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
John Casey
Developer, PMC Member - Apache Maven (http://maven.apache.org)
Blog: http://www.ejlife.net/blogs/buildchimp/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

New snaps for components 2.1 and maven-artifact please?

[Jason Dillon]

Can I please get new snaps of the components/trunk and artifact/trunk  
deployed please?


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Any tools to scan maven-artifact repositories?

[Jason Dillon]

Are there any available tools (API level) to point at a maven  
repository and navigate through it?  (remote or local)?  Perhaps to  
scan for specific artifact types or something like that?


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [SURVEY] How does your team retrieve artifacts?

[Jason Dillon]

Um, why would you want to only support http?

--jason


On May 21, 2008, at 2:30 PM, Brett Porter wrote:


Hi Jason,

Is this related to your previous suggestion that we should only
support HTTP in Maven 2.1, or is there some other objective in mind?

Thanks,
Brett

2008/5/21 Jason van Zyl <[EMAIL PROTECTED]>:

Hi,

I'm just trying to get some data on what protocol is used to retrieve
artifacts. This question strictly relates to what you use for  
retrieval.
Most people I have seen use a web server or a shared network drive,  
but I'd

like to get some feedback.

[ ] Our team uses HTTP to retrieve our artifacts
[ ] Our team intends to use HTTP to retrieve our artifacts
[ ] Our team uses the filesystem
[ ] Our team does not use HTTP or the filesystem because   
please say

what protocol you use and the reason

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

A language that doesn't affect the way you think about programming  
is not

worth knowing.

— Alan Perlis




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






--
Brett Porter
Blog: http://blogs.exist.com/bporter/

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [SURVEY] How does your team retrieve artifacts?

[Jason Dillon]

Mostly using http or https, though for the Geronimo TCK builds we are
using sftp for a private repository... mostly because it was less
work/infrastructure to setup https and than it was to re-use the
existing ssh channels.

The Geronimo build also use the file protocol internally to hook up
some patched artifacts.

--jason


On Wed, May 21, 2008 at 8:26 PM, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>
> On 21-May-08, at 12:30 AM, Brett Porter wrote:
>
>> Hi Jason,
>>
>> Is this related to your previous suggestion that we should only
>> support HTTP in Maven 2.1, or is there some other objective in mind?
>>
>
> I want to first know what users are doing before suggesting anything.
>
>> Thanks,
>> Brett
>>
>> 2008/5/21 Jason van Zyl <[EMAIL PROTECTED]>:
>>>
>>> Hi,
>>>
>>> I'm just trying to get some data on what protocol is used to retrieve
>>> artifacts. This question strictly relates to what you use for retrieval.
>>> Most people I have seen use a web server or a shared network drive, but
>>> I'd
>>> like to get some feedback.
>>>
>>> [ ] Our team uses HTTP to retrieve our artifacts
>>> [ ] Our team intends to use HTTP to retrieve our artifacts
>>> [ ] Our team uses the filesystem
>>> [ ] Our team does not use HTTP or the filesystem because  please say
>>> what protocol you use and the reason
>>>
>>> Thanks,
>>>
>>> Jason
>>>
>>> --
>>> Jason van Zyl
>>> Founder,  Apache Maven
>>> jason at sonatype dot com
>>> --
>>>
>>> A language that doesn't affect the way you think about programming is not
>>> worth knowing.
>>>
>>> — Alan Perlis
>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>>
>>
>> --
>> Brett Porter
>> Blog: http://blogs.exist.com/bporter/
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> --
>
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Is there a JIRA project for maven-artifact?

[Jason Dillon]

Thanks, you should update its category so it shows up in the Maven  
Technologies group list.


--jason


On May 21, 2008, at 10:09 PM, Brett Porter wrote:


MARTIFACT

On 22/05/2008, at 1:07 AM, Jason Dillon wrote:

I've got a patch waiting which adds type information for collection  
bits it uses... dunno where to post it.


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Status of Shade plugin....

[Jason Dillon]

Please :-)  Sun is too bright, bring on the shade.

--jason


On May 21, 2008, at 10:07 PM, Jason van Zyl wrote:

I think if that many issues are resolved then release it. Can always  
do another release.


On 20-May-08, at 11:39 AM, Daniel Kulp wrote:



A bunch of bugs have been fixed in the shade plugin recently.   I'm  
thinking of doing a 1.1 release shortly. Does anyone have other  
things to add into the release?   If not, I'll proceed with a  
release.




** Bug
* [MSHADE-23] - ${basedir} is wrong after running shade plugin
* [MSHADE-24] - Use proper file encoding when generating dependency  
reduced POM
* [MSHADE-25] - Use proper encoding when reading/writing component  
descriptor
* [MSHADE-26] - Fix case-insensitive string comparisions in  
resource transformers

* [MSHADE-29] - Documentation has invalid xml
* [MSHADE-31] - When promoteTransitiveDependencies=true, all  
 are stripped from the dependency-reduced-pom
* [MSHADE-34] - Shade includes both .jar and -test.jars when only  
the .jar was needed


** Improvement
* [MSHADE-27] - Allow to configure file encoding for processing of  
NOTICE file
* [MSHADE-28] - Add full support for glob patterns in relocator  
exclusions



---
Daniel Kulp
[EMAIL PROTECTED]
http://www.dankulp.com/blog





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

We all have problems. How we deal with them is a measure of our worth.

-- Unknown



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

maven-artifact 3.0-SNAPSHOT prefers dependencies repositories?

[Jason Dillon]

Hi, I've finally gotten around to integration maven-artifact w/ 
GShell... and I noticed that when resolving artifacts it tends to  
prefer  the repositories in dependency poms?  Maybe its not a maven- 
artifact thingy, but a maven-project thingy as I'm re-using the Maven  
metadata source thingy.


But I have noticed that I see it trying to download bits from remote  
repositories when my local file:// repository (for testing) seems to  
have everything it needs already.


Is there a reason that repos defined in a deps pom are preferred?

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Is there a JIRA project for maven-artifact?

[Jason Dillon]

I've got a patch waiting which adds type information for collection  
bits it uses... dunno where to post it.


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Non-retrotranslated maven-artifact 3.0?

[Jason Dillon]

BTW, the new maven-artifact api kicks ass, so much easier to use  
IMO... :-)


--jason


On May 16, 2008, at 9:40 PM, Jason van Zyl wrote:

I've removed the retrotranslation from maven-artifact and deployed a  
snapshot so give that a whirl.


On 16-May-08, at 4:44 AM, Jason Dillon wrote:

Hi folks, can we change the maven-artifact 3.0 bits to _attach_  
instead of _replace_ when retrotranslating?  I'm consuming 3.0 for  
GShell, which already requires Java 5, so the retrotranslation just  
tacks on ~600k of stuff that I don't really need.


I'd like to just use the pure Java5 version, and when using attach,  
the retrotranslator-m-p will create a translated jar with a jdk14  
classifier in addition to the untranslated artifact.


Please?

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will  
come

and sit softly on your shoulder ...

-- Thoreau



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Non-retrotranslated maven-artifact 3.0?

[Jason Dillon]

Did you commit this to svn, I don't see any changes...

--jason


On May 16, 2008, at 9:40 PM, Jason van Zyl wrote:

I've removed the retrotranslation from maven-artifact and deployed a  
snapshot so give that a whirl.


On 16-May-08, at 4:44 AM, Jason Dillon wrote:

Hi folks, can we change the maven-artifact 3.0 bits to _attach_  
instead of _replace_ when retrotranslating?  I'm consuming 3.0 for  
GShell, which already requires Java 5, so the retrotranslation just  
tacks on ~600k of stuff that I don't really need.


I'd like to just use the pure Java5 version, and when using attach,  
the retrotranslator-m-p will create a translated jar with a jdk14  
classifier in addition to the untranslated artifact.


Please?

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will  
come

and sit softly on your shoulder ...

-- Thoreau



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Non-retrotranslated maven-artifact 3.0?

[Jason Dillon]

Hi folks, can we change the maven-artifact 3.0 bits to _attach_  
instead of _replace_ when retrotranslating?  I'm consuming 3.0 for  
GShell, which already requires Java 5, so the retrotranslation just  
tacks on ~600k of stuff that I don't really need.


I'd like to just use the pure Java5 version, and when using attach,  
the retrotranslator-m-p will create a translated jar with a jdk14  
classifier in addition to the untranslated artifact.


Please?

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Release enforcer 1.0 ?

[Jason Dillon]

Eh, seems like a simple fix as its only documentation.

I'd like to see 1.0 out, or perhaps a 1.0-rc-1 ASAP... regardless of  
the documentation issues.


--jason


On May 16, 2008, at 4:36 PM, Jerome Lacoste wrote:

On Fri, May 16, 2008 at 10:27 AM, Arnaud HERITIER  
<[EMAIL PROTECTED]> wrote:

Hi Team,

Can we release enforcer 1.0 ?
Everything is fixed in the roadmap (
https://jira.codehaus.org/browse/MENFORCER?report=com.atlassian.jira.plugin.system.project:roadmap-panel)
and it fixes several important issues like MENFORCER-11 & 12.
If nobody have the time to do it, I can.


There seems to be at least one documentation issue: MENFORCER-31

Shouldn't it be fixed first ?

J

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [proposal] java5 as minimal runtime for maven 2.1 (and 2.0.10 ?)

[Jason Dillon]

Perhaps 2.1 needs to be changed to 2.2 and then 2.1 can be used for  
what would be 2.0.10 + Java5


--jason


On May 4, 2008, at 6:32 PM, Marat Radchenko wrote:


+1 for 2.1, -1 for 2.0.10
On 5/4/08, nicolas de loof <[EMAIL PROTECTED]> wrote:

Hello,

As you can read at http://java.sun.com/j2se/1.4.2/
*" J2SE 1.4.2 is in its Java Technology End of Life (EOL)  
transition period*.
The EOL transition period began Dec, 11 2006 and will complete  
October 30th,

2008"

I don't think we have plan yet to release maven 2.1, so I think it  
would be

a valid to require java 1.5 as minimal runtime.

Main beneficts (IMHO) :

- annotation can replace javadoc-style IoC an Maven plugin  
declarations

(code allready available :
http://docs.codehaus.org/display/MAVEN/Java+5+Annotations+for 
+Plugins)
- jsr-250 annotations can replace some plexus interfaces  
( LogEnabled ->
@Resource('log') , Initializable --> @PostConstruct ...) and make  
component
more "standard" and accessible to developpers without plexus  
knowledge.

- generics can make the maven model more comprehensible. The current
"Collection project.getArtifacts()" is not really clear and the fiew
available javadoc don't help a lot.

Other possible improvements :

- plugin test tool could use jUnit 4 runners to create something  
comparable

to spring-test-context :
annotate your plugin test class with  
@Runwith( "MavenPluginTestRunner" )

@Pom( "myTestPom.xml" )
and the test will prepare the plugin set in the test pom and inject  
it in

the test class.
- benefict from java.util.concurrent to do some tasks in parallel ?  
Example

: dependencies downloading
- any other ?


WDYT ?


Nicolas.



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Maven archetype plugin version 2.0-alpha-3 [take 3]

[Jason Dillon]

+1

--jason


On Apr 25, 2008, at 5:10 AM, Raphaël Piéroni wrote:


Hi,

We solved 22 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14088

Staging repo:
http://people.apache.org/~rafale/archetype-stage-repository/

Staging site:
http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-3/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Raphaël



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: What does this WARNING mean?

[Jason Dillon]

Thanks... I'm not sure why that is a warn either... :-\

--jason


On Apr 24, 2008, at 4:40 AM, Hervé BOUTEMY wrote:


where:
http://maven.apache.org/ref/2.0.9/maven-project/xref/org/apache/maven/project/DefaultMavenProjectBuilder.html#525

hope this will help to understand why: I don't really know

Hervé

Le mercredi 23 avril 2008, Jason Dillon a écrit :

Anyone know what this warning means:


[WARNING] Attempting to build MavenProject instance for Artifact
(org.codehaus.mojo:ianal-maven-plugin:1.0-alpha-1-20080423.162027-1)
of type: maven-plugin; constructing POM artifact instead. ?


Not specific to the ianal plugin, but gmaven plugins spit this out,
probably from some of the runtime loading magic it does... but I  
don't

know why or where it happens.

Anyone know?

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

What does this WARNING mean?

[Jason Dillon]

Anyone know what this warning means:


[WARNING] Attempting to build MavenProject instance for Artifact  
(org.codehaus.mojo:ianal-maven-plugin:1.0-alpha-1-20080423.162027-1)  
of type: maven-plugin; constructing POM artifact instead. ?



Not specific to the ianal plugin, but gmaven plugins spit this out,  
probably from some of the runtime loading magic it does... but I don't  
know why or where it happens.


Anyone know?

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-3 [take 2]

[Jason Dillon]

+1

--jason


On Apr 19, 2008, at 1:39 AM, Raphaël Piéroni wrote:


Hi,

We solved 22 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14088

Staging repo:
http://people.apache.org/~rafale/archetype-stage-repository/

Staging site:
http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-3/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Raphaël



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-3

[Jason Dillon]

+1

---jason


On Apr 11, 2008, at 5:22 AM, Raphaël Piéroni wrote:


Hi,

We solved 20 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11095&styleName=Html&version=14088

Staging repo:
http://people.apache.org/~rafale/archetype-stage-repository/

Staging site:
http://maven.apache.org/plugins/maven-archetype-plugin-2.0-alpha-3

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1


Regards,

Raphaël



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Maven 2.0.9

[Jason Dillon]

+1

--jason


On Apr 7, 2008, at 11:42 PM, Brian E. Fox wrote:

Time to vote on the final Maven 2.0.9 Release. We went through 8  
Release

Candidates and fixed all know regressions from 2.0.8 to 2.0.9 during
that time. Note that there were no source changes between RC8 and this
final build.



Release is staged at:

http://people.apache.org/~brianf/stage-2.0.9



Binaries are here:

http://people.apache.org/~brianf/stage-2.0.9/org/apache/maven/apache-mav
en/2.0.9/



List of issues fixed:

Release Notes - Maven 2 - Version 2.0.9





** Bug

   * [MNG-1412] - dependency sorting in classpath

   * [MNG-1914] - Wrong url in error message when using a mirror

   * [MNG-2123] - NullPointerException when a dependency uses version
range and another uses an actual version incompatible with that range

   * [MNG-2145] - Plugins' dependencies are not always checked

   * [MNG-2178] - incorrect M2_HOME guess in mvn.bat

   * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
profiles section is missing or empty

   * [MNG-2339] - ${project.*} are interpreted in the wrong place

   * [MNG-2744] - checksum comparison should be case-insensitive

   * [MNG-2809] - Can't activate a profile by checking for the  
presence

of a file in ${user.home}

   * [MNG-2848] - Environment variables in profile activation not
working

   * [MNG-2861] - NullPointerException in DefaultArtifactCollector for
relocated resolvedArtifacts with different version ranges and  
available

versions.

   * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo()  
if

there's no mojo in pom.xml

   * [MNG-2928] - Null pointer exeception when introducing version
range [major.minor.build-SNAPSHOT,)

   * [MNG-2972] - Ignores version of plugin dependency specified in my
pom

   * [MNG-3086] - NullPointerException in
ResolutionNode.getTrail(ResolutionNode.java:136)

   * [MNG-3099] - Profiles ignored when working with non-projects  
(such

as archetype:create)

   * [MNG-3111] - Classpath order incorrect

   * [MNG-3156] - NullPointerException with mvn dependency:sources

   * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor

   * [MNG-3259] - Regression: Maven drops dependencies in multi-module
build

   * [MNG-3286] - execution.inherited field is ignored

   * [MNG-3288] - Invalid systemPath allows build to continue--failing
in later phase.

   * [MNG-3296] - mvn.bat looses error code on windows NT type
platforms

   * [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set

   * [MNG-3316] - Barfs at attribues named .*encoding

   * [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP
with Novell login

   * [MNG-3355] - CLONE -${pom.build.sourceDirectory} and
${pom.build.testSourceDirectory} no longer recognized

   * [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat

   * [MNG-3394] - Plugin versions inherited via 
cannot be overriden by . section of sub modules

   * [MNG-3396] - Managed versions dont affect over constrained ranges

   * [MNG-3400] - MavenProject is not extensible

   * [MNG-3405] - "Checking for updates from repository" logging  
should

not display if WagonManager is offline

   * [MNG-3410] - Managed versions in plugins are not considered when
using them

   * [MNG-3415] - Transfer errors cause junk metadata in the local  
repo


   * [MNG-3426] - regression :  in plugin configuration
doesn't override plugin classpath

   * [MNG-3430] - Toolchain doesn't match Toolchain extensions

   * [MNG-3431] - Pom Extensions not supported for Toolchains

   * [MNG-3439] - incorrect child dependency selected when parent is
not selected

   * [MNG-3441] - Maven should always retrieve metadata to be updated
from the deployment repository

   * [MNG-3460] - org.apache.maven.profiles.DefaultProfileManagerTest
fails if you use a different local repo

   * [MNG-3464] - maven-toolchains missing from final binary.. need to
update the assembly

   * [MNG-3473] - site generation with 2.0.9 and plugin:report (2.4
ONLY) is broken

   * [MNG-3484] - INT_MAVEN_OPTS are not quoted in mvnDebug which
causes issues on some shells

   * [MNG-3485] - unable to override wagons that are bundled with a
different version via extensions

   * [MNG-3494] - local pom dependencies should get injected before
inherited dependencies

   * [MNG-3495] - NPE  at
org 
.apache.maven.wagon.repository.Repository.hashCode(Repository.java:24

1)



** Improvement

   * [MNG-428] - Japanese message resource

   * [MNG-2881] - Improve logging when downloading snapshots in  
offline

mode

   * [MNG-3279] - Support Exception Chaining for MojoFailureException

   * [MNG-3318] - ActiveProjectArtifact should have appropriate equals
and hashCode methods

   * [MNG-3331] - Normalize paths to sub modules

   * [MNG-3388] - DefaultPluginManager needs to catch LinkageError

   * [MNG-3395] - Default core plugin versions in the superpom.

   * [MNG-3442] - Add explicit resource bundle for English

   * [MNG-3461] - Enhance Mirr

Re: problem with site-plugin 2.0-beta-6

[Jason Dillon]

Are you using beta-6 w/o any problems?  I can't get it to generate  
proper links at all :-(


--jason


On Apr 3, 2008, at 3:26 AM, Brian E. Fox wrote:

I think it's safer to leave it at beta-6. Most people aren't  
expressing any issues and if anyone has trouble, they can manually  
lock to beta-5. This is safer than potentially downgrading everyone.


-Original Message-
From: Bouiaw [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 02, 2008 11:51 AM
To: Maven Developers List
Subject: Re: problem with site-plugin 2.0-beta-6

Hi,

Just an information that is important (from my point of view) to know.

Site plugin beta-6 has an important issue (
http://jira.codehaus.org/browse/MSITE-270) : with multi modules  
projects,

menus are wrong, making site plugin unusable for the majority of
multi-modules sites.

beta-5 plugin has not this important issue.

Regards,
Sébastien Deleuze

On Wed, Apr 2, 2008 at 4:24 PM, Brian E. Fox  
<[EMAIL PROTECTED]>

wrote:

2.0.9 defines the plugins in the superpom now. He probably have  
beta-5
kicking around from who-knows-when. We can drop back to beta-5 in  
2.0.9

but that may potentially downgrade some users.

-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 02, 2008 4:34 AM
To: Maven Developers List
Subject: Re: problem with site-plugin 2.0-beta-6

I've had problems with beta-6 too - I wonder if we should stick with
beta-5 in 2.0.9?

I'm unsure why 2.0.8 was using beta-5 while 2.0.9 uses beta-6, as
David said that it was not specified in his POMs on IRC.

Cheers,
Brett

On 02/04/2008, at 7:18 PM, [EMAIL PROTECTED] wrote:



Ran 209rc6 and as a side effect the site-plugin version got resolved
to 2.0-beta-6 which gave me the following problem:


[DEBUG] Configuring mojo 'org.apache.maven.plugins:maven-site- 
plugin:

2.0-beta-6:attach-descriptor' -->
[DEBUG]   (f) artifact = no.dnbnor.api:api:pom:1.3-SNAPSHOT
[DEBUG]   (f) basedir = /tmp/dnbnorapi-trunk
[DEBUG]   (f) inputEncoding = ISO-8859-1
[DEBUG]   (f) localRepository = [local] ->

file:///heim/ab62939/.m2/repository

[DEBUG]   (f) locales = no,en
[DEBUG]   (f) outputEncoding = ISO-8859-1
[DEBUG]   (f) project = MavenProject: no.dnbnor.api:api:1.3-SNAPSHOT
@ /tmp/dnbnorapi-trunk/pom.xml
[DEBUG]   (f) reactorProjects = [MavenProject: no.dnbnor.api:api: 
1.3-

SNAPSHOT @ /tmp/dnbnorapi-trunk/pom.xml, MavenProject:
no.dnbnor.api:dnbnorapi-common:1.3-SNAPSHOT @ /tmp/dnbnorapi-trunk/
dnbnorapi-common/pom.xml, MavenProject: no.dnbnor.api:dnbnorapi-
springutils:1.3-SNAPSHOT @ /tmp/dnbnorapi-trunk/dnbnorapi-
springutils/pom.xml, MavenProject: no.dnbnor.api:dnbnorapi-server:
1.3-SNAPSHOT @ /tmp/dnbnorapi-trunk/dnbnorapi-server/pom.xml,
MavenProject: no.dnbnor.api:dnbnorapi-war:1.3-SNAPSHOT @ /tmp/
dnbnorapi-trunk/dnbnorapi-war/pom.xml, MavenProject:
no.dnbnor.api:dnbnorapi-ejb:1.3-SNAPSHOT @ /tmp/dnbnorapi-trunk/
dnbnorapi-ejb/pom.xml, MavenProject: no.dnbnor.api:dnbnorapi-mdb: 
1.3-

SNAPSHOT @ /tmp/dnbnorapi-trunk/dnbnorapi-mdb/pom.xml, MavenProject:
no.dnbnor.api:dnbnorapi-ear:1.3-SNAPSHOT @ /tmp/dnbnorapi-trunk/
dnbnorapi-ear/pom.xml, MavenProject: no.dnbnor.api:dnbnorapi-client:
1.3-SNAPSHOT @ /tmp/dnbnorapi-trunk/dnbnorapi-client/pom.xml,
MavenProject: no.dnbnor.api:dnbnorapi-tests:1.3-SNAPSHOT @ /tmp/
dnbnorapi-trunk/dnbnorapi-tests/pom.xml, MavenProject:
no.dnbnor.api:dnbnorapi-performancetest:1.3-SNAPSHOT @ /tmp/
dnbnorapi-trunk/dnbnorapi-performancetest/pom.xml, MavenProject:
no.dnbnor.api:dnbnorapi-maven-plugin:1.3-SNAPSHOT @ /tmp/dnbnorapi-
trunk/dnbnorapi-maven-plugin/pom.xml]
[DEBUG]   (f) siteDirectory = /tmp/dnbnorapi-trunk/src/site
[DEBUG] -- end configuration --
[INFO] [site:attach-descriptor]
[DEBUG] Mapped url: /tmp/dnbnorapi-trunk/src/site to relative path:
src/site
[INFO]




[ERROR] BUILD ERROR
[INFO]




[INFO] Error parsing site descriptor

Embedded error: Unrecognised tag: 'site' (position: START_TAG seen  

xml version="1.0" encoding="ISO-8859-1"?>\r\n... @2:7)
[INFO]




[DEBUG] Trace
org.apache.maven.lifecycle.LifecycleExecutionException: Error
parsing site descriptor
  at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor 
.executeGoals(DefaultLifecycleExecutor.java:

583)
  at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor
.executeGoalWithLifecycle(DefaultLifecycleExecutor.java:499)
  at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:
478)
  at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor
.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:330)
  at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor
.executeTaskSegments(DefaultLifecycleExecutor.java:291)
  at
org
.apache
.maven
.lifecycle
.DefaultLifecycleExecutor.execute

maven-archetype-plugin 2.0-alpha-2 installing .maven-archetype extentions

[Jason Dillon]

Hiya, I'm having some problem getting my archetype module installed  
into my local repository (haven't tried a remote deploy yet) with  
a .jar extention.  It always puts the archive into the repo with  
a .maven-archetype ext, which causes problems when trying to actually  
use the archetype:



[INFO]  


[INFO] Building GMaven Archetypes :: Basic
[INFO]task-segment: [install]
[INFO]  


[INFO] [enforcer:enforce {execution: default}]
[INFO] [remote-resources:process {execution: default}]
[INFO] [resources:resources]
[INFO] Using default encoding to copy filtered resources.
[INFO] [resources:testResources]
[INFO] Using default encoding to copy filtered resources.
[INFO] Setting property: classpath.resource.loader.class =>  
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.

[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.
[INFO] [archetype:jar]
[INFO] [archetype:add-archetype-metadata]
[INFO] [archetype:integration-test]
[INFO] [install:install]
[INFO] Installing /Users/jason/ws/groovy/gmaven/gmaven-archetypes/ 
gmaven-archetype-basic/target/gmaven-archetype-basic-1.0-beta-4- 
SNAPSHOT.jar to /Users/jason/.m2/repository/org/codehaus/groovy/maven/ 
archetypes/gmaven-archetype-basic/1.0-beta-4-SNAPSHOT/gmaven-archetype- 
basic-1.0-beta-4-SNAPSHOT.maven-archetype



I've configured my project with the extension:





org.apache.maven.archetype
archetype-packaging
2.0-alpha-2





And my archetype modules are using the maven-archetype packaging.  I  
also tried setting the archetype plugin as an extension, but that  
didn't work.


Anyone know what is going on?

--jason


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Syntax highligthing for APT sources in IDEA

[Jason Dillon]

Anyone know how to do this?

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Velocity verbosity

[Jason Dillon]

Hiya, how can we get the default behavior of plugins which use  
velocity to be less verbose?


I see muck like this which I'd rather not:


[INFO] Setting property: classpath.resource.loader.class =>  
'org.codehaus.plexus.velocity.ContextClassLoaderResourceLoader'.

[INFO] Setting property: velocimacro.messages.on => 'false'.
[INFO] Setting property: resource.loader => 'classpath'.
[INFO] Setting property: resource.manager.logwhenfound => 'false'.


Can we get these logged as DEBUG?  And how?

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Why no sources published for plexus-container-default 1.0-alpha-44 release?

[Jason Dillon]

:-(

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: maven-artifact 3 release?

[Jason Dillon]

Cool!  So can we get a release of the new maven-artifact bits out in  
the next week or two?


--jason


On Mar 24, 2008, at 1:12 AM, Jason van Zyl wrote:

Oleg is back from Russian, I have his CLA now and that's what was  
blocking the release. The release of 2.1-alpha-1 as well.


On 23-Mar-08, at 12:19 AM, Jason Dillon wrote:
Is the new maven-artifact ready for prime-time?  Any idea when it  
might get released?


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

-- Jakob Burckhardt



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

maven-artifact 3 release?

[Jason Dillon]

Is the new maven-artifact ready for prime-time?  Any idea when it  
might get released?


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release maven-shade-plugin 1.0.1

[Jason Dillon]

+1

--jason


On Mar 17, 2008, at 10:12 PM, Daniel Kulp wrote:



There is a critical bug in 1.0 where the resulting merged NOTICE files
may not be correct.   This release is JUST to fix that issue (thus the
1.0.1 version and not 1.1):
http://jira.codehaus.org/browse/MSHADE-22

Staging area:
http://people.apache.org/~dkulp/stage_shade/

Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-shade-plugin-1.0.1/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release apache-jar-resource-bundle version 1.4

[Jason Dillon]

Does this bundle have the same bits as the legal-bundle from genesis  
does?


--jason


On Mar 17, 2008, at 10:05 PM, Daniel Kulp wrote:



To comply with the latest requirements discussed on legal-discuss, we
need a new version of the apache-jar-resource-bundle.

The only change is really the result of discussions and testing  
around:

http://jira.codehaus.org/browse/MRRESOURCES-32
Many thanks to David Jencks for leading that up with legal-discuss.

Staging area:
http://people.apache.org/~dkulp/stage-bundle/

Tag:
http://svn.apache.org/repos/asf/maven/resources/tags/apache-jar-resource-bundle-1.4/

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [VOTE] Release maven-remote-resources version 1.0

[Jason Dillon]

+1

--jason


On Mar 17, 2008, at 10:18 PM, Daniel Kulp wrote:



Several projects are sucessfully using remote-resources so it's time  
pull

it out of beta and do the 1.0 release.  :-)

This version provides three new improvements from 1.0-beta-2:

** Improvement
   * [MRRESOURCES-22] - Provide "excludes" for artifacts that are  
passed

into velocity
   * [MRRESOURCES-23] - Introduce a parameter to define the scopes of
the libraries to be included in the NOTICE licensing.
   * [MRRESOURCES-34] - Allow appended text to also be velocity
templates


Staging area:
http://people.apache.org/~dkulp/stage_rr/

Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.0/


Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

maven-shade-plugin 1.0 seems to be altering project.basedir

[Jason Dillon]

Any reason why after running shade that the project.basedir becomes  
project.build.directory ?


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: RSS feed for central repo changes?

[Jason Dillon]

Thx :-)

--jason


On Mar 14, 2008, at 2:52 PM, Dan Tran wrote:


I use this feed

http://www.mvnrepository.com/feeds/rss2.0.xml



On Fri, Mar 14, 2008 at 12:34 AM, Jason Dillon <[EMAIL PROTECTED]>  
wrote:

Is there an RSS feed somewhere to track changes to the central
repository?

--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RSS feed for central repo changes?

[Jason Dillon]

Is there an RSS feed somewhere to track changes to the central  
repository?


--jason

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [vote] Release Maven Shade plugin 1.0

[Jason Dillon]

+1

--jason


On Mar 2, 2008, at 10:20 AM, Brett Porter wrote:


Hi,

The Shade plugin is ready to be released. This is needed for the  
2.0.9 release as well.


We solved 6 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11540&styleName=Html&version=13994

The remaining issues in JIRA are feature requests.

Staging repo:
http://people.apache.org/~brett/staged-releases/org/apache/maven/plugins/maven-shade-plugin/1.0/

Staging site:
http://maven.apache.org/plugins/maven-shade-plugin/staging/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: An Attribute Based POM

[Jason Dillon]

If I ever need an xml diver ill give you a ring :-P
 
But most folks I know don't care to swim in xml... They'd drownd...

--jason


-Original Message-
From: "Don Brown" <[EMAIL PROTECTED]>

Date: Tue, 12 Feb 2008 17:01:43 
To:"Maven Developers List" 
Subject: Re: An Attribute Based POM


Heh, you would read it that way...well, I guess we do have a few crazy
POMs with pages and pages of Ant tags.  If you love swimming in XML,
we have a small ocean over here :)

Don

On 2/12/08, Brett Porter <[EMAIL PROTECTED]> wrote:
> Are you saying that if you are looking forward to dealing with more
> verbosity, you should interview at Atlassian? :)
>
> On 12/02/2008, at 4:47 PM, Don Brown wrote:
>
> > Atlassian is hiring ... :)
> >
> > On 2/12/08, Jason Dillon <[EMAIL PROTECTED]> wrote:
> >> IMO we should strive to make the pom even more verbose... So all us
> >> maven folk can keep our jobbies :-P
> >>
> >> --jason
> >>
> >>
> >> -Original Message-
> >> From: Brett Porter <[EMAIL PROTECTED]>
> >>
> >> Date: Tue, 12 Feb 2008 16:35:35
> >> To:"Maven Developers List" 
> >> Subject: Re: An Attribute Based POM
> >>
> >>
> >> Yes, I happen to agree with the theory Shane and Jason outlined and
> >> is
> >> why I accepted the status quo for 5 years :) But I always thought the
> >> Maven dependencies tag in Ant looked better and was easier to read. I
> >> think the expanded format makes more sense for machine-generated
> >> and -
> >> read documents.
> >>
> >> Perhaps XML isn't the right choice in the first place - but it is
> >> well
> >> tooled and familiar to Java weenies. Maybe one day IDE support will
> >> be
> >> ubiquitously used and it won't matter, but for now a lot of people
> >> look at POMs and edit them in vim and would like them to be simpler.
> >> The more important thing is remaining consistent throughout the
> >> change
> >> IMO.
> >>
> >> - Brett
> >>
> >> On 12/02/2008, at 4:22 PM, Don Brown wrote:
> >>
> >>> Whether an attribute-based design is "proper" is a less important
> >>> question than what makes Maven more usable.  Form should follow
> >>> function.  What users care about is more readable POMs, less typing,
> >>> and less clutter.  I've been really impressed with the Maven team
> >>> adopting a more programmatic approach to Maven recently, and this
> >>> change will go a long way to making Maven more usable and less
> >>> curse-worthy.
> >>>
> >>> Don
> >>>
> >>> On 2/12/08, Shane Isbell <[EMAIL PROTECTED]> wrote:
> >>>> I know that it is not always clear when to use and attribute and
> >>>> when to use
> >>>> an element; but typically, attributes are used to attach metadata
> >>>> or
> >>>> nonessential information about an element, while subelements are
> >>>> essential
> >>>> parts of the parent element. To me, the groupId, artifactId and
> >>>> version
> >>>> would be essential parts of a dependency element.
> >>>>
> >>>> Shane
> >>>>
> >>>> On Feb 10, 2008 10:45 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> >>>>
> >>>>> Hi,
> >>>>>
> >>>>> I've always wanted to see an attribute based POM, so based on
> >>>>> Nicolas'
> >>>>> suggestion I killed some time after waking up early this morning
> >>>>> to do
> >>>>> it.
> >>>>>
> >>>>> JIRA: http://jira.codehaus.org/browse/MNG-3397
> >>>>>
> >>>>> Here is a build to try:
> >>>>> http://people.apache.org/~brett/apache-maven-2.0.9-SNAPSHOT-terse-bin.tar.gz
> >>>>> and svn branch:
> >>>>> http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x-terse
> >>>>>
> >>>>> Here are two different files for comparison (it halved the size):
> >>>>>
> >>>>> http://svn.apache.org/viewvc/maven/archiva/trunk/pom.xml?content-type=text%2Fplain&view=co
> >>>>>
> >>>>> http://svn.apache.org/viewvc/maven/archiva/trunk/pom-4.1.0.xml?content-type=text%2Fplain&view=co
> >>>>

Re: An Attribute Based POM

[Jason Dillon]

Hehe. Nooo I was just being sarcastic in my traditional form.

I'd like to see some verbosity related changes to simplify the pom's structure 
eventually... Cause IMO if we can describe the same data with less chars that 
is going to be easier for folks to consume and manage Of course its gotta 
be consistent, cause inconsistency in format (between attr and elem) is more 
harmful than bloat from attr-only configuration. But you guys r smart and know 
that already na?

But when it comes down to it I don't care too much about attr vs elem. What I 
think is much more useful is to allow dependency (and dependency-like elements) 
to be grouped, so that similar elements (like groupId and version) can be 
shared be a number of children. This is IMO a much bigger step towords pom 
simplification and a debate over attr vs elem. 

Basically I don't care it its an attr or elem, just let me reuse as mush 
information as possible. If I end up with a pom containing more than 3 
duplicates of the same config... Something is broke and could use some love. 

Cheers,

--jason

-Original Message-
From: Brett Porter <[EMAIL PROTECTED]>

Date: Tue, 12 Feb 2008 16:51:07 
To:"Maven Developers List" 
Subject: Re: An Attribute Based POM


Are you saying that if you are looking forward to dealing with more  
verbosity, you should interview at Atlassian? :)

On 12/02/2008, at 4:47 PM, Don Brown wrote:

> Atlassian is hiring ... :)
>
> On 2/12/08, Jason Dillon <[EMAIL PROTECTED]> wrote:
>> IMO we should strive to make the pom even more verbose... So all us  
>> maven folk can keep our jobbies :-P
>>
>> --jason
>>
>>
>> -Original Message-
>> From: Brett Porter <[EMAIL PROTECTED]>
>>
>> Date: Tue, 12 Feb 2008 16:35:35
>> To:"Maven Developers List" 
>> Subject: Re: An Attribute Based POM
>>
>>
>> Yes, I happen to agree with the theory Shane and Jason outlined and  
>> is
>> why I accepted the status quo for 5 years :) But I always thought the
>> Maven dependencies tag in Ant looked better and was easier to read. I
>> think the expanded format makes more sense for machine-generated  
>> and -
>> read documents.
>>
>> Perhaps XML isn't the right choice in the first place - but it is  
>> well
>> tooled and familiar to Java weenies. Maybe one day IDE support will  
>> be
>> ubiquitously used and it won't matter, but for now a lot of people
>> look at POMs and edit them in vim and would like them to be simpler.
>> The more important thing is remaining consistent throughout the  
>> change
>> IMO.
>>
>> - Brett
>>
>> On 12/02/2008, at 4:22 PM, Don Brown wrote:
>>
>>> Whether an attribute-based design is "proper" is a less important
>>> question than what makes Maven more usable.  Form should follow
>>> function.  What users care about is more readable POMs, less typing,
>>> and less clutter.  I've been really impressed with the Maven team
>>> adopting a more programmatic approach to Maven recently, and this
>>> change will go a long way to making Maven more usable and less
>>> curse-worthy.
>>>
>>> Don
>>>
>>> On 2/12/08, Shane Isbell <[EMAIL PROTECTED]> wrote:
>>>> I know that it is not always clear when to use and attribute and
>>>> when to use
>>>> an element; but typically, attributes are used to attach metadata  
>>>> or
>>>> nonessential information about an element, while subelements are
>>>> essential
>>>> parts of the parent element. To me, the groupId, artifactId and
>>>> version
>>>> would be essential parts of a dependency element.
>>>>
>>>> Shane
>>>>
>>>> On Feb 10, 2008 10:45 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I've always wanted to see an attribute based POM, so based on
>>>>> Nicolas'
>>>>> suggestion I killed some time after waking up early this morning
>>>>> to do
>>>>> it.
>>>>>
>>>>> JIRA: http://jira.codehaus.org/browse/MNG-3397
>>>>>
>>>>> Here is a build to try:
>>>>> http://people.apache.org/~brett/apache-maven-2.0.9-SNAPSHOT-terse-bin.tar.gz
>>>>> and svn branch:
>>>>> http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x-terse
>>>>>
>>>>> Here are two different files for comparison (it halved the size):
>>>

Re: An Attribute Based POM

[Jason Dillon]

IMO we should strive to make the pom even more verbose... So all us maven folk 
can keep our jobbies :-P

--jason


-Original Message-
From: Brett Porter <[EMAIL PROTECTED]>

Date: Tue, 12 Feb 2008 16:35:35 
To:"Maven Developers List" 
Subject: Re: An Attribute Based POM


Yes, I happen to agree with the theory Shane and Jason outlined and is  
why I accepted the status quo for 5 years :) But I always thought the  
Maven dependencies tag in Ant looked better and was easier to read. I  
think the expanded format makes more sense for machine-generated and - 
read documents.

Perhaps XML isn't the right choice in the first place - but it is well  
tooled and familiar to Java weenies. Maybe one day IDE support will be  
ubiquitously used and it won't matter, but for now a lot of people  
look at POMs and edit them in vim and would like them to be simpler.  
The more important thing is remaining consistent throughout the change  
IMO.

- Brett

On 12/02/2008, at 4:22 PM, Don Brown wrote:

> Whether an attribute-based design is "proper" is a less important
> question than what makes Maven more usable.  Form should follow
> function.  What users care about is more readable POMs, less typing,
> and less clutter.  I've been really impressed with the Maven team
> adopting a more programmatic approach to Maven recently, and this
> change will go a long way to making Maven more usable and less
> curse-worthy.
>
> Don
>
> On 2/12/08, Shane Isbell <[EMAIL PROTECTED]> wrote:
>> I know that it is not always clear when to use and attribute and  
>> when to use
>> an element; but typically, attributes are used to attach metadata or
>> nonessential information about an element, while subelements are  
>> essential
>> parts of the parent element. To me, the groupId, artifactId and  
>> version
>> would be essential parts of a dependency element.
>>
>> Shane
>>
>> On Feb 10, 2008 10:45 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
>>
>>> Hi,
>>>
>>> I've always wanted to see an attribute based POM, so based on  
>>> Nicolas'
>>> suggestion I killed some time after waking up early this morning  
>>> to do
>>> it.
>>>
>>> JIRA: http://jira.codehaus.org/browse/MNG-3397
>>>
>>> Here is a build to try:
>>> http://people.apache.org/~brett/apache-maven-2.0.9-SNAPSHOT-terse-bin.tar.gz
>>> and svn branch:
>>> http://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x-terse
>>>
>>> Here are two different files for comparison (it halved the size):
>>>
>>> http://svn.apache.org/viewvc/maven/archiva/trunk/pom.xml?content-type=text%2Fplain&view=co
>>>
>>> http://svn.apache.org/viewvc/maven/archiva/trunk/pom-4.1.0.xml?content-type=text%2Fplain&view=co
>>>
>>> What I did is basically convert all the primitive types in the model
>>> to attributes. I think more could be done (flattening lists, doing  
>>> the
>>> same for plugin configuration elements), but this gets a big win at
>>> least in the dependencies section for minimal work.
>>>
>>> It should be completely backwards compatible. It detects v4.0.0 and
>>> reads it like it used to (then internally converts to the 4.1.0 Java
>>> model).
>>>
>>> Here's some notes on the implementation so far (again, go easy, I  
>>> just
>>> whipped this up today and it's not production ready):
>>> - I see this as a stepping stone to the final solution. I've said  
>>> this
>>> before, but I think the POM should separate the build information  
>>> from
>>> the project metadata (particularly that stored in the repository). I
>>> think we need to take baby steps towards that though.
>>> - this could feasibly be applied to the settings and profile files  
>>> too.
>>> - I switched to StAX in the process. This is likely going to  
>>> introduce
>>> some small quirks we need to iron out (like the hack I added to  
>>> parse
>>> Trygve's name - why did we ever allow that!) I think ideally we'd  
>>> use
>>> the Xpp3Reader for 4.0.0 and the StaxReader for 4.1.0 for best
>>> compatibility. This would also fix the problem in that I've just
>>> removed the Xpp3Reader and so some plugins may choke. I'm sure the
>>> release plugin won't be happy, for example.
>>> - There is probably a slight performance overhead in reading v4 POMs
>>> since it repopulates the model twice. I haven't measured it but if
>>> it's an issue we could optimise the reader/converter. It also adds
>>> about 200k to the maven-model JAR.
>>> - It is very close to detecting based on namespace so we could  
>>> enforce
>>> the use of that instead.
>>>
>>> Enjoy!
>>>
>>> Cheers,
>>> Brett
>>>
>>> --
>>> Brett Porter
>>> [EMAIL PROTECTED]
>>> http://blogs.exist.com/bporter/
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>
>>>
>>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>

Re: Merging shitty-maven-plugin and maven-invoker-plugin was [Re: [MECLIPSE] refactor IT tests to use shitty maven plugin ?]

[Jason Dillon]

As mentioned before I'm not a big fan of merging these plugins.  IMO,  
SHITTY provides a lot of additional functionality on top of what the  
maven-invoker-plugin provides, like:


 * Groovy integration
 * More flexible configuration
 * Clean and install support integrated (for less pom.xml  
configuration)

 * ANSI color support
 * Parallel test invocation
 * Support for richer test validation and rejection
 * Smarter handling for invocations when project defines no tests

At first I was using the maven-clean-plugin, maven-install-plugin and  
maven-inovker-plugin, but I found it insufficient in my desire to  
simplify configuration and allow some projects to define tests and  
others to omit them.  I also wanted to add colors to make it a little  
easier for me to grok the output, run tests in parallel, support more  
flexible validation and a bunch of other issues.  So I choose to write  
a new plugin at the Codehaus, which allows me to *very quickly* add  
features, respond to problems and grow the functionality of the  
plugin.  Apache plugins on the other hand are a little more limited in  
flexibility, which tends to slow the release cycle and IMO puts a bit  
of a damper on innovation from the reduced numbers of iterations.  Its  
not a knock on Apache, as I'm a commiter and PMC member, but that is  
really and at this point in the life of SHITTY I believe that its best  
to continue living at the Codehaus.


IMO, invoker is useful, but so is SHITTY.  I created SHITTY because I  
needed something that worked NOW, and didn't have time to wait weeks  
or months for patch review and application, and then weeks or months  
more for a release so I could actually use it.


Personally I don't think folks really care about BeanShell vs.  
Groovy... and if I took a pool I'd imaging most folks would rather  
have Groovy.  But if its a big deal I can make SHITTY run BeanShell  
scripts.


Anyways... SHITTY was created out of my frustration with clean,  
install and invoker... to make my life easier, and allow me to build  
projects (mostly mojo projects) which had some reasonable tests to  
ensure that I didn't screw anything up.  I personally don't see that  
clean, install and invoker plugins merging together.  So I'd rather  
see the invoker continue to be a plugin to help with invocation of sub- 
maven builds, and SHITTY for complete integration testing of sub-maven  
builds.  Maybe one day they can share more code... though since SHITTY  
is written in Groovy and maven-invoker-plugin is Java, I'm not sure  
how that will work out.


I think some time is still needed to add more features and let both  
plugins mature...


Hope that helps some :-)

--jason


On Dec 17, 2007, at 12:17 AM, olivier lamy wrote:


Hi,

Agree on merge but in a new plugin or merging in maven-invoker- 
plugin ?

Before starting this work, I'd like to release the current
maven-invoker-plugin to not delay some other releases which depends  
on this.

I will call a vote today.
After we can work on the merge.

Thoughs ? or objections ?

--
Olivier

2007/12/17, nicolas de loof <[EMAIL PROTECTED]>:


I just looked at invoker plugin as part of maven-jar-plugin it tests.
Looks very similar to shitty, just two diffs :

- shitty handles installing a test jar in the local repo. Invoker  
requires
more conf in POM to install the jar in a custom local repo (the way  
it is

used in MJAR)
- shitty uses groovy for verify scripts, verifier uses beanshell.
Both accept standard Java.

Couldn't those two plugins merge ? They are so similar !


2007/12/14, nicolas de loof <[EMAIL PROTECTED]>:


Not sure to understand, maybe I miss-used testing-harness :

I set a test POM with just the plugin configuration, so that I can  
run :


   File testPom = new File( getBasedir(),
"src/test/resources/compile.pom" );
   Mojo mojo = (Mojo) lookupMojo( "compile", testPom );
   assertNotNull( "Failed to configure the plugin", mojo );
   mojo.execute();

Right, but then when my plugin has many plexus @component I have  
to set

them in the test POM as configuration elements, using
implementation="XXXStub". So it seems this NOT to be a real maven  
build.

The
EclipsePlugin requires a MavenProject with many sub-components,  
that is

difficult to setup

Or maybe I missunderstood the use of this plugin ?

Nico.


2007/12/14, Brian E. Fox <[EMAIL PROTECTED]>:



AFAIK, shitty is similar to invoker, but does more : it install  
the

current

artifact in local repo with version "testing" and invoke a maven

build.



Seems to be what the invoker it-test do. Shitty alos use groovy

scripts

to

test the result.


This is _exactly_ what the plugin testing harness (currently used  
by

the

eclipse plugin) does.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]









-
To un

Re: [VOTE] release maven-shade-plugin 1.0-beta-1

[Jason Dillon]

+1

--jason


On Jan 17, 2008, at 3:22 PM, Daniel Kulp wrote:



Well, I'd prefer to not get into "version number" arguments as it  
really
just doesn't matter.Hell, we have plugins (like the release  
plugin,

dependency plugin, etc..) that EVERYONE uses that haven't had a real
release and others (like surefire) that never had a "alpha/beta"
release, but probably should have.

The fact is MSHADE-9 is not something we can fix in maven-shade- 
plugin.

It's a bug in ASM and isn't fixable until they provide a fix.  (unless
someone wants to jump into ASM code.  I don't have the time.)   Since
they haven't provided a new version into the repos in almost a year,  
I'm

not going to hold my breath for a fix.

IMO, we shouldn't let that hold up moving forward with getting this
plugin in shape for the many people and projects that don't need that
fixed.   In it's current form, the plugin works perfectly fine for a
large number of use cases.   Thus, I say lets get it out.   Wether  
it's

call beta-1 or alpha-16 or even 1.0 is relatively irrelevant to me.

Anway, that all said, any more PMC votes either way?

Dan



On Wednesday 16 January 2008, Dan Fabulich wrote:

I approve of the idea of releasing another version of
maven-shade-plugin, but I don't think we should call it non-alpha
until MSHADE-9 is fixed.

http://jira.codehaus.org/browse/MSHADE-9

If this were called 1.0-alpha-16, I'd give it a +1; as it stands, I
have to vote -1 (non-binding).

-Dan

Daniel Kulp wrote:

I'd like to release maven-shade-plugin 1.0-beta-1 as I kind of need
it for some of my projects.  I think Geronimo may need it as well.

This fixes a couple issues we'e run into:

** Bug
  * [MSHADE-11] - Shaded jars are not unjarrable
  * [MSHADE-13] - META-INF/INDEX.LIST files need to be skipped
** New Feature
  * [MSHADE-12] - Ability to filter contents of the archives added
to the shaded jar

Release notes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?version=13921&style
Name=Text&projectId=11540&Create=Create

Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-shade-plugi
n-1.0-beta-1/

Staged at:
http://people.apache.org/~dkulp/stage_shade/


The vote will be open for 72 hours.

Here is my +1
--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog


- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




--
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Merging shitty-maven-plugin and maven-invoker-plugin was [Re: [MECLIPSE] refactor IT tests to use shitty maven plugin ?]

[Jason Dillon]

I'm personally not very interested in merging the plugins.  I can  
explain more when I'm back from Thailand :-)


--jason


On Dec 18, 2007, at 3:13 PM, Jason van Zyl wrote:



On 17 Dec 07, at 12:17 AM 17 Dec 07, olivier lamy wrote:


Hi,

Agree on merge but in a new plugin or merging in maven-invoker- 
plugin ?

Before starting this work, I'd like to release the current
maven-invoker-plugin to not delay some other releases which depends  
on this.

I will call a vote today.
After we can work on the merge.

Thoughs ? or objections ?



You may actually want to approach the people who actually wrote  
these plugins. They wrote them for a particular reason, so make sure  
you talk to them before merging their code. The onus is on you to  
make sure you've communicated with the respective authors.



--
Olivier

2007/12/17, nicolas de loof <[EMAIL PROTECTED]>:


I just looked at invoker plugin as part of maven-jar-plugin it  
tests.

Looks very similar to shitty, just two diffs :

- shitty handles installing a test jar in the local repo. Invoker  
requires
more conf in POM to install the jar in a custom local repo (the  
way it is

used in MJAR)
- shitty uses groovy for verify scripts, verifier uses beanshell.
Both accept standard Java.

Couldn't those two plugins merge ? They are so similar !


2007/12/14, nicolas de loof <[EMAIL PROTECTED]>:


Not sure to understand, maybe I miss-used testing-harness :

I set a test POM with just the plugin configuration, so that I  
can run :


  File testPom = new File( getBasedir(),
"src/test/resources/compile.pom" );
  Mojo mojo = (Mojo) lookupMojo( "compile", testPom );
  assertNotNull( "Failed to configure the plugin", mojo );
  mojo.execute();

Right, but then when my plugin has many plexus @component I have  
to set

them in the test POM as configuration elements, using
implementation="XXXStub". So it seems this NOT to be a real maven  
build.

The
EclipsePlugin requires a MavenProject with many sub-components,  
that is

difficult to setup

Or maybe I missunderstood the use of this plugin ?

Nico.


2007/12/14, Brian E. Fox <[EMAIL PROTECTED]>:



AFAIK, shitty is similar to invoker, but does more : it install  
the

current

artifact in local repo with version "testing" and invoke a maven

build.



Seems to be what the invoker it-test do. Shitty alos use groovy

scripts

to

test the result.


This is _exactly_ what the plugin testing harness (currently  
used by

the

eclipse plugin) does.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]








Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver  
might.


-- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]