Hi,
Am 06.03.2013 um 14:56 schrieb Simone Tripodi:
> And, just for the sake of putting more steaks on the barbeque, the
> bundle-plugin takes care of adjusting the version in the MANIFEST.MF
> according to the SemVer recommendations; version is now 1.3-SNAPSHOT
> and look below how the MANIFEST.MF has been generated.
So here's the topping: The Commons parent POM has configuration to set the
export package version to the same as the project version:
> <commons.osgi.export>org.apache.commons.*;version=${project.version};-noimport:=true</commons.osgi.export>
Which is the background, why I spoke about taking care of the export package
version, should you decide to release as 2.0. This would have exported the
packages at 2.0 which in OSGi semantic versioning terms would constitute a
backwards compatibility breaking release, which is probably not the intent of
the Commons project....
Regards
Felix
>
> alles gute!
> -Simo
>
> $ cat target/osgi/MANIFEST.MF
> Manifest-Version: 1.0
> Bnd-LastModified: 1362567127928
> Build-Jdk: 1.6.0_37
> Built-By: stripodi
> Bundle-Description: The FileUpload component provides a simple yet flexi
> ble means of adding support for multipart file upload functionality
> to servlets and web applications.
> Bundle-DocURL: http://commons.apache.org/fileupload/
> Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.txt
> Bundle-ManifestVersion: 2
> Bundle-Name: Commons FileUpload
> Bundle-SymbolicName: org.apache.commons.fileupload
> Bundle-Vendor: The Apache Software Foundation
> Bundle-Version: 1.3.0.SNAPSHOT
> Created-By: Apache Maven Bundle Plugin
> DynamicImport-Package: javax.portlet
> Export-Package: org.apache.commons.fileupload.util;version="1.3.0.SNAPSH
> OT",org.apache.commons.fileupload.disk;version="1.3.0.SNAPSHOT",org.apa
> che.commons.fileupload;version="1.3.0.SNAPSHOT",org.apache.commons.file
> upload.servlet;version="1.3.0.SNAPSHOT",org.apache.commons.fileupload.p
> ortlet;version="1.3.0.SNAPSHOT"
> Import-Package: javax.servlet,javax.servlet.http,org.apache.commons.io,o
> rg.apache.commons.io.output
> Include-Resource: META-INF/LICENSE.txt=LICENSE.txt,META-INF/NOTICE.txt=N
> OTICE.txt
> Tool: Bnd-1.50.0
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
> On Wed, Mar 6, 2013 at 2:32 PM, Benedikt Ritter <brit...@apache.org> wrote:
>> 2013/3/6 Felix Meschberger <fmesc...@adobe.com>
>>
>>> Hi,
>>>
>>> Am 06.03.2013 um 12:51 schrieb Benedikt Ritter:
>>>
>>>> 2013/3/6 sebb <seb...@gmail.com>
>>>>
>>>>> On 6 March 2013 08:53, Simone Tripodi <simonetrip...@apache.org> wrote:
>>>>>>>> Is there anybody that can suggest how to handle that situation?
>>>>>>>
>>>>>>> Create new methods which return long rather than int; deprecate the
>>> old
>>>>> methods.
>>>>>>>
>>>>>>> e.g.
>>>>>>>
>>>>>>> @Deprecated
>>>>>>> public int getContentLength() { ... }
>>>>>>>
>>>>>>> /**
>>>>>>> * @since x.x
>>>>>>> */
>>>>>>>
>>>>>>> public long getLongContentLength() { ... }
>>>>>>> or
>>>>>>> public long getContentLengthLong() { ... }
>>>>>>> or
>>>>>>> public long longContentLength() { ... }
>>>>>>
>>>>>> that should be enough to bump to 1.3.0 since there are APIs addition -
>>>>>> do you agree?
>>>>>
>>>>> Yes, except it should be 1.3, not 1.3.0.
>>>>> If a point release is then required, it is 1.3.1, but point releases
>>>>> are fairly rare.
>>>>>
>>>>
>>>> Having OSGi this may not be the best convention, as OSGi requires version
>>>> numbers to have 3 digits.
>>>
>>> Not really, 1.3 is a perfectly valid OSGi version, too. Actually, even 1
>>> is a valid version (according to the OSGi Syntax)
>>>
>>
>> Hi Felix,
>>
>> thanks for enlighting me about OSGi once again :)
>>
>> Benedikt
>>
>>
>>>
>>> Regards
>>> Felix
>>>
>>>>
>>>> Benedikt
>>>>
>>>>
>>>>>
>>>>>> -Simo
>>>>>>
>>>>>> http://people.apache.org/~simonetripodi/
>>>>>> http://simonetripodi.livejournal.com/
>>>>>> http://twitter.com/simonetripodi
>>>>>> http://www.99soft.org/
>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> http://people.apache.org/~britter/
>>>> http://www.systemoutprintln.de/
>>>> http://twitter.com/BenediktRitter
>>>> http://github.com/britter
>>>
>>>
>>> --
>>> Felix Meschberger | Principal Scientist | Adobe
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>>> For additional commands, e-mail: dev-h...@commons.apache.org
>>>
>>>
>>
>>
>> --
>> http://people.apache.org/~britter/
>> http://www.systemoutprintln.de/
>> http://twitter.com/BenediktRitter
>> http://github.com/britter
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
--
Felix Meschberger | Principal Scientist | Adobe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
