On 23/09/13 16:37, Reto Bachmann-Gmür wrote:
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
Don't forget to put the source-release on
http://www.apache.org/dist/clerezza.
After all, that is the item that is the formal release; all this binary
stuff is "merely" convenience!
Andy
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
