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 <[email protected]>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 <[email protected]>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 >> >> >> > >
