[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [m2e-users] Maven build with resolve worspace artifacts possible bug
|
I don't think he was referring to the specific case of test-jar classifier, but to the general term of classifier.
In his example he was saying that:
* There exists Project A, which is of WAR packaging.
* There exists Project B, which is of WAR packaging as well, but also has an attached artifact of JAR classifier (not test-classes).
* Project A depends on B JAR, and not on B WAR.
So from what I understand, in Eclipse, m2e creates the .classpath properly thus A depends on B.
But from some reason when you do Run As -> Maven Install, the dependencies are not calculated correctly, and A depends on the B JAR which resides in the .m2/repository and not the most updated one in project B.
This does seem like a bug to me as well.
On May 7, 2012, at 18:51 PM, Igor Fedorenko wrote:
> "packaging" does not apply to attached artifacts, as far as I know, but
> this is a minor terminology point.
>
> Eclipse does not have a concept similar to "attached artifacts" and each
> project is treated as single classpath entry. So when project A depends
> of project B, project A's classpath includes all exported class output
> folders of project B, including B's test-classes folder. This is likely
> the reason why your projects compile inside workspace.
>
> When workspace resolution is enabled for command-line build, m2e
> resolves attached artifacts with classifier=tests to target project's
> test-classes folder, which is not perfect but works in vast majority of
> cases. For other classifiers m2e simply has no way to know contents of
> their corresponding attached artifacts.
>
> --
> Regards,
> Igor
>
> On 12-05-07 4:03 AM, Stepan Vavra wrote:
>> Igor thank you for your response!
>>
>> I'm still not satisfied with the reasoning you wrote because the
>> resolution works correctly when requested by Eclipse build (in contrary
>> to your statement that it's not supported at all).
>> And therefore I'd just like to be clear if the problem I was referring
>> to was fully understood. You also referred to classifiers but my concern
>> are different packaging/types.
>>
>>
>> [When the resolution is ok]
>> m2e resolves the dependency to attached secondary artifact (with
>> different packaging) correctly when it is executed by Eclipse as a
>> normal build (e.g. "Build automatically" is enabled) of the project (I
>> mean it works when Eclipse itself wants to build the project with such a
>> dependency).
>>
>> BUT
>>
>> [When the resolution is NOT ok]
>> if i run the the maven script of the project with such a dependency as
>> Maven build (e.g. from Run as dialog) then m2e resolves the dependency
>> to attached secondary artifact (with different packaging) incorrectly.
>> (assuming "Resolve workspace artifacts" option is enabled)
>>
>> And since it's half working I think it's a bug.
>> My point is that m2e should resolve the dependency to attached artifacts
>> (which are different packaging types than the main artifact) in the same
>> way whether executed as Maven build or by Eclipse itself.
>>
>> Best regards,
>> Stepan
>>
>>
>> On Sun, May 6, 2012 at 10:20 PM, Igor Fedorenko <igor@xxxxxxxxxxxxxx
>> <mailto:igor@xxxxxxxxxxxxxx>> wrote:
>>
>> This is expected. Maven project model does not provide enough
>> information for m2e to be able to determine contents of project attached
>> artifacts in a generic way. We have some hardcoded logic to support
>> classifier=tests but can't support other classifiers.
>>
>> --
>> Regards,
>> Igor
>>
>>
>> On 12-05-06 3:08 PM, Stepan Vavra wrote:
>>
>> Hello,
>>
>> I've found possible bug in the way how m2e resolves workspace
>> artifacts
>> when running as maven build from run as dialog in Eclipse. And
>> therefore
>> I'd like to discuss here if it is really a bug.
>>
>> The problem is that if a project A produces secondary artifact
>> that is a
>> different type (packaging) than the main artifact... then
>> project B with
>> dependency on the secondary artifact from project A doesn't get the
>> dependency resolved into the workspace project but into the local
>> repository.
>> This happens when running maven script from Run as Maven build
>> dialog
>> with workspace artifact resolution enabled.
>> On the other hand it is ok when the build is executed by the Eclipse
>> maven builder as a part of Eclipse build.
>>
>>
>> To be more verbose:
>> 1. project A produces 2 artifacts of different types (e.g. war
>> as main
>> and jar as secondary)
>> 2. project B has a dependency on secondary artifact from project
>> A (e.g.
>> on jar artifact from project A)
>> 3. both projects are imported in Eclipse workspace
>> 4. open Maven build dialog from Run as dialog of project B
>> 5. enable the dependency workspace resolution
>> 6. run any phase (initialize is enough)
>> 7. when running maven build of project B the secondary artifact of
>> project A is not resolved to workspace but into to local repository
>>
>> However if the initialize phase of project B is executed by maven
>> builder itself (i.e. during the compilation of the workspace) the
>> secondary artifact is resolved correctly.
>>
>>
>>
>> How to reproduce the problem (each number refers to one step
>> from above):
>> 1.
>> a) create simple war project A as archetype
>> 'org.apache.maven.archetypes:__maven-archetype-webapp'
>> b) add creation of secondary artifact that is different type
>> than the
>> main one. The easiest way is to enable attach artifact option in war
>> plugin which produces jar artifact.
>> <build>
>> <finalName>webA</finalName>
>> <plugins>
>> <plugin>
>> <artifactId>maven-war-plugin</__artifactId>
>> <configuration>
>> <attachClasses>true</__attachClasses>
>> </configuration>
>> </plugin>
>>
>> </plugins>
>> </build>
>>
>> 2.
>> a) create simple war project B as archetype
>> 'org.apache.maven.archetypes:__maven-archetype-webapp'
>> d) add dependency which refers to the 'attach classes' artifact of
>> project A (the important part is that the type is jar and not war)
>> <dependency>
>> <groupId>org.test</groupId>
>> <artifactId>webA</artifactId>
>> <type>jar</type>
>> <classifier>classes</__classifier>
>> <version>1.0-SNAPSHOT</__version>
>> </dependency>
>>
>> 3.4.5.6. are hopefully clear enough
>>
>> 7.
>> a) To get information how dependencies are resolved I used maven
>> dependency plugin (to store dependencies paths in properties)
>> and gmaven
>> plugin (to print those paths on the screen)
>> b) to configure the dependency plugin:
>> <plugin>
>> <groupId>org.apache.maven.__plugins</groupId>
>> <artifactId>maven-dependency-__plugin</artifactId>
>> <version>2.3</version>
>> <executions>
>> <execution>
>> <goals>
>> <goal>properties</goal>
>> </goals>
>> </execution>
>> </executions>
>> </plugin>
>> c) to configure the gmaven plugin:
>> <plugin>
>> <groupId>org.codehaus.gmaven</__groupId>
>> <artifactId>gmaven-plugin</__artifactId>
>> <version>1.4</version>
>> <executions>
>> <execution>
>> <id>print</id>
>> <phase>initialize</phase>
>> <goals>
>> <goal>execute</goal>
>> </goals>
>> <configuration>
>> <source>
>> project.dependencies.each() {
>> identifier =
>> "${it.groupId}:${it.__artifactId}:${it.type}"
>> identifier += it.classifier ==
>> null ?
>> "" : ":${it.classifier}"
>> println "${it} resolves to: " +
>> project.properties[identifier]
>> }
>> </source>
>> </configuration>
>> </execution>
>> </executions>
>> </plugin>
>>
>> When such configuration is run as Maven build we can see that the
>> dependency points to the local repo instead to the 'target/classes'
>> directory of project A
>> If I run eclipse with allocated console (e.g. as java) (It is not
>> visible in Maven console in Eclipse (the same issue as with
>> antrun)) I
>> can see in stdout of Eclipse that gmaven outputs correctly resolved
>> dependencies to the workspace during the normal build of the
>> project B.
>>
>> I'm sorry that the formatting of the xml fragments I included is
>> probably not nicely indented.
>>
>> Thanks for your support!
>>
>> Stepan Vavra
>>
>>
>> _________________________________________________
>> m2e-users mailing list
>> m2e-users@xxxxxxxxxxx <mailto:m2e-users@xxxxxxxxxxx>
>> https://dev.eclipse.org/__mailman/listinfo/m2e-users
>> <https://dev.eclipse.org/mailman/listinfo/m2e-users>
>>
>> _________________________________________________
>> m2e-users mailing list
>> m2e-users@xxxxxxxxxxx <mailto:m2e-users@xxxxxxxxxxx>
>> https://dev.eclipse.org/__mailman/listinfo/m2e-users
>> <https://dev.eclipse.org/mailman/listinfo/m2e-users>
>>
>>
>>
>>
>> --
>> Stepan Vavra
>>
>>
>> _______________________________________________
>> m2e-users mailing list
>> m2e-users@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/m2e-users
> _______________________________________________
> m2e-users mailing list
> m2e-users@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/m2e-users
