Nice. That does indeed resolve the tactical issue with the uPortal project build:
https://travis-ci.org/Jasig/uPortal/builds/20647920 Does this mean that the <dependency> <groupId>xalan</groupId> <artifactId>serializer</artifactId> </dependency> in CalendarPortlet's pom.xml ought to be dropped? https://github.com/Jasig/CalendarPortlet/blob/master/pom.xml#L595 Andrew On 3/12/14, 6:00 PM, Drew Wills wrote: > Folks, > > I believe issue with the (offline) builds.osafoundation.org repo is > fixed. > > - https://issues.jasig.org/browse/UP-4024 > - > https://github.com/Jasig/uPortal/commit/99851d10babb88e8c9c795faa959d327d08a9412 > > It turned out to be much less sinister than originally thought. > > Yes, the xalan:serializer jar is natively hosted in a non-M2 Central > repo that is currently defunct. > > But... > > - Calendar doesn't actually appear to be using it; and > - uPortal was never getting its copy from there anyway > > The copy of xalan:serializer that gets deployed with uPortal *actually > does* come from M2 Central -- it's at > 'WEB-INF/lib/serializer-2.7.1.jar' within the > org.jasig.portlet:CalendarPortlet:war:2.1.3-M4 artifact. (Deep in the > WAR it overlays.) > > The build issue was owing to the following > uportal-portlets-overlay/CalendarPortlet dependency (which pulls in > the CalendarPortlet Java code in JAR form): > > <dependency> > <groupId>org.jasig.portlet</groupId> > <artifactId>CalendarPortlet</artifactId> > <version>${CalendarPortlet.version}</version> > <classifier>classes</classifier> > <type>jar</type> > <scope>provided</scope> > </dependency> > > Adding... > > <exclusions> > <exclusion> > <groupId>xalan</groupId> > <artifactId>serializer</artifactId> > </exclusion> > </exclusions> > > clears up the issue. > > drew > > On 03/11/2014 05:29 PM, Drew Wills wrote: >> Thanks Tim. >> >> Vicky was able to build today as well, on a new machine, by adding only >> the 1 dependency. >> >> But I also tried just removing the dependency that breaks the build -- >> xalan:serializer:2.7.0 -- and it succeeds! It looks like that >> dependency is no longer needed. >> >> I can probably cut a new release tomorrow. >> >> drew >> >> On 03/11/2014 12:28 PM, Tim Raymond wrote: >>> Drew, >>> I'm not sure if this answers your question; I added the content of the >>> xalan dir from one box to my new local .m2 dir, and after doing so the >>> build worked. >>> >>> >>> Tim Raymond >>> Director, Central Applications >>> Instructional and Information Technologies >>> California State Polytechnic University, Pomona >>> Phone: 909.869.6851 >>> Cell: 909.260.3200 >>> Fax: 909.979.6406 >>> >>> PGP Public Key: >>> https://keyserver2.pgp.com/vkd/DownloadKey.event?keyid=0x2FDBD1EADDC19329 >>> >>> >>> >>> >>> >>> On 3/11/14, 11:04 AM, "Drew Wills" <[email protected]> wrote: >>> >>>> On 03/11/2014 10:37 AM, Andrew Petro wrote: >>>>> So, I still think the medium-term solution here is to step through >>>>> this >>>>> >>>>> >>>>> https://docs.sonatype.org/display/Repository/Uploading+3rd-party+Artifact >>>>> >>>>> >>>>> s+to+The+Central+Repository >>>>> >>>> >>>> +1 for this approach in the medium term. >>>> >>>> For the long term, James submitted a ticket to the caldav4j project >>>> requesting that they push to M2 central. I think we should add our >>>> voices to that -- and maybe help them somehow. >>>> >>>> The only question is the short term. >>>> >>>> I'd be delighted to work on the medium- or short-term solution, but I >>>> can't promise that I will have the opportunity to do that between now >>>> and any certain date. (Are you available for that by chance?) >>>> >>>> Pulling the Calendar may mean that it's not included in 4.1. I don't >>>> want to check the caldav4j jar into the git repo any more than you do, >>>> but I think it's preferable to loosing the Calendar for the 4.1 >>>> release. >>>> >>>> The Calendar is a useful function for the platform that helps us make >>>> the case that the platform has features that you want. Being bundled, >>>> moreover, gets the Calendar in front of new people who way want to >>>> enhance, document, beautify, or troubleshoot it. >>>> >>>> Can anyone confirm or deny that the caldav4j jar is the only >>>> dependency >>>> causing the the issue? >>>> >>>> There is another approach we can take. We could factor the caldav >>>> support into a separate Maven sub-module and include it optionally >>>> -- in >>>> other words, not include it with the overlay -- until we can organize >>>> the medium- or long-term solution. >>>> >>>> drew >>>> >>>> >>>> -- >>>> 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 >>> >>> >> > -- 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
