Build namespace m has build number 234 which is newer than 29

[Madhura Shetty, modificado 9 Anos atrás.]

I am receiving the following error when i build the deploy, "Build namespace m has build number 234 which is newer than 29".

I have tried with the below link to solve it I changed the build number in service.Properties file but after i build the project once again the build number again changes
build.namespace=m
build.number=29

but i was not able to figure out what i should do actually to resolve the issue .
http://www.liferay.com/community/forums/-/message_boards/message/16577981

Please let me know what should i do to resolve the issue.
Thanks in advance.

[Sanketh Iyer, modificado 9 Anos atrás.]

Hi,

You need to change the build.number to something greater than 234

Regards,
Sanketh Iyer

[Madhura Shetty, modificado 9 Anos atrás.]

I did build.number=250 and then i build the project
again it says
Build namespace m has build number 250 which is newer than 30

[Pankaj Kathiriya, modificado 9 Anos atrás.]

Make sure you are modifying service.properties under src folder not classes folder.

[Jay Trivedi, modificado 9 Anos atrás.]

Make sure you don't edit file in classes generated folder
Just clear temp and delete that Portlet from webapps once. Deploy it again will resolve your porblem.

[David H Nebinger, modificado 9 Anos atrás.]

Wow, so many wrong answers...

When you build services, the build number increases in service.properties. This value is included in the service jar and basically must match the value of the deployed plugin providing the service.

So what you have is a service jar that is at build number 234, but the remote plugin providing the service is still at 29.

This whole thing is an attempt by Liferay to enforce, from a systems perspective, that the service jars and the service providing plugin stay in sync with each other.

The problem is that if you add, say, an entity and build services the service jar and the plugin have a newer number, say 239. Now if you build another portlet plugin with this service jar and deploy it (but haven't deployed the plugin providing the service that is 239), then you get this message because they are now out of sync.

The important lesson to learn is to only build services when a) you add/remove/update an entity in service.xml or b) you add/remove/update a method or it's signature in Xxx[Local]ServiceImpl classes. If you just change a method body, you do not need to build services and your build number doesn't have to change and you don't run into out of sync issues such as this one.

A corrolary to this, whenever you build services you must deploy not only the plugin providing the service, but you must also update and deploy all plugins dependent upon that service (with the new updated service jars).

[Jack Bakker, modificado 9 Anos atrás.]

I saw on a Nov 13 dev.life session that a way is to

delete from servicecomponent where buildnamespace='*yourServiceBuildNameSpaceHere'

[David H Nebinger, modificado 9 Anos atrás.]

The issue with that Jack is that if version 29 is the version of the plugin providing the service implements, the service jar is probably still going to fail since it is so much newer.

[Jack Bakker, modificado 9 Anos atrás.]

David H Nebinger:

The issue with that Jack is that if version 29 is the version of the plugin providing the service implements, the service jar is probably still going to fail since it is so much newer.

Yup. Yet, given I generally have 10+ portlets drawing on custom services, I continue to have one portlet plugin for services where I move the service jar to a global classpath instead of copying the service jar into all the portlets that consume the services. I likely will continue this approach until OSGi ways offer a better bundled way. But yes David, if you are taking the approach of copying the service jar to all consumer portlets, then knowing that a service jar in a portlet is not current is useful information...