I tried Archiva a while back but it was too buggy and hard to install/configure at the time. I'm pretty sure that the UI and features of nexus are far and above Archiva. I believe that the Maven central repository uses nexus now as well.
--Brent On Wed, Nov 26, 2008 at 5:10 PM, Casper Bang <[EMAIL PROTECTED]> wrote: > > Hi Brent, > > Have you tried Archiva? And if so, what are the advantages of Nexus > over Archiva? > > /Casper > > On Nov 26, 9:03 pm, Brent <[EMAIL PROTECTED]> wrote: > > I highly recommend using Nexus maven repo manager. Pretty much > > everyone else is moving toward it for maven as well. > > > > http://nexus.sonatype.org/ > > > > Just take a look at the demo site. It's real easy to setup as well. > > I used to use artifactory, but switched to this one. > > > > --Brenthttp://geekyryan.blogspot.com/ > > > > On Nov 26, 2:09 pm, RogerV <[EMAIL PROTECTED]> wrote: > > > > > The animus expressed toward .XML style syntax is something that tends > > > to resonate with me. I do tend to like declarative approaches - which > > > both Ant and Maven more or less take - vs overly imperative approaches > > > to describing builds. Hence I tend to resist the temptation to take a > > > full blown scripting language approach to describing project builds. > > > > > As to another area where XML inflicts cognitive pain - Spring > > > Framework applicationContext.xml files. > > > > > I do believe in separating bean initialization away from compiled Java > > > code into a strictly interpreted-at-runtime text file of some kind. I > > > like a few annotations for some things but I don't want to use them to > > > fully replace the semantic actions that go on in > > > applicationContext.xml files. > > > > > I want a better bean configuration/initialization script language - > > > but not really an imperative language. I don't want to script logic > > > there, I just want to declare the initialization actions and the bean > > > relationships. > > > > > So hence I've grabbed ANTLR and am devising a new configuration DSL to > > > supplant XML. I'm calling it jfig. The syntax of jfig looks like this: > > > > > applicationContext.jfig > > > =============================================== > > > > > properties_include "classpath:application.properties"; > > > > > org.apache.commons.dbcp.BasicDataSource dataSource { > > > @destroy-method = close; > > > driverClassName = "${jdbc.driverClassName}"; > > > url = "${jdbc.url}"; > > > username = "${jdbc.username}"; > > > password = "${jdbc.password}"; > > > defaultAutoCommit = true; > > > > > } > > > > > org.springframework.orm.ibatis.SqlMapClientFactoryBean sqlMapClient { > > > configLocation = "classpath:sqlmap-config.xml"; > > > dataSource = $dataSource; > > > > > } > > > > > java.util.Properties props { > > > "James Ward" = "Adobe Flex evangelist"; > > > "Stu Stern" = "Gorilla Logic - Flex Monkey test automation"; > > > Dilbert = "character in popular comic strip of same title"; > > > > > } > > > > > java.util.HashMap map { > > > this($props); > > > > > } > > > > > =============================================== > > > > > The '@' prefixes Spring BeanDefintion attributes that can be set. > > > > > The '$' prefixes bean ID names when they're being referenced as a > > > dependency. > > > > > Obviously includes for Java .properties definitions are supported and > > > use the ${foo.bar} syntax for referencing property definitions in any > > > bean configuration. > > > > > Notice the 'this' keyword is used when doing constructor injection (as > > > opposed to setter injection). Constructor injection can still be > > > combined with setter injection too. > > > > > The java.util.Properties class is specially recognized so that it's > > > easy to initialize an instance with name/value pairs, and then that > > > can be used to initialize other beans that accept a Properties > > > argument. > > > > > A certain amount of type checking will be done during jfig config file > > > parsing. If a bean class doesn't exist on the classpath, or a property > > > is not found, or is not of a compatible type (same with constructor > > > args), then will fail on the spot, referencing the relevant lines in > > > the jfig file. > > > > > Very early days. I've got a working parser that processes this syntax > > > and instantiates these beans. I'm next going to rewrite the parse > > > actions to start invoking Spring Framework APIs for bean definition > > > and bean registration. > > > > > Later on I'll use ANTLR to creat an ActionScript runtime in order to > > > devise a mini dependency injection framework for Flex apps - using > > > this same jfig syntax. It'll hold the AST in memory as the so-called > > > "application context". To instantiate a requested bean will involve > > > traversing the AST to instantiate dependencies in a just-in-time > > > manner. > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
