We do have an internal repository set up, as I would imagine others will
too. At our company we have a so called 'library' with call kinds of handy
utilities that are used in other projects.

So deploying the maven style to that internal repository will see that just
as the normal plugin.

We also have setup maven-proxy as well, but that is not a requirement I
think.

We have a server running cruisecontrol (yes, we are planning to move to
continuum as soon as it has rss support build in) and there it automatically
detects the latest version of the checkstyle dependancy. So I am pretty sure
it works very well ;)

Kind regards,
Roy

On 9/5/06, Stephen Duncan <[EMAIL PROTECTED]> wrote:

My experience is that this won't work for people who have not manually
installed the shared project; the dependency won't be downloaded from
an internal repository, it will only try "central" (you won't see this
if you use a proxy & mirror for central I guess).  I believe the
correct way to do this is by declaring acompany:acompany_style as an
extension.

      <build>
          <extensions>
              <extension>
                  <groupId>acompany</groupId>
                  <artifactId>acompany_style</artifactId>
                  <version>1.0-SNAPSHOT</version>
              </extension>
          </extensions>
      </build>

-Stephen

On 9/4/06, Roy van der Kuil <[EMAIL PROTECTED]> wrote:
> Hi,
>
> We have a similar setup and have created a 'project' with only a couple
of
> resources. (our own version of the checkstyle xml and suppressions).
>
> We deployed this 'jar' and made the maven-checkstyle-plugin dependant on
> that dependancy:
>       <plugin>
>         <groupId>org.apache.maven.plugins</groupId>
>         <artifactId>maven-checkstyle-plugin</artifactId>
>          <dependencies>
>           <dependency>
>               <groupId>acompany</groupId>
>               <artifactId>acompay_style</artifactId>
>               <version>1.0-SNAPSHOT</version>
>           </dependency>
>         </dependencies>
>       </plugin>
>
> This actually works very well and makes sure every project uses the
'latest'
> style.
>
>
> On 9/4/06, Olivier Vierlinck <[EMAIL PROTECTED]> wrote:
> >
> > We use maven+checkstyle on a multi-project.
> >
> > We have defined our checks (mycheckstyle.xml) for one of the
component.
> > The
> > xml file is stored right at the root of the component (next to the src
and
> > target folders) in the top pom file we have:
> >
> >    <plugin>
> >       <groupId>org.apache.maven.plugins</groupId>
> >       <artifactId>maven-checkstyle-plugin</artifactId>
> >       <configuration>
> >          <configLocation>mycheckstyle.xml</configLocation>
> >       </configuration>
> >    </plugin>
> >
> > So we have a structure like this
> >
> >    topProject
> >    --- pom.xml
> >
> >    --- subComponent1
> >    --- --- src
> >    --- --- target
> >    --- --- pom.xml
> >    --- --- mycheckstyle.xml
> >    --- --- ...
> >
> >    --- subComponent2
> >    --- --- src
> >    --- --- target
> >    --- --- pom.xml
> >    --- --- ...
> >
> >    --- --- subsubComponent2.1
> >    --- --- --- src
> >    --- --- --- target
> >    --- --- --- pom.xml
> >    --- --- --- ...
> >
> > This works fine. But now, we would like to use the same configuration
file
> > for ALL our component. So, we would like to have our (single)
> > mycheckstyle.xml file stored only once, right under the topProject,
next
> > to
> > the top pom.xml file.
> >
> > How can we define that in the pom file. I tried using relative path
> > (../mycheckstyle.xml), full url (file:../mycheckstyle.xml), using
maven
> > variables ($project.dir/mycheckstyle.xml) but without success, always
with
> > one or another error message from maven such as
> >
> >    Unable to find location '../mycheckstyle.xml' as URL, File or
Resource.
> >
> > Is there any way to combine maven's knowledge of the
project/components
> > tree
> > so that each individual component knwos the top level and use it to
locate
> > the mycheckstyle.xml. Even better: is there a way to support component
> > with
> > different level in the tree (as subComponent2 and subComponent2.1 in
the
> > example above)
> >
> > Thanks,
> > Olivier
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>


--
Stephen Duncan Jr
www.stephenduncanjr.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


Reply via email to