search

sonatype / nexus-ruby-support

26 stars 7 forks source link

Fix pom files to work with Nexsus 2.6 #32

Closed rseddon closed 11 years ago

rseddon commented 11 years ago

Fix build to work against 2.6.0-04

mkristian commented 11 years ago

do you think we can switch between nexus-oss-webapp and nexus-bundle-template via profile activation. i.e. the nexus-oss-webapp with "activeByDefault" and the other when the property nexux.version is set to 2.6.0.05 ? though it might be a bit cumbersome in the long run but now it feels wrong to break the build for nexus.version 2.5.x since you still need to build the plugin for whatever nexus version you are running.

peterlynch commented 11 years ago

activeByDefault is evil and should never be used under any circumstance.

The more correct solution is to use pom properties to control the bundle to test with. Should model the ITs after how Nexus is doing it.

https://github.com/sonatype/nexus-oss/blob/master/pom.xml#L114

Also I noticed https://github.com/sonatype/nexus-ruby-support/blob/master/nexus-ruby-plugin-its/src/test/filtered-resources/injected-test.properties with hard coded bundle GA, so this pull will probably not fix all scenarios.

mkristian commented 11 years ago

activeByDefault is evil and should never be used under any circumstance.

could be please explain that statement as such the is no reason to believe it is evil.

mkristian commented 11 years ago

the nexus setup just introduce another indirection. that does not help much since the people need to be able to build the plugin for nexus.version=2.5.0.04 and the ITs need to use the nexus server for the same version and maven needs to trigger the download for the weboss or webtemplate artifacts for which they need to part of the POM.

so as long you can not build plugins with older versions (without getting errors even so the ITs error does not matter for building the plugin) it makes no sense to to switch to a setup for the "latest" version ONLY

mkristian commented 11 years ago

thanx for the PR and I would really appreciate some pointers to the "evil" topic from above ;)

peterlynch commented 11 years ago

@mkristian

evil because it helps introduce potential build problems without your knowledge ( or at least the knowledge of someone not familiar with the build process.

Suppose you have:

<profiles>
    <profile>
      <!-- activate my awesome defaults for build feature 1 -->
      <id>active-by-default-1</id>
      <activation>
        <activeByDefault>true</activeByDefault>
      </activation>
    </profile>

    <profile>
      <!-- activate my ADDITIONAL stuff I want during release using -Prelease or with maven-release-plugin config for example -->
      <id>release</id>
    </profile>

  </profiles>

Now everything works great until someone comes along with -Prelease ( like release plugin) - now everything that was useful in the active-by-default-1 profile is not activated and builder was none the wiser.

The better approach is to put defaults outside of profiles, perhaps using default property values, never use 'activebyDefault'. Then you will be assured you build up or replace pom configuration in a predictable manner.

Don't even get me started on how inheritance of activeByDefault is semantically broken...

:-P

mkristian commented 11 years ago

thanx for explanation - makes perfect sense ;) anyways I did already change the setup without active-by-default and just pushed it