when 0.9.4 ?

[David Bernard]

Hi,

When the next version will be releases ?
With the separeted jar (for maven's users), with errorCode in
exception, ...

Because, I try to develop with 0.9.3 but the javadoc (http://
code.sxip.com/openid4java/apidoc/) seems to point to the svn/snapshot
java source, and it's a pain.

Thanks.

PS: if need help to released, I can help.

[Sutra Zhou]

There is an issue can't be fixed now:
The dependency higgins-sts-*.jar can't be found in maven repository yet.

http://groups.google.com/group/openid4java/browse_thread/thread/8d3553bd19aa29ba?hl=en

2007/10/7, David Bernard <dwa...@free.fr>:

[David Bernard]

I could host it on my repository (http://alchim.sf.net/download/
releases or http://alchim.sf.net/download/snapshots), before
submitting it to central repo.

tips: to change the version number on pom.xml in one shot (because you
can't use the maven-release-plugin) :
$> find maven2 -name 'pom.xml' |xargs perl -pi -e 's/0.9.3/0.9.4-
SNAPSHOT/g'

I'll try to deploy openid4java-0.9.4-SNAPSHOTS to my snapshots
repository.

On Oct 7, 2:12 pm, "Sutra Zhou" <zhoushu...@gmail.com> wrote:
> There is an issue can't be fixed now:
> The dependency higgins-sts-*.jar can't be found in maven repository yet.
>

> http://groups.google.com/group/openid4java/browse_thread/thread/8d355...
>
> 2007/10/7, David Bernard <dway...@free.fr>:

[Sutra Zhou]

OK, thanks.

2007/10/7, David Bernard <dwa...@free.fr>:

I could host it on my repository (http://alchim.sf.net/download/

releases or http://alchim.sf.net/download/snapshots ), before

[Johnny Bufu]

Hi David,

On 7-Oct-07, at 5:08 AM, David Bernard wrote:
> When the next version will be releases ?

0.9.4 was released a couple of weeks ago.
http://openid.net/pipermail/general/2007-September/003519.html

Sorry, I should have posted a message here, too. Not sure what's the
status of the maven-related issues.

Johnny

[David Bernard]

Ah, thanks for the news (I'll try this version with my current project (a wicket consumer).

Suggestions to avoid others repeat my mistake :
* tell on the home page http://code.google.com/p/openid4java/ what is the last version
* also put archive on the download section of google
* tag the version on SVN
* submit a bundle(s) to maven repo
* update the version into the pom.xml from maven's dir and samples

I've started to work on the maven deployment of openid4java, and I continue (I'll replace 0.9.4-SNAPSHOT by 0.9.5-SNAPSHOT ;-) ).
I'll submit a patch when it was done.
I'll also deploy 0.9.4 and 0.9.5-SNAPSHOT on my public repository.

Thx.

[David Bernard]

* set version to 0.9.5-SNAPSHOT
* clean up : to have simple pom.xml (readable and maintenable)
* remove duplication between children's pom.xml and parent's pom.xml
(groupId, version, developers, scm, ...)
* comments scm information, must not be used by maven's plugin
(normal scm point to the root project = directory with the pom.xml for
svn)
* define dependencyManagement into the parent's pom.xml to manage
version number in a central point
* change the groupId of higgins to org.eclipse.higgins (follow the
convention)
* use ${groupId} and {$version} for dependency to other openid4java
children projects
* upgrade version of jetty to 6.1.6rc0 (and fix the groupId)
* remove optional dependencies of commons-logging (not mark as
optional : every logging system that could be wrapped)
* deploy higgins on a repository http://alchim.sf.net/download/snapshots/
(create pom.xml and a deploy.sh)
* deploy openid4java-0.9.4.339.jar on a repository http://alchim.sf.net/download/releases/
* remove the build/reporting section from the children project,
because there is to many compilation error due to lake of class.
* generate a basic maven site (reports, javadoc) for 0.9.5-SNAPSHOT
avaliable at http://alchim.sf.net/openid4java/ (and main of 0.9.5-
SNAPSHOT javadoc at http://alchim.sourceforge.net/openid4java/openid4java/apidocs/index.html)

Because :
* the original project isn't split into several projects, to maintain
the include/exclude of the build will be a hard task
* the full jar isn't currently heavy 600K
* the main goal of the maven sub project is to provide a clear
definition of dependencies
Then
* I define every dependencies of openid4java to scope provided or
test, remove compile and runtime
* other subproject are converted into "meta-project" (like meta
package in linux distro), provide an empty jar and define the required
(compile/runtime) dependencies.
* I remove the build, reporting section from "meta-project"

So maven user define a dependency of its project with the meta-project
(and not directly with openid4java (may be rename it to openid4java-
core/nodep/... to avoid bug when user will upgrade from 0.9.3 or
0.9.4)

Obviously, when the original project will be split or converted to
maven, the jar generated will be lighter and the pom will be correct
and uptodate.

Todo :
* optimise dependencies (eg: does openid4java-infocard depends of
openid4java or openid4java-server ?)
* check the new pom.xml (dependencies) by a core developper
* more end user tests/feedback
* submit fix to maven central repo about
* openxri depencencies
* for a pom for xmlsec-1.3.0

(the changeset is attached to issue (see tracker), it's not a patch
but a directory to install at the save level as maven2 dir, to allow
install it and test it in a parallele directory, if you prefer i could
submit a patch for maven2 directory)

For maven users of 0.9.4
add into your pom.xml

<repositories>
<repository>
<id>alchim</id>
<name>Achim Repository</name>
<url>http://alchim.sf.net/download/releases</url>
<releases />
</repository>
</repositories>

...
<dependency>
<groupId>org.openid4java</groupId>
<artifactId>openid4java</artifactId>
<version>0.9.4.339</version>
</dependency>

For maven users of 0.9.5-SNAPSHOT

<repositories>
<repository>
<id>alchim.snapshots</id>
<name>Achim Repository Snapshots</name>
<url>http://alchim.sf.net/download/snapshots</url>
<snapshots />
</repository>
</repositories>

...
<dependency>
<groupId>org.openid4java</groupId>
<artifactId>openid4java-consumer</artifactId>
<!--artifactId>openid4java-server</artifactId-->
<version>0.9.5-SNAPSHOT</version>
</dependency>

feedbacks ?? (want other reports,...)

[David Bernard]

And I also added myselft as contributor in the pom.xml ;-)

[Sutra Zhou]

Provide a patch, then I can merge them to the svn trunk?

2007/10/8, David Bernard <dwa...@free.fr>:

[Sutra Zhou]

Oh, i've got the patch here: http://code.google.com/p/openid4java/issues/detail?id=34
Thanks.

2007/10/8, Sutra Zhou < zhous...@gmail.com>:

[Sutra Zhou]

Dear David,
You set the dependencies in openid4java/pom.xml as provided.
Then if some use it, the jars are missing.
What about this?

Sutra

2007/10/8, David Bernard < dwa...@free.fr>:

Sorry, I can't attach a svn patch with comment in the issue tracker, so I attach it here

[David Bernard]

Sustra,

Users must not declare dependency to openid4java but to one (or more)
of the "meta-project" openid4java-consumer, openid4java-server,... as
explain above. It is also why, I suggest to rename openid4java to
something like openid4java-
core/nodep/private... to avoid bug and confusion for users when user

will upgrade from 0.9.3 or

0.9.4, or simply use it.

David

[Sutra Zhou]

What about extracting the provided dependencies to the openid4java-parent(also set them as provided)?

2007/10/9, David Bernard <dwa...@free.fr>:

[David Bernard]

in the parent I don't define dependencies (except logging) but
dependencyManagement so the version and the scope used by every
children project. Children project only need to tell the groupId and
the artifactId (and override scope if need).
If I set scope to provided in parent then I need to override scope in
every children need it (1, 2, 3 or more override). But like it's done
I only need to override in openid4java(-private), and like that I show
explicitly that I don't want dependencies for it.

is it clear ?

[Sutra Zhou]

It looks like that extracting to parent can not resolve this problem.

Let's rename the openid4java to openid4java-core/nodep/private, and add a new project 'openid4java' to handler the full of openid4java.

I think 'openid4java-nodep' is the best.

2007/10/9, Sutra Zhou <zhous...@gmail.com>:

[David Bernard]

OK for openid4java-nodep, but I see the need for a new project with
full dep => more confusion for users

On Oct 8, 7:05 pm, "Sutra Zhou" <zhoushu...@gmail.com> wrote:
> It looks like that extracting to parent can not resolve this problem.
>
> Let's rename the openid4java to openid4java-core/nodep/private, and add a
> new project 'openid4java' to handler the full of openid4java.
>
> I think 'openid4java-nodep' is the best.
>

> 2007/10/9, Sutra Zhou <zhoushu...@gmail.com>:

>
>
>
> > What about extracting the provided dependencies to the
> > openid4java-parent(also set them as provided)?
>

> > 2007/10/9, David Bernard <dway...@free.fr>:

[Johan Karlberg]

I agree that there should be an openid4java-core module that -server and -consumer and similar depend on, but I was under the impression that the openi4java module itself is there to allow for automatic upgrade of existing projects that depend on artifactId openid4java. My preference is to drop the openid4java artifactId completely, forcing people to update their poms, but if that isn't acceptable, I wonder if we can't have a virtual module that just depends on -core, -consumer, -server, sample-* and so on, though, if maven supports this, leaving us with less artifacts duplicating the relevant classes, and less trouble if people get this library as a transitive dependency from two places, and each uses their own artifact (like with spring currently, some include the full spring, and some just the partial jars)

Johan

[Sutra Zhou]

Done.
Currently:

Sub projects:

openid4java:
    All of openid4java.

openid4java-consumer:
    OpenID consumer.

openid4java-infocard:
    Infocard support.

openid4java-server:
    OpenID server.

openid4java-server-JdbcServerAssociationStore:
    An association store implementention with springframework(http://www.springframework.org/) jdbc.

openid4java-consumer-SampleConsumer:
    Sample code of consumer.

openid4java-server-SampleServer:
    Sample code of server.

openid4java-nodeps
    Holds all java source of OpenID4Java, but without any dependencies.
    This a private project for openid4java itself to use.

2007/10/9, Johan Karlberg <johan.k...@gmail.com>:

[David Bernard]

Nice :-)

two changes to made :
* move the exclusions of commons-httpclient from openide4java-
consumer, openide4java-server to openid4java-parent (it's a common
configuration shared by every modules)
<exclusions>
<exclusion>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
</exclusion>
</exclusions>
* in the parent/root's pom.xml, the replace ${artifactId} by
openid4java at the end (in the site definition) to allow a correct
deployment of module's report
<site>
<id>alchim.sf.net</id>
<name>sourceforge</name>
<url>scp://alchim.sf.net/home/groups/a/al/
alchim/htdocs/openid4java</url>
</site>
</distributionManagement>
</profile>
</profiles>
</project>

[David Bernard]

Sustra

Why did you rollback the version I set to 0.9.5-SNAPSHOT to 0.9.3 ?
0.9.3 is already published and tagged
0.9.4 is already published by sxip (see above) but not tagged

I also suggest to change everywhere in the code 0.9.4 and 0.9.3 to
0.9.5-SNAPSHOT.

[Sutra Zhou]

Version number will be changed when we upload to ibiblio.
I'll upload to ibiblio after we fixed the maven scripts.

2007/10/10, David Bernard < dwa...@free.fr>:

[David Bernard]

If I understand you the version 0.9.4 announced below doesn't exist !!

The common way to work (w/o maven) is :
* work on x.a-SNAPSHOT
* release
* change the version on local copy from x.a-SNAPSHOT to x.a
* test+package the artifact
* commit the change
* tag the version on scm (svn, cvs, mercurial,...)
* deploy/publish the artifacts (jar, javadoc, site, project's archives,...) on forge (sourceforge, code.google,...), maven's repository,...
* change/increment the version from x.a to x.b-SNAPSHOT (x.a.1-SNAPSHOT, y.0,...)
* commit change
* (optional) publish announce
* work on x.b-SNAPSHOT
...

=> when a version is release, nobody work on it implicitly (from scm trunk/head we work on next)
=> no confusion when svn user use, install artifacts on local repository and want to work with several version
=> versionning isn't liked to maven (eg: v 0.9.4 isn't available on ibiblio, note I've got different behavior between 0.9.4 and 0.9.3/0.9.5-SNAPSHOT, see Defects on IssueTracker)
=> work with CI tools
=> process of releasing clear

The SNAPSHOT prefix is different from apha, beta, milestone modifier, because it means that the content of the artifact could change at the next download/usage, it didn't inform about the quality of
the content.

david

[Sutra Zhou]

Hi David,
I've made a branch named 'openid4java-0.9.4' just now, this branch's java source is identify to java-openid-sxip-0.9.4.339.tar.gz that released on http://code.sxip.com/openid4java/ .
Please switch your work copy to this branch by:
$ svn sw https://openid4java.googlecode.com/svn/branches/openid4java-0.9.4

And I've fix first of the two changes as I don't know how to fix the second one:

After we check all the issues of maven scripts. I'll make a tag from this branch and upload it to ibiblio.

2007/10/10, David Bernard <dwa...@free.fr>:

[David Bernard]

I submitted a patch (http://code.google.com/p/openid4java/issues/detail?id=38)

Due to current work on failures with simple-openid from trunk, I checkout a fresh version and then switch.
I notice during the checkout, lot of jar and duplicate jar accross all the project. I think I clean up/reorg should be plan.

For the trunk, what is the version 0.9.5-SNAPSHOT ?

FYI: I'm not member of the team, so to checkout and to swith, I used http and not https.

david

PS: thanks for integrating my previous patches.

[Sutra Zhou]

The patch in issue 38 has been applied, thanks.

If there is no more issue about maven scripts in the next week, I'll upload it to ibiblio and merge the branch to trunk.

2007/10/11, David Bernard < dwa...@free.fr>:

I submitted a patch ( http://code.google.com/p/openid4java/issues/detail?id=38)

[Sutra Zhou]

Any on can help me to create a upload bundle(http://maven.apache.org/guides/mini/guide-central-repository-upload.html).
Or tell me how to do, as the follow are not work:
%cd maven2
%mvn -e repository:bundle-create
+ Error stacktraces are turned on.
[INFO] Scanning for projects...
[INFO] Reactor build order:
[INFO]   OpenID4Java Parent
[INFO]   OpenID4Java no dependencies
[INFO]   OpenID4Java Consumer
[INFO]   OpenID4Java Server
[INFO]   OpenID4Java Infocard
[INFO]   OpenID4Java Server JdbcServerAssociationStore
[INFO]   OpenID4Java Consumer SampleConsumer
[INFO]   OpenID4Java Server SampleServer
[INFO]   OpenID4Java
[INFO] Searching repository for plugin with prefix: 'repository'.
[INFO] ----------------------------------------------------------------------------
[INFO] Building OpenID4Java Parent
[INFO]    task-segment: [repository:bundle-create]
[INFO] ----------------------------------------------------------------------------
[INFO] Preparing repository:bundle-create
[INFO] [site:attach-descriptor]
[INFO] [repository:bundle-create]
[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------
[INFO] Packaging cannot be POM when creating an upload bundle.
[INFO] ------------------------------------------------------------------------
[INFO] Trace
org.apache.maven.lifecycle.LifecycleExecutionException : Packaging cannot be POM when creating an upload bundle.
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:564)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeStandaloneGoal (DefaultLifecycleExecutor.java:493)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoal(DefaultLifecycleExecutor.java:463)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures (DefaultLifecycleExecutor.java:311)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:278)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute (DefaultLifecycleExecutor.java:143)
        at org.apache.maven.DefaultMaven.doExecute(DefaultMaven.java:334)
        at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:125)
        at org.apache.maven.cli.MavenCli.main (MavenCli.java:280)
        at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
        at sun.reflect.DelegatingMethodAccessorImpl.invoke (DelegatingMethodAccessorImpl.java:25)
        at java.lang.reflect.Method.invoke(Method.java:585)
        at org.codehaus.classworlds.Launcher.launchEnhanced(Launcher.java:315)
        at org.codehaus.classworlds.Launcher.launch (Launcher.java:255)
        at org.codehaus.classworlds.Launcher.mainWithExitCode(Launcher.java:430)
        at org.codehaus.classworlds.Launcher.main(Launcher.java:375)
Caused by: org.apache.maven.plugin.MojoExecutionException : Packaging cannot be POM when creating an upload bundle.
        at org.apache.maven.plugins.repository.BundleCreateMojo.execute(BundleCreateMojo.java:71)
        at org.apache.maven.plugin.DefaultPluginManager.executeMojo (DefaultPluginManager.java:443)
        at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:539)
        ... 16 more
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4 seconds
[INFO] Finished at: Tue Oct 30 01:55:49 CST 2007
[INFO] Final Memory: 5M/10M
[INFO] ------------------------------------------------------------------------

Should I create the sub projects one by one?

2007/10/12, Sutra Zhou <zhous...@gmail.com>:

[Johnny Bufu]

Hello everybody,

Since we're going forward with two packaging methods we need to
better coordinate the release process between the two in order to
avoid inconsistencies and confusions.

So I've posted on the wiki David's the workflow that David proposed a
while ago, and filled in the details for the Ant part:

http://code.google.com/p/openid4java/wiki/ReleaseProcess

Sutra and David (or anyone else maven-savvy): can you please do the
same for the maven part?

It would also be great if maven could use the version from the
project.properties (I've posted a TODO item on the wiki page), rather
than having to manually update it in a bunch of pom files.

Thanks!
Johnny

[David Bernard]

Hi,

I didn't know this limitation of bundle-create.

I think, that if you create bundle for one by one for each project, then you could upload them, but user can't used them due to the dependencies on openide4java-parent not uploaded.
We have 2 solutions, at least :
1. deploying jars (and dependencies higgings) on a repository under svn (at the same level as wiki), using svn as a file system (+0)
2. I could deploy jars on my alchim.sf.net repository where I already deploy snapshots and higgins

If we want user don't need to declare our repository in his pom, we could request a sync from central repo with our respository for the groupId org.openid4java. This possibility isn't available with a
repository under svn (iirc), the sync is already enable with the alchim.sf.net repository for the groupId net.sf.alchim.
see section "Sync'ing your own repository to the central repository automatically" in the link you provide.

/david

[Johnny Bufu]

> http://code.google.com/p/openid4java/wiki/ReleaseProcess
>
> Sutra and David (or anyone else maven-savvy): can you please do the
> same for the maven part?

Thanks for the maven part Sutra! I have a couple of questions though:

* test and package the artifact
* ant: trunk/: ant dist --> java-openid-sxip-x.b.rev.tar.gz
*maven: trunk/maven2/: mvn package --> openid4java-SUB_PROJECT/
target/SUB_PROJECT-x.b.rev.jar
*commit the change

Do we need the commit above? Neither ant nor maven packaging seem to
modify the local copy.

How are the jar published to the maven repositories? (I assume this
is required in order for the whole thing to work if someone downloads
the package and uses the maven scripts.)

Thanks!
Johnny

[David Bernard]

Johnny Bufu wrote:
>
>> http://code.google.com/p/openid4java/wiki/ReleaseProcess
>>
>> Sutra and David (or anyone else maven-savvy): can you please do the
>> same for the maven part?
>
> Thanks for the maven part Sutra! I have a couple of questions though:
>
> * test and package the artifact
> * ant: trunk/: ant dist --> java-openid-sxip-x.b.rev.tar.gz
> *maven: trunk/maven2/: mvn package --> openid4java-SUB_PROJECT/
> target/SUB_PROJECT-x.b.rev.jar
> *commit the change
>
> Do we need the commit above? Neither ant nor maven packaging seem to
> modify the local copy.

I think, the commit is needed in case of change of fix last minute tests,... And commiting before tagging is a good practice. IMHO, if you want to remove a commit, remove the previous one just after
change of version.

> How are the jar published to the maven repositories? (I assume this
> is required in order for the whole thing to work if someone downloads
> the package and uses the maven scripts.)

To be usable/downloadable by maven a jar must be accessible from a repository :
* the local (cache) repository
* a remote repository, the default one is central repo, but it's possible to define other one (what I did for higgins)
* an embedded repository, it's like the classic lib dir from ant with the same problems. IMO using embedded repository is only for end application, not for lib and frameworks

Being and central repository as several advantages :
* better visibility, indexing by mvnrepository.com
* users don't need to define repository into its pom

To be publishing on central repository :
* you must filled a JIRA request with the bundle to publish (for every artifact and version). Didn't work for project with packaging != jar (in our case openid4java-parent isn't a jar) => not
available for us
* you must deploy artifact into a repository that is sync/mirrored into central repository
* require one JIRA request for a groupId

I already configure the pom to be deployable on the alchim.sf.net repositories (snapshots and releases).
I could :
* publish the artifact 0.9.4 and 0.9.5-SNAPSHOT under it (and the maven site ?).
* request sync from central repo to alchim.sf.net for releases of the groupId org.openid4java (already done for other groupId)
* give you permissions to deploy on alchim.sf.net (I need the sourceforge account) for later

What is your opinion ?

[Johnny Bufu]

On 31-Oct-07, at 2:00 AM, David Bernard wrote:
>> * test and package the artifact
>> * ant: trunk/: ant dist --> java-openid-sxip-x.b.rev.tar.gz
>> *maven: trunk/maven2/: mvn package --> openid4java-SUB_PROJECT/
>> target/SUB_PROJECT-x.b.rev.jar
>> *commit the change
>>
>> Do we need the commit above? Neither ant nor maven packaging seem to
>> modify the local copy.
>
> I think, the commit is needed in case of change of fix last minute
> tests,...

If there are local patches, you would be back at the previous
'working on snapshot'. That is: the preparation step should not break
any tests.

> And commiting before tagging is a good practice.

Right, but I was saying that following the release process there are
no local changes to commit.

> IMHO, if you want to remove a commit, remove the previous one just
> after
> change of version.

The ant packaging puts the svn rev in the package name and VERSION
file, so that it's easy to tell at any time what code is inside.

Johnny

[Johnny Bufu]

On 31-Oct-07, at 2:00 AM, David Bernard wrote:

> To be usable/downloadable by maven a jar must be accessible from a
> repository :
> * the local (cache) repository
> * a remote repository, the default one is central repo, but it's
> possible to define other one (what I did for higgins)
> * an embedded repository, it's like the classic lib dir from ant
> with the same problems. IMO using embedded repository is only for
> end application, not for lib and frameworks
>
> Being and central repository as several advantages :
> * better visibility, indexing by mvnrepository.com
> * users don't need to define repository into its pom
>
> To be publishing on central repository :
> * you must filled a JIRA request with the bundle to publish (for
> every artifact and version). Didn't work for project with
> packaging != jar (in our case openid4java-parent isn't a jar) => not
> available for us

How can the sub-projects under samples/ be distributed using maven?

> * you must deploy artifact into a repository that is sync/mirrored
> into central repository
> * require one JIRA request for a groupId

So before announcing a new releases, we have to wait for the maven
repository admins to approve this request so that the new jars are
available?

> I already configure the pom to be deployable on the alchim.sf.net
> repositories (snapshots and releases).
> I could :
> * publish the artifact 0.9.4 and 0.9.5-SNAPSHOT under it (and the
> maven site ?).
> * request sync from central repo to alchim.sf.net for releases of
> the groupId org.openid4java (already done for other groupId)
> * give you permissions to deploy on alchim.sf.net (I need the
> sourceforge account) for later

What's the advantage of using repository other than maven's default /
central?

Johnny

[David Bernard]

Johnny Bufu wrote:
>
> On 31-Oct-07, at 2:00 AM, David Bernard wrote:
>> To be usable/downloadable by maven a jar must be accessible from a
>> repository :
>> * the local (cache) repository
>> * a remote repository, the default one is central repo, but it's
>> possible to define other one (what I did for higgins)
>> * an embedded repository, it's like the classic lib dir from ant
>> with the same problems. IMO using embedded repository is only for
>> end application, not for lib and frameworks
>>
>> Being and central repository as several advantages :
>> * better visibility, indexing by mvnrepository.com
>> * users don't need to define repository into its pom
>>
>> To be publishing on central repository :
>> * you must filled a JIRA request with the bundle to publish (for
>> every artifact and version). Didn't work for project with
>> packaging != jar (in our case openid4java-parent isn't a jar) => not
>> available for us
>
> How can the sub-projects under samples/ be distributed using maven?

Several possibilities in maven world:
* samples aren't lib, do we really need to distribute them throught a repository (central) ? or simply provide an archive with sample
* using "assembly", assemblies are archives (tarball, zip,...) with free contents (xml definition)
there is some predefined package src, project, jar-with-dependencies
* define samples as a jar or war
*may be others, I'm not an expert...

In my case, to have more "realist" samples (remove advantages to be part of the project), i manage them as separate projects.
And I distribute them with there own archive or/and war.

>
>> * you must deploy artifact into a repository that is sync/mirrored
>> into central repository
>> * require one JIRA request for a groupId
>
> So before announcing a new releases, we have to wait for the maven
> repository admins to approve this request so that the new jars are
> available?

maven admins approve/apply JIRA request pour publication on central.
There 2 main types of request :
* publishing one bundle
* ask for enableling an automatic sync from a repository, that requester manage
The second solution is better :
* less work for maven admin (they delegate the management of a groupId to an other server).
* less work for publisher (we), we manage publication on our repository when we can publish what "we want" and 24h later it is available on central repo (if under the mirrored groupId, other things
aren't mirrored)
* users could use central repo or our repository

>
>> I already configure the pom to be deployable on the alchim.sf.net
>> repositories (snapshots and releases).
>> I could :
>> * publish the artifact 0.9.4 and 0.9.5-SNAPSHOT under it (and the
>> maven site ?).
>> * request sync from central repo to alchim.sf.net for releases of
>> the groupId org.openid4java (already done for other groupId)
>> * give you permissions to deploy on alchim.sf.net (I need the
>> sourceforge account) for later
>
> What's the advantage of using repository other than maven's default /
> central?

* we could use sync/mirror to central repo less manual work (see above)
* we could host higgins and other lib not available on central repo and reference them from any poms
* we could publish snapshot version (outside mirrored area)

/david