Hi all,

@Stephen C. thanks for the answer
@Karl H. after this long thread discussion became clear to me what's a best
solution for this kind of necessity in maven projects. I read your blog post
and the suggestion there is cool but it's not exactly what I was looking
for, but anyway thinks for the help.
@Mirko F. I was aware about the ${user.dir} property before all this
discussion but I think that property is not flexible as I the way desired,
so I discarded it.
@Baptiste M. I aware of this plugin but it doesn't solve what I need, thanks
for the tip.

Following the Maven Way™, I put my shared resources in a common dependecy so
it's easy now to share them between the projects but this led to a situation
where the resources that once before was in the src/main/resources of main
project, now they are inside of src/main/resources of a child project. In
fact, I have now two shared dependencies, one with application scope shared
files and one with test scope files, in both I have information about
database connections, one for production, one for tests.
Well, my problem now is how can I use these properties in such files in my
pom's files as maven properties? There is a plugin called
properties-maven-plugin that's suppose to help with that but it was blamed
as hell in this thread
(http://mojo.10943.n7.nabble.com/State-of-properties-maven-plugin-td39686.html),
and even if it was a good plugin, again it will lead to the problem of
shared files by the file system.

I'm putting this situation here just to take the oportunity of this
discussion as I would like to question about the Maven and the Maven Way™.
After I had reach in the will of suggest that the property 'rootParentDir'
be created and see that it was a afront against the Maven Way™ I started to
inquiry how I reach such conclusion that create such property will be a good
idea and, disregarding some of my misconcepts about the Maven Way™, I think
that was Maven itself that lead me to such conclusion. Maven resources or
build filters is all based on things on file system. If you will want to
specify a resource or a build filter you need to specify a absolute or
relative path to that resource. Why this it can't be speficied from the
classpath too? Or it can be? It's possible?

As example, the plugin flyway-maven-plugin have an option to configure the
resources it will look for as following:

                <plugin>
                    <groupId>com.googlecode.flyway</groupId>
                    <artifactId>flyway-maven-plugin</artifactId>
                    <version>2.1.1</version>
                    <configuration>
                        <driver>${database.driver}</driver>
                        <url>${database.url}</url>
                        <user>${database.user}</user>
                        <password>${database.password}</password>
                        <locations>
                            *<location>classpath:database/schema</location>*
                        </locations>
                    </configuration>
                </plugin>

Will be useful if build filters or maven properties could be
specified/loaded in the same manner, from the classpath (or something maven
like). Even in this example, the properties ${database.*} needs be declared
in somewhere like a filter file which location is based on the file system
or as maven properties, either one will lead in a duplication of that
properties information (one in filter/maven property, one in a property file
of shared dependency).

This approach with maven filters or properties is valid or again I'm
misunderstanding some maven concept?
If it's valid, anyone know if exist some effort on that or even, if it
already exist? Otherwise an improvement in the properties-maven-plugin to
feature this is valid or maybe create a new plugin?

Thanks.



-----
Anderson Vaz
--
View this message in context: 
http://mojo.10943.n7.nabble.com/Build-Helper-Maven-Plugin-Build-MetaData-Maven-Plugin-tp39569p39725.html
Sent from the Developer mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply via email to