Maven 1.x Eclipse Plugin

maven.eclipse.conclasspath is ignored when junit test src is not present

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.9
  • Fix Version/s: 1.10
  • Component/s: None
  • Labels:
    None
  • Environment:
    XP, jdk 1.4.2
  • Number of attachments :
    0

Description

Tracing thru the jelly code and tested it myself, maven-eclipse-plugin
completely ignore the processing of maven.eclipse.conclasspath when the ${unitTestSourcesPresent} is not true.

the code is in src/plugin-resources/templates/classpath.jelly

is it a bug?

Activity

Hide
Dan Tran added a comment -

the work around to create a empty test source directory

Show
Dan Tran added a comment - the work around to create a empty test source directory
Hide
David Eric Pugh added a comment -

The workaournd describe of creating the empty directory is the right thing. There are quite a few places in Maven where this logic occurs, it's not an Eclipse plugin specific thing.

Show
David Eric Pugh added a comment - The workaournd describe of creating the empty directory is the right thing. There are quite a few places in Maven where this logic occurs, it's not an Eclipse plugin specific thing.
Hide
Jason Taft added a comment -

Though the workaround does work, I am not understanding the reasoning behind it.

Maybe my situation will help explain my lack of understanding?

I am working on improving the eclipse plugin to allow me to create the appropriate .project and .classpath artifacts for use with Websphere Studio Application Developer (WSAD) 5. Although I can use the currently (I'm using v1.9 of this plugin) generated artifacts to successfully import a project into WSAD's java perspective, these artifacts need some additional information in order to be recognized by the J2EE perspective (the application assembly toolkit is now the j2ee perspective) shipped with WSAD.

One of the additions I need to make is to add a conclasspath entry for the websphere j2ee.ejb "container."

My ejb project doesn't contain any unit tests (and it isn't necessary to get into the merits of this decision).

I look forward to the enlightenment, be gentle , but I currently fail to see why creating an empty unit test src directory should be necessary as my long-term solution.

Thanks,
Jason Taft

Show
Jason Taft added a comment - Though the workaround does work, I am not understanding the reasoning behind it. Maybe my situation will help explain my lack of understanding? I am working on improving the eclipse plugin to allow me to create the appropriate .project and .classpath artifacts for use with Websphere Studio Application Developer (WSAD) 5. Although I can use the currently (I'm using v1.9 of this plugin) generated artifacts to successfully import a project into WSAD's java perspective, these artifacts need some additional information in order to be recognized by the J2EE perspective (the application assembly toolkit is now the j2ee perspective) shipped with WSAD. One of the additions I need to make is to add a conclasspath entry for the websphere j2ee.ejb "container." My ejb project doesn't contain any unit tests (and it isn't necessary to get into the merits of this decision). I look forward to the enlightenment, be gentle , but I currently fail to see why creating an empty unit test src directory should be necessary as my long-term solution. Thanks, Jason Taft
Hide
Dan Tran added a comment -

Can I reopen this? I have to document this work around in my comp, and everyone just seems to forget about this and confusions keep coming back.

Would be hard to fix the jelly code right?

Show
Dan Tran added a comment - Can I reopen this? I have to document this work around in my comp, and everyone just seems to forget about this and confusions keep coming back. Would be hard to fix the jelly code right?
Hide
Dan Tran added a comment -

see my last comment

Show
Dan Tran added a comment - see my last comment
Hide
fabrizio giustina added a comment -

fixed in svn

Show
fabrizio giustina added a comment - fixed in svn

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved: