Re: [jira] Commented: (OODT-63) Use hard coded version numbers in shared component POMs so that MVN install works

["Mattmann, Chris A (388J)" <ch...@jpl.nasa.gov>]

Haha, you are just too radical for me!

Conceptually and organizationally it makes sense (what you propose), I'm just hesitant since we just made an Apache release that didn't have this organization. Doesn't mean it can never change though. I'm +0 for it...

Cheers,
Chris

On Dec 14, 2010, at 4:40 PM, Brian Foster (JIRA) wrote:

> 
>    [ https://issues.apache.org/jira/browse/OODT-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12971498#action_12971498 ] 
> 
> Brian Foster commented on OODT-63:
> ----------------------------------
> 
> 
> **WARNING . . . RADICAL CHANGE PURPOSED AHEAD!!!*** ;)
> 
> the top level mvn eclipse:eclipse (when run on the top level module pom.xml) is broken because eclipse requires the directory in which a module exists to be the same name as the artifactId in the pom.xml since maven build the paths in the eclipse project files based of the artifactId not the directory names
>   - not sure this warrants a change on our end (however, i think it is a least worth considering)
>   - may be something which should be posted on mvn eclipse:eclipse plugin JIRA
> 
> also the CAS components still build with cas-* however, they are not clearly recognized as a CAS component in the svn repo . . . think a directory structure change might be warranted here . . . maybe reintroduce the cas-* in the directory name (this would also fix the mvn eclipse:eclipse problem) OR move all the CAS components into a 'cas' directory so you would have something along the lines of:
> 
> {noformat}
> .../trunk/
>    pom.xml
>    cas/
>        pom.xml
>        filemgr/
>            pom.xml
>            ...
>        workflow/
>            pom.xml
>            ...
>        ...
>    commons/
>        pom.xml
>        ...
>    grid/
>        pom.xml
>        ....
>    ...
> {noformat}
> 
> 
>> Use hard coded version numbers in shared component POMs so that MVN install works
>> ---------------------------------------------------------------------------------
>> 
>>                Key: OODT-63
>>                URL: https://issues.apache.org/jira/browse/OODT-63
>>            Project: OODT
>>         Issue Type: Improvement
>>         Components: build proces
>>   Affects Versions: 0.1-incubating
>>           Reporter: Chris A. Mattmann
>>           Assignee: Chris A. Mattmann
>>           Priority: Critical
>>            Fix For: 0.2
>> 
>> 
>> As it turns out, good ol' Maven doesn't allow POMs with ${variables} for version #s to allow their ${version}s to be resolved dynamically at runtime. In practical terms what this means it that currently the OODT jars can't be published, e.g., to Maven Central, because you get a whole bunch of warnings about not being able to download oodt-core-${oodt.version}.
>> This can be remedied by not being as slick when it comes to variable management in the POMs, and simply by putting the actual POM version in all dependent POMs within the OODT build.
> 
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: chris.a.mattmann@nasa.gov
WWW:   http://sunset.usc.edu/~mattmann/
Phone: +1 (818) 354-8810
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++