Re: [Dspace-tech] DSpace 1.7.0 Maven 3.0.2 - DuplicateProjectException / Missing pom.xml properties

2011-03-07 Thread Patrick Etienne
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
instructionshttps://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=nodenode=3339268i=0by-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 

Re: [Dspace-tech] DSpace 1.7.0 Maven 3.0.2 - DuplicateProjectException / Missing pom.xml properties

2011-03-07 Thread Mark Diggory
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 
 instructionshttps://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=nodenode=3339268i=0by-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 

Re: [Dspace-tech] DSpace 1.7.0 Maven 3.0.2 - DuplicateProjectException / Missing pom.xml properties

2011-03-07 Thread Patrick Etienne
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
 instructionshttps://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=nodenode=3339268i=0by-user=t]

 *Sent:* 

Re: [Dspace-tech] DSpace 1.7.0 Maven 3.0.2 - DuplicateProjectException / Missing pom.xml properties

2011-03-07 Thread Peter Karunyu
Below are some notes I took after installing DSpace 1.7.0 on Windows 7 using
Maven 3.0.2:

1. Use mvn install instead of mvn package. Note, mvn install will download a
whole bucketload of stuff, you need to have a good internet connection.
2. Also, incase of any issues, do mvn -eX install  log.txt then read the
log for surely a description of the error will be there
3. If you use a proxy server to get to the internet, make sure you input the
settings in settings.xml for in the maven directory
4. Make sure to use ant fresh_install  log2.txt and read the damn log! If
you see something like 'duplicate', drop the dspace database and create it
again, then repeat ant fresh_install.
5. Make sure you don't have JAVA_OPTS in the environment variables, mine was
just breaking dspace create-administrator, removing it things worked fine.


On Tue, Mar 8, 2011 at 7:48 AM, Peter Karunyu pkaru...@gmail.com wrote:

 Patrick,
 I was getting the exact same errors while trying to setup DSpace 1.7.0 with
 Maven 3.0.2 on Windows 7, I posted the error here and a few good folks on
 and off this list helped me out and I posted the solution also.

 Long story short, it works :-)

 I should mention that at not point did I need or use Eclipse so it is
 possible that your use case is different from mine. Either way, let me dig
 up that post and send it your way.


 Regards,
 Peter.


 On Mon, Mar 7, 2011 at 11:20 PM, Patrick Etienne 
 patrick.etie...@library.gatech.edu wrote:

 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
 instructionshttps://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