Hi Richard,
It does involve patching more files. But there is a big difference - if you
follow my approach, then you are only patching the local files that you use
to build your installation of DSpace - i.e. you can start with the binary
distribution.
And the files that you are changing just sit within your immediate filepath
- there is no need to install them to your local Maven repository, and they
can't differ from the distributions in the central repository.
If you patch the DSpace API pom, then you need to install that into your
local Maven repository cache. That copy is then going to be different from
the "same" file that is in the central distribution. And then you'll get a
non-failing build, but broken runtime, simply by building on a different
machine, or even logging in as a different user on the same machine (as the
local Maven repository is stored within the user home directory).
So, my approach plays better with building in multiple environments,
including setting up a continuous integration server. This appears to be
the issue that you are running into - where the live environment is in fact
pulling the dspace-api pom from the central repository, and not using your
patched version.
Regards,
G
On 21 November 2012 12:55, Richard Jones <[email protected]> wrote:
> Hi Graham,
>
> Thanks - I considered the approach that you mention, but the only
> difference I could see was that it involved patching a lot more pom
> files. The issue, though, seems to be with the transitive
> dependencies - they are not being pulled into either the offline lib
> or the webapps, which is baffling me. Not least because it works fine
> in my dev environment, but not in the live environment.
>
> Cheers,
>
> Richard
>
> On Wed, Nov 21, 2012 at 12:03 PM, Graham Triggs <[email protected]>
> wrote:
> > Hi Richard,
> >
> > I'm not sure if that's a wise approach.
> >
> > The way I've done it, is that to inject dependencies into every (web)
> > application, I add a dependencies section to the pom.xml in the modules
> > directory (i.e. the parent of jspui, xmlui, etc.).
> >
> > And to inject dependencies into the offline 'lib' directory, I add it to
> the
> > pom.xml in the root of the binary distribution, or the 'dspace'
> directory of
> > the source distribution (i.e. the parent of the modules directory).
> >
> > I'm only adding the dependency to one JAR, and the other JAR(s) are
> always
> > being pulled in via its transitive dependencies.
> >
> > Two things you should watch out for though:
> >
> > 1) if you have dependencies on specific versions of JARs that are also
> > required by DSpace, you may need to add exclusions to stop it including
> the
> > ones referenced by DSpace.
> > 2) if you have dependencies on additional Spring modules, and don't
> provide
> > exact version numbers (e.g. you allow Maven to use a range of versions),
> > then Maven 3 will [probably] select the wrong version of your Spring
> module.
> >
> > Regards,
> > G
> >
> >
> > On 21 November 2012 10:44, Richard Jones <[email protected]> wrote:
> >>
> >> Hi Folks,
> >>
> >> A little further question about this ...
> >>
> >> I have had to work around the lack of support for adding code modules
> >> to the core of DSpace by patching the dspace-api pom.xml file so that
> >> my dependencies get pulled in everywhere they are relevant. I have
> >> encountered a strange problem though, which I haven't been able to
> >> resolve:
> >>
> >> In some environments, when I mvn clean package DSpace, my code
> >> library's jar file gets pulled in to all the webapps and to the core
> >> dspace lib directory, but none of /that/ library's dependencies get
> >> pulled in. So, the application doesn't work because whenever my code
> >> calls out to another library upon which it uniquely depends, there is
> >> a ClassNotFound exception.
> >>
> >> Perhaps there is an exclude filter somewhere in the build system, or a
> >> rule which says not to pull in certain dependencies?
> >>
> >> Cheers,
> >>
> >> Richard
> >>
> >>
> >> On Thu, Nov 1, 2012 at 10:37 AM, Richard Jones <[email protected]>
> >> wrote:
> >> > Hi Folks,
> >> >
> >> > Great, thanks for that - I think this is probably what I want, so when
> >> > we move to DSpace 3.0 I'll use that approach.
> >> >
> >> > Cheers,
> >> >
> >> > Richard
> >> >
> >> > On Tue, Oct 30, 2012 at 8:52 AM, helix84 <[email protected]> wrote:
> >> >> Hi Richard,
> >> >>
> >> >> Kevin just added this, I think it's related to what you're asking:
> >> >>
> >> >>
> >> >>
> https://wiki.duraspace.org/display/DSDOC3x/Advanced+Customisation#AdvancedCustomisation-Additionsmodule
> >> >>
> >> >> The change itself came from here:
> >> >> https://github.com/DSpace/DSpace/pull/3
> >> >>
> >> >> Regards,
> >> >> ~~helix84
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Monitor your physical, virtual and cloud infrastructure from a single
> >> web console. Get in-depth insight into apps, servers, databases, vmware,
> >> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
> >> Pricing starts from $795 for 25 servers or applications!
> >> http://p.sf.net/sfu/zoho_dev2dev_nov
> >>
> >> _______________________________________________
> >> Dspace-devel mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/dspace-devel
> >
> >
>
------------------------------------------------------------------------------
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
