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, 7 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, 8 months
clustering sso, exo.profiles and wsrp webservice security
by Matt Wringe
Hi,
For wsrp ws-security we need to pass the username and actual password
(not token) between the consumer and producer. We need to do what is
currently done with the ClusteredSSOFilter and PortalLoginModule when
the clustering exo.profile is enabled.
What is the current policy for dealing with exo.profiles? I can't seem
to find much info on it other than when to use it for the clustering
setup.
Would it be acceptable to create a 'sso' or 'wsrpsso' profile which
would also enable the authenticated credentials propagation in the
ClusteringSSOFilter and PortalLoginModule? Or is the profile setup
reserved for other tasks?
I would rather not have to duplicate this effort in the wsrp code.
Thanks,
Matt Wringe
13 years, 8 months
Trunk with Maven 2.2.1
by Thomas Heute
Some of you may have noticed that trunk has an issue with Maven 2.2.1 it
ends up with:
***********************************************
[ERROR] BUILD ERROR
[INFO]
------------------------------------------------------------------------
[INFO] Error building POM (may not be this project's POM).
Project ID: org.gatein:gatein-dep
Reason: POM 'org.gatein:gatein-dep' not found in repository: Unable to
download the artifact from any repository
org.gatein:gatein-dep:pom:1.0.3-Beta01
from the specified remote repositories:
central (http://repo1.maven.org/maven2),
__jpp_repo__ (file:///usr/share/maven2/repository)
for project org.gatein:gatein-dep
***********************************************
And it seems to work fine with Maven 3.
The thing is related to the fact that gatein consumes a component which
includes gatein-dep with the scope "import", it seems to be exactly the
same issue as:
http://maven-users.828.n2.nabble.com/Resolving-dependencies-of-type-pom-t...
Also it may have been related to:
http://jira.codehaus.org/browse/MNG-3553 (Funny to see that the reporter
and assignee are Red Hat employees, and 1 of the commenter is our famous
Arnaud :))
So as a workaround I added the dependency in the parent pom which solves
the issue (Not committed yet as I'm also fixing other stuff).
Thomas
13 years, 8 months
Component releases
by Thomas Heute
The following components have been released:
parent 1.1.0-Beta01
dep 1.0.3-Beta01
common 2.0.4-Beta01
wci 2.1.0-Beta01
pc 2.3.0-Beta01
mop 1.0.6-Beta01
Alain, you can go ahead and merge your WCI integration in GateIn using
WCI 2.1.0-Beta01.
Later we will release GateIn 3.2 Beta01 as time allows.
We'll still need to release WSRP and SSO.
Thomas.
13 years, 8 months
XML Parsing, where do we stand
by Thomas Heute
Nick, Julien, Alain,
As said before we'd like to harmonize the XML parsing accross the GateIn
projects. Let's kill this once for all...
It doesn't mean we would change the existing parsers overnight but it
means we will impose a way for any new parsing (or when we decide to
rewrite a parser).
If we need parser tools, they will go in Common module ultimately. There
might be a phase when the code will be duplicated (as Nick's tools need
to work on an untouched portal where upgrading common is not an option).
We already agreed that StAX as a base was the way to go, I hope we still
agree ;)
Let's separate in reading/writing XML (doesn't necessarily necessarily
mean marhalling/unmarshalling BTW) and agree on both.
Reading XML:
Option 1:
Plain StAX, JBoss AS 7 uses that (in fact they use StAX Mapper,
a very lightweight library made by the JBoss AS7 team.
https://github.com/jbossas/staxmapper/ which only helps to work with
multiple namespaces + some little helpers for ignoring part of the file,
format the XML when writing...)
One example of JBoss AS 7 parsing file:
https://github.com/emuckenhuber/jboss-as/blob/master/web/src/main/java/or...
Option 2:
Nick's stuff (please explain advantages/drawbacks)
Option 3:
Julien/Alain's stuff (please explain advantages/drawbacks)
Writing XML:
Option 1:
Plain StAX (well-formed guaranteed over plain Writer)
Option 2:
Nick's stuff (please explain advantages/drawbacks)
Option 3:
Julien/Alain's stuff (please explain advantages/drawbacks)
Note that there are other utilities and frameworks based on StAX:
Stax-Utils: http://stax-utils.dev.java.net/
StaxMate: http://wiki.fasterxml.com/StaxMateHome
Apache Axiom: http://ws.apache.org/commons/axiom/
Thomas/
/
13 years, 8 months
