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 06:41:52 GMT
I agree with Dennis--modern dependency management is way more elegant and
less error-prone than classdepandjar.

-j


On Tue, Feb 11, 2014 at 6:35 PM, Dennis Reedy <dennis.reedy@gmail.com>wrote:

>
>
> Sent from my iPhone
>
> > On Feb 11, 2014, at 8:22 PM, Greg Trasuk <trasukg@stratuscom.com> wrote:
> >
> >
> > Those recommendations are more applicable to application services than
> those in the core River distribution.
>
> I disagree. River core services exhibit the same exact structure as
> application services, the only difference being that River services are
> produced by the River project.
>
> The referenced conventions mention Maven, but are applicable for other
> project/build tools, including Gradle.
>
> IMO, the most straight forward thing to do is to create a multi-module
> build that creates jars equivalent to the classdepandjar created jars.
>
> Regards
>
> Dennis
>
> > 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