I think for now it's ok to release all together. I don't see a problem
with this. As a matter of fact, we've never even discussed independent
releases. Commit Away!
David
David
Elliot Metsger wrote:
David H. DeWolf wrote:
yup. the maven resources plugin can help with filtering/replacement
too. . .
Ok so I've done what I proposed below in my working copy (I haven't
committed it yet).
One problem with my solution is that you cannot version the Pluto
artifacts independently of each other. I don't know if that is a
problem or not.
If that isn't a problem (or if it is a problem we can resolve later)
I'll commit the patch, and of course feel free to change things around
(you won't hurt my feelings) :-)
Elliot
David
Elliot Metsger wrote:
David H. DeWolf wrote:
>
> Agreed. i think the maven resources plugin is what we want here.
Here's
> the JIRA for it:
>
> https://issues.apache.org/jira/browse/PLUTO-191
In the past I've had a "version.properties" file sitting in the
resource directory, with property names like:
commons-logging.version=${commons-logging.version}
The property names come from the pom.
That file gets interpolated, and would be packaged up in the jar. So
you end up with a versions.properties file with
commons-logging.version = 1.0.4
Then java code (i.e. the Pluto maven plugin) can query the properties
file for version information.
Is this the approach you are thinking of David? Or is there a better
way? I can get started on this if you want.
Elliot
Charles Severance wrote:
The duplication of version numbers to all child pom.xml files is a
pain. Is there a way of using a
variable in the pom.xml project/parent/version element value for
all the pluto-* modules?
In Sakai, we got repeatedly killed by scattered constants - finally
we simply "included" something like ../project.xml for these
"variables" - that of course is Maven 1 speak - but until we
centralized this version nuber one place - we never could get
anything to properly release.
It seemed that hard-coding *where* the constant came from (like
../xyz.xml or ../../xyz.xml) while brittle was a small price to pay.
/Chuck
