Mark,

Excellent, thanks so much for the confirmation here. It wasn't a significant
issue in that 2.2.1 worked fine, but I wanted to make sure that I wasn't
missing anything for my tutorials / guides.

Cheers

 - Patrick E.

On Mon, Mar 7, 2011 at 3:16 PM, Mark Diggory <mdigg...@atmire.com> wrote:

> Patrick,
>
> this is a known issue with Maven 3, we are working on some project
> restructuring in DSpace trunk to alleviate this, for now, if you can build
> with the latest version of maven 2, that would be recommended. I think you
> can choose the maven installation in the m2eclipse plugin so you are not
> using the internal 3 version that comes with it. Likewise, if you want to
> build from /dspace/pom. you can drop the other <module> references in the
> dspace-parent pom by commenting them out.
>
> Mark
>
>
> On Mon, Mar 7, 2011 at 9:14 AM, Patrick Etienne <
> patrick.etie...@library.gatech.edu> wrote:
>
>> Elliot (et al),
>>
>> Many thanks for the reply. You might have to say that I am both using and
>> not using Eclipse, though the part where I am may be interfering with the
>> part where I am not. I'm attempting to setup both a local development
>> environment through Eclipse as well as a non-Eclipse (command-line) setup to
>> mimic the development and production servers that my system administrator
>> has setup (in effort to learn how best to streamline workflow for
>> maintaining multiple instances).
>>
>> I'm going to briefly describe my setup in hopes that providing the info
>> will help narrow down the difficulty (though it may just be trying to use
>> Eclipse in tandem with the command line).
>>
>> Using Eclipse, I create a new (generic) project from svn and download the
>> source to (rather than the regular workspace directory) my /usr/local/src
>> directory (One-Big-Project approach, which may be a problem). >From there
>> I'll follow as updated instructions as I can from the Eclipse / DSpace setup
>> wiki entry (including "Enabled Nested Modules"). From here I have all the
>> other required dspace tools installed and the dspace.cfg configured etc. At
>> this point I try running a Maven goal on the source directory as a test (mvn
>> clean, for instance). I'll try running this same goal several ways, here are
>> the results:
>>
>> Eclipse 3.6 (Helios) - Embedded Maven 3.0.2 - Fails
>> Eclipse 3.6 (Helios) - External 3.0.2 - Fails
>> Eclipse 3.6 (Helios) - External 2.2.1 - Succeeds
>> Command Line - 3.0.2 - Fails
>> Command Line - 2.2.1 - Succeeds
>>
>> My question at this point would be, is there something inherently
>> different about downloading from svn to my source directory using the
>> command line vs. performing the same operation through project creation from
>> svn within Eclipse? Would attempting to "Enable Dependency Management" in
>> Eclipse (or some other operation within the Eclipse / DSpace setup
>> instructions<https://wiki.duraspace.org/display/DSPACE/IDE+Integration+-+DSpace,+Eclipse+and+Tomcat#IDEIntegration-DSpace%2CEclipseandTomcat-WorkingwithDSpace1.5>)
>> taint the files in my source directory to the effect of having a Maven goal
>> fail when run via the command line? All failures are the same error message.
>>
>> One significant thing I found interesting is that setting up one project
>> per DSpace module would alleviate the "referencing the same module within
>> multiple pom.xml files" problem (I think), due to them being separate
>> projects rather than one big project. I did see that m2eclipse is behaving
>> differently in the eclipse GUI due to some Eclipse API changes in 3.6 (run
>> configurations, etc). I didn't realize that "Enable Nested Modules" wasn't
>> supported in later versions, that may be the deal right there. As a general
>> public FYI, it seems that m2eclipse (or like functionality) has been slated
>> for core integration in 3.7 (due out June 22nd). That could be interesting.
>>
>> I think I'm going to try setting up DSpace from scratch all via command
>> line into a different location, but I have the feeling that I'll still hit
>> the same error.
>>
>> Elliot, again thanks for the reply. This has given me good food for
>> thought and a way to continue trouble shooting. Cheers mate!
>>
>> If anyone else happens to have experience with similar issues, any tips or
>> suggestions would be appreciated.
>>
>>  - Patrick E.
>>
>>
>>  On Mon, Mar 7, 2011 at 10:43 AM, edawson <edaw...@maf.org> wrote:
>>>
>>> Hi Patrick,
>>>
>>>
>>>
>>> Are you using Eclipse? I was getting very similar errors when I didn’t
>>> have my projects set up correctly. I never had any trouble using Maven 3.02
>>> via command line. With a bit of searching I found out it looks like the
>>> Maven option to “Enable Nested Modules” isn’t supported in the later
>>> versions of m2eclipse. So I set up one project per DSpace module and it all
>>> seemed to work. The m2eclipse dependency management then was able to
>>> correctly identify the modules as separate Java projects. I hope this helps
>>> (obviously not if you’re not using eclipse).
>>>
>>>
>>>
>>> Elliot
>>>
>>
>>
>>>  *From:* Patrick Etienne [via DSpace] [mailto:[hidden 
>>> email]<http://user/SendEmail.jtp?type=node&node=3339268&i=0&by-user=t>]
>>>
>>> *Sent:* Monday, March 07, 2011 7:57 AM
>>> *To:* Elliot Dawson
>>> *Subject:* DSpace 1.7.0 & Maven 3.0.2 - DuplicateProjectException /
>>> Missing pom.xml properties
>>>
>>>
>>>
>>> DSpace Techies and Devs -
>>>
>>>
>>>
>>> I wanted to see whether anyone had had success setting up DSpace 1.7.0
>>> using Maven 3.0.2. I ask because I'm attempting to put together a guide /
>>> tutorial / how-to for establishing a solid and streamlined workflow for
>>> maintaining multiple development and production dspace environments (we have
>>> a grant project where we will be hosting several institutions' dspace
>>> repositories).
>>>
>>>
>>>
>>> To make a long story short, it seems as though installation works fine on
>>> maven 2.2.1 but fails on 3.0.2 with the following [ERROR]:
>>>
>>>
>>>
>>> "*Two or more projects in the reactor have the same identifier, please
>>> make sure that <groupId>:<artifactId>:<version> is unique for each project:
>>> * (...)"
>>>
>>> (goes on to list all dspace maven projects)
>>>
>>>
>>>
>>> In effort to investigate the problem, I put together a google
>>> spreadsheet<https://spreadsheets.google.com/ccc?key=0AgxlFEYcNkPzdC13N3V1cXdPdDRuYWdWRVJWTFo4Q0E&hl=en&authkey=CNqj2pAG>listing
>>>  all the dspace maven project pom.xml files as well as (manually
>>> checking their) <groupId>:<artifactId>:<version> strings. Unfortunately (or
>>> fortunately?) there were no duplicate project identifiers. However, after
>>> some more searching I found that it's likely *not a problem with an
>>> actual duplicate project identifier* as much as it is having *two
>>> pom.xml files referencing the same maven <module/>*. There's information
>>> on the net about possibly changing this error message so it better reflects
>>> the actual cause of the problem (jira over at 
>>> Sonatype<https://issues.sonatype.org/browse/TYCHO-531>),
>>> but I couldn't find a maven specific bug report. Note, the bug would only be
>>> about the information the error message provides; referencing the same maven
>>> <module/> from two different pom.xml files is still a valid problem (or so
>>> it seems) in 3.0.2
>>>
>>> Specifically, the two pom.xml files that seem to be contributing to the
>>> problem are the {dspace-1.7.0-src-release}/pom.xml and the
>>> {dspace-1.7.0-src-release}/dspace/pom.xml. Both files make references to the
>>> following project <modules/>:
>>>
>>> dspace-ap
>>> dspace-stats
>>> dspace-discovery
>>> dspace-oai
>>> dspace-jspui
>>> dspace-sword
>>> dspace-xmlui
>>> dspace-lni
>>>
>>>
>>>
>>> This is probably a good point at which to say that I'm not terribly
>>> familiar with maven. I'm not sure why exactly it seems to be within spec to
>>> reference the same <module/> with two different pom.xml files within 2.2.1
>>> but not with 3.0.2. However, it does seem to be the source of the error I
>>> listed above (or at least, from what I can tell). If anyone has any tips,
>>> hints, resources, or suggestions related to getting maven 3.0.2 to play nice
>>> with dspace (or vice-versa) please let me know!
>>>
>>>
>>>
>>>  - Patrick E.
>>>
>>>
>>> --
>>> Patrick K. Etienne
>>> Systems Analyst
>>> Georgia Institute of Technology
>>> Library & Information Center
>>> (404) 385-8121
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> What You Don't Know About Data Connectivity CAN Hurt You
>>> This paper provides an overview of data connectivity, details
>>> its effect on application quality, and explores various alternative
>>> solutions. http://p.sf.net/sfu/progress-d2d
>>> _______________________________________________
>>> DSpace-tech mailing list
>>> [hidden 
>>> email]<http://user/SendEmail.jtp?type=node&node=3339149&i=0&by-user=t&by-user=t>
>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>>>
>>> ------------------------------
>>>
>>> *If you reply to this email, your message will be added to the
>>> discussion below:*
>>>
>>>
>>> http://dspace.2283337.n4.nabble.com/DSpace-1-7-0-Maven-3-0-2-DuplicateProjectException-Missing-pom-xml-properties-tp3339149p3339149.html<http://dspace.2283337.n4.nabble.com/DSpace-1-7-0-Maven-3-0-2-DuplicateProjectException-Missing-pom-xml-properties-tp3339149p3339149.html?by-user=t>
>>>
>>> To start a new topic under DSpace - Tech, email [hidden 
>>> email]<http://user/SendEmail.jtp?type=node&node=3339268&i=1&by-user=t>
>>>
>>> ------------------------------
>>> View this message in context: RE: DSpace 1.7.0 & Maven 3.0.2 -
>>> DuplicateProjectException / Missing pom.xml 
>>> properties<http://dspace.2283337.n4.nabble.com/DSpace-1-7-0-Maven-3-0-2-DuplicateProjectException-Missing-pom-xml-properties-tp3339149p3339268.html>
>>> Sent from the DSpace - Tech mailing list 
>>> archive<http://dspace.2283337.n4.nabble.com/DSpace-Tech-f3276945.html>at 
>>> Nabble.com.
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>>
>>> What You Don't Know About Data Connectivity CAN Hurt You
>>> This paper provides an overview of data connectivity, details
>>> its effect on application quality, and explores various alternative
>>> solutions. http://p.sf.net/sfu/progress-d2d
>>> _______________________________________________
>>> DSpace-tech mailing list
>>> DSpace-tech@lists.sourceforge.net
>>>
>>> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>>>
>>>
>>
>>
>> --
>> Patrick K. Etienne
>> Systems Analyst
>> Georgia Institute of Technology
>> Library & Information Center
>> (404) 385-8121
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> What You Don't Know About Data Connectivity CAN Hurt You
>> This paper provides an overview of data connectivity, details
>> its effect on application quality, and explores various alternative
>> solutions. http://p.sf.net/sfu/progress-d2d
>> _______________________________________________
>> DSpace-tech mailing list
>> DSpace-tech@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/dspace-tech
>>
>>
>
>
> --
> Mark R. Diggory
> @mire - www.atmire.com
> 2888 Loker Avenue East - Suite 305 - Carlsbad - CA - 92010
> Technologielaan 9 - 3001 Heverlee - Belgium
>



-- 
Patrick K. Etienne
Systems Analyst
Georgia Institute of Technology
Library & Information Center
(404) 385-8121
------------------------------------------------------------------------------
What You Don't Know About Data Connectivity CAN Hurt You
This paper provides an overview of data connectivity, details
its effect on application quality, and explores various alternative
solutions. http://p.sf.net/sfu/progress-d2d
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech

Reply via email to