Ole Ersoy wrote:
Yes I think what I'm saying is getting diluted because
you are used to thinking about how the current
installer plugin works.
OK - Pretend for a minute that there are no installer
plugins. We are just getting started.
Okie.
All we have are maven java projects.
Now we want to create a maven plugin that
that we can use to create the RPM installer.
However other projects have to be able to use it to,
and we want everyone using it the same way to make
cross project collaboration easier, etc.
So we first make a generic decision with respect to
where the stuff the installer installs comes from.
OK
We think that it's smart to pull all the resources
that the installer plugin needs from the maven
repository, because that's where Maven puts everything
after various quality assurance tests pass.
Hmmm even non-java artifacts like shared libs and stuff? Meaning things
where the extension is not .jar or .pom? Cuz maven has serious issues
with doing that I think. Don't know fully though but I'd give it a try.
So as as a rule we state that the Maven plugin we are
creating pulls resources and artifacts from the
Repository only. We're going with the Maven
Convention over configuration motto.
Coolio but you have to really experiment with maven to see if it can
manage other artifact types besides jars and poms.
So the plugin does not care about stuff that exists in
maven projects sitting in a workspace or in a version
control system.
It only cares about stuff that maven has installed in
a local maven repository.
Does that make more sense?
Aye that makes sense. So you want to stuff things into the
src/main/resources area so they are bundled in jars and can be extracted
from them once those jars are pulled down from ibiblio or elsewhere?
Alex
