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.


--Brent
http://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
-~----------~----~----~----~------~----~------~--~---

Reply via email to