You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Bartosz Kowalewski <ko...@gmail.com> on 2010/05/21 02:31:42 UTC
A proposal on how to clean-up some of the Aries projects
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
Re: A proposal on how to clean-up some of the Aries projects
Posted by Bartosz Kowalewski <ko...@gmail.com>.
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 <jg...@gmail.com>:
> 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
> <ko...@gmail.com> 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
>>
>
Re: A proposal on how to clean-up some of the Aries projects
Posted by Jarek Gawor <jg...@gmail.com>.
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
<ko...@gmail.com> 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
>