I think that your goal is a noble one, but also one that most likely
cannot be generically solved by a single plugin... you can certainly
solve it for your company with a single plugin.
for example, we have a virtual machine based solution to which our EAR
and RARs and custom thingamys have to be deployed before we can
release the VM template for deployment on customer sites. I have
written a maven plugin that does "our" release deployment process in
30s where manual tasks would take 2-3 hours... and I use ranges in a
"deployment" pom to pick up the released versions... but our
deployment process is special... sftp these files to location X on the
target machine... sftp those files to location Y... parse some
files... run a command remotely and parse the output... compare the
two parse results and compute the deployment actions... ssh in and
perform the actions, restarting any necessary services... etc
it's not that your problem is against the maven way, more that there
cannot be a maven way to solve thus problem for everyone... and as of
yet I am not sure that there us even a solution for 40% of people
(other than download assembly/installer from maven repo)
Sent from my [rhymes with tryPod] ;-)
On 21 Feb 2010, at 14:20, eyal edri <[email protected]> wrote:
Well,
i think some won't like my end goal, saying it's not the "MAVEN
WAY", or say
that maven was not designed for it.
but i'll explain nonetheless, since some might like the idea and
make use of
it also.
In the beginning there were a few friends: Perl, MAKE and RPM.
they all played together and once in a while RPM left and gone to
YUM :)
When the rpm wanted to be on production, YUM installed it (with all
his Dependant friends that tag a long with him wherever he goes,
although
they are each unique and can be installed via YUM separately).
Now the company has decided to move to JAVA programming, so the new
friends
are:
Java, Maven and Jar. and once in a while JAR went to Artifactory
(or Nexus
sometimes).
But.. when the JAR file wanted to be installed on production,
Artifactory
didn't know what he wanted, since he only servers development
environment.
But it doesn't make sense. Maven has an amazing dependency
architecture that
overcomes many of RPM's problems and can be easily be used like YUM
for
actual production deployment.
Unfortunately, i didn't find any plugin that does the job, nor did
any of
the usual solutions were relevant (wagon, assembly, uber-jar,
containers..)
So i decided to use maven plugins like "dependency:copy-
dependencies" and
the GMaven plugin to accomplish this, which i then wrapped in a bash
script
to run all the maven properties together.
I created a generic POM file that will install any project i'll tell
him via
the -D command line options.
it works beautifully, with a small issue regarding the unjaring of
resources
with GMaven.
*of course the final end game is to create a new "Maven Production
Installer" plugin.*
*
*
*but until then, i want to create a working environment and close
the loop.*
*
*
This is probably a result of my company unique status, where all of
the code
is deployed to a center which is manged by US, and there is no end-
customer
that waits for a complete .tar.gz pacakge.
*
*
*I hope i made my goal clear, *
*
*
*Eyal.
*
On Sun, Feb 21, 2010 at 3:53 PM, Stephen Connolly <
[email protected]> wrote:
the problem with that us always going to be transitives...
if I depend on your module, unless I know how to get the property
values, I
will be unable to get your transitive dependencies... so as such
the only
way maven could determine what your transitive dependencies are,
would be to
fire up a lifecycle on your pom... but I only have your pom
downloaded from
the remote repo, and not your full project...
that is why what you are trying to do is a bad plan... perhaps if you
describe your ultimate end game, but I suspect you are putting
scripting
into your pom because you want to avoid creating a maven plugin for
"this
one special case"... sometimes it's just easier to create a plugin...
we have one project that did some code generation by using a peel
script to
parse a C++ header file generate some XML which was then passed
through xslt
to generate the java source code... it's a one off... but in the
end it was
better off writing a maven plugin... and now we gave replaced the
perl with
java code to parse... so our whole build is now in java... easier
bootstrap
for new devs
but 3 years ago I almost said, just hack it with antrun and exec...
Sent from my [rhymes with tryPod] ;-)
On 21 Feb 2010, at 13:19, eyal edri <[email protected]> wrote:
hi,
is it possible to read a property that is calculated by maven in
runtime:
<modelVersion>4.0.0</modelVersion>
<groupId>com.company.install</groupId>
<artifactId>JavaInstaller</artifactId>
<packaging>pom</packaging>
<version>0.0.2-SNAPSHOT</version>
<name>Java Installer</name>
<description>Installer for maven java projects</description>
<parent>
<groupId>com.company.maven.pom</groupId>
<artifactId>CtchParent</artifactId>
<version>0.0.16-SNAPSHOT</version>
</parent>
* <properties>*
* <installedVersion>0.0.1-SNAPSHOT</installedVersion>*
* </properties>*
<dependencies>
<dependency>
<groupId>${installedGroupId}</groupId>
<artifactId>${installedArtifactId}</artifactId>
* <version>(${installedVersion},)</version> -> this will
install the
latest version available from the repo.*
</dependency>
</dependencies>
can i access the project.dependencies.dependency.version value?
i need it in a groovy code that is run afterward using GMaven
plugin.
thanks!
--
Eyal Edri
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Eyal Edri
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
