Drew,
Eh.
I'd rather uPortal not get (back) in the business of including and
versioning dependency binaries in source control. Dependencies ought to
be in Central, and there's a process for getting third party artifacts
into central when the projects don't get their act together to get their
own artifacts into central.
So, I still think the medium-term solution here is to step through this
https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifacts+to+The+Central+Repository
so that the disappeared dependencies are in Central. Central guarantees
that once a dependency is there published, then within reason it will
never disappear. Well-mirrored, solid culture, etc.
Medium term as in, say, in time for the uPortal 4.1 release, so that the
Calendar portlet could be included in that release.
Here's a pull request implementing the immediate-term solution of
dropping the calendar portlet and thereby fixing the build:
https://github.com/Jasig/uPortal/pull/265
Andrew
On 3/11/14, 10:43 AM, Drew Wills wrote:
Andrew,
I'd like to explore doing something like...
<dependency>
<groupId>caldav4j</groupId>
<artifactId>caldav4j</artifactId>
<version>1.0.0</version>
<scope>system</scope>
<systemPath>${project.basedir}/lib/caldav4j.jar</systemPath>
</dependency>
in the overlay.
drew
On 03/11/2014 07:30 AM, Andrew Petro wrote:
uPortal developers,
Thoughts on (temporarily) dropping the Calendar portlet outright from
master so as to un-break the uPortal build pending its inability to get
its dependencies from Central?
Pursuing in parallel getting those dependencies up as third-parties in
Central so the build un-breaks, at which point the portlet could return
to the quickstart?
I think it's the prudent move to minimize friction on other open
development loops.
Andrew
--
You are currently subscribed to [email protected] as:
[email protected]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/uportal-dev
