Re: Depend on a jar via another pom file

2014-01-14 Thread Baptiste Mathus
Well, what "scope" are used here? Thus is a central element to manage
transitivity.

Btw, you should never rely on a dependency to get a dependency you're also
using. You must redeclare it in your own pom. (mvn dependency:analyze can
also help you here).

Cheers
Le 8 janv. 2014 16:59, "Omar@Gmail"  a écrit :

> I have a maven module (lets call it M) that requires aspectjrt but M
> already depends on another pom file that has aspectjrt within its
> dependency tree  like so:
>
> M ->  middle pom -> aspectjrt
>
> The problem is M would not compile unless I express the aspectjrt
> dependency directly in the M pom file, why?
>
> Is there a way for M to get apsectjrt via the middle pom without directly
> depending on aspectjrt?
>


RE: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?

2014-01-14 Thread KARR, DAVID
> -Original Message-
> From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> Sent: Tuesday, January 14, 2014 3:10 PM
> To: Maven Users List
> Subject: Re: Is it possible to deliberately have two dependencies with the
> same groupid, artifactid, and packaging, but different version?
> 
> On 14 January 2014 22:49, KARR, DAVID  wrote:
> 
> > > -Original Message-
> > > From: Barrie Treloar [mailto:baerr...@gmail.com]
> > > Sent: Tuesday, January 14, 2014 2:23 PM
> > > To: Maven Users List
> > > Subject: Re: Is it possible to deliberately have two dependencies with
> > the
> > > same groupid, artifactid, and packaging, but different version?
> > >
> > > On 15 January 2014 01:40, KARR, DAVID  wrote:
> > > > Again, I didn't want to debate whether this is "convenient", I just
> > wanted
> > > to know if Maven dependency resolution and things like the EAR plugin
> > will
> > > have any trouble incorporating multiple dependencies with the same G:A,
> > but
> > > different version.
> > >
> > > David, you've been on the list long enough to see the term "If you
> > > fight Maven you will lose".
> > > That way pain lies.
> >
> > I haven't heard anyone confirm conclusively that this will not work, so up
> > to now it appears to just be an opinion that there's something wrong with
> > this approach.
> >
> 
> Perhaps I just wasn't clear enough...
> 
> Maven will resolve any list of dependencies so that there is a single
> unique version of any GA.
> 
> Where you have a maven does not bomb out when you double list a dependency,
> you will get a single version.
> 
> The correct parsing behaviour that Maven *should* follow is:
> 
> * If the double dependency is in a project *being built* then fail the build
> 
> * If the double dependency is in a dependency of the project being built,
> then resolve to single version.
> 
> AFAIK the only unknown I am aware of is whether the first case applies, but
> in all cases that I am aware of you will only see one version of any GA

Ok, thanks for clarifying.

I guess I'll plan on putting the version number into the artifact id string so 
the G:A will vary.
 
> > I've also been writing software long enough to know that reality often
> > makes theory irrelevant.
> >
> > > You will have much more joy solving the problem in a way that Maven helps
> > > you.
> > >
> > > Does any of Stephen's response help out?
> >
> > I believe that's a different situation.
> >
> > There will be a new version of this artifact every single month such that
> > multiple versions of the same artifact can and will be used at the same
> > time (very soon we will be using 6 at the same time).  It doesn't make
> > sense to me to define a new group id or artifact id every month,
> > considering the only difference between two names (and their contents) will
> > simply be a number, representing its version number.  If the only
> > difference is the version, then it should be reflected in the version
> > number, as that's the primary difference between them.
> >
> >
> > -
> > To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> > For additional commands, e-mail: users-h...@maven.apache.org
> >
> >

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



Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?

2014-01-14 Thread Wayne Fay
> I haven't heard anyone confirm conclusively that this will not work, so up
> to now it appears to just be an opinion that there's something wrong with
> this approach.

Let me make it perfectly clear for you then:
This will not work. Maven will resolve both dependencies with the same
GA and different Vs into a single GAV.

Wayne

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



Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?

2014-01-14 Thread Stephen Connolly
On 14 January 2014 22:49, KARR, DAVID  wrote:

> > -Original Message-
> > From: Barrie Treloar [mailto:baerr...@gmail.com]
> > Sent: Tuesday, January 14, 2014 2:23 PM
> > To: Maven Users List
> > Subject: Re: Is it possible to deliberately have two dependencies with
> the
> > same groupid, artifactid, and packaging, but different version?
> >
> > On 15 January 2014 01:40, KARR, DAVID  wrote:
> > > Again, I didn't want to debate whether this is "convenient", I just
> wanted
> > to know if Maven dependency resolution and things like the EAR plugin
> will
> > have any trouble incorporating multiple dependencies with the same G:A,
> but
> > different version.
> >
> > David, you've been on the list long enough to see the term "If you
> > fight Maven you will lose".
> > That way pain lies.
>
> I haven't heard anyone confirm conclusively that this will not work, so up
> to now it appears to just be an opinion that there's something wrong with
> this approach.
>

Perhaps I just wasn't clear enough...

Maven will resolve any list of dependencies so that there is a single
unique version of any GA.

Where you have a maven does not bomb out when you double list a dependency,
you will get a single version.

The correct parsing behaviour that Maven *should* follow is:

* If the double dependency is in a project *being built* then fail the build

* If the double dependency is in a dependency of the project being built,
then resolve to single version.

AFAIK the only unknown I am aware of is whether the first case applies, but
in all cases that I am aware of you will only see one version of any GA


> I've also been writing software long enough to know that reality often
> makes theory irrelevant.
>
> > You will have much more joy solving the problem in a way that Maven helps
> > you.
> >
> > Does any of Stephen's response help out?
>
> I believe that's a different situation.
>
> There will be a new version of this artifact every single month such that
> multiple versions of the same artifact can and will be used at the same
> time (very soon we will be using 6 at the same time).  It doesn't make
> sense to me to define a new group id or artifact id every month,
> considering the only difference between two names (and their contents) will
> simply be a number, representing its version number.  If the only
> difference is the version, then it should be reflected in the version
> number, as that's the primary difference between them.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


RE: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?

2014-01-14 Thread KARR, DAVID
> -Original Message-
> From: Barrie Treloar [mailto:baerr...@gmail.com]
> Sent: Tuesday, January 14, 2014 2:23 PM
> To: Maven Users List
> Subject: Re: Is it possible to deliberately have two dependencies with the
> same groupid, artifactid, and packaging, but different version?
> 
> On 15 January 2014 01:40, KARR, DAVID  wrote:
> > Again, I didn't want to debate whether this is "convenient", I just wanted
> to know if Maven dependency resolution and things like the EAR plugin will
> have any trouble incorporating multiple dependencies with the same G:A, but
> different version.
> 
> David, you've been on the list long enough to see the term "If you
> fight Maven you will lose".
> That way pain lies.

I haven't heard anyone confirm conclusively that this will not work, so up to 
now it appears to just be an opinion that there's something wrong with this 
approach.

I've also been writing software long enough to know that reality often makes 
theory irrelevant.

> You will have much more joy solving the problem in a way that Maven helps
> you.
> 
> Does any of Stephen's response help out?

I believe that's a different situation.

There will be a new version of this artifact every single month such that 
multiple versions of the same artifact can and will be used at the same time 
(very soon we will be using 6 at the same time).  It doesn't make sense to me 
to define a new group id or artifact id every month, considering the only 
difference between two names (and their contents) will simply be a number, 
representing its version number.  If the only difference is the version, then 
it should be reflected in the version number, as that's the primary difference 
between them.


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



Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?

2014-01-14 Thread Barrie Treloar
On 15 January 2014 01:40, KARR, DAVID  wrote:
> Again, I didn't want to debate whether this is "convenient", I just wanted to 
> know if Maven dependency resolution and things like the EAR plugin will have 
> any trouble incorporating multiple dependencies with the same G:A, but 
> different version.

David, you've been on the list long enough to see the term "If you
fight Maven you will lose".
That way pain lies.

You will have much more joy solving the problem in a way that Maven helps you.

Does any of Stephen's response help out?

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



Why does maven-javadoc-plugin:javadoc execute from an aggregator POM?

2014-01-14 Thread Justin Georgeson
I'm working with a set of eclipse-plugin projects using the Tycho plugins. We 
are trying to embed the javadocs in the plugin jar file, with an extension 
point so that the Javadocs show-up inline in the IDE. Since I need the javadoc 
to be generated prior to the package phase, I have configured the javadoc goal 
in the pluginManagement section of my parent POM, bound to the process-sources 
phase. This works fine when building the eclipse-plugin POM. But when I build 
from an aggregator POM, it fails with the error "No public or protected classes 
found to document." I can run the aggregate goal to get one giant apidocs index 
of all the projects, but that doesn't generate the per-project apidocs to embed 
in each project's jar file because the aggregate goal skips all the 
non-aggregator POMs. So shouldn't the non-aggregate "javadoc" goals quietly not 
fork and execute the javadoc executable when it's processing an aggregator POM 
within the reactor?

--
This e-mail, including any attached files, may contain confidential and 
privileged information for the sole use of the intended recipient.  Any review, 
use, distribution, or disclosure by others is strictly prohibited.  If you are 
not the intended recipient (or authorized to receive information for the 
intended recipient), please contact the sender by reply e-mail and delete all 
copies of this message.


[ANN] WAS6 Maven Plugin version 1.2.1 Released

2014-01-14 Thread Javier Murciego
Hi,

The Mojo team is pleased to announce the release of the WAS6 Maven Plugin
version 1.2.1

This plugin works along with an installation of WebSphere Application
Server (standalone or ND), to provide automated tasks for: generating RMIC
stubs, starting/stopping servers, installing/updating/uninstalling EARs to
application servers, starting/stopping application and run arbitrary
scripts through wsadmin

http://mojo.codehaus.org/was6-maven-plugin/

To get this update, simply specify the version in your project's plugin
configuration:


   org.codehaus.mojo
   was6-maven-plugin
   1.2.1


Some links :

Documentation: http://mojo.codehaus.org/was6-maven-plugin/
JIRA: http://jira.codehaus.org/browse/MWAS
svn:  https://svn.codehaus.org/mojo/tags/was6-maven-plugin-1.2.1/

Release Notes are available at
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11730&version=19594

**Bug
*[MWAS-70] - Skip does not work for wsAdmin, wsStartServer and wsStopServer
*[MWAS-72] - WSEJBDeploy fails when pom uses system or provided
dependencies.
*[MWAS-73] - WSDL2Java fails when pom uses system or provided dependencies.
**New Feature
*[MWAS-59] - Support install/uninstall and start/stop for WARs

Enjoy,

The Mojo team.

Javier Murciego


Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed

2014-01-14 Thread Anders Hammar
Don't think that's doable as the user could configure the params for
different goals in the same configuration section (on plugin level, not
execution level).

/Anders


On Tue, Jan 14, 2014 at 7:38 PM, S. Ali Tokmen wrote:

> Hi Baptiste, Thomas
>
> I guess you all got a point :) The reason why I want to check the
> configuration is indeed something that would have to be done in each goal.
>
> My remaining question would be whether there is a way to read the
>  XML definition from the MOJO - I could then manually
> implement such a verification in the different MOJOs.
>
> Please advise
>
> Thank you
>
> S. Ali Tokmen
> http://ali.tokmen.com/
>
> My IM, GSM, PGP and other contact details
> are on http://contact.ali.tokmen.com
>
> On 14/01/14 14:24, Baptiste Mathus wrote:
> > Hi,
> > Stephen already answered along those lines. What are you missing?
> > Cheers
> >
> >
> > 2014/1/9 S. Ali Tokmen 
> >
> >> Hi Anders
> >>
> >> Thanks for your reply - and happy new year :)
> >>
> >> Is there any way I can inject / read the whole plugin configuration from
> >> the plugin?
> >>
> >> Best regards
> >>
> >> S. Ali Tokmen
> >> http://ali.tokmen.com/
> >>
> >> My IM, GSM, PGP and other contact details
> >> are on http://contact.ali.tokmen.com
> >>
> >> On 08/01/14 20:00, Anders Hammar wrote:
> >>> AFAIK there is no support for this. If you think there should be,
> please
> >>> file a ticket [1].
> >>>
> >>> /Anders
> >>>
> >>> [1] http://jira.codehaus.org/browse/MNG/
> >>>
> >>>
> >>> On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen  >>> wrote:
> >>>
>  Dear Maven users
> 
>  I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3
>  plugin; and would have a question with regards to how parameters are
>  managed.
> 
>  We defined our MOJOs with parameters (you can see
> 
> 
> >>
> http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java
>  for example), but what happens is that if a user unwillingly puts a
>  parameter in the wrong place then the plugin execution doesn't stop.
> 
>  As an example, I can write the below POM and build still works (even
>  thought the MOJO has no parameter called "foo"):
> 
>    
>  org.codehaus.cargo
>  cargo-maven2-plugin
>  1.4.6
>  
>    
>  bar
>    
>  
>    
> 
>  Is there any way I can instruct by MOJO to fail if there is an unknown
>  parameter?
> 
>  Please advise
> 
>  Thank you
> 
>  --
> 
>  S. Ali Tokmen
>  http://ali.tokmen.com/
> 
>  My IM, GSM, PGP and other contact details
>  are on http://contact.ali.tokmen.com
> 
> 
>  -
>  To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>  For additional commands, e-mail: users-h...@maven.apache.org
> 
> 
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >> --
> >> Baptiste  MATHUS - http://batmat.net
> >> Sauvez un arbre,
> >> Mangez un castor ! nbsp;! 
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


RE: New logo?

2014-01-14 Thread Will Hoover
Like this?

http://s8.postimg.org/jdcbco351/maven5.png

-Original Message-
From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On
Behalf Of Paul Benedict
Sent: Monday, January 13, 2014 6:32 PM
To: Maven Users List
Subject: Re: New logo?

Great logo, but yes, an orange hat too similar to red hat. If we're using an
Apache feather, maybe we can use a Cowboy hat to complete the theme?


On Mon, Jan 13, 2014 at 5:22 PM, Adam Retter
wrote:

> My personal fear of the hat, is that it is too similar to Redhat IMHO.
>
>
> On 13 January 2014 22:29, John Miller  wrote:
>
>> Well I guess the attachment did not go through..
>>
>>
>>
>> [image: Maven Hat..jpg]
>>
>>
>>
>>
>>
>> Thanks
>>
>> John
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>
>
>
> --
> Adam Retter
>
> skype: adam.retter
> tweet: adamretter
> http://www.adamretter.org.uk
>



--
Cheers,
Paul


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



RE: New logo?

2014-01-14 Thread Will Hoover
Stephen,

Can you add the following two images to the contest entries?

http://s9.postimg.org/ubyk4kczj/maven6.png

http://s8.postimg.org/jdcbco351/maven5.png

-Original Message-
From: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Tuesday, January 14, 2014 11:33 AM
To: Maven Users List
Subject: Re: New logo?

And if you are not a nomadic developer (who jumps from project to project)
then a lot of the benefits of Maven will seem to get in your way... once you
are moving from project to project, knowing that you always have the
`deploy` tent to push the results of your build to the remote repository is
a "good thingT"


On 14 January 2014 16:30, Stephen Connolly
wrote:

> Maven is like a village made from tents... you can move from location 
> to location (project to project) and you bring all the same tents 
> (phases / conventions as to how to build a project) with you. Because 
> we are an Apache project we chose a tent that is keeping with the 
> stylings of the Apache feather logo
>
> There's a post-hoc justification for you ;-)
>
>
> On 14 January 2014 15:51, Mark H. Wood  wrote:
>
>> On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote:
>> > Putting maven-20 in context, you get:
>> >
>> >
>> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-con
>> text.png
>>
>> *Very* nice work, but...what does this Native Americans theme have to 
>> do with "maven"?  Yes, I know, but people *will* ask.  Especially 
>> since the answer has no connection with what Maven would do for them.
>>
>> Unless I'm mistaken, the Maven landing page exists to sell Maven, not 
>> the Apache Software Foundation.  A link to the Foundation's landing 
>> page is quite appropriate and should be easy to find, but that's not 
>> why people come to this page.  They come because they've heard 
>> something about Maven and want to know more, or Google gave them a 
>> link when they asked something about software project management or 
>> build tools, or because some other project had a "built with Maven"
>> link on its page and they're curious.  They'll probably be best 
>> pleased if, at a glance, they can get some notion of what Maven does.
>>
>> Possibly that message simply isn't very visual, and the best one can 
>> do is to select a (formerly) meaningless but unique mascot or 
>> abstract symbol.  Possibly there is an image that will make people think,
"yes!
>> that is Maven in action."
>>
>> I'm really not that sort of visual thinker, but images of structure, 
>> assembly, or gathering seem appropriate.  The best(?) I've been able 
>> to imagine is a funnel with classes falling in and a package falling 
>> out.  Or perhaps an assembly line.  (What do classes look like? beats
>> me.)  Maybe you can do something with the Reactor:  skinny pipes 
>> bring things in, one big pipe lets the product out.
>>
>> --
>> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
>> Machines should not be friendly.  Machines should be obedient.
>>
>
>


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



Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed

2014-01-14 Thread S. Ali Tokmen
Hi Baptiste, Thomas

I guess you all got a point :) The reason why I want to check the
configuration is indeed something that would have to be done in each goal.

My remaining question would be whether there is a way to read the
 XML definition from the MOJO - I could then manually
implement such a verification in the different MOJOs.

Please advise

Thank you

S. Ali Tokmen
http://ali.tokmen.com/

My IM, GSM, PGP and other contact details
are on http://contact.ali.tokmen.com

On 14/01/14 14:24, Baptiste Mathus wrote:
> Hi,
> Stephen already answered along those lines. What are you missing?
> Cheers
>
>
> 2014/1/9 S. Ali Tokmen 
>
>> Hi Anders
>>
>> Thanks for your reply - and happy new year :)
>>
>> Is there any way I can inject / read the whole plugin configuration from
>> the plugin?
>>
>> Best regards
>>
>> S. Ali Tokmen
>> http://ali.tokmen.com/
>>
>> My IM, GSM, PGP and other contact details
>> are on http://contact.ali.tokmen.com
>>
>> On 08/01/14 20:00, Anders Hammar wrote:
>>> AFAIK there is no support for this. If you think there should be, please
>>> file a ticket [1].
>>>
>>> /Anders
>>>
>>> [1] http://jira.codehaus.org/browse/MNG/
>>>
>>>
>>> On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen >> wrote:
>>>
 Dear Maven users

 I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3
 plugin; and would have a question with regards to how parameters are
 managed.

 We defined our MOJOs with parameters (you can see


>> http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java
 for example), but what happens is that if a user unwillingly puts a
 parameter in the wrong place then the plugin execution doesn't stop.

 As an example, I can write the below POM and build still works (even
 thought the MOJO has no parameter called "foo"):

   
 org.codehaus.cargo
 cargo-maven2-plugin
 1.4.6
 
   
 bar
   
 
   

 Is there any way I can instruct by MOJO to fail if there is an unknown
 parameter?

 Please advise

 Thank you

 --

 S. Ali Tokmen
 http://ali.tokmen.com/

 My IM, GSM, PGP and other contact details
 are on http://contact.ali.tokmen.com


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


>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>> --
>> Baptiste  MATHUS - http://batmat.net
>> Sauvez un arbre,
>> Mangez un castor ! nbsp;! 
>>


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



Re: New logo?

2014-01-14 Thread Stephen Connolly
And if you are not a nomadic developer (who jumps from project to project)
then a lot of the benefits of Maven will seem to get in your way... once
you are moving from project to project, knowing that you always have the
`deploy` tent to push the results of your build to the remote repository is
a "good thing™"


On 14 January 2014 16:30, Stephen Connolly
wrote:

> Maven is like a village made from tents... you can move from location to
> location (project to project) and you bring all the same tents (phases /
> conventions as to how to build a project) with you. Because we are an
> Apache project we chose a tent that is keeping with the stylings of the
> Apache feather logo
>
> There's a post-hoc justification for you ;-)
>
>
> On 14 January 2014 15:51, Mark H. Wood  wrote:
>
>> On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote:
>> > Putting maven-20 in context, you get:
>> >
>> >
>> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png
>>
>> *Very* nice work, but...what does this Native Americans theme have to do
>> with "maven"?  Yes, I know, but people *will* ask.  Especially since
>> the answer has no connection with what Maven would do for them.
>>
>> Unless I'm mistaken, the Maven landing page exists to sell Maven, not
>> the Apache Software Foundation.  A link to the Foundation's landing
>> page is quite appropriate and should be easy to find, but that's not
>> why people come to this page.  They come because they've heard
>> something about Maven and want to know more, or Google gave them a
>> link when they asked something about software project management or
>> build tools, or because some other project had a "built with Maven"
>> link on its page and they're curious.  They'll probably be best
>> pleased if, at a glance, they can get some notion of what Maven does.
>>
>> Possibly that message simply isn't very visual, and the best one can
>> do is to select a (formerly) meaningless but unique mascot or abstract
>> symbol.  Possibly there is an image that will make people think, "yes!
>> that is Maven in action."
>>
>> I'm really not that sort of visual thinker, but images of structure,
>> assembly, or gathering seem appropriate.  The best(?) I've been able
>> to imagine is a funnel with classes falling in and a package falling
>> out.  Or perhaps an assembly line.  (What do classes look like? beats
>> me.)  Maybe you can do something with the Reactor:  skinny pipes bring
>> things in, one big pipe lets the product out.
>>
>> --
>> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
>> Machines should not be friendly.  Machines should be obedient.
>>
>
>


Re: New logo?

2014-01-14 Thread Stephen Connolly
Maven is like a village made from tents... you can move from location to
location (project to project) and you bring all the same tents (phases /
conventions as to how to build a project) with you. Because we are an
Apache project we chose a tent that is keeping with the stylings of the
Apache feather logo

There's a post-hoc justification for you ;-)


On 14 January 2014 15:51, Mark H. Wood  wrote:

> On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote:
> > Putting maven-20 in context, you get:
> >
> >
> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png
>
> *Very* nice work, but...what does this Native Americans theme have to do
> with "maven"?  Yes, I know, but people *will* ask.  Especially since
> the answer has no connection with what Maven would do for them.
>
> Unless I'm mistaken, the Maven landing page exists to sell Maven, not
> the Apache Software Foundation.  A link to the Foundation's landing
> page is quite appropriate and should be easy to find, but that's not
> why people come to this page.  They come because they've heard
> something about Maven and want to know more, or Google gave them a
> link when they asked something about software project management or
> build tools, or because some other project had a "built with Maven"
> link on its page and they're curious.  They'll probably be best
> pleased if, at a glance, they can get some notion of what Maven does.
>
> Possibly that message simply isn't very visual, and the best one can
> do is to select a (formerly) meaningless but unique mascot or abstract
> symbol.  Possibly there is an image that will make people think, "yes!
> that is Maven in action."
>
> I'm really not that sort of visual thinker, but images of structure,
> assembly, or gathering seem appropriate.  The best(?) I've been able
> to imagine is a funnel with classes falling in and a package falling
> out.  Or perhaps an assembly line.  (What do classes look like? beats
> me.)  Maybe you can do something with the Reactor:  skinny pipes bring
> things in, one big pipe lets the product out.
>
> --
> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
> Machines should not be friendly.  Machines should be obedient.
>


Re: New logo?

2014-01-14 Thread Stephen Connolly
maven-22: uses some of the imagery from the 60-seconds tutorial to form the
logo

https://cwiki.apache.org/confluence/download/attachments/38569278/maven-22.png?version=1&modificationDate=1389716094692&api=v2


On 14 January 2014 15:55, Stephen Connolly
wrote:

>
>
>
> On 14 January 2014 15:51, Mark H. Wood  wrote:
>
>> On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote:
>> > Putting maven-20 in context, you get:
>> >
>> >
>> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png
>>
>> *Very* nice work, but...what does this Native Americans theme have to do
>> with "maven"?  Yes, I know, but people *will* ask.  Especially since
>> the answer has no connection with what Maven would do for them.
>>
>> Unless I'm mistaken, the Maven landing page exists to sell Maven, not
>> the Apache Software Foundation.  A link to the Foundation's landing
>> page is quite appropriate and should be easy to find, but that's not
>> why people come to this page.  They come because they've heard
>> something about Maven and want to know more, or Google gave them a
>> link when they asked something about software project management or
>> build tools, or because some other project had a "built with Maven"
>> link on its page and they're curious.  They'll probably be best
>> pleased if, at a glance, they can get some notion of what Maven does.
>>
>> Possibly that message simply isn't very visual, and the best one can
>> do is to select a (formerly) meaningless but unique mascot or abstract
>> symbol.  Possibly there is an image that will make people think, "yes!
>> that is Maven in action."
>>
>
> The best I have come up with for an image as to what Maven does is
>
>
> https://cwiki.apache.org/confluence/display/MAVEN/Tutorial%3A+Maven+in+60+seconds
>
> But that does not a good logo make.
>
> Our current "logo" is just the word "maven" with the 'a' in orange
>
> At least this version, or maven-21 includes the Apache feather... and
> hints at us being an Apache project...
>
>
>>
>> I'm really not that sort of visual thinker, but images of structure,
>> assembly, or gathering seem appropriate.  The best(?) I've been able
>> to imagine is a funnel with classes falling in and a package falling
>> out.  Or perhaps an assembly line.  (What do classes look like? beats
>> me.)  Maybe you can do something with the Reactor:  skinny pipes bring
>> things in, one big pipe lets the product out.
>>
>> --
>> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
>> Machines should not be friendly.  Machines should be obedient.
>>
>
>


Re: New logo?

2014-01-14 Thread Mark H. Wood
On Tue, Jan 14, 2014 at 12:45:18PM +, Adam Retter wrote:
> Does the Apache Foundation of any of its members have any money to
> engage a graphical designer? I was just thinking that after the
> voting, you could get a designer to do a proper job on the logo
> (perhaps producing some variations of the voted on design which could
> again be voted on further?). I do not mean any offence to everyone
> that submitted designs, but clearly we are not professional artists
> ;-)

Actually I think the artwork is quite good.  It's the visual language
itself that seems uncertain.  Which points even more strongly to the
need for a graphic designer.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.


signature.asc
Description: Digital signature


Re: New logo?

2014-01-14 Thread Stephen Connolly
On 14 January 2014 15:51, Mark H. Wood  wrote:

> On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote:
> > Putting maven-20 in context, you get:
> >
> >
> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png
>
> *Very* nice work, but...what does this Native Americans theme have to do
> with "maven"?  Yes, I know, but people *will* ask.  Especially since
> the answer has no connection with what Maven would do for them.
>
> Unless I'm mistaken, the Maven landing page exists to sell Maven, not
> the Apache Software Foundation.  A link to the Foundation's landing
> page is quite appropriate and should be easy to find, but that's not
> why people come to this page.  They come because they've heard
> something about Maven and want to know more, or Google gave them a
> link when they asked something about software project management or
> build tools, or because some other project had a "built with Maven"
> link on its page and they're curious.  They'll probably be best
> pleased if, at a glance, they can get some notion of what Maven does.
>
> Possibly that message simply isn't very visual, and the best one can
> do is to select a (formerly) meaningless but unique mascot or abstract
> symbol.  Possibly there is an image that will make people think, "yes!
> that is Maven in action."
>

The best I have come up with for an image as to what Maven does is

https://cwiki.apache.org/confluence/display/MAVEN/Tutorial%3A+Maven+in+60+seconds

But that does not a good logo make.

Our current "logo" is just the word "maven" with the 'a' in orange

At least this version, or maven-21 includes the Apache feather... and hints
at us being an Apache project...


>
> I'm really not that sort of visual thinker, but images of structure,
> assembly, or gathering seem appropriate.  The best(?) I've been able
> to imagine is a funnel with classes falling in and a package falling
> out.  Or perhaps an assembly line.  (What do classes look like? beats
> me.)  Maybe you can do something with the Reactor:  skinny pipes bring
> things in, one big pipe lets the product out.
>
> --
> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
> Machines should not be friendly.  Machines should be obedient.
>


Re: New logo?

2014-01-14 Thread Paul Benedict
Love this logo. Very awesome.


On Tue, Jan 14, 2014 at 9:51 AM, Mark H. Wood  wrote:

> On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote:
> > Putting maven-20 in context, you get:
> >
> >
> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png
>
> *Very* nice work, but...what does this Native Americans theme have to do
> with "maven"?  Yes, I know, but people *will* ask.  Especially since
> the answer has no connection with what Maven would do for them.
>
> Unless I'm mistaken, the Maven landing page exists to sell Maven, not
> the Apache Software Foundation.  A link to the Foundation's landing
> page is quite appropriate and should be easy to find, but that's not
> why people come to this page.  They come because they've heard
> something about Maven and want to know more, or Google gave them a
> link when they asked something about software project management or
> build tools, or because some other project had a "built with Maven"
> link on its page and they're curious.  They'll probably be best
> pleased if, at a glance, they can get some notion of what Maven does.
>
> Possibly that message simply isn't very visual, and the best one can
> do is to select a (formerly) meaningless but unique mascot or abstract
> symbol.  Possibly there is an image that will make people think, "yes!
> that is Maven in action."
>
> I'm really not that sort of visual thinker, but images of structure,
> assembly, or gathering seem appropriate.  The best(?) I've been able
> to imagine is a funnel with classes falling in and a package falling
> out.  Or perhaps an assembly line.  (What do classes look like? beats
> me.)  Maybe you can do something with the Reactor:  skinny pipes bring
> things in, one big pipe lets the product out.
>
> --
> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
> Machines should not be friendly.  Machines should be obedient.
>



-- 
Cheers,
Paul


Re: New logo?

2014-01-14 Thread Mark H. Wood
On Tue, Jan 14, 2014 at 12:08:09PM +, Stephen Connolly wrote:
> Putting maven-20 in context, you get:
> 
> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png

*Very* nice work, but...what does this Native Americans theme have to do
with "maven"?  Yes, I know, but people *will* ask.  Especially since
the answer has no connection with what Maven would do for them.

Unless I'm mistaken, the Maven landing page exists to sell Maven, not
the Apache Software Foundation.  A link to the Foundation's landing
page is quite appropriate and should be easy to find, but that's not
why people come to this page.  They come because they've heard
something about Maven and want to know more, or Google gave them a
link when they asked something about software project management or
build tools, or because some other project had a "built with Maven"
link on its page and they're curious.  They'll probably be best
pleased if, at a glance, they can get some notion of what Maven does.

Possibly that message simply isn't very visual, and the best one can
do is to select a (formerly) meaningless but unique mascot or abstract
symbol.  Possibly there is an image that will make people think, "yes!
that is Maven in action."

I'm really not that sort of visual thinker, but images of structure,
assembly, or gathering seem appropriate.  The best(?) I've been able
to imagine is a funnel with classes falling in and a package falling
out.  Or perhaps an assembly line.  (What do classes look like? beats
me.)  Maybe you can do something with the Reactor:  skinny pipes bring
things in, one big pipe lets the product out.

-- 
Mark H. Wood, Lead System Programmer   mw...@iupui.edu
Machines should not be friendly.  Machines should be obedient.


signature.asc
Description: Digital signature


Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?

2014-01-14 Thread Curtis Rueden
Hi David,

> Again, I didn't want to debate whether this is "convenient", I just
> wanted to know if Maven dependency resolution and things like the EAR
> plugin will have any trouble incorporating multiple dependencies with
> the same G:A, but different version.

I haven't tried it, but personally I would be shocked if Maven allowed this
at all. Did you try it? Does it work?

IMO, the major reason for versions is so that Maven (and humans) knows to
select one from a set. If you need more than one at the same time, change
the value of A.

Including multiple versions of the same artifact violates Maven's current
assumptions rather severely.

Regards,
Curtis


On Tue, Jan 14, 2014 at 9:10 AM, KARR, DAVID  wrote:

> > -Original Message-
> > From: Barrie Treloar [mailto:baerr...@gmail.com]
> > Sent: Monday, January 13, 2014 4:48 PM
> > To: Maven Users List
> > Subject: Re: Is it possible to deliberately have two dependencies with
> the
> > same groupid, artifactid, and packaging, but different version?
> >
> > On 14 January 2014 10:54, KARR, DAVID  wrote:
> > > I have a situation where it would be convenient for my pom to have two
> > dependencies that are almost identical, only being different by the
> version.
> > The makeup of the artifact is such that it would be safe (and intended)
> to
> > use both of them.  The Java package used in each is similar, but
> different.
> > The package will vary along with the version number.
> > >
> > > Will dependency resolution and the EAR plugin (and any other mechanism
> that
> > lists dependencies) have any trouble with this?
> >
> > Can you describe why you think this would be convenient?
> > Have you looked at classifiers?
> > http://stackoverflow.com/questions/8040964/how-to-use-or-abuse-artifact-
> > classifiers-in-maven
>
> A new version of this artifact is produced perhaps once a month.  Perhaps
> 2-3 versions of this artifact will be referenced in the client code base at
> one time.  More versions than that are supported in the server code base,
> throughout all environments.  The only difference in the reported name of
> this artifact from one version to the next is the version number.
>
> Again, I didn't want to debate whether this is "convenient", I just wanted
> to know if Maven dependency resolution and things like the EAR plugin will
> have any trouble incorporating multiple dependencies with the same G:A, but
> different version.
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


RE: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?

2014-01-14 Thread KARR, DAVID
> -Original Message-
> From: Barrie Treloar [mailto:baerr...@gmail.com]
> Sent: Monday, January 13, 2014 4:48 PM
> To: Maven Users List
> Subject: Re: Is it possible to deliberately have two dependencies with the
> same groupid, artifactid, and packaging, but different version?
> 
> On 14 January 2014 10:54, KARR, DAVID  wrote:
> > I have a situation where it would be convenient for my pom to have two
> dependencies that are almost identical, only being different by the version.
> The makeup of the artifact is such that it would be safe (and intended) to
> use both of them.  The Java package used in each is similar, but different.
> The package will vary along with the version number.
> >
> > Will dependency resolution and the EAR plugin (and any other mechanism that
> lists dependencies) have any trouble with this?
> 
> Can you describe why you think this would be convenient?
> Have you looked at classifiers?
> http://stackoverflow.com/questions/8040964/how-to-use-or-abuse-artifact-
> classifiers-in-maven

A new version of this artifact is produced perhaps once a month.  Perhaps 2-3 
versions of this artifact will be referenced in the client code base at one 
time.  More versions than that are supported in the server code base, 
throughout all environments.  The only difference in the reported name of this 
artifact from one version to the next is the version number.

Again, I didn't want to debate whether this is "convenient", I just wanted to 
know if Maven dependency resolution and things like the EAR plugin will have 
any trouble incorporating multiple dependencies with the same G:A, but 
different version.


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



Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed

2014-01-14 Thread Thomas Broyer
Isn't that simply because the  is shared by all goals? (or
all goals of the parent )


On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen wrote:

> Dear Maven users
>
> I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3
> plugin; and would have a question with regards to how parameters are
> managed.
>
> We defined our MOJOs with parameters (you can see
>
> http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java
> for example), but what happens is that if a user unwillingly puts a
> parameter in the wrong place then the plugin execution doesn't stop.
>
> As an example, I can write the below POM and build still works (even
> thought the MOJO has no parameter called "foo"):
>
>   
> org.codehaus.cargo
> cargo-maven2-plugin
> 1.4.6
> 
>   
> bar
>   
> 
>   
>
> Is there any way I can instruct by MOJO to fail if there is an unknown
> parameter?
>
> Please advise
>
> Thank you
>
> --
>
> S. Ali Tokmen
> http://ali.tokmen.com/
>
> My IM, GSM, PGP and other contact details
> are on http://contact.ali.tokmen.com
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/ 


Re: Maven2/Maven3 plugin development: Ensuring only the available parameters are allowed

2014-01-14 Thread Baptiste Mathus
Hi,
Stephen already answered along those lines. What are you missing?
Cheers


2014/1/9 S. Ali Tokmen 

> Hi Anders
>
> Thanks for your reply - and happy new year :)
>
> Is there any way I can inject / read the whole plugin configuration from
> the plugin?
>
> Best regards
>
> S. Ali Tokmen
> http://ali.tokmen.com/
>
> My IM, GSM, PGP and other contact details
> are on http://contact.ali.tokmen.com
>
> On 08/01/14 20:00, Anders Hammar wrote:
> > AFAIK there is no support for this. If you think there should be, please
> > file a ticket [1].
> >
> > /Anders
> >
> > [1] http://jira.codehaus.org/browse/MNG/
> >
> >
> > On Tue, Jan 7, 2014 at 7:38 PM, S. Ali Tokmen  >wrote:
> >
> >> Dear Maven users
> >>
> >> I am one of the owners of Codehaus CARGO, which has a Maven2/Maven3
> >> plugin; and would have a question with regards to how parameters are
> >> managed.
> >>
> >> We defined our MOJOs with parameters (you can see
> >>
> >>
> http://svn.codehaus.org/cargo/extensions/trunk/maven2/plugin/src/main/java/org/codehaus/cargo/maven2/AbstractCargoMojo.java
> >> for example), but what happens is that if a user unwillingly puts a
> >> parameter in the wrong place then the plugin execution doesn't stop.
> >>
> >> As an example, I can write the below POM and build still works (even
> >> thought the MOJO has no parameter called "foo"):
> >>
> >>   
> >> org.codehaus.cargo
> >> cargo-maven2-plugin
> >> 1.4.6
> >> 
> >>   
> >> bar
> >>   
> >> 
> >>   
> >>
> >> Is there any way I can instruct by MOJO to fail if there is an unknown
> >> parameter?
> >>
> >> Please advise
> >>
> >> Thank you
> >>
> >> --
> >>
> >> S. Ali Tokmen
> >> http://ali.tokmen.com/
> >>
> >> My IM, GSM, PGP and other contact details
> >> are on http://contact.ali.tokmen.com
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> >> For additional commands, e-mail: users-h...@maven.apache.org
> >>
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! 
>


Re: During plugin development, what is the context classloader set to?

2014-01-14 Thread Baptiste Mathus
Hi,
ClassWorlds is your friend if you need to do classloader fine-tuning.

For example (taken in an old poc, so this should be adapted to use
annotations etc.), something along the following would create a classpath
with test scope elements.

...
public class SomeMojo extends AbstractMojo
{
/**
 * @parameter expression="${project.testClasspathElements}"
 */
private
List
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/String.html>>
 testProjectArtifacts;
...
protected
ClassLoader
 getClassLoader()
{
try
{
ClassWorld world = new ClassWorld();
ClassRealm realm = world.newRealm("project");
for
(String
artifact
: testProjectArtifacts)
{
getLog().debug("Constituent : " + artifact);
realm.addConstituent(new
File
(artifact).toURL());
}
return realm.getClassLoader();
}
catch
(Exception
 e)
{
throw new
RuntimeException
("WTF", e);
}
}

HTH


2014/1/8 Laird Nelson 

> I have a plugin that I'm writing that needs to do two things during the
> course of its execution:
> Load a resource from the current project's classpath
> Load a resource from its own guts
>
> This is a fallback kind of thing: if the plugin can't find anything
> appropriate on the project classpath, then and only then do I want it to
> examine its own .jar file for the resource in question.
>
> My hunch is that there are probably already two classloaders set up for
> just this purpose.
>
> I am guessing (haven't tried yet) that the project classpath is probably
> visible to Thread.currentThread().getContextClassLoader().  Is that right?
>
> I'm also guessing (haven't tried yet) that from within my mojo
> this.getClass().getClassLoader() will return me a ClassLoader that is set
> up to be able to see my mojo's innards.  Is that right?
>
> Best,
> Laird
>
> --
> http://about.me/lairdnelson
>
> --
> Baptiste  MATHUS - http://batmat.net
> Sauvez un arbre,
> Mangez un castor ! nbsp;! 


RE: How to include @inheritDoc from a dependent jar

2014-01-14 Thread Mikael Petterson
Hi,

New try :-)

I have the following:

Interface in dependency jar javadoc:

/**
 * Deletes the object found at the specified location.
 * 
 * @param Object any type of object
 * @throws InvalidObjectException lots of text
 * @throws NoSuchObjectException lots of text
 */
public void delete (Object object)throws throws InvalidObjectException, 
NoSuchObjectException;

Implementing class:

/**
 * {@inheritDoc}
 */
@Override
public void delete(Object object) throws InvalidObjectException, 
NoSuchObjectException {
//implementation of delete
}

Is this correct or?   Since this will not produce any javadoc for 
implementation of delete ( last code).


Br.

//mike

-Original Message-
From: Martin Gainty [mailto:mgai...@hotmail.com] 
Sent: den 14 januari 2014 13:27
To: users@maven.apache.org
Subject: RE: How to include @inheritDoc from a dependent jar

  


> From: mikael.petter...@ericsson.com
> To: users@maven.apache.org
> Subject: How to include @inheritDoc from a dependent jar
> Date: Tue, 14 Jan 2014 12:14:21 +
> 
> Hi,
> 
> We are building a maven site that will contain javadoc for our AppX api ( jar 
> file).
> AppX depends on a few other jar files ( that we have built using maven) . One 
> dependency jar contain an interface with javadoc and we have a class 
> implementing it, in AppX.
> AppX has @inheritDoc in in the javadoc so we don't have to rewrite it.
> 
> When I use the following under 
> 
> 
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.8.1
> 
> 
> But when I open up the javadoc for my Appx and look at the class implementing 
> the interface there is no javadoc. What am I missing?

MG>@Inheritdoc pulls Javadoc comments @comment @author @param @throws 
MG>@return from Implemented interface If you have none of the Javadoc 
MG>tags in the corresponding base method of implemented interface then 
MG>AppX class will not be able to 'inherit' those Javadoc attributes
 
> Br,
> 
> //mike
"The longest journey is the the journey inwards..Of him who has chosen his 
dentiny..Who has started upon his quest for the source of his being" Dag 
Hammarskjold
  

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



Re: New logo?

2014-01-14 Thread Stephen Connolly
maven-21 in context:
http://people.apache.org/~stephenc/maven-logo-contest/maven-21-in-context.png


On 14 January 2014 12:18, Stephen Connolly
wrote:

> I thought a hand-drawn font using straight lines only might look good with
> the teepee
>
> maven-21:
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-21.png?version=1&modificationDate=1389701827196&api=v2
>
>
> On 14 January 2014 12:08, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> Putting maven-20 in context, you get:
>>
>>
>> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png
>>
>>
>> On 14 January 2014 10:37, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> My wife had a suggestion... why not make the M in maven out of two tee
>>> pees... linking in with the Apache theme...
>>>
>>> So I present
>>>
>>> maven-19:
>>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1&modificationDate=1389695638903&api=v2
>>>
>>> and finding a use for the feather
>>>
>>> maven-20:
>>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1&modificationDate=1389695654233&api=v2
>>>
>>>
>>> On 14 January 2014 10:35, Stephen Connolly <
>>> stephen.alan.conno...@gmail.com> wrote:
>>>
 As a homage to Roy's wife, may I present

 maven-18:
 https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1&modificationDate=1389695623134&api=v2


 On 13 January 2014 15:36, Lyons, Roy  wrote:

> I asked my wife on the drive to the train today what animal she thinks
> fits Maven.  Her response made me chuckle.
>
> Without hesitation, she said "Honey Badger"
>
> When I asked why, she said that Honey Badgers are part of nature and
> generally do their thing nicely -- but if you piss it off, things will
> get
> really really bad...  She said she had the same experience with Maven.
>  It
> works nicely, but if you try to do something really non-standard, you
> will
> feel its wrath :)
>
> Heh.
>
> Anyhow, I thought it was funny enough to share - not really a serious
> consideration to make a Honey Badger our mascot.
>
> On 1/10/14 1:20 AM, "Kristian Rosenvold"  >
> wrote:
>
> >I think the association-work around what maven /is/ is a great way to
> >approach a logo contest elsewhere. I have worked with some great
> graphic
> >designers in my time, and the kind input the good ones want are
> typically
> >related around your thoughts/feelings around the product rather than
> which
> >particular animal you prefer, which is a bit of a secondary kind of
> input
> >along with all different kinds of other constraints/ideas (the boss
> >prefers
> >blue).
> >
> >When I first encountered maven I had come to the realization that all
> my
> >ant projects were basically the same, and that there was no reason for
> >customizing
> >what was basically a standard process. So maven gives me associations
> to a
> >mass-production line at a factory, rather than a tailor making
> individual
> >processes. Furthermore, the lifecycle amplifies the idea of a
> >conveyor-belt
> >mass-production line; all parts move through the same conveyor belt
> >process, stopping at
> >individual stages to get work done. I would almost be willing to
> think of
> >a
> >waterfall (Uh-oh...)
> >
> >So it would appear to me that I'm not thinking of an animal at all !
> >
> >Kristian
> >
> >
> >
> >
> >
> >
> >
> >2014/1/9 Mark H. Wood 
> >
> >> On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote:
> >> > All of the logos are OK, but none of them really symbolize
> anything in
> >> > particular about Maven. IMO the best logos encapsulate the
> purpose of
> >>the
> >> > project somehow, either overtly, covertly or both.
> >>
> >> Good point.  I was associating with the name "Maven", looking for a
> >> symbol of in-depth understanding of a specialized field.
> >>
> >> http://en.wiktionary.org/wiki/maven
> >>
> >> So, what does Maven do?  It passes unique source and object code
> >> inputs through a standardized process, guided by an expression of
> the
> >> relationships among those inputs, to assemble a well-specified
> >> configuration of runnable code.  What does that look like?
> >>
> >> --
> >> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
> >> Machines should not be friendly.  Machines should be obedient.
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

>>>
>>

Re: New logo?

2014-01-14 Thread Stephen Connolly
I think we would have no issue getting a small amount of funding from the
foundation to feed an external logo competition... but I think we would
want to have some scope defined for such a competition... so yeah I see no
issue with using the top 3 as seed for an external logo competition, e.g.
on the site already mentioned on a previous thread... but I think we do
need a spec and part of the point of this discussion is to generate such a
spec.


On 14 January 2014 12:45, Adam Retter  wrote:

> Does the Apache Foundation of any of its members have any money to
> engage a graphical designer? I was just thinking that after the
> voting, you could get a designer to do a proper job on the logo
> (perhaps producing some variations of the voted on design which could
> again be voted on further?). I do not mean any offence to everyone
> that submitted designs, but clearly we are not professional artists
> ;-)
>
> On 14 January 2014 12:40, Stephen Connolly
>  wrote:
> > We are "Apache Maven" so there is always going to be that temptation to
> > abuse the "Apache" link...
> >
> > I would like to hear more about your objections.
> >
> > Keep in mind that ultimately it will come down to a vote...
> >
> > I'm thinking we have two rounds of voting... the first round to select
> the
> > top 3 and the second round to select the winner...
> >
> > WIth the above scheme I would plan on having a healthy discussion of the
> > top 3 candidates in case any are deemed inappropriate, i.e. the PMC will
> > reserve the right to veto any that it deems inappropriate, substituting
> > with the next most popular.
> >
> > Then the winner will be an open vote from the 3 finalists...
> >
> > Or at least that is my plan
> >
> > So far we have about 8 ideas...
> >
> > * The moose with the internet in his hand
> >
> > * The owl
> >
> > * The assembly line
> >
> > * The honey badger
> >
> > * The two yurts in a native american style
> >
> > * The twin peaks
> >
> > * The fedora as an M (likely too close to redhat... so not counting for
> now)
> >
> > * A simple lettering with a monochrome feather
> >
> > * A stylized lettering with the feather as a y
> >
> > If we get to about 15-20 ideas and/or there seems to be a stop to the
> flow
> > of new ideas, then I will probably call the first round of voting...
> >
> >
> >
> > On 14 January 2014 12:19, Tim Pizey  wrote:
> >
> >> That looks really nice (though I do have problems with any North
> >> American Indian references).
> >>
> >> cheers
> >> TimP
> >>
> >> On 14 January 2014 12:08, Stephen Connolly
> >>  wrote:
> >> > Putting maven-20 in context, you get:
> >> >
> >> >
> >>
> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png
> >> >
> >> >
> >> > On 14 January 2014 10:37, Stephen Connolly
> >> > wrote:
> >> >
> >> >> My wife had a suggestion... why not make the M in maven out of two
> tee
> >> >> pees... linking in with the Apache theme...
> >> >>
> >> >> So I present
> >> >>
> >> >> maven-19:
> >> >>
> >>
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1&modificationDate=1389695638903&api=v2
> >> >>
> >> >> and finding a use for the feather
> >> >>
> >> >> maven-20:
> >> >>
> >>
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1&modificationDate=1389695654233&api=v2
> >> >>
> >> >>
> >> >> On 14 January 2014 10:35, Stephen Connolly <
> >> >> stephen.alan.conno...@gmail.com> wrote:
> >> >>
> >> >>> As a homage to Roy's wife, may I present
> >> >>>
> >> >>> maven-18:
> >> >>>
> >>
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1&modificationDate=1389695623134&api=v2
> >> >>>
> >> >>>
> >> >>> On 13 January 2014 15:36, Lyons, Roy 
> wrote:
> >> >>>
> >>  I asked my wife on the drive to the train today what animal she
> thinks
> >>  fits Maven.  Her response made me chuckle.
> >> 
> >>  Without hesitation, she said "Honey Badger"
> >> 
> >>  When I asked why, she said that Honey Badgers are part of nature
> and
> >>  generally do their thing nicely -- but if you piss it off, things
> will
> >>  get
> >>  really really bad...  She said she had the same experience with
> Maven.
> >>   It
> >>  works nicely, but if you try to do something really non-standard,
> you
> >>  will
> >>  feel its wrath :)
> >> 
> >>  Heh.
> >> 
> >>  Anyhow, I thought it was funny enough to share - not really a
> serious
> >>  consideration to make a Honey Badger our mascot.
> >> 
> >>  On 1/10/14 1:20 AM, "Kristian Rosenvold" <
> >> kristian.rosenv...@gmail.com>
> >>  wrote:
> >> 
> >>  >I think the association-work around what maven /is/ is a great
> way to
> >>  >approach a logo contest elsewhere. I have worked with some great
> >> graphic
> >>  >designers in my time, and the kind input the good ones want are
> >>  typically
> >>  >related around your thoughts/feeli

RE: How to include @inheritDoc from a dependent jar

2014-01-14 Thread Mikael Petterson
Thanks for reply Martin. See my comments below.

Br,

//mike

-Original Message-
From: Martin Gainty [mailto:mgai...@hotmail.com] 
Sent: den 14 januari 2014 13:27
To: users@maven.apache.org
Subject: RE: How to include @inheritDoc from a dependent jar

  


> From: mikael.petter...@ericsson.com
> To: users@maven.apache.org
> Subject: How to include @inheritDoc from a dependent jar
> Date: Tue, 14 Jan 2014 12:14:21 +
> 
> Hi,
> 
> We are building a maven site that will contain javadoc for our AppX api ( jar 
> file).
> AppX depends on a few other jar files ( that we have built using maven) . One 
> dependency jar contain an interface with javadoc and we have a class 
> implementing it, in AppX.
> AppX has @inheritDoc in in the javadoc so we don't have to rewrite it.
> 
> When I use the following under 
> 
> 
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.8.1
> 
> 
> But when I open up the javadoc for my Appx and look at the class implementing 
> the interface there is no javadoc. What am I missing?

MG>@Inheritdoc pulls Javadoc comments @comment @author @param @throws 
MG>@return from Implemented interface If you have none of the Javadoc 
MG>tags in the corresponding base method of implemented interface then 
MG>AppX class will not be able to 'inherit' those Javadoc attributes

I have the following:

Interface in dependency jar javadoc:

/**
 * Deletes the object found at the specified location.
 * 
 * @param Object any type of object
 * @throws InvalidObjectException lots of text
 * @throws NoSuchObjectException lots of text
 */
public void delete (Object object)throws throws InvalidObjectException, 
NoSuchObjectException;

Implementing class:

/**
 * {@inheritDoc}
 */
@Override
public void delete(Object object) throws InvalidObjectException, 
NoSuchObjectException {
//implementation of delete
}

Is this correct or?   Since this will not produce any javadoc for 
implementation of delete ( last code).


 
> Br,
> 
> //mike
"The longest journey is the the journey inwards..Of him who has chosen his 
dentiny..Who has started upon his quest for the source of his being" Dag 
Hammarskjold
  

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



Re: New logo?

2014-01-14 Thread Adam Retter
Does the Apache Foundation of any of its members have any money to
engage a graphical designer? I was just thinking that after the
voting, you could get a designer to do a proper job on the logo
(perhaps producing some variations of the voted on design which could
again be voted on further?). I do not mean any offence to everyone
that submitted designs, but clearly we are not professional artists
;-)

On 14 January 2014 12:40, Stephen Connolly
 wrote:
> We are "Apache Maven" so there is always going to be that temptation to
> abuse the "Apache" link...
>
> I would like to hear more about your objections.
>
> Keep in mind that ultimately it will come down to a vote...
>
> I'm thinking we have two rounds of voting... the first round to select the
> top 3 and the second round to select the winner...
>
> WIth the above scheme I would plan on having a healthy discussion of the
> top 3 candidates in case any are deemed inappropriate, i.e. the PMC will
> reserve the right to veto any that it deems inappropriate, substituting
> with the next most popular.
>
> Then the winner will be an open vote from the 3 finalists...
>
> Or at least that is my plan
>
> So far we have about 8 ideas...
>
> * The moose with the internet in his hand
>
> * The owl
>
> * The assembly line
>
> * The honey badger
>
> * The two yurts in a native american style
>
> * The twin peaks
>
> * The fedora as an M (likely too close to redhat... so not counting for now)
>
> * A simple lettering with a monochrome feather
>
> * A stylized lettering with the feather as a y
>
> If we get to about 15-20 ideas and/or there seems to be a stop to the flow
> of new ideas, then I will probably call the first round of voting...
>
>
>
> On 14 January 2014 12:19, Tim Pizey  wrote:
>
>> That looks really nice (though I do have problems with any North
>> American Indian references).
>>
>> cheers
>> TimP
>>
>> On 14 January 2014 12:08, Stephen Connolly
>>  wrote:
>> > Putting maven-20 in context, you get:
>> >
>> >
>> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png
>> >
>> >
>> > On 14 January 2014 10:37, Stephen Connolly
>> > wrote:
>> >
>> >> My wife had a suggestion... why not make the M in maven out of two tee
>> >> pees... linking in with the Apache theme...
>> >>
>> >> So I present
>> >>
>> >> maven-19:
>> >>
>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1&modificationDate=1389695638903&api=v2
>> >>
>> >> and finding a use for the feather
>> >>
>> >> maven-20:
>> >>
>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1&modificationDate=1389695654233&api=v2
>> >>
>> >>
>> >> On 14 January 2014 10:35, Stephen Connolly <
>> >> stephen.alan.conno...@gmail.com> wrote:
>> >>
>> >>> As a homage to Roy's wife, may I present
>> >>>
>> >>> maven-18:
>> >>>
>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1&modificationDate=1389695623134&api=v2
>> >>>
>> >>>
>> >>> On 13 January 2014 15:36, Lyons, Roy  wrote:
>> >>>
>>  I asked my wife on the drive to the train today what animal she thinks
>>  fits Maven.  Her response made me chuckle.
>> 
>>  Without hesitation, she said "Honey Badger"
>> 
>>  When I asked why, she said that Honey Badgers are part of nature and
>>  generally do their thing nicely -- but if you piss it off, things will
>>  get
>>  really really bad...  She said she had the same experience with Maven.
>>   It
>>  works nicely, but if you try to do something really non-standard, you
>>  will
>>  feel its wrath :)
>> 
>>  Heh.
>> 
>>  Anyhow, I thought it was funny enough to share - not really a serious
>>  consideration to make a Honey Badger our mascot.
>> 
>>  On 1/10/14 1:20 AM, "Kristian Rosenvold" <
>> kristian.rosenv...@gmail.com>
>>  wrote:
>> 
>>  >I think the association-work around what maven /is/ is a great way to
>>  >approach a logo contest elsewhere. I have worked with some great
>> graphic
>>  >designers in my time, and the kind input the good ones want are
>>  typically
>>  >related around your thoughts/feelings around the product rather than
>>  which
>>  >particular animal you prefer, which is a bit of a secondary kind of
>>  input
>>  >along with all different kinds of other constraints/ideas (the boss
>>  >prefers
>>  >blue).
>>  >
>>  >When I first encountered maven I had come to the realization that
>> all my
>>  >ant projects were basically the same, and that there was no reason
>> for
>>  >customizing
>>  >what was basically a standard process. So maven gives me associations
>>  to a
>>  >mass-production line at a factory, rather than a tailor making
>>  individual
>>  >processes. Furthermore, the lifecycle amplifies the idea of a
>>  >conveyor-belt
>>  >mass-production line; all parts move through the same

Re: New logo?

2014-01-14 Thread Kristian Rosenvold
How about just using all of this + textual ideas as input for an external
logo competiton ?

Kristian


2014/1/14 Stephen Connolly 

> We are "Apache Maven" so there is always going to be that temptation to
> abuse the "Apache" link...
>
> I would like to hear more about your objections.
>
> Keep in mind that ultimately it will come down to a vote...
>
> I'm thinking we have two rounds of voting... the first round to select the
> top 3 and the second round to select the winner...
>
> WIth the above scheme I would plan on having a healthy discussion of the
> top 3 candidates in case any are deemed inappropriate, i.e. the PMC will
> reserve the right to veto any that it deems inappropriate, substituting
> with the next most popular.
>
> Then the winner will be an open vote from the 3 finalists...
>
> Or at least that is my plan
>
> So far we have about 8 ideas...
>
> * The moose with the internet in his hand
>
> * The owl
>
> * The assembly line
>
> * The honey badger
>
> * The two yurts in a native american style
>
> * The twin peaks
>
> * The fedora as an M (likely too close to redhat... so not counting for
> now)
>
> * A simple lettering with a monochrome feather
>
> * A stylized lettering with the feather as a y
>
> If we get to about 15-20 ideas and/or there seems to be a stop to the flow
> of new ideas, then I will probably call the first round of voting...
>
>
>
> On 14 January 2014 12:19, Tim Pizey  wrote:
>
> > That looks really nice (though I do have problems with any North
> > American Indian references).
> >
> > cheers
> > TimP
> >
> > On 14 January 2014 12:08, Stephen Connolly
> >  wrote:
> > > Putting maven-20 in context, you get:
> > >
> > >
> >
> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png
> > >
> > >
> > > On 14 January 2014 10:37, Stephen Connolly
> > > wrote:
> > >
> > >> My wife had a suggestion... why not make the M in maven out of two tee
> > >> pees... linking in with the Apache theme...
> > >>
> > >> So I present
> > >>
> > >> maven-19:
> > >>
> >
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1&modificationDate=1389695638903&api=v2
> > >>
> > >> and finding a use for the feather
> > >>
> > >> maven-20:
> > >>
> >
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1&modificationDate=1389695654233&api=v2
> > >>
> > >>
> > >> On 14 January 2014 10:35, Stephen Connolly <
> > >> stephen.alan.conno...@gmail.com> wrote:
> > >>
> > >>> As a homage to Roy's wife, may I present
> > >>>
> > >>> maven-18:
> > >>>
> >
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1&modificationDate=1389695623134&api=v2
> > >>>
> > >>>
> > >>> On 13 January 2014 15:36, Lyons, Roy  wrote:
> > >>>
> >  I asked my wife on the drive to the train today what animal she
> thinks
> >  fits Maven.  Her response made me chuckle.
> > 
> >  Without hesitation, she said "Honey Badger"
> > 
> >  When I asked why, she said that Honey Badgers are part of nature and
> >  generally do their thing nicely -- but if you piss it off, things
> will
> >  get
> >  really really bad...  She said she had the same experience with
> Maven.
> >   It
> >  works nicely, but if you try to do something really non-standard,
> you
> >  will
> >  feel its wrath :)
> > 
> >  Heh.
> > 
> >  Anyhow, I thought it was funny enough to share - not really a
> serious
> >  consideration to make a Honey Badger our mascot.
> > 
> >  On 1/10/14 1:20 AM, "Kristian Rosenvold" <
> > kristian.rosenv...@gmail.com>
> >  wrote:
> > 
> >  >I think the association-work around what maven /is/ is a great way
> to
> >  >approach a logo contest elsewhere. I have worked with some great
> > graphic
> >  >designers in my time, and the kind input the good ones want are
> >  typically
> >  >related around your thoughts/feelings around the product rather
> than
> >  which
> >  >particular animal you prefer, which is a bit of a secondary kind of
> >  input
> >  >along with all different kinds of other constraints/ideas (the boss
> >  >prefers
> >  >blue).
> >  >
> >  >When I first encountered maven I had come to the realization that
> > all my
> >  >ant projects were basically the same, and that there was no reason
> > for
> >  >customizing
> >  >what was basically a standard process. So maven gives me
> associations
> >  to a
> >  >mass-production line at a factory, rather than a tailor making
> >  individual
> >  >processes. Furthermore, the lifecycle amplifies the idea of a
> >  >conveyor-belt
> >  >mass-production line; all parts move through the same conveyor belt
> >  >process, stopping at
> >  >individual stages to get work done. I would almost be willing to
> > think
> >  of
> >  >a
> >  >waterfall (Uh-oh...)
> >  >
> > >>>

Re: New logo?

2014-01-14 Thread Stephen Connolly
We are "Apache Maven" so there is always going to be that temptation to
abuse the "Apache" link...

I would like to hear more about your objections.

Keep in mind that ultimately it will come down to a vote...

I'm thinking we have two rounds of voting... the first round to select the
top 3 and the second round to select the winner...

WIth the above scheme I would plan on having a healthy discussion of the
top 3 candidates in case any are deemed inappropriate, i.e. the PMC will
reserve the right to veto any that it deems inappropriate, substituting
with the next most popular.

Then the winner will be an open vote from the 3 finalists...

Or at least that is my plan

So far we have about 8 ideas...

* The moose with the internet in his hand

* The owl

* The assembly line

* The honey badger

* The two yurts in a native american style

* The twin peaks

* The fedora as an M (likely too close to redhat... so not counting for now)

* A simple lettering with a monochrome feather

* A stylized lettering with the feather as a y

If we get to about 15-20 ideas and/or there seems to be a stop to the flow
of new ideas, then I will probably call the first round of voting...



On 14 January 2014 12:19, Tim Pizey  wrote:

> That looks really nice (though I do have problems with any North
> American Indian references).
>
> cheers
> TimP
>
> On 14 January 2014 12:08, Stephen Connolly
>  wrote:
> > Putting maven-20 in context, you get:
> >
> >
> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png
> >
> >
> > On 14 January 2014 10:37, Stephen Connolly
> > wrote:
> >
> >> My wife had a suggestion... why not make the M in maven out of two tee
> >> pees... linking in with the Apache theme...
> >>
> >> So I present
> >>
> >> maven-19:
> >>
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1&modificationDate=1389695638903&api=v2
> >>
> >> and finding a use for the feather
> >>
> >> maven-20:
> >>
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1&modificationDate=1389695654233&api=v2
> >>
> >>
> >> On 14 January 2014 10:35, Stephen Connolly <
> >> stephen.alan.conno...@gmail.com> wrote:
> >>
> >>> As a homage to Roy's wife, may I present
> >>>
> >>> maven-18:
> >>>
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1&modificationDate=1389695623134&api=v2
> >>>
> >>>
> >>> On 13 January 2014 15:36, Lyons, Roy  wrote:
> >>>
>  I asked my wife on the drive to the train today what animal she thinks
>  fits Maven.  Her response made me chuckle.
> 
>  Without hesitation, she said "Honey Badger"
> 
>  When I asked why, she said that Honey Badgers are part of nature and
>  generally do their thing nicely -- but if you piss it off, things will
>  get
>  really really bad...  She said she had the same experience with Maven.
>   It
>  works nicely, but if you try to do something really non-standard, you
>  will
>  feel its wrath :)
> 
>  Heh.
> 
>  Anyhow, I thought it was funny enough to share - not really a serious
>  consideration to make a Honey Badger our mascot.
> 
>  On 1/10/14 1:20 AM, "Kristian Rosenvold" <
> kristian.rosenv...@gmail.com>
>  wrote:
> 
>  >I think the association-work around what maven /is/ is a great way to
>  >approach a logo contest elsewhere. I have worked with some great
> graphic
>  >designers in my time, and the kind input the good ones want are
>  typically
>  >related around your thoughts/feelings around the product rather than
>  which
>  >particular animal you prefer, which is a bit of a secondary kind of
>  input
>  >along with all different kinds of other constraints/ideas (the boss
>  >prefers
>  >blue).
>  >
>  >When I first encountered maven I had come to the realization that
> all my
>  >ant projects were basically the same, and that there was no reason
> for
>  >customizing
>  >what was basically a standard process. So maven gives me associations
>  to a
>  >mass-production line at a factory, rather than a tailor making
>  individual
>  >processes. Furthermore, the lifecycle amplifies the idea of a
>  >conveyor-belt
>  >mass-production line; all parts move through the same conveyor belt
>  >process, stopping at
>  >individual stages to get work done. I would almost be willing to
> think
>  of
>  >a
>  >waterfall (Uh-oh...)
>  >
>  >So it would appear to me that I'm not thinking of an animal at all !
>  >
>  >Kristian
>  >
>  >
>  >
>  >
>  >
>  >
>  >
>  >2014/1/9 Mark H. Wood 
>  >
>  >> On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote:
>  >> > All of the logos are OK, but none of them really symbolize
> anything
>  in
>  >> > particular about Maven. IMO the best logos encapsulate

RE: How to include @inheritDoc from a dependent jar

2014-01-14 Thread Martin Gainty
  


> From: mikael.petter...@ericsson.com
> To: users@maven.apache.org
> Subject: How to include @inheritDoc from a dependent jar
> Date: Tue, 14 Jan 2014 12:14:21 +
> 
> Hi,
> 
> We are building a maven site that will contain javadoc for our AppX api ( jar 
> file).
> AppX depends on a few other jar files ( that we have built using maven) . One 
> dependency jar contain an interface with javadoc and we have a class 
> implementing it, in AppX.
> AppX has @inheritDoc in in the javadoc so we don't have to rewrite it.
> 
> When I use the following under 
> 
> 
> org.apache.maven.plugins
> maven-javadoc-plugin
> 2.8.1
> 
> 
> But when I open up the javadoc for my Appx and look at the class implementing 
> the interface there is no javadoc. What am I missing?

MG>@Inheritdoc pulls Javadoc comments @comment @author @param @throws @return 
from Implemented interface
MG>If you have none of the Javadoc tags in the corresponding base method of 
implemented interface 
MG>then AppX class will not be able to 'inherit' those Javadoc attributes
 
> Br,
> 
> //mike
"The longest journey is the the journey inwards..Of him who has chosen his 
dentiny..Who has started upon his quest for the source of his being" Dag 
Hammarskjold
  

Re: New logo?

2014-01-14 Thread Tim Pizey
That looks really nice (though I do have problems with any North
American Indian references).

cheers
TimP

On 14 January 2014 12:08, Stephen Connolly
 wrote:
> Putting maven-20 in context, you get:
>
> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png
>
>
> On 14 January 2014 10:37, Stephen Connolly
> wrote:
>
>> My wife had a suggestion... why not make the M in maven out of two tee
>> pees... linking in with the Apache theme...
>>
>> So I present
>>
>> maven-19:
>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1&modificationDate=1389695638903&api=v2
>>
>> and finding a use for the feather
>>
>> maven-20:
>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1&modificationDate=1389695654233&api=v2
>>
>>
>> On 14 January 2014 10:35, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> As a homage to Roy's wife, may I present
>>>
>>> maven-18:
>>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1&modificationDate=1389695623134&api=v2
>>>
>>>
>>> On 13 January 2014 15:36, Lyons, Roy  wrote:
>>>
 I asked my wife on the drive to the train today what animal she thinks
 fits Maven.  Her response made me chuckle.

 Without hesitation, she said "Honey Badger"

 When I asked why, she said that Honey Badgers are part of nature and
 generally do their thing nicely -- but if you piss it off, things will
 get
 really really bad...  She said she had the same experience with Maven.
  It
 works nicely, but if you try to do something really non-standard, you
 will
 feel its wrath :)

 Heh.

 Anyhow, I thought it was funny enough to share - not really a serious
 consideration to make a Honey Badger our mascot.

 On 1/10/14 1:20 AM, "Kristian Rosenvold" 
 wrote:

 >I think the association-work around what maven /is/ is a great way to
 >approach a logo contest elsewhere. I have worked with some great graphic
 >designers in my time, and the kind input the good ones want are
 typically
 >related around your thoughts/feelings around the product rather than
 which
 >particular animal you prefer, which is a bit of a secondary kind of
 input
 >along with all different kinds of other constraints/ideas (the boss
 >prefers
 >blue).
 >
 >When I first encountered maven I had come to the realization that all my
 >ant projects were basically the same, and that there was no reason for
 >customizing
 >what was basically a standard process. So maven gives me associations
 to a
 >mass-production line at a factory, rather than a tailor making
 individual
 >processes. Furthermore, the lifecycle amplifies the idea of a
 >conveyor-belt
 >mass-production line; all parts move through the same conveyor belt
 >process, stopping at
 >individual stages to get work done. I would almost be willing to think
 of
 >a
 >waterfall (Uh-oh...)
 >
 >So it would appear to me that I'm not thinking of an animal at all !
 >
 >Kristian
 >
 >
 >
 >
 >
 >
 >
 >2014/1/9 Mark H. Wood 
 >
 >> On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote:
 >> > All of the logos are OK, but none of them really symbolize anything
 in
 >> > particular about Maven. IMO the best logos encapsulate the purpose
 of
 >>the
 >> > project somehow, either overtly, covertly or both.
 >>
 >> Good point.  I was associating with the name "Maven", looking for a
 >> symbol of in-depth understanding of a specialized field.
 >>
 >> http://en.wiktionary.org/wiki/maven
 >>
 >> So, what does Maven do?  It passes unique source and object code
 >> inputs through a standardized process, guided by an expression of the
 >> relationships among those inputs, to assemble a well-specified
 >> configuration of runnable code.  What does that look like?
 >>
 >> --
 >> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
 >> Machines should not be friendly.  Machines should be obedient.
 >>


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


>>>
>>



-- 
Tim Pizey
http://pizey.net/~timp

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



Re: New logo?

2014-01-14 Thread Stephen Connolly
I thought a hand-drawn font using straight lines only might look good with
the teepee

maven-21:
https://cwiki.apache.org/confluence/download/attachments/38569278/maven-21.png?version=1&modificationDate=1389701827196&api=v2


On 14 January 2014 12:08, Stephen Connolly
wrote:

> Putting maven-20 in context, you get:
>
>
> http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png
>
>
> On 14 January 2014 10:37, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> My wife had a suggestion... why not make the M in maven out of two tee
>> pees... linking in with the Apache theme...
>>
>> So I present
>>
>> maven-19:
>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1&modificationDate=1389695638903&api=v2
>>
>> and finding a use for the feather
>>
>> maven-20:
>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1&modificationDate=1389695654233&api=v2
>>
>>
>> On 14 January 2014 10:35, Stephen Connolly <
>> stephen.alan.conno...@gmail.com> wrote:
>>
>>> As a homage to Roy's wife, may I present
>>>
>>> maven-18:
>>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1&modificationDate=1389695623134&api=v2
>>>
>>>
>>> On 13 January 2014 15:36, Lyons, Roy  wrote:
>>>
 I asked my wife on the drive to the train today what animal she thinks
 fits Maven.  Her response made me chuckle.

 Without hesitation, she said "Honey Badger"

 When I asked why, she said that Honey Badgers are part of nature and
 generally do their thing nicely -- but if you piss it off, things will
 get
 really really bad...  She said she had the same experience with Maven.
  It
 works nicely, but if you try to do something really non-standard, you
 will
 feel its wrath :)

 Heh.

 Anyhow, I thought it was funny enough to share - not really a serious
 consideration to make a Honey Badger our mascot.

 On 1/10/14 1:20 AM, "Kristian Rosenvold" 
 wrote:

 >I think the association-work around what maven /is/ is a great way to
 >approach a logo contest elsewhere. I have worked with some great
 graphic
 >designers in my time, and the kind input the good ones want are
 typically
 >related around your thoughts/feelings around the product rather than
 which
 >particular animal you prefer, which is a bit of a secondary kind of
 input
 >along with all different kinds of other constraints/ideas (the boss
 >prefers
 >blue).
 >
 >When I first encountered maven I had come to the realization that all
 my
 >ant projects were basically the same, and that there was no reason for
 >customizing
 >what was basically a standard process. So maven gives me associations
 to a
 >mass-production line at a factory, rather than a tailor making
 individual
 >processes. Furthermore, the lifecycle amplifies the idea of a
 >conveyor-belt
 >mass-production line; all parts move through the same conveyor belt
 >process, stopping at
 >individual stages to get work done. I would almost be willing to think
 of
 >a
 >waterfall (Uh-oh...)
 >
 >So it would appear to me that I'm not thinking of an animal at all !
 >
 >Kristian
 >
 >
 >
 >
 >
 >
 >
 >2014/1/9 Mark H. Wood 
 >
 >> On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote:
 >> > All of the logos are OK, but none of them really symbolize
 anything in
 >> > particular about Maven. IMO the best logos encapsulate the purpose
 of
 >>the
 >> > project somehow, either overtly, covertly or both.
 >>
 >> Good point.  I was associating with the name "Maven", looking for a
 >> symbol of in-depth understanding of a specialized field.
 >>
 >> http://en.wiktionary.org/wiki/maven
 >>
 >> So, what does Maven do?  It passes unique source and object code
 >> inputs through a standardized process, guided by an expression of the
 >> relationships among those inputs, to assemble a well-specified
 >> configuration of runnable code.  What does that look like?
 >>
 >> --
 >> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
 >> Machines should not be friendly.  Machines should be obedient.
 >>


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


>>>
>>
>


How to include @inheritDoc from a dependent jar

2014-01-14 Thread Mikael Petterson
Hi,

We are building a maven site that will contain javadoc for our  AppX api ( jar 
file).
AppX depends on a few other jar files ( that we have built using maven) . One 
dependency jar contain an interface with javadoc and we have a class 
implementing it, in AppX.
AppX has @inheritDoc in in the javadoc so we don't have to rewrite it.

When I use the following under 



org.apache.maven.plugins

maven-javadoc-plugin

2.8.1


But when I open up the javadoc for my Appx and look at the class implementing 
the interface there is no javadoc. What am I missing?

Br,

//mike


Re: New logo?

2014-01-14 Thread Stephen Connolly
Putting maven-20 in context, you get:

http://people.apache.org/~stephenc/maven-logo-contest/maven-20-in-context.png


On 14 January 2014 10:37, Stephen Connolly
wrote:

> My wife had a suggestion... why not make the M in maven out of two tee
> pees... linking in with the Apache theme...
>
> So I present
>
> maven-19:
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1&modificationDate=1389695638903&api=v2
>
> and finding a use for the feather
>
> maven-20:
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1&modificationDate=1389695654233&api=v2
>
>
> On 14 January 2014 10:35, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> As a homage to Roy's wife, may I present
>>
>> maven-18:
>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1&modificationDate=1389695623134&api=v2
>>
>>
>> On 13 January 2014 15:36, Lyons, Roy  wrote:
>>
>>> I asked my wife on the drive to the train today what animal she thinks
>>> fits Maven.  Her response made me chuckle.
>>>
>>> Without hesitation, she said "Honey Badger"
>>>
>>> When I asked why, she said that Honey Badgers are part of nature and
>>> generally do their thing nicely -- but if you piss it off, things will
>>> get
>>> really really bad...  She said she had the same experience with Maven.
>>>  It
>>> works nicely, but if you try to do something really non-standard, you
>>> will
>>> feel its wrath :)
>>>
>>> Heh.
>>>
>>> Anyhow, I thought it was funny enough to share - not really a serious
>>> consideration to make a Honey Badger our mascot.
>>>
>>> On 1/10/14 1:20 AM, "Kristian Rosenvold" 
>>> wrote:
>>>
>>> >I think the association-work around what maven /is/ is a great way to
>>> >approach a logo contest elsewhere. I have worked with some great graphic
>>> >designers in my time, and the kind input the good ones want are
>>> typically
>>> >related around your thoughts/feelings around the product rather than
>>> which
>>> >particular animal you prefer, which is a bit of a secondary kind of
>>> input
>>> >along with all different kinds of other constraints/ideas (the boss
>>> >prefers
>>> >blue).
>>> >
>>> >When I first encountered maven I had come to the realization that all my
>>> >ant projects were basically the same, and that there was no reason for
>>> >customizing
>>> >what was basically a standard process. So maven gives me associations
>>> to a
>>> >mass-production line at a factory, rather than a tailor making
>>> individual
>>> >processes. Furthermore, the lifecycle amplifies the idea of a
>>> >conveyor-belt
>>> >mass-production line; all parts move through the same conveyor belt
>>> >process, stopping at
>>> >individual stages to get work done. I would almost be willing to think
>>> of
>>> >a
>>> >waterfall (Uh-oh...)
>>> >
>>> >So it would appear to me that I'm not thinking of an animal at all !
>>> >
>>> >Kristian
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >2014/1/9 Mark H. Wood 
>>> >
>>> >> On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote:
>>> >> > All of the logos are OK, but none of them really symbolize anything
>>> in
>>> >> > particular about Maven. IMO the best logos encapsulate the purpose
>>> of
>>> >>the
>>> >> > project somehow, either overtly, covertly or both.
>>> >>
>>> >> Good point.  I was associating with the name "Maven", looking for a
>>> >> symbol of in-depth understanding of a specialized field.
>>> >>
>>> >> http://en.wiktionary.org/wiki/maven
>>> >>
>>> >> So, what does Maven do?  It passes unique source and object code
>>> >> inputs through a standardized process, guided by an expression of the
>>> >> relationships among those inputs, to assemble a well-specified
>>> >> configuration of runnable code.  What does that look like?
>>> >>
>>> >> --
>>> >> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
>>> >> Machines should not be friendly.  Machines should be obedient.
>>> >>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>


Re: New logo?

2014-01-14 Thread Stephen Connolly
FYI: ndeloof points out http://raven.rubyforge.org/

So I think any logo with a raven in it is well and truly dead in the water


On 14 January 2014 10:37, Stephen Connolly
wrote:

> My wife had a suggestion... why not make the M in maven out of two tee
> pees... linking in with the Apache theme...
>
> So I present
>
> maven-19:
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1&modificationDate=1389695638903&api=v2
>
> and finding a use for the feather
>
> maven-20:
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1&modificationDate=1389695654233&api=v2
>
>
> On 14 January 2014 10:35, Stephen Connolly <
> stephen.alan.conno...@gmail.com> wrote:
>
>> As a homage to Roy's wife, may I present
>>
>> maven-18:
>> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1&modificationDate=1389695623134&api=v2
>>
>>
>> On 13 January 2014 15:36, Lyons, Roy  wrote:
>>
>>> I asked my wife on the drive to the train today what animal she thinks
>>> fits Maven.  Her response made me chuckle.
>>>
>>> Without hesitation, she said "Honey Badger"
>>>
>>> When I asked why, she said that Honey Badgers are part of nature and
>>> generally do their thing nicely -- but if you piss it off, things will
>>> get
>>> really really bad...  She said she had the same experience with Maven.
>>>  It
>>> works nicely, but if you try to do something really non-standard, you
>>> will
>>> feel its wrath :)
>>>
>>> Heh.
>>>
>>> Anyhow, I thought it was funny enough to share - not really a serious
>>> consideration to make a Honey Badger our mascot.
>>>
>>> On 1/10/14 1:20 AM, "Kristian Rosenvold" 
>>> wrote:
>>>
>>> >I think the association-work around what maven /is/ is a great way to
>>> >approach a logo contest elsewhere. I have worked with some great graphic
>>> >designers in my time, and the kind input the good ones want are
>>> typically
>>> >related around your thoughts/feelings around the product rather than
>>> which
>>> >particular animal you prefer, which is a bit of a secondary kind of
>>> input
>>> >along with all different kinds of other constraints/ideas (the boss
>>> >prefers
>>> >blue).
>>> >
>>> >When I first encountered maven I had come to the realization that all my
>>> >ant projects were basically the same, and that there was no reason for
>>> >customizing
>>> >what was basically a standard process. So maven gives me associations
>>> to a
>>> >mass-production line at a factory, rather than a tailor making
>>> individual
>>> >processes. Furthermore, the lifecycle amplifies the idea of a
>>> >conveyor-belt
>>> >mass-production line; all parts move through the same conveyor belt
>>> >process, stopping at
>>> >individual stages to get work done. I would almost be willing to think
>>> of
>>> >a
>>> >waterfall (Uh-oh...)
>>> >
>>> >So it would appear to me that I'm not thinking of an animal at all !
>>> >
>>> >Kristian
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >2014/1/9 Mark H. Wood 
>>> >
>>> >> On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote:
>>> >> > All of the logos are OK, but none of them really symbolize anything
>>> in
>>> >> > particular about Maven. IMO the best logos encapsulate the purpose
>>> of
>>> >>the
>>> >> > project somehow, either overtly, covertly or both.
>>> >>
>>> >> Good point.  I was associating with the name "Maven", looking for a
>>> >> symbol of in-depth understanding of a specialized field.
>>> >>
>>> >> http://en.wiktionary.org/wiki/maven
>>> >>
>>> >> So, what does Maven do?  It passes unique source and object code
>>> >> inputs through a standardized process, guided by an expression of the
>>> >> relationships among those inputs, to assemble a well-specified
>>> >> configuration of runnable code.  What does that look like?
>>> >>
>>> >> --
>>> >> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
>>> >> Machines should not be friendly.  Machines should be obedient.
>>> >>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>>
>>>
>>
>


Re: New logo?

2014-01-14 Thread Stephen Connolly
My wife had a suggestion... why not make the M in maven out of two tee
pees... linking in with the Apache theme...

So I present

maven-19:
https://cwiki.apache.org/confluence/download/attachments/38569278/maven-19.png?version=1&modificationDate=1389695638903&api=v2

and finding a use for the feather

maven-20:
https://cwiki.apache.org/confluence/download/attachments/38569278/maven-20.png?version=1&modificationDate=1389695654233&api=v2


On 14 January 2014 10:35, Stephen Connolly
wrote:

> As a homage to Roy's wife, may I present
>
> maven-18:
> https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1&modificationDate=1389695623134&api=v2
>
>
> On 13 January 2014 15:36, Lyons, Roy  wrote:
>
>> I asked my wife on the drive to the train today what animal she thinks
>> fits Maven.  Her response made me chuckle.
>>
>> Without hesitation, she said "Honey Badger"
>>
>> When I asked why, she said that Honey Badgers are part of nature and
>> generally do their thing nicely -- but if you piss it off, things will get
>> really really bad...  She said she had the same experience with Maven.  It
>> works nicely, but if you try to do something really non-standard, you will
>> feel its wrath :)
>>
>> Heh.
>>
>> Anyhow, I thought it was funny enough to share - not really a serious
>> consideration to make a Honey Badger our mascot.
>>
>> On 1/10/14 1:20 AM, "Kristian Rosenvold" 
>> wrote:
>>
>> >I think the association-work around what maven /is/ is a great way to
>> >approach a logo contest elsewhere. I have worked with some great graphic
>> >designers in my time, and the kind input the good ones want are typically
>> >related around your thoughts/feelings around the product rather than
>> which
>> >particular animal you prefer, which is a bit of a secondary kind of input
>> >along with all different kinds of other constraints/ideas (the boss
>> >prefers
>> >blue).
>> >
>> >When I first encountered maven I had come to the realization that all my
>> >ant projects were basically the same, and that there was no reason for
>> >customizing
>> >what was basically a standard process. So maven gives me associations to
>> a
>> >mass-production line at a factory, rather than a tailor making individual
>> >processes. Furthermore, the lifecycle amplifies the idea of a
>> >conveyor-belt
>> >mass-production line; all parts move through the same conveyor belt
>> >process, stopping at
>> >individual stages to get work done. I would almost be willing to think of
>> >a
>> >waterfall (Uh-oh...)
>> >
>> >So it would appear to me that I'm not thinking of an animal at all !
>> >
>> >Kristian
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >2014/1/9 Mark H. Wood 
>> >
>> >> On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote:
>> >> > All of the logos are OK, but none of them really symbolize anything
>> in
>> >> > particular about Maven. IMO the best logos encapsulate the purpose of
>> >>the
>> >> > project somehow, either overtly, covertly or both.
>> >>
>> >> Good point.  I was associating with the name "Maven", looking for a
>> >> symbol of in-depth understanding of a specialized field.
>> >>
>> >> http://en.wiktionary.org/wiki/maven
>> >>
>> >> So, what does Maven do?  It passes unique source and object code
>> >> inputs through a standardized process, guided by an expression of the
>> >> relationships among those inputs, to assemble a well-specified
>> >> configuration of runnable code.  What does that look like?
>> >>
>> >> --
>> >> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
>> >> Machines should not be friendly.  Machines should be obedient.
>> >>
>>
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>


Re: New logo?

2014-01-14 Thread Stephen Connolly
As a homage to Roy's wife, may I present

maven-18:
https://cwiki.apache.org/confluence/download/attachments/38569278/maven-18.png?version=1&modificationDate=1389695623134&api=v2


On 13 January 2014 15:36, Lyons, Roy  wrote:

> I asked my wife on the drive to the train today what animal she thinks
> fits Maven.  Her response made me chuckle.
>
> Without hesitation, she said "Honey Badger"
>
> When I asked why, she said that Honey Badgers are part of nature and
> generally do their thing nicely -- but if you piss it off, things will get
> really really bad...  She said she had the same experience with Maven.  It
> works nicely, but if you try to do something really non-standard, you will
> feel its wrath :)
>
> Heh.
>
> Anyhow, I thought it was funny enough to share - not really a serious
> consideration to make a Honey Badger our mascot.
>
> On 1/10/14 1:20 AM, "Kristian Rosenvold" 
> wrote:
>
> >I think the association-work around what maven /is/ is a great way to
> >approach a logo contest elsewhere. I have worked with some great graphic
> >designers in my time, and the kind input the good ones want are typically
> >related around your thoughts/feelings around the product rather than which
> >particular animal you prefer, which is a bit of a secondary kind of input
> >along with all different kinds of other constraints/ideas (the boss
> >prefers
> >blue).
> >
> >When I first encountered maven I had come to the realization that all my
> >ant projects were basically the same, and that there was no reason for
> >customizing
> >what was basically a standard process. So maven gives me associations to a
> >mass-production line at a factory, rather than a tailor making individual
> >processes. Furthermore, the lifecycle amplifies the idea of a
> >conveyor-belt
> >mass-production line; all parts move through the same conveyor belt
> >process, stopping at
> >individual stages to get work done. I would almost be willing to think of
> >a
> >waterfall (Uh-oh...)
> >
> >So it would appear to me that I'm not thinking of an animal at all !
> >
> >Kristian
> >
> >
> >
> >
> >
> >
> >
> >2014/1/9 Mark H. Wood 
> >
> >> On Thu, Jan 09, 2014 at 09:32:54AM -0600, Curtis Rueden wrote:
> >> > All of the logos are OK, but none of them really symbolize anything in
> >> > particular about Maven. IMO the best logos encapsulate the purpose of
> >>the
> >> > project somehow, either overtly, covertly or both.
> >>
> >> Good point.  I was associating with the name "Maven", looking for a
> >> symbol of in-depth understanding of a specialized field.
> >>
> >> http://en.wiktionary.org/wiki/maven
> >>
> >> So, what does Maven do?  It passes unique source and object code
> >> inputs through a standardized process, guided by an expression of the
> >> relationships among those inputs, to assemble a well-specified
> >> configuration of runnable code.  What does that look like?
> >>
> >> --
> >> Mark H. Wood, Lead System Programmer   mw...@iupui.edu
> >> Machines should not be friendly.  Machines should be obedient.
> >>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>


Re: Is it possible to deliberately have two dependencies with the same groupid, artifactid, and packaging, but different version?

2014-01-14 Thread Stephen Connolly
I like to consider a G:A as being substitutable along the V access... if
you change the artifact so that it is not substitutable, then you really
need to change the G:A part.

Now substitutable does not mean no breaking API changes... it does mean
that the package name and at least some of the class names are the same.

So a good case in point here is Jackson the JSON serialization library...

There are many versions of Jackson, but when a major breaking change to the
API was required Tatu changed from org.codehaus.jackson:jackson-core-asl to
com.fasterxml.jackson.core:jackson-core and also changed the package name
of the classes.

This was the correct thing to do, IMHO.

They maintained 82 releases of the API without having to refactor in a
breaking way.

The changes that they needed would break the API, leaving no way for
existing code to inter-op

As a result, by changing package name and G:A the two versions can
co-exist...

Now let us consider some other ways that Tatu & Co could have handled this:

* They could have kept the package name the same and changed the G:A. That
would mean that classes in the package name would not be coming from the
same jar file, and so with a security manager enabled the "same jar origin
policy" would mean that at run time you end up getting class conflicts all
over the place as different classloaders resolve the package name from
different jar files depending on which class they reference first and the
order of the jars in the classpath... sounds a lot like hell... let's scrap
that plan

* They could have changed the package name and kept the G:A. That would
mean that any fool* using version ranges could now find that their code
fails to compile. (*only a fool uses version ranges)... that is self
inflicted hell... also dependencyManagement will overrule versions so if
somebody uses a dependencyManagement to force a version that will force a
single version even though the classpath *should* have two versions... plus
how Maven resolves the dependency tree means that it assumes that for any
G:A varying the V gives you substitutable artifacts (and if they don't work
then either `compile` or `test/verify` will fail the build so that's ok)

So the rule of thumb I use is:

* every time you change the package name, change the G:A

* if you are making breaking API changes that are not substitutable, change
the package name


# aside

Is there a use case for dependencies of the same GA but different V?

I think there may be, at least when dealing with non-java resources... and
Java 9 / OSGi provides a use case also.

For example, you may have a legitimate (if crappy) reason to include two
versions of jQuery in your web application... one set of pages may use the
older one during a transition for example.

So in modelVersion 5.0.0, I do think that we should investigate a means of
flagging that certain types of dependency collection require a single
unique version resolved for each GA dependency, while other types of
dependency collection require the set of versions for each GA dependency




On 14 January 2014 00:24, KARR, DAVID  wrote:

> I have a situation where it would be convenient for my pom to have two
> dependencies that are almost identical, only being different by the
> version.  The makeup of the artifact is such that it would be safe (and
> intended) to use both of them.  The Java package used in each is similar,
> but different.  The package will vary along with the version number.
>
> Will dependency resolution and the EAR plugin (and any other mechanism
> that lists dependencies) have any trouble with this?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>