You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Heiko Studt <he...@iteg.at> on 2022/11/14 14:31:40 UTC

Problems during initial build of Aries

Hello,

I'd got some problems on getting Aries to build locally:

1.
According to the website, Aries is still on SVN:

https://aries.apache.org/documentation/development/buildingaries.html
https://aries.apache.org/documentation/development/resources.html

According to the Readme in GitHub and the mails in the mailing list, the 
GIT is primarily used for development:
https://github.com/apache/aries/blob/trunk/README.md

=> So I am using a github clone of the branch "trunk".

2.
I've tried to use JDK 11, but the "versioning" is still depending on the 
Java-5 file format (to my understanding it is reading the internal 
structure of those class files).
=> I go along with JDK-8.

I did not find this information on any web page or Readme!?
Do you have any plans on migrating to some higher build setup?

3.
Then, I needed to modify blueprint/blueprint-parent/pom.xml for the 
correct SNAPSHOT version numbers. Like blueprint.core was 
1.10.2-SNAPSHOT, but locally it was building the 1.10.4-SNAPSHOT version.

For completeness, I have built everything and had to modify the 
following as well:

  * proxy/proxy-itests/pom.xml: org.apache.aries.proxy was like 6 
version numbers behind...
  * transactions/transaction-itests/pom.xml: change the version of 
org.apache.aries.transaction.blueprint

This problem is possibly not occurring for the daily builder's setup, as 
those have built these versions on the same machine before. Though, I do 
not know whether this possibly affects the test's validity for the 
jumped versions!?


Do you want a PR for the currently missing version configs?


MFG
-- 
Heiko Studt


Re: Problems during initial build of Aries

Posted by Raymond Augé <ra...@liferay.com.INVALID>.
Hello Heiko,

sorry for your troubles. You changes are welcome but here's a micro
orientation on how things work in this repo:

Typically you navigate into one of the sub projects and build from there.
Each project may be at different levels of JDK, have different
(inter)dependencies and then is released independently.

The fact that some (sub project) dependencies don't reflect the exact
versions of the real sub projects in the repo is pretty much expected.

If you are planning to make changes however, do so on one single sub
project at a time so that issues are trackable per the associated JIRA
component.

Sincerely,

On Mon, Nov 14, 2022 at 9:32 AM Heiko Studt <he...@iteg.at> wrote:

> Hello,
>
> I'd got some problems on getting Aries to build locally:
>
> 1.
> According to the website, Aries is still on SVN:
>
> https://aries.apache.org/documentation/development/buildingaries.html
> https://aries.apache.org/documentation/development/resources.html
>
> According to the Readme in GitHub and the mails in the mailing list, the
> GIT is primarily used for development:
> https://github.com/apache/aries/blob/trunk/README.md
>
> => So I am using a github clone of the branch "trunk".
>
> 2.
> I've tried to use JDK 11, but the "versioning" is still depending on the
> Java-5 file format (to my understanding it is reading the internal
> structure of those class files).
> => I go along with JDK-8.
>
> I did not find this information on any web page or Readme!?
> Do you have any plans on migrating to some higher build setup?
>
> 3.
> Then, I needed to modify blueprint/blueprint-parent/pom.xml for the
> correct SNAPSHOT version numbers. Like blueprint.core was
> 1.10.2-SNAPSHOT, but locally it was building the 1.10.4-SNAPSHOT version.
>
> For completeness, I have built everything and had to modify the
> following as well:
>
>   * proxy/proxy-itests/pom.xml: org.apache.aries.proxy was like 6
> version numbers behind...
>   * transactions/transaction-itests/pom.xml: change the version of
> org.apache.aries.transaction.blueprint
>
> This problem is possibly not occurring for the daily builder's setup, as
> those have built these versions on the same machine before. Though, I do
> not know whether this possibly affects the test's validity for the
> jumped versions!?
>
>
> Do you want a PR for the currently missing version configs?
>
>
> MFG
> --
> Heiko Studt
>
>

-- 
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow, Java Champion