Hi Felix, It probably won't help you, but I had the same issue when creating the iPOJO Ant Task. For me the issue was for Xerces. The approach I used is kind of strange but works. Instead of having one artifact for ant and maven... I created three artifacts: - a common one (iPOJO Manipulator) which do the work but propose stable a front end. - a maven plugin receiving Maven configuration and configuring the manipulator - a ant task that do the same as the maven plugin. This artifact includes Xerces.
The advantage of this approach is that I can change the manipulator version using Ant and Maven configuration (Ant task classpath and Maven plugin dependency). Regards, Clement 2010/10/20 Felix Meschberger <[email protected]> > Hi all, > > Working on FELIX-2642 I was able to get the Maven SCR Plugin also be an > Ant Task. Unlike Maven, though, Ant is not out-of-the-box able to > automatically download task (and other) dependencies from the web. Yet, > for the Ant task to fully function, the QDox, ASM and our own SCR > Annotations library must be available to the task. > > The easiest thing would be to just include the QDox, ASM and our own SCR > Annotations libraries inside the maven-scr-plugin JAR file. > > What I am unsure about is, whether we should really include the > libraries with the standard maven-scr-plugin JAR file or whether we > should create anonther, Ant-specific, artifact. > > From my POV here are the pros an cons of integrating the libs with the > standard build: > > + easier build > + resolves a build time dependency problem for maven too > (the scr.annotations SNAPSHOT needs not be deployed because it > is already included in the plugin) > + no additional QDox and ASM downloads > - bigger size of the JAR file > - It would probably be impossible to upgrade the QDox or ASM > dependency for the maven-scr-plugin in a per-plugin dependencies > section > > I currently tend to just include the libraries with the standard build. > > WDYT ? > > Regards > Felix >
