I think that GroupId should be explicit. So maybe add GroupId as a
required param and make topLevelPackage an option that defaults to
GroupId and is only applicable for non-pom projects.
So the user would be required to enter the project name and group id.
If this is a pom project then we'd proceed to create it. If this is a
non-pom (jar, war, ear, etc.) then if they did not enter
topLevelPackage, we'd prompt for it with a default of the GroupId. By
keeping them separate we can also use different validation rules so
you could have a GroupId that uses java reserved words but then you'd
have to specify a different topLevelPackage.
On Tue, May 17, 2011 at 10:02 AM, Lincoln Baxter, III
<lincolnbaxter(a)gmail.com> wrote:
Hmmm, that is a good point. For now however, for simplicities sake,
let's
use the PackagingType enum to enable selection, and only use the
'--createMain' command if the project is a JAR or WAR.
For --finalName, I think we can leave that safely?
For --topLevelPackage, I agree, let's just add a better description. In
fact, there is another issue with this that involves java keywords, so we
should probably address these at the same time:
https://issues.jboss.org/browse/SEAMFORGE-167
We might actually want to add a check in the NewProjectPlugin that verifies
if the groupId is a valid java package. If not, we can offer to keep the
groupId but let the user specify a new, legal, java package name for the
topLevelPackage.
Thoughts?
~Lincoln
On Tue, May 17, 2011 at 1:35 AM, Tim Pedone <macdude357(a)gmail.com> wrote:
>
> One issue with reusing the existing plugin is that some of the options
> don't apply to pom projects. In particular are the createMain and
> FinalName options. Also the topLevelPackage option should really be
> GroupId for a pom although I guess we could solve that with a little
> more info in the help text so it's obvious that "topLevelPackage" =
> "GroupId".
>
> On Mon, May 16, 2011 at 10:25 PM, Lincoln Baxter, III
> <lincolnbaxter(a)gmail.com> wrote:
> > I think we should try to re-use the existing new-project plugin. Default
> > to
> > Java, but offer an @Option for PackagingType in order to facilitate
> > things.
> >
> > This is worth looking in to for sure, more tomorrow.
> > ~Lincoln
> >
> > On Mon, May 16, 2011 at 10:36 PM, Tim Pedone <macdude357(a)gmail.com>
> > wrote:
> >>
> >> I was copying the NewProjectPlugin as the basis for a
> >> NewPomProjectPlugin so when I said I'd remove that code, I meant from
> >> the copied code I was using. Before I do that, would you rather have
> >> a different plugin for the Pom project or add a "type" argument to
the
> >> new-project command?
> >>
> >> On Mon, May 16, 2011 at 7:12 PM, Lincoln Baxter, III
> >> <lincolnbaxter(a)gmail.com> wrote:
> >> > Why do you need beans.xml in a POM project? I mean, if this is a case
> >> > that
> >> > you really need, it might be something we should change in Forge.
> >> > Just
> >> > trying to understand better what you need :)
> >> >
> >> > On Mon, May 16, 2011 at 5:57 PM, Tim Pedone
<macdude357(a)gmail.com>
> >> > wrote:
> >> >>
> >> >> I see, I'll try omitting the code that creates the beans.xml
file
> >> >> when
> >> >> generating a pom project and see if that works.
> >> >>
> >> >> On Mon, May 16, 2011 at 12:59 PM, Lincoln Baxter, III
> >> >> <lincolnbaxter(a)gmail.com> wrote:
> >> >> > If there is no beans.xml in the project, CDIFacet will not
> >> >> > register
> >> >> > itself;
> >> >> > howeer, it's possible that we need to further restrict
packaging
> >> >> > types
> >> >> > for
> >> >> > CDIFacet to JAR and WAR.
> >> >> >
> >> >> > ~Lincoln
> >> >> >
> >> >> > On Mon, May 16, 2011 at 11:22 AM, Tim Pedone
> >> >> > <macdude357(a)gmail.com>
> >> >> > wrote:
> >> >> >>
> >> >> >> Sorry, I must have miscommunicated what was going on. I
don't
> >> >> >> want
> >> >> >> to
> >> >> >> use the CDIFacet, it's getting added automatically.
If you take
> >> >> >> a
> >> >> >> look at the NewProjectPlugin code, it adds some facets to
the
> >> >> >> project:
> >> >> >>
> >> >> >> Project project = projectFactory.createProject(dir,
> >> >> >> DependencyFacet.class,
> >> >> >> MetadataFacet.class,
> >> >> >> JavaSourceFacet.class,
ResourceFacet.class);
> >> >> >>
> >> >> >> ProjectFactory adds the given facets to the project but
then
> >> >> >> calls
> >> >> >> registerFacets() which iterates *all* facets and adds them
to the
> >> >> >> project resulting in the CDIFacet (and others) getting
added.
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> On Sun, May 15, 2011 at 10:01 PM, Lincoln Baxter, III
> >> >> >> <lincolnbaxter(a)gmail.com> wrote:
> >> >> >> > I don't think that using the CDIFacet for this
purpose is the
> >> >> >> > right
> >> >> >> > thing to
> >> >> >> > do. The CDI Facet represents a java project with CDI
enabled,
> >> >> >> > so I
> >> >> >> > don't
> >> >> >> > think a POM project fits that description :)
> >> >> >> >
> >> >> >> > I would just add the CDI api as a dependency, though
I suppose
> >> >> >> > I
> >> >> >> > should
> >> >> >> > ask,
> >> >> >> > why are you trying to do this in this particular
way?
> >> >> >> >
> >> >> >> > ~Lincoln
> >> >> >> >
> >> >> >> > On Sun, May 15, 2011 at 2:02 AM, Tim Pedone
> >> >> >> > <macdude357(a)gmail.com>
> >> >> >> > wrote:
> >> >> >> >>
> >> >> >> >> As part of implementing the ability to add
dependencies based
> >> >> >> >> off
> >> >> >> >> the
> >> >> >> >> dependencyManagement section of a parent pom, it
would be
> >> >> >> >> helpful
> >> >> >> >> for
> >> >> >> >> testing purposes (and likely for users as well)
to be able to
> >> >> >> >> create
> >> >> >> >> a
> >> >> >> >> project of type "pom". I copied the
NewProjectPlugin and used
> >> >> >> >> it
> >> >> >> >> to
> >> >> >> >> create a PomProjectPlugin. I removed the Java
facet and set
> >> >> >> >> the
> >> >> >> >> packaging to "pom"; however, it seems
that
> >> >> >> >> ProjectFactory.createProject() calls
registerFacet() which
> >> >> >> >> attempts
> >> >> >> >> to
> >> >> >> >> add every facet (CDI, JEE, etc.) to the project.
The CDI
> >> >> >> >> facet
> >> >> >> >> fails
> >> >> >> >> because the project is not a war or jar. Is that
behavior
> >> >> >> >> correct
> >> >> >> >> (adding the CDI facet to all projects)?
> >> >> >> >> _______________________________________________
> >> >> >> >> forge-dev mailing list
> >> >> >> >> forge-dev(a)lists.jboss.org
> >> >> >> >>
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >> > --
> >> >> >> > Lincoln Baxter, III
> >> >> >> >
http://ocpsoft.com
> >> >> >> >
http://scrumshark.com
> >> >> >> > "Keep it Simple"
> >> >> >> >
> >> >> >> > _______________________________________________
> >> >> >> > forge-dev mailing list
> >> >> >> > forge-dev(a)lists.jboss.org
> >> >> >> >
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >> _______________________________________________
> >> >> >> forge-dev mailing list
> >> >> >> forge-dev(a)lists.jboss.org
> >> >> >>
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >> >
> >> >> >
> >> >> >
> >> >> > --
> >> >> > Lincoln Baxter, III
> >> >> >
http://ocpsoft.com
> >> >> >
http://scrumshark.com
> >> >> > "Keep it Simple"
> >> >> >
> >> >> > _______________________________________________
> >> >> > forge-dev mailing list
> >> >> > forge-dev(a)lists.jboss.org
> >> >> >
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >> >
> >> >> >
> >> >>
> >> >> _______________________________________________
> >> >> forge-dev mailing list
> >> >> forge-dev(a)lists.jboss.org
> >> >>
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >
> >> >
> >> >
> >> > --
> >> > Lincoln Baxter, III
> >> >
http://ocpsoft.com
> >> >
http://scrumshark.com
> >> > "Keep it Simple"
> >> >
> >> > _______________________________________________
> >> > forge-dev mailing list
> >> > forge-dev(a)lists.jboss.org
> >> >
https://lists.jboss.org/mailman/listinfo/forge-dev
> >> >
> >> >
> >>
> >> _______________________________________________
> >> forge-dev mailing list
> >> forge-dev(a)lists.jboss.org
> >>
https://lists.jboss.org/mailman/listinfo/forge-dev
> >
> >
> >
> > --
> > Lincoln Baxter, III
> >
http://ocpsoft.com
> >
http://scrumshark.com
> > "Keep it Simple"
> >
> > _______________________________________________
> > forge-dev mailing list
> > forge-dev(a)lists.jboss.org
> >
https://lists.jboss.org/mailman/listinfo/forge-dev
> >
> >
>
> _______________________________________________
> forge-dev mailing list
> forge-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/forge-dev
--
Lincoln Baxter, III
http://ocpsoft.com
http://scrumshark.com
"Keep it Simple"
_______________________________________________
forge-dev mailing list
forge-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/forge-dev