Re: Expected implementation date for Maven MIXIN Feature

[Anders Hammar]

No, it will not.

As you've already seen, adding dependencies through a profile is a very bad
thing to do. You must understand that using Maven isn't just about making
your build work but also making sure that dependency management for those
using (consuming) your artifact works. When you add dependencies in a
profile this most often gets screwed up.

/Anders

On Fri, Apr 15, 2011 at 00:29, Bock, Richard (NSN - DE/Munich) <
richard.b...@nsn.com> wrote:

> Hi Stephen and Martin
>
> Thanks for your constructive contribution :-)
>
> As we implement a framework it is important to leave the user pom files as
> clean as possible to avoid tedious upgrades when we change the
> implementation.
>
> Currently I inject the following stuff using profiles with file exists
> condition:
>
> 1.) dependencies (type compile and provided)
> ...
>
>javax.servlet
>servlet-api
>2.3
>provided
>
>
>
>  com.nsn.see.sce.container.sipservlet
>container-sipservlet-api
>${sceVersion}
>compile
>
> ...
>
> 2.) plugin configuration e.g.
>
> 
>
>
>org.apache.maven.plugins
>maven-war-plugin
>2.1.1
>
>
>  ${project.basedir}/WebContent/WEB-INF/web.xml
>
>
>
>  ${project.basedir}/WebContent/WEB-INF
>
>  WEB-INF
>
>
>  weblogic.xml
>
>  sip.xml
>
>
>  false
>
>
>
>
>
>
>
> 3.) plugin management configurations
>
> 4.) properties
>
> The only negative sideeffect the profile workaround currently has is that
> the dependencies cannot be used transitively as the file marker is not in
> repository. I just wonder if I could replace the dependencies with the
> import feature. Will import also add the provided dependencies?
>
> /Richard
>
>
>
> -Original Message-
> From: ext Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
> Sent: Thursday, April 14, 2011 2:23 PM
> To: Maven Users List
> Cc: Martin Gainty
> Subject: Re: Expected implementation date for Maven MIXIN Feature
>
> http://www.mail-archive.com/dev@maven.apache.org/msg85145.html
>
> On 14 April 2011 13:16, Martin Gainty  wrote:
> >
> > you may want to consider aggregating your plugins into a
> dependency-management block
> > then further down have your poms pull in that dependency-management block
> of plugins with import
> > in the calling poms dependency-management dependency
> >
> >
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
> >
> > if this doesnt suit your need we could provide a better solution if
> > you could provide specifics on what you are attempting to accomplish
> >
> > gruss
> > Martin
> > __
> > Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
> >
> > Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> > Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas
> le destinataire prévu, nous te demandons avec bonté que pour satisfaire
> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
> de ceci est interdite. Ce message sert à l'information seulement et n'aura
> pas n'importe quel effet légalement obligatoire. Étant donné que les email
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
> aucune responsabilité pour le contenu fourni.
> >
> >
> >
> >
> >> Subject: RE: Expected implementation date for Maven MIXIN Feature
> >> Date: Thu, 14 Apr 2011 11:50:06 +0200
> >> From: richard.b...@nsn.com
> >> To: users@maven.apache.org
> >>
> >> Hi Anders,
> >>
> >> Thanks for your clarifications. I try get the wordings right. But what
> >> are you actually suggesting? I mean stay away from profiles. Yeah. But
> >> what to use instead? Modules will not work as I am actually already
> >> using them. I need modules that have an aggregation parent and still get
> >> some model type specific configuration (plugins e.g. that are always
> >> same for a certain module type).
> >>
> >

Re: Mojo: How do I write a plugin to interact with another?

[Anders Hammar]

The build-helper-maven-plugin has the goal reserve-network-port which writes
port numbers to maven properties that can be used within the project. Maybe
that's something to look at?

/Anders

On Thu, Apr 14, 2011 at 21:32, laredotornado-3 wrote:

> Hi,
>
> I'm using Maven 3.0.3.  I want to write a Maven plugin that will ultimately
> output a string (in my case, a version control revision number) that will
> be
> used by another plugin (SCM).  How do I pass the value from one place to
> another?  FYI, I want the value to be used by the scm:checkout task here
> ...
>
>
>org.apache.maven.plugins
>maven-scm-plugin
>1.5
>
>  install
>  username
>  password
>
>  revision
>
>
>
> Could someone point me at an example or let me know how this is done?
> Thanks, - Dave
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Mojo-How-do-I-write-a-plugin-to-interact-with-another-tp4303832p4303832.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Trying to migrate to maven 3.0.3

[Tom Eugelink]

 If you do nothing fancy in your plugins then you should be able to migrate to 
3 without changes to the plugin. 3.0 is mainly a refactoring of the 2 code and 
tries to remain as much backwards compatible as is possible. So no, yes, no.
3 will complain if you did not specify versions in the plugins, so that is 
something to pick up.




On 15-4-2011 04:34, Sony Antony wrote:

We have been using mvn 2.1 for a while and we have understood it fairly
well.
Recently we decided to move to 3.x,( mainly for teh parallel build feature
with the -T switch )

But we find teh documentation difficult to come by. Googling didnt dig up
any tutorial or guides for 3.0 specific features.
Specifically, we have the following fundamental questions. Will be very
grateful if somebody could answer these.

1. I read about the changes for the pom.xml in 3.x. Does that mean that I
should change my poms, even if I m not using any features specific to 3.x. (
Maybe I should change the namespace from http://maven.apache.org/POM/4.0.0 to
something newer ? )
2. When I built a simple project, all of teh plugins that got automatically
downloaded from http://repo1.maven.org looked pretty much like the plugins
used by maven 2.x. Does that mean that most of the plugins and repositories
I would be using will be exactly same as maven 2.x ?
3. Even teh super pom looks teh same in maven 3.x ( verified using
help:effective-pom ). Are we supposed to oevrride any of teh versions in the
superpom for the core plugins, so as to get the ones that would work with
maven 3.x ? ( probably to get the latest thread safe versions ? )

Thank you for reading.



--sony




--

*Tom Eugelink*
Senior software engineer
+31 (0)6 - 47 93 85 92
t.eugel...@knowledgeplaza.nl 
*KnowledgePlaza *
Sutton 15
7327 AB Apeldoorn
Tel: +31 (0)55 - 526 3887
Fax: +31 (0)55 - 526 3950
i...@knowledgeplaza.nl 
Disclaimer: The information contained in this message is for the intended 
addressee only and may contain confidential and/or privileged information. If 
you are not the intended addressee, please delete this message and notify the 
sender; do not copy or distribute this message or disclose its contents to 
anyone.

Trying to migrate to maven 3.0.3

[Sony Antony]

We have been using mvn 2.1 for a while and we have understood it fairly
well.
Recently we decided to move to 3.x,( mainly for teh parallel build feature
with the -T switch )

But we find teh documentation difficult to come by. Googling didnt dig up
any tutorial or guides for 3.0 specific features.
Specifically, we have the following fundamental questions. Will be very
grateful if somebody could answer these.

1. I read about the changes for the pom.xml in 3.x. Does that mean that I
should change my poms, even if I m not using any features specific to 3.x. (
Maybe I should change the namespace from http://maven.apache.org/POM/4.0.0 to
something newer ? )
2. When I built a simple project, all of teh plugins that got automatically
downloaded from http://repo1.maven.org looked pretty much like the plugins
used by maven 2.x. Does that mean that most of the plugins and repositories
I would be using will be exactly same as maven 2.x ?
3. Even teh super pom looks teh same in maven 3.x ( verified using
help:effective-pom ). Are we supposed to oevrride any of teh versions in the
superpom for the core plugins, so as to get the ones that would work with
maven 3.x ? ( probably to get the latest thread safe versions ? )

Thank you for reading.



--sony

Re: maven-3.0.2 + maven-site-plugin-3.0-beta-3 + multi module projects (can't resolve module dependencies)

[Andrew Hughes]

Hi Lukas,

I agree with you - I'm working this out as I go :)  Switching between m2 and
m3 had no effect - same result.

I'll do two workarounds to "fix" my situation:
1. Remove the 'site' from the release:prepare (as Stevo suggested)
2. Change my Jenkin's jobs so that they are free-style projects with
multiple "build steps", 1=clean install, 2=site. This way the dependencies
*should* be in a maven repository.

I'd really like to contribute to the site plugin, but its a pretty steep
learning curve.

Cheers


On Thu, Apr 14, 2011 at 5:21 PM, Lukas Theussl  wrote:

>
> I'm not sure I follow you, why do you say a workaround is to go back to
> maven 2? MSITE-171 was opened against site-plugin-2.0-beta-5, as I said,
> it's an old issue that's been there forever AFAIK.
>
> -Lukas
>
>
>
> Andrew Hughes wrote:
>
>> Update,
>>
>> I tried to back this out to maven2 and a collection of old plugins, but I
>> still can't get it working. Everything I try fails for this reason or
>> something else telling me to update my plugins. I even totally re-created
>> new project/modules in an effort to fix this. I'm totally stumped with
>> this
>> and starting to wonder if I am on a wild goose chase :'(
>>
>>
>>
>>
>> On Thu, Apr 14, 2011 at 9:14 AM, Andrew Hughes
>>  wrote:
>>
>>  Lukas,
>>>
>>> Thanks for the answer. Unless I can fix this myself I had better shut up
>>> about it. I guess the workaround here is to stay on maven 2 for the time
>>> being (note that the pom  sections are different in m2 and m3
>>> pom.xml's ).
>>>
>>> Thanks for the info.
>>>
>>>
>>> Steve,
>>>
>>> That's a really good point and a big "gotcha" for anyone trying to
>>> release
>>> their project. Seems like m2 might be the only proper workaround to this
>>> (if
>>> you really do want sites). In addition to this... a little off topic but
>>> quite relevant to what you have said. I'm a big fan of sites, but I
>>> believe
>>> site-deploy shouldn't be a goal that is run during a release. This is
>>> because the site can be re-built and deployed anytime you want (post
>>> release). It's convenient to have these run together, but let's say a
>>> password has expired or the site's url host is turned off, or network
>>> problems - I think it adds unnecessary risk to a release. Consequently we
>>> turned this off...
>>>
>>>
>>> 
>>> 
>>> org.apache.maven.plugins
>>> 
>>> 
>>> maven-release-plugin
>>> 
>>> 
>>>
>>> 
>>>
>>> 
>>> deploy
>>> 
>>> 
>>> 
>>>
>>>
>>>
>>> I have a different opinion on this. I am a big fan of maven site's
>>> however
>>> I don't believe that if something fails during
>>>
>>>
>>> On Wed, Apr 13, 2011 at 5:09 PM, Stevo Slavić  wrote:
>>>
>>>  I'm also affected by this issue, when releasing project using
 maven-release-plugin, prepare goes well, perform fails as it detects
 site in distributionManagement and default goals run are "deploy
 site-deploy" so maven tries to generate and deploy site, but since
 site plugin tries to resolve something that's not installed/deployed
 yet, release:perform fails.

 One workaround could be to configure prepare mojo's


 http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#preparationGoals
 to be "clean install" instead of default "clean verify", install is
 after verify, if verification fails install will not be performed, if
 verification is successful install will be performed and artifacts
 will be available in local repository, so as long as release:perform
 is run on same node/machine by same user as release:prepare, site
 should be generated and deployed; deploy will install/overwrite
 artifacts again in local repo and deploy them to remote repo.

 Regards,
 Stevo.

 On Wed, Apr 13, 2011 at 9:17 AM, Lukas Theussl
 wrote:

>
> That's an old issue, see http://jira.codehaus.org/browse/MSITE-171 and
> related tickets.
>
> -Lukas
>
>
> Andrew Hughes wrote:
>
>>
>> Hi All,
>>
>> Before each of the following test, I delete my project/module
>> artifacts
>> from
>> my local repo
>>
>> The following works :)
>>
>> *mvn clean install *
>> *mvn site*
>>
>>
>> The following fails :(
>>
>> *mvn clean install site*
>>
>>
>> The following also fails :(
>>
>> *mvn clean install site:site*
>>
>>
>> The error I consistently get is:
>>
>> [ERROR] Failed to execute goal
>> org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site
>>
> (default-site)

> on
>> project acme-project: failed to get Reports: Failed to execute goal on
>> project acme-project-d: Could not resolve dependencies for project
>> com.acme.project:acme-project-module-d:ejb:5.1.0-SNAPSHOT: *Could not
>>
> find

> artifact com.acme.project:acme-project-module-a:jar:5.1.0-SNAPSHOT* in
>> archiva (http://acme.com/repository/all/) ->   

PDF Plugin

[Stephen Cresswell]

Has anyone got the PDF plugin working with Maven 2.2.1?



org.apache.maven.plugins

maven-site-plugin

2.2



   

org.apache.maven.plugins

maven-pdf-plugin

1.1





pdf

site



pdf






${project.reporting.outputDirectory}









Results in

Caused by: java.lang.NoSuchMethodException:
org.apache.maven.doxia.sink.Sink.toString()
at java.lang.Class.getMethod(Class.java:1605)
at
org.apache.maven.plugins.pdf.PdfMojo$SinkDelegate.invoke(PdfMojo.java:1935)

Cheers,

S

RE: Expected implementation date for Maven MIXIN Feature

[Bock, Richard (NSN - DE/Munich)]

Hi Stephen and Martin

Thanks for your constructive contribution :-)

As we implement a framework it is important to leave the user pom files as 
clean as possible to avoid tedious upgrades when we change the implementation.

Currently I inject the following stuff using profiles with file exists 
condition:

1.) dependencies (type compile and provided)
...

javax.servlet
servlet-api
2.3
provided


com.nsn.see.sce.container.sipservlet
container-sipservlet-api
${sceVersion}
compile

...

2.) plugin configuration e.g.




org.apache.maven.plugins
maven-war-plugin
2.1.1


${project.basedir}/WebContent/WEB-INF/web.xml



${project.basedir}/WebContent/WEB-INF

WEB-INF


weblogic.xml

sip.xml


false







3.) plugin management configurations

4.) properties

The only negative sideeffect the profile workaround currently has is that the 
dependencies cannot be used transitively as the file marker is not in 
repository. I just wonder if I could replace the dependencies with the import 
feature. Will import also add the provided dependencies?

/Richard



-Original Message-
From: ext Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Sent: Thursday, April 14, 2011 2:23 PM
To: Maven Users List
Cc: Martin Gainty
Subject: Re: Expected implementation date for Maven MIXIN Feature

http://www.mail-archive.com/dev@maven.apache.org/msg85145.html

On 14 April 2011 13:16, Martin Gainty  wrote:
>
> you may want to consider aggregating your plugins into a 
> dependency-management block
> then further down have your poms pull in that dependency-management block of 
> plugins with import
> in the calling poms dependency-management dependency
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
>
> if this doesnt suit your need we could provide a better solution if
> you could provide specifics on what you are attempting to accomplish
>
> gruss
> Martin
> __
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
> sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
> oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich 
> dem Austausch von Informationen und entfaltet keine rechtliche 
> Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen 
> wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
> destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
> l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci 
> est interdite. Ce message sert à l'information seulement et n'aura pas 
> n'importe quel effet légalement obligatoire. Étant donné que les email 
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter 
> aucune responsabilité pour le contenu fourni.
>
>
>
>
>> Subject: RE: Expected implementation date for Maven MIXIN Feature
>> Date: Thu, 14 Apr 2011 11:50:06 +0200
>> From: richard.b...@nsn.com
>> To: users@maven.apache.org
>>
>> Hi Anders,
>>
>> Thanks for your clarifications. I try get the wordings right. But what
>> are you actually suggesting? I mean stay away from profiles. Yeah. But
>> what to use instead? Modules will not work as I am actually already
>> using them. I need modules that have an aggregation parent and still get
>> some model type specific configuration (plugins e.g. that are always
>> same for a certain module type).
>>
>> Currently using profiles and  is only a
>> workaround. I am still curious to get a reply from some Maven
>> contributor on whether this problem can be solved with MIXIN and when
>> MIXIN will be available.
>>
>> Using profiles in this manner has the advantage 

Re: Compile C# in maven

[Dennis Lundberg]

Hi

Have go at using NPanday, which is currently in the Apache Incubator.

http://incubator.apache.org/npanday/

Alvarez, Dona - GMRT-EST skrev 2011-04-14 17:12:
> Hi,
> 
> Can you please recommend a way to compile a C# solution in maven? I just need 
> to be able to compile and run the resulting executable in maven. Preferably 
> something that will work in both Windows and Linux.
> 
> Thanks,
> Dona
> 
> --
> This message w/attachments (message) is intended solely for the use of the 
> intended recipient(s) and may contain information that is privileged, 
> confidential or proprietary. If you are not an intended recipient, please 
> notify the sender, and then please delete and destroy all copies and 
> attachments, and be advised that any review or dissemination of, or the 
> taking of any action in reliance on, the information contained in or attached 
> to this message is prohibited. 
> Unless specifically indicated, this message is not an offer to sell or a 
> solicitation of any investment products or other financial product or 
> service, an official confirmation of any transaction, or an official 
> statement of Sender. Subject to applicable law, Sender may intercept, 
> monitor, review and retain e-communications (EC) traveling through its 
> networks/systems and may produce any such EC to regulators, law enforcement, 
> in litigation and as required by law. 
> The laws of the country of each sender/recipient may impact the handling of 
> EC, and EC may be archived, supervised and produced in countries other than 
> the country in which you are located. This message cannot be guaranteed to be 
> secure or free of errors or viruses. 
> 
> References to "Sender" are references to any subsidiary of Bank of America 
> Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are 
> Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a 
> Condition to Any Banking Service or Activity * Are Not Insured by Any Federal 
> Government Agency. Attachments that are part of this EC may have additional 
> important disclosures and disclaimers, which you should read. This message is 
> subject to terms available at the following link: 
> http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you 
> consent to the foregoing.
> 


-- 
Dennis Lundberg

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

Mojo: How do I write a plugin to interact with another?

[laredotornado-3]

Hi,

I'm using Maven 3.0.3.  I want to write a Maven plugin that will ultimately
output a string (in my case, a version control revision number) that will be
used by another plugin (SCM).  How do I pass the value from one place to
another?  FYI, I want the value to be used by the scm:checkout task here ...

  
org.apache.maven.plugins
maven-scm-plugin
1.5

  install
  username
  password
  
  revision

  

Could someone point me at an example or let me know how this is done? 
Thanks, - Dave


--
View this message in context: 
http://maven.40175.n5.nabble.com/Mojo-How-do-I-write-a-plugin-to-interact-with-another-tp4303832p4303832.html
Sent from the Maven - Users mailing list archive at Nabble.com.

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

RE: Compile C# in maven

[Hessick, Michael]

I'd recommend starting here, I was able to get several example .NET projects 
building using this plugin.

Trying to get NPanday to work might be an exercise in frustration.


1)  http://maven-dotnet-plugin.appspot.com/usage.html


-Mike


-Original Message-
From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On Behalf Of 
Anders Hammar
Sent: Thursday, April 14, 2011 12:34 PM
To: Maven Users List
Subject: Re: Compile C# in maven

Ignore Martin, he/she/it is a bot.

I don't have any experience myself, but I have seen references to the
NPanday project and the maven NAR plugin for .Net and Maven.

/Anders

On Thu, Apr 14, 2011 at 17:38, Alvarez, Dona - GMRT-EST <
dona.alva...@baml.com> wrote:

>
> Here's the info:
>
> $ uname -a
> Linux uswxapbtis02 2.6.18-164.2.1.el5 #1 SMP Mon Sep 21 04:37:42 EDT 2009
> x86_64 x86_64 x86_64 GNU/Linux
> $ cat /proc/version
> Linux version 2.6.18-164.2.1.el5 (mockbu...@x86-006.build.bos.redhat.com)
> (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Mon Sep 21 04:37:42
> EDT 2009
>
> And I'm compiling to native dll and exe
>
> Thanks.
>
> -Original Message-
> From: Martin Gainty [mailto:mgai...@hotmail.com]
> Sent: Thursday, April 14, 2011 10:22 AM
> To: users@maven.apache.org
> Subject: RE: Compile C# in maven
>
>
> C# has different compiler options for each version of host OS so we would
> need to know:
> 1)what is the Host environment discovered by executing at command line?
> uname -a
> 2)are you compiling for MSIL (an assembly to go into gac) or are you
> compiling to native dll?
>
> bedankt,
> Martin
> __
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
> destinataire prévu, nous te demandons avec bonté que pour satisfaire
> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
> de ceci est interdite. Ce message sert à l'information seulement et n'aura
> pas n'importe quel effet légalement obligatoire. Étant donné que les email
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
> aucune responsabilité pour le contenu fourni.
>
>
>
>
> > Date: Thu, 14 Apr 2011 10:12:23 -0500
> > From: dona.alva...@baml.com
> > Subject: Compile C# in maven
> > To: users@maven.apache.org
> >
> > Hi,
> >
> > Can you please recommend a way to compile a C# solution in maven? I just
> need to be able to compile and run the resulting executable in maven.
> Preferably something that will work in both Windows and Linux.
> >
> > Thanks,
> > Dona
> >
> > --
> > This message w/attachments (message) is intended solely for the use of
> the intended recipient(s) and may contain information that is privileged,
> confidential or proprietary. If you are not an intended recipient, please
> notify the sender, and then please delete and destroy all copies and
> attachments, and be advised that any review or dissemination of, or the
> taking of any action in reliance on, the information contained in or
> attached to this message is prohibited.
> > Unless specifically indicated, this message is not an offer to sell or a
> solicitation of any investment products or other financial product or
> service, an official confirmation of any transaction, or an official
> statement of Sender. Subject to applicable law, Sender may intercept,
> monitor, review and retain e-communications (EC) traveling through its
> networks/systems and may produce any such EC to regulators, law enforcement,
> in litigation and as required by law.
> > The laws of the country of each sender/recipient may impact the handling
> of EC, and EC may be archived, supervised and produced in countries other
> than the country in which you are located. This message cannot be guaranteed
> to be secure or free of errors or viruses.
> >
> > References to "Sender" are references to any subsidiary of Bank of
> America Corporation. Securities and Insurance Products: * Are Not FDIC
> Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit
> * Are Not a Condition to Any Banking Service or Activity * Are Not Insured
> by Any Federal Government Agency. Attachments that are part of this EC may
> have additional important disclosures and disclaimers, which you should
> read. This message is subject to terms available at the following link:
> > http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender
> you

Re: Compile C# in maven

[Anders Hammar]

Ignore Martin, he/she/it is a bot.

I don't have any experience myself, but I have seen references to the
NPanday project and the maven NAR plugin for .Net and Maven.

/Anders

On Thu, Apr 14, 2011 at 17:38, Alvarez, Dona - GMRT-EST <
dona.alva...@baml.com> wrote:

>
> Here's the info:
>
> $ uname -a
> Linux uswxapbtis02 2.6.18-164.2.1.el5 #1 SMP Mon Sep 21 04:37:42 EDT 2009
> x86_64 x86_64 x86_64 GNU/Linux
> $ cat /proc/version
> Linux version 2.6.18-164.2.1.el5 (mockbu...@x86-006.build.bos.redhat.com)
> (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Mon Sep 21 04:37:42
> EDT 2009
>
> And I'm compiling to native dll and exe
>
> Thanks.
>
> -Original Message-
> From: Martin Gainty [mailto:mgai...@hotmail.com]
> Sent: Thursday, April 14, 2011 10:22 AM
> To: users@maven.apache.org
> Subject: RE: Compile C# in maven
>
>
> C# has different compiler options for each version of host OS so we would
> need to know:
> 1)what is the Host environment discovered by executing at command line?
> uname -a
> 2)are you compiling for MSIL (an assembly to go into gac) or are you
> compiling to native dll?
>
> bedankt,
> Martin
> __
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene
> Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte
> Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht
> dient lediglich dem Austausch von Informationen und entfaltet keine
> rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von
> E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le
> destinataire prévu, nous te demandons avec bonté que pour satisfaire
> informez l'expéditeur. N'importe quelle diffusion non autorisée ou la copie
> de ceci est interdite. Ce message sert à l'information seulement et n'aura
> pas n'importe quel effet légalement obligatoire. Étant donné que les email
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter
> aucune responsabilité pour le contenu fourni.
>
>
>
>
> > Date: Thu, 14 Apr 2011 10:12:23 -0500
> > From: dona.alva...@baml.com
> > Subject: Compile C# in maven
> > To: users@maven.apache.org
> >
> > Hi,
> >
> > Can you please recommend a way to compile a C# solution in maven? I just
> need to be able to compile and run the resulting executable in maven.
> Preferably something that will work in both Windows and Linux.
> >
> > Thanks,
> > Dona
> >
> > --
> > This message w/attachments (message) is intended solely for the use of
> the intended recipient(s) and may contain information that is privileged,
> confidential or proprietary. If you are not an intended recipient, please
> notify the sender, and then please delete and destroy all copies and
> attachments, and be advised that any review or dissemination of, or the
> taking of any action in reliance on, the information contained in or
> attached to this message is prohibited.
> > Unless specifically indicated, this message is not an offer to sell or a
> solicitation of any investment products or other financial product or
> service, an official confirmation of any transaction, or an official
> statement of Sender. Subject to applicable law, Sender may intercept,
> monitor, review and retain e-communications (EC) traveling through its
> networks/systems and may produce any such EC to regulators, law enforcement,
> in litigation and as required by law.
> > The laws of the country of each sender/recipient may impact the handling
> of EC, and EC may be archived, supervised and produced in countries other
> than the country in which you are located. This message cannot be guaranteed
> to be secure or free of errors or viruses.
> >
> > References to "Sender" are references to any subsidiary of Bank of
> America Corporation. Securities and Insurance Products: * Are Not FDIC
> Insured * Are Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit
> * Are Not a Condition to Any Banking Service or Activity * Are Not Insured
> by Any Federal Government Agency. Attachments that are part of this EC may
> have additional important disclosures and disclaimers, which you should
> read. This message is subject to terms available at the following link:
> > http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender
> you consent to the foregoing.
>
>
> --
> This message w/attachments (message) is intended solely for the use of the
> intended recipient(s) and may contain information that is privileged,
> confidential or proprietary. If you are not an intended recipient, please
> notify the sender, and then please delete and destroy all copies and
> attachments, and be advised that any review or disseminatio

Re: overriding goal's configuration from command line?

[amaresh mourya]

Thanks Tim and Stephen...
-Amaresh

On Thu, Apr 14, 2011 at 5:30 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> BUT if you have specified a configuration using a fixed value, then
> that default property will be ignored so if you have
>
>
>org.apache.maven.plugins
>maven-compiler-plugin
>2.0.2
>
>1.6
>1.6
>
>
>
> Then the property will not be considered
>
> if you have
>
> 
> 1.6
> 
> ...
> 
>org.apache.maven.plugins
>maven-compiler-plugin
>2.0.2
>
> ${maven.compiler.source}
> 1.6
>
>
>
> then the property will be defaulted but can be overiden from the command
> line.
>
> On 14 April 2011 11:42, Tim Kettler  wrote:
> > Hi,
> >
> > you can look that up in the documentation of the goal [1]. If an
> expression
> > is defined for a parameter that is what you can use as a property on the
> > commandline. In your example: -Dmaven.compiler.source=1.5
> >
> > -Tim
> >
> > [1]
> http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html
> >
> > Am 14.04.2011 12:16, schrieb amaresh mourya:
> >>
> >> Hi,
> >>
> >> How do I override compiler source to be used If I run mvn
> compiler:compile
> >> from the command line.
> >>
> >> Compiler:compile goal has parameter called source. Doesn't that mean If
> I
> >> run
> >> [ mvn compiler:compile -Dsource=1.5 ] it should use 1.5 instead of 1.6?
> >>
> >> My POM is like :
> >>
> >> 
> >> http://maven.apache.org/POM/4.0.0";>
> >> 4.0.0
> >> Application6
> >> mavenProj
> >> 1.0-SNAPSHOT
> >> Project for mavenProj
> >> 
> >> 
> >> 
> >> org.apache.maven.plugins
> >> maven-compiler-plugin
> >> 2.0.2
> >> 
> >> 1.6
> >> 1.6
> >> 
> >> 
> >>   
> >>
> >> 
> >>
> >>
> >> thanks
> >> --Amaresh
> >>
> >> On Thu, Apr 14, 2011 at 3:22 PM, Stephen Connolly<
> >> stephen.alan.conno...@gmail.com>  wrote:
> >>
> >>> what you can do in that case is define properties in the pom and use
> >>> those properties to define the default-cli values.
> >>>
> >>> properties set via the CLI override properties declared in the POM.
> >>>
> >>>  http://maven.apache.org/POM/4.0.0";>
> >>> 4.0.0
> >>> Application6
> >>> mavenProj
> >>> 1.0-SNAPSHOT
> >>> Project for mavenProj
> >>> 
> >>>welcome
> >>>chandan
> >>> 
> >>> 
> >>> 
> >>>  
> >>> MyPlugins
> >>> hiPlugin
> >>> 1.0
> >>> 
> >>> 
> >>>default-cli
> >>> 
> >>> hi
> >>> 
> >>>  
> >>>  ${greetings}
> >>>  ${person}
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>> 
> >>>  
> >>>  
> >>>  
> >>>  
> >>>
> >>> Note that the property names do not have to be the same as the
> >>> @parameter expression="${myplugin.greeting}"  style
> >>> default properties you specified in your mojo, but usually you would
> >>> keep them the same... unless you are relying on those properties for
> >>> the lifecycle-invoked goals
> >>>
> >>> -Stephen
> >>>
> >>> On 14 April 2011 10:28, amaresh mourya
>  wrote:
> 
>  Hi All,
> 
>  I have a POM which has a plugin. I have configured it to use some
> >>>
> >>> specific
> 
>  settings at the time of command line invocation of the goal. I set
> these
>  configurations in execution ID as "default-cli".
> 
>  This MyPlugins:hiPlugin:1.0:hi goals just prints the output in format
> of
> >>>
> >>> :
> 
>  ${person} says ${greetings}
>  When I ran goal (MyPlugins:hiPlugin:1.0:hi) on command line I got the
>  expected output that was : "Chandan says Welcome"
>  But My question is why am I not able to override these configurations
> >>>
> >>> from
> 
>  command line, I wanted to run goal with parameter
> >>>
> >>> (MyPlugins:hiPlugin:1.0:hi
> 
>  -Dperson=Vishal) to get the output as "Vishal says Welcome". But I am
> >>>
> >>> still
> 
>  getting output "Chandan says Welcome".
> 
>  Here is my POM.
> 
>  http://maven.apache.org/POM/4.0.0";>
> 4.0.0
> Application6
> mavenProj
> 1.0-SNAPSHOT
> Project for mavenProj
> 
> 
>  
> MyPlugins
> hiPlugin
> 1.0
> 
> 
> 

RE: Compile C# in maven

[Alvarez, Dona - GMRT-EST]

Here's the info:

$ uname -a
Linux uswxapbtis02 2.6.18-164.2.1.el5 #1 SMP Mon Sep 21 04:37:42 EDT 2009 
x86_64 x86_64 x86_64 GNU/Linux
$ cat /proc/version
Linux version 2.6.18-164.2.1.el5 (mockbu...@x86-006.build.bos.redhat.com) (gcc 
version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Mon Sep 21 04:37:42 EDT 2009

And I'm compiling to native dll and exe

Thanks.

-Original Message-
From: Martin Gainty [mailto:mgai...@hotmail.com] 
Sent: Thursday, April 14, 2011 10:22 AM
To: users@maven.apache.org
Subject: RE: Compile C# in maven


C# has different compiler options for each version of host OS so we would need 
to know:
1)what is the Host environment discovered by executing at command line?
uname -a
2)are you compiling for MSIL (an assembly to go into gac) or are you compiling 
to native dll?

bedankt,
Martin 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




> Date: Thu, 14 Apr 2011 10:12:23 -0500
> From: dona.alva...@baml.com
> Subject: Compile C# in maven
> To: users@maven.apache.org
> 
> Hi,
> 
> Can you please recommend a way to compile a C# solution in maven? I just need 
> to be able to compile and run the resulting executable in maven. Preferably 
> something that will work in both Windows and Linux.
> 
> Thanks,
> Dona
> 
> --
> This message w/attachments (message) is intended solely for the use of the 
> intended recipient(s) and may contain information that is privileged, 
> confidential or proprietary. If you are not an intended recipient, please 
> notify the sender, and then please delete and destroy all copies and 
> attachments, and be advised that any review or dissemination of, or the 
> taking of any action in reliance on, the information contained in or attached 
> to this message is prohibited. 
> Unless specifically indicated, this message is not an offer to sell or a 
> solicitation of any investment products or other financial product or 
> service, an official confirmation of any transaction, or an official 
> statement of Sender. Subject to applicable law, Sender may intercept, 
> monitor, review and retain e-communications (EC) traveling through its 
> networks/systems and may produce any such EC to regulators, law enforcement, 
> in litigation and as required by law. 
> The laws of the country of each sender/recipient may impact the handling of 
> EC, and EC may be archived, supervised and produced in countries other than 
> the country in which you are located. This message cannot be guaranteed to be 
> secure or free of errors or viruses. 
> 
> References to "Sender" are references to any subsidiary of Bank of America 
> Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are 
> Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a 
> Condition to Any Banking Service or Activity * Are Not Insured by Any Federal 
> Government Agency. Attachments that are part of this EC may have additional 
> important disclosures and disclaimers, which you should read. This message is 
> subject to terms available at the following link: 
> http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you 
> consent to the foregoing.
  

--
This message w/attachments (message) is intended solely for the use of the 
intended recipient(s) and may contain information that is privileged, 
confidential or proprietary. If you are not an intended recipient, please 
notify the sender, and then please delete and destroy all copies and 
attachments, and be advised that any review or dissemination of, or the taking 
of any action in reliance on, the information contained in or attached to this 
message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a 
solicitation of any investment products or other financial product or service, 
an official confirmation of an

RE: Compile C# in maven

[Martin Gainty]

C# has different compiler options for each version of host OS so we would need 
to know:
1)what is the Host environment discovered by executing at command line?
uname -a
2)are you compiling for MSIL (an assembly to go into gac) or are you compiling 
to native dll?

bedankt,
Martin 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




> Date: Thu, 14 Apr 2011 10:12:23 -0500
> From: dona.alva...@baml.com
> Subject: Compile C# in maven
> To: users@maven.apache.org
> 
> Hi,
> 
> Can you please recommend a way to compile a C# solution in maven? I just need 
> to be able to compile and run the resulting executable in maven. Preferably 
> something that will work in both Windows and Linux.
> 
> Thanks,
> Dona
> 
> --
> This message w/attachments (message) is intended solely for the use of the 
> intended recipient(s) and may contain information that is privileged, 
> confidential or proprietary. If you are not an intended recipient, please 
> notify the sender, and then please delete and destroy all copies and 
> attachments, and be advised that any review or dissemination of, or the 
> taking of any action in reliance on, the information contained in or attached 
> to this message is prohibited. 
> Unless specifically indicated, this message is not an offer to sell or a 
> solicitation of any investment products or other financial product or 
> service, an official confirmation of any transaction, or an official 
> statement of Sender. Subject to applicable law, Sender may intercept, 
> monitor, review and retain e-communications (EC) traveling through its 
> networks/systems and may produce any such EC to regulators, law enforcement, 
> in litigation and as required by law. 
> The laws of the country of each sender/recipient may impact the handling of 
> EC, and EC may be archived, supervised and produced in countries other than 
> the country in which you are located. This message cannot be guaranteed to be 
> secure or free of errors or viruses. 
> 
> References to "Sender" are references to any subsidiary of Bank of America 
> Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are 
> Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a 
> Condition to Any Banking Service or Activity * Are Not Insured by Any Federal 
> Government Agency. Attachments that are part of this EC may have additional 
> important disclosures and disclaimers, which you should read. This message is 
> subject to terms available at the following link: 
> http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you 
> consent to the foregoing.
  

findbugs plugin: effect on effort attribute in configuration

[eyal edri]

Can someone explain what is the effect of the 'effort' attribute in the
configuration?
is there a risk for false positives with this option?

thanks

Eyal.

Compile C# in maven

[Alvarez, Dona - GMRT-EST]

Hi,

Can you please recommend a way to compile a C# solution in maven? I just need 
to be able to compile and run the resulting executable in maven. Preferably 
something that will work in both Windows and Linux.

Thanks,
Dona

--
This message w/attachments (message) is intended solely for the use of the 
intended recipient(s) and may contain information that is privileged, 
confidential or proprietary. If you are not an intended recipient, please 
notify the sender, and then please delete and destroy all copies and 
attachments, and be advised that any review or dissemination of, or the taking 
of any action in reliance on, the information contained in or attached to this 
message is prohibited. 
Unless specifically indicated, this message is not an offer to sell or a 
solicitation of any investment products or other financial product or service, 
an official confirmation of any transaction, or an official statement of 
Sender. Subject to applicable law, Sender may intercept, monitor, review and 
retain e-communications (EC) traveling through its networks/systems and may 
produce any such EC to regulators, law enforcement, in litigation and as 
required by law. 
The laws of the country of each sender/recipient may impact the handling of EC, 
and EC may be archived, supervised and produced in countries other than the 
country in which you are located. This message cannot be guaranteed to be 
secure or free of errors or viruses. 

References to "Sender" are references to any subsidiary of Bank of America 
Corporation. Securities and Insurance Products: * Are Not FDIC Insured * Are 
Not Bank Guaranteed * May Lose Value * Are Not a Bank Deposit * Are Not a 
Condition to Any Banking Service or Activity * Are Not Insured by Any Federal 
Government Agency. Attachments that are part of this EC may have additional 
important disclosures and disclaimers, which you should read. This message is 
subject to terms available at the following link: 
http://www.bankofamerica.com/emaildisclaimer. By messaging with Sender you 
consent to the foregoing.

Re: same proyects running under java 1.4 and java 1.5

[Jörg Schaible]

Hi Anders,

Anders Hammar wrote:

> You will be trying to deploy the pom twice (once for each build run) which
> the release repository policy of your Nexus instance will not let you do.
> Thus, the build will fail (as it should).
> But you might be using some tooling will less checking...

No, it has every time a different version. In the example either 1.4.x(-
SNAPSHOT) or 1.5.x(-SNAPSHOT). We're not using Nexus though, but again, it's 
no different from building two different branches.

- Jörg


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

Re: same proyects running under java 1.4 and java 1.5

[Anders Hammar]

You will be trying to deploy the pom twice (once for each build run) which
the release repository policy of your Nexus instance will not let you do.
Thus, the build will fail (as it should).
But you might be using some tooling will less checking...

/Anders

On Thu, Apr 14, 2011 at 16:15, Jörg Schaible wrote:

> Hi Anders,
>
> Anders Hammar wrote:
>
> > How are you executing one build run that produces both artifacts? Are you
> > really deploying to a repository? I can't see how that would work, but I
> > could be missing something.
>
> Why do you have to? Even for a release you don't have to release the
> component in both versions *at once* although it can be of advantage to
> keep
> the versions in sync.
>
> For snapshots it depends on your orgnization. For CI I would actually build
> two times with a linked build plan, i.e. when the Java 6 version succeeds
> proceed with a Java 5 setup.
>
> See, it is like working on two branches, but with shared code. Since it is
> only the version that is different, you have even an automated upgrade
> path.
> If you Java 5 app is switching to Java 6 you can use the "newer" branch.
> It's compile time compatible only, but that does not matter, because the
> switch from JDBC 3 to JDBC 4 is also not binary compatible.
>
> And, yes, I agree that profiles should normally not be used to select
> different artifacts, it's just for this case where it gets handy without
> doing harm if you control the version in a depMgmt section anyway for the
> client project ;-)
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: same proyects running under java 1.4 and java 1.5

[Jörg Schaible]

Hi Anders,

Anders Hammar wrote:

> How are you executing one build run that produces both artifacts? Are you
> really deploying to a repository? I can't see how that would work, but I
> could be missing something.

Why do you have to? Even for a release you don't have to release the 
component in both versions *at once* although it can be of advantage to keep 
the versions in sync.

For snapshots it depends on your orgnization. For CI I would actually build 
two times with a linked build plan, i.e. when the Java 6 version succeeds 
proceed with a Java 5 setup.

See, it is like working on two branches, but with shared code. Since it is 
only the version that is different, you have even an automated upgrade path. 
If you Java 5 app is switching to Java 6 you can use the "newer" branch. 
It's compile time compatible only, but that does not matter, because the 
switch from JDBC 3 to JDBC 4 is also not binary compatible.

And, yes, I agree that profiles should normally not be used to select 
different artifacts, it's just for this case where it gets handy without 
doing harm if you control the version in a depMgmt section anyway for the 
client project ;-)

- Jörg


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

Re: same proyects running under java 1.4 and java 1.5

[Fernando Wermus]

Interesting solution. thanks! I will consult

2011/4/13 Jörg Schaible 

> Hi,
>
> Fernando Wermus wrote:
>
> > Hi all,
> > We have a proyect which we need to compile under java 1.4 for some
> > companies and 1.6 for other companies. The problem is that in java 1.6 we
> > have a class that implements an interface named ResulSet. Result changes
> > its methods from 1.4 to 1.6 because jdbc changes. Then we need to have an
> > implementation of Resulset for java 1.4 and another impl for java 1.6.
> > What we need is to add to our currents profiles a way to include or
> > exclude some class in the proyect with the same package and class name.
> >
> > Is any solution from maven for this problem?
> >
> > thanks in advance and I hope you have understood our problem.
>
> This is how we did it:
>
> 1/ Use two independent version lines i.e. do it like Apache commons dbcp
> where version 1.3.x is for JDBC 3 (Java 5 or lower) and version 1.4.x is
> for
> JDBC 4 (Java 6).
>
> 2/ Use comment markers in your Java code, see following snippet:
>
> = %< =
> /*JDBC4**/
> import java.sql.NClob;
> import java.sql.RowId;
> import java.sql.SQLXML;
> //*JDBC4*/
> = %< =
>
> All types and methods that are only available for JDBC 4 are surrounded
> with
> those two markers i.e. the code is compilable from your IDE with Java 6 as
> usual.
>
> 3/ Prepare the POM to modify the source using a profile based on the target
> JDK.
>
> The trick is to use the original source that compiles against JDBC 4 and
> filter it (resp. generate new sources) with a regular expression that uses
> those two markers to create Java block comments and let the compiler use
> the
> new sources then.
>
> === %< ===
> ...
>  your.company
>  your.artifact
>  ${version.your.artifact}
> ...
>  
>${local.source.directory}
>  
> ...
>  
>
>  jdk15
>  
>1.5
>  
>  
>
>  
>your.company
>regexp-plugin
>
>  
>filter-jdbc4
>generate-sources
>
>  perform
>
>  
>
>
>  
>${basedir}/src/main/java
>${basedir}/target/generated-
> sources/java
>   
>  
>/\*JDBC4\*\*/
>/*JDBC4
>  
>  
>//\*JDBC4\*/
>JDBC4*/
>  
>
>  
>
>  
>
>  
>  
>target/generated-
> sources/java
>  
>
>  
> ...
>  
>src/main/java
>  
> === %< ===
>
> The property "version.your.artifact" is defined in the parent and the
> artifact is also declared there in a depMgmt section:
>
> === %< ===
> ...
>  
>
>  
>your.company
>your.artifact
>${version.your.artifact}
>  
>
>  
> ...
>  
>
>  jdk15
>  
>1.5
>  
>  
>1.6.0-SNAPSHOT
>  
>
>  
> ...
>  
>1.5.0-SNAPSHOT
>  
> === %< ===
>
> Now, the plugin we use for the regexp fitlering is not publicly available,
> but if you look at Apache dbcp, it is done there with an Ant task and you
> should be able to to similar with the antrun plugin. I've also seen once
> that plexus-utils have capabilities for regexp filtering, but I don't know
> if there's any syntax to activate this for standard Maven filtering. OTOH
> it
> is really easy to write such a simply plugin yourself ;-)
>
> Note, we used the current JDK for profile activation i.e. it depends on the
> Java version we use to run Maven itself. This might not be appropriate, you
> will have to define different activations then.
>
> Hope this gives you some ideas,
> Jörg
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Expected implementation date for Maven MIXIN Feature

[Stephen Connolly]

http://www.mail-archive.com/dev@maven.apache.org/msg85145.html

On 14 April 2011 13:16, Martin Gainty  wrote:
>
> you may want to consider aggregating your plugins into a 
> dependency-management block
> then further down have your poms pull in that dependency-management block of 
> plugins with import
> in the calling poms dependency-management dependency
>
> http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html
>
> if this doesnt suit your need we could provide a better solution if
> you could provide specifics on what you are attempting to accomplish
>
> gruss
> Martin
> __
> Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
>
> Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
> sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
> oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich 
> dem Austausch von Informationen und entfaltet keine rechtliche 
> Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen 
> wir keine Haftung fuer den Inhalt uebernehmen.
> Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
> destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
> l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci 
> est interdite. Ce message sert à l'information seulement et n'aura pas 
> n'importe quel effet légalement obligatoire. Étant donné que les email 
> peuvent facilement être sujets à la manipulation, nous ne pouvons accepter 
> aucune responsabilité pour le contenu fourni.
>
>
>
>
>> Subject: RE: Expected implementation date for Maven MIXIN Feature
>> Date: Thu, 14 Apr 2011 11:50:06 +0200
>> From: richard.b...@nsn.com
>> To: users@maven.apache.org
>>
>> Hi Anders,
>>
>> Thanks for your clarifications. I try get the wordings right. But what
>> are you actually suggesting? I mean stay away from profiles. Yeah. But
>> what to use instead? Modules will not work as I am actually already
>> using them. I need modules that have an aggregation parent and still get
>> some model type specific configuration (plugins e.g. that are always
>> same for a certain module type).
>>
>> Currently using profiles and  is only a
>> workaround. I am still curious to get a reply from some Maven
>> contributor on whether this problem can be solved with MIXIN and when
>> MIXIN will be available.
>>
>> Using profiles in this manner has the advantage that all module pom
>> files are using the traditional aggregation parent but do not contain
>> any redundant plugin configurations that are related to the module type
>> (e.g. modeling project, java implementation project, web service project
>> and so on)
>>
>> /Richard
>>
>>
>> -Original Message-
>> From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On
>> Behalf Of ext Anders Hammar
>> Sent: Thursday, April 14, 2011 11:09 AM
>> To: Maven Users List
>> Subject: Re: Expected implementation date for Maven MIXIN Feature
>>
>> Please, don't call it a super-pom. There is only one (and will only be
>> just
>> one) super-POM and it lives in Maven core. What you are talking about is
>> a
>> parent-pom and should be called that.
>>
>> Also, you're talking about archetypes which is something completely
>> different from "artifacts" which I believe you're referring to. Please
>> pay
>> attention to the wording as it makes it easier for other people to
>> understand what you're explaining.
>>
>> As you've noticed, the actual profile isn't inherited but rather the
>> effect
>> of the profile. One of those tricky things with profiles but that's by
>> design. The simplest thing is to try staying away from profiles all
>> together
>> as they very often trick you into doing something which isn't the Maven
>> Way..
>>
>> /Anders
>>
>> On Wed, Apr 13, 2011 at 20:32, Bock, Richard (NSN - DE/Munich) <
>> richard.b...@nsn.com> wrote:
>>
>> > Today I found a workaround which is somehow not optional but keeps me
>> > alive.
>> >
>> > All the base artifact types of a certain platform type will be put
>> into a
>> > super-pom for that platform type. E.g. jee-super-pom. Each artifact
>> base
>> > type plugin and properties is encapsulated into a Profile. The profile
>> is
>> > activated by a file that exists in the child project.
>> >
>> > Now the aggregator project myapp-pom can inherit from the
>> jee-super.pom.
>> >
>> > Each module module-pom will have a file e.g. javalib-architype,
>> > groovylib-architype, basemodel-architype, testimpl-architype. This
>> will
>> > activate the base architype profiles.
>> >
>> > Drawback is that this leaves the module-pom projects with funny empty
>> > marker files in the project folder and the files cannot be looked up
>> in the
>> > repository as they are no architypes.
>> >
>> > What I find rather annoying is that even the activiation condition
>> based on
>> > pro

RE: Expected implementation date for Maven MIXIN Feature

[Martin Gainty]

you may want to consider aggregating your plugins into a dependency-management 
block
then further down have your poms pull in that dependency-management block of 
plugins with import
in the calling poms dependency-management dependency

http://maven.apache.org/guides/introduction/introduction-to-dependency-mechanism.html

if this doesnt suit your need we could provide a better solution if 
you could provide specifics on what you are attempting to accomplish

gruss 
Martin 
__ 
Verzicht und Vertraulichkeitanmerkung/Note de déni et de confidentialité
 
Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger 
sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung 
oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem 
Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. 
Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung 
fuer den Inhalt uebernehmen.
Ce message est confidentiel et peut être privilégié. Si vous n'êtes pas le 
destinataire prévu, nous te demandons avec bonté que pour satisfaire informez 
l'expéditeur. N'importe quelle diffusion non autorisée ou la copie de ceci est 
interdite. Ce message sert à l'information seulement et n'aura pas n'importe 
quel effet légalement obligatoire. Étant donné que les email peuvent facilement 
être sujets à la manipulation, nous ne pouvons accepter aucune responsabilité 
pour le contenu fourni.




> Subject: RE: Expected implementation date for Maven MIXIN Feature
> Date: Thu, 14 Apr 2011 11:50:06 +0200
> From: richard.b...@nsn.com
> To: users@maven.apache.org
> 
> Hi Anders,
> 
> Thanks for your clarifications. I try get the wordings right. But what
> are you actually suggesting? I mean stay away from profiles. Yeah. But
> what to use instead? Modules will not work as I am actually already
> using them. I need modules that have an aggregation parent and still get
> some model type specific configuration (plugins e.g. that are always
> same for a certain module type).
> 
> Currently using profiles and  is only a
> workaround. I am still curious to get a reply from some Maven
> contributor on whether this problem can be solved with MIXIN and when
> MIXIN will be available.
> 
> Using profiles in this manner has the advantage that all module pom
> files are using the traditional aggregation parent but do not contain
> any redundant plugin configurations that are related to the module type
> (e.g. modeling project, java implementation project, web service project
> and so on)
> 
> /Richard
> 
> 
> -Original Message-
> From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On
> Behalf Of ext Anders Hammar
> Sent: Thursday, April 14, 2011 11:09 AM
> To: Maven Users List
> Subject: Re: Expected implementation date for Maven MIXIN Feature
> 
> Please, don't call it a super-pom. There is only one (and will only be
> just
> one) super-POM and it lives in Maven core. What you are talking about is
> a
> parent-pom and should be called that.
> 
> Also, you're talking about archetypes which is something completely
> different from "artifacts" which I believe you're referring to. Please
> pay
> attention to the wording as it makes it easier for other people to
> understand what you're explaining.
> 
> As you've noticed, the actual profile isn't inherited but rather the
> effect
> of the profile. One of those tricky things with profiles but that's by
> design. The simplest thing is to try staying away from profiles all
> together
> as they very often trick you into doing something which isn't the Maven
> Way..
> 
> /Anders
> 
> On Wed, Apr 13, 2011 at 20:32, Bock, Richard (NSN - DE/Munich) <
> richard.b...@nsn.com> wrote:
> 
> > Today I found a workaround which is somehow not optional but keeps me
> > alive.
> >
> > All the base artifact types of a certain platform type will be put
> into a
> > super-pom for that platform type. E.g. jee-super-pom. Each artifact
> base
> > type plugin and properties is encapsulated into a Profile. The profile
> is
> > activated by a file that exists in the child project.
> >
> > Now the aggregator project myapp-pom can inherit from the
> jee-super.pom.
> >
> > Each module module-pom will have a file e.g. javalib-architype,
> > groovylib-architype, basemodel-architype, testimpl-architype. This
> will
> > activate the base architype profiles.
> >
> > Drawback is that this leaves the module-pom projects with funny empty
> > marker files in the project folder and the files cannot be looked up
> in the
> > repository as they are no architypes.
> >
> > What I find rather annoying is that even the activiation condition
> based on
> > properties will not work as the parent profiles will only be triggered
> by
> > parent properties and not by properties defined in the module-pom.
> >
> > So I just hope someday or earlier then later someone will add a
> feature to
> > Maven

Re: overriding goal's configuration from command line?

[Stephen Connolly]

BUT if you have specified a configuration using a fixed value, then
that default property will be ignored so if you have


org.apache.maven.plugins
maven-compiler-plugin
2.0.2

1.6
1.6



Then the property will not be considered

if you have


1.6

...

org.apache.maven.plugins
maven-compiler-plugin
2.0.2

${maven.compiler.source}
1.6



then the property will be defaulted but can be overiden from the command line.

On 14 April 2011 11:42, Tim Kettler  wrote:
> Hi,
>
> you can look that up in the documentation of the goal [1]. If an expression
> is defined for a parameter that is what you can use as a property on the
> commandline. In your example: -Dmaven.compiler.source=1.5
>
> -Tim
>
> [1] http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html
>
> Am 14.04.2011 12:16, schrieb amaresh mourya:
>>
>> Hi,
>>
>> How do I override compiler source to be used If I run mvn compiler:compile
>> from the command line.
>>
>> Compiler:compile goal has parameter called source. Doesn't that mean If I
>> run
>> [ mvn compiler:compile -Dsource=1.5 ] it should use 1.5 instead of 1.6?
>>
>> My POM is like :
>>
>> 
>> http://maven.apache.org/POM/4.0.0";>
>>     4.0.0
>>     Application6
>>     mavenProj
>>     1.0-SNAPSHOT
>>     Project for mavenProj
>>     
>>         
>>             
>>                 org.apache.maven.plugins
>>                 maven-compiler-plugin
>>                 2.0.2
>>                 
>>                     1.6
>>                     1.6
>>                 
>>             
>>       
>>    
>> 
>>
>>
>> thanks
>> --Amaresh
>>
>> On Thu, Apr 14, 2011 at 3:22 PM, Stephen Connolly<
>> stephen.alan.conno...@gmail.com>  wrote:
>>
>>> what you can do in that case is define properties in the pom and use
>>> those properties to define the default-cli values.
>>>
>>> properties set via the CLI override properties declared in the POM.
>>>
>>>  http://maven.apache.org/POM/4.0.0";>
>>>     4.0.0
>>>     Application6
>>>     mavenProj
>>>     1.0-SNAPSHOT
>>>     Project for mavenProj
>>>     
>>>        welcome
>>>        chandan
>>>     
>>>     
>>>         
>>>          
>>>                 MyPlugins
>>>                 hiPlugin
>>>                 1.0
>>>                 
>>>                     
>>>                        default-cli
>>>                         
>>>                             hi
>>>                         
>>>                          
>>>                              ${greetings}
>>>                              ${person}
>>>                         
>>>                     
>>>                 
>>>             
>>>         
>>>     
>>>  
>>>  
>>>  
>>>  
>>>
>>> Note that the property names do not have to be the same as the
>>> @parameter expression="${myplugin.greeting}"  style
>>> default properties you specified in your mojo, but usually you would
>>> keep them the same... unless you are relying on those properties for
>>> the lifecycle-invoked goals
>>>
>>> -Stephen
>>>
>>> On 14 April 2011 10:28, amaresh mourya  wrote:

 Hi All,

 I have a POM which has a plugin. I have configured it to use some
>>>
>>> specific

 settings at the time of command line invocation of the goal. I set these
 configurations in execution ID as "default-cli".

 This MyPlugins:hiPlugin:1.0:hi goals just prints the output in format of
>>>
>>> :

 ${person} says ${greetings}
 When I ran goal (MyPlugins:hiPlugin:1.0:hi) on command line I got the
 expected output that was : "Chandan says Welcome"
 But My question is why am I not able to override these configurations
>>>
>>> from

 command line, I wanted to run goal with parameter
>>>
>>> (MyPlugins:hiPlugin:1.0:hi

 -Dperson=Vishal) to get the output as "Vishal says Welcome". But I am
>>>
>>> still

 getting output "Chandan says Welcome".

 Here is my POM.

 http://maven.apache.org/POM/4.0.0";>
    4.0.0
    Application6
    mavenProj
    1.0-SNAPSHOT
    Project for mavenProj
    
        
         
                MyPlugins
                hiPlugin
                1.0
                
                    
                       default-cli
                        
                            hi
                        
                         
                             welcome
                             chandan
                        
                    
                
            
        
    
 
 
 
 


 Thanks,
 Amaresh

>>>
>>
>
> -

Re: same proyects running under java 1.4 and java 1.5

[Anders Hammar]

How are you executing one build run that produces both artifacts? Are you
really deploying to a repository? I can't see how that would work, but I
could be missing something.

/Anders

On Thu, Apr 14, 2011 at 12:00, Jörg Schaible wrote:

> Hi Anders,
>
> Anders Hammar wrote:
>
> > I strongly recommend staying away from profiles (and having multiple
> > artifacts being produced by one Maven project). Sooner or later it will
> > bit you. Also, in a true Maven build, you only do one build (including
> > deploying to the repository) and therefore having different profiles
> being
> > activated based on the JDK the build is being done with doesn't fit well
> > (IMHO).
>
> this is the whole point: You don't have different dependecies, but
> different
> version numbers, therefore the profiles don't harm here. In the end it is
> not different of specifying a version in the depMgmt section to select a
> specific version.
>
> > Go with different modules!
>
> In this special case, I cannot recommend it.
>
> - Jörg
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: overriding goal's configuration from command line?

[Tim Kettler]

Hi,

you can look that up in the documentation of the goal [1]. If an 
expression is defined for a parameter that is what you can use as a 
property on the commandline. In your example: -Dmaven.compiler.source=1.5


-Tim

[1] http://maven.apache.org/plugins/maven-compiler-plugin/compile-mojo.html

Am 14.04.2011 12:16, schrieb amaresh mourya:

Hi,

How do I override compiler source to be used If I run mvn compiler:compile
from the command line.

Compiler:compile goal has parameter called source. Doesn't that mean If I
run
[ mvn compiler:compile -Dsource=1.5 ] it should use 1.5 instead of 1.6?

My POM is like :


http://maven.apache.org/POM/4.0.0";>
 4.0.0
 Application6
 mavenProj
 1.0-SNAPSHOT
 Project for mavenProj
 
 
 
 org.apache.maven.plugins
 maven-compiler-plugin
 2.0.2
 
 1.6
 1.6
 
 
   




thanks
--Amaresh

On Thu, Apr 14, 2011 at 3:22 PM, Stephen Connolly<
stephen.alan.conno...@gmail.com>  wrote:


what you can do in that case is define properties in the pom and use
those properties to define the default-cli values.

properties set via the CLI override properties declared in the POM.

  http://maven.apache.org/POM/4.0.0";>
 4.0.0
 Application6
 mavenProj
 1.0-SNAPSHOT
 Project for mavenProj
 
welcome
chandan
 
 
 
  
 MyPlugins
 hiPlugin
 1.0
 
 
default-cli
 
 hi
 
  
  ${greetings}
  ${person}
 
 
 
 
 
 
  
  
  
  

Note that the property names do not have to be the same as the
@parameter expression="${myplugin.greeting}"  style
default properties you specified in your mojo, but usually you would
keep them the same... unless you are relying on those properties for
the lifecycle-invoked goals

-Stephen

On 14 April 2011 10:28, amaresh mourya  wrote:

Hi All,

I have a POM which has a plugin. I have configured it to use some

specific

settings at the time of command line invocation of the goal. I set these
configurations in execution ID as "default-cli".

This MyPlugins:hiPlugin:1.0:hi goals just prints the output in format of

:

${person} says ${greetings}
When I ran goal (MyPlugins:hiPlugin:1.0:hi) on command line I got the
expected output that was : "Chandan says Welcome"
But My question is why am I not able to override these configurations

from

command line, I wanted to run goal with parameter

(MyPlugins:hiPlugin:1.0:hi

-Dperson=Vishal) to get the output as "Vishal says Welcome". But I am

still

getting output "Chandan says Welcome".

Here is my POM.

http://maven.apache.org/POM/4.0.0";>
4.0.0
Application6
mavenProj
1.0-SNAPSHOT
Project for mavenProj


 
MyPlugins
hiPlugin
1.0


   default-cli

hi

 
 welcome
 chandan












Thanks,
Amaresh







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

Re: overriding goal's configuration from command line?

[amaresh mourya]

Hi,

How do I override compiler source to be used If I run mvn compiler:compile
from the command line.

Compiler:compile goal has parameter called source. Doesn't that mean If I
run
[ mvn compiler:compile -Dsource=1.5 ] it should use 1.5 instead of 1.6?

My POM is like :


http://maven.apache.org/POM/4.0.0";>
4.0.0
Application6
mavenProj
1.0-SNAPSHOT
Project for mavenProj



org.apache.maven.plugins
maven-compiler-plugin
2.0.2

1.6
1.6


  
   



thanks
--Amaresh

On Thu, Apr 14, 2011 at 3:22 PM, Stephen Connolly <
stephen.alan.conno...@gmail.com> wrote:

> what you can do in that case is define properties in the pom and use
> those properties to define the default-cli values.
>
> properties set via the CLI override properties declared in the POM.
>
>  http://maven.apache.org/POM/4.0.0";>
> 4.0.0
> Application6
> mavenProj
> 1.0-SNAPSHOT
> Project for mavenProj
> 
>welcome
>chandan
> 
> 
> 
>  
> MyPlugins
> hiPlugin
> 1.0
> 
> 
>default-cli
> 
> hi
> 
>  
>  ${greetings}
>  ${person}
> 
> 
> 
> 
> 
> 
>  
>  
>  
>  
>
> Note that the property names do not have to be the same as the
> @parameter expression="${myplugin.greeting}" style
> default properties you specified in your mojo, but usually you would
> keep them the same... unless you are relying on those properties for
> the lifecycle-invoked goals
>
> -Stephen
>
> On 14 April 2011 10:28, amaresh mourya  wrote:
> > Hi All,
> >
> > I have a POM which has a plugin. I have configured it to use some
> specific
> > settings at the time of command line invocation of the goal. I set these
> > configurations in execution ID as "default-cli".
> >
> > This MyPlugins:hiPlugin:1.0:hi goals just prints the output in format of
> :
> > ${person} says ${greetings}
> > When I ran goal (MyPlugins:hiPlugin:1.0:hi) on command line I got the
> > expected output that was : "Chandan says Welcome"
> > But My question is why am I not able to override these configurations
> from
> > command line, I wanted to run goal with parameter
> (MyPlugins:hiPlugin:1.0:hi
> > -Dperson=Vishal) to get the output as "Vishal says Welcome". But I am
> still
> > getting output "Chandan says Welcome".
> >
> > Here is my POM.
> >
> > http://maven.apache.org/POM/4.0.0";>
> >4.0.0
> >Application6
> >mavenProj
> >1.0-SNAPSHOT
> >Project for mavenProj
> >
> >
> > 
> >MyPlugins
> >hiPlugin
> >1.0
> >
> >
> >   default-cli
> >
> >hi
> >
> > 
> > welcome
> > chandan
> >
> >
> >
> >
> >
> >
> > 
> > 
> > 
> > 
> >
> >
> > Thanks,
> > Amaresh
> >
>

Re: same proyects running under java 1.4 and java 1.5

[Jörg Schaible]

Hi Anders,

Anders Hammar wrote:

> I strongly recommend staying away from profiles (and having multiple
> artifacts being produced by one Maven project). Sooner or later it will
> bit you. Also, in a true Maven build, you only do one build (including
> deploying to the repository) and therefore having different profiles being
> activated based on the JDK the build is being done with doesn't fit well
> (IMHO).

this is the whole point: You don't have different dependecies, but different 
version numbers, therefore the profiles don't harm here. In the end it is 
not different of specifying a version in the depMgmt section to select a 
specific version.

> Go with different modules!

In this special case, I cannot recommend it.

- Jörg


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

Re: Expected implementation date for Maven MIXIN Feature

[Stephen Connolly]

If the plugins are orthogonal to the module types then just bung it
all in the root pluginManagement and be done with it.

I am assuming that you have a non-orthogonal case though. In the
non-orthogonal case you could stop having inheritance follow
aggregation. it would mean some duplication in the child poms (need to
specify /project/version, /project/url, /project/scm,
/project/distributionManagement/site) and you'd probably want to add
to /project/dependencyManagement/dependencies


  aggregation-parent-groupId
  aggregation-parent-artifactId
  ${project.version} 
  pom
  import


So that the aggregation can enforce dependency management on all its
child modules.

That's about the closest you can get to the MIXIN proposal today.

-Stephen

On 14 April 2011 10:50, Bock, Richard (NSN - DE/Munich)
 wrote:
> Hi Anders,
>
> Thanks for your clarifications. I try get the wordings right. But what
> are you actually suggesting? I mean stay away from profiles. Yeah. But
> what to use instead? Modules will not work as I am actually already
> using them. I need modules that have an aggregation parent and still get
> some model type specific configuration (plugins e.g. that are always
> same for a certain module type).
>
> Currently using profiles and  is only a
> workaround. I am still curious to get a reply from some Maven
> contributor on whether this problem can be solved with MIXIN and when
> MIXIN will be available.
>
> Using profiles in this manner has the advantage that all module pom
> files are using the traditional aggregation parent but do not contain
> any redundant plugin configurations that are related to the module type
> (e.g. modeling project, java implementation project, web service project
> and so on)
>
> /Richard
>
>
> -Original Message-
> From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On
> Behalf Of ext Anders Hammar
> Sent: Thursday, April 14, 2011 11:09 AM
> To: Maven Users List
> Subject: Re: Expected implementation date for Maven MIXIN Feature
>
> Please, don't call it a super-pom. There is only one (and will only be
> just
> one) super-POM and it lives in Maven core. What you are talking about is
> a
> parent-pom and should be called that.
>
> Also, you're talking about archetypes which is something completely
> different from "artifacts" which I believe you're referring to. Please
> pay
> attention to the wording as it makes it easier for other people to
> understand what you're explaining.
>
> As you've noticed, the actual profile isn't inherited but rather the
> effect
> of the profile. One of those tricky things with profiles but that's by
> design. The simplest thing is to try staying away from profiles all
> together
> as they very often trick you into doing something which isn't the Maven
> Way..
>
> /Anders
>
> On Wed, Apr 13, 2011 at 20:32, Bock, Richard (NSN - DE/Munich) <
> richard.b...@nsn.com> wrote:
>
>> Today I found a workaround which is somehow not optional but keeps me
>> alive.
>>
>> All the base artifact types of a certain platform type will be put
> into a
>> super-pom for that platform type. E.g. jee-super-pom. Each artifact
> base
>> type plugin and properties is encapsulated into a Profile. The profile
> is
>> activated by a file that exists in the child project.
>>
>> Now the aggregator project myapp-pom can inherit from the
> jee-super.pom.
>>
>> Each module module-pom will have a file e.g. javalib-architype,
>> groovylib-architype, basemodel-architype, testimpl-architype. This
> will
>> activate the base architype profiles.
>>
>> Drawback is that this leaves the module-pom projects with funny empty
>> marker files in the project folder and the files cannot be looked up
> in the
>> repository as they are no architypes.
>>
>> What I find rather annoying is that even the activiation condition
> based on
>> properties will not work as the parent profiles will only be triggered
> by
>> parent properties and not by properties defined in the module-pom.
>>
>> So I just hope someday or earlier then later someone will add a
> feature to
>> Maven to resolved the parent properties, then the child properties and
> then
>> start resolving the profiles only.
>>
>> Or let us keep the hope up some one delivers the MIXIN feature.
>>
>> /Richard
>>
>>
>> -Original Message-
>> From: ext Wayne Fay [mailto:wayne...@gmail.com]
>> Sent: Wednesday, April 13, 2011 8:19 PM
>> To: Maven Users List
>> Subject: Re: Expected implementation date for Maven MIXIN Feature
>>
>> > AM gets the version from A through the parent relationship.
>> > AM gets the plugin sce.model from the MIXIN relationship to M.
>> >
>> > AI gets the version from A through the parent relationship.
>> > AI gets the plugin sce.compile from the MIXIN relationship to I.
>>
>> Sounds roughly like composition of objects/projects in the POM, is
>> that about right? I haven't really been following any discussion of
>> Mixins previously.
>>
>> Wayne
>>
>> -

Re: overriding goal's configuration from command line?

[Stephen Connolly]

what you can do in that case is define properties in the pom and use
those properties to define the default-cli values.

properties set via the CLI override properties declared in the POM.

 http://maven.apache.org/POM/4.0.0";>
    4.0.0
    Application6
    mavenProj
    1.0-SNAPSHOT
    Project for mavenProj

       welcome
       chandan

    
        
         
                MyPlugins
                hiPlugin
                1.0
                
                    
                       default-cli
                        
                            hi
                        
                         
                             ${greetings}
                             ${person}
                        
                    
                
            
        
    
 
 
 
 

Note that the property names do not have to be the same as the
@parameter expression="${myplugin.greeting}" style
default properties you specified in your mojo, but usually you would
keep them the same... unless you are relying on those properties for
the lifecycle-invoked goals

-Stephen

On 14 April 2011 10:28, amaresh mourya  wrote:
> Hi All,
>
> I have a POM which has a plugin. I have configured it to use some specific
> settings at the time of command line invocation of the goal. I set these
> configurations in execution ID as "default-cli".
>
> This MyPlugins:hiPlugin:1.0:hi goals just prints the output in format of :
> ${person} says ${greetings}
> When I ran goal (MyPlugins:hiPlugin:1.0:hi) on command line I got the
> expected output that was : "Chandan says Welcome"
> But My question is why am I not able to override these configurations from
> command line, I wanted to run goal with parameter (MyPlugins:hiPlugin:1.0:hi
> -Dperson=Vishal) to get the output as "Vishal says Welcome". But I am still
> getting output "Chandan says Welcome".
>
> Here is my POM.
>
> http://maven.apache.org/POM/4.0.0";>
>    4.0.0
>    Application6
>    mavenProj
>    1.0-SNAPSHOT
>    Project for mavenProj
>    
>        
>         
>                MyPlugins
>                hiPlugin
>                1.0
>                
>                    
>                       default-cli
>                        
>                            hi
>                        
>                         
>                             welcome
>                             chandan
>                        
>                    
>                
>            
>        
>    
> 
> 
> 
> 
>
>
> Thanks,
> Amaresh
>

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

RE: Expected implementation date for Maven MIXIN Feature

[Bock, Richard (NSN - DE/Munich)]

Hi Anders,

Thanks for your clarifications. I try get the wordings right. But what
are you actually suggesting? I mean stay away from profiles. Yeah. But
what to use instead? Modules will not work as I am actually already
using them. I need modules that have an aggregation parent and still get
some model type specific configuration (plugins e.g. that are always
same for a certain module type).

Currently using profiles and  is only a
workaround. I am still curious to get a reply from some Maven
contributor on whether this problem can be solved with MIXIN and when
MIXIN will be available.

Using profiles in this manner has the advantage that all module pom
files are using the traditional aggregation parent but do not contain
any redundant plugin configurations that are related to the module type
(e.g. modeling project, java implementation project, web service project
and so on)

/Richard


-Original Message-
From: anders.g.ham...@gmail.com [mailto:anders.g.ham...@gmail.com] On
Behalf Of ext Anders Hammar
Sent: Thursday, April 14, 2011 11:09 AM
To: Maven Users List
Subject: Re: Expected implementation date for Maven MIXIN Feature

Please, don't call it a super-pom. There is only one (and will only be
just
one) super-POM and it lives in Maven core. What you are talking about is
a
parent-pom and should be called that.

Also, you're talking about archetypes which is something completely
different from "artifacts" which I believe you're referring to. Please
pay
attention to the wording as it makes it easier for other people to
understand what you're explaining.

As you've noticed, the actual profile isn't inherited but rather the
effect
of the profile. One of those tricky things with profiles but that's by
design. The simplest thing is to try staying away from profiles all
together
as they very often trick you into doing something which isn't the Maven
Way..

/Anders

On Wed, Apr 13, 2011 at 20:32, Bock, Richard (NSN - DE/Munich) <
richard.b...@nsn.com> wrote:

> Today I found a workaround which is somehow not optional but keeps me
> alive.
>
> All the base artifact types of a certain platform type will be put
into a
> super-pom for that platform type. E.g. jee-super-pom. Each artifact
base
> type plugin and properties is encapsulated into a Profile. The profile
is
> activated by a file that exists in the child project.
>
> Now the aggregator project myapp-pom can inherit from the
jee-super.pom.
>
> Each module module-pom will have a file e.g. javalib-architype,
> groovylib-architype, basemodel-architype, testimpl-architype. This
will
> activate the base architype profiles.
>
> Drawback is that this leaves the module-pom projects with funny empty
> marker files in the project folder and the files cannot be looked up
in the
> repository as they are no architypes.
>
> What I find rather annoying is that even the activiation condition
based on
> properties will not work as the parent profiles will only be triggered
by
> parent properties and not by properties defined in the module-pom.
>
> So I just hope someday or earlier then later someone will add a
feature to
> Maven to resolved the parent properties, then the child properties and
then
> start resolving the profiles only.
>
> Or let us keep the hope up some one delivers the MIXIN feature.
>
> /Richard
>
>
> -Original Message-
> From: ext Wayne Fay [mailto:wayne...@gmail.com]
> Sent: Wednesday, April 13, 2011 8:19 PM
> To: Maven Users List
> Subject: Re: Expected implementation date for Maven MIXIN Feature
>
> > AM gets the version from A through the parent relationship.
> > AM gets the plugin sce.model from the MIXIN relationship to M.
> >
> > AI gets the version from A through the parent relationship.
> > AI gets the plugin sce.compile from the MIXIN relationship to I.
>
> Sounds roughly like composition of objects/projects in the POM, is
> that about right? I haven't really been following any discussion of
> Mixins previously.
>
> Wayne
>
> -
> 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

overriding goal's configuration from command line?

[amaresh mourya]

Hi All,

I have a POM which has a plugin. I have configured it to use some specific
settings at the time of command line invocation of the goal. I set these
configurations in execution ID as "default-cli".

This MyPlugins:hiPlugin:1.0:hi goals just prints the output in format of :
${person} says ${greetings}
When I ran goal (MyPlugins:hiPlugin:1.0:hi) on command line I got the
expected output that was : "Chandan says Welcome"
But My question is why am I not able to override these configurations from
command line, I wanted to run goal with parameter (MyPlugins:hiPlugin:1.0:hi
-Dperson=Vishal) to get the output as "Vishal says Welcome". But I am still
getting output "Chandan says Welcome".

Here is my POM.

http://maven.apache.org/POM/4.0.0";>
4.0.0
Application6
mavenProj
1.0-SNAPSHOT
Project for mavenProj


 
MyPlugins
hiPlugin
1.0


   default-cli

hi

 
 welcome
 chandan












Thanks,
Amaresh

Re: same proyects running under java 1.4 and java 1.5

[Anders Hammar]

I strongly recommend staying away from profiles (and having multiple
artifacts being produced by one Maven project). Sooner or later it will bit
you. Also, in a true Maven build, you only do one build (including deploying
to the repository) and therefore having different profiles being activated
based on the JDK the build is being done with doesn't fit well (IMHO).
Go with different modules!

/Anders

On Wed, Apr 13, 2011 at 18:31, Jörg Schaible  wrote:

> Hi,
>
> Fernando Wermus wrote:
>
> > Hi all,
> > We have a proyect which we need to compile under java 1.4 for some
> > companies and 1.6 for other companies. The problem is that in java 1.6 we
> > have a class that implements an interface named ResulSet. Result changes
> > its methods from 1.4 to 1.6 because jdbc changes. Then we need to have an
> > implementation of Resulset for java 1.4 and another impl for java 1.6.
> > What we need is to add to our currents profiles a way to include or
> > exclude some class in the proyect with the same package and class name.
> >
> > Is any solution from maven for this problem?
> >
> > thanks in advance and I hope you have understood our problem.
>
> This is how we did it:
>
> 1/ Use two independent version lines i.e. do it like Apache commons dbcp
> where version 1.3.x is for JDBC 3 (Java 5 or lower) and version 1.4.x is
> for
> JDBC 4 (Java 6).
>
> 2/ Use comment markers in your Java code, see following snippet:
>
> = %< =
> /*JDBC4**/
> import java.sql.NClob;
> import java.sql.RowId;
> import java.sql.SQLXML;
> //*JDBC4*/
> = %< =
>
> All types and methods that are only available for JDBC 4 are surrounded
> with
> those two markers i.e. the code is compilable from your IDE with Java 6 as
> usual.
>
> 3/ Prepare the POM to modify the source using a profile based on the target
> JDK.
>
> The trick is to use the original source that compiles against JDBC 4 and
> filter it (resp. generate new sources) with a regular expression that uses
> those two markers to create Java block comments and let the compiler use
> the
> new sources then.
>
> === %< ===
> ...
>  your.company
>  your.artifact
>  ${version.your.artifact}
> ...
>  
>${local.source.directory}
>  
> ...
>  
>
>  jdk15
>  
>1.5
>  
>  
>
>  
>your.company
>regexp-plugin
>
>  
>filter-jdbc4
>generate-sources
>
>  perform
>
>  
>
>
>  
>${basedir}/src/main/java
>${basedir}/target/generated-
> sources/java
>   
>  
>/\*JDBC4\*\*/
>/*JDBC4
>  
>  
>//\*JDBC4\*/
>JDBC4*/
>  
>
>  
>
>  
>
>  
>  
>target/generated-
> sources/java
>  
>
>  
> ...
>  
>src/main/java
>  
> === %< ===
>
> The property "version.your.artifact" is defined in the parent and the
> artifact is also declared there in a depMgmt section:
>
> === %< ===
> ...
>  
>
>  
>your.company
>your.artifact
>${version.your.artifact}
>  
>
>  
> ...
>  
>
>  jdk15
>  
>1.5
>  
>  
>1.6.0-SNAPSHOT
>  
>
>  
> ...
>  
>1.5.0-SNAPSHOT
>  
> === %< ===
>
> Now, the plugin we use for the regexp fitlering is not publicly available,
> but if you look at Apache dbcp, it is done there with an Ant task and you
> should be able to to similar with the antrun plugin. I've also seen once
> that plexus-utils have capabilities for regexp filtering, but I don't know
> if there's any syntax to activate this for standard Maven filtering. OTOH
> it
> is really easy to write such a simply plugin yourself ;-)
>
> Note, we used the current JDK for profile activation i.e. it depends on the
> Java version we use to run Maven itself. This might not be appropriate, you
> will have to define different activations then.
>
> Hope this gives you some ideas,
> Jörg
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: Expected implementation date for Maven MIXIN Feature

[Anders Hammar]

Please, don't call it a super-pom. There is only one (and will only be just
one) super-POM and it lives in Maven core. What you are talking about is a
parent-pom and should be called that.

Also, you're talking about archetypes which is something completely
different from "artifacts" which I believe you're referring to. Please pay
attention to the wording as it makes it easier for other people to
understand what you're explaining.

As you've noticed, the actual profile isn't inherited but rather the effect
of the profile. One of those tricky things with profiles but that's by
design. The simplest thing is to try staying away from profiles all together
as they very often trick you into doing something which isn't the Maven
Way..

/Anders

On Wed, Apr 13, 2011 at 20:32, Bock, Richard (NSN - DE/Munich) <
richard.b...@nsn.com> wrote:

> Today I found a workaround which is somehow not optional but keeps me
> alive.
>
> All the base artifact types of a certain platform type will be put into a
> super-pom for that platform type. E.g. jee-super-pom. Each artifact base
> type plugin and properties is encapsulated into a Profile. The profile is
> activated by a file that exists in the child project.
>
> Now the aggregator project myapp-pom can inherit from the jee-super.pom.
>
> Each module module-pom will have a file e.g. javalib-architype,
> groovylib-architype, basemodel-architype, testimpl-architype. This will
> activate the base architype profiles.
>
> Drawback is that this leaves the module-pom projects with funny empty
> marker files in the project folder and the files cannot be looked up in the
> repository as they are no architypes.
>
> What I find rather annoying is that even the activiation condition based on
> properties will not work as the parent profiles will only be triggered by
> parent properties and not by properties defined in the module-pom.
>
> So I just hope someday or earlier then later someone will add a feature to
> Maven to resolved the parent properties, then the child properties and then
> start resolving the profiles only.
>
> Or let us keep the hope up some one delivers the MIXIN feature.
>
> /Richard
>
>
> -Original Message-
> From: ext Wayne Fay [mailto:wayne...@gmail.com]
> Sent: Wednesday, April 13, 2011 8:19 PM
> To: Maven Users List
> Subject: Re: Expected implementation date for Maven MIXIN Feature
>
> > AM gets the version from A through the parent relationship.
> > AM gets the plugin sce.model from the MIXIN relationship to M.
> >
> > AI gets the version from A through the parent relationship.
> > AI gets the plugin sce.compile from the MIXIN relationship to I.
>
> Sounds roughly like composition of objects/projects in the POM, is
> that about right? I haven't really been following any discussion of
> Mixins previously.
>
> Wayne
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: maven-3.0.2 + maven-site-plugin-3.0-beta-3 + multi module projects (can't resolve module dependencies)

[Lukas Theussl]

I'm not sure I follow you, why do you say a workaround is to go back to 
maven 2? MSITE-171 was opened against site-plugin-2.0-beta-5, as I said, 
it's an old issue that's been there forever AFAIK.


-Lukas


Andrew Hughes wrote:

Update,

I tried to back this out to maven2 and a collection of old plugins, but I
still can't get it working. Everything I try fails for this reason or
something else telling me to update my plugins. I even totally re-created
new project/modules in an effort to fix this. I'm totally stumped with this
and starting to wonder if I am on a wild goose chase :'(




On Thu, Apr 14, 2011 at 9:14 AM, Andrew Hughes  wrote:


Lukas,

Thanks for the answer. Unless I can fix this myself I had better shut up
about it. I guess the workaround here is to stay on maven 2 for the time
being (note that the pom  sections are different in m2 and m3
pom.xml's ).

Thanks for the info.


Steve,

That's a really good point and a big "gotcha" for anyone trying to release
their project. Seems like m2 might be the only proper workaround to this (if
you really do want sites). In addition to this... a little off topic but
quite relevant to what you have said. I'm a big fan of sites, but I believe
site-deploy shouldn't be a goal that is run during a release. This is
because the site can be re-built and deployed anytime you want (post
release). It's convenient to have these run together, but let's say a
password has expired or the site's url host is turned off, or network
problems - I think it adds unnecessary risk to a release. Consequently we
turned this off...




org.apache.maven.plugins


maven-release-plugin






deploy






I have a different opinion on this. I am a big fan of maven site's however
I don't believe that if something fails during


On Wed, Apr 13, 2011 at 5:09 PM, Stevo Slavić  wrote:


I'm also affected by this issue, when releasing project using
maven-release-plugin, prepare goes well, perform fails as it detects
site in distributionManagement and default goals run are "deploy
site-deploy" so maven tries to generate and deploy site, but since
site plugin tries to resolve something that's not installed/deployed
yet, release:perform fails.

One workaround could be to configure prepare mojo's

http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html#preparationGoals
to be "clean install" instead of default "clean verify", install is
after verify, if verification fails install will not be performed, if
verification is successful install will be performed and artifacts
will be available in local repository, so as long as release:perform
is run on same node/machine by same user as release:prepare, site
should be generated and deployed; deploy will install/overwrite
artifacts again in local repo and deploy them to remote repo.

Regards,
Stevo.

On Wed, Apr 13, 2011 at 9:17 AM, Lukas Theussl
wrote:


That's an old issue, see http://jira.codehaus.org/browse/MSITE-171 and
related tickets.

-Lukas


Andrew Hughes wrote:


Hi All,

Before each of the following test, I delete my project/module artifacts
from
my local repo

The following works :)

*mvn clean install *
*mvn site*


The following fails :(

*mvn clean install site*


The following also fails :(

*mvn clean install site:site*


The error I consistently get is:

[ERROR] Failed to execute goal
org.apache.maven.plugins:maven-site-plugin:3.0-beta-3:site

(default-site)

on
project acme-project: failed to get Reports: Failed to execute goal on
project acme-project-d: Could not resolve dependencies for project
com.acme.project:acme-project-module-d:ejb:5.1.0-SNAPSHOT: *Could not

find

artifact com.acme.project:acme-project-module-a:jar:5.1.0-SNAPSHOT* in
archiva (http://acme.com/repository/all/) ->   [Help 1]

...site appears to be running on the incorrect phase or build

lifecycle.

Consequently, the (module) dependencies have not been install/deployed

to

my
local repository yet.

Any idea's how I can fix this???

Cheers.



-
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








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

Re: aggregator module includes its own parent as a sub-module

[Andreas Sewe]

Hi Oleg:

Simple tests show that maven will accept such a project without any 
errors or even warnings, but I would like to know whether this kind of 
circular "parent"-"aggregator" dependency is bad.

Any opinions why this should not be done?


Not when it comes to the build itself, not. When it comes to site 
generation, however, expect "inconsistencies" between the modules menu 
and the breadcrumbs. The former will show the parent as a module of the 
aggregator while the latter will show a trail like parent > aggregator. 
While technically correct (from a Maven point of view), this is probably 
something your site's users won't expect. (I have raised an issue about 
this: .)


Just something to keep in mind.

Andreas

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