Hi Jarek,
#1 Thanks!
#2 Agree - not really an issue, but I always try to configure build
files, so that I do not need to tweak IDE specific descriptors.
I can see one solution for this issue. It gets rid of dependency on
the filesystem level and fetches the xsd using a Maven dependency, but
it's still a bit ugly :). Here it is:
Instead of the old reource entry for the blueprint.xsd file:
<resource>
<directory>../blueprint-api/src/main/resources/org/osgi/service/blueprint</directory>
<targetPath>org/apache/aries/blueprint</targetPath>
<includes>
<include>blueprint.xsd</include>
</includes>
</resource>
You can use:
<resource>
<directory>${project.build.directory}/xsd/org/osgi/service/blueprint</directory>
<targetPath>org/apache/aries/blueprint</targetPath>
<includes>
<include>blueprint.xsd</include>
</includes>
</resource>
And this also requires Maven to unpack the blueprint-api artifact,
retrieve the xsd and copy it to ${project.build.directory}/xsd:
<plugins>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-dependency-plugin</artifactId>
<executions>
<execution>
<id>unpack</id>
<phase>generate-resources</phase>
<goals>
<goal>unpack</goal>
</goals>
<configuration>
<artifactItems>
<artifactItem>
<groupId>org.apache.aries.blueprint</groupId>
<artifactId>org.apache.aries.blueprint.api</artifactId>
<type>jar</type>
<overWrite>false</overWrite>
<outputDirectory>${project.build.directory}/xsd</outputDirectory>
<includes>org/osgi/service/blueprint/blueprint.xsd</includes>
</artifactItem>
</artifactItems>
</configuration>
</execution>
</executions>
</plugin>
</plugins>
The xsd is retrieved from the API artifact in the generate-resources
phase, which is run before resources are processed. The final result
is the same as with the original config, but .classpath does not need
to be manually altered.
#3 Yup, of course global ignore pattern in my client solves this issue
on my side. I just thought that you may want to do clean-up and use
consistent svn:ignore vaues for all suprojects. The fact that some
projects contain svn:ignore suggests that not all committers use
global ignores :). Anyway, my intention was only to point out that
there is inconsistency in SVN properties, so that you can decide if
you want do something about it. It's definitely not a big deal :).
Thanks,
Bartek
2010/5/21 Jarek Gawor <[email protected]>:
> Bartek,
>
> I took care of #1.
>
> As for #2 it's not a big deal. It's just one time fix and only when
> setting things up in Eclipse. But if you or somebody else has a
> workaround for it that would be great.
>
> As for #3 yeah, that's true. Different people have different settings
> and things at the end are not consistent. I configured my svn client
> to ignore these directories in any project (see global-ignores
> option).
>
> Jarek
>
> On Thu, May 20, 2010 at 8:31 PM, Bartosz Kowalewski
> <[email protected]> wrote:
>> Hi All (again),
>>
>> After checking Apache Aries out and using Eclipse for playing with
>> Aries source code I have some comments to
>> http://incubator.apache.org/aries/buildingaries.html#BuildingAries-Fixingfailures
>>
>> 1) A comment on: 'If there is a build error in the
>> org.apache.aries.blueprint.itests project then remove this jar:
>> org/apache/felix/org.osgi.foundation/1.2.0.jar
>> from the project's classpath.'
>>
>> I had the same issue with a different project some time ago.
>> org.osgi.foundation contains classes that are normally shipped with
>> JDK and this leads to serious problems (as 'mvn eclipse:eclipse'
>> places the classpath entry for org.osgi.foundation above the one for
>> the JDK). Proposed change:
>>
>> Project:
>> <groupId>org.apache.aries.blueprint</groupId>
>> <artifactId>blueprint</artifactId>
>>
>> Change:
>> <dependency>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>org.apache.felix.configadmin</artifactId>
>> <version>1.2.4</version>
>> </dependency>
>>
>> To:
>>
>> <dependency>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>org.apache.felix.configadmin</artifactId>
>> <version>1.2.4</version>
>> <exclusions>
>> <!--
>> This library needs to be ignored as it attempts to
>> shadow classes
>> from JDK.
>> -->
>> <exclusion>
>> <groupId>org.apache.felix</groupId>
>> <artifactId>org.osgi.foundation</artifactId>
>> </exclusion>
>> </exclusions>
>> </dependency>
>>
>> This gets rid of the issue and youaren't forced to modify .classpath
>> anymore. The classes provided by org.osgi.foundation are all shipped
>> with JDK, so no side effects should be observed after adding this
>> exclusion.
>>
>> 2) A comment on:
>> 'You will see some of the blueprint projects don't build. To fix this
>> you need to comment out the following line:
>>
>> <!-- <classpathentry kind="src"
>> path="/Users/linsun/aries/blueprint/blueprint-api/src/main/resources/org/osgi/service/blueprint"
>> including="blueprint.xsd" excluding="**/*.java"/> -->
>>
>> in the .classpath file in the aries-blueprint-core project.'
>>
>> I don't know any clean way to get rid of this inter-project dependency
>> (dependency on the filesystem level). The source directory/package
>> structure (in the -api project) and the target directory/package
>> structure (in the -core project) are different, so such a simple
>> approach like adding maven-dependency-plugin:unpack-dependencies with
>> a single include to pom.xml will not work :/. However, the requirement
>> to manually modify the .classpath makes me feel really bad :). Is
>> anyone able to fix it in a clean way?
>>
>> 3) Some projects have svn:ignore defined:
>> *.iml
>> target
>> .settings
>> .classpath
>> .project
>>
>> but many do NOT have these entries. While I can leave without these
>> entries :), somebody might want to add the missing settings.
>>
>> Thanks,
>> Bartek
>>
>
