Hi guys, Yesterday I had a discussion with Sonatype guys, especially Jason van Zyl to make our ops4j artifacts from http://repository.ops4j.org/maven2 and http://repository.ops4j.org/mvn-snapshots/ available via nexus at http://osgi.sonatype.org and/or http://oss.sonatype.org. The benefits, I guess, will be advanced repository control, staging before public access, staging before publishing to maven central, future federated access, automatically presence in OBR (when they have the support) and so on. I do not know exactly what are the benefits till I do not get my hands dirty with nexus but we will see. Even only the presence there alongside other open source stuff is good enough. Also I do not know by now if the sonatype repos are the ones that should be used to release to or are just proxy to our repos. I have to figure out. Anyhow regardless the fact that we do or not have the sonatype repos I think that is anyhow good to have a clean up.
You can follow the issue here: https://issues.sonatype.org/browse/OSSRH-14 But they complain about the fact that we host artifacts which are not ours as you will see bellow in a copy of my discussion. I do agree that we should separate them and I would say that is now also time to cleanup our repos of wrongly deployed artifacts or very old obsolete ones. So, I propose that we have this repos: http://repository.ops4j.org/mvn-releases - ops4j releases; should contain only released maven artifacts for the groups starting with org.ops4j http://repository.ops4j.org/mvn-snapshots - ops4j snapshots; should contain only released maven artifacts for the groups starting with org.ops4j http://repository.ops4j.org/mvn-3rdparty - 3rd party artifacts that we host To not break existing usage we may still have the http://repository.ops4j.org/maven2 but that one should be if possible only an uber repo of mvn-releases and mvn-3rdparty (Niclas? - apache http guru) And during this process I propose that we get rid of old stuff that we think that is not worth keeping anymore. or artifacts that were deployed int a wrong spot as for example http://repository.ops4j.org/maven2/pax/logging/ or http://repository.ops4j.org/maven2/test/test/ And if there are things that we are not sure about maybe it will just be better to not remove them but store them for a while in an "obsolete" dir on the file system so we may have them back online if requested with a good reason. There are also qi4j artifacts in ops4j repo so I suggest that for qi4j we create similar reos but under repository.qi4j.org. Maybe we should also review http://repository.ops4j.org/ subdirectories as I think not everything which is there is still useful. WDYT? -- Alin Dreghiciu http://www.ops4j.org - New Energy for OSS Communities - Open Participation Software. http://www.qi4j.org - New Energy for Java - Domain Driven Development. Looking for a job. Sent from Cluj-Napoca, CJ, Romania _______________________________________________ general mailing list general@lists.ops4j.org http://lists.ops4j.org/mailman/listinfo/general
