[
https://jira.duraspace.org/browse/DS-676?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18830#action_18830
]
Tim Donohue commented on DS-676:
--------------------------------
This issue was discussed in DSpace Developers Mtg on Feb 2 2011
Overall, general agreement that this needs to be fixed. Most seemed to agree
that it may be better to create a separate, filtered
'dspace-version.properties' file, rather than attempting to rely on the
location of pom.properties Maven file.
Full discussion follows:
[20:12] <tdonohue> Use groupId and artifactId from the dspace-api POM in
Util.java : https://jira.duraspace.org/browse/DS-676
[20:12] <tdonohue> grahamtriggs is assigned for DS-676, graham, anything you
want reviewed or comments on?
[20:12] <mdiggory> next
[20:13] <grahamtriggs> what I've proposed works. question is whether people
want it
[20:13] <mdiggory> yes... that is somewhat a pain, especially when this first
came in as a feature, those of us working IDE actually did not have a jar to
look this up in
[20:14] <tdonohue> wondering, is there an advantage to only filtering the
Util.java file? or is it just as easy (or easier) to filter all source code?
[20:15] <mdiggory> grahamtriggs: think its logical, but also think maybe
"generated sources" could be used to write a filtered properties file rather
than altering java
[20:15] <mdiggory> sorry generate-resources
[20:15] <mhwood> Generated resource sounds the best yet.
[20:17] <tdonohue> yea, I like mdiggory's idea of a filtered property file. I
worry about filtering all our Java code (though it also is likely safe)
[20:17] <grahamtriggs> so pom.properties will always go into
/META-INF/maven/org.dspace/dspace-api/ - regardless of what the pom actually
says is the group / artifact id?
[20:17] <mdiggory> are you changing the group id of dspace-api?
[20:18] <grahamtriggs> note that the problem isn't what's in the property file,
but where it is being placed in the JAR hierarchy
[20:18] <grahamtriggs> mdiggory: yes - so I don't get any accidental
resolutions to the published dspace-api in maven central, when I need to use my
customized version
[20:19] * mdiggory X get past me Satan!
[20:19] <mhwood> Put this kind of thing into
"[somedir]dspace-statics.properties" and you don't care where it is, as long as
it's on the CLASSPATH.
[20:19] <mdiggory> sorry... knee jerk reaction
[20:20] * keithgilbertson ([email protected]) has
joined #duraspace
[20:20] <mhwood> Ha, that's one I need to remember.
[20:20] <mdiggory> ok, I guess if your so bold to do that...
[20:20] <tdonohue> +1 to mhwood -- I was thinking the same thing. Why not have
a separate filtered *.properties file for this info (if possible), rather than
depending on pom.properties at all
[20:20] <mdiggory> I asume you change the gid/artifactid coordinates, it will
change the location of the file
[20:21] <mdiggory> I think... if we say we are going to create a file
dspace-version.properties...
[20:21] <mdiggory> that would be in the resources/classpath, then we can fix
the location
[20:21] <grahamtriggs> mdiggory: yes, that's what happens - change the groupId,
and the pom.properties gets inserted into
/META-INF/maven/YOURGROUPPACKAGE/dspace-api
[20:22] <grahamtriggs> mdiggory: and then filter that file to take the version
that's in the pom....
[20:22] <tdonohue> +1 to a dspace-version.properties file (which is filtered).
It seems odd to me to do all these workarounds just to access the pom.properties
[20:22] * mdiggory weeps sadly that we will never stop overriding classes...
[20:23] <mdiggory> well, TBH, it could contain much more detail than the pom
[20:24] <tdonohue> should we stop there? any other comments on DS-676?
[20:24] <mhwood> I never liked depending on a file magically provided by Maven
that I just happened to notice, but I'm still finding my way around Maven and
grasped at it as a possible way for DSpace to *know who it is*, for pity's sake.
[20:24] * grahamtriggs doesn't care about overriding classes. This is, to an
extent, what open source development is all about. Remember that local changes
may be a future contribution, and clearly we can't evolve the platform if we
never change the core classes.
[20:24] <mdiggory> More like a JAR Manifest, but I prefer a properties file
because there may not yet be a jar when this is being tested
[20:25] <tdonohue> Ok. sounds like we have some agreement that a separate
properties file should be used for DS-676. We'll stop there for today and move
on to next topics
> Use groupId and artifactId from the dspace-api POM in Util.java
> ---------------------------------------------------------------
>
> Key: DS-676
> URL: https://jira.duraspace.org/browse/DS-676
> Project: DSpace
> Issue Type: Improvement
> Components: DSpace API
> Affects Versions: 1.6.0, 1.6.1, 1.6.2
> Reporter: Graham Triggs
> Assignee: Graham Triggs
> Original Estimate: 5 minutes
> Remaining Estimate: 5 minutes
>
> Util.java has a hardcoded reference to the groupId and artifactId that is
> designated in the dspace-api POM file.
> This makes it unnecessarily awkward to change the group or artifact name if
> you are doing local customized builds.
> The problem can be simply avoided by making Maven filter the Java sources
> before compiling, and reference the Maven variables from the source.
> Util.java:
> InputStream cis = Util.class.getResourceAsStream
>
> ("/META-INF/maven/${pom.groupId}/${pom.artifactId}/pom.properties");
> pom.xml:
> <build>
> <resources>
> <resource>
> <directory>src/main/java</directory>
> <filtering>true</filtering>
> <targetPath>../filtered-sources/java</targetPath>
> </resource>
> <resource>
> <directory>src/main/resources</directory>
> <filtering>true</filtering>
> </resource>
> </resources>
> <sourceDirectory>target/filtered-sources/java</sourceDirectory>
> </build>
--
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
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
