[Design of JBoss Build System] - Maven Version ranges - generateReleasePoms (Repost)
by adrian＠jboss.org
In order to capture what was actually used to build the release
you need to generate a release pom. This is a release-pom.xml that gets checked in
when you tag the release in release:perform.
| <plugin>
| <groupId>org.apache.maven.plugins</groupId>
| <artifactId>maven-release-plugin</artifactId>
| <version>2.0-beta-7</version>
| <configuration>
| <!-- The tagBase property is needed during the release process so that the maven release plugin
| - will create the tag in the appropriate svn location. If the svn location is the default
| - of "../tags" then we don't need to specify the tagBase. -->
|
| <tagBase>svn://localhost/project2/tags/</tagBase>
|
| <!-- HERE -->
|
| <generateReleasePoms>true</generateReleasePoms>
|
| <!-- We don't want to use the default release profile because it creates javadoc jars for the repo.
|
| - Since we include source jars in the repo, we don't need the javadoc jars. -->
| <useReleaseProfile>false</useReleaseProfile>
|
| <!-- The release plugin activates a custom profile called "release". -->
| <arguments>-Prelease</arguments>
| </configuration>
| <inherited>true</inherited>
| </plugin>
| </plugins>
|
I think we should do this anyway even if we don't use version ranges.
This captures all the information used to build the release including the
user's ~/.m2/settings.xml relevant to the build
e.g. you can see that during my testing I have been using some
local repositories to get artifacts.
| <?xml version="1.0" encoding="UTF-8"?><project>
| <modelVersion>4.0.0</modelVersion>
| <groupId>test</groupId>
| <artifactId>project2</artifactId>
| <name>Project2</name>
| <version>1.0.0-Beta-5</version>
| <description>Project2</description>
| <url>http://www.jboss.org/project2</url>
| <issueManagement>
| <system>jira</system>
| <url>http://jira.jboss.com/</url>
| </issueManagement>
| <licenses>
| <license>
| <name>lgpl</name>
| <url>http://repository.jboss.com/licenses/lgpl.txt</url>
| </license>
| </licenses>
| <scm>
| <connection>svn://localhost/project2/tags/project2-1.0.0-Beta-5</connection>
| <developerConnection>svn://localhost/project2/tags/project2-1.0.0-Beta-5</developerConnection>
| </scm>
| <organization>
| <name>JBoss, a division of Red Hat, Inc.</name>
| <url>http://www.jboss.org</url>
| </organization>
| <build>
| <sourceDirectory>src/main</sourceDirectory>
| <scriptSourceDirectory>src/main/scripts</scriptSourceDirectory>
| <testSourceDirectory>src/tests</testSourceDirectory>
| <outputDirectory>target/classes</outputDirectory>
| <testOutputDirectory>target/test-classes</testOutputDirectory>
| <resources>
| <resource>
| <directory>src/main/resources</directory>
| </resource>
| </resources>
| <testResources>
| <testResource>
| <directory>src/test/resources</directory>
| </testResource>
| </testResources>
| <directory>target</directory>
| <finalName>project2</finalName>
| <plugins>
| <plugin>
| <artifactId>maven-surefire-plugin</artifactId>
| <version>2.4.1</version>
| <configuration>
| <redirectTestOutputToFile>true</redirectTestOutputToFile>
| <includes>
| <include>**/*TestCase.java</include>
| </includes>
| <useSystemClassLoader>true</useSystemClassLoader>
| </configuration>
| </plugin>
| <plugin>
| <artifactId>maven-release-plugin</artifactId>
| <version>2.0-beta-7</version>
| <inherited>true</inherited>
| <configuration>
| <tagBase>svn://localhost/project2/tags/</tagBase>
| <generateReleasePoms>true</generateReleasePoms>
| <useReleaseProfile>false</useReleaseProfile>
| <arguments>-Prelease</arguments>
| </configuration>
| </plugin>
| </plugins>
| </build>
| <repositories>
| <repository>
| <releases>
| <enabled>false</enabled>
| </releases>
| <snapshots />
| <id>snapshots.jboss.org</id>
| <url>file:///home/ejort/temp/snapshots</url>
| </repository>
| <repository>
| <releases />
| <snapshots>
| <enabled>false</enabled>
| </snapshots>
| <id>repository.jboss.org</id>
| <url>http://repository.jboss.org/maven2</url>
| </repository>
| <repository>
| <releases />
| <snapshots>
| <enabled>false</enabled>
| </snapshots>
| <id>repository</id>
| <url>file:///home/ejort/temp/maven-repository</url>
| </repository>
| <repository>
| <snapshots>
| <enabled>false</enabled>
| </snapshots>
| <id>central</id>
| <name>Maven Repository Switchboard</name>
| <url>http://repo1.maven.org/maven2</url>
| </repository>
| </repositories>
| <pluginRepositories>
| <pluginRepository>
| <releases />
| <snapshots>
| <enabled>false</enabled>
| </snapshots>
| <id>repository.jboss.org</id>
| <url>http://repository.jboss.org/maven2</url>
| </pluginRepository>
| <pluginRepository>
| <releases>
| <updatePolicy>never</updatePolicy>
| </releases>
| <snapshots>
| <enabled>false</enabled>
| </snapshots>
| <id>central</id>
| <name>Maven Plugin Repository</name>
| <url>http://repo1.maven.org/maven2</url>
| </pluginRepository>
| </pluginRepositories>
| <dependencies>
| <dependency>
| <groupId>junit</groupId>
| <artifactId>junit</artifactId>
| <version>4.4</version>
| <scope>test</scope>
| </dependency>
| <dependency>
| <groupId>test</groupId>
| <artifactId>project1</artifactId>
| <version>1.0.0-Beta-1</version>
| <scope>compile</scope>
| </dependency>
| </dependencies>
| <reporting>
| <outputDirectory>target/site</outputDirectory>
| <plugins>
| <plugin>
| <artifactId>maven-javadoc-plugin</artifactId>
| <version>2.2</version>
| <configuration>
| <links>
| <link>http://java.sun.com/j2se/1.5.0/docs/api</link>
| </links>
| </configuration>
| </plugin>
| <plugin>
| <artifactId>maven-project-info-reports-plugin</artifactId>
| <version>2.0.1</version>
| </plugin>
| <plugin>
| <artifactId>maven-surefire-report-plugin</artifactId>
| <version>2.3</version>
| <reportSets>
| <reportSet>
| <reports>
| <report>report-only</report>
| </reports>
| </reportSet>
| </reportSets>
| </plugin>
| <plugin>
| <groupId>org.codehaus.mojo</groupId>
| <artifactId>taglist-maven-plugin</artifactId>
| <version>2.0</version>
| </plugin>
| </plugins>
| </reporting>
| <distributionManagement>
| <repository>
| <id>repository.jboss.org</id>
| <url>file:///home/ejort/temp/maven-repository</url>
| </repository>
| <snapshotRepository>
| <id>snapshots.jboss.org</id>
| <name>JBoss Snapshot Repository</name>
| <url>file:///home/ejort/temp/snapshots</url>
| </snapshotRepository>
| </distributionManagement>
| <properties>
| <maven.repository.root>/home/ejort/temp/maven-repository</maven.repository.root>
| <jboss.repository.root>/home/ejort/temp/repository.jboss.org</jboss.repository.root>
| </properties>
| </project>
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139822#4139822
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139822
16 years, 1 month
[Design of JBoss jBPM] - Re: New jBPM Console
by camunda
anonymous wrote : You ignore the fact that JSF knowledge is much wider spread. Which means that buiding the site in JSF makes it easer for us to deliver JSF components which will be an interesting asset for our project. Also JSF related expertise is easier to find/get/manage.
I absolutely agree with that statement! I see JSF Knowledge growing everywhere, and it makes sense, it is a Java EE 5 standard! By the way, JSF is a full day in the JBoss and EJB 3 Training, so it should be a direction JBoss is going...
And the approach started with the current console (providing facelets for reusable components) is perfectly the right one I would say.
And currently there is some effort going on to integrate JSF applications into portals as portlets (again standards everywhere!), so I think this will make it easy for customers to leverage the console also as starting point for own web guis....
Since EJB3 seems to be seen as too limiting, I would vote for POJO + JPA. In the implementation, this can be also annotated to be a EJB3 app if the container supports it (at least it works in my mind at the moment ;-)).
Cheers Bernd
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140067#4140067
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140067
16 years, 1 month
[Design of POJO Server] - Re: Tests of JRMPInvoker
by adrian＠jboss.org
"bstansberry(a)jboss.com" wrote : As part of my recent adventures in testsuite housecleaning, I saw that the testsuite jrmp-invoker target isn't executed during a testsuite run. The target runs a set of EJB2 tests with the JRMPInvoker replacing UnifiedInvoker.
|
| Any particular reason those aren't executed? If yes, any other good coverage of JRMPInvoker in the testsuite? If no, can we chuck the JRMPInvoker from AS 5 and require use of UnifiedInvoker? :-)
|
| As part of the testsuite cleanup, I got the jrmp-invoker target to run properly so if we want to keep JRMPInvoker we can add the target to the regular testsuite run.
|
| Further to all of the above, there is no "pooled-invoker" target that performs the same tests with the PooledInvoker. Same questions re: other coverage or dropping PooledInvoker apply.
If we delete the JRMPInvoker, how does JBoss4 talk to JBoss5 and vice versa
(other than using Corba? :-)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4140022#4140022
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4140022
16 years, 1 month
[Design of EJB 3.0] - Re: Security Regressions in EJB3 TestSuite
by wolfc
"anil.saldhana(a)jboss.com" wrote : Your tests should just be setting the principal/cred. Why are you trying to get the callerPrincipal from SecurityAssociation? What happened to ejbcontext.getCallerPrincipal? When will the spaghetti ejb3 layer look edible? :)
As soon as you stop mucking in ejb3-core and create a clean separation in ejb3-security. EJBContext.getCallerPrincipal() should delegate to the security component (either directly or via plugin).
The only question is whether it is possible to test ejb3-security stand alone. (It should only be a question of how.)
"anil.saldhana(a)jboss.com" wrote : Regarding getting the latest principal on the securitycontext, the api that you quote looks good. But I still am at a loss as to why you are trying to retrieve the principal/caller principal in the tests. Please point me to the tests that are trying to do this. :)
I would rather see:
Hashtable<?, ?> environment = new Hashtable<?, ?>();
| environment.put(InitialContext.SECURITY_PRINCIPAL, "me");
| environment.put(InitialContext.SECURITY_CREDENTIALS, "creds"); // TODO: String?
| InitialContext ctx = new InitialContext(environment);
| ...
| ctx.close();
but that is a nice to have.
As to the 'why' in some tests, don't bother. As long as the test is valid it must work!
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4139996#4139996
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4139996
16 years, 1 month