Thanks Reto, I will definitely give it a try in the coming days.

Regards,

Minto


Op 23-9-2013 17:37, Reto Bachmann-Gmür schreef:
> Hi Minto
>
> You're more than welcome to tailor a release.
>
> Roughly the steps to do as I remember them:
>
> - Optional: announce that will be tailoring a relase at a certain date, say
> which modules will at least be part of the release. This allows people to
> fix their favourite bugs till that date, ask for another module to be added
> or explain why they think the current trunk version is unreleasable
> - move all the modules to a release branch
> - add a trow-away reactor to build all the modules in that branch
> - make sure the svn-repo infos point to the branch
> - use the release plugin to create the release candidate
> - stage it on https://repository.apache.org/ after removing unneded files
> (such as the throw-away reactor)
> - start the vote
> - if the vote passed: promote on repository.apache.org
>
> Give it a try, I'm glad to help at any stage.
>
> Cheers,
> Reto
>
> See
> http://www.apache.org/dev/release-publishing.html and
> http://www.apache.org/dev/publishing-maven-artifacts.html
>
>
>
>
> On Sun, Sep 22, 2013 at 9:43 PM, Minto van der Sluis <[email protected]> wrote:
>
>> Hi Reto,
>>
>> Some remarks below.
>>
>> Any idea when we could release these ext bundles and the other Clerezza
>> Jena based bundles? I know I asked it before a while ago. But this time
>> I am on the verge of releasing my own stuff. It would look much better
>> if I used released Clerezza components instead of snapshot ones.
>>
>> Regards,
>>
>> Minto
>>
>> Op 22-9-2013 17:11, Reto Bachmann-Gmür schreef:
>>> Some more thoughts:
>>> - The probllem with having the identical version number as the wrapped
>> jar
>>> is taht if we release the bundles we will (n+1)-SNAPSHOT versions in
>> trunk
>>> that wrap the artifact versioned n. And it's going to be a mess is need
>> to
>>> release a new bundle for the same wrapped version (say we forgot an
>> export
>>> or so). I think this problem is solved by adding a _1 to the version
>> number.
>> The additional sequence number could also be added after the first
>> change. But using it from the start is an other option. One way or the
>> other I do not really have a preference. So if you prefer it like this
>> its fine with me.
>>> - I think the base of artifact ID should be the original
>> groupId:Artifactid
>>> (unless the artifactId already contains the groupId)
>> It's different from Apache ServiceMix but that's fine with me. After all
>> we run our own race ;-)
>>> I hope it's OK that I committed this changes and added the new bundles to
>>> the launcher.
>> No problem.
>>>
>>> Cheers,
>>> Reto
>>>
>>>
>>>
>>>
>>> On Sat, Sep 21, 2013 at 10:39 PM, Reto Bachmann-Gmür
>> <[email protected]>wrote:
>>>> Hi Minto
>>>>
>>>>                     <dependency>
>> <groupId>org.apache.servicemix.bundles</groupId>
>>>>>                         <artifactId>src-assembly</artifactId>
>>>>>                         <version>1.0</version>
>>>>>                     </dependency>
>>>>>
>>>>> I guess we want to get rid of this dependency as well, by creating our
>>>>> own. I will copy the src-assembly from service mix.
>>>>>
>>>> There is no problem depending on some servicemix dependencies. Here I
>> just
>>>> don't see what this is needed for, i.e. why a special source assembly is
>>>> needed for the ext-projects.
>>>>
>>>> Also I notice that the bundles parent was not part of the bundles
>> reactor
>>>> and that it did not inherit from the clerezza parent. Hope it's OK that
>> I
>>>> changed this (under your issue).
>>>>
>>>> Now the next step is to try the tdb launcher out with the new
>> bundles....
>>>> Cheers,
>>>> Reto
>>>>
>>>>> On Fri, Sep 20, 2013 at 10:27 AM, Minto van der Sluis <[email protected]>
>>>> wrote:
>>>>>> Hi folks,
>>>>>>
>>>>>> I just committed my work on the lean Apache jena ext wrappers. Please
>>>>>> have a close look. The ext bundles can be found in the newly
>> created ext
>>>>>> folder.
>>>>>>
>>>>>> Now I wonder how to continue with these new/ServiceMix style
>> wrappers. I
>>>>>> have the following questions:
>>>>>>
>>>>>> 1. Wrapper hosting.
>>>>>> Do we want to host/own these wrappers our selves or donate it to
>>>>>> ServiceMix. From what I read ServiceMix bundles are open for others to
>>>>>> donate wrappers. See
>>>>>> http://svn.apache.org/repos/asf/servicemix/smx4/bundles/trunk/
>>>>>>
>>>>>> 2. Wrapper versioning
>>>>>> When we decide to host ext wrappers ourselves then we should decide on
>>>>>> versioning these wrappers as well. Do we need separate wrappers for
>>>>>> separate version like ServiceMix has. For instance jena-core-2.10.0,
>>>>>> jena-core-2.10.1, jena-core-2.11.0, ... Personally I think we do not
>>>>>> need this. Once a version is release it could be tagged or branched in
>>>>>> svn (requires a change to what's currently committed). Also I think
>> that
>>>>>> within Clerezza we should stick to using a single version as much as
>>>>>> possible.
>>>>>>
>>>>>> 3. How to test within Clerezza
>>>>>> Since I only use part of Clerezza (rdf abstraction layer + jena
>>>>>> storage). I don't know how to test if these new wrappers work inside
>>>>>> clerezza as well. I could start with running all unittests. But I am
>>>>>> more concerned about the various launchers. How do I test if these
>> still
>>>>>> work.
>>>>>>
>>>>>> What remains to be done:
>>>>>> - remove the old ext jena wrappers (jena and jena.tdb)
>>>>>> - preferably use the ServiceMix style for all other ext bundles as
>> well.
>>>>>> - modify launchers/bundlelists to use the new ext wrappers (also add
>>>>>> required dependencies)
>>>>>>
>>>>>> Please let me know what you guys think.
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>> Minto
>>>>>>
>>>>
>>>> --
>>>>> ir. ing. Minto van der Sluis
>>>>> Software innovator / renovator
>>>>> Xup BV
>>>>>
>>>>> Mobiel: +31 (0) 626 014541
>>>>>
>>>>>
>>
>> --
>> ir. ing. Minto van der Sluis
>> Software innovator / renovator
>> Xup BV
>>
>> Mobiel: +31 (0) 626 014541
>>
>>


-- 
ir. ing. Minto van der Sluis
Software innovator / renovator
Xup BV

Mobiel: +31 (0) 626 014541

Reply via email to