New versioning and organisation strategy
by Pete Muir
Hi all,
Rafael, Jason and I did a brainstorm about this at JUDCon Brazil, and came up with the following proposal:
* jdf plugin for forge - longer term needs rolling into Forge core. This is issue https://issues.jboss.org/browse/FORGE-378. As this is proposed for Forge 2, we suggest not altering the version or group id of this plugin
* qstools - version scheme (starting 1.x) is good. Alter group id when we do the next major release only
* quickstarts
- change group id to follow products:
- org.jboss.quickstart.eap, org.jboss.quickstart.jdg etc.
- add a sandbox group id which covers quickstarts not in products
- change versions to follow products major.minor.micro version, with a qualifier to allow bug fixes:
- e.g. 6.0.1-qs-1, 6.0.1-qs-2 etc
* archetypes
- use group id scheme same as quickstarts but use org.jboss.archetype.eap etc.
- follow same version scheme as quickstarts, but use -atype-1 etc.
* BOMs
- use group id scheme same as quickstarts but use org.jboss.bom.eap etc.
- follow same version scheme as quickstarts, but use -bom-1
- projects will be encouraged to create BOMs as well
Let me know what you think,
Pete
12 years, 1 month
javax.enterprise:cdi-api dependency in portlet projects
by Peter Palaga
Hi Pete,
we are going to support CDI in portlets in JPP 6.1. I am trying to find
out what is the best way for customer projects (and the same for our
quickstarts) to depend on javax.enterprise:cdi-api.
cdi-api-1.0-SP4.jar comes packaged in a module javax/enterprise/api/main
with AS/EAP and GateIn depends on this module.
I see several options how customer projects could depend on it in their
POMs but I am not able to decide which one is the best:
(a) There are some POMs managing javax.enterprise:cdi-api version in
http://repo1.maven.org/maven2/org/jboss/spec/ One of those (which?)
could be imported to GateIn BOM.
(b) Manage javax.enterprise:cdi-api version directly in GateIn BOM.
(c) Let customer projects manage javax.enterprise:cdi-api themselves
Discussion:
(a) and (b) seem to be the most comfortable options for customers as
they are supposed to import GateIn BOM into their projects anyway.
(a) seems to be the most comfortable option for me as a maintainer of
GateIn BOM. For this to work, I'd need to know which of those POMs under
org/jboss/spec I should take and I'd need to know the mapping between
AS/EAP version and the chosen POM from org/jboss/spec - is that
documented somewhere?
Are there any reasons not to prefer this option?
Thanks,
Peter
12 years, 5 months
Archetype BOM version
by Rafael Benevides
Today Karel made a comment on a Archetype PR that needs an answer:
The Archetypes uses the 1.0.2.Final-redhat-1 version to as the
"jboss-bom-enterprise-version" from EAP
But Karel asked if shouldn't it use 1.0.4.Final-redhat-wfk-1 from WFK?
What it the supposed version for "jboss-bom-enterprise-version" in
Archetypes ?
Thanks
--
Rafael Benevides | Senior Software Engineer
Red Hat Brazil
+55-61-9269-6576
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
12 years, 5 months
New release versions scheme
by Rafael Benevides
Hi all,
We planned to discuss the new release schema on Judcon.
I think that for this kind of discussion it's important to identify the
dependencies from our deliverables. I think that's important because it
is probable that we will need to change the number of versions used
until now and I also think that the new release version number should
make sense to all artifacts.
Based on the attached diagram we can also discuss the release order.
When JDF .Final release is near, the amount of work to make everything
fit can be reduced if we follow the release cycle proposed:
- Release the BOMs
- Update the Stacks.yaml with new BOM version
- Update the Quickstarts to use the new BOM
- Update the Archetypes to use the new Quickstarts (with the new BOM)
- Update the Stacks.yaml with new Archetype version
- Finally release JDF site
Well, that's just a brainstorm and a initial point to begin the discussion.
--
Rafael Benevides | Senior Software Engineer
Red Hat Brazil
+55-61-9269-6576
Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com
12 years, 5 months
Re: [jdf-dev] SOA-P quickstarts
by Pete Muir
On 11 Apr 2013, at 18:08, Keith Babo <kbabo(a)redhat.com> wrote:
>
> Howdy,
>
> We have a ton of quickstarts already:
> https://github.com/jboss-switchyard/quickstarts
>
> I don't think they relate 1:1 to the type of thing we would do for JDF, but I think they can be used as source materials to create something better. My two main beefs with our project quickstarts at the moment:
>
> - Original use cases for examples are tough to come by and people tend to copy and paste the same example artifacts.
> - They tend to be very focused on a particular feature being demonstrated vs. a showcase of the project.
These are what we refer to as quickstarts. Showcasing something simple and constrained.
Your quickstarts look great for what we need, so it's just a case of aligning them well.
>
> I think the JDF stuff for SOA should have some business relevance with original examples and demonstration of multiple aspects of the platform working together. There was a home loan demo for SOA P 5 that we could do in SY/SOA 6 with no problem whatsoever.
This is what we are referring to as a showcase example, and we plan to do something here, probably starting in June, if that is ok with you guys (as I have a new guy starting then whose focus will be on building showcase examples). So my proposal is that we focus on quickstarts for now :-)
>
> I'm not a huge fan of archetypes in general, but I think they can be very useful if they represent a common pattern or practice. For example, SOAP proxying is something that happens quite a bit in SOA land and an archetype which spits out an application based on that template could be valuable.
Yes, I agree archetypes aren't great. However we've found they are useful as they are common format which everyone can write. Then we have Forge for more advanced project manipulation.
>
> cheers,
> keith
>
>
> On Apr 11, 2013, at 12:32 PM, Pete Muir <pmuir(a)redhat.com> wrote:
>
>> Hi all,
>>
>> Kenny has offered to help out getting the SOA-P quickstarts into shape - making sure they are consistent with those we have for EAP etc.
>>
>> From our side, Sande and Rafael can both help you, as can I. The best way to get help is to join #jboss-jdf on freenode.
>>
>> A few resources to start with:
>>
>> * Contribution guide - https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/CONTRIBUTING.md - cover lots of stuff like code formatting
>> * For those with access - overall developer experience requirements - https://docspace.corp.redhat.com/docs/DOC-136011
>> * QSTools - Rafael, please provide the link - this tool automates many of the checks we do on quickstarts
>>
>> In general, one of our big requirements is that there are a lot of comments in the code, this is often the most laborious area, and hopefully one where Kenny can really help, as he knows about the subject :-)
>>
>> The goal here is to get any quickstarts that we have on the SOA-P side ready for inclusion in JDF, and also to identify any gaps we may have, and find volunteers to work on those.
>>
>> It's also worth thinking about an archetype or two for SOA-P at the same time. Rafael's QSTools is able to generate archetypes from quickstarts, so it's really just a case of identifying which quickstart(s) to base it on.
>>
>> Finally, I should mention that do want to focus on SOA-P here, not on the upstream projects.
>>
>> Kev, Keith, could you respond with what you know we have in SOA-P land today, and where Kenny et al can start to take a look?
>>
>> Pete
>
12 years, 5 months
Archetype Synchronization.
by Rafael Benevides
After some work improving QSTools, it now has the feature to synchronize
Archetypes with a specified project.
Note: I took a look on fuse tooling but it doesn't fit our needs and
lacks of customization.
For QSTools, the only thing needed it to add qstools plugin declaration
to archetype pom.xml as the following example:
(...)
|||<plugin>|||
|||<groupId>org.jboss.maven.plugins</groupId>|||
|||<artifactId>maven-qstools-plugin</artifactId>|||
|||<version>1.0.0.CR3</version>|||
||| <configuration>|||
|||<projectGitRepo>git://github.com/jboss-jdf/jboss-as-quickstart.git</projectGitRepo>|||
|||<projectPath>kitchensink-ear</projectPath>|||
|||<rootPackage>org.jboss.as.quickstarts.kitchensink_ear</rootPackage>|||
|||<multiModuleProject>true</multiModuleProject>|||
|||<branch>jdf-2.1.1.Final</branch>|||
|||<extraReplaceValues>|||
|||<extraReplaceValue>jboss-as-kitchensink-ear</extraReplaceValue>|||
|||<extraReplaceValue>kitchensink-ear-quickstart</extraReplaceValue>|||
|||<extraReplaceValue>kitchensink-quickstart</extraReplaceValue>|||
|||<extraReplaceValue>KitchensinkEarQuickstart</extraReplaceValue>|||
|||<extraReplaceValue>JBoss AS Quickstarts: Kitchensink
EAR</extraReplaceValue>|||
|||</extraReplaceValues>|||
||| </configuration>|||
||| <executions>|||
||| <execution>|||
|||<phase>generate-sources</phase>|||
||| <goals>|||
|||<goal>archetypeSync</goal>|||
||| </goals>|||
||| </execution>|||
||| </executions>|||
||| </plugin>|
(...)
The Archetypes results is at the following PR:
https://github.com/jboss-jdf/jboss-as-archetype/pull/15
I made tests on the generated Archetype and I liked the result, but I
would like to ask for help on testing it too.
Feel free to post comments on this feature/result.
Thank you.
-------- Mensagem original --------
Assunto: [JBoss JIRA] (JDF-253) jboss-html5-mobile-archetype does align
jQuery version with WFK
Data: Thu, 11 Apr 2013 17:16:56 -0400 (EDT)
De: Rafael Benevides (JIRA) <jira-events(a)lists.jboss.org>
Para: benevides(a)redhat.com
Rafael Benevides
<https://issues.jboss.org/secure/ViewProfile.jspa?name=rafabene>
commented on Bug JDF-253 <https://issues.jboss.org/browse/JDF-253>
*jboss-html5-mobile-archetype does align jQuery version with WFK*
<https://issues.jboss.org/browse/JDF-253>
The Archetype are now kept in sync with the origin quickstart. That's
made by a QSTools goal.
I would like that the following PR should be reviewed/tested for someone
else: https://github.com/jboss-jdf/jboss-as-archetype/pull/15
I made some basic tests and I feel confortable with the sync made by
QSTools, but it's always good that have another review or more tests.
This Pull Request has 3 modifications/commits
1) Remove the Blank Archetype - There's no need to keep the Archetypes
on gitrepo since it's generated with release.sh script
2) Added pom.xml config that to use qstools:archetypeSync goal. The main
point is that a Archetype could be synched with a branch/tag/commit -
*The idea is that the archetypes should use a quickstarts .Final tag on
each JDF release.*
<projectGitRepo>git://github.com/jboss-jdf/jboss-as-quickstart.git</projectGitRepo>
<projectPath>kitchensink-html5-mobile</projectPath>
<rootPackage>org.jboss.as.quickstarts.html5_mobile</rootPackage>
<branch>628fe0122ca9e81812b52d0cfc723d0e12078562</branch>
3) The synchronization it self. I tested it but I would like that you
test it too before I merge this PR.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
SOA-P quickstarts
by Pete Muir
Hi all,
Kenny has offered to help out getting the SOA-P quickstarts into shape - making sure they are consistent with those we have for EAP etc.
>From our side, Sande and Rafael can both help you, as can I. The best way to get help is to join #jboss-jdf on freenode.
A few resources to start with:
* Contribution guide - https://github.com/jboss-jdf/jboss-as-quickstart/blob/master/CONTRIBUTING.md - cover lots of stuff like code formatting
* For those with access - overall developer experience requirements - https://docspace.corp.redhat.com/docs/DOC-136011
* QSTools - Rafael, please provide the link - this tool automates many of the checks we do on quickstarts
In general, one of our big requirements is that there are a lot of comments in the code, this is often the most laborious area, and hopefully one where Kenny can really help, as he knows about the subject :-)
The goal here is to get any quickstarts that we have on the SOA-P side ready for inclusion in JDF, and also to identify any gaps we may have, and find volunteers to work on those.
It's also worth thinking about an archetype or two for SOA-P at the same time. Rafael's QSTools is able to generate archetypes from quickstarts, so it's really just a case of identifying which quickstart(s) to base it on.
Finally, I should mention that do want to focus on SOA-P here, not on the upstream projects.
Kev, Keith, could you respond with what you know we have in SOA-P land today, and where Kenny et al can start to take a look?
Pete
12 years, 5 months