Thirdparty clarification
by Julien Viet
I would like to clarify how now 3rd party should be managed in GateIn trunk, because it has changed implicitly since yesterday (see the another thread of this list).
Now we are trying to handle all 3rd party dependencies in a separate "dependency" oriented pom known as gatein-dep that specifies the version of the library we use in GateIn and its components (although it is less strict for component). This has been existing until now but was not really used, so it's not really something new, what is new is that now we want to use it for real.
This pom is not in the project itself which means that it has a separate lifecycle and any update to the thirdparty should be done here. It may seem a bit heavy but in fact this serve the purpose that updating a lib has often consequences at the integration level of the whole server. So indeed if one version must be changed or added, this should be done in this gatein-dep pom. Actually this helped me to find out dated libraries in gatein that were expected by Shindig at runtime but were not satisfied (now the Shindig fork uses the gatein-dep as it has many dependencies).
The gatein-dep pom can be found here http://anonsvn.jboss.org/repos/gatein/maven/dep/trunk/
It is integrated in gatein by a declaration in the parent pom:
<dependency>
<groupId>org.gatein</groupId>
<artifactId>gatein-dep</artifactId>
<version>1.1.0-Beta03</version>
<type>pom</type>
<scope>import</scope>
</dependency>
Of course it does not mean you cannot override a version in your own pom when you need to test something like adding a new library or changing a version to test something. Actually this can be done by changing the parent pom in your local copy. When you think something should be changed or added, then you should raise the concern to get this change in the gatein-dep pom.
cheers
Julien
13 years, 10 months
Some portal build fixes
by Marko Strukelj
I’ve done some fixes on the portal build …
I’ve added parent.relativePath to many modules to fix ‘chicken or egg’
problem that caused failures when building from scratch with empty
repository, without additional settings.xml. Might be that I just patched up
the ‘bugs’, not really fixed them, as the modules involved might have wrong
parents set in the first place. But it clean builds now when before it
didn’t (using maven3).
Also, in jboss packaging we have a dependency on
org.exoplatform.portal:exo.portal.server.jboss.plugin
Looking at the contents of this artifact it’s obvious that it has no effect
at all. It contains one conf/portal/configuration.xml file whose content is
completely commented out.
This is the only artifact for jboss-as5 and jboss-as6 packaging that depends
on exo maven repository - it’s not available in jboss repo.
So I commented it out for both jboss-as5 and jboss-as6 packaging, and it now
builds OOTB without having to create settings.xml with repositories
definitions.
Also I’d prefer if we mandate maven3 for build. It’s double work to test
build for maven2, as well as for maven3, and there’s constant dilemma if
someone claims build doesn’t work - what version of maven they used. I see
no good reason to maintain compatibility with maven2, when build works
perfectly fine with maven3.
There’s the issue of packaging/profiles.xml which has no effect when
building with maven3, so currently you have to specify extra settings via
CLI. That can be fixed by moving properties into packaging/pom.xml.
- marko
13 years, 10 months
Thirdparty update
by Julien Viet
Hi All,
I have upgraded gatein trunk with a major thirdparty update: https://issues.jboss.org/browse/GTNPORTAL-1867.
It means that it is possible that you can observe different behavior when using the server, but I'm confident that the changes are ok, however I would feel better if you could review the patch.
The changes can be divided into two categories:
1/ JCR 1.14.0-CR1 upgrade that changes many thirdparties (like Groovy)
2/ Chromattic 1.1.0-beta2 that brings a few new features used by GateIn (like improved support for mixins)
There is one change for JCR that was not done that is the upgrade of SLF4J to 1.6, because it would need to change first a few dependencies consuming SLF4J 1.5.x (gatein dependencies, Chromattic).
cheers
Julien
13 years, 10 months
Some old issue
by Thomas Heute
Javascript merge/compressing seems to not behave well in all cases and
we got a couple of comments from customers and users:
https://issues.jboss.org/browse/GTNPORTAL-1182
What's the status on this ? I remember that we looked into other JS
compressors but what was the decision on this ?
Thomas
13 years, 10 months
GateIn Maven update
by Thomas Heute
I've updated GateIn portal to only use 1 repository
https://repository.jboss.org/nexus/content/groups/public/ (which proxies
several repositories).
I kept the definition of the repo in GateIn Portal root pom to
facilitate users/contributors life when they want to build the portal.
For components, there is no definition of repositories (so it doesn't
get inherited) and if you need to build a component you will need to add
the repository in your own settings.xml. I don't have the snippet handy
(I use mirrorOf as I am psychotic), if someone has the definition of the
profile, please paste it here.
Also do not add any new repository definition, we can add thirdparty
libraries into the JBoss one or we can proxy more repositories if needed.
I tested locally and I hope I didn't break the build for anyone (Tested
on Maven 2.2.1/Linux environment).
Thanks,
Thomas
13 years, 10 months
