6.4.3

[Sebastiano Vigna]

fastutil 6.4.3 has been released (almost no changes) and pushed thorugh Sonatype. In a couple of hours it should be on Maven Central: please make comments on any aspect of the publishing process that I might have screwed up, as this is all new for me (it's not even very clear to me what should go in the jar of sources).

I am releasing dsiutils, too, and converting all my stuff to this kind of release process. Let's see...

Ciao,

seba

[Dawid Weiss]

Well, you can inspect what was there before --

http://repo1.maven.org/maven2/it/unimi/dsi/fastutil/6.4.2/

The source and javadoc JARs contain anything you might have wanted to
link so that .class files opened in Eclipse for example do link to
their real source code. I would include generated sources as well for
this reason. Did you keep POM artifact namespace, etc?

Dawid

[Sebastiano Vigna]

On Feb 23, 2012, at 12:45 PM, Dawid Weiss wrote:

> The source and javadoc JARs contain anything you might have wanted to
> link so that .class files opened in Eclipse for example do link to
> their real source code.

> uld include generated sources as well for
> this reason. Did you keep POM artifact namespace, etc?

Oops. Good point--presently the sources are not included, I'll do it.

Ciao,

seba

[Holger Hoffstätte]

Hi,

just joined - maybe I should have done so before. :)

First of all thanks for getting the "official" artifact published to
central; I have been using Dawid's version and even contributed a (for
me) rather important feature. Two questions:

- what was the reason for the change of the groupId? I now have to
change all client-side dependencies, and there's a good chance that
via transitive dependencies I'll end up with duplicates on the
classpath.

- I checked the manifest and the OSGi support is apparently gone,
since (I presume) you didn't know it was there or what it was. That
makes deploying fastutil into any OSGi runtimes impossible without
*again* maintaining my own fork or embedding fastutil into every
client bundle. Especially the latter is clearly not an option. OSGi is
the sanest way to safely share the classes between dozens of clients
and save massive amounts of space. The fix for this is fairly easy;
just manually generate the Manifest.info metadata and add it into the
jar.

Sorry for not chiming in earlier , I didn't know this list existed. :/

Thanks again for fastutil.

Holger

[Sebastiano Vigna]

On Feb 25, 2012, at 1:00 PM, Holger Hoffstätte wrote:

> - what was the reason for the change of the groupId? I now have to
> change all client-side dependencies, and there's a good chance that
> via transitive dependencies I'll end up with duplicates on the
> classpath.

When I requested authorization to Sonatype, that's the groupId they gave me and I didn't discuss. There's another problem: in the six months the DSI will no longer exists, so having a groupId associated to non-existing entity and to an ultimately non-registered domain seemed weird.

> - I checked the manifest and the OSGi support is apparently gone,
> since (I presume) you didn't know it was there or what it was. That

Exactly.

> makes deploying fastutil into any OSGi runtimes impossible without
> *again* maintaining my own fork or embedding fastutil into every
> client bundle. Especially the latter is clearly not an option. OSGi is
> the sanest way to safely share the classes between dozens of clients
> and save massive amounts of space. The fix for this is fairly easy;
> just manually generate the Manifest.info metadata and add it into the
> jar.

Please give me precise indications and I'll do it for all projects. I was expecting about a month of small fixes and suggestions trickling in--it has been two *very busy* days, believe me :).

Ciao,

seba

[Dawid Weiss]

>> - I checked the manifest and the OSGi support is apparently gone,
>> since (I presume) you didn't know it was there or what it was. That

I totally forgot about it. And it's going to be a pain to generate
manually -- see, I told you trying to cater for Maven plugins manually
will be an increasingly going sore point ;)

The OSGi config is generated (in maven) by looking at class
relationships. If you unpack:
http://repo1.maven.org/maven2/it/unimi/dsi/fastutil/6.4.2/fastutil-6.4.2.jar

and look at the manifest file it'll contain these entries:

Implementation-Title: fastutil
Implementation-Version: 6.4.2
Implementation-Vendor-Id: it.unimi.dsi
Export-Package: it.unimi.dsi.fastutil.io;uses:="it.unimi.dsi.fastutil.
booleans,it.unimi.dsi.fastutil.bytes,it.unimi.dsi.fastutil.chars,it.u
nimi.dsi.fastutil.doubles,it.unimi.dsi.fastutil.floats,it.unimi.dsi.f
astutil.ints,it.unimi.dsi.fastutil.longs,it.unimi.dsi.fastutil.shorts
,it.unimi.dsi.fastutil";version="6.4.2",it.unimi.dsi.fastutil.chars;u
ses:="it.unimi.dsi.fastutil.objects,it.unimi.dsi.fastutil.booleans,it
....
Tool: Bnd-1.15.0
Bundle-Name: fastutil
Bundle-RequiredExecutionEnvironment: J2SE-1.5,JavaSE-1.6
Bundle-Version: 6.4.2
Bnd-LastModified: 1327614293624
Bundle-ManifestVersion: 2
Bundle-License: http://www.apache.org/licenses/LICENSE-2.0.html
Bundle-SymbolicName: it.unimi.dsi.fastutil

I guess you could just generate this statically and sed the version
number, but the export-package option will be tough. Maybe Holger
knows how to generate it using command line tools.

As for the namespace -- it's not unheard of to just keep the namespace
you once had, even if it's gone now. Holger does have a point in that
fragmenting your project across maven central is a pain. I'd stick to
the old name.

Dawid

[Sebastiano Vigna]

I'll have a look into this. I'll ask for a it.unimi.dsi groupid and restart the whole thing. Maybe there's an ivy task that does the OSGI stuff...
-- Inviato dal mio cellulare Android con K-9 Mail.

Dawid Weiss <dawid...@gmail.com> ha scritto:

[Earwin]

On Feb 25, 4:05 pm, Sebastiano Vigna <vi...@dsi.unimi.it> wrote:
> When I requested authorization to Sonatype, that's the groupId they gave me and I didn't discuss. There's another problem: in the six months the DSI will no longer exists, so having a groupId associated to non-existing entity and to an ultimately non-registered domain seemed weird.

Say, are you going to move http://vigna.dsi.unimi.it/ (and friends)
somewhere accessible, or it is better to go backup everything of
interest right now, while there is time?

[Dawid Weiss]

> There's another problem: in the six months the DSI will no longer exists,

That's actually interesting -- is it department restructuring (domain
will cease to exist) or is it really a shutdown of the institute? This
would be sad.

Dawid

[Sebastiano Vigna]

On Feb 26, 2012, at 10:35 AM, Earwin wrote:

> Say, are you going to move http://vigna.dsi.unimi.it/ (and friends)
> somewhere accessible, or it is better to go backup everything of
> interest right now, while there is time?

Well... what do you mean? The site?

Ciao,

seba

[Sebastiano Vigna]

No, we're just merging with another department and we will change name.

Ciao,

seba

[Michael Ekstrand]

On 02/25/2012 06:57 AM, Sebastiano Vigna wrote:
> I'll have a look into this. I'll ask for a it.unimi.dsi groupid and
> restart the whole thing. Maybe there's an ivy task that does the OSGI
> stuff...

You already have it; what Sonatype gives you is a prefix. You're allowed
to publish under any groupID under it; since they've authorized you for
'it.unimi', you can push 'it.unimi.dsi'.

- Michael

--
Michael Ekstrand <ekst...@cs.umn.edu>
Ph.D candidate, Computer Science -- University of Minnesota
GroupLens Research: http://www.grouplens.org
window manager, n: a program for arranging multiple Emacs frames

[Holger Hoffstätte]

[sorry for any duplicate mails, posting seems broken]

Dawid,

Thanks for explaining and sorry for not answering earlier.

On 25.02.2012 13:13, Dawid Weiss wrote:
>>> >>> - I checked the manifest and the OSGi support is apparently gone,
>>> >>> since (I presume) you didn't know it was there or what it was. That
> >
> > I totally forgot about it. And it's going to be a pain to generate
> > manually -- see, I told you trying to cater for Maven plugins manually
> > will be an increasingly going sore point ;)

The metadata is easy to generate in a variety of ways; the
maven-bundle-plugin internally just uses the bnd tool [1].

The instructions for generating the metadata are easy and in fact
mostly
the built-in defaults, see [2]. The <instructions> are fed into bnd,
so
there is no reason why the same set of instructions cannot be used
with an
ant-based build process, using bnd's ant task. The syntax is slightly
different, but the reuslt will be exactly the same.

Btw I just realized that all this is fine for 99.9% of fastutil since
it
is is "only" a library and does nothing fancy wrt. classloading or
other
dynamic behaviour ... of course with the exception of the damn binary
Object IO, which will fail with ClassNotFound exceptions - as usual
with
stuff that relies on unrestricted class space access. :( But we can
tackle
that later.

> > The OSGi config is generated (in maven) by looking at class
> > relationships.

Typically the author of a bundle is expected to provide imports and
exports; the automagic generation is only a convenience to get started
and
for cases where the built-in rules are sufficient.

Anyway in the next couple of days I'll try to convert the pom bits
from
the maven build into the equivalent of the ant task. This will of
course
require the bnd jar to be added as build dependency. Where is the
"official" source repo/tracker? Could not find it so far.

cheers
Holger

[1] http://www.aqute.biz/Bnd/Bnd
[2] https://github.com/elehack/fastutil-maven/blob/master/pom.xml#L214

[Dawid Weiss]

Thanks Holger,

> require the bnd jar to be added as build dependency. Where is the
> "official" source repo/tracker? Could not find it so far.

I've been trying to convince Sebastiano to use github for some time
now (hint, hint), but as far as I know there is no "in-progress"
repository in the traditional sense. Only bundle releases are pushed
(sources and binaries).

Dawid

[Sebastiano Vigna]

On Mar 5, 2012, at 2:40 PM, Holger Hoffstätte wrote:

> require the bnd jar to be added as build dependency. Where is the
> "official" source repo/tracker? Could not find it so far.

There is no such thing. There might be in the future. But one week of my life went away fighting with the Mavenverse, and I don't intend to put into it any more time for a while. If we must do this OSGi thing, it must be easy.

Presently we have an explicit POM, but all other projects have a pom-model and use ivy:makepom. If that makes it easier for you, we can switch to POM models in fastutil, too...

Ciao,

seba