Re: import plugin configurations

[Marcos Mendez]

thanks. i've done the dependency mgmt stuff. works fine and with a main import. 
we actually have the poms set pretty much the way you describe. but we have a 
lot of projects (diff repos and builds) and we need to change them all 
correctly to update standard things which is not good. gonna tinker a little 
bit more...

On Jan 4, 2013, at 18:14, Ansgar Konermann  
wrote:

> Suggestions:
> 
> Dependency management: a small number of poms. In the beginning: could be
> one pom.
> 
> Build behaviour: a small number of parent poms. One for each type of
> artifact you're going to produce. Say: JAR, WAR. Maybe one common parent
> where you define plugin versions and build behaviour which is really the
> same for all your artifacts.
> 
> Hint: plugin management can use properties which are "undefined" in the
> parent pom. You can define their values in the inheriting module's pom.
> Think OOP: parent pom can define abstract/parameterized behaviour,
> inheriting pom defines abstract parts of behaviour.
> 
> Put dependencies of each module into that module. Reduce number of
> dependencies as much as possible. Don't depend on, say, a JAR, just because
> all your other modules do that too.
> 
> If this does not work for you, let us know the detailed "why".
> Am 04.01.2013 23:42 schrieb "Marcos Mendez" :
> 
>> ok what us the maven way? if it is to have the same parent then it will
>> not work for me. conventions are fine until they impede.
>> 
>> On Jan 4, 2013, at 17:38, Anders Hammar  wrote:
>> 
>>> I seriously doubt it is possible. And even if it was, it's the wrong way
>> to
>>> go as there is already a standard way to handle it in Maven. And Maven is
>>> all about conventions and not inventing your own solution.
>>> 
>>> /Anders
>>> 
>>> 
>>> On Fri, Jan 4, 2013 at 11:35 PM, Ansgar Konermann <
>>> ansgar.konerm...@googlemail.com> wrote:
>>> 
 If you really do, please discuss your approach here on the mailing list.
 
 I'm sure it will be useful for others, too.
 Am 04.01.2013 23:11 schrieb "Marcos Mendez" :
 
> thanks. i'll see if i can create a plugin to do it then.
> 
> On Jan 4, 2013, at 16:38, Anders Hammar  wrote:
> 
>>> I actually do mean super pom.
>> 
>> 
>> No, you don't. What you're talking about is something often called a
 BOM
>> (bill of material) or maybe an import-pom.
>> 
>> 
>>> We have multiple projects that have similar configurations,
> dependencies,
>>> plugins, etc.  I don't want to have them repeated each time and they
> will
>>> not have the same parent - it is not feasible. I've used the import
> scope
>>> for setting dependency versions (e.g. dependency management) in one
> place
>>> and that worked ok. Has anyone tried to do this for plugins
> configurations
>>> as well?
>> 
>> It only works for depMgmt. PluginMgmt you need to inherit from a
> parent-pom.
>> 
>> /Anders
>> 
>> 
>>> 
>>> 
>>> On Jan 4, 2013, at 4:09 PM, Anders Hammar wrote:
>>> 
 First, there is only one "super-POM" and that one is included in
 Maven
 itself. What you probably mean is a "parent pom".
 
 To use that parent pom you declare it in the "parent" section, not
 as a
 import scope dependency.
 
 /Anders
 
 On Fri, Jan 4, 2013 at 10:00 PM, Marcos Mendez >> 
>>> wrote:
 
> 
> I've defined a superpom and I'm using the import scope in another
> maven
> project to apply those. I'm not seeing the configurations being
> applied
>>> for
> the plugins I've defined in the superpom's pluginManagement.
> 
> Any ideas?
> 
> Regards,
> Marcos
 -
> 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
>> 
>> -
>> 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

Maven versioning

[tc78]

I am currently working with a group that is migrating a group of applications
and libraries to Maven.  I can’t seem to find the best way to handle the POM
versioning so I thought I would bounce that off those of you with more
experience.  There are roughly 20 web apps and 10 libraries.  What I am
wondering is if I have a new version of a web app coming out, is it best to
bump up the version on the app’s pom.xml as well as the dependency poms’
versions or is it standard for each library to increment on its own.  Say
for instance I implement someApp 1.1 and I now need to have a bug fix for
someDependency.  Does that make the next deployed version of someApp 1.1.1
or does that just bump up the version of someDependency?

Most of the work I did previously with Maven was working with SNAPSHOTs so
after I am trying to wrap my head around the versioning management portion
of it.  


Thanks!



--
View this message in context: 
http://maven.40175.n5.nabble.com/Maven-versioning-tp5741895.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: import plugin configurations

[Ansgar Konermann]

Suggestions:

Dependency management: a small number of poms. In the beginning: could be
one pom.

Build behaviour: a small number of parent poms. One for each type of
artifact you're going to produce. Say: JAR, WAR. Maybe one common parent
where you define plugin versions and build behaviour which is really the
same for all your artifacts.

Hint: plugin management can use properties which are "undefined" in the
parent pom. You can define their values in the inheriting module's pom.
Think OOP: parent pom can define abstract/parameterized behaviour,
inheriting pom defines abstract parts of behaviour.

Put dependencies of each module into that module. Reduce number of
dependencies as much as possible. Don't depend on, say, a JAR, just because
all your other modules do that too.

If this does not work for you, let us know the detailed "why".
Am 04.01.2013 23:42 schrieb "Marcos Mendez" :

> ok what us the maven way? if it is to have the same parent then it will
> not work for me. conventions are fine until they impede.
>
> On Jan 4, 2013, at 17:38, Anders Hammar  wrote:
>
> > I seriously doubt it is possible. And even if it was, it's the wrong way
> to
> > go as there is already a standard way to handle it in Maven. And Maven is
> > all about conventions and not inventing your own solution.
> >
> > /Anders
> >
> >
> > On Fri, Jan 4, 2013 at 11:35 PM, Ansgar Konermann <
> > ansgar.konerm...@googlemail.com> wrote:
> >
> >> If you really do, please discuss your approach here on the mailing list.
> >>
> >> I'm sure it will be useful for others, too.
> >> Am 04.01.2013 23:11 schrieb "Marcos Mendez" :
> >>
> >>> thanks. i'll see if i can create a plugin to do it then.
> >>>
> >>> On Jan 4, 2013, at 16:38, Anders Hammar  wrote:
> >>>
> > I actually do mean super pom.
> 
> 
>  No, you don't. What you're talking about is something often called a
> >> BOM
>  (bill of material) or maybe an import-pom.
> 
> 
> > We have multiple projects that have similar configurations,
> >>> dependencies,
> > plugins, etc.  I don't want to have them repeated each time and they
> >>> will
> > not have the same parent - it is not feasible. I've used the import
> >>> scope
> > for setting dependency versions (e.g. dependency management) in one
> >>> place
> > and that worked ok. Has anyone tried to do this for plugins
> >>> configurations
> > as well?
> 
>  It only works for depMgmt. PluginMgmt you need to inherit from a
> >>> parent-pom.
> 
>  /Anders
> 
> 
> >
> >
> > On Jan 4, 2013, at 4:09 PM, Anders Hammar wrote:
> >
> >> First, there is only one "super-POM" and that one is included in
> >> Maven
> >> itself. What you probably mean is a "parent pom".
> >>
> >> To use that parent pom you declare it in the "parent" section, not
> >> as a
> >> import scope dependency.
> >>
> >> /Anders
> >>
> >> On Fri, Jan 4, 2013 at 10:00 PM, Marcos Mendez  >
> > wrote:
> >>
> >>>
> >>> I've defined a superpom and I'm using the import scope in another
> >>> maven
> >>> project to apply those. I'm not seeing the configurations being
> >>> applied
> > for
> >>> the plugins I've defined in the superpom's pluginManagement.
> >>>
> >>> Any ideas?
> >>>
> >>> Regards,
> >>> Marcos
> >> -
> >>> 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
> >>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

Re: import plugin configurations

[Marcos Mendez]

ok what us the maven way? if it is to have the same parent then it will not 
work for me. conventions are fine until they impede.

On Jan 4, 2013, at 17:38, Anders Hammar  wrote:

> I seriously doubt it is possible. And even if it was, it's the wrong way to
> go as there is already a standard way to handle it in Maven. And Maven is
> all about conventions and not inventing your own solution.
> 
> /Anders
> 
> 
> On Fri, Jan 4, 2013 at 11:35 PM, Ansgar Konermann <
> ansgar.konerm...@googlemail.com> wrote:
> 
>> If you really do, please discuss your approach here on the mailing list.
>> 
>> I'm sure it will be useful for others, too.
>> Am 04.01.2013 23:11 schrieb "Marcos Mendez" :
>> 
>>> thanks. i'll see if i can create a plugin to do it then.
>>> 
>>> On Jan 4, 2013, at 16:38, Anders Hammar  wrote:
>>> 
> I actually do mean super pom.
 
 
 No, you don't. What you're talking about is something often called a
>> BOM
 (bill of material) or maybe an import-pom.
 
 
> We have multiple projects that have similar configurations,
>>> dependencies,
> plugins, etc.  I don't want to have them repeated each time and they
>>> will
> not have the same parent - it is not feasible. I've used the import
>>> scope
> for setting dependency versions (e.g. dependency management) in one
>>> place
> and that worked ok. Has anyone tried to do this for plugins
>>> configurations
> as well?
 
 It only works for depMgmt. PluginMgmt you need to inherit from a
>>> parent-pom.
 
 /Anders
 
 
> 
> 
> On Jan 4, 2013, at 4:09 PM, Anders Hammar wrote:
> 
>> First, there is only one "super-POM" and that one is included in
>> Maven
>> itself. What you probably mean is a "parent pom".
>> 
>> To use that parent pom you declare it in the "parent" section, not
>> as a
>> import scope dependency.
>> 
>> /Anders
>> 
>> On Fri, Jan 4, 2013 at 10:00 PM, Marcos Mendez 
> wrote:
>> 
>>> 
>>> I've defined a superpom and I'm using the import scope in another
>>> maven
>>> project to apply those. I'm not seeing the configurations being
>>> applied
> for
>>> the plugins I've defined in the superpom's pluginManagement.
>>> 
>>> Any ideas?
>>> 
>>> Regards,
>>> Marcos
>> -
>>> 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
>> 

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

Re: import plugin configurations

[Anders Hammar]

I seriously doubt it is possible. And even if it was, it's the wrong way to
go as there is already a standard way to handle it in Maven. And Maven is
all about conventions and not inventing your own solution.

/Anders


On Fri, Jan 4, 2013 at 11:35 PM, Ansgar Konermann <
ansgar.konerm...@googlemail.com> wrote:

> If you really do, please discuss your approach here on the mailing list.
>
> I'm sure it will be useful for others, too.
> Am 04.01.2013 23:11 schrieb "Marcos Mendez" :
>
> > thanks. i'll see if i can create a plugin to do it then.
> >
> > On Jan 4, 2013, at 16:38, Anders Hammar  wrote:
> >
> > >> I actually do mean super pom.
> > >
> > >
> > > No, you don't. What you're talking about is something often called a
> BOM
> > > (bill of material) or maybe an import-pom.
> > >
> > >
> > >> We have multiple projects that have similar configurations,
> > dependencies,
> > >> plugins, etc.  I don't want to have them repeated each time and they
> > will
> > >> not have the same parent - it is not feasible. I've used the import
> > scope
> > >> for setting dependency versions (e.g. dependency management) in one
> > place
> > >> and that worked ok. Has anyone tried to do this for plugins
> > configurations
> > >> as well?
> > >
> > > It only works for depMgmt. PluginMgmt you need to inherit from a
> > parent-pom.
> > >
> > > /Anders
> > >
> > >
> > >>
> > >>
> > >> On Jan 4, 2013, at 4:09 PM, Anders Hammar wrote:
> > >>
> > >>> First, there is only one "super-POM" and that one is included in
> Maven
> > >>> itself. What you probably mean is a "parent pom".
> > >>>
> > >>> To use that parent pom you declare it in the "parent" section, not
> as a
> > >>> import scope dependency.
> > >>>
> > >>> /Anders
> > >>>
> > >>> On Fri, Jan 4, 2013 at 10:00 PM, Marcos Mendez 
> > >> wrote:
> > >>>
> > 
> >  I've defined a superpom and I'm using the import scope in another
> > maven
> >  project to apply those. I'm not seeing the configurations being
> > applied
> > >> for
> >  the plugins I've defined in the superpom's pluginManagement.
> > 
> >  Any ideas?
> > 
> >  Regards,
> >  Marcos
> > 
> -
> >  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: import plugin configurations

[Ansgar Konermann]

If you really do, please discuss your approach here on the mailing list.

I'm sure it will be useful for others, too.
Am 04.01.2013 23:11 schrieb "Marcos Mendez" :

> thanks. i'll see if i can create a plugin to do it then.
>
> On Jan 4, 2013, at 16:38, Anders Hammar  wrote:
>
> >> I actually do mean super pom.
> >
> >
> > No, you don't. What you're talking about is something often called a BOM
> > (bill of material) or maybe an import-pom.
> >
> >
> >> We have multiple projects that have similar configurations,
> dependencies,
> >> plugins, etc.  I don't want to have them repeated each time and they
> will
> >> not have the same parent - it is not feasible. I've used the import
> scope
> >> for setting dependency versions (e.g. dependency management) in one
> place
> >> and that worked ok. Has anyone tried to do this for plugins
> configurations
> >> as well?
> >
> > It only works for depMgmt. PluginMgmt you need to inherit from a
> parent-pom.
> >
> > /Anders
> >
> >
> >>
> >>
> >> On Jan 4, 2013, at 4:09 PM, Anders Hammar wrote:
> >>
> >>> First, there is only one "super-POM" and that one is included in Maven
> >>> itself. What you probably mean is a "parent pom".
> >>>
> >>> To use that parent pom you declare it in the "parent" section, not as a
> >>> import scope dependency.
> >>>
> >>> /Anders
> >>>
> >>> On Fri, Jan 4, 2013 at 10:00 PM, Marcos Mendez 
> >> wrote:
> >>>
> 
>  I've defined a superpom and I'm using the import scope in another
> maven
>  project to apply those. I'm not seeing the configurations being
> applied
> >> for
>  the plugins I've defined in the superpom's pluginManagement.
> 
>  Any ideas?
> 
>  Regards,
>  Marcos
>  -
>  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: import plugin configurations

[Marcos Mendez]

thanks. i'll see if i can create a plugin to do it then.

On Jan 4, 2013, at 16:38, Anders Hammar  wrote:

>> I actually do mean super pom.
> 
> 
> No, you don't. What you're talking about is something often called a BOM
> (bill of material) or maybe an import-pom.
> 
> 
>> We have multiple projects that have similar configurations, dependencies,
>> plugins, etc.  I don't want to have them repeated each time and they will
>> not have the same parent - it is not feasible. I've used the import scope
>> for setting dependency versions (e.g. dependency management) in one place
>> and that worked ok. Has anyone tried to do this for plugins configurations
>> as well?
> 
> It only works for depMgmt. PluginMgmt you need to inherit from a parent-pom.
> 
> /Anders
> 
> 
>> 
>> 
>> On Jan 4, 2013, at 4:09 PM, Anders Hammar wrote:
>> 
>>> First, there is only one "super-POM" and that one is included in Maven
>>> itself. What you probably mean is a "parent pom".
>>> 
>>> To use that parent pom you declare it in the "parent" section, not as a
>>> import scope dependency.
>>> 
>>> /Anders
>>> 
>>> On Fri, Jan 4, 2013 at 10:00 PM, Marcos Mendez 
>> wrote:
>>> 
 
 I've defined a superpom and I'm using the import scope in another maven
 project to apply those. I'm not seeing the configurations being applied
>> for
 the plugins I've defined in the superpom's pluginManagement.
 
 Any ideas?
 
 Regards,
 Marcos
 -
 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: import plugin configurations

[Anders Hammar]

> I actually do mean super pom.


No, you don't. What you're talking about is something often called a BOM
(bill of material) or maybe an import-pom.


> We have multiple projects that have similar configurations, dependencies,
> plugins, etc.  I don't want to have them repeated each time and they will
> not have the same parent - it is not feasible. I've used the import scope
> for setting dependency versions (e.g. dependency management) in one place
> and that worked ok. Has anyone tried to do this for plugins configurations
> as well?
>

It only works for depMgmt. PluginMgmt you need to inherit from a parent-pom.

/Anders


>
>
> On Jan 4, 2013, at 4:09 PM, Anders Hammar wrote:
>
> > First, there is only one "super-POM" and that one is included in Maven
> > itself. What you probably mean is a "parent pom".
> >
> > To use that parent pom you declare it in the "parent" section, not as a
> > import scope dependency.
> >
> > /Anders
> >
> > On Fri, Jan 4, 2013 at 10:00 PM, Marcos Mendez 
> wrote:
> >
> >>
> >> I've defined a superpom and I'm using the import scope in another maven
> >> project to apply those. I'm not seeing the configurations being applied
> for
> >> the plugins I've defined in the superpom's pluginManagement.
> >>
> >> Any ideas?
> >>
> >> Regards,
> >> Marcos
> >> -
> >> 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: import plugin configurations

[Marcos Mendez]

I found this approach at 
http://weblogs.java.net/blog/fabriziogiudici/archive/2010/02/21/shrink-your-pom.
 Maybe the name is not correct, but I want a pom with most configurations that 
I can import from all my separate projects. Works for dependencies, though I 
have to define a separate process to actually import the properties from that 
pom. I just want to have the plugin configurations come from one place.

On Jan 4, 2013, at 4:25 PM, Marcos Mendez wrote:

> I actually do mean super pom. We have multiple projects that have similar 
> configurations, dependencies, plugins, etc.  I don't want to have them 
> repeated each time and they will not have the same parent - it is not 
> feasible. I've used the import scope for setting dependency versions (e.g. 
> dependency management) in one place and that worked ok. Has anyone tried to 
> do this for plugins configurations as well?
> 
> 
> On Jan 4, 2013, at 4:09 PM, Anders Hammar wrote:
> 
>> First, there is only one "super-POM" and that one is included in Maven
>> itself. What you probably mean is a "parent pom".
>> 
>> To use that parent pom you declare it in the "parent" section, not as a
>> import scope dependency.
>> 
>> /Anders
>> 
>> On Fri, Jan 4, 2013 at 10:00 PM, Marcos Mendez  wrote:
>> 
>>> 
>>> I've defined a superpom and I'm using the import scope in another maven
>>> project to apply those. I'm not seeing the configurations being applied for
>>> the plugins I've defined in the superpom's pluginManagement.
>>> 
>>> Any ideas?
>>> 
>>> Regards,
>>> Marcos
>>> -
>>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>>> For additional commands, e-mail: users-h...@maven.apache.org
>>> 
>>> 
> 

Re: import plugin configurations

[Marcos Mendez]

I actually do mean super pom. We have multiple projects that have similar 
configurations, dependencies, plugins, etc.  I don't want to have them repeated 
each time and they will not have the same parent - it is not feasible. I've 
used the import scope for setting dependency versions (e.g. dependency 
management) in one place and that worked ok. Has anyone tried to do this for 
plugins configurations as well?


On Jan 4, 2013, at 4:09 PM, Anders Hammar wrote:

> First, there is only one "super-POM" and that one is included in Maven
> itself. What you probably mean is a "parent pom".
> 
> To use that parent pom you declare it in the "parent" section, not as a
> import scope dependency.
> 
> /Anders
> 
> On Fri, Jan 4, 2013 at 10:00 PM, Marcos Mendez  wrote:
> 
>> 
>> I've defined a superpom and I'm using the import scope in another maven
>> project to apply those. I'm not seeing the configurations being applied for
>> the plugins I've defined in the superpom's pluginManagement.
>> 
>> Any ideas?
>> 
>> Regards,
>> Marcos
>> -
>> 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: Release preparation not removing SNAPSHOT suffix

[Julien Silland]

I understand the root issue is not from the release plugin itself but from the 
SCM implementation. Though, I have to mention that the plugin was error'ing out 
when I had left modified files before running maven:prepare.

My git version is: 1.7.7.5 (Apple Git-26)

Here's a sample output of git status --porcelain:

 M pom.xml
A  foo-archetype/pom.xml
?? phonebook/


This is respectively for a modified file, a new file and an untracked folder. I 
have no idea what's that character in between the beginning of the line and the 
'M' for the modified file. 

-- 
Julien Silland


On Friday, January 4, 2013 at 12:55 PM, Robert Scholte wrote:

> The real issue is https://jira.codehaus.org/browse/SCM-709
> To solve it we could really use some feedback on this issue:
> - which version of GIT are you using?
> - what is the output of 'git status --porcelain' if a file is modified?
> 
> Robert
> 
> Op Fri, 04 Jan 2013 21:00:40 +0100 schreef Julien Silland 
> mailto:julien.sill...@turn.com)>:
> 
> > Thanks for the pointer to the bug. I've configured my project to use the 
> > 2.3.2 version of the release plugin and things are working as expected. 
> > I haven't explored switching to different scm version dependency.
> > 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 
> (mailto:users-unsubscr...@maven.apache.org)
> For additional commands, e-mail: users-h...@maven.apache.org 
> (mailto:users-h...@maven.apache.org)
> 
> 

Re: import plugin configurations

[Anders Hammar]

First, there is only one "super-POM" and that one is included in Maven
itself. What you probably mean is a "parent pom".

To use that parent pom you declare it in the "parent" section, not as a
import scope dependency.

/Anders

On Fri, Jan 4, 2013 at 10:00 PM, Marcos Mendez  wrote:

>
> I've defined a superpom and I'm using the import scope in another maven
> project to apply those. I'm not seeing the configurations being applied for
> the plugins I've defined in the superpom's pluginManagement.
>
> Any ideas?
>
> Regards,
> Marcos
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
> For additional commands, e-mail: users-h...@maven.apache.org
>
>

import plugin configurations

[Marcos Mendez]

I've defined a superpom and I'm using the import scope in another maven project 
to apply those. I'm not seeing the configurations being applied for the plugins 
I've defined in the superpom's pluginManagement.

Any ideas?

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

Re: copy selected dependencies transitively

[Ron Wheeler]

What are you actually trying to do?
Why do you need to do this? What makes your environment different from 
everyone else's operation?


Perhaps there are easier ways to get what you want by reformulating the 
problem.


Ron

On 04/01/2013 11:17 AM, Erik Fäßler wrote:

Hi all,

my issue is no new one and I found some related posts - even on this list - 
already. But none of them has been answered, so I try my luck.

What I want:
Copy one (or multiple) selected dependency of my project into a directory of its own. 
That is, unlike the normal "copy-dependencies" execution which just copies all 
dependencies into a directory, I want to select only some of them.
I tried it with includeArtifactIds like this:


maven-dependency-plugin
2.6


Copy dependencies 
transitive
package


copy-dependencies



false

lib

myartifact







But here, the original meaning of "includeArtifactIds" is "copy exactly the artifacts of the given IDs, 
nothing else", which also means that no transitive dependencies are copied. I stated explicitly 
"false" but this seems to be ignored.
Question: Is there another way to achieve what I need (copy selected artifacts 
along with their transitive dependencies into a folder of their own).
Feature Request: I guess it wouldn't be too difficult to take the 
"false" command into account and just 
copy the transitive dependencies in this case, would it? If this could be added, it would help me and 
I guess some other people out there.

Thanks and best regards,

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





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102


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

Re: Release preparation not removing SNAPSHOT suffix

[Robert Scholte]

The real issue is https://jira.codehaus.org/browse/SCM-709
To solve it we could really use some feedback on this issue:
- which version of GIT are you using?
- what is the output of 'git status --porcelain' if a file is modified?

Robert

Op Fri, 04 Jan 2013 21:00:40 +0100 schreef Julien Silland  
:


Thanks for the pointer to the bug. I've configured my project to use the  
2.3.2 version of the release plugin and things are working as expected.  
I haven't explored switching to different scm version dependency.


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

Re: JNI jars dependencies

[Stuart Maclean]

Sorry Martin, I missed some of your points:


Hi from a newbie.MG>a newbie with extensive experience with maven and make 
files!



Ah yes, I meant new to mailing list ;)

com.wapmx.native loader can unpack it at runtime. MG>is this 
NativeLoader what you're alluding 
toMG>http://dev.loci.wisc.edu/trac/software/browser/branches/maven/projects/native-library-util/src/main/java/com/wapmx/nativeutils/jniloader/NativeLoader.java?rev=7574


Essentially yes, that is it.  I did try contacting the original author, 
to no avail.  I can't recall now if I was able to get that artifact from 
a repo or had to install it manually.


of a poor man's AOL (from the nar plugin, which I ended up NOT using). 
MG>did'nt catch the reasons why you do'nt want to use nar..explain please


I didn't use NAR as I was worried it was unsupported,fragmented and 
overly optimistic on what it was trying to achieve.  I could live with 
the exec plugin firing make, I am happy in make myself.tion across many

platform Makefiles. MG>smart ..OS and compiler specific variables should be 
aggregated in OS and compiler specific profiles



Yes.  I cannot fathom why there is no easier way to run javah from 
Maven.  It certainly isn't 'native' the way gcc is 'native'.  It's a 
standard Java tool running on .class files.  OK, it produces C headers 
but that doesn't make it 'native'.  I may switch to the antrun-plugin 
for the javah step, since the native-maven-plugin looks a bit alpha 
itself, and I don't use it for any 'heavy lifting', I use make.

MG>app code?
MG>JNI ?MG>How is the app PATHed to native binaries?


See last post, you don't need any LD_LIBRARY_PATH nor -Djava.library.path.

I should qualify this by saying that in PRINCIPLE this should all work 
on Windows, I have NOT actually tested it, I have just tested Linux 32 
and 64 bit.



Stuart

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

Re: JNI jars dependencies

[Stuart Maclean]

Hi Martin, all,

the native code, either a .so or .dll, lives in the uber.jar at 
/META-INF/lib/.  We then link this in via wapmx's native loader:


import com.wapmx.nativeutils.jniloader.NativeLoader;

class LoadJNI {

static {
String libName = "tsk4j";
try {
System.err.println( "Loading: " + libName );
NativeLoader.loadLibrary( libName );
} catch( IOException ioe ) {
throw new ExceptionInInitializerError( ioe );
}
}
}

The NativeLoader will create ./tmplib and dump the .so in there and then 
call Java's regular loader.  So the only side-effect is the ./tmplib 
creation.  And I imagine you could register a deleteOnExit hook to even 
clean that up, I don't bother.


My LoadJNI class is essentially a dummy class purely to do the native 
load.  In classes where I actually HAVE native methods which are to be 
found in the .so, I force a class dependency:


class HasNatives {

void native foo();

static {
  LoadJNI dummy = new LoadJNI();
}

Short of multi-class-loader issues, this seems to work.  All of my 
classes which depend on the .so for their native are 'regular' classes 
with no fancy class loader things going on.


Any better ideas on how to ensure the .so loaded before any use would be 
welcomed.


Stuart



Stuart

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

RE: JNI jars dependencies

[Martin Gainty]

  > Date: Fri, 4 Jan 2013 11:54:46 -0800
> From: stu...@apl.washington.edu
> To: users@maven.apache.org
> Subject: Re: JNI jars dependencies
> 
> Hi from a newbie.MG>a newbie with extensive experience with maven and make 
> files!
> 
> I too have been fighting with how best to develop maven artifacts 
> containing jni parts.  Though I found several useful posts on jni and 
> maven , e.g.
> 
> http://www.tricoder.net/blog/?p=197
> 
> http://docs.codehaus.org/display/MAVENUSER/Projects+With+JNI
> 
> http://www.humboldt.co.uk/2009/02/wrapping-a-native-library-with-maven.html
> 
> in the end I rolled my own solution, something I wanted to avoid.  My 
> goal was to produce usable artifacts that worked across platforms, ie 
> linux 32 and 64 bit and perhaps windows.  Here's some notes on my 
> experiences over the past 3-4 days.  My particular jni effort was to 
> 'Java-ify' an existing C library.
> 
> I isolated the Java classes which had native methods into a single Maven 
> module, so producing a single artifact.  I placed the Java sources under 
> the regular src/main/java.  In the pom, I used maven-native-plugin to 
> invoke javah to produce the headers (jn the default location 
> target/native/javah).  In the same pom, I then used the exec plugin to 
> invoke make in ./native/${os.name}.  Both of these are bound to the 
> compile phase, so a simple
> 
> mvn
> 
> will compile Java, run javah, then locate correct Makefile and run it.
> 
>I then added makefiles to ./native/Linux and ./native/Windows.  In 
> the Linux makefile, I used VPATH to locate the C sources in 
> ${basedir}/src/main/c.  The final .so file (which has no platform/arch 
> encoded into its name, ie is just libfoo.so) is copied by the make into 
> ${basedir}/target/classes/META-INF/lib, so the package phase will locate 
> the .so at /META-INF/lib/libfoo.so, from which the nifty 
> com.wapmx.native loader can unpack it at runtime. MG>is this NativeLoader 
> what you're alluding 
> toMG>http://dev.loci.wisc.edu/trac/software/browser/branches/maven/projects/native-library-util/src/main/java/com/wapmx/nativeutils/jniloader/NativeLoader.java?rev=7574
> 
> The whole artifact is then named
> 
> NAME-${os.arch}-${os.name}  and installed and/or deployed.  this is sort 
> of a poor man's AOL (from the nar plugin, which I ended up NOT using). 
> MG>did'nt catch the reasons why you do'nt want to use nar..explain please
> 
> Then a project/module which depends on this artifact simply uses the 
> name above.  It's a bit crude, but for 2 or 3 platforms maximum, I think 
> it will be manageable.
> 
> Points:
> 
> the javah invocation could have been done either from Maven or make.  I 
> chose to to it in Maven, mostly to avoid duplication across many 
> platform Makefiles. MG>smart ..OS and compiler specific variables should be 
> aggregated in OS and compiler specific profiles
> 
> I use the wapmx artifact to extract the native lib from the jar, better 
> than requiring LD_LIBRARY_PATH solutions.
> 
> My particular jni scenario required that the Java side maintain C 
> pointers (in both directions).  Knowing that these would be 64 bits wide 
> on 64 bit platforms, I had to use Java longs and jlong in the C code.  
> Compiling on 32 bit Linux, I then had to add
> 
> ifeq ($(shell uname -m),i686)
> # want any warning to raise error, but silence any 64/32 bit conversions
> CFLAGS += -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast
> endif
> 
> to the Makefile to silence the compiler's warnings.  I always compile 
> with -Werror (any warning is an error, fail to build)
> 
> In the C link phase in my makefiles, I statically linked the C library I 
> am wrapping, call it W.  To do this, I used an explicit file name, eg.
> 
> cc -o libfoo.so /path/to/libW.a my1.o my2.o
> 
> I tried fancy -Wl,-static and -Wl,-shared linker options but it always 
> failed to link.  I should point out that I had sources to libW, so could 
> configure/make it as desired.
> 
> 
> Then my end user (who is handed just a single jar) does not need any 
> libW.so at runtime.MG>whats inside the uber.jar?
MG>app code?
MG>JNI ?MG>How is the app PATHed to native binaries?
> 
> 
> Paths I investigated but did not finally use:
> 
> having the Java classes containing the native methods (call it A) and 
> the actual .so (call it B) as separate Maven modules, as explained in 
> the first url above. Then B depends upon A being built so that javah can 
> locate .class files, but then how do you run test cases in A, since you 
> need native code in B.MG>perhaps aggregate the plugins for B into a child 
> module?
> 
> I did not use maven-nar-plugin, since as suggested, it is really a Maven 
> solution to wider native development.  I had a localised (or so I think) 
> jni issue.
> 
> I used maven-native-plugin over the antrun-plugin, which apparently 
> would also give access to javah (would this require an extra Ant 
> build.xml or can this be 'embedded' in the pom???) MG>forked ant targets 
> ca

Re: Release preparation not removing SNAPSHOT suffix

[Julien Silland]

Thanks for the pointer to the bug. I've configured my project to use the 2.3.2 
version of the release plugin and things are working as expected. I haven't 
explored switching to different scm version dependency.

-- 
Julien Silland


On Thursday, January 3, 2013 at 2:34 AM, Robert Scholte wrote:

> See https://jira.codehaus.org/browse/MRELEASE-812
> 
> Robert
> 
> Op Thu, 03 Jan 2013 08:26:30 +0100 schreef Ansgar Konermann 
> mailto:ansgar.konerm...@googlemail.com)>:
> > Had a similar issue recently. In the directory you're trying to release,
> > what is the output of "git status"?
> > Am 03.01.2013 03:01 schrieb "Julien Silland"  > (mailto:julien.sill...@turn.com)>:
> > 
> > > Hi,
> > > 
> > > I'm in the process of fully automating the release of my artifacts which
> > > are currently checked-in an internal git repo. I've configured my 
> > > project
> > > with what I think are the correct scm settings and have gotten a 
> > > moderate
> > > amount of success, namely building a project and tagging a commit with 
> > > the
> > > right version (foo-1.0).
> > > 
> > > However, the documentation for the release:prepare phase indicates that
> > > the -SNAPSHOT suffix in my pom.xml should be deleted as part of the 
> > > tagging
> > > process:
> > > 
> > > From:
> > > http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html
> > > Change the version in the POMs from x-SNAPSHOT to a new version (you 
> > > will
> > > be prompted for the versions to use)
> > > 
> > > But that side-effect is nowhere to be found: after the phase ends, the
> > > remote pom.xml hasn't been altered (it still declares 1.0-SNAPSHOT) even
> > > though it is tagged with foo-1.0 and the local version of the pom.xml is
> > > bumped to 1.1-SNAPSHOT. I would have expected a git push to happen 
> > > before
> > > the tagging to change the pom.xml to a non-snapshot 1.0 version.
> > > Predictably, trying to perform a release builds a 1.0-SNAPSHOT jar, 
> > > which
> > > is not desired.
> > > 
> > > I may be expecting the wrong things to happen but would happily receive
> > > some guidance.
> > > 
> > > My release configuration is minimal:
> > > 
> > > 
> > > org.apache.maven.plugins
> > > maven-release-plugin
> > > 2.4
> > > 
> > > Maven release plugin: 
> > > 
> > > 
> > > 
> > > 
> > > Thanks,
> > > -jsi
> > > 
> > > --
> > > Julien Silland
> > > 
> > 
> > 
> 
> 
> -
> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org 
> (mailto:users-unsubscr...@maven.apache.org)
> For additional commands, e-mail: users-h...@maven.apache.org 
> (mailto:users-h...@maven.apache.org)
> 
> 

Re: JNI jars dependencies

[Stuart Maclean]

Hi from a newbie.

I too have been fighting with how best to develop maven artifacts 
containing jni parts.  Though I found several useful posts on jni and 
maven , e.g.


http://www.tricoder.net/blog/?p=197

http://docs.codehaus.org/display/MAVENUSER/Projects+With+JNI

http://www.humboldt.co.uk/2009/02/wrapping-a-native-library-with-maven.html

in the end I rolled my own solution, something I wanted to avoid.  My 
goal was to produce usable artifacts that worked across platforms, ie 
linux 32 and 64 bit and perhaps windows.  Here's some notes on my 
experiences over the past 3-4 days.  My particular jni effort was to 
'Java-ify' an existing C library.


I isolated the Java classes which had native methods into a single Maven 
module, so producing a single artifact.  I placed the Java sources under 
the regular src/main/java.  In the pom, I used maven-native-plugin to 
invoke javah to produce the headers (jn the default location 
target/native/javah).  In the same pom, I then used the exec plugin to 
invoke make in ./native/${os.name}.  Both of these are bound to the 
compile phase, so a simple


mvn

will compile Java, run javah, then locate correct Makefile and run it.

  I then added makefiles to ./native/Linux and ./native/Windows.  In 
the Linux makefile, I used VPATH to locate the C sources in 
${basedir}/src/main/c.  The final .so file (which has no platform/arch 
encoded into its name, ie is just libfoo.so) is copied by the make into 
${basedir}/target/classes/META-INF/lib, so the package phase will locate 
the .so at /META-INF/lib/libfoo.so, from which the nifty 
com.wapmx.native loader can unpack it at runtime.


The whole artifact is then named

NAME-${os.arch}-${os.name}  and installed and/or deployed.  this is sort 
of a poor man's AOL (from the nar plugin, which I ended up NOT using).


Then a project/module which depends on this artifact simply uses the 
name above.  It's a bit crude, but for 2 or 3 platforms maximum, I think 
it will be manageable.


Points:

the javah invocation could have been done either from Maven or make.  I 
chose to to it in Maven, mostly to avoid duplication across many 
platform Makefiles.


I use the wapmx artifact to extract the native lib from the jar, better 
than requiring LD_LIBRARY_PATH solutions.


My particular jni scenario required that the Java side maintain C 
pointers (in both directions).  Knowing that these would be 64 bits wide 
on 64 bit platforms, I had to use Java longs and jlong in the C code.  
Compiling on 32 bit Linux, I then had to add


ifeq ($(shell uname -m),i686)
# want any warning to raise error, but silence any 64/32 bit conversions
CFLAGS += -Wno-int-to-pointer-cast -Wno-pointer-to-int-cast
endif

to the Makefile to silence the compiler's warnings.  I always compile 
with -Werror (any warning is an error, fail to build)


In the C link phase in my makefiles, I statically linked the C library I 
am wrapping, call it W.  To do this, I used an explicit file name, eg.


cc -o libfoo.so /path/to/libW.a my1.o my2.o

I tried fancy -Wl,-static and -Wl,-shared linker options but it always 
failed to link.  I should point out that I had sources to libW, so could 
configure/make it as desired.



Then my end user (who is handed just a single jar) does not need any 
libW.so at runtime.



Paths I investigated but did not finally use:

having the Java classes containing the native methods (call it A) and 
the actual .so (call it B) as separate Maven modules, as explained in 
the first url above. Then B depends upon A being built so that javah can 
locate .class files, but then how do you run test cases in A, since you 
need native code in B.


I did not use maven-nar-plugin, since as suggested, it is really a Maven 
solution to wider native development.  I had a localised (or so I think) 
jni issue.


I used maven-native-plugin over the antrun-plugin, which apparently 
would also give access to javah (would this require an extra Ant 
build.xml or can this be 'embedded' in the pom???)


Comments, suggestions welcomed

Stuart

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

copy selected dependencies transitively

[Erik Fäßler]

Hi all,

my issue is no new one and I found some related posts - even on this list - 
already. But none of them has been answered, so I try my luck.

What I want:
Copy one (or multiple) selected dependency of my project into a directory of 
its own. That is, unlike the normal "copy-dependencies" execution which just 
copies all dependencies into a directory, I want to select only some of them.
I tried it with includeArtifactIds like this:


maven-dependency-plugin
2.6


Copy dependencies 
transitive
package


copy-dependencies



false

lib

myartifact







But here, the original meaning of "includeArtifactIds" is "copy exactly the 
artifacts of the given IDs, nothing else", which also means that no transitive 
dependencies are copied. I stated explicitly 
"false" but this seems to be ignored.
Question: Is there another way to achieve what I need (copy selected artifacts 
along with their transitive dependencies into a folder of their own).
Feature Request: I guess it wouldn't be too difficult to take the 
"false" command into account and just 
copy the transitive dependencies in this case, would it? If this could be 
added, it would help me and I guess some other people out there.

Thanks and best regards,

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

Re: rpm-maven-plugin 2.1-alpha-2 not truncating version

[Anders Hammar]

Very likely a bug if the docs says otherwise. I did the last release of
that plugin but I can't recall any ticket about this change.
Please have a look at the tickets in JIRA for the 2.1-alpha-2 release and
see if you can find anything that seems related to this. If not, please
file a ticket of the issue and attach a small project to reproduce this.
Also, as there is close to no activity on this plugin you should probably
also provide a patch if you want it fixed.

/Anders


On Fri, Jan 4, 2013 at 12:44 AM, Jeff  wrote:

> In version 2.1-alpha-1, if the version contained a '-' (dash) I would get a
> warning that said:
>
>
> [WARNING] rpm version string truncated to 2012.12.19.001
>
>
> where the original version was 2012.12.19.001-SNAPSHOT.
>
> After updating to 2.1-alpha-2, I no longer see that warning and now my
> build fails.
>
> Is this intentional?  I'm not a Maven expert yet and don't know how to
> manually truncate the version.
>
> The docs located at
> http://mojo.codehaus.org/rpm-maven-plugin/ident-params.html#version says
> it
> "will be truncated at the first dash".
>
> I'll revert back to alpha-1 but wondered if the behavior is changing or if
> this is a bug?
>
> --
> Jeff Vincent
> predato...@gmail.com
> See my LinkedIn profile at:
> http://www.linkedin.com/in/rjeffreyvincent
> I ♥ DropBox  !!
>