river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Ramsdale <jeff.ramsd...@gmail.com>
Subject Re: [Vote] (RIVER-432) Jar files in svn and src distributions
Date Wed, 12 Feb 2014 08:28:18 GMT
Somehow I didn't get Greg's message earlier--just seeing the full text now.

I think the multiple modules resulting in multiple Eclipse projects (for
instance) is a huge strength. Each artifact then has its own classpath and
significantly reduces the possibility of compilation or runtime errors.
Sure there's a little extra complexity in configuration, but that's to help
ensure dependency resolution is correct. As devs we need to be responsible
for the contents of our classpaths and Maven-repository-based tools are a
huge help in that.

Personally I far prefer Maven to Gradle. I do not see the ability to do
custom scripting as an advantage and I find having an XSD schema to work
from reduces errors. Scripting adds a lot of variables (no pun intended)
and could lead to an increased support load. On the other hand, once we
decide to use a dependency-based system over classdepandjar it shouldn't
matter which flavor we use as long as it is compatible with Maven
repository metadata.

-j


On Tue, Feb 11, 2014 at 5:22 PM, Greg Trasuk <trasukg@stratuscom.com> wrote:

>
> Those recommendations are more applicable to application services than
> those in the core River distribution.  FWIW, however, the core services are
> already mostly structured this way - downloadable classes are all in
> *-dl.jar files (e.g. reggie-dl.jar, mahalo-dl.jar, etc).  The only
> difference is that the core API classes like Registrar, JavaSpaces, etc,
> are in jsk-platform.jar.
>
> Now, I think most of us would agree that the 'classdepandjar' mechanism is
> a little clunky, so restructuring the build may help with that.
>
> I have been using Maven to build applications (e.g. the samples at
> https://github.com/trasukg/river-container-examples).  The only thing I
> find slightly irritating is that you end up with a proliferation of Maven
> modules, which equates to a proliferation of Netbeans or Eclipse projects.
>  With Maven, that's unavoidable, because Maven really really wants to have
> only one artifact produced per module.  So 'hello-api' requires its own
> module, as does 'hello-service' (for the implementation code), and
> 'hello-module' (the packaging for the container).  'hello-dl' would be
> another, if there were a smart proxy.  That's also not specific to Jini
> projects; you get the same thing in JEE6 projects - separate projects for
> the JPA module, EJB module, EJB API, Web module, etc.  Other build tools
> may be happier with multiple artifacts from one project.  Ant certainly is,
> but of course you drift into the complexities of the current build with
> 'classDepAndJar'.
>
> I think the first step might be to split out the infrastructure services
> like Reggie, Mahalo, and Outrigger into separate deliverables, leaving the
> contents of jsk-platform in the core module.  We'll have to do some
> thinking about how to structure the integration testing for that.
>
> Cheers,
>
> Greg Trasuk
>
>
>
> On Feb 11, 2014, at 6:52 PM, Rafał Krupiński <
> rafal.krupinski@sorcersoft.com> wrote:
>
> > Dnia 2014-02-11, wto o godzinie 15:59 +0100, Simon IJskes - QCG pisze:
> >> On 11-02-14 11:35, Peter wrote:
> >>
> >>> We will need a new build system for java 8, this looks like a step in
> that direction.  In reality we need to adopt the build conventions used by
> Rio.
> >>
> >> What are these? Maven?
> >
> > Not necessarily Maven, although Dennis mentions it.
> > http://www.rio-project.org/conventions.html#Project_Modules
> >
> > It works very well for our River/Rio services.
> >
> > Regards
> > Rafał Krupiński
> >
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message