FELIPE, TE ENVIO ESTAS NOVEDADES, AUN SIGUEN INTENTANDO RESOLVER EL
PROBLEMA, LO BUENO ES QUE YA SABEN EXACTAMENTE LO QUE OCURRIO HACE 3 DIAS.
2010/11/11 <[email protected]>
> Send Dspace-devel mailing list submissions to
> [email protected]
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
> or, via email, send a message with subject or body 'help' to
> [email protected]
>
> You can reach the person managing the list at
> [email protected]
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Dspace-devel digest..."
>
>
> Today's Topics:
>
> 1. Re: Recent Bamboo build failures -- trying to track down
> exact cause (Mark Diggory)
> 2. Re: Recent Bamboo build failures -- trying to track down
> exact cause (Tim Donohue)
> 3. Re: Recent Bamboo build failures -- trying to track down
> exact cause (Mark Diggory)
> 4. [DuraSpace JIRA] Updated: (DS-525) Move item - inherit
> default policies of destination collection
> (Stuart Lewis (DuraSpace JIRA))
> 5. [DuraSpace JIRA] Resolved: (DS-525) Move item - inherit
> default policies of destination collection
> (Stuart Lewis (DuraSpace JIRA))
> 6. [DuraSpace JIRA] Assigned: (DS-640) Interal System Error when
> browsing with wrong argument (Kim Shepherd (DuraSpace JIRA))
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Thu, 11 Nov 2010 12:07:54 -0800
> From: Mark Diggory <[email protected]>
> Subject: Re: [Dspace-devel] Recent Bamboo build failures -- trying to
> track down exact cause
> To: [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=UTF-8
>
> Firstly, it shouldn't matter, but the build was originally configured
> to be in [dspace-source] and only peform packaging and test of the
> addons, not the complete assembly.
>
> Inbetween traveling and meetings I've determined the error is caused
> because the dspace-ui-shared war overlays artifact is not getting
> properly attached in the maven reactor. We use overlays inside
> [dspace-source]/dspace for discovery and languages.
>
> In the case of languages, its an asyncronous release and we have no
> problems.
>
> In the case of discovery, it is in the build and the overlay will
> break if tests are run in that directory.
>
> I'm researching if I can get the artifact properly registered in the
> maven reactor. Alternatives are...
>
> 1.) move the dspace-ui-share dependencies out of dspace-jspui-webapp
> and dspace-xmlui-webapp and only build at [dspace-source] with
> -Paddons
> 2.) move dspace-ui-share into "modules" and release it asynchronously.
> 3.) copy the contents of dspace-ui-shared into both
> dspace-xmlui-webapp and dspace-jspui-webapp and get rid of it, only
> test from [dspace-source] with -Paddons.
>
> Given my past opinion on the contents of dspace-ui-shared not just
> being copied into the two other webapps, I prefer (3) and tolerate
> (1). I feel we are not quite ready for (2)
>
> Mark
>
>
> e build is for test
>
> On Thu, Nov 11, 2010 at 11:49 AM, Mark H. Wood <[email protected]> wrote:
> > I note that the build seems to start in [DSpace-source] rather than
> > [DSpace-source]/dspace. ?Strange things happen when doing that. ?I've
> > never worked out why. ?It definitely makes the Reactor build in a
> > different order.
> >
> > --
> > Mark H. Wood, Lead System Programmer ? [email protected]
> > Balance your desire for bells and whistles with the reality that only a
> > little more than 2 percent of world population has broadband.
> > ? ? ? ?-- Ledford and Tyler, _Google Analytics 2.0_
> >
> >
> ------------------------------------------------------------------------------
> > Centralized Desktop Delivery: Dell and VMware Reference Architecture
> > Simplifying enterprise desktop deployment and management using
> > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> > client virtualization framework. Read more!
> > http://p.sf.net/sfu/dell-eql-dev2dev
> > _______________________________________________
> > Dspace-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/dspace-devel
> >
> >
>
>
>
> --
> Mark R. Diggory
> @mire -?www.atmire.com
> 533 2nd Street - Encinitas, CA 92024 - USA
> Technologielaan 9 - 3001 Heverlee - Belgium
>
>
>
> ------------------------------
>
> Message: 2
> Date: Thu, 11 Nov 2010 14:14:41 -0600
> From: Tim Donohue <[email protected]>
> Subject: Re: [Dspace-devel] Recent Bamboo build failures -- trying to
> track down exact cause
> To: Mark Diggory <[email protected]>
> Cc: [email protected]
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=UTF-8; format=flowed
>
> On 11/11/2010 2:07 PM, Mark Diggory wrote:
> > I'm researching if I can get the artifact properly registered in the
> > maven reactor. Alternatives are...
> >
> > 1.) move the dspace-ui-share dependencies out of dspace-jspui-webapp
> > and dspace-xmlui-webapp and only build at [dspace-source] with
> > -Paddons
> > 2.) move dspace-ui-share into "modules" and release it asynchronously.
> > 3.) copy the contents of dspace-ui-shared into both
> > dspace-xmlui-webapp and dspace-jspui-webapp and get rid of it, only
> > test from [dspace-source] with -Paddons.
> >
> > Given my past opinion on the contents of dspace-ui-shared not just
> > being copied into the two other webapps, I prefer (3) and tolerate
> > (1). I feel we are not quite ready for (2)
>
> I'd vote for #3 -- personally, I've never really liked having 5
> javascript files be their own "dspace-ui-share" module. Each interface
> should use it's own javascript as it needs to -- and not be reliant on
> using the same version of scriptaculous JS as the other UIs.
>
> - Tim
>
>
>
> ------------------------------
>
> Message: 3
> Date: Thu, 11 Nov 2010 12:15:39 -0800
> From: Mark Diggory <[email protected]>
> Subject: Re: [Dspace-devel] Recent Bamboo build failures -- trying to
> track down exact cause
> To: Tim Donohue <[email protected]>
> Cc: [email protected]
> Message-ID:
> <[email protected]>
> Content-Type: text/plain; charset=UTF-8
>
> On Thu, Nov 11, 2010 at 12:06 PM, Tim Donohue <[email protected]>
> wrote:
> > Hi Mark W,
> >
> > Unfortunately, your suggestion to change directories doesn't seem to
> > matter. ?Locally, on my own machine, I can achieve the same error
> > messages whether I run this command from [dspace-source] or
> > [dspace-source]/dspace/
> >
> > mvn package test -Dmaven.test.skip=false
> >
> > So, I don't think it's a problem with Bamboo (or how Bamboo is setup to
> > run). ?I think it's a problem with our Maven pom.xml files -- as I can
> > achieve the same errors even without using Bamboo.
>
> As I said. And we will want to consider Bamboo a "test execution
> environment" we may do releasing there sometime soon. But doing the
> complete assembly there yet isn't a requirement for the release.
>
> >
> > ?From what I've been able to tell searching around online, it's possible
> > Maven is getting confused about dependency management. ?Digging into our
> > pom.xml files, we have a ton of repetition between POMs -- where a child
> > POM overwrites dependencies/settings with the same values as their
> > parent POM.
>
> yes, the dspace-ui-shared not getting attached.
> >
> > I've done some cleaning of the Discovery POMs locally (which seem to be
> > the messiest and most repetitive -- likely cause it used to be a totally
> > separate module). ?I *believe* I just succeeded in fixing the error
> > reported in the building & testing of 'dspace-discovery-xmlui-webapp'.
> > Unfortunately, now I'm getting the *exact same* error in the building &
> > testing of 'dspace-xmlui-webapp' (again, based on 'dspace-xmlui-api'
> > being unable to be copied properly). ?So, this may not be a single
> > problem caused by a single POM -- it may be a problem of how several of
> > our POMs are currently interacting (especially those that depend on
> > 'dspace-xmlui-api').
>
> I don't think that discovery was the original problem I was
> experiencing on my end. And that you are now having the same problem I
> am. Whcih version maven are you building with, we need to try to be
> on 2.2.1 or greater.
>
> >
> > After some more testing, I will commit some of my initial cleanup. ?Even
> > if it doesn't fix the entire problem yet, it seems to be getting closer
> > to some sort of resolution.
>
> The fixes I proposed are about 6 lines of code that clearup the issue
> for getting bamboo to operate properly. Likewise, as long as tests
> are run as mvn test -Paddons from the [dspace-src] you should be safe
> with the assembly process working.
>
> >
> > Essentially, I believe our POMs need some overhaul -- we aren't taking
> > advantage of inheritance in many places, and it seems like it may be
> > confusing Maven to some extent. ?The smaller we can make most of the
> > POMs the better.
>
> We need to be very cautious about using inheritance in poms, the
> asyncronous release and the usage of dspace-pom as an external pom are
> there for a specific purpose. I've gone through the things that
> should and should not be inherited several time in tuning it up. The
> more you inherit, the fewer options you leave for turning things off
> in the children.
> >
> > - Tim
> >
> > On 11/11/2010 1:49 PM, Mark H. Wood wrote:
> >> I note that the build seems to start in [DSpace-source] rather than
> >> [DSpace-source]/dspace. ?Strange things happen when doing that. ?I've
> >> never worked out why. ?It definitely makes the Reactor build in a
> >> different order.
> >>
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> >> Simplifying enterprise desktop deployment and management using
> >> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> >> client virtualization framework. Read more!
> >> http://p.sf.net/sfu/dell-eql-dev2dev
> >>
> >>
> >>
> >> _______________________________________________
> >> Dspace-devel mailing list
> >> [email protected]
> >> https://lists.sourceforge.net/lists/listinfo/dspace-devel
> >
> >
> ------------------------------------------------------------------------------
> > Centralized Desktop Delivery: Dell and VMware Reference Architecture
> > Simplifying enterprise desktop deployment and management using
> > Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> > client virtualization framework. Read more!
> > http://p.sf.net/sfu/dell-eql-dev2dev
> > _______________________________________________
> > Dspace-devel mailing list
> > [email protected]
> > https://lists.sourceforge.net/lists/listinfo/dspace-devel
> >
>
>
>
> --
> Mark R. Diggory
> @mire -?www.atmire.com
> 533 2nd Street - Encinitas, CA 92024 - USA
> Technologielaan 9 - 3001 Heverlee - Belgium
>
>
>
> ------------------------------
>
> Message: 4
> Date: Thu, 11 Nov 2010 21:07:56 +0000 (UTC)
> From: "Stuart Lewis (DuraSpace JIRA)" <[email protected]>
> Subject: [Dspace-devel] [DuraSpace JIRA] Updated: (DS-525) Move item -
> inherit default policies of destination collection
> To: [email protected]
> Message-ID: <707512560.40.1289509676514.javamail.j...@atlas>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://jira.duraspace.org/browse/DS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Stuart Lewis updated DS-525:
> ----------------------------
>
> Attachment:
> [DS-525]_Move_item_-_inherit_default_policies_of_destination_collection_5827.patch
>
> Second version of the patch - same as before, but against trunk revision
> 5827, as a lot of code has changed since the patch was first written.
>
> > Move item - inherit default policies of destination collection
> > --------------------------------------------------------------
> >
> > Key: DS-525
> > URL: https://jira.duraspace.org/browse/DS-525
> > Project: DSpace
> > Issue Type: New Feature
> > Components: DSpace API, JSPUI, XMLUI
> > Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0
> > Reporter: Stuart Lewis
> > Priority: Major
> > Fix For: 1.7.0
> >
> > Attachments:
> [DS-525]_Move_item_-_inherit_default_policies_of_destination_collection.patch,
> [DS-525]_Move_item_-_inherit_default_policies_of_destination_collection_5827.patch
> >
> >
> > When using the UI to move an item, the item is moved, and it takes its
> authZ policies with it,
> > However, a common use case is to move an item from a dark collection, to
> an open collection. In this case, it is desired behaviour for the authZ
> policies to be updated to the default policies of the destination
> collection.
> > This patch gives a new checkbox for jspui and xmlui to allow the
> destination policy to be inherited. By default the checkbox is unchecked.
> > The API has been updated to add this as a boolean option on the
> Item.moveItem method.
> > The patch also fixes two bugs with the xmlui move item function:
> > 1) When selecting which collection to move the item to, the collection
> that is is currently in is no longer listed.
> > 2) Previously a new authZ policy was added to the item to allow the admin
> to move the item. This was not removed once the item had been moved. If an
> item was moved multiple times, lots of these policies were left in the item.
> Instead, the patch updates it to set a temporary action allowing this,
> rather than a policy.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> https://jira.duraspace.org/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Thu, 11 Nov 2010 21:49:56 +0000 (UTC)
> From: "Stuart Lewis (DuraSpace JIRA)" <[email protected]>
> Subject: [Dspace-devel] [DuraSpace JIRA] Resolved: (DS-525) Move item
> - inherit default policies of destination collection
> To: [email protected]
> Message-ID: <1898471720.44.1289512196518.javamail.j...@atlas>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://jira.duraspace.org/browse/DS-525?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Stuart Lewis resolved DS-525.
> -----------------------------
>
> Documentation Status: Complete or Committed (was: Needed)
> Resolution: Fixed
> Assignee: Stuart Lewis
>
> Added documentation, with warning about embargoes:
>
>
> https://wiki.duraspace.org/pages/diffpages.action?pageId=22022835&originalId=22547177
>
> > Move item - inherit default policies of destination collection
> > --------------------------------------------------------------
> >
> > Key: DS-525
> > URL: https://jira.duraspace.org/browse/DS-525
> > Project: DSpace
> > Issue Type: New Feature
> > Components: DSpace API, JSPUI, XMLUI
> > Affects Versions: 1.5.0, 1.5.1, 1.5.2, 1.6.0
> > Reporter: Stuart Lewis
> > Assignee: Stuart Lewis
> > Priority: Major
> > Fix For: 1.7.0
> >
> > Attachments:
> [DS-525]_Move_item_-_inherit_default_policies_of_destination_collection.patch,
> [DS-525]_Move_item_-_inherit_default_policies_of_destination_collection_5827.patch
> >
> >
> > When using the UI to move an item, the item is moved, and it takes its
> authZ policies with it,
> > However, a common use case is to move an item from a dark collection, to
> an open collection. In this case, it is desired behaviour for the authZ
> policies to be updated to the default policies of the destination
> collection.
> > This patch gives a new checkbox for jspui and xmlui to allow the
> destination policy to be inherited. By default the checkbox is unchecked.
> > The API has been updated to add this as a boolean option on the
> Item.moveItem method.
> > The patch also fixes two bugs with the xmlui move item function:
> > 1) When selecting which collection to move the item to, the collection
> that is is currently in is no longer listed.
> > 2) Previously a new authZ policy was added to the item to allow the admin
> to move the item. This was not removed once the item had been moved. If an
> item was moved multiple times, lots of these policies were left in the item.
> Instead, the patch updates it to set a temporary action allowing this,
> rather than a policy.
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> https://jira.duraspace.org/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
>
>
> ------------------------------
>
> Message: 6
> Date: Fri, 12 Nov 2010 01:52:56 +0000 (UTC)
> From: "Kim Shepherd (DuraSpace JIRA)" <[email protected]>
> Subject: [Dspace-devel] [DuraSpace JIRA] Assigned: (DS-640) Interal
> System Error when browsing with wrong argument
> To: [email protected]
> Message-ID: <1499654185.51.1289526776584.javamail.j...@atlas>
> Content-Type: text/plain; charset=UTF-8
>
>
> [
> https://jira.duraspace.org/browse/DS-640?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel]
>
> Kim Shepherd reassigned DS-640:
> -------------------------------
>
> Assignee: Kim Shepherd (was: Stuart Lewis)
>
> > Interal System Error when browsing with wrong argument
> > ------------------------------------------------------
> >
> > Key: DS-640
> > URL: https://jira.duraspace.org/browse/DS-640
> > Project: DSpace
> > Issue Type: Bug
> > Components: JSPUI, XMLUI
> > Affects Versions: 1.5.2, 1.6.0, 1.6.1, 1.6.2
> > Reporter: Hardik Mishra
> > Assignee: Kim Shepherd
> > Priority: Major
> > Attachments: browse.patch
> >
> >
> > On Browsing Items:
> > If someone tries to use browse type for which browse index does not
> exist, like browse=publisher
> > e.g. http://dspace.webinito.com/browse?type
> > OR
> > e.g. http://dspace.webinito.com/browse?type=xyz
> > You will get Internal System Error
>
> --
> This message is automatically generated by JIRA.
> -
> If you think it was sent incorrectly contact one of the administrators:
> https://jira.duraspace.org/secure/Administrators.jspa
> -
> For more information on JIRA, see: http://www.atlassian.com/software/jira
>
>
>
>
>
> ------------------------------
>
>
> ------------------------------------------------------------------------------
> Centralized Desktop Delivery: Dell and VMware Reference Architecture
> Simplifying enterprise desktop deployment and management using
> Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
> client virtualization framework. Read more!
> http://p.sf.net/sfu/dell-eql-dev2dev
>
> ------------------------------
>
> _______________________________________________
> Dspace-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-devel
>
>
> End of Dspace-devel Digest, Vol 54, Issue 25
> ********************************************
>
--
Atte.
Sergio Fredes Mena
Estudiante de Bibliotecología y Documentación
Estudiante de Diplomado en Comunicación Organizacional y Liderazgo.
www.prodigioconsultores.com/
------------------------------------------------------------------------------
Centralized Desktop Delivery: Dell and VMware Reference Architecture
Simplifying enterprise desktop deployment and management using
Dell EqualLogic storage and VMware View: A highly scalable, end-to-end
client virtualization framework. Read more!
http://p.sf.net/sfu/dell-eql-dev2dev
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
