RE: Missing Maven 2.0.8 sources

[Brian E. Fox]

These are uploaded now. Give it a few hours to sync.

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Paul Benedict
Sent: Friday, February 01, 2008 8:45 AM
To: dev@maven.apache.org
Subject: Missing Maven 2.0.8 sources

The Maven 2.0.8 sources and 2.0.8 Ant Task sources are not uploaded into
mirrors. Can somebody take care of this?

Paul

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

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

[Arnaud HERITIER]

+1
Great work.
How the plugin find the list of archetypes ? More particularly, how in a
corporate environment I can access to our custom archetypes ? We just have
to upload them in our internal repository ?

Arnaud

On Feb 4, 2008 11:35 PM, Raphaël Piéroni <[EMAIL PROTECTED]> wrote:

> Hi,
>
> http://people.apache.org/~rafale/site/maven-archetype-plugin/
>
> Here is the actual documentation.
> Please consider it is a work in progress.
>
> Raphaël
>
> 2008/2/4, Brian E. Fox <[EMAIL PROTECTED]>:
> > It's interactive by default so pretty easy to use. The other new goal is
> create-from-project where you run it in a project and it will walk you
> through making an archetype of that project (it goes into
> /target/generated-sources where you can then go and install/deploy it)
> >
> > -Original Message-
> > From: Raphaël Piéroni [mailto:[EMAIL PROTECTED]
> > Sent: Monday, February 04, 2008 3:36 AM
> > To: Maven Developers List
> > Subject: Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-1
> >
> > How to use it :
> > mvn archetype:create.
> >
> > Regards,
> >
> > Raphaël
> >
> > 2008/2/4, Jorg Heymans <[EMAIL PROTECTED]>:
> > > (sorry for hijacking the vote thread for this)
> > >
> > > Hi Raphaël,
> > >
> > > Can you give us some pointers to list threads, proposals or specs that
> > > explain the basics of the new architecture and how to use it ? I'm
> very keen
> > > to try it out and give you all the feedback you want, but if it means
> > > grepping the sources to find out how things work i'll hold off until
> > > alpha-2.
> > >
> > > Thanks!
> > > Jorg
> > >
> > > On Feb 2, 2008 1:25 AM, Raphaël Piéroni <[EMAIL PROTECTED]>
> wrote:
> > >
> > > > Hi,
> > > >
> > > > Here comes the time for calling the first release of the Maven
> > > > Archetype plugin version 2.0-alpha-1.
> > > >
> > > > Staging repo:
> > > >
> http://people.apache.org/~rafale/staging-repo/maven-archetype-plugin/
> 
> > > >
> > > > Staging site:
> > > > No staging site now, the new documentation is not yet written.
> > > > Its is planed for version 2.0-alpha-2.
> > > >
> > > > Vote open for 96 hours.
> > > >
> > > > [ ] +1
> > > > [ ] +0
> > > > [ ] -1
> > > >
> > > >
> > > > Regards,
> > > >
> > > > Raphaël
> > > >
> > >
> >
>



-- 
..
Arnaud HERITIER
..
OCTO Technology - aheritier AT octo DOT com
www.octo.com | blog.octo.com
..
ASF - aheritier AT apache DOT org
www.apache.org | maven.apache.org
...

Re: Upgrade the version of maven to build all plugins on m.z.a.o was Re: Install maven 2.0.8 on maven.zones.a.o

[Arnaud HERITIER]

It's working fine now
http://maven.zones.apache.org/continuum/buildResults.action?projectId=17&projectGroupId=2
There was probably a delay somewhere.

cheers

arnaud

On Feb 4, 2008 11:28 PM, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:

> I made the change to use maven 2.0.8 and jdk 1.4.2, but for integration
> tests it seems that it is always maven 2.0.7 which is used. Any idea ?
>
> Arnaud
>
>
> On Feb 4, 2008 2:16 AM, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:
>
> > Everybody is ok to upgrade the version of maven used to build all our
> > plugins on maven.zones.apache.org (from 2.0.7 to 2.0.8) ?
> >
> > Arnaud
> >
> > On Feb 4, 2008 1:50 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
> >
> > > It's kind of like Maven inheritence, you can't block inheriting things
> > > from the group.
> > >
> > > I would be ok with building all the plugins with 2.0.8 as the latest
> > > release...
> > >
> > > On 04/02/2008, at 11:47 AM, Arnaud HERITIER wrote:
> > >
> > > > Finally I already did it but I have a question about continuum.
> > > > Can I ask to one project to use a different profile of the one
> > > > defined in
> > > > the group ?
> > > > It seems to not be possible.
> > > > I can add a new build for the eclipse plugin with this profile but
> > > > it will
> > > > continue to be built (and to fail) with builds defined in the group
> > > ?
> > > > And I 'm not sure that it is a good idea to upgrade the version of
> > > > maven for
> > > > all our plugins ?
> > > >
> > > > WDYT ?
> > > >
> > > > Arnaud
> > > >
> > > > On Feb 4, 2008 1:32 AM, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:
> > > >
> > > >> yes it's good, I can administrate profiles.
> > > >> thanks. I'll do the setup tomorrow
> > > >>
> > > >> cheers
> > > >>
> > > >>
> > > >> On Feb 4, 2008 1:28 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
> > > >>
> > > >>> you should be able to add that now
> > > >>>
> > > >>> On 04/02/2008, at 10:29 AM, Arnaud HERITIER wrote:
> > > >>>
> > >  yep, the second one. I would like to be able to configure the
> > >  eclipse plugin
> > >  to use it when I'll install it.
> > > 
> > >  Arnaud
> > > 
> > >  On Feb 3, 2008 11:43 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> > > 
> > > > You have a log in on the machine so should be able to install it
> > > -
> > > > ore
> > > > are you referring to have it included in the Continuum profiles?
> > > >
> > > > - Brett
> > > >
> > > > On 02/02/2008, at 8:01 AM, Arnaud HERITIER wrote:
> > > >
> > > >> Nobody ? No idea ?
> > > >> I would like to be sure that the build is good before to
> > > >> release the
> > > >> plugin
> > > >> (in almost 1 week)
> > > >>
> > > >> Arnaud
> > > >>
> > > >> On Feb 1, 2008 8:59 AM, Arnaud HERITIER <[EMAIL PROTECTED]>
> > > >> wrote:
> > > >>
> > > >>> Hi all,
> > > >>>
> > > >>> Is it possible to add maven 2.0.8 on our integration server ?
> > > >>> The eclipse plugin requires it to build (not to be used - but
> > > I
> > > >>> have to
> > > >>> check) because we have some tests for encoding issues.
> > > >>> How can I do it ? I have access to the server but I think that
> > > i
> > > >>> need to
> > > >>> be admin in continuum ?
> > > >>>
> > > >>> cheers
> > > >>>
> > > >>> Arnaud
> > > >>>
> > > >>> --
> > > >>> ..
> > > >>> Arnaud HERITIER
> > > >>> ..
> > > >>> OCTO Technology - aheritier AT octo DOT com
> > > >>> www.octo.com | blog.octo.com
> > > >>> ..
> > > >>> ASF - aheritier AT apache DOT org
> > > >>> www.apache.org | maven.apache.org
> > > >>> ...
> > > >>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> ..
> > > >> Arnaud HERITIER
> > > >> ..
> > > >> OCTO Technology - aheritier AT octo DOT com
> > > >> www.octo.com | blog.octo.com
> > > >> ..
> > > >> ASF - aheritier AT apache DOT org
> > > >> www.apache.org | maven.apache.org
> > > >> ...
> > > >
> > > >
> > > >
> > > -
> > > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > > For additional commands, e-mail: [EMAIL PROTECTED]
> > > >
> > > >
> > > 
> > > 
> > >  --
> > >  ..
> > >  Arnaud HERITIER
> > >  ..
> > >  OCTO Technology - aheritier AT octo DOT com

Re: [Discuss] MPLUGIN-40

[Tim O'Brien]

On Feb 4, 2008, at 8:49 PM, Dan Fabulich wrote:


Tim O'Brien wrote:

I'm sorry, hold on... starting stopwatch "mvn help:describe - 
Dplugin=nifty -Dmojo=nifty -Dfull" - alright, I type fast, but that  
took me 10 seconds.   Then I hit enter and a whole *crapload* of  
information zoomed past.   Ok, CTRL-R, mvn, adding a "| less".
Ok, for something like "help:describe", I'm looking at eight or  
nine pages of sleep inducing variable names.


Slow down, we agree more than we disagree.  That's why I filed a  
bunch of bugs against MPH today:


http://tinyurl.com/2c4j42

In particular, I think MPH-31 and MPH-32 would be good fixes, and  
don't require weird changes to core.  I'd prefer you'd typed "mvn  
help -Dcmd=nifty:nifty", and that "mvn help" explained how that works.


I'm serious the help plugin hurts, go back to what Jason said about  
svn doing a better job.


(Didn't I say that?)  I'm not saying that the help plugin is  
perfect; I'm saying that we don't need to re-invent the wheel or  
hack the CLI to make this feature work, and that if you want to use  
it, you can start doing so right now.


Well I think it would help to make it a bit more accessible.   All that:

mvn help:describe -Dplugin= -Dmojo= -Dfull

Should likely be changed to something easier to type:

mvn-help dependency

or

mvn-help ant:run

mvn-help -l   

No?  Yes?




But as for finding plugins, it's better to search the Internet for  
that sort of thing, rather than trying to turn the Maven core into  
an Internet search engine for Maven plugins.


Dan, can I quote you on "It's better to search the Internet for  
that sort of thing" the next time I have to defend Maven to some  
end-user who is absolutely enraged by the fact that they've had to  
spend the last fourteen hours trying to track down the reason why  
the dependency plugin they have installed doesn't support the tree  
goal even though the documentation on the Maven site tells them to  
run it (Hint: they don't have the right version)


Version diagnosis is very different from finding plugins to use.  It  
IS better to search the Internet to find plugins, which is what the - 
G switch is all about.  (It tells you about all plugins available  
everywhere, not just the ones you've got installed.)  Searching the  
Internet isn't better to diagnose version problems, but then, -G  
wouldn't have helped that either.




I guess I disagree here because I believe the following statements to  
be true:  mojo is something of a horror (it's getting a little  
better), plugins on the Maven site are often dev versions, the future  
of the success of Maven is for plugin development to become very  
decentralized (see Springer's Docbkx, and the Israfil Flex plugin)


I think a simple tool, packaged with Maven that knows of some plugin  
groupIds. Would be a great thing.   Run it, it lists all the plugins  
it knows about, you can see information about them.It's like gem  
for Maven..


In fact, the help plugin is a pretty good way of diagnosing  
versions, or at least starting to.  "mvn help:describe - 
Dplugin=dependency -Dmedium" will tell you what you can do with the  
dependency plugin you've got installed and, prominently, what  
version you're using.


Annoyed by those -Dfull and -Dmedium flags?  Me, too... that's  
MPH-31, MPH-32, and MPH-35.


No one is saying they want Maven to be the "Internet Search Engine"  
for plugins.  Maybe someone is saying, "what we have now isn't  
adequate". Seconded.


We agree again!



Alright, Dan, let's do it.   Let me know how I can help.

Makes sense.  But, wait, in that help:describe, you didn't call it  
a "goal", the property was a "mojo"?


Yeah, that's why I already filed MPH-33 earlier today.


I dig.



-Dan

-
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: [Discuss] MPLUGIN-40

[Dan Fabulich]

Tim O'Brien wrote:

I'm sorry, hold on... starting stopwatch "mvn help:describe 
-Dplugin=nifty -Dmojo=nifty -Dfull" - alright, I type fast, but that took me 
10 seconds.   Then I hit enter and a whole *crapload* of information zoomed 
past.   Ok, CTRL-R, mvn, adding a "| less".   Ok, for something like 
"help:describe", I'm looking at eight or nine pages of sleep inducing 
variable names.


Slow down, we agree more than we disagree.  That's why I filed a bunch of 
bugs against MPH today:


http://tinyurl.com/2c4j42

In particular, I think MPH-31 and MPH-32 would be good fixes, and don't 
require weird changes to core.  I'd prefer you'd typed "mvn help 
-Dcmd=nifty:nifty", and that "mvn help" explained how that works.


I'm serious the help plugin hurts, go back to what Jason said about svn 
doing a better job.


(Didn't I say that?)  I'm not saying that the help plugin is perfect; I'm 
saying that we don't need to re-invent the wheel or hack the CLI to make 
this feature work, and that if you want to use it, you can start doing so 
right now.


But as for finding plugins, it's better to search the Internet for that 
sort of thing, rather than trying to turn the Maven core into an Internet 
search engine for Maven plugins.


Dan, can I quote you on "It's better to search the Internet for that 
sort of thing" the next time I have to defend Maven to some end-user who 
is absolutely enraged by the fact that they've had to spend the last 
fourteen hours trying to track down the reason why the dependency plugin 
they have installed doesn't support the tree goal even though the 
documentation on the Maven site tells them to run it (Hint: they don't 
have the right version)


Version diagnosis is very different from finding plugins to use.  It IS 
better to search the Internet to find plugins, which is what the -G switch 
is all about.  (It tells you about all plugins available everywhere, not 
just the ones you've got installed.)  Searching the Internet isn't better 
to diagnose version problems, but then, -G wouldn't have helped that 
either.


In fact, the help plugin is a pretty good way of diagnosing versions, or 
at least starting to.  "mvn help:describe -Dplugin=dependency -Dmedium" 
will tell you what you can do with the dependency plugin you've got 
installed and, prominently, what version you're using.


Annoyed by those -Dfull and -Dmedium flags?  Me, too... that's MPH-31, 
MPH-32, and MPH-35.


No one is saying they want Maven to be the "Internet Search Engine" for 
plugins.  Maybe someone is saying, "what we have now isn't adequate". 
Seconded.


We agree again!

Makes sense.  But, wait, in that help:describe, you didn't call it a 
"goal", the property was a "mojo"?


Yeah, that's why I already filed MPH-33 earlier today.

-Dan

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

Re: [Discuss] MPLUGIN-40

[Jan Nielsen]

On Feb 4, 2008 5:14 PM, Dan Fabulich <[EMAIL PROTECTED]> wrote:
> Jan Nielsen wrote:
>
> > Finding the definitive help information for a plugin should be
> > absolutely trivial and built-in; having the CLI option which give the
> > code-you-are-executing-right-now the ability to answer that question
> > avoids the issues we have today with multiple sources for a plugin with
> > different HTML usage information.
>
> Have you tried "mvn help:describe -Dplugin=nifty -Dmojo=nifty -Dfull"?  I
> think we already have what you want, but we've yet again failed to
> document it adequately.  (Try it with -Dplugin=compiler -Dmojo=compile.)

My point was useability; my first thought would not have been:

  mvn help:describe -Dplugin=nifty -Dmojo=nify -Dfull

but something like:

  mvn nifty:help

So, as you point out, all that would be needed is to hook up "mvn
" to "mvn help:describe -Dplugin= -Dmojo=
-Dfull".

>
> > And while I'm at it, and relatedly, whatever happened to "-G" to get me
> > a list of all plugins???
>
> I never used 1.x, but I don't think that makes sense any more.  We could
> certainly provide a list of all valid lifecycle phases (and we should do
> so in the help plugin), since those are static and don't change.

Yes! That would be terrific. And a list of the currently plugged in
plugins for each lifecycle phase would be handy as well.

>
> http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html
>
> But as for finding plugins, it's better to search the Internet for that
> sort of thing, rather than trying to turn the Maven core into an Internet
> search engine for Maven plugins.  (Similarly, wouldn't it be cool if you
> could use a simple Maven command-line switch to search for jars you could
> use in your project?  Wait, no it wouldn't; that's what Google is for.)

I understand your point, Dan. And while I agree somewhat with that, I
like asking Eclipse to update and or search for new updates that are
relevant to my version of Eclipse. I can use Google, and that's cool,
but if Eclipse can help me filter all the irrelevant stuff that's even
better - like, say, plugins which don't work on my version of the
software.

>
> > And I might as well chuck in: why in the world do I need to do "mvn
> > nifty:nifty" and not just "mvn nifty"?
>
> Because that way we don't have to guess whether you're trying to run a
> goal or a lifecycle phase.  "install" is a great example.  Do you just
> want to run the install:install goal, or did you want to run every
> lifecycle phase up through the install phase?

I agree; there is an issue with the plugins which are named the same
as the static set of life-cycles, and that's unfortunate. But how
about you make an exception for those that are not...which is the vast
majority, no? So, really "mvn nifty" just means "run the nifty
plugin's default goal", and "mvn install" just means run the "install"
life-cycle, and "mvn install:help" means get me help on the install
plugin...how would the average CLI user expect to get help on the
"install" lifecycle? (Hint, it does not involve any -D switches or
multiple arguments :-)



>
> -Dan
>
>
> -
> 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: [Discuss] MPLUGIN-40

[Tim O'Brien]

On Feb 4, 2008, at 6:14 PM, Dan Fabulich wrote:


Jan Nielsen wrote:

Finding the definitive help information for a plugin should be  
absolutely trivial and built-in; having the CLI option which give  
the code-you-are-executing-right-now the ability to answer that  
question avoids the issues we have today with multiple sources for  
a plugin with different HTML usage information.


Have you tried "mvn help:describe -Dplugin=nifty -Dmojo=nifty - 
Dfull"?  I think we already have what you want, but we've yet again  
failed to document it adequately.  (Try it with -Dplugin=compiler - 
Dmojo=compile.)


I'm sorry, hold on... starting stopwatch "mvn help:describe - 
Dplugin=nifty -Dmojo=nifty -Dfull" - alright, I type fast, but that  
took me 10 seconds.   Then I hit enter and a whole *crapload* of  
information zoomed past.   Ok, CTRL-R, mvn, adding a "| less".   Ok,  
for something like "help:describe", I'm looking at eight or nine pages  
of sleep inducing variable names.


I'm serious the help plugin hurts, go back to what Jason said about  
svn doing a better job.





And while I'm at it, and relatedly, whatever happened to "-G" to  
get me a list of all plugins???


I never used 1.x, but I don't think that makes sense any more.  We  
could certainly provide a list of all valid lifecycle phases (and we  
should do so in the help plugin), since those are static and don't  
change.


http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

But as for finding plugins, it's better to search the Internet for  
that sort of thing, rather than trying to turn the Maven core into  
an Internet search engine for Maven plugins.  (Similarly, wouldn't  
it be cool if you could use a simple Maven command-line switch to  
search for jars you could use in your project?  Wait, no it  
wouldn't; that's what Google is for.)


Dan, can I quote you on "It's better to search the Internet for that  
sort of thing" the next time I have to defend Maven to some end-user  
who is absolutely enraged by the fact that they've had to spend the  
last fourteen hours trying to track down the reason why the dependency  
plugin they have installed doesn't support the tree goal even though  
the documentation on the Maven site tells them to run it (Hint: they  
don't have the right version)


No one is saying they want Maven to be the "Internet Search Engine"  
for plugins.   Maybe someone is saying, "what we have now isn't  
adequate".Seconded.





And I might as well chuck in: why in the world do I need to do "mvn  
nifty:nifty" and not just "mvn nifty"?


Because that way we don't have to guess whether you're trying to run  
a goal or a lifecycle phase.  "install" is a great example.  Do you  
just want to run the install:install goal, or did you want to run  
every lifecycle phase up through the install phase?


Makes sense.But, wait, in that help:describe, you didn't call it a  
"goal", the property was a "mojo"?I guess what Mavenland has to  
get over is that "users" don't know what a Mojo is?   They shouldn't  
be expected to know what a "Mojo" is, you should be able to use Maven  
without knowing very much about it.





-Dan

-
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: [Discuss] MPLUGIN-40

[Jason van Zyl]

On 4-Feb-08, at 4:20 PM, Dan Fabulich wrote:


Jason van Zyl wrote:

I'm not saying the CLI is a good option. I think it's a bad option.  
Keep this out of the core. It's perfectly fine as a plugin.


I'll throw in my two cents and point out that while I basically  
agree with this, I don't think the help plugin is adequately  
documented by the software right now.




I agree, I think what Vincent made would be great where it was just  
auto generated and stuffed into the plugin so that "mvn foo:help" just  
works. It will take a while for all plugins to have this but I don't  
think it's that big a deal.


That is, I think some other command line tools (notably svn) are  
pretty easy to learn using just the command line.  You start with  
"svn help"; it gives you a list of commands you can use, and  
suggests that you type "svn help " for more help on a  
specific command.


Right now, "mvn --help" gives you a list of command line switches,  
but no commands to run, not even a suggestion that you might want to  
use the help plugin.


It would be easy to modify the "--help" text to mention the help  
plugin, and maybe that's enough.  But I think we could at least make  
a very simple "help" lifecycle phase that's bound to "help:describe"  
by default.  That would make "mvn help" a synonym for "mvn help:describe 
".


I think this would be pretty useful if we also did some more work on  
the Maven help plugin, which is surprisingly tricky to use.  I just  
filed about half a dozen new JIRA issues on it today that suggest  
some ways it could be easier to use and work with.


For example, I could imagine the user typing "mvn  
help:describe" (or, eventually, just "mvn help") and getting a nice  
description of how the help plugin works.  Then they could use that  
to learn more about Maven, perhaps investigating a particular plugin  
goal with "mvn help -Dcmd=idea:idea", or get a list of goals in a  
plugin with "mvn help -Dplugin=idea", or learn about the lifecycle  
with "mvn help:lifecycle".


The core and the CLI calling to a wrapper for something housed in a  
plugin is not a good idea.


+1.

-Dan

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

Re: [Discuss] MPLUGIN-40

[Dan Fabulich]

Jason van Zyl wrote:

I'm not saying the CLI is a good option. I think it's a bad option. Keep this 
out of the core. It's perfectly fine as a plugin.


I'll throw in my two cents and point out that while I basically agree with 
this, I don't think the help plugin is adequately documented by the 
software right now.


That is, I think some other command line tools (notably svn) are pretty 
easy to learn using just the command line.  You start with "svn help"; it 
gives you a list of commands you can use, and suggests that you type "svn 
help " for more help on a specific command.


Right now, "mvn --help" gives you a list of command line switches, but no 
commands to run, not even a suggestion that you might want to use the help 
plugin.


It would be easy to modify the "--help" text to mention the help plugin, 
and maybe that's enough.  But I think we could at least make a very simple 
"help" lifecycle phase that's bound to "help:describe" by default.  That 
would make "mvn help" a synonym for "mvn help:describe".


I think this would be pretty useful if we also did some more work on the 
Maven help plugin, which is surprisingly tricky to use.  I just filed 
about half a dozen new JIRA issues on it today that suggest some ways it 
could be easier to use and work with.


For example, I could imagine the user typing "mvn help:describe" (or, 
eventually, just "mvn help") and getting a nice description of how the 
help plugin works.  Then they could use that to learn more about Maven, 
perhaps investigating a particular plugin goal with "mvn help 
-Dcmd=idea:idea", or get a list of goals in a plugin with "mvn help 
-Dplugin=idea", or learn about the lifecycle with "mvn help:lifecycle".


The core and the CLI calling to a wrapper for something housed in a 
plugin is not a good idea.


+1.

-Dan

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

Re: [Discuss] MPLUGIN-40

[Dan Fabulich]

Jan Nielsen wrote:

Finding the definitive help information for a plugin should be 
absolutely trivial and built-in; having the CLI option which give the 
code-you-are-executing-right-now the ability to answer that question 
avoids the issues we have today with multiple sources for a plugin with 
different HTML usage information.


Have you tried "mvn help:describe -Dplugin=nifty -Dmojo=nifty -Dfull"?  I 
think we already have what you want, but we've yet again failed to 
document it adequately.  (Try it with -Dplugin=compiler -Dmojo=compile.)


And while I'm at it, and relatedly, whatever happened to "-G" to get me 
a list of all plugins???


I never used 1.x, but I don't think that makes sense any more.  We could 
certainly provide a list of all valid lifecycle phases (and we should do 
so in the help plugin), since those are static and don't change.


http://maven.apache.org/guides/introduction/introduction-to-the-lifecycle.html

But as for finding plugins, it's better to search the Internet for that 
sort of thing, rather than trying to turn the Maven core into an Internet 
search engine for Maven plugins.  (Similarly, wouldn't it be cool if you 
could use a simple Maven command-line switch to search for jars you could 
use in your project?  Wait, no it wouldn't; that's what Google is for.)


And I might as well chuck in: why in the world do I need to do "mvn 
nifty:nifty" and not just "mvn nifty"?


Because that way we don't have to guess whether you're trying to run a 
goal or a lifecycle phase.  "install" is a great example.  Do you just 
want to run the install:install goal, or did you want to run every 
lifecycle phase up through the install phase?


-Dan

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

Re: [Discuss] MPLUGIN-40

[Jason van Zyl]

On 4-Feb-08, at 3:37 PM, Jan Nielsen wrote:


FWIW, I (and probably 99.9% of the Maven user-base) have desired just
this kind of option for plugins for a  l o o o n g  time. Something
like:

 mvn nifty help
 mvn nifty -h
 mvn nifty --help
 mvn nifty:help


This one is fine. As it doesn't need to go into the CLI, it's just  
part of the plugin.




 mvn nifty:option
 mvn nifty

and if you do:

 mvn nifty:invalid

you just get the help (where "nifty" is any plugin; "any", as in for
all plugins...if the plugin can be downloaded, help is there). That's
pretty canonical CLI behavior.


I think everyone could live with the "mvn foo:help".




I don't know whether that's something that requires a modification to
the core of Maven, or not, and I really don't care. It's a huge
dis-service to all users to not have this available, thereby forcing
the user to chase down the web-page for every plugin they have an
interest in. Finding the definitive help information for a plugin
should be absolutely trivial and built-in; having the CLI option which
give the code-you-are-executing-right-now the ability to answer that
question avoids the issues we have today with multiple sources for a
plugin with different HTML usage information.

And while I'm at it, and relatedly, whatever happened to "-G" to get
me a list of all plugins??? I know it ain't easy, but how about giving
me a list of all the names of the plugins found in the configured
repositories when I do "mvn -G", or "mvn plugin:help", or "mvn
plugin:list", whatever. Cache the result in the repositories if
you need to, but make it easy for the user to find and use plugins.
And I might as well chuck in: why in the world do I need to do "mvn
nifty:nifty" and not just "mvn nifty"? Yes; a plugin can have more
than one goal - that's great; but if I do "mvn nifty" it just means
"mvn nifty:nifty" and if I do "mvn nifty:wizbang" well, then that's
the wizbang goal of the nifty plugin.

-Jan


On Feb 4, 2008 5:09 AM, Vincent Siveton <[EMAIL PROTECTED]>  
wrote:

Hi,

2008/2/3, Jason van Zyl <[EMAIL PROTECTED]>:

I think keeping this out of the core, be that the lifecycle executor
or the CLI would be a far better option.


Agree for CLI.

Vincent, just to be clear you have taken the logic that already  
exists

in the help plugin?


More wrapped logic from PluginXdocGenerator.

Cheers,

Vincent



On 3-Feb-08, at 3:17 PM, Brett Porter wrote:


Something like

mvn -H idea:idea or mvn -H idea

which is akin to what Subversion has, for example.

this would allow the CLI to translate to the appropriate
help:describe goal and then exit, which is pretty clean, as  
compared

to modifying the lifecycle executor.

- Brett

On 04/02/2008, at 10:13 AM, Vincent Siveton wrote:


Hi Brett,

What do you propose for cmd line switch?

Personally, I am fine with mvn my-plugin:help which seems more
common.
A lot of tools (all?) have an help option.

Cheers,

Vincent

2008/2/3, Brett Porter <[EMAIL PROTECTED]>:
Would a different lifecycle or command line switch be more  
intuitive

than this?

On 04/02/2008, at 9:55 AM, Vincent Siveton wrote:


Hi,

I realize that the fix for MPLUGIN-40 (All plugins should by
default
have an auto-generated goal 'help') is definitely *not*  
intuitive

for
the end user.

Background:
I created a plugin-plugin goal which generates an Help mojo.  
This

generated mojo just displays the goals and their
description/parameters for a given plugin project. Since it is a
goal
inside the maven-plugin-plugin, we need to release it and *all*
plugins to make available this new feature (it could take a
time ;) ).

I proposed another approach: modify the  
DefaultLifecycleExecutor to

handle this particular goal. So we could call "mvn idea:help" to
display all available idea goals and "mvn idea:toto" will  
throw an

exception by displaying the help.
Pro: more easy for the end user and works for all plugins
Con: just available in mvn 2.0.9+

WDYT?

Vincent

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



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]




--

Re: [Discuss] MPLUGIN-40

[Jan Nielsen]

FWIW, I (and probably 99.9% of the Maven user-base) have desired just
this kind of option for plugins for a  l o o o n g  time. Something
like:

  mvn nifty help
  mvn nifty -h
  mvn nifty --help
  mvn nifty:help
  mvn nifty:option
  mvn nifty

and if you do:

  mvn nifty:invalid

you just get the help (where "nifty" is any plugin; "any", as in for
all plugins...if the plugin can be downloaded, help is there). That's
pretty canonical CLI behavior.

I don't know whether that's something that requires a modification to
the core of Maven, or not, and I really don't care. It's a huge
dis-service to all users to not have this available, thereby forcing
the user to chase down the web-page for every plugin they have an
interest in. Finding the definitive help information for a plugin
should be absolutely trivial and built-in; having the CLI option which
give the code-you-are-executing-right-now the ability to answer that
question avoids the issues we have today with multiple sources for a
plugin with different HTML usage information.

And while I'm at it, and relatedly, whatever happened to "-G" to get
me a list of all plugins??? I know it ain't easy, but how about giving
me a list of all the names of the plugins found in the configured
repositories when I do "mvn -G", or "mvn plugin:help", or "mvn
plugin:list", whatever. Cache the result in the repositories if
you need to, but make it easy for the user to find and use plugins.
And I might as well chuck in: why in the world do I need to do "mvn
nifty:nifty" and not just "mvn nifty"? Yes; a plugin can have more
than one goal - that's great; but if I do "mvn nifty" it just means
"mvn nifty:nifty" and if I do "mvn nifty:wizbang" well, then that's
the wizbang goal of the nifty plugin.

-Jan


On Feb 4, 2008 5:09 AM, Vincent Siveton <[EMAIL PROTECTED]> wrote:
> Hi,
>
> 2008/2/3, Jason van Zyl <[EMAIL PROTECTED]>:
> > I think keeping this out of the core, be that the lifecycle executor
> > or the CLI would be a far better option.
>
> Agree for CLI.
>
> > Vincent, just to be clear you have taken the logic that already exists
> > in the help plugin?
>
> More wrapped logic from PluginXdocGenerator.
>
> Cheers,
>
> Vincent
>
>
> > On 3-Feb-08, at 3:17 PM, Brett Porter wrote:
> >
> > > Something like
> > >
> > > mvn -H idea:idea or mvn -H idea
> > >
> > > which is akin to what Subversion has, for example.
> > >
> > > this would allow the CLI to translate to the appropriate
> > > help:describe goal and then exit, which is pretty clean, as compared
> > > to modifying the lifecycle executor.
> > >
> > > - Brett
> > >
> > > On 04/02/2008, at 10:13 AM, Vincent Siveton wrote:
> > >
> > >> Hi Brett,
> > >>
> > >> What do you propose for cmd line switch?
> > >>
> > >> Personally, I am fine with mvn my-plugin:help which seems more
> > >> common.
> > >> A lot of tools (all?) have an help option.
> > >>
> > >> Cheers,
> > >>
> > >> Vincent
> > >>
> > >> 2008/2/3, Brett Porter <[EMAIL PROTECTED]>:
> > >>> Would a different lifecycle or command line switch be more intuitive
> > >>> than this?
> > >>>
> > >>> On 04/02/2008, at 9:55 AM, Vincent Siveton wrote:
> > >>>
> >  Hi,
> > 
> >  I realize that the fix for MPLUGIN-40 (All plugins should by
> >  default
> >  have an auto-generated goal 'help') is definitely *not* intuitive
> >  for
> >  the end user.
> > 
> >  Background:
> >  I created a plugin-plugin goal which generates an Help mojo. This
> >  generated mojo just displays the goals and their
> >  description/parameters for a given plugin project. Since it is a
> >  goal
> >  inside the maven-plugin-plugin, we need to release it and *all*
> >  plugins to make available this new feature (it could take a
> >  time ;) ).
> > 
> >  I proposed another approach: modify the DefaultLifecycleExecutor to
> >  handle this particular goal. So we could call "mvn idea:help" to
> >  display all available idea goals and "mvn idea:toto" will throw an
> >  exception by displaying the help.
> >  Pro: more easy for the end user and works for all plugins
> >  Con: just available in mvn 2.0.9+
> > 
> >  WDYT?
> > 
> >  Vincent
> > 
> >  -
> >  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

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

[Raphaël Piéroni]

Hi,

http://people.apache.org/~rafale/site/maven-archetype-plugin/

Here is the actual documentation.
Please consider it is a work in progress.

Raphaël

2008/2/4, Brian E. Fox <[EMAIL PROTECTED]>:
> It's interactive by default so pretty easy to use. The other new goal is 
> create-from-project where you run it in a project and it will walk you 
> through making an archetype of that project (it goes into 
> /target/generated-sources where you can then go and install/deploy it)
>
> -Original Message-
> From: Raphaël Piéroni [mailto:[EMAIL PROTECTED]
> Sent: Monday, February 04, 2008 3:36 AM
> To: Maven Developers List
> Subject: Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-1
>
> How to use it :
> mvn archetype:create.
>
> Regards,
>
> Raphaël
>
> 2008/2/4, Jorg Heymans <[EMAIL PROTECTED]>:
> > (sorry for hijacking the vote thread for this)
> >
> > Hi Raphaël,
> >
> > Can you give us some pointers to list threads, proposals or specs that
> > explain the basics of the new architecture and how to use it ? I'm very keen
> > to try it out and give you all the feedback you want, but if it means
> > grepping the sources to find out how things work i'll hold off until
> > alpha-2.
> >
> > Thanks!
> > Jorg
> >
> > On Feb 2, 2008 1:25 AM, Raphaël Piéroni <[EMAIL PROTECTED]> wrote:
> >
> > > Hi,
> > >
> > > Here comes the time for calling the first release of the Maven
> > > Archetype plugin version 2.0-alpha-1.
> > >
> > > Staging repo:
> > > http://people.apache.org/~rafale/staging-repo/maven-archetype-plugin/
> > >
> > > Staging site:
> > > No staging site now, the new documentation is not yet written.
> > > Its is planed for version 2.0-alpha-2.
> > >
> > > Vote open for 96 hours.
> > >
> > > [ ] +1
> > > [ ] +0
> > > [ ] -1
> > >
> > >
> > > Regards,
> > >
> > > Raphaël
> > >
> >
>

Re: XMLRPC Extensions

[Emmanuel Venisse]

I think we use actually XMLRPC extensiosns (
http://ws.apache.org/xmlrpc/extensions.html). I can't remember why, but
maybe you can remove it in the xmlrpc server part to see if it run without
them.

Emmanuel

On Feb 4, 2008 7:55 PM, jimmy <[EMAIL PROTECTED]> wrote:

> I am wondering exactly what the XMLRPC Extensions are that you are using
> entail?
>
> I am trying to write an XMLRPC Client in Python to connect to Continuum
> but it appears that the standard XMLRPC implementation provided by
> Python does not work and I am trying to pinpoint the problem
>
> I have been diving into Continuum code trying to figure out how it
> differs from a standard XMLRPC implementation.
>
> Right now my best guess is an authentication problem using Python's
> XMLRPC library but that is just a guess.
>
> Basically every command I try to execute on my Continuum server I get a
> fault error message of 'No such handler: system.listMethods'
>
> Any information or pointers would be beneficial.
>
> Thank You
>
> Jimmy
>
>

Re: Upgrade the version of maven to build all plugins on m.z.a.o was Re: Install maven 2.0.8 on maven.zones.a.o

[Arnaud HERITIER]

I made the change to use maven 2.0.8 and jdk 1.4.2, but for integration
tests it seems that it is always maven 2.0.7 which is used. Any idea ?

Arnaud

On Feb 4, 2008 2:16 AM, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:

> Everybody is ok to upgrade the version of maven used to build all our
> plugins on maven.zones.apache.org (from 2.0.7 to 2.0.8) ?
>
> Arnaud
>
> On Feb 4, 2008 1:50 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
>
> > It's kind of like Maven inheritence, you can't block inheriting things
> > from the group.
> >
> > I would be ok with building all the plugins with 2.0.8 as the latest
> > release...
> >
> > On 04/02/2008, at 11:47 AM, Arnaud HERITIER wrote:
> >
> > > Finally I already did it but I have a question about continuum.
> > > Can I ask to one project to use a different profile of the one
> > > defined in
> > > the group ?
> > > It seems to not be possible.
> > > I can add a new build for the eclipse plugin with this profile but
> > > it will
> > > continue to be built (and to fail) with builds defined in the group ?
> > > And I 'm not sure that it is a good idea to upgrade the version of
> > > maven for
> > > all our plugins ?
> > >
> > > WDYT ?
> > >
> > > Arnaud
> > >
> > > On Feb 4, 2008 1:32 AM, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:
> > >
> > >> yes it's good, I can administrate profiles.
> > >> thanks. I'll do the setup tomorrow
> > >>
> > >> cheers
> > >>
> > >>
> > >> On Feb 4, 2008 1:28 AM, Brett Porter <[EMAIL PROTECTED]> wrote:
> > >>
> > >>> you should be able to add that now
> > >>>
> > >>> On 04/02/2008, at 10:29 AM, Arnaud HERITIER wrote:
> > >>>
> >  yep, the second one. I would like to be able to configure the
> >  eclipse plugin
> >  to use it when I'll install it.
> > 
> >  Arnaud
> > 
> >  On Feb 3, 2008 11:43 PM, Brett Porter <[EMAIL PROTECTED]> wrote:
> > 
> > > You have a log in on the machine so should be able to install it -
> > > ore
> > > are you referring to have it included in the Continuum profiles?
> > >
> > > - Brett
> > >
> > > On 02/02/2008, at 8:01 AM, Arnaud HERITIER wrote:
> > >
> > >> Nobody ? No idea ?
> > >> I would like to be sure that the build is good before to
> > >> release the
> > >> plugin
> > >> (in almost 1 week)
> > >>
> > >> Arnaud
> > >>
> > >> On Feb 1, 2008 8:59 AM, Arnaud HERITIER <[EMAIL PROTECTED]>
> > >> wrote:
> > >>
> > >>> Hi all,
> > >>>
> > >>> Is it possible to add maven 2.0.8 on our integration server ?
> > >>> The eclipse plugin requires it to build (not to be used - but I
> > >>> have to
> > >>> check) because we have some tests for encoding issues.
> > >>> How can I do it ? I have access to the server but I think that i
> > >>> need to
> > >>> be admin in continuum ?
> > >>>
> > >>> cheers
> > >>>
> > >>> Arnaud
> > >>>
> > >>> --
> > >>> ..
> > >>> Arnaud HERITIER
> > >>> ..
> > >>> OCTO Technology - aheritier AT octo DOT com
> > >>> www.octo.com | blog.octo.com
> > >>> ..
> > >>> ASF - aheritier AT apache DOT org
> > >>> www.apache.org | maven.apache.org
> > >>> ...
> > >>
> > >>
> > >>
> > >>
> > >> --
> > >> ..
> > >> Arnaud HERITIER
> > >> ..
> > >> OCTO Technology - aheritier AT octo DOT com
> > >> www.octo.com | blog.octo.com
> > >> ..
> > >> ASF - aheritier AT apache DOT org
> > >> www.apache.org | maven.apache.org
> > >> ...
> > >
> > >
> > >
> > -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> > 
> > 
> >  --
> >  ..
> >  Arnaud HERITIER
> >  ..
> >  OCTO Technology - aheritier AT octo DOT com
> >  www.octo.com | blog.octo.com
> >  ..
> >  ASF - aheritier AT apache DOT org
> >  www.apache.org | maven.apache.org
> >  ...
> > >>>
> > >>>
> > >>>
> > -
> > >>> To unsubscribe, e-mail: [EMAIL PROTECTED]
> > >>> For additional commands, e-mail: [EMAIL PROTECTED]
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >>
> > >> .

Re: svn commit: r618196 - /maven/artifact/branches/CAP/notes.txt

[Christian Edward Gruber]

A classic use-case of this that I think is orthogonal to "javadoc" and  
"sources" classifiers would be binary native artifacts per-platform.   
Taking libc for a sec, (stupid example, but what the heck...  You  
might have:


libc-2.0.5-win32-win32.dll.
libc-2.0.5-openbsd-i386.so
libc-2.0.5-darwin-i386-ppc.dynlib (fat binary)

These are all built from the same canonical sources, so how would you  
structure them.  Above would be the artifact using a quasi- 
classifier.  If you ended up with crazy projects with "../" throughout  
the build path, you might create 3 modules that actually compiler the  
artifacts, at which point you have:


libc-win32-win32-2.0.5.dll.
libc-openbsd-i386-2.0.5.so
libc-darwin-i386-ppc-2.0.5.dynlib (fat binary)

(where the artifactId of the parent is "libc", and the modules are  
"llibc-win32-win32")


Here you end up with additional craziness on Mac owing to universal  
(fat) binaries, since in the underlying structures it's not universal,  
but i386+ppc.


The point is that neither futzing with modues, or hacking classifiers  
is sufficient.  But associative metadata might just be the trick.


Christian.


On 4-Feb-08, at 13:45 , John Casey wrote:

I can accept this, particularly if it leads to having dependency  
metadata that is specific to these [formerly attached] artifacts.  
Assemblies that contain their dependencies, when used as  
dependencies, should affect dependency resolution differently than  
the associated "naked" jar...which to me means it needs different  
dependency metadata.


I'm fine with defining a superset of the association mechanism that  
includes artifacts currently deployed with classifiers, as long as  
we can use what's out there now without creating another buggy  
metadata deficit like we did when moving from Maven 1.x to 2.0.


-john

On Feb 4, 2008, at 12:38 PM, Jason van Zyl wrote:



On 4-Feb-08, at 8:56 AM, John Casey wrote:

I'd tend to disagree about classifier not being a 'core' part of  
the artifact system...it distinguishes a main artifact from one of  
its derivatives, and serves as a pretty foundational part of how  
we retrieve artifacts from existing remote repositories. Without  
it, I doubt that you can reconstruct the path to some existing  
artifacts (like sources or javadocs) reliably without bastardizing  
the version string.


This is where I think you've already baked in what you think about  
Maven. Look at how we deploy our derivative artifacts right now. We  
don't track any of it in the metadata when we deploy. We toss it up  
there and things hope they are there. Like javadocs, or sources. I  
think what's more important is that the coordinate be unique and we  
have a way to associate what ever artifacts together in a scalable  
way. So you say "I want to associate this artifact with that one,  
this is how I would like to record that relationship in the  
metadata.". Subsequently you can query the metadata and know these  
relationships. We currently don't do this. It generally boils down  
to a bunch of coordinates in the repository. How we choose to  
relate them via the metadata. We have all sort of problems with  
classifiers currently because it was an adhoc method of  
association. A general model of association would be a superset of  
what we currently do for classifiers. I agree we need an mechanism  
for association, I don't think classifiers have worked all that well.





We can see that the artifact system has certain inescapable  
identity attributes. Scope is obviously more related to how an  
artifact is used, since you can't see any trace of scope in the  
artifact as it's been deployed on a remote repository. Classifier,  
however, doesn't fit this criteria...it's not a usage marker, but  
an identity marker.


The rest I agree with.

-john

On Feb 4, 2008, at 3:00 AM, [EMAIL PROTECTED] wrote:


Author: jvanzyl
Date: Mon Feb  4 00:00:21 2008
New Revision: 618196

URL: http://svn.apache.org/viewvc?rev=618196&view=rev
Log:
o notes about the refactoring

Added:
  maven/artifact/branches/CAP/notes.txt   (with props)

Added: maven/artifact/branches/CAP/notes.txt
URL: 
http://svn.apache.org/viewvc/maven/artifact/branches/CAP/notes.txt?rev=618196&view=auto
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
= 
===

--- maven/artifact/branches/CAP/notes.txt (added)
+++ maven/artifact/branches/CAP/notes.txt Mon Feb  4 00:00:21 2008
@@ -0,0 +1,28 @@
+Maven Artifact is supposed to be a general artifact mechanism  
for retrieving, installing, and deploying artifacts
+to repositories. Maven Artifact was originally decoupled from  
Maven proper and as such carries a lot of baggage
+which prevents it from being used generally and carries many  
notions that are very specific to Maven itself. Artifacts
+currently have a notion of scope, classifiers, and behavioral  
attributes such as whether scopes should be inherited.
+For any mechanism to work generally these baked in no

Re: svn commit: r618196 - /maven/artifact/branches/CAP/notes.txt

[John Casey]

I can accept this, particularly if it leads to having dependency  
metadata that is specific to these [formerly attached] artifacts.  
Assemblies that contain their dependencies, when used as  
dependencies, should affect dependency resolution differently than  
the associated "naked" jar...which to me means it needs different  
dependency metadata.


I'm fine with defining a superset of the association mechanism that  
includes artifacts currently deployed with classifiers, as long as we  
can use what's out there now without creating another buggy metadata  
deficit like we did when moving from Maven 1.x to 2.0.


-john

On Feb 4, 2008, at 12:38 PM, Jason van Zyl wrote:



On 4-Feb-08, at 8:56 AM, John Casey wrote:

I'd tend to disagree about classifier not being a 'core' part of  
the artifact system...it distinguishes a main artifact from one of  
its derivatives, and serves as a pretty foundational part of how  
we retrieve artifacts from existing remote repositories. Without  
it, I doubt that you can reconstruct the path to some existing  
artifacts (like sources or javadocs) reliably without bastardizing  
the version string.


This is where I think you've already baked in what you think about  
Maven. Look at how we deploy our derivative artifacts right now. We  
don't track any of it in the metadata when we deploy. We toss it up  
there and things hope they are there. Like javadocs, or sources. I  
think what's more important is that the coordinate be unique and we  
have a way to associate what ever artifacts together in a scalable  
way. So you say "I want to associate this artifact with that one,  
this is how I would like to record that relationship in the  
metadata.". Subsequently you can query the metadata and know these  
relationships. We currently don't do this. It generally boils down  
to a bunch of coordinates in the repository. How we choose to  
relate them via the metadata. We have all sort of problems with  
classifiers currently because it was an adhoc method of  
association. A general model of association would be a superset of  
what we currently do for classifiers. I agree we need an mechanism  
for association, I don't think classifiers have worked all that well.





We can see that the artifact system has certain inescapable  
identity attributes. Scope is obviously more related to how an  
artifact is used, since you can't see any trace of scope in the  
artifact as it's been deployed on a remote repository. Classifier,  
however, doesn't fit this criteria...it's not a usage marker, but  
an identity marker.


The rest I agree with.

-john

On Feb 4, 2008, at 3:00 AM, [EMAIL PROTECTED] wrote:


Author: jvanzyl
Date: Mon Feb  4 00:00:21 2008
New Revision: 618196

URL: http://svn.apache.org/viewvc?rev=618196&view=rev
Log:
o notes about the refactoring

Added:
   maven/artifact/branches/CAP/notes.txt   (with props)

Added: maven/artifact/branches/CAP/notes.txt
URL: http://svn.apache.org/viewvc/maven/artifact/branches/CAP/ 
notes.txt?rev=618196&view=auto
 
==

--- maven/artifact/branches/CAP/notes.txt (added)
+++ maven/artifact/branches/CAP/notes.txt Mon Feb  4 00:00:21 2008
@@ -0,0 +1,28 @@
+Maven Artifact is supposed to be a general artifact mechanism  
for retrieving, installing, and deploying artifacts
+to repositories. Maven Artifact was originally decoupled from  
Maven proper and as such carries a lot of baggage
+which prevents it from being used generally and carries many  
notions that are very specific to Maven itself. Artifacts
+currently have a notion of scope, classifiers, and behavioral  
attributes such as whether scopes should be inherited.
+For any mechanism to work generally these baked in notions need  
to be removed, vetted, and then made compatible with
+notions currently in Maven. A list of things that should not be  
in the Artifact:

+
+ * scope
+ * classifier
+ * dependency filter
+ * dependency trail
+ * resolved
+ * released
+ * optional
+ * available versions
+
+These are all attributes of the target system
+
+*Removal of the ArtifactFactory
+
+ 3 February 2008 (Sunday)
+
+ I have removed the factory and left only a small set of  
constructors (which I would like to reduce to one) so that you
+ have a valid artifact after construction. I have also started  
to hide the VersionRange creation. You just pass in
+ a string and the constructor for the DefaultArtifact will do  
the right thing. This will ultimately need to be more
+ pluggable as different versioning strategies happen. But  
variations of the theme like Maven, OSGi, will have their

+ own subclasses and tools to operate on the graphs of dependencies.
+

Propchange: maven/artifact/branches/CAP/notes.txt
 
--

   svn:eol-style = native

Propchange: maven/artifact/branches/CAP/notes.txt
---

Unresolved Expressions: null or expression literal?

[Benjamin Bentmann]

Hello,

A question: What is the result of an expression evalution when the
referenced property/getter/object does not exist?

I recently struggled with a Beanshell rule for the Maven Enforcer Plugin
when the project is run by the Maven Integration for Eclipse. For example,
the following (non-sense) Beanshell snippet

System.out.println(${missing.property});
true;

outputs

 null

when run on the console (with Maven 2.0.8). Running the same POM inside
Eclipse (with org.maven.ide.eclipse_0.0.12.20071107-2300) yields

 inline evaluation of: ``System.out.println(${missing.property}); true;'' :
 Attempt to access property on undefined variable or class name

i.e. the Beanshell interpreter sees the literal expression instead of null.

Now, what is the right behavior or is this an intended change for Maven 2.1?

Thanks in advance,


Benjamin Bentmann


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

Re: svn commit: r618196 - /maven/artifact/branches/CAP/notes.txt

[Jason van Zyl]

On 4-Feb-08, at 8:56 AM, John Casey wrote:

I'd tend to disagree about classifier not being a 'core' part of the  
artifact system...it distinguishes a main artifact from one of its  
derivatives, and serves as a pretty foundational part of how we  
retrieve artifacts from existing remote repositories. Without it, I  
doubt that you can reconstruct the path to some existing artifacts  
(like sources or javadocs) reliably without bastardizing the version  
string.


This is where I think you've already baked in what you think about  
Maven. Look at how we deploy our derivative artifacts right now. We  
don't track any of it in the metadata when we deploy. We toss it up  
there and things hope they are there. Like javadocs, or sources. I  
think what's more important is that the coordinate be unique and we  
have a way to associate what ever artifacts together in a scalable  
way. So you say "I want to associate this artifact with that one, this  
is how I would like to record that relationship in the metadata.".  
Subsequently you can query the metadata and know these relationships.  
We currently don't do this. It generally boils down to a bunch of  
coordinates in the repository. How we choose to relate them via the  
metadata. We have all sort of problems with classifiers currently  
because it was an adhoc method of association. A general model of  
association would be a superset of what we currently do for  
classifiers. I agree we need an mechanism for association, I don't  
think classifiers have worked all that well.





We can see that the artifact system has certain inescapable identity  
attributes. Scope is obviously more related to how an artifact is  
used, since you can't see any trace of scope in the artifact as it's  
been deployed on a remote repository. Classifier, however, doesn't  
fit this criteria...it's not a usage marker, but an identity marker.


The rest I agree with.

-john

On Feb 4, 2008, at 3:00 AM, [EMAIL PROTECTED] wrote:


Author: jvanzyl
Date: Mon Feb  4 00:00:21 2008
New Revision: 618196

URL: http://svn.apache.org/viewvc?rev=618196&view=rev
Log:
o notes about the refactoring

Added:
   maven/artifact/branches/CAP/notes.txt   (with props)

Added: maven/artifact/branches/CAP/notes.txt
URL: 
http://svn.apache.org/viewvc/maven/artifact/branches/CAP/notes.txt?rev=618196&view=auto
= 
= 
= 
= 
= 
= 
= 
= 
= 
=

--- maven/artifact/branches/CAP/notes.txt (added)
+++ maven/artifact/branches/CAP/notes.txt Mon Feb  4 00:00:21 2008
@@ -0,0 +1,28 @@
+Maven Artifact is supposed to be a general artifact mechanism for  
retrieving, installing, and deploying artifacts
+to repositories. Maven Artifact was originally decoupled from  
Maven proper and as such carries a lot of baggage
+which prevents it from being used generally and carries many  
notions that are very specific to Maven itself. Artifacts
+currently have a notion of scope, classifiers, and behavioral  
attributes such as whether scopes should be inherited.
+For any mechanism to work generally these baked in notions need to  
be removed, vetted, and then made compatible with
+notions currently in Maven. A list of things that should not be in  
the Artifact:

+
+ * scope
+ * classifier
+ * dependency filter
+ * dependency trail
+ * resolved
+ * released
+ * optional
+ * available versions
+
+These are all attributes of the target system
+
+*Removal of the ArtifactFactory
+
+ 3 February 2008 (Sunday)
+
+ I have removed the factory and left only a small set of  
constructors (which I would like to reduce to one) so that you
+ have a valid artifact after construction. I have also started to  
hide the VersionRange creation. You just pass in
+ a string and the constructor for the DefaultArtifact will do the  
right thing. This will ultimately need to be more
+ pluggable as different versioning strategies happen. But  
variations of the theme like Maven, OSGi, will have their

+ own subclasses and tools to operate on the graphs of dependencies.
+

Propchange: maven/artifact/branches/CAP/notes.txt
--
   svn:eol-style = native

Propchange: maven/artifact/branches/CAP/notes.txt
--
   svn:keywords = "Author Date Id Revision"




---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john




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]

Re: svn commit: r618196 - /maven/artifact/branches/CAP/notes.txt

[John Casey]

I'd tend to disagree about classifier not being a 'core' part of the  
artifact system...it distinguishes a main artifact from one of its  
derivatives, and serves as a pretty foundational part of how we  
retrieve artifacts from existing remote repositories. Without it, I  
doubt that you can reconstruct the path to some existing artifacts  
(like sources or javadocs) reliably without bastardizing the version  
string.


We can see that the artifact system has certain inescapable identity  
attributes. Scope is obviously more related to how an artifact is  
used, since you can't see any trace of scope in the artifact as it's  
been deployed on a remote repository. Classifier, however, doesn't  
fit this criteria...it's not a usage marker, but an identity marker.


The rest I agree with.

-john

On Feb 4, 2008, at 3:00 AM, [EMAIL PROTECTED] wrote:


Author: jvanzyl
Date: Mon Feb  4 00:00:21 2008
New Revision: 618196

URL: http://svn.apache.org/viewvc?rev=618196&view=rev
Log:
o notes about the refactoring

Added:
maven/artifact/branches/CAP/notes.txt   (with props)

Added: maven/artifact/branches/CAP/notes.txt
URL: http://svn.apache.org/viewvc/maven/artifact/branches/CAP/ 
notes.txt?rev=618196&view=auto
== 


--- maven/artifact/branches/CAP/notes.txt (added)
+++ maven/artifact/branches/CAP/notes.txt Mon Feb  4 00:00:21 2008
@@ -0,0 +1,28 @@
+Maven Artifact is supposed to be a general artifact mechanism for  
retrieving, installing, and deploying artifacts
+to repositories. Maven Artifact was originally decoupled from  
Maven proper and as such carries a lot of baggage
+which prevents it from being used generally and carries many  
notions that are very specific to Maven itself. Artifacts
+currently have a notion of scope, classifiers, and behavioral  
attributes such as whether scopes should be inherited.
+For any mechanism to work generally these baked in notions need to  
be removed, vetted, and then made compatible with
+notions currently in Maven. A list of things that should not be in  
the Artifact:

+
+ * scope
+ * classifier
+ * dependency filter
+ * dependency trail
+ * resolved
+ * released
+ * optional
+ * available versions
+
+These are all attributes of the target system
+
+*Removal of the ArtifactFactory
+
+ 3 February 2008 (Sunday)
+
+ I have removed the factory and left only a small set of  
constructors (which I would like to reduce to one) so that you
+ have a valid artifact after construction. I have also started to  
hide the VersionRange creation. You just pass in
+ a string and the constructor for the DefaultArtifact will do the  
right thing. This will ultimately need to be more
+ pluggable as different versioning strategies happen. But  
variations of the theme like Maven, OSGi, will have their

+ own subclasses and tools to operate on the graphs of dependencies.
+

Propchange: maven/artifact/branches/CAP/notes.txt
-- 


svn:eol-style = native

Propchange: maven/artifact/branches/CAP/notes.txt
-- 


svn:keywords = "Author Date Id Revision"




---
John Casey
Committer and PMC Member, Apache Maven
mail: jdcasey at commonjava dot org
blog: http://www.ejlife.net/blogs/john
rss: http://feeds.feedburner.com/ejlife/john

Re: [Discuss] MPLUGIN-40

[Jason van Zyl]

On 4-Feb-08, at 4:09 AM, Vincent Siveton wrote:


Hi,

2008/2/3, Jason van Zyl <[EMAIL PROTECTED]>:

I think keeping this out of the core, be that the lifecycle executor
or the CLI would be a far better option.


Agree for CLI.



I'm not saying the CLI is a good option. I think it's a bad option.  
Keep this out of the core. It's perfectly fine as a plugin. The core  
and the CLI calling to a wrapper for something housed in a plugin is  
not a good idea. Generate it as part of the new tools, promote it and  
it will get picked up in new plugin releases.


Vincent, just to be clear you have taken the logic that already  
exists

in the help plugin?


More wrapped logic from PluginXdocGenerator.

Cheers,

Vincent


On 3-Feb-08, at 3:17 PM, Brett Porter wrote:


Something like

mvn -H idea:idea or mvn -H idea

which is akin to what Subversion has, for example.

this would allow the CLI to translate to the appropriate
help:describe goal and then exit, which is pretty clean, as compared
to modifying the lifecycle executor.

- Brett

On 04/02/2008, at 10:13 AM, Vincent Siveton wrote:


Hi Brett,

What do you propose for cmd line switch?

Personally, I am fine with mvn my-plugin:help which seems more
common.
A lot of tools (all?) have an help option.

Cheers,

Vincent

2008/2/3, Brett Porter <[EMAIL PROTECTED]>:
Would a different lifecycle or command line switch be more  
intuitive

than this?

On 04/02/2008, at 9:55 AM, Vincent Siveton wrote:


Hi,

I realize that the fix for MPLUGIN-40 (All plugins should by
default
have an auto-generated goal 'help') is definitely *not* intuitive
for
the end user.

Background:
I created a plugin-plugin goal which generates an Help mojo. This
generated mojo just displays the goals and their
description/parameters for a given plugin project. Since it is a
goal
inside the maven-plugin-plugin, we need to release it and *all*
plugins to make available this new feature (it could take a
time ;) ).

I proposed another approach: modify the  
DefaultLifecycleExecutor to

handle this particular goal. So we could call "mvn idea:help" to
display all available idea goals and "mvn idea:toto" will throw  
an

exception by displaying the help.
Pro: more easy for the end user and works for all plugins
Con: just available in mvn 2.0.9+

WDYT?

Vincent

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



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]



Thanks,

Jason

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

Three people can keep a secret provided two of them are dead.

-- Unknown 





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

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

[Mauro Talevi]

+1

Raphaël Piéroni wrote:

Hi,

Here comes the time for calling the first release of the Maven
Archetype plugin version 2.0-alpha-1.

Staging repo:
http://people.apache.org/~rafale/staging-repo/maven-archetype-plugin/

Staging site:
No staging site now, the new documentation is not yet written.
Its is planed for version 2.0-alpha-2.

Vote open for 96 hours.

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


Regards,

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

[Milos Kleint]

+1

Milos

On Feb 2, 2008 1:25 AM, Raphaël Piéroni <[EMAIL PROTECTED]> wrote:
> Hi,
>
> Here comes the time for calling the first release of the Maven
> Archetype plugin version 2.0-alpha-1.
>
> Staging repo:
> http://people.apache.org/~rafale/staging-repo/maven-archetype-plugin/
>
> Staging site:
> No staging site now, the new documentation is not yet written.
> Its is planed for version 2.0-alpha-2.
>
> Vote open for 96 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Regards,
>
> 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-1

[Brian E. Fox]

It's interactive by default so pretty easy to use. The other new goal is 
create-from-project where you run it in a project and it will walk you through 
making an archetype of that project (it goes into /target/generated-sources 
where you can then go and install/deploy it)

-Original Message-
From: Raphaël Piéroni [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 04, 2008 3:36 AM
To: Maven Developers List
Subject: Re: [VOTE] Release Maven Archetype plugin version 2.0-alpha-1

How to use it :
mvn archetype:create.

Regards,

Raphaël

2008/2/4, Jorg Heymans <[EMAIL PROTECTED]>:
> (sorry for hijacking the vote thread for this)
>
> Hi Raphaël,
>
> Can you give us some pointers to list threads, proposals or specs that
> explain the basics of the new architecture and how to use it ? I'm very keen
> to try it out and give you all the feedback you want, but if it means
> grepping the sources to find out how things work i'll hold off until
> alpha-2.
>
> Thanks!
> Jorg
>
> On Feb 2, 2008 1:25 AM, Raphaël Piéroni <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > Here comes the time for calling the first release of the Maven
> > Archetype plugin version 2.0-alpha-1.
> >
> > Staging repo:
> > http://people.apache.org/~rafale/staging-repo/maven-archetype-plugin/
> >
> > Staging site:
> > No staging site now, the new documentation is not yet written.
> > Its is planed for version 2.0-alpha-2.
> >
> > Vote open for 96 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Regards,
> >
> > Raphaël
> >
>

Re: [Discuss] MPLUGIN-40

[Vincent Siveton]

Hi,

2008/2/3, Jason van Zyl <[EMAIL PROTECTED]>:
> I think keeping this out of the core, be that the lifecycle executor
> or the CLI would be a far better option.

Agree for CLI.

> Vincent, just to be clear you have taken the logic that already exists
> in the help plugin?

More wrapped logic from PluginXdocGenerator.

Cheers,

Vincent

> On 3-Feb-08, at 3:17 PM, Brett Porter wrote:
>
> > Something like
> >
> > mvn -H idea:idea or mvn -H idea
> >
> > which is akin to what Subversion has, for example.
> >
> > this would allow the CLI to translate to the appropriate
> > help:describe goal and then exit, which is pretty clean, as compared
> > to modifying the lifecycle executor.
> >
> > - Brett
> >
> > On 04/02/2008, at 10:13 AM, Vincent Siveton wrote:
> >
> >> Hi Brett,
> >>
> >> What do you propose for cmd line switch?
> >>
> >> Personally, I am fine with mvn my-plugin:help which seems more
> >> common.
> >> A lot of tools (all?) have an help option.
> >>
> >> Cheers,
> >>
> >> Vincent
> >>
> >> 2008/2/3, Brett Porter <[EMAIL PROTECTED]>:
> >>> Would a different lifecycle or command line switch be more intuitive
> >>> than this?
> >>>
> >>> On 04/02/2008, at 9:55 AM, Vincent Siveton wrote:
> >>>
>  Hi,
> 
>  I realize that the fix for MPLUGIN-40 (All plugins should by
>  default
>  have an auto-generated goal 'help') is definitely *not* intuitive
>  for
>  the end user.
> 
>  Background:
>  I created a plugin-plugin goal which generates an Help mojo. This
>  generated mojo just displays the goals and their
>  description/parameters for a given plugin project. Since it is a
>  goal
>  inside the maven-plugin-plugin, we need to release it and *all*
>  plugins to make available this new feature (it could take a
>  time ;) ).
> 
>  I proposed another approach: modify the DefaultLifecycleExecutor to
>  handle this particular goal. So we could call "mvn idea:help" to
>  display all available idea goals and "mvn idea:toto" will throw an
>  exception by displaying the help.
>  Pro: more easy for the end user and works for all plugins
>  Con: just available in mvn 2.0.9+
> 
>  WDYT?
> 
>  Vincent
> 
>  -
>  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]
> >
>
> 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: [Discuss] MPLUGIN-40

[Vincent Siveton]

Hi,

2008/2/3, Brett Porter <[EMAIL PROTECTED]>:
> Something like
>
> mvn -H idea:idea or mvn -H idea

I didn't think about this kind of CLI option before! It sounds good
for the end user.

> which is akin to what Subversion has, for example.
>
> this would allow the CLI to translate to the appropriate help:describe
> goal and then exit, which is pretty clean, as compared to modifying
> the lifecycle executor.

Yeah it was the goal of my question :) I felt uncomfortable to modify it.

Cheers,

Vincent

>
> - Brett
>
> On 04/02/2008, at 10:13 AM, Vincent Siveton wrote:
>
> > Hi Brett,
> >
> > What do you propose for cmd line switch?
> >
> > Personally, I am fine with mvn my-plugin:help which seems more common.
> > A lot of tools (all?) have an help option.
> >
> > Cheers,
> >
> > Vincent
> >
> > 2008/2/3, Brett Porter <[EMAIL PROTECTED]>:
> >> Would a different lifecycle or command line switch be more intuitive
> >> than this?
> >>
> >> On 04/02/2008, at 9:55 AM, Vincent Siveton wrote:
> >>
> >>> Hi,
> >>>
> >>> I realize that the fix for MPLUGIN-40 (All plugins should by default
> >>> have an auto-generated goal 'help') is definitely *not* intuitive
> >>> for
> >>> the end user.
> >>>
> >>> Background:
> >>> I created a plugin-plugin goal which generates an Help mojo. This
> >>> generated mojo just displays the goals and their
> >>> description/parameters for a given plugin project. Since it is a
> >>> goal
> >>> inside the maven-plugin-plugin, we need to release it and *all*
> >>> plugins to make available this new feature (it could take a
> >>> time ;) ).
> >>>
> >>> I proposed another approach: modify the DefaultLifecycleExecutor to
> >>> handle this particular goal. So we could call "mvn idea:help" to
> >>> display all available idea goals and "mvn idea:toto" will throw an
> >>> exception by displaying the help.
> >>> Pro: more easy for the end user and works for all plugins
> >>> Con: just available in mvn 2.0.9+
> >>>
> >>> WDYT?
> >>>
> >>> Vincent
> >>>
> >>> -
> >>> 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: Archiva 1.1 Roadmap

[nicolas de loof]

Early version of archiva had on admin menu a "sync repository" entry.

Not sure if the original idea was to manage a classical rsync-like miror or
to isolate local cache for remote proxied repositories.


I would suggest some "virtual" repository

A simple example is my corporate use case : many user don't know maven well
and have no idea what a repository is (and how to configure), so we have
configured settings.xml to mirror all common repositories to the archiva
instance : http://server/archiva/repository/maven

The "maven" managed repository is an aggregate of proxied (central, java.net,
jboss, ...) and managed ones : corporate builds, restricted jars (SUN apis,
oracle driver) and sources bundles (missing in public repos)

This repository, declared in archiva configuration as "managed" is NOT the
one we have to manage ! It only is a facade to other managed and proxied
repositories.


Nico.

> >
> > One item I wanted to single out is the separation between managed
> > repositories used for publishing and those used for caching artifacts
> > from remote repositories. I don't think it makes much sense to have a
> > managed repository that can do both.
>
>
> a big +1 here :) a lot of people has been confused over this especially
> when
> there are quite a handful of repositories being managed.
>
>
> >
> >
> > This separation would allow us to have:
> > * Provide indexing, browsing and search only for "publishing" (See foot
> > note)
> > * RSS feeds for new artifacts in published repositories.
> >
> > Foot note:
> > Allowing to search proxied data is a broken idea - its an incomplete
> > view of a remote repositories and when your dealing with tens of
> > gigabytes of metadata and artifacts this becomes painful and slow.
> >
> > Anyway, I look forward to your comments.
> >
> > Thanks,
> > James Dumay
> >
> >
> Thanks,
> Deng
>

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

[Raphaël Piéroni]

How to use it :
mvn archetype:create.

Regards,

Raphaël

2008/2/4, Jorg Heymans <[EMAIL PROTECTED]>:
> (sorry for hijacking the vote thread for this)
>
> Hi Raphaël,
>
> Can you give us some pointers to list threads, proposals or specs that
> explain the basics of the new architecture and how to use it ? I'm very keen
> to try it out and give you all the feedback you want, but if it means
> grepping the sources to find out how things work i'll hold off until
> alpha-2.
>
> Thanks!
> Jorg
>
> On Feb 2, 2008 1:25 AM, Raphaël Piéroni <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > Here comes the time for calling the first release of the Maven
> > Archetype plugin version 2.0-alpha-1.
> >
> > Staging repo:
> > http://people.apache.org/~rafale/staging-repo/maven-archetype-plugin/
> >
> > Staging site:
> > No staging site now, the new documentation is not yet written.
> > Its is planed for version 2.0-alpha-2.
> >
> > Vote open for 96 hours.
> >
> > [ ] +1
> > [ ] +0
> > [ ] -1
> >
> >
> > Regards,
> >
> > Raphaël
> >
>

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

[Jorg Heymans]

(sorry for hijacking the vote thread for this)

Hi Raphaël,

Can you give us some pointers to list threads, proposals or specs that
explain the basics of the new architecture and how to use it ? I'm very keen
to try it out and give you all the feedback you want, but if it means
grepping the sources to find out how things work i'll hold off until
alpha-2.

Thanks!
Jorg

On Feb 2, 2008 1:25 AM, Raphaël Piéroni <[EMAIL PROTECTED]> wrote:

> Hi,
>
> Here comes the time for calling the first release of the Maven
> Archetype plugin version 2.0-alpha-1.
>
> Staging repo:
> http://people.apache.org/~rafale/staging-repo/maven-archetype-plugin/
>
> Staging site:
> No staging site now, the new documentation is not yet written.
> Its is planed for version 2.0-alpha-2.
>
> Vote open for 96 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
>
> Regards,
>
> Raphaël
>