How is the version determined by nbm-maven-plugin ?

View: New views
4 Messages — Rating Filter:   Alert me  

How is the version determined by nbm-maven-plugin ?

by Emilian Bold-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hy,

I'm using nbm-maven-plugin 3.0 to populate the repository.

It looks to me like the plugin generates some strange version numbers.  
Not only the standard nbm version + implementation number, but it also  
seems to append some version from the *dependencies* implementation  
number.

This is also weird as if I change only 1 module's build number for  
example, I might need to update 2 or more dependencies if the pom-s as  
the plugin might have generated one of there /long/ version numbers.

How does this thing work ? I would expect the maven version to be  
something like 1.2.3.50 (nbm version + implementation number) and  
instead I'm looking at munch longer maven ids (like 1.2.3.50.20.30).  
This "kinda" makes sense but I'm just checking if it's normal behavior.

--emi

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Re: How is the version determined by nbm-maven-plugin ?

by Milos Kleint-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

nbm:populate-repository takes the version value from the specification version as is present in the module jar file, unless specified by the forcedVersion parameter to be a single value across modules. I recommend the forcedVersion approach.

Milos

On Fri, Oct 16, 2009 at 4:49 PM, Emilian Bold <emilian.bold@...> wrote:
Hy,

I'm using nbm-maven-plugin 3.0 to populate the repository.

It looks to me like the plugin generates some strange version numbers. Not only the standard nbm version + implementation number, but it also seems to append some version from the *dependencies* implementation number.

This is also weird as if I change only 1 module's build number for example, I might need to update 2 or more dependencies if the pom-s as the plugin might have generated one of there /long/ version numbers.

How does this thing work ? I would expect the maven version to be something like 1.2.3.50 (nbm version + implementation number) and instead I'm looking at munch longer maven ids (like 1.2.3.50.20.30). This "kinda" makes sense but I'm just checking if it's normal behavior.

--emi

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email




Re: How is the version determined by nbm-maven-plugin ?

by Emilian Bold-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

I see, never looked at the generated MANIFEST.MF. Indeed, it looks like if you have strict dependencies, those implementation version numbers get appended to OpenIDE-Module-Specification-Version.

--emi

On Oct 16, 2009, at 6:34 PM, Milos Kleint wrote:

nbm:populate-repository takes the version value from the specification version as is present in the module jar file, unless specified by the forcedVersion parameter to be a single value across modules. I recommend the forcedVersion approach.

Milos

On Fri, Oct 16, 2009 at 4:49 PM, Emilian Bold <emilian.bold@...> wrote:
Hy,

I'm using nbm-maven-plugin 3.0 to populate the repository.

It looks to me like the plugin generates some strange version numbers. Not only the standard nbm version + implementation number, but it also seems to append some version from the *dependencies* implementation number.

This is also weird as if I change only 1 module's build number for example, I might need to update 2 or more dependencies if the pom-s as the plugin might have generated one of there /long/ version numbers.

How does this thing work ? I would expect the maven version to be something like 1.2.3.50 (nbm version + implementation number) and instead I'm looking at munch longer maven ids (like 1.2.3.50.20.30). This "kinda" makes sense but I'm just checking if it's normal behavior.

--emi

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email





Re: How is the version determined by nbm-maven-plugin ?

by Milos Kleint-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

yeah, it's some sort of smartism that has to do with module updates. never entirely grasped the gory details.

Milos

On Fri, Oct 16, 2009 at 5:47 PM, Emilian Bold <emilian.bold@...> wrote:
I see, never looked at the generated MANIFEST.MF. Indeed, it looks like if you have strict dependencies, those implementation version numbers get appended to OpenIDE-Module-Specification-Version.

--emi

On Oct 16, 2009, at 6:34 PM, Milos Kleint wrote:

nbm:populate-repository takes the version value from the specification version as is present in the module jar file, unless specified by the forcedVersion parameter to be a single value across modules. I recommend the forcedVersion approach.

Milos

On Fri, Oct 16, 2009 at 4:49 PM, Emilian Bold <emilian.bold@...> wrote:
Hy,

I'm using nbm-maven-plugin 3.0 to populate the repository.

It looks to me like the plugin generates some strange version numbers. Not only the standard nbm version + implementation number, but it also seems to append some version from the *dependencies* implementation number.

This is also weird as if I change only 1 module's build number for example, I might need to update 2 or more dependencies if the pom-s as the plugin might have generated one of there /long/ version numbers.

How does this thing work ? I would expect the maven version to be something like 1.2.3.50 (nbm version + implementation number) and instead I'm looking at munch longer maven ids (like 1.2.3.50.20.30). This "kinda" makes sense but I'm just checking if it's normal behavior.

--emi

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email