Spec BOM versions
by George Gastaldi
Hi All !!
The latest EE plugins in forge now allows you to select a spec BOM
version. There should be some way to display what´s in each BOM, like
the JSF version used, etc.
Is this information listed somewhere ?
Regards,
George Gastaldi
11 years, 11 months
Plug-in for collect key properties list from source code with regular expressions
by Pablo Palazon
Hi everybody!,
I'd like to present a plug-in for collect key properties and be added to
properties files (https://github.com/ppalazon/rxlist-forge). Basic, this
plug-in search regular expressions in the content of a group of files, for
example all java source code (*.java).
I use this plug-in for collect multilingual key used in java and xhtml
code. For example:
facesmessages.info(messages.getMessage("command.success.message"))
or
<h:outputText value="#{messages['person.preffix']}, #{user.lastname}"/>
Normally, I wrote business code and I don't worry about write this in a
multilingual properties file. Later, I must review all code for collect
used multilingual keys. This is tedious when you have many sources files,
and you have some keys in properties file.
For install: forge git-plugin git://github.com/ppalazon/rxlist-forge.git
This plug-in only contains a commands with 3 arguments
--rxProperties -> regular expression for find properties files
(Messages.*.properties)
--rxSearchFiles -> regular expression for say which files explore (.*.java,
.*.xhtml, etc)
--regexp -> regular expression for describe where is keys
(messages.getMessage\(''(.*?)''\), messages.getMessage\('(.*?)'\))
Examples:
rxlist --rxProperties messages_.*.properties --rxSearchFiles .*.java
--regexp Componente1.getMessage\(''(.*?)''\) - (I use 2 simple quotes,
don't double quote)
rxlist --rxProperties messages_.*.properties --rxSearchFiles .*.xhtml
--regexp messages.getMessage\('(.*?)'\) - With simple quotes
All regular expression is based on Java Pattern (
http://docs.oracle.com/javase/6/docs/api/java/util/regex/Pattern.html)
This plugin insert non declared properties keys in properties files, and
insert a default content (founded.key=>>founded.key).
If you would like to see this in action, there are some test files in
src/test/resources with 2 properties files, 1 java file and 1 xhtml file.
You can open original properties files, and search updated properties files
with test (RegExpListPluginTest) in a generated directory.
I used this plug-in in a web application, and It's useful when you'd been
used a lot of properties key for multilingual. I'd like to listen you any
suggest, error or improve for this plug-in, or maybe this help you for
create new plug-in for forge. Thanks you so much for this platform, it was
very easy and quick develop this plug-in.
11 years, 11 months
Forge test failures due to JavaParser Formatting
by Lincoln Baxter, III
Hey Guys,
Looking like some test failures were introduced in the faces-scaffold
project due to the new JavaParser formatting.
Ivan, could you or someone else take a look if you have a free moment?
Otherwise I'll keep working on them as I get a chance. It looks like purely
a formatting issue, not a functional one. So the tests just need to be
updated.
Mucho gracias :)
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
11 years, 11 months
Moving forward with FORGE-183
by Jevgeni Zelenkov
Hi Forge developers,
I am still stuck trying to get FORGE-183 pull request accepted. Did I
set the record already as the longest unaccepted pull request in the
Forge's history? :)
Here is the summary of all the feedback I received so far:
----
----
Does it make sense to require the Git Facet on the GitPlugin? Facets
imply that a project is also required, and it may be possible to use
GitPlugin outside of a project. This is a limitation, currently, where
Facet constraints cannot be placed on individual methods - but
something we hope to address in the future. So in the mean time, The
plugin would need to be split into two separate plugins - we can
discuss the best approach for this on the dev list.
--
Regarding the GitFacet - I believe it's in the right place for the moment,
but I don't believe that the GitPlugin should be referencing it, since the
commands in GitPlugin could be used even without a Project.
GitFacet (as the issue describes poorly) is something that should be usable
to inspect the state of a Project via:
project.hasFacet(GitFacet.class)
After that, everything else is an added benefit. It should probably also
perform tasks like:
project.getFacet(GitFacet.class).getBranches()
project.getFacet(GitFacet.class).getTags()
project.getFacet(GitFacet.class).getRemotes()
project.getFacet(GitFacet.class).getStatus()
And that's where your imagination kicks in.
--
To confuse things even further, I would not implement the actual JGit
features in the Facet itself (even though it would be correct to do
so.) I would instead create a utility class that the Facet itself
would use. This utility class could be reused by plugins directly (for
plugins that do not necessarily operate on a project.)
So, really FORGE-183 is open-ended, but in general it's meant to allow
projects to know when they contain a Git repository. You will need this
feature for the Git undo plugin.
--
My recommendation is to implement GitFacet in such a way that it will be
"installed" or "registered" if the project contains, or exists in, a git
repository. Then once you have done that, I'd start working on the
UndoPlugin and UndoFacet.
----
----
Based on that feedback, I wrote a TODO list of updates, which should
be added to the current pull request to get it accepted:
1. remove "RequiresFacet" annotation from the Git plugin
2. At least the following methods should be added to the Git plugin,
GitFacet and GitUtils: getBranches(), getTags(), getRemotes() and
getStatus(). GitFacet has no dependency on jGit, GitUtils is dependent
on jGit. GitFacet install() and isInstalled() methods are OK in their
current form.
3. Current GitUtils methods should refactored, so that they don't
return any objects from jGit library, like Ref. (the only exception
being "public static Git git(final DirectoryResource dir)")
Does that make sense?
Here is a demo implementation of the getBranches methods for Git
plugin, GitFacet and GitUtils. Other methods will look similar.
Git plugin method implementation:
@Command("branches")
public void gitGetBranches() throws Exception
{
if (shell.getCurrentProject().hasFacet(GitFacet.class))
shell.getCurrentProject().getFacet(GitFacet.class).getBranches();
}
GitFacet method implementation:
public List<String> getBranches()
{
Git git = GitUtils.git(project.getProjectRoot());
return GitUtils.getBranches(git);
}
GitUtils method implementation (actually implements the functionality):
public static List<String> getBranches(final Git repo)
{
List<String> results = new ArrayList<String>();
for(Ref branchRef : repo.branchList().call())
{
results.add(branchRef.getName());
}
return results;
}
General questions:
1. Does installFacet() method needs to be called anywhere in the Git plugin?
2. Does Git plugin should be split into two plugins? One containing
project-related methods, and another, containing methods, which could
be called outside of a project.
I would appreciate your feedback.
Best regards,
Jevgeni
11 years, 11 months
@GeneratedValue Strategy
by Ryan Bradley
Greetings all,
Currently, the entity plugin annotates the ID primary key with
@GeneratedValue. This annotation uses the default generation strategy,
GenerationType.AUTO, to generate the values for this key. Using this
strategy, the same set of values is used for all entity tables. In
other words, you cannot have two entities with the same value for ID, as
it is incremented with each entity creation rather than with each
creation of an entity of a specific type.
Thinking of scaffold implementations, it might be best if a separate set
of IDs was generated for each separate entity. I believe that this can
be accomplished by annotating the field with
@GeneratedValue(strategy=GenerationType.IDENTITY). I was thinking of
modifying the ScaffoldPlugin to change the GenerationType on this
annotation in the generateFromEntity method (from-entity command).
Any objections to this change?
Cheers,
Ryan
11 years, 11 months
Re: [forge-dev] Checking in (Lincoln Baxter, III)
by Jevgeni Zelenkov
Thanks a lot! Yes the idea with installing GitFacet makes sense.
-- Jevgeni
On Thu, May 17, 2012 at 6:00 PM, "Lincoln Baxter, III"
<lincolnbaxter(a)gmail.com> wrote:
> Hey Jevgeni,
>
> I'm copying the dev list because this is a public question. (Please try to
> do this on all communications unless it is something private :) That way we
> can all help and discuss.
>
> So, really FORGE-183 is open-ended, but in general it's meant to allow
> projects to know when they contain a Git repository. You will need this
> feature for the Git undo plugin.
>
> My recommendation is to implement GitFacet in such a way that it will be
> "installed" or "registered" if the project contains, or exists in, a git
> repository. Then once you have done that, I'd start working on the
> UndoPlugin and UndoFacet. You will quickly discover which other methods the
> GitFacet needs to contain, and we can discuss on the dev list in order to
> make sure the design is as good as we can get it.
>
> Sound good?
> ~Lincoln
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/forge-dev
11 years, 11 months
Helping on the Forge website
by Lincoln Baxter, III
Hey Sandro (and all!)
I'd like to outline my goals for the Forge website and get feedback,
possible also get help:
1. As a first step, we need to parse the plugin repository and bring it
into the website in order to let people see the plugins we have at this
point. Perhaps we could expand the descriptions of some so that people know
how to get started using them.
2. As a second step, the plugin's README documentation from GitHub
should be displayed in the body of the forge website. This way each plugin
would have a way to describe its usage directly in the results.
3. As a third step, it should be possible to search this list of plugins
via the website, so you can see a list of matching plugins, and a short
description of each so that you can know if it's what you're looking for
before you view the full page for that plugin.
It would look a lot like what Arquillian has done here for their API docs,
which I'd also like to pull in for Forge plugin developers with the Forge
APIs:
http://staging-arquilliandev.rhcloud.com/modules/reference/#org.jboss.arq...
What do you guys think?
~Lincoln
11 years, 11 months
Re: [forge-dev] Checking in
by Lincoln Baxter, III
Hey Jevgeni,
I'm copying the dev list because this is a public question. (Please try to
do this on all communications unless it is something private :) That way we
can all help and discuss.
So, really FORGE-183 is open-ended, but in general it's meant to allow
projects to know when they contain a Git repository. You will need this
feature for the Git undo plugin.
My recommendation is to implement GitFacet in such a way that it will be
"installed" or "registered" if the project contains, or exists in, a git
repository. Then once you have done that, I'd start working on the
UndoPlugin and UndoFacet. You will quickly discover which other methods the
GitFacet needs to contain, and we can discuss on the dev list in order to
make sure the design is as good as we can get it.
Sound good?
~Lincoln
On Thu, May 17, 2012 at 11:24 AM, Jevgeni Zelenkov <
jevgeni.zelenkov(a)googlemail.com> wrote:
> Hi Lincoln,
>
> I was unable to finish with the FORGE-183 issue. I don't have a clear
> idea of what exacly needs to be done. GitPlugin, GitFacet and GitUtils
> classes are already present. Should I make sure, that GitPlugin only
> calls GitFacet or GitUtils methods and that GitUtils never returns
> jGit-related classes?
> It feels like I should not submit any concrete undo-plugin related
> method implementations as a part of FORGE-183. That should be a
> different issue.
> Is it even the right thing to do, to concentrate on FORGE-183 so much?
> Should I just start coding features and deal with FORGE-183 later?
> (FORGE-183 looks like refactoring to me now)
>
>
> Best regards,
> Jevgeni
>
> On 5/16/12, Lincoln Baxter, III <lincolnbaxter(a)gmail.com> wrote:
> > Hi Jevgeni,
> >
> > Just checking in to see how your vacation was :) Are you ready to get
> > started on your super Git undo plugin? :)
> >
> > --
> > Lincoln Baxter, III
> > http://ocpsoft.org
> > "Simpler is better."
> >
>
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
11 years, 11 months
