RE: Depending on POM using inheritance breaks build

2010-12-14 Thread cowwoc


Eric Haszlakiewicz wrote:
> 
>>-Original Message-
>>From: cowwoc [mailto:cow...@bbs.darktech.org]
>>
>>Wayne Fay wrote:
>>>
 What do you recommend I do to work around this problem?
>>>
>>> Don't use the ${swt.classifier} for now...
>>>
>>> You may notice it was reported 5 years ago so if you actually want it
>>> fixed, you'll probably need to help on MNG-1388.
>>>
>>
>>How do you deal with artifacts that need a different native library
>>depending on the build platform without the use of ${swt.classifier}?
> 
> This feels to me like the old problem that there is no distinction between
> the pom file used to control the build, and the pom file that describes
> the artifact.  
> In a general sense, the properties that exist at the time that an artifact
> gets created (in this case swt.classifier, which was set by a profile)
> aren't remembered in the deployed artifact.
> 
> The workaround I've seen suggested for this is to throw another layer of
> indirection in there and have a separate pom for each possible value of
> your variable.  
> In your case, I think you'd split project B into a B-windows-x86/pom.xml,
> B-whateverelse/pom.xml, etc... modules that each refer to the
> swt.classifier with a fixed value.  
> Then you'd need to set up an overall pom.xml that lists different modules
> based on the profile, 
> and you'll probably want some kind of common pom that all of the
> sub-modules depend on to pull in all the other normal dependencies.
> Obviously, this doesn't work well if you have more than just one variable
> you're dealing with, 
> and it seems (to me anyway) to be an unnecessary complex and confusing way
> to set things up, 
> but supposedly that's the "maven way".
> 
> eric
> 

Gentlemen,

Does any of you care to comment on this problem? Is this convoluted approach
really the best available way of solving the problem?

Gili
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/POM-inheritance-breaks-build-tp3263869p3304793.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



RE: Depending on POM using inheritance breaks build

2010-11-15 Thread Haszlakiewicz, Eric

>Dear god, that's terrible! I don't want to have to maintain 8 different POM
>files (the number of platforms I support) per variable. Is there an easier
>workaround?

One thing I've been thinking about, but never actually tried, is to set up a 
wrapper maven build that has all the various variables, and use resource 
filtering (or perhaps the maven-replacer-plugin) to generate the real pom.xml 
file based on a template.  Then kick off real build using that generated 
pom.xml (which could be integrated into the wrapper pom with maven-exec-plugin).
Resource filtering looks like it might be convenient since it uses the same 
syntax (${foo}) for text replacement, but I suggested maven-replacer-plugin 
too, since you might want to explicitly distinguish between variables that get 
replaced and those that don't and using the plugin lets you define a custom 
token to do the search and replace on.

One snag in all of this is going to be that you can't really use the classifier 
to distinguish between the artifacts anymore b/c I believe every artifact with 
the same groupId:artifactId:version ends up with a single pom file, even if 
there are files with multiple different classifiers.

eric
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



RE: Depending on POM using inheritance breaks build

2010-11-15 Thread cowwoc


Eric Haszlakiewicz wrote:
> 
>>-Original Message-
>>From: cowwoc [mailto:cow...@bbs.darktech.org]
>>
>>Wayne Fay wrote:
>>>
 What do you recommend I do to work around this problem?
>>>
>>> Don't use the ${swt.classifier} for now...
>>>
>>> You may notice it was reported 5 years ago so if you actually want it
>>> fixed, you'll probably need to help on MNG-1388.
>>>
>>
>>How do you deal with artifacts that need a different native library
>>depending on the build platform without the use of ${swt.classifier}?
> 
> This feels to me like the old problem that there is no distinction between
> the pom file used to control the build, and the pom file that describes
> the artifact.  
> In a general sense, the properties that exist at the time that an artifact
> gets created (in this case swt.classifier, which was set by a profile)
> aren't remembered in the deployed artifact.
> 
> The workaround I've seen suggested for this is to throw another layer of
> indirection in there and have a separate pom for each possible value of
> your variable.  
> In your case, I think you'd split project B into a B-windows-x86/pom.xml,
> B-whateverelse/pom.xml, etc... modules that each refer to the
> swt.classifier with a fixed value.  
> Then you'd need to set up an overall pom.xml that lists different modules
> based on the profile, 
> and you'll probably want some kind of common pom that all of the
> sub-modules depend on to pull in all the other normal dependencies.
> Obviously, this doesn't work well if you have more than just one variable
> you're dealing with, 
> and it seems (to me anyway) to be an unnecessary complex and confusing way
> to set things up, 
> but supposedly that's the "maven way".
> 

Dear god, that's terrible! I don't want to have to maintain 8 different POM
files (the number of platforms I support) per variable. Is there an easier
workaround?

PS: Eric is quite right in that the built artifact should remember/hard-code
the values used to build it. Anyone who depends on it should use the
hard-coded values.

Gili
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/POM-inheritance-breaks-build-tp3263869p3266370.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



RE: Depending on POM using inheritance breaks build

2010-11-15 Thread Haszlakiewicz, Eric
>-Original Message-
>From: cowwoc [mailto:cow...@bbs.darktech.org]
>
>Wayne Fay wrote:
>>
>>> What do you recommend I do to work around this problem?
>>
>> Don't use the ${swt.classifier} for now...
>>
>> You may notice it was reported 5 years ago so if you actually want it
>> fixed, you'll probably need to help on MNG-1388.
>>
>
>How do you deal with artifacts that need a different native library
>depending on the build platform without the use of ${swt.classifier}?

This feels to me like the old problem that there is no distinction between the 
pom file used to control the build, and the pom file that describes the 
artifact.  
In a general sense, the properties that exist at the time that an artifact gets 
created (in this case swt.classifier, which was set by a profile) aren't 
remembered in the deployed artifact.

The workaround I've seen suggested for this is to throw another layer of 
indirection in there and have a separate pom for each possible value of your 
variable.  
In your case, I think you'd split project B into a B-windows-x86/pom.xml, 
B-whateverelse/pom.xml, etc... modules that each refer to the swt.classifier 
with a fixed value.  
Then you'd need to set up an overall pom.xml that lists different modules based 
on the profile, 
and you'll probably want some kind of common pom that all of the sub-modules 
depend on to pull in all the other normal dependencies.
Obviously, this doesn't work well if you have more than just one variable 
you're dealing with, 
and it seems (to me anyway) to be an unnecessary complex and confusing way to 
set things up, 
but supposedly that's the "maven way".

eric
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Depending on POM using inheritance breaks build

2010-11-14 Thread cowwoc


Wayne Fay wrote:
> 
>> What do you recommend I do to work around this problem?
> 
> Don't use the ${swt.classifier} for now...
> 
> You may notice it was reported 5 years ago so if you actually want it
> fixed, you'll probably need to help on MNG-1388.
> 

How do you deal with artifacts that need a different native library
depending on the build platform without the use of ${swt.classifier}?

Thanks,
Gili
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/POM-inheritance-breaks-build-tp3263869p3264597.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Depending on POM using inheritance breaks build

2010-11-14 Thread Wayne Fay
> What do you recommend I do to work around this problem?

Don't use the ${swt.classifier} for now...

You may notice it was reported 5 years ago so if you actually want it
fixed, you'll probably need to help on MNG-1388.

Wayne

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Depending on POM using inheritance breaks build

2010-11-14 Thread cowwoc


Benjamin Bentmann wrote:
> 
> Looks like http://jira.codehaus.org/browse/MNG-1388
> Benjamin

What do you recommend I do to work around this problem?
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/POM-inheritance-breaks-build-tp3263869p3264522.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Depending on POM using inheritance breaks build

2010-11-14 Thread Benjamin Bentmann

cowwoc wrote:


 
 
 org.eclipse.swt
 swt
 ${swt.classifier}
 3.6.1
 
 
 
 
 windows-x86
 
 win32-x86
 
 
 


Looks like http://jira.codehaus.org/browse/MNG-1388


Benjamin

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org



Re: Depending on POM using inheritance breaks build

2010-11-14 Thread cowwoc

Hi,

   I'm getting a build error when my project depends on a POM that uses
inheritance. Given three POM files:

* C depends on B.
* B inherits from A.
* I can build A and B
* C fails to build because of its dependency on B.

The full source-code and build output is included below for your review.

Here is A's POM:

http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
com.foo
A
pom
1.0-SNAPSHOT
A


foo releases
libs-releases-local
default
http://foo.net/artifactory/libs-releases-local




org.eclipse.swt
swt
${swt.classifier}
3.6.1




windows-x86

win32-x86





Here is B's POM:

http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0

com.foo
A
1.0-SNAPSHOT
../A

B
jar
B



org.apache.maven.plugins
maven-jar-plugin

${swt.classifier}






windows-x86

win32-x86





Here is C's POM:

http://maven.apache.org/POM/4.0.0";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
  xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
http://maven.apache.org/maven-v4_0_0.xsd";>
4.0.0
com.amayagaming
C
jar
1.0-SNAPSHOT
C


${project.groupId}
B
${project.version}
win32-x86




Here is the build output from C:


Building C
   task-segment: [install]

[compiler:compile]
Nothing to compile - all classes are up to date
Downloading:
http://foo.net/artifactory/libs-releases-local/org/eclipse/swt/swt/3.6.1/swt-3.6.1-${swt.classifier}.jar
[WARNING] Unable to get resource
'org.eclipse.swt:swt:jar:${swt.classifier}:3.6.1' from repository foo
releases (http://foo.net/artifactory/libs-releases-local): Error
transferring file: foo.net
Downloading:
http://repo1.maven.org/maven2/org/eclipse/swt/swt/3.6.1/swt-3.6.1-${swt.classifier}.jar
Unable to find resource 'org.eclipse.swt:swt:jar:${swt.classifier}:3.6.1' in
repository central (http://repo1.maven.org/maven2)

[ERROR]BUILD ERROR

Failed to resolve artifact.

Missing:
--
1) org.eclipse.swt:swt:jar:${swt.classifier}:3.6.1


Please help!

Thanks,
Gili
-- 
View this message in context: 
http://maven.40175.n5.nabble.com/POM-inheritance-breaks-build-tp3263869p3264491.html
Sent from the Maven - Users mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org